Ankündigung: Update auf MySensors 2.0 API - alive usw. geändert!

Begonnen von Beta-User, 04 Januar 2019, 13:05:24

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

nach längerer Vorbereitung in diesem Thread, werden mit dem morgigen Update auch Neuerungen bei MySensors verteilt. Es werden dann alle features unterstützt, die in der Version 2.0 der MySensors API enthalten sind.

Da manches anders ist, ist ggf. "action required", man kann die alte Funktionalität aber übergangsweise bei Bedarf noch recht einfach wieder aktivieren. Wie, steht hier:

- Benennung des battery-Readings.
Entsprechend dem Vorschlag im Developer-Bereich ist der Name dieses Readings zukünftig "batteryPercent"
Wer unbedingt den alten Namen benötigt: Zeile 707 wieder aktivieren (# entfernen) oder ein userreading anlegen (letzteres wäre die Empfehlung!)

- heartbeat
-- Sendet eine Node ein heartbeat(), wird das alive-Reading aktualisiert. Es wird empfohlen, beim Programmieren der Nodes, die auf "alive" überwacht werden sollen, darauf zu achten, dass diese einen heartbeat, einen Batterie-Wert (oder smartsleep-Signal) senden (s.u.).
-- Es gibt ein neues "get", mit dem eine Node auch aktiv "angepingt" werden kann - damit kann man also prüfen, ob die Kommunikation von und zu einer Node derzeit steht.
-- Das ist nicht-triggernd realisiert, man muß also den Browser-refresh ausführen, um den aktualisierten Zeitstempel zu sehen.
-- Einschränkung: Macht man das ganze über die Kommandozeile, erscheint ein leeres Dialogfeld. Wenn ich dazu komme, baue ich das noch um nach dem Muster von MQTT2_DEVICE; da geht das...
Wer das alte "alive"-Verhalten bei updates von allen Readings benötigt: Zeile 679 reaktivieren. Für Nodes, die dauerhaft per Funk zu erreichen sind und ein normales "sleep" verwenden, kann man bei Bedarf auch zyklisch einen heartbeat-Request ("get <node> heartbeat") senden.

Wichtig: Im Moment gehe ich davon aus, dass zwar alles funktioniert, der code aber noch an der einen oder anderen Stelle zu optimieren sein wird. Wer also nicht "ständig" nach updates die oben genannten Änderungen durchführen will, sollte nach dem morgigen update und Durchführung der für ihn relevanten Änderungen dann MYSENSORS_DEVICE vom update ausnehmen.

- OTA-Funktionalität
-- Status ist eher experimentell, auch wenn derzeit keine größeren Probleme bekannt sind!
-- Unterstützt werden sowohl der MYSBootloader (nur nRF-Nodes) wie der OptiBoot-Bootloader (alle Transportlayer).
-- Zur Konfiguration siehe die Commandref.
Danke an @Wallmeier für den Code dazu!

- Reading-Namen
Kommentare bei der Presentation können in die Reading-Namen eingebaut werden, das ganze wird durch ein "get" angestoßen.
Vorausgesetzt wird, dass die Node überhaupt einen entsprechenden Kommentar bei der Presentation sendet, der in den Readingnamen einfließen kann...

- smartsleep
-- Status wach/schlafend ist sichtbar
-- Es können auch Sendebefehle an schlafende Nodes ausgeliefert werden; dies setzt voraus, dass im jeweiligen Sketch statt sleep() smartSleep() verwendet wird.   
Hinweise und Einschränkung: bei Nicht-ACK-Nachrichten ist nicht auszuschließen, dass Messages verloren gehen, gerade bei solchen Nodes, die über einen Repeater angesprochen werden. Bei Problemen sollte zunächst die Zeit bis zum Einschlafen der Nodes verlängert werden (MY_SMART_SLEEP_WAIT_DURATION_MS).

- RSSI
-- erfordert aktive Anfrage via neuem "get" oder und entsprechenden Code auf der Node (MY_SIGNAL_REPORT_ENABLED)
-- macht nur bei RFM-Nodes Sinn (soweit bekannt; nRF liefert uu. einen kalkulierten Wert)
-- leeres Dialogfeld, wenn über FHEMWEB angestoßen (s.o.)
Hinweis: Es wird eine Art Schleife aufgerufen, die alle möglichen Werte nacheinander abfragt; gehen zwischenzeitlich Nachrichten verloren, muß das neu angestoßen werden, sonst gibt es ein internal, das anzeigt, auf welcher Stufe der Prozess gerade steht. Ist der länger unverändert, ist die Anforderung im off gelandet...

- MY_SPECIAL_DEBUG kann genutzt werden
Realisiert als Abfrageschleife wie RSSI, s.o., erfordert ebenfalls entsprechenden Code auf der Node.

Grüße und viel Freude mit den neuen features,

Beta-User

Changelog:
- Hinweis auf Batteriewert für alive-Refresh ergänzt
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

Ranseyer

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

Zitat von: Ranseyer am 05 Januar 2019, 13:15:12
Danke dir für den Einsatz !
Danke für die Rückmeldung, gerne geschehen!

Eine Anregung noch für die Entwicklung zukünftiger Platinen: Für RFM etc. wäre es super, wenn am SPI-Bus noch Platz wäre für Speicherbausteine... Die Dinger kosten als SOP8 so um die 40ct in China. Vielleicht kann jemand, der sowas im Einsatz hat mal melden, welche Type er verwendet?

Ich habe W25Q32B-Module daliegen, aber bisher nichts in die Richtung getestet, hat lange genug gedauert, bis das mit MYSBootloader mal was geworden ist...




Dann vielleicht mal als Ideensammlung und Ausblick - ohne Anspruch auf Vollständigkeit:
An sich sollte MYSENSORS die setExtensions nutzen. Allerdings sehe ich bei meinen Nodes keine entsprechenden Optionen. Vielleicht kann mich jemand aufschlauben, was da noch zu machen ist, damit das wirklich funktioniert - neben on-for-timer fände ich ein paar templates nett (für attrTemplate), um für die Standard-Sketche nettere Darstellungen "auf die Schnelle" bereitzustellen.
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

Ranseyer

Zitateine Anregung noch für die Entwicklung zukünftiger Platinen: Für RFM etc. wäre es super, wenn am SPI-Bus noch Platz wäre für Speicherbausteine...

Gute Idee. In den SMD-Varianten von Brasletti ist das schon so. (und in 1-2 Varianten von mir)
Ich versuche dran zu denken...
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!

The-Holgi

Hallo,
erstmal Danke für das update.
Mir ist aufgefallen, dass perfmon jede Minute eine Meldung ausgibt wenn das GW nicht erreichbar bzw in nicht in "Betrieb" ist.
Stellt man im device disconnect ein, sind die Meldungen weg.
2019.01.05 17:55:52.007 1: Perfmon: possible freeze starting at 17:55:49, delay is 3.007
2019.01.05 17:56:55.031 1: Perfmon: possible freeze starting at 17:56:53, delay is 2.031
2019.01.05 17:57:58.059 1: Perfmon: possible freeze starting at 17:57:56, delay is 2.059

Da ich gerade erst mit Mysensors angefangen habe, kann ich nicht sagen, ob das mit der "alten" Version auch schon war.

Gruß Holger
HP T610 Thin Client; Docker Fhem 5.9; 2X CUL V3 868mhz; Max Heizungssteuerung; FS20kse; FS20UWS; FS20S8-3; 2 FS20DI; HM-CFG-LAN,HM-LC-SW1-PL,HM-SEC-SD, HM-SE1PBU-FM;
Harmony Hub;Hue-Bridge mit Iris, E27 Bulb & FLS-PP

Beta-User

Zitat von: The-Holgi am 05 Januar 2019, 18:13:26
Da ich gerade erst mit Mysensors angefangen habe, kann ich nicht sagen, ob das mit der "alten" Version auch schon war.
Bin ziemlich sicher, dass das wenn, dann entweder aus 00_MYSENSORS kommt oder aus DevIO (maW: bereits länger so ist und scheinbar bisher in der Praxis kein Problem). Muß ich mir anschauen, kann aber dauern.
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

The-Holgi

Hallo,
ist ja auch kein großes Problem.
Wollte nur drauf hinweisen.

Gruß Holger
HP T610 Thin Client; Docker Fhem 5.9; 2X CUL V3 868mhz; Max Heizungssteuerung; FS20kse; FS20UWS; FS20S8-3; 2 FS20DI; HM-CFG-LAN,HM-LC-SW1-PL,HM-SEC-SD, HM-SE1PBU-FM;
Harmony Hub;Hue-Bridge mit Iris, E27 Bulb & FLS-PP

Markus.

Hallo Zusammen,

Habe meine Nodes jetzt von NrF auf RFM69 868 umgebaut und mit der neuen Lib geflahst.
Bis auf einen habe ich den Standard Sketch verwendet. Auf dem letzten habe ich dann MY_SIGNAL_REPORT_ENABLED und
MY_SPECIAL_DEBUG gesetzt. Dazu muss ich sagen das mein seirelles RFM Gateway noch auf Version 2.1 geflasht ist.
Bekomme aber kein RSSI zurück wenn ich ein get daruf mache. Kann es sein das es an der älteren Firmware des Gateways liegt? Oder muss ich da noch was berücksichtigen im Sketch?

Gruß

Markus


Beta-User

Moin,

eigentlich sollten die beiden Angaben so genügen, und die Features sollten auch mit einem beliebigen 2.x-GW funktionieren.

ABER: die Ausgabe müßte ich noch auf asynchrones get umstellen (habe aber noch keinen Plan, wie das genau ginge) - bisher bleibt das Dialogfeld immer leer, selbst wenn tatsächlich Werte ankommen (steht hoffentlich auch so in der cref und den Ankündigungen dazu). Und das erste Mal sieht man die entsprechenden Readings auch erst, wenn man die Seite neu lädt.

Und bei "schlafenden" geht es nur, wenn smartSleep aktiviert ist, sonst geht die Anfrage typischerweise ins (zeitliche) nirgendwo. Bitte dazu ggf. mehr Infos.
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

Markus.

#9
also Smartsleep habe ich am ende des Loops aktiviert..


//sendHeartbeat();
//sleep(SLEEP_TIME);
smartSleep(SLEEP_TIME);

Die Sleeptime habe ich auf 5 Minuten bei meinen Batterienodes.
"Beisst" sich eigentlich My_Debug und My_Special_Debug im Define?


#define MY_DEBUG
#define MY_SPECIAL_DEBUG
#define MY_SIGNAL_REPORT_ENABLED

// Enable and select radio type attached
  #define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY RFM69_868MHZ

#define MY_BAUD_RATE 38400
#define MY_NODE_ID 110



Gruß

Markus

Beta-User

Hmm,

ein paar Anmerkungen/Fragen:
- sprechen GW und Node grundsätzlich miteinander? (evtl. gab es da Änderungen im Treiber für RFM69, aus der sich Inkompabilitäten beim Funk ergeben). Also: Presentation kommt und ggf. Meßdaten/Infos über den Schlafzustand?
- Die untersch. DEBUG-Optionen sind m.E. was unterschiedliches und verursachen keine Konflikte
- Mit welcher Freq. läuft der Arduino? Ggf. geht die Anfrage auch deswegen ins Leere, weil der Arduino sich schneller wieder schlafen legt als gedacht (500UL is der default-Wert, müßte auch in der cref stehen).
- updates zu den Werten kommen erst, wenn der Arduino aufwacht; ggf. die Seite danach erst neu laden; ggf. zieht sich das sogar über mehrere Perioden (DEBUG-Info insbes.).

Für erste Tests würde ich erst mal ohne (smart)sleep rangehen, (wait müßte funktionieren), und dann nach und nach alles austesten, ggf. erst mal mit kürzeren Intervallen und Beobachtung der seriellen Konsole. Ich mußte auch erst mal ein Gefühl dafür entwickeln, wie was zusammenhängt, das dauert nach meiner Erfahrung einfach ein wenig...
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

Markus.

ja Gateway und node reden miteinander, die Daten kommen ja auch alle 5 Minuten sauber in FHEM rein.
Ich werde das mal austesten.

Gruß

Markus

Markus.

#12
Coole Sache :-)
Also bei mir sieht es nun wie folgt aus...

