[gelöst] smartSleep friert Fhem ein

[achim771]

Ich werde mal testweise einen RPI2 anstelle des RPI3+ testen...

[Beta-User]

Hmm, ich glaube eigentlich nicht, dass es an der Serverhardware hängt oder an der Zahl der Interfaces.

Im Moment würde ich noch tippen, dass die timer sich irgendwie in die Quere kommen; da hatte ich eh' längerfristig noch einen Umbau im Hinterkopf.

@achim771: Hat die Node 107 irgendwas, was speziell ist?
Könnte es sein, dass die Funkverbindung grenzwertig ist?

@alru: hast du mehrere schlafende Nodes im Einsatz oder nur die eine, mit der du das zuerst festgestellt hast? Wenn nur eine: Kannst du mal testen, ob es bei einer zweiten auch solche Nebenwirkungen hat? (Ich müßte erst wieder Hardware stöpseln, das dauert vermutlich insgesamt zu lange).

[achim771]

@Beta-User: Node 107 ist eine PIR-Sensor mit LDR (Sensebender Micro-Board im Eigenbau), Nach PIR-Trigger sendet das Node ein LDR-Wert, das Motion-Signal, und fragt 2 Werte vom Controller ab.
Räumlich liegt der Controller mittig in der Wohnung. Reichweite scheint daher i.O. zu sein. Mit der 2018er-Version läuft es auch ohne Probleme.
Das MYS-Gateway ist mit INT-Leitung, ein Nano und nRF24L01+PA+LNA-Modul.

Zur Hardware: mein Gedanke lag an der etwas merkwürdigen Serial/BT-Konstruktion des 3+, würde dann aber auch nur das HM-Modul direkt betreffen.

Leider fehlen mir die Perl-Programmierkenntisse.

[alru]

Moin,

das ursprüngliche Problem habe ich nur mit einem Node (mein Testgerät, ein UNO) getestet
Ich kann das gerne noch an einem anderen testen, wird aber vermutlich bis morgen dauern...

Der Test soll dann mit der 18211 Version laufen, das war ja der ursprüngliche, der bei mir die Probleme bereitet hat, richtig?
(Ich komm hier langsam mit den Versionen durcheinander ....)

[Beta-User]

Kein Streß, der Hinweis, dass die Node was wissen will, hat mich hoffentlich auf die richtige Spur gebracht.
Habe eben ein update hochgeladen, das wird mit dem heutigen update dann bereits verteilt.

@achim771: Dass es mit der 2018-er Version aus dem svn klappt, ist eigentlich klar. Da hat FHEM noch gar nichts davon mitbekommen, wenn eine Node in den smartSleep gegangen ist und daher alles, was zu versenden war, auch direkt rausgeschickt. Jetzt muß die Node dahingehend verwaltet werden, dass dieser Zustand überwacht wird. Leider schien die implementierte Methode, das nur über die POST_SLEEP_NOTIFICATION zu machen, (nicht nur im von alru festgestellten Fall, dass die Node neu gestartet wird) fehleranfällig zu sein: Geht die Notification - aus welchem Grund auch immer - verloren, wurde alles in die Warteschlange gesteckt, auch z.B. Zeit-Anfragen usw., die seitens der Node eine direkte Rückmeldung erwarten, weshalb diese die dann immer wieder schickt und damit eine Art Schleife auszulösen scheint.
Jetzt habe ich daher die Sperre für solche direkt zu versendenden Anfragen ausgebaut bzw. mehr eingehende Messages werden ähnlich wie eine POST_SLEEP_NOTIFICATION behandelt.

Rückmeldung ist erbeten, ich bin nicht ganz sicher, dass das update alle Fälle abdeckt.

[achim771]

super

kam heute spät von der Arbeit, aber seit ca 8h läuft der Server ohne Probleme mit dem letzten Update durch. Das war wohl das fehlende Puzzlestück.
Eine Sache ist mir allerdings noch aufgefallen:
.Einige Internals haben sich geändert, z.B. 'protocol' in 'version'
.Ein Repeater-Node, der alle 60sek ein heartbeat sendet hat im "state" nach wie vor "received presentation" (diese Node hat nur die Repeater-Funktion)
lässt sich daran etwas machen? alle anderen zeigen den awake, asleep, dead-state an

Super, Klasse Arbeit

[Beta-User]

  Danke für die Rückmeldung, hier läuft auch alles soweit durch.

