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ü

Mysensors Gateway Soft WDT reset alle paar Minuten Sende Queue löschen

Begonnen von Stefan_Ne, 26 Juni 2020, 09:53:38

Vorheriges Thema - Nächstes Thema

Stefan_Ne

Hallo zusammen,

ich nutze etliche Mysensors devices und habe jetzt das Problen, dass Fhemfür abgeschaltete Sensoren noch etwas der Sende Queue hat und wenn das zu viel wird gibt es am Gateway einen Soft reset.
Hat jemand eine Lösung wie man die Sende Queue löschen kann. Neustart Fhem und Gateway hilft nicht.

So sieht das Log des Gateway aus.

09:48:44.327 -> 282907 !TSF:MSG:SEND,0-0-53-53,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:0
09:48:52.047 -> 290647 GWT:RFC:C=0,MSG=51;1;1;1;2;0
09:48:53.302 -> 291905 !TSF:MSG:SEND,0-0-51-51,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:0
09:48:57.057 -> 295647 GWT:RFC:C=0,MSG=53;1;1;1;2;0
09:48:58.313 -> 296905 !TSF:MSG:SEND,0-0-53-53,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:0
09:49:12.216 -> 310796 GWT:RFC:C=0,MSG=51;1;1;1;2;0
09:49:13.465 -> 312055 !TSF:MSG:SEND,0-0-51-51,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:0
09:49:13.519 -> 312130 GWT:RFC:C=0,MSG=53;1;1;1;2;0
09:49:14.768 -> 313389 !TSF:MSG:SEND,0-0-53-53,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:0
09:49:15.469 -> 314073 GWT:RFC:C=0,MSG=57;1;1;0;2;0
09:49:16.725 -> 315331 !TSF:MSG:SEND,0-0-57-57,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:0
09:49:16.825 -> 315406 GWT:RFC:C=0,MSG=58;1;1;0;2;0
09:49:18.074 -> 316665 !TSF:MSG:SEND,0-0-58-58,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:0
09:49:18.128 -> 316740 GWT:RFC:C=0,MSG=51;1;1;1;2;0
09:49:19.376 -> 318000 !TSF:MSG:SEND,0-0-51-51,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:0
09:49:28.051 -> 326647 GWT:RFC:C=0,MSG=53;1;1;1;2;0
09:49:29.299 -> 327917 !TSF:MSG:SEND,0-0-53-53,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:0
09:49:36.070 -> 334647 GWT:RFC:C=0,MSG=51;1;1;1;2;0
09:49:37.319 -> 335926 !TSF:MSG:SEND,0-0-51-51,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:0
09:49:45.037 -> 343647 GWT:RFC:C=0,MSG=53;1;1;1;2;0
09:49:46.493 -> 345105 !TSF:MSG:SEND,0-0-53-53,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:0

Beta-User

Vorab: auch hier in diesem Forenbereich ist das Verwenden von Code-Tags ausdrücklich erwünscht...

Zum einen kann man den buffer für zu sendene Messages (nRF-only?) erhöhen, dafür gab es irgendwo einen Parameter im MySensors-Code. Bei GW-Geräten und Repeatern war der aber afaik schon etwas erhöht.

Zum anderen wäre das Gesamt-Setup interessant. Anweisungen an nicht erreichbare Nodes zu senden, dürfte immer ein Problem darstellen, die Frage ist, warum sie nicht erreichbar sind. Du schreibst was von "abgeschaltet".
Falls damit "kurz vom Netz genommen" gemeint ist, wäre die Zuordnung eines anderen (dummy-/als disconnected gesetzten) IO denkbar, evtl. überlege ich mal, ob man ein "attr <node> dummy 1" einführen sollte, um FHEM-seitig verhindern zu können, dass überhaupt was an das GW geht, wenn eine Node bekanntermaßen "weg" ist.
Falls die Node schläft, sollte man hier "smartSleep" einsetzen, dann weiß das MYSENSORS-Modul (ordentliche Funkverbindung vorausgesetzt), wann gesendet werden soll und das GW bekommt solange gar nichts von den zu sendenen Messages mit.