2019-02-23 06:49:01   R_RSSI_to_Parent -61
     2019-02-22 20:27:44   R_TX_Powerlevel_Pct -100
     2019-02-22 20:27:45   R_Uplink_Quality -245
     2019-02-22 19:56:05   SKETCH_NAME     Temperature Sensor
     2019-02-22 19:56:05   SKETCH_VERSION  1.0
     2019-02-23 06:59:35   XDBG_CPU_FREQUENCY 85
     2019-02-23 07:04:51   XDBG_CPU_VOLTAGE 3473
     2019-02-23 07:10:07   XDBG_FREE_MEMORY 1257
     2019-02-23 07:15:22   batteryPercent  83
     2019-02-22 19:56:05   parentId        0
     2019-02-23 07:15:23   state           asleep
     2019-02-23 07:15:22   temperature     23.9
     2019-02-23 07:15:22   voltage5        3.43


Ob die Werte, nicht die eigentlichen Sensorwerte, plausibel sind kann ich im Moment noch nicht beurteilen;-)
Beim GET RSSI wird der Wert auch beim nächsten "Aufwachen" übertragen. Nur wann RX_Uplink_Quality oder RX_TX_Powerlevel übertragen wird blicke ich noch nicht so ganz.

Gruß

Markus




Beta-User

Zitat von: Markus. am 23 Februar 2019, 06:57:46
Coole Sache :-)
:)
Das hört man doch gerne 8) .

Also: Übertragen wird nur auf Anfrage - dazu braucht man per default jeweils einen "get"-Request (ob man das vom Sketch aus auch anders lösen könnte, kann ich nicht sagen, geht aber vermutlich auch).

Da der Request erst an der Node ankommen muß, wird er bei smartSleep-Nodes gequeued (sonst weiß das Modul das ja nicht), und vor dem nächsten Einschlafen versendet (die smartSleep-Nodes melden das, warten kurz und gehen dann erst richtig schlafen).
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

Beta-User

Kurzer update:
Aufgrund einer Anfrage im MySensors-Forum gibt's anbei eine Testversion.

Die sollte eigentlich auch fehlerfrei laufen, enthält aber folgende Änderungen zu smartSleep:
- Wird was gesendet, wenn die node nicht schläft, wird gleich die ganze Queue ebenfalls versendet und nicht mehr auf die PRE_SLEEP_NOTIFICATION gewartet.
- kommt eine heartbeat-Message, sollte ebenfalls die Queue direkt versendet werden. Das letztere kann man nutzen, um Empfangsbereitschaft in der loop zu signalisieren (an sich reicht ja eine smartSleep-Message, um den alive-Status zu aktualisieren).

Wäre nett, wenn ein paar Leute Rückmeldung geben könnten, ob das soweit fehlerfrei läuft, ich habe aktuell keine Node im Einsatz, die smartSleep nutzt, und bei den normalen Nodes scheinen keine Probleme aufzutreten.

Gruß, 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