Was den Repeater angeht, nehme ich an, dass der immer läuft, oder? Anders als bei smartSleep-Nodes muß man da ein extra Attribut setzen. Ist  das gesetzt?

[achim771]

Ja, der Repeater läuft natürlich hellwach durch. Das Heartbeat-Flag in den Internals wird auch gesetzt.
Welches Attribut sollte gesetzt werden? Ist das Timeout-Attribut gemeint? Da muss ich heute abend nachschauen.

[alru]

Moin,

ich habe auch einen Node, der als Aktor und Repeater arbeitet. Dort ist keine heartbeat oder smartSleep implementiert. In den Readings (@achim771: bei dir in den Internals ??) tauchte dann (verm. nach dem dem Fhem/Mysensor Update) irgendwann das heartbeat auf. Ein get heartbeat funktioniert auch.

Wie kann man diesen Nodes beibringen, regelmäßig ein heartbeat zu senden?
Mir fallen 2 Möglichkeiten ein:

• In die Loop vom Node einen Zähler einbauen, der nach x Loops einen heartbeat sendet
  
• Über ein at in Fhem den heartbeat abfragen.

Das von dir erwähnte Attribut kenne ich auch nicht, hört sich aber nach der von mir gesuchten eleganteren Lösung an.

[Beta-User]

Welches Attribut sollte gesetzt werden? Ist das Timeout-Attribut gemeint? Da muss ich heute abend nachschauen.

Ja, timeoutAlive ist zu setzen; wenn es Verbesserungsvorschläge für die cref gibt: her damit...

Einige Internals haben sich geändert, z.B. 'protocol' in 'version'

Hmm, da muß ich zugeben, dass ich die Mechanismen in der alten Version irgendwie auch nicht so recht verstanden habe, also was das im einzelnen sollte... Es hat mich ziemlich genervt, dass ich jedesmal nach dem FHEM-Start ein "rotes Fragezeichen" hatte, sobald ich mehrere GW's mit unterschiedlichen MySensors-lib-Ständen hatte. Ursache war, dass das Modul das Attribut "Version" (doppelt) geändert hatte. Da nach der allg. Definition Attribute eigentlich dem User gehören, habe ich das erst mal deaktiviert, bis dato war das keinem aufgefallen , es scheint also eigentlich keinen wirklichen Nutzen zu haben (jedenfalls als Attribut).
Wenn jemand dazu sachdienliche Vorschläge hat, was da wie erforderlich ist, können wir das gerne aufgreifen, im Moment hat das aber m.E. keine hohe Prio.

@alru
Würde statt des Zählers millis nehmen (siehe z.B. das Beispiel hier), aber im Prinzip gibt es diese beiden Varianten (Node machen lassen oder FHEM regelmäßig anfragen lassen, z.B. mit einem at).
Und wie gesagt: auch eine battery-Message resettet den internen Timer für alive/dead.

Das ist aber eigentlich eine Frage, die ggf. hier besser aufgehoben wäre.

Kannst du bei Gelegenheit dann das Thema als "gelöst" kennzeichnen, wenn die kommenden Tage keine Probleme mehr auftauchen?

[alru]

Würde statt des Zählers millis nehmen ...

Die Nodes sollen bei mir die Aufgabe bekommen sich rechtzeitig zu melden (Push an Fhem). Dann spare ich mir die at Befehle in Fhem.
Den millis() habe ich noch nicht eingesetzt. Sieht dafür aber sehr gut aus. Danke für den Tipp.

Kannst du bei Gelegenheit dann das Thema als "gelöst" kennzeichnen, wenn die kommenden Tage keine Probleme mehr auftauchen?

Ja, mach ich zeitnah.

[achim771]

Das mit dem Attribut wars, dann klappt ja doch alles
Ich komm schon durcheinander bei dem ganzen Testen

[Pseudex]

hi.
das Thema ist schon älter aber ich habe  letztens auch Probleme gehabt mit einem Sensor der smartsleep verwendet. Hier schien FHEM in eine Endlosschleife zu geraten und nur mit SIG-KILL konnte ich den FHEM Prozess beenden. Wann genau das passiert ist kann ich nicht sagen. Ich meine, wenn ich zwei oder mehrere male das Senden aus FHEM angestoßen habe.

Mein Server ist ein Asus-PN51 mit 5700U CPU und 64GB RAM. Ressourcen sollten hier nicht das Problem sein.

Ich habe mir den Code 10_MYSENSORS_DEVICE.pm angeschaut und bin mir an zwei Stellen nicht sicher, ob das so gewollt ist.

Code Auswählen Erweitern

sub sendRetainedMessages {
    my $hash = shift // return;
    my $retainedMsg;
    while (ref ($retainedMsg = shift @{$hash->{retainedMessagesForRadioId}->{messages}}) eq 'HASH') {
       sendClientMessage($hash,%$retainedMsg);
    }
    return;
}

Hier hatte ich die Befürchtung, dass die WHILE Schleife nicht beendet wird. Aber der Vergleich auf "HASH" sollte wahrscheinlich sicher sein. Hier wäre wahrscheinlich noch ein limiter (max 10 Durchläufe oder so ähnlich) als Absicherung vorteilhaft.

Code Auswählen Erweitern

sub sendClientMessage {
    my ($hash,%msg) = @_;
    $msg{radioId} = $hash->{radioId};
    my $name = $hash->{NAME};
    $msg{ack} = $hash->{ack} if !defined $msg{ack};
    my $messages = $hash->{retainedMessagesForRadioId}->{messages};
    if (!$hash->{nowSleeping}) {
      sendMessage($hash->{IODev},%msg);
      refreshInternalMySTimer($hash,"Ack") if (($msg{ack} or $hash->{IODev}->{ack}) and $hash->{timeoutAck});
      Log3 ($name,5,"$name is not sleeping, sending message!");
      if ($hash->{nowSleeping}) {
        $hash->{nowSleeping} = 0 ;
        sendRetainedMessages($hash);
      }
      $hash->{retainedMessages}=scalar(@$messages) if (defined $hash->{retainedMessages});
    } else {
      Log3 ($name,5,"$name is sleeping, enqueing message! ");
      #write to queue if node is asleep
      if (!defined $hash->{retainedMessages}) {
        $messages = {messages => [%msg]};
        $hash->{retainedMessages}=1;
        Log3 ($name,5,"$name: No array yet for enqueued messages, building it!");
      } else {
         @$messages = grep {
           $_->{childId} != $msg{childId}
           or $_->{cmd}     != $msg{cmd}
           or $_->{subType} != $msg{subType}
         } @$messages;
         push @$messages,\%msg;
         eval { $hash->{retainedMessages} = scalar(@$messages) }; #might be critical!
      }
    }
    return;
}


sendClientMessage wird von der sub-routine sendRetainedMessages aufgerufen.
In dieser sub-routine kann aber wieder sendClientMessage aufgerufen werden, was zu einer Rekursion führen kann.

Code Auswählen Erweitern

define MYSENSOR_124 MYSENSORS_DEVICE 124
attr MYSENSOR_124 DbLogInclude pv_.*:300:force,batt_.*:300:force,device_.*:300:force,load_.*:300:force
attr MYSENSOR_124 IODev MySensorGw
attr MYSENSOR_124 alias EPEVER Solar
attr MYSENSOR_124 icon sani_solar
attr MYSENSOR_124 mapReading_batt_current 2 current
attr MYSENSOR_124 mapReading_batt_level 2 percentage
attr MYSENSOR_124 mapReading_batt_power 2 power
attr MYSENSOR_124 mapReading_batt_temperature 2 temperature
attr MYSENSOR_124 mapReading_batt_voltage 2 voltage
attr MYSENSOR_124 mapReading_device_load 4 status
attr MYSENSOR_124 mapReading_device_temperature 4 temperature
attr MYSENSOR_124 mapReading_load_current 3 current
attr MYSENSOR_124 mapReading_load_energy 3 energy
attr MYSENSOR_124 mapReading_load_power 3 power
attr MYSENSOR_124 mapReading_load_voltage 3 voltage
attr MYSENSOR_124 mapReading_pv_current 1 current
attr MYSENSOR_124 mapReading_pv_energy 1 energy
attr MYSENSOR_124 mapReading_pv_power 1 power
attr MYSENSOR_124 mapReading_pv_voltage 1 voltage
attr MYSENSOR_124 mode node
attr MYSENSOR_124 room MySensors
attr MYSENSOR_124 setCommands on:device_load:on off:device_load:off
attr MYSENSOR_124 setReading_device_load on,off
attr MYSENSOR_124 stateFormat batt_level
#   DEF        124
#   FUUID      639efa62-f33f-a1b0-14d8-8f1931e14d9fd8c5
#   FVERSION   10_MYSENSORS_DEVICE.pm:0.266690/2022-11-06
#   IODev      MySensorGw
#   NAME       MYSENSOR_124
#   NR         315
#   STATE      67
#   TYPE       MYSENSORS_DEVICE
#   ack        0
#   eventCount 163
#   nowSleeping 1
#   outstandingAck 0
#   preSleep   2500
#   radioId    124
#   repeater   0
#   Helper:
#     DBLOG:
#       batt_current:
#         myDbLog:
#           TIME       1673261427.54225
#           VALUE      0.11
#       batt_level:
#         myDbLog:
#           TIME       1673260862.83766
#           VALUE      67
#       batt_voltage:
#         myDbLog:
#           TIME       1673261119.11482
#           VALUE      25.81
#       pv_current:
#         myDbLog:
#           TIME       1673258928.01454
#           VALUE      0.12
#       pv_power:
#         myDbLog:
#           TIME       1673261225.70554
#           VALUE      4.64
#       pv_voltage:
#         myDbLog:
#           TIME       1673259675.6915
#           VALUE      55.33
#   READINGS:
#     2023-01-09 10:57:14   IODev           MySensorGw
#     2023-01-07 23:29:33   SKETCH_NAME     Solar Charger EPEVER
#     2023-01-07 23:29:33   SKETCH_VERSION  1.1
#     2023-01-09 11:50:27   batt_current    0.11
#     2023-01-09 11:41:02   batt_level      67
#     2023-01-07 23:29:38   batt_temperature 25.00
#     2023-01-09 11:49:27   batt_voltage    25.81
#     2023-01-09 10:47:03   device_load     off
#     2023-01-09 10:45:46   device_temperature 25.52
#     2023-01-08 12:40:38   load_current    0.04
#     2023-01-08 12:31:22   load_energy     1.25
#     2023-01-09 10:45:46   load_power      0.00
#     2023-01-09 10:45:46   load_voltage    0.00
#     2023-01-07 23:29:33   parentId        0
#     2023-01-09 11:08:48   pv_current      0.12
#     2023-01-09 10:23:51   pv_energy       1.66
#     2023-01-09 11:51:13   pv_power        3.09
#     2023-01-09 11:23:18   pv_voltage      27.78
#     2023-01-09 11:51:34   sleepState      asleep
#     2023-01-09 10:47:03   state           off
#   gets:
#   messagesForRadioId:
#   readingMappings:
#     1:
#       17:
#         name       pv_power
#       18:
#         name       pv_energy
#       38:
#         name       pv_voltage
#       39:
#         name       pv_current
#     2:
#       0:
#         name       batt_temperature
#       17:
#         name       batt_power
#       3:
#         name       batt_level
#       38:
#         name       batt_voltage
#       39:
#         name       batt_current
#     3:
#       17:
#         name       load_power
#       18:
#         name       load_energy
#       38:
#         name       load_voltage
#       39:
#         name       load_current
#     4:
#       0:
#         name       device_temperature
#       2:
#         name       device_load
#   retainedMessagesForRadioId:
#     messages:
#   setcommands:
#     off:
#       val        off
#       var        device_load
#     on:
#       val        on
#       var        device_load
#   sets:
#     clear      noArg
#     device_load on,off
#     flash      noArg
#     fwType     
#     off       
#     on         
#     reboot     noArg
#     time       noArg
#
setstate MYSENSOR_124 67
setstate MYSENSOR_124 2023-01-09 10:57:14 IODev MySensorGw
setstate MYSENSOR_124 2023-01-07 23:29:33 SKETCH_NAME Solar Charger EPEVER
setstate MYSENSOR_124 2023-01-07 23:29:33 SKETCH_VERSION 1.1
setstate MYSENSOR_124 2023-01-09 11:50:27 batt_current 0.11
setstate MYSENSOR_124 2023-01-09 11:41:02 batt_level 67
setstate MYSENSOR_124 2023-01-07 23:29:38 batt_temperature 25.00
setstate MYSENSOR_124 2023-01-09 11:49:27 batt_voltage 25.81
setstate MYSENSOR_124 2023-01-09 10:47:03 device_load off
setstate MYSENSOR_124 2023-01-09 10:45:46 device_temperature 25.52
setstate MYSENSOR_124 2023-01-08 12:40:38 load_current 0.04
setstate MYSENSOR_124 2023-01-08 12:31:22 load_energy 1.25
setstate MYSENSOR_124 2023-01-09 10:45:46 load_power 0.00
setstate MYSENSOR_124 2023-01-09 10:45:46 load_voltage 0.00
setstate MYSENSOR_124 2023-01-07 23:29:33 parentId 0
setstate MYSENSOR_124 2023-01-09 11:08:48 pv_current 0.12
setstate MYSENSOR_124 2023-01-09 10:23:51 pv_energy 1.66
setstate MYSENSOR_124 2023-01-09 11:51:13 pv_power 3.09
setstate MYSENSOR_124 2023-01-09 11:23:18 pv_voltage 27.78
setstate MYSENSOR_124 2023-01-09 11:51:34 sleepState asleep
setstate MYSENSOR_124 2023-01-09 10:47:03 state off


das ist die definition vom device


hier ist der Quellcode von meinem Sensor: https://gitea.kaiserflur.de/pseudex/epeversolar/src/commit/71ff4a132b6a4f7563a9158fc5d3c7e9ebb9c2ee/src/main.cpp

[Beta-User]

Hmmm,

ich rätsle jetzt schon eine Weile rum, wann und wieso es zu dem von dir beobachteten Verhalten kommt, und warum das anscheinend nur bei dir so ist - dieser Code ist ja ca. 3 Jahre alt.

Du hast dahingehend recht, dass der wechselseitige Aufruf tendenziell "loop-Gefahr" bedeutet. ABER: Irgendwie werde ich schon aus dem Code nicht schlau, der von dir zitierte Aufruf von sendRetainedMessages() befindet sich an einer Code-Stelle, die m.E. nie angefahren werden kann, weil sendMessage() an dem Internal "nowSleeping" nichts ändert und von daher diese Bedingung nie wahr sein sollte?!? Das eigentliche Problem müßte demnach woanders zu suchen sein.

Vorschlag: Deaktiviere erst mal diese komische if-Konstruktion

Code Auswählen Erweitern

      #if ($hash->{nowSleeping}) {
      #  $hash->{nowSleeping} = 0 ;
      #  sendRetainedMessages($hash);
      #}

Danach sollte der Fehler weiter vorhanden sein (vielleicht machst du ein "save", bevor du FHEM in abschussfähigen Zustand versertzt?)...

Einen Limiter einzubauen widerstrebt mir, weil es an sich sinnvoll ist, die Liste schnellstmöglich abzuarbeiten. Eventuell wäre ein timer-basierter Selbstaufruf sinnvoll, um zum einen das GW nicht zu überfrachten und zum anderen FHEM zu erlauben, zwischendurch was anderes zu machen?

Zum anderen sollte das mit "nowSleeping" eigentlich als "Kennung" ausreichen, um solche Rekursions-Probleme zu vermeiden.
Ansonsten wäre ggf. noch interessant, wie sich die Array-Größe innerhalb der "while"-Schleife entwickelt. Wenn deine These stimmt, dass da was rekursiv passiert, dürfte die nicht abnehmen. Könnte man loggen.

[tmandel]

Moin,

bei mir kommt das Problem auch immer Mal wieder vor.
Ich habe mal ein paar zusätzliche Log Ausgaben eingebaut und konnte zumindest sehen, dass eine Endlosschleife in sendRetainedMessages den ganzen FHEM Prozess zum stehen bringt.

Trotzdem konnte ich das Problem noch nicht mit 100% Sicherheit reproduzieren.

@Pseudex: Besteht das Problem bei dir noch?

Was mir sonst noch so aufgefallen ist.  Du verwendet im Sketch

Code Auswählen Erweitern

#define MY_SMART_SLEEP_WAIT_DURATION_MS 2500Ich habe auch etwas längere Zeiten bei mir dafür vorgesehen. Im FHEM werden die Timer anscheinend mit einer nicht ganz syncronen Formel gesetzt

Code Auswählen Erweitern

my $postsleeptime=($hash->{preSleep} - 200)/1000;

Da im Code zwischendurch

Code Auswählen Erweitern

$hash->{nowSleeping} abgefragt wird, aber mittels Timer zur Laufzeit überschrieben wird, könnte hier die Ursache sein, dass das Problem so schlecht reproduzierbar ist.