Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

[gelöst] Nodes überwachen: outstandingAck und alive Prüfung

Begonnen von alru, 27 März 2018, 20:13:15

Vorheriges Thema - Nächstes Thema

Ranseyer

FileLog soll schon sein.
Das wäre nun mein Stand:
(Das Log ist noch leer)

define Status_RS485 readingsGroup <Gerät>,<Status> TYPE=MYSENSORS_DEVICE:FILTER=IODev=mySensGwRS485
attr Status_RS485 DbLogExclude .*
attr Status_RS485 mapping %ALIAS
attr Status_RS485 room Unsorted
attr Status_RS485 valueFormat {$VALUE !~ m/alive/?$VALUE:undef;;}
attr Status_RS485 valueIcon {'state.dead' => 'lan_rs485@orange','state.NACK' => 'lan_rs485@red' }
define Status_RS485_Log FileLog ./log/Status_RS485-%Y-%m.log Status_RS485
attr Status_RS485_Log DbLogExclude .*
attr Status_RS485_Log room 9.90_Logs
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

Die ReadingsGroup dient m.E. nur zur Anzeige und generiert nach meiner Kenntnis keine eigenen Events.

Ich würde meinen, dass das (ungetestet) eher so aussehen sollte:
define Status_RS485_Log FileLog ./log/Status_RS485-%Y-%m.log MYSENSORS.*:.(dead|alive|NACK)
und eben addStateEvent benötigt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

basti223

Hallo zusammen,

super Anpassung! Danach habe ich auch schon lange gesucht.. Könnte man im Zuge dieser Anpassung auch noch die Heartbeatlogik aus MySensors implementieren? Ich habe meine MySensors-Geräte alle so aufgebaut, dass diese alle 5 Minuten einen Heartbeat senden, anscheinend wird dieser in FHEM aber immer noch nicht ausgewertet :( Habe mit Verbose 5 im Gateway nichts dergleichen gesehen und meine Geräte springen alle auf dead  :(

Beta-User

Zitat von: basti223 am 21 Mai 2018, 22:22:03
Könnte man im Zuge dieser Anpassung auch noch die Heartbeatlogik aus MySensors implementieren? Ich habe meine MySensors-Geräte alle so aufgebaut, dass diese alle 5 Minuten einen Heartbeat senden, anscheinend wird dieser in FHEM aber immer noch nicht ausgewertet :(
Moin basti223,

die Heartbeat-Logik ist in den aktuellen Modulen nicht implementiert.

Wenn du magst, kannst du gerne meine aktuellen Versionen testen: https://github.com/rejoe2/FHEM_MYSENSORS/tree/Development
Es werden die 10_MYSENSORS_DEVICE.pm und die Constants.pm in lib/Device/MySensors benötigt.

Damit wird der heartbeat ausgewertet und man hat auch die Möglichkeit, diesen aktiv durch ein "get" anzufordern (was jedenfalls bei nicht-schlafenden Nodes problemlos funktioniert).

Hat auch den Vorteil, dass man darüber auch ein "get" für RSSI-Werte von RFM-Nodes absetzen können sollte (allerdings habe ich noch keine RFM-Nodes, weiß also nicht, ob die Richtung paßt, und die Rückmeldung bei RS485-Nodes ist wenig aussagekräftig ::) ). Was ganz vielleicht geht, ist das verzögerte Senden von Meldungen an "smartsleep"-Nodes (bislang komplett ungetestet, der Code-Entwurf schadet aber bei "normalen" nodes auch nicht).

Diese (bzw. eine geringfügig andere Vor-) Version hatte ich jetzt ca. 2 Wochen im Einsatz, die hat(te) aber noch ein paar Haken:

- Es gab da noch zu viele sichtbare interne Readings (sollte weitestgehend behoben sein)
- das battery-Reading ist umbenannt (siehe aktuelle Diskussion dazu im Entwickerbereich, auf batteryPercentage)

Dann gibt es noch einen zusätzlichen Percentage-Kanal für RGB(W)-Devices (da gab es neulich hier auch einen Thread zu).

An sich könnte man das "alive"-update zukünftig (so wie du (@bast223) das auch geplant hattest) nur noch bei einem heartbeat (bzw. evtl. noch einzubauen: einer smartsleep-Info) machen. Die Node muß das dann entweder senden, oder man muß ein entsprechendes get ausführen. Das würde den Code für alle anderen wieder entschlacken, die das nicht nutzen wollen (weil nur noch ein kleiner Teil der Messages zur Erneuerung des Timers führen würde).

Tests und Rückmeldung dazu sind natürlich willkommen, aber erwartet keine Wunder ;) . Insbesondere das mit dem smartsleep sollte sich mal jemand ansehen, der wirklich was von Perl versteht, da sind ein paar weitere Implikationen im Zusammenhang mit ACK-Anforderungen drin, die man ggf. noch abfangen sollte.

Und ob bzw. wann und in welcher Form das effektiv einen Weg in die offiziellen Module findet, ist eine andere Frage. Wenn allg. Interesse an den heartbeat-Geschichten besteht, aber die smartsleep-Funktionalität eine größere Baustelle ist, könnte man daraus ggf. auch recht einfach erst mal eine Zwischenversion stricken, die nur die oben geschilderten heartbeat und RSSI-Implementierung aus der 2.0 API enthält.

Grüße,
Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files