Hoffe, erst mal Lösungsansätze aufgezeigt zu haben.
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

Stefan_Ne

Hallo Beta User,

danke erstmal für deine Hilfe.
Das Gateway ist ein ESP8266 mit RFM69 Version 2.3.1, Hardware ist seit 3 Jahren im Einsatz.
Ich habe den Tag über einiges probiert und auch herausgefunden.
Es ist in der Tat so, wenn zu viele Messages nicht gesendet werden können stürzt das Gateway ab.
Ich habe kurzerhand ein neues gebaut mit der aktuellen ESP Board Lib und Mys Ver 2.3.2.
Es passiert immernoch aber lange nicht mehr so häufig 1mal / 1/2 Stunde. Dann die neue Software auf das alte Gateway und es stürzt alle paar Minuten ab.
Also gehe ich da mal von einem Hardwaredefekt aus.
Noch ein wenig aufgeräumt, alles was nicht wirklich gesendet werden muss reduziert. Sieht jetzt ganz gut aus.
Bei mir gibt es einen kunterbunten Mix von knapp 50 Mysensor Devices an diesem Gateway die sich seit  gerne mitteilen wollen :-)  und wo auch schon mal einer abgeschaltet ist, aslo stromlos.
Devices die kritsch für den Betrieb des Hauses sind, in deutlich kleinerer Anzahl (10Stück) hängen an einem eigenen Gateway und das ist weitaus stabiler.

Weisst Du wieviele Devices ein ESP8266 Gateway veraberiten kann ?

Besten Dank und Grüße
Stefan

Beta-User

Zum Thema ESP-Gateway kann ich nichts sagen, ich nutze für MySenors ausschließlich die USB-Version.

Dazu habe ich aber einen Satz nRF-Hardware als MiLight-Hub, aber das ist eine andere Story - wobei auch da ist mir vor ein paar Monaten mal die Hardware nach mehreren Jahren jetzt hops gegangen - vermutlich auch wegen eines Memory-Wear-outs oder ähnlichem (die WLAN-Credentials waren einfach kaputt bzw. nicht mehr zu speichern).
Sowas steigert mein grundsätzliches Mißtrauen gegenüber diesem Typ Microcontroler...

Andererseits sind mir weder von hier noch aus dem MySensors-Forum Berichte über Probleme mit vielen Nodes bekannt, das sollte also kein grundsätzliches Problem sein, auch 50 und mehr aktive Sensoren zu haben (ggf. dort mal nachhaken?).

Das Problem mit dem (Zwischen-) Speichern sollte doch eigentlich nur auftreten, wenn das GW die Messages nicht vermittelt bekommt. Könnte in Richtung Controller auf WLAN-Probleme hindeuten, in Richtung der anderen Nodes eben auf Funkprobleme. Da müßte man dann die Gesamtlast kennen und weitere Infos haben (echos/Acks? Verschlüsselung, Modemeinstellungen...). Nicht grade mein Spezialgebiet, btw....

Wegen der Option, einzelne Nodes für das (nicht-reaktive) Senden deaktivieren zu können, muß ich mal eine ruhige Minute finden um darüber nachzudenken. Ggf. kommt dann mal eine Testversion, kann aber dauern (Vorschläge/patches nehme ich aber gerne an ;) ...)
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

Stefan_Ne

Hallo Beta-User,

leider kann ich keine seriellen Gateway nutzen, da FHEm auf einer VM läuft. (geht schon aber irgentwie nicht gut und uncool)

Zu früh gefreut ES ist wieder da. Ein paar Stunden Ruhe vor dem Sturm.
Ich glaube kaum das es ein Problem von FHEM ist.
Das lief lange ohne Probeme, wirklich komisch.
Irgendein Device wird das verursachen.

Lösung ... nicht schön und vor Allem nicht nachhaltig.

Der Umzug der Devices Eins nach dem Anderen auf ein neues Gate mit neuer RF ID ... wird helfen, ist aber eine ganz unglückliche Lösung..

Da kommt leider wieder der Punkt wo Smart Home echt Schei..e ist aber ohne ist es halt nicht anders.

So sieht das Log der Gateway aus


23:28:26.427 -> 47243 TSF:MSG:READ,59-59-0,s=97,c=1,t=47,pt=2,l=2,sg=0:-62
23:28:34.556 -> 55377 GWT:TSA:C=0,CONNECTED
23:28:34.605 -> 55427 GWT:RFC:C=0,MSG=0;0;3;0;2;
23:29:06.330 -> 87131 TSF:MSG:READ,56-56-0,s=99,c=1,t=2,pt=1,l=1,sg=0:1
23:29:06.377 -> 87215 TSF:MSG:READ,56-56-0,s=97,c=1,t=47,pt=1,l=1,sg=0:147
23:29:07.533 -> 88331 TSF:MSG:READ,56-56-0,s=98,c=1,t=47,pt=1,l=1,sg=0:185
23:29:13.186 -> 93993 GWT:RFC:C=0,MSG=53;1;1;1;2;1
23:29:15.261 ->
23:29:15.261 -> Soft WDT reset
23:29:15.261 ->
23:29:15.261 -> >>>stack>>>
23:29:15.307 ->
23:29:15.307 -> ctx: cont
23:29:15.307 -> sp: 3ffffc80 end: 3fffffc0 offset: 01a0


Beta-User

Zitat von: Stefan_Ne am 26 Juni 2020, 23:57:36
leider kann ich keine seriellen Gateway nutzen, da FHEm auf einer VM läuft. (geht schon aber irgentwie nicht gut und uncool)
Uncool ist besser wie unfunktional... Kabel sind besonders uncool, aber meine Hauptinstallation@MySensors ist ein RS485-Netz ;D , und die Kabel sind im Keller teils aufputz verlegt (wie andere dort auch). Als Kompromiss: Wie wäre es mit einem LAN-GW?
Wie angedeutet, der ESP8266 ist mMn. ein schlecht designtes Stück Hardware. Dazu kommt (aber unabhängig davon): sobald man viel WLAN-Genönse hat, ist auch ein normaler Consumer-AP gerne mal überfordert; speziell die Kombi FritzBox+ESP8266 ist "berüchtigt", ohne dass jemand die wirkliche Ursache dafür kennt...

ZitatZu früh gefreut ES ist wieder da. Ein paar Stunden Ruhe vor dem Sturm.
Ich glaube kaum das es ein Problem von FHEM ist.
Schade, aber ich teile deinen Glauben, aber sicher bin ich auch nicht; manchmal ist es eine Kombination von verschiedenen Faktoren.

Aber das hier klingt irgendwie nach einem "babbling idiot".

Da du aber der erste bist, der sowas berichtet, würde ich es - wie gesagt - schlicht mal @MySenors.org posten und nachfragen, ob jemand ähnliche Erfahrungen hat; so kannst du es ggf. schneller eingrenzen?

Ansonsten nochmal die (dringende!) Bitte: Nutze Code-Tags für alles, was "Maschinentext" ist, also auch solche Logauszüge. Ist viel einfacher zu lesen und es wird hier als schlechter Stil empfunden, wenn man es nicht macht...
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

gandi1791

Servus.

Ich nutze auch ESP8266 als Gateway. Die meisten Nodes liefern nur Daten. Vereinzelt habe ich aber auch Nodes, die Daten empfangen und auch manchmal - beabsichtigt und unbeabsichtigt - offline sind.
Probleme in dieser Frequenz habe ich dazu nicht, dennoch habe ich von Zeit zu Zeit komische Phänomene.
Von daher würde mich interessieren, wie ich feststellen kann, ob noch was in der Sendequeue des GW ist.

Vielen Dank und Gruß
Andi
fhem auf proxmox container
minicul>ESP-01>868>MAX!; minicul>ESP-01>433>SignalDuino>RSL/Jaro/IT
ESP-01>HM-MOD-RPI-PCB>HM
MySensorsGW>NodeMCU>Sensoren, Aktoren, div.
Broadlink RM Pro+ >433 Steckdosen, IR TV/Receiver; Hue, Alexa Echo Plus, div.Dot 2/3/4;DVB-T Stick>mqtt>TFA 30.3180