[gelöst]Nachrichten an schlafende Node senden funktioniert nicht

Begonnen von frober, 01 März 2023, 19:41:43

Vorheriges Thema - Nächstes Thema

frober

Hallo zusammen,

laut MYSENSORS API ist es möglich, Nachrichten an die schlafende Node zu senden, die beim Aufwachen "abgeholt" werden.

ZitatEach sleep function has a "smart" variant, which sends heartbeat and process incoming messages before going to sleep. This is useful for sending out firmwares or commands for sleeping nodes. The controller must support buffering of messages and send them when node wakes up.

Während der Entwicklung hat das teilweise funktioniert, d.h. nicht jedes Aufwachen bekam die Nachrichten gesendet, bzw. manchmal kam auch nur ein Teil der Nachrichten.
Im finalen Betrieb (~10-15 s wach) funktioniert es gar nicht mehr.

Das senden, bzw. der Empfang der Nachrichten funktioniert grundsätzlich, wenn die Node wach ist.

Im GW und der Node ist jeweils requestAck gesetzt.

Muss ich noch etwas einstellen, bzw. wurde das überhaupt implementiert?

Nachtrag: V2.3.1

Danke und Grüße
Bernd
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Beta-User

Hmmm, an sich unterstützt FHEM smartSleep, und mir wäre auch nicht bewußt, was geändert zu haben, was in der Hinsicht problematisch sein könnte.
Ob man da was per Attribut oder so einstellen muß, hast du bestimmt geprüft? (Ich meine mich zu erinnern, dass die "ich geh schlafen"-Meldung ausreicht und das automatisch geht).

Da du Ack anforderst, sollte das auch immer wieder versucht werden.

Problematisch ist eigentlich nur das timing (ähnlich wie beim Pairing bei CUL_HM): Die message muss rechtzeitig vom GW versendet werden, sonst schläft die Node schon wieder.

Würde daher erst mal nach den "üblichen Verdächtigen" fahnden:
- delays in FHEM selbst (v.a. viele Events?)
- Netzwerkdelays (v.a. falls ein WLAN-GW im Spiel ist => wirkt sich negativ auf den Hin- und Rückweg aus!).
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

frober

Danke Beta-User, für die schnelle Antwort.

Attr habe ich nichts spezifisches gefunden, außer requestAck.

Der GW hängt am USB und der Test läuft aktuell auf einem Testsystem. Da passiert nicht viel, ist aber ein Raspi 1b+, also relativ langsam. Die Auslastung ist aber gering.

Was mir gerade einfällt, ich habe das logging mit SQL aktiviert, evtl. ist das der Grund, bezogen auf das Testsystem.

Ich probiere es Morgen mal auf meinem Hauptsystem Raspi 3b.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

KarlHeinz2000

Arbeitest du mit smartSleep im node?
Fhem muss erkennen, dass der node schlafen gehen will und sendet dann erst zum node.



sleep() [1/3]
int8_t sleep ( const uint32_t  sleepingMS,
const bool  smartSleep = false
)

Sleep (PowerDownMode) the MCU and radio. Wake up on timer.

Parameters
    sleepingMS Number of milliseconds to sleep.
    smartSleep Set True if sending heartbeat and process incoming messages before going to sleep.

Returns
    MY_WAKE_UP_BY_TIMER if timer woke it up, MY_SLEEP_NOT_POSSIBLE if not possible (e.g. ongoing FW update)



Das kann man aber auch während loop schon anstoßen. So mache ich das, wenn ich weiß, dass keine Nachrichten kollidieren können:
  // FHEM soll "preSleep" erkennen, obwohl hier noch LOOP ist
  // notify controller about going to sleep, payload indicates smartsleep waiting time in MS
  _sendRoute(build(_msgTmp, GATEWAY_ADDRESS, NODE_SENSOR_ID, C_INTERNAL, I_PRE_SLEEP_NOTIFICATION).set((uint32_t)MY_SMART_SLEEP_WAIT_DURATION_MS));


Somit bekomme ich ~90% der "im Schlaf" gesendeten Nachrichten. Der Rest geht leider trotzdem verloren.

frober

Zitat von: KarlHeinz2000 am 02 März 2023, 08:26:31
Arbeitest du mit smartSleep im node?

Das habe ich übersehen  :o

Ich habe aktuell nur sleep().
Das ist meine erste Funknode und ich habe mich auf den Bsp.Sketch von der MySensors Seite konzentriert, den ich auch bewusst nutze. Musste jedoch erst mal die Funktion verstehen. Vor allem, das das sleep nur durch Zuweisung an eine Variable schon ausgeführt wird, war mir nicht bewusst.
Dadurch ist mir smartSleep entgangen...

Ich ändere es auf smartSleep(), danke für den Hinweis.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...


frober

Zitat von: KarlHeinz2000 am 02 März 2023, 10:38:21
smartSleep ist deprecated, besser sleep(time,true) benutzen


https://www.mysensors.org/apidocs/group__MySensorsCoregrp.html#gab5f84c4227e3478af4b6600d5e8d8b15

OK, dann muss ich wohl doch schon auf die 2.3.2 umsteigen...
Mein softACK (in meinen RS484-Nodes) ist da auch schon auf Echo umgestellt und deprecated.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

KarlHeinz2000

wenn es geht, brauchst du nicht umstellen. Große Änderungen wird es bei MYS wohl eh nicht mehr geben  :-\

frober

#8
Ich bin doch auf die 2.3.2 umgestiegen. Die Änderungen betreffen ja nur die Schreibweise im Sketch, das Sendeprotokoll ist unverändert, somit habe ich erstmal bei den bestehenden Nodes keinen Handlungsbedarf.

Wenn man es richtig macht, funktioniert es auch. 8)

Ich habe #define MY_SMART_SLEEP_WAIT_DURATION_MS 5000ul gesetzt, damit habe ich aktuell bei den Tests alle Nachrichten empfangen.

Danke nochmals für eure Hilfe.

Nachtrag: ...und ich habe ein neues Reading sleepState asleep  ;D
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...