Fragen zu: Direkverknüpfungen mit HB-Sensoren

[FUEL4EP]

Danke!

Für WEATHER_TH zeigt mit grepall folgende Sketches von Dir, die diese LINK_ROLES definiert haben:

./JP-HB-Devices-addon/src/addon/firmware/rftypes/hb-rc-4-dis-th-crg.xml
./JP-HB-Devices-addon/src/addon/firmware/rftypes/hb-wds40-thp-o.xml
./JP-HB-Devices-addon/src/addon/firmware/rftypes/hb-uni-sen-temp.xml
./JP-HB-Devices-addon/src/addon/firmware/rftypes/hb-ou-af-sen-temp.xml
./JP-HB-Devices-addon/src/addon/firmware/rftypes/hb-uni-sen-cap-moist-t.xml
./JP-HB-Devices-addon/src/addon/firmware/rftypes/hb-rc-4-dis-th.xml
./JP-HB-Devices-addon/src/addon/firmware/rftypes/hb-uni-sen-wea_le_v10.xml
./JP-HB-Devices-addon/src/addon/firmware/rftypes/hb-uni-sen-wea.xml
./JP-HB-Devices-addon/src/addon/firmware/rftypes/hb-uni-sen-cap-moist.xml
./JP-HB-Devices-addon/src/addon/firmware/rftypes/hb-uni-sen-temp-sc.xml
./JP-HB-Devices-addon/src/addon/firmware/rftypes/hb-uni-sen-temp-max6675.xml

Welches davon ist ein gutes Beispiel für

Man konfiguriert einen Schwellwert und dann muss bei Erreichen ein sendPeerEvent erfolgen.

[jp112sdl]

Wie gesagt - ich hab es nur in einem Projekt ein-/umgesetzt

Wirklich bewusst verwendet habe ich WEATHER_CS nur bei der Wetterstation HB-UNI-SEN-WEA
https://github.com/jp112sdl/JP-HB-Devic ... ge_v14.xml
https://github.com/jp112sdl/HB-UNI-Sen- ... #L454-L472

[FUEL4EP]

.. dann müssen wir beide uns ja vor Plagiatsjägern hüten

Im Open-Source Bereich ist ja glücklicherweise Abschreiben erwünscht. Quellen müssen aber auch hier angegeben werden.

[Baxxy]

Oh, da habe ich ja wieder was angerichtet.

Primär hatte ich mich ja nur gewundert das in jedem Sketch "PEERS_PER_CHANNEL" definiert wird, aber man gar keine PEERS verknüpfen kann.

Grüße
Baxxy

[FUEL4EP]

Hi Baxxy,

nein, im Gegenteil. Solche Diskussionen helfen unserem Verständnis weiter. Ich werde beim nächsten Projekt versuchen, diese neuen Erkenntnisse mal umzusetzen. Die Frage kam gerade zur richtigen Zeit, um dort noch einzufließen Danke, dafür!

[Baxxy]

Ich werde beim nächsten Projekt versuchen, diese neuen Erkenntnisse mal umzusetzen.

Ich behalte das im Auge.

Ich bin jetzt die Informationen nochmal durchgegangen, verstehe aber leider nicht alles.

Auf meine "Anforderung" (Aktor EIN / AUS bei < oder > Helligkeit x) bezogen...
Der Sender (Sensor) müsste also entweder die Rolle "SWITCH" innehaben / emulieren (für einen fixen Entscheidungswert) oder sich als Bewegungsmelder ausgeben und einen Entscheidungswert mit dem Inhalt der aktuellen Helligkeit senden?

Klingt beides kompliziert...

Grüße
Baxxy

[papa]

Der Sensor muss nur einen Channel definieren, der den Helligkeitwert skaliert auf den Bereich von 0-255 (oder nur 200?) als Statusmessage sendet und die Liste4 für die Direktverknüpfung bereitstellen. Was dann die andere Seite (sprich der Empfänger) draus macht ist allein seine Sache. Aktor AN/AUS wäre dann auf jeden Fall ein SWITCH mit der entsprechenden Liste3.

[TomMajor]

ich finde auch, sehr interessante Frage von Baxxy.

Heißt u.a. doch auch dass für viele HomeBrew Sensoren (ohne expliziten Peer Support im xml und und Code) PEERS_PER_CHANNEL auf 0 gesetzt werden kann weil keine Auswirkung (aber wahrscheinlich nur interessant wenn man den EEPROM anderweitig braucht, sonst egal) ?

Im Bild die Settings eines HmIP-STHO-A.
Ich vermute die Parameter der Channels 2/3 "Entscheidungswert senden" usw. geben einen Eindruck wie man sowas parametrieren könnte und lassen den zusätzlich notwendigen Code im Sketch etwas erahnen..

Entscheidungswert hat den Range 0-255.

[jp112sdl]

Ich vermute die Parameter der Channels 2/3 "Entscheidungswert senden" usw. geben einen Eindruck wie man sowas parametrieren könnte und lassen den zusätzlich notwendigen Code im Sketch etwas erahnen..

Das entspricht Variante 1)

Da kämen 2 Konzepte infrage.
1.) Der SENDER sendet bei einem konfigurierten Schwellwert einen Entscheidungswert (wie z.B. Messsteckdosen es machen)
2.) Der SENDER sendet bei einer Aktion (z.B. MOTION) den Helligkeitswert mit. Dann liegt es beim Empfänger, die Helligkeit auszuwerten/zu verarbeiten.

Variante 2 wäre so, dass bei jeder Übertragung ein Wert 0...255 (Helligkeit) mitgesendet wird.

Der Sensor muss nur einen Channel definieren, der den Helligkeitwert skaliert auf den Bereich von 0-255 (oder nur 200?) als Statusmessage sendet und die Liste4 für die Direktverknüpfung bereitstellen. Was dann die andere Seite (sprich der Empfänger) draus macht ist allein seine Sache. Aktor AN/AUS wäre dann auf jeden Fall ein SWITCH mit der entsprechenden Liste3.

V1: Der Entscheidungswert gilt für alle DV-Partner
Vorteil: Gesendet wird sofort, wenn die Bedingung eintrifft.
Die Bedingungsprüfung erfolgt beim Sender und er muss dann nur den Entscheidungswert senden.
Reaktion: sehr schnell, Duty gering

V2: Jeder DV kann auf unterschiedliche Werte reagieren
Nachteil: Da der Wert nur bei einem Ereignis mitgesendet wird, ist das Verhalten träger.

[TomMajor]

Danke für die Erläuterungen.
So langsam beinhaltet der thread alle Infos die man braucht wenn mal jemand sowas implementieren wollte für einen HB Sensor.