probleme seit dem neuesten update, oder spinnen meine sensoren?

Begonnen von the ratman, 09 April 2017, 17:05:32

Vorheriges Thema - Nächstes Thema

the ratman

hiho,

seit gestern  spinnen meine letzten 2 zwave-geräte - beide "FIBARO System FGMS001 Motion Sensor", die bisher mehr oder weniger gemacht haben, was sie sollten.
nun wird sporadisch nix upgedatet. z.b. bleibt der status auf "open" stehen, oder die temp. bzw. lux werden nicht upgedatet.
einer der sensoren war vorgestern noch auf 75%, einer auf 33% batterie und heute durft ich bei beiden sensoren die batterien wechseln, die wirklich leer waren.
readings wietimeToAck 0.041 2017-04-09 14:59:06 würden ja auch gut aussehen, wäre das reading nicht auch schon wieder 2 stunden alt ...
einzige abhilfe (für ca. 1 stunde) ist ein wakeup per 3-fachen tastendruck am sensor.

da das beide sensoren betrifft, geh ich mal von den neuesten updates aus. hab auch brav get model usw. ausgeführt, wie verlangt.
was nun? was kann ich liefern, damit ihr mir helfen könnt? im log (verbose 5) steht allerdings mal nichts.

btw - ich hab einen der sensoren vollständig rausgeschmissen und neu angelernt, wie ein irrer div. einstellungen gedreht - nix hilft ...
→do↑p!dnʇs↓shit←

krikan

Zitatda das beide sensoren betrifft, geh ich mal von den neuesten updates aus. hab auch brav get model usw. ausgeführt, wie verlangt.
Das beschriebene "Problem" kann nicht durch das bloße update der XML-Config-Dateien oder einen "get <device> model" Abruf entstehen.

Hast Du mal das Dongle stromlos gemacht und den Server neu gestartet?

the ratman

hi, ja, zumindest den raspi runter gefahren. heute nachmittag ..
die letzten stunden rennen beide wieder wie ein glöckerl. könnte also wirklich daran gelegen haben.

und ja, wird wohl so sein, dass es nicht das update war. warscheinlich ists mir da einfach erst aufgefallen.
ich hatte immer wieder bei beiden geräten sporadische ausfälle. meistens über nacht - die gingen dann aber immer wieder nach ein paar stunden von selbst wieder.
was mich halt wirklich nervös macht ist nicht zu wissen, ob nun z.b. die batterie-anzeige "gehangen" hat, oder die wirklich in nur 24 stunden ne halbe batterie gfressen haben.

und ne frage noch: was könnte es gewesen sein, wenn ein stromlos machen hilft?
dann wohl der dongle?
aber wie vermeiden?
→do↑p!dnʇs↓shit←

rudolfkoenig

Zitatund ne frage noch: was könnte es gewesen sein, wenn ein stromlos machen hilft?
Ich habe schon 2-3 Faelle hier gelesen, die darueber berichtet haben, dass Geraetemeldungen nicht ankommen. Ich vermute irgendein Dongle Fehler, weiss aber weder genau woran es liegt, noch wie man es fixt. Als Workaround habe ich ein einmal die Stunde abgesetztes get zu einem der Geraete empfohlen, bisher ohne Rueckmeldung.

Frank_Huber

Hast du evtl nach dem Update den Neustart vergessen?
Das ist mir schon passiert weil ich das update log falsch verstanden habe. Da gab es dann auch unerklärliche Dinge...

the ratman

nönö, ich mach immer brav neustarts nach dem update.

ich werd mal rudolfkoenigs tipp verfolgen.
hab jetzt mal beide geräte auf ein wakeup von 3600 sek. gestellt und setze dann mit nem at je einen get an die geräte ab - mal gucken ...

@rudolfkoenig
wenn  ich hier nichts mehr schreibe, dann funzt das. ansonsten mach ich hier sowieso wieder mimimi *g*
→do↑p!dnʇs↓shit←

the ratman

bis jetzt läuft mit dem at ...
meine 3 werte werden von beiden sensoren upgedatet (neuer zeitrekord *g*), allerdings hat einer der sensoren immer mal wieder einentransmit NO_ACK
→do↑p!dnʇs↓shit←

Mundus

Hallo,

habe ähnliche Probleme https://forum.fhem.de/index.php/topic,69866.0.html. Leider kann ich die Ursache noch nicht eingrenzen. Aufgrund der (evtl. deutlichen) Reduzierung der Batterielaufzeit, habe ich mich noch nicht dafür entschieden, das WakeUp-Intervall hochzusetzen.

Gruß Mundus

tomspatz

In meinem Falle habe ich ein viel stabileres Netz erhalten erst nachdem ich die mit einem at erzeugten Abfragen auf ein DOIF umgestellt habe.
Somit wird mE der Sendstack nicht unnötig vollgeschrieben und die Abfragen gehen "gezielter" raus.
defmod BatterieAbfrageSensoren DOIF (["Fenster:wakeup"] or ["tuer:wakeup"] or ["Schalter:wakeup"] or ["Tuer:wakeup"] or ["Sensor:wakeup"]) (get $DEVICE battery)
attr BatterieAbfrageSensoren alias Batterie Abfrage Sensoren
attr BatterieAbfrageSensoren do always

LG
Tom

the ratman

muß ich mal probieren, weil das at bringt eh nix - wieder die halbe nacht keine daten von den sensoren ... wird halt schwer, so ganz ohne erzeugte events ...
mit zwave hab ich scheints ganz spezielles glück *g* würd mir der umbau auf hm nicht 200,- kosten, wäre zwave eh schon lange weg.
→do↑p!dnʇs↓shit←

krikan

Nutzt irgendwer mit dem Problem auch einen anderen Controller als UZB oder Razberry? Wenn ja, welchen?
UZB oder Razberry-Nutzer: Welche Firmware hat der Controller?

GeZi3560

ZitatIch habe schon 2-3 Faelle hier gelesen, die darueber berichtet haben, dass Geraetemeldungen nicht ankommen. Ich vermute irgendein Dongle Fehler, weiss aber weder genau woran es liegt, noch wie man es fixt. Als Workaround habe ich ein einmal die Stunde abgesetztes get zu einem der Geraete empfohlen, bisher ohne Rueckmeldung.
Ja sorry Rudolf ...   nachdem ich das nun halbstündlich ein get auf ein Device mache habe ich keine Hänger mehr.
Raspberry Pi 4 4GB, MariaDB,2 Cul V3 868 ,1 Cul V3, 433, Zwave-USB, Conbee2, DeConz, MAX WT und Ventile,HM, Somfy, Fibaro, Shellys, Tradfri, Lidl Zigbee

the ratman

lt fhem hab ich zWaveDongle version => Z-Wave 3.99 STATIC_CONTROLLER

is das vielleicht interessant?
zWaveDongle timeouts => 0106640f

→do↑p!dnʇs↓shit←

krikan

Zitat von: the ratman am 11 April 2017, 11:14:36
lt fhem hab ich zWaveDongle version => Z-Wave 3.99 STATIC_CONTROLLER
Sorry, war zu ungenau. Deine Angabe ist das SDK. Die Firmwareversion steht im Reading caps. Das "Vers:5 Rev:0" ist bspw. Firmware 5.0.

Zitatis das vielleicht interessant?
zWaveDongle timeouts => 0106640f
Zunächst einmal nicht. Das wird durch 00_ZWDongle.pm im Standard immer so gesetzt. (Wir vermuten, dass das für SECURITY notwendig ist; wissen aber nichts, das Sigma keine Controllerdoku veröffentlicht.)

Ich suche eigentlich das Schema des Problems. Mit meinem Visions und dem UZB mit neuester Firmware kenne ich es selbst nicht.

the ratman

#14
büddeschön, dein "caps" (sicherheitshalber gleich alles):Vers:5 Rev:2 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET UNKNOWN_28 NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE ZW_GET_PRIORITY_ROUTE ZW_SET_PRIORITY_ROUTE UNKNOWN_98 ZW_SET_WUT_TIMEOUT ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP UNKNOWN_d4 UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH UNKNOWN_f5
wirklich brauchbare (nachvollziehbare) infos kann ich ned wirklich zu liefern.
ich hab zumindest bis jetzt kein muster erkannt. mal geht nur ein sensor nicht, mal beide, mal fangen sie damit gleichzeitig an, muß aber nicht sein. nicht mal, was ausfällt kann man sagen. mal krieg ich gar keine werte, dann wieder nur einen nicht, ... ist zum haare ausraufen. das einzig sichere dabei: im log steht 0, nicht mal warnings.
ein "feeling" dazu (also nix beweisbares, nachvollziehbares) hätte ich: ich hab den eindruck, dass das zwave-zeugs am ehesten bei wenig auslastung zum spinnen anfangt. also z.b. nachts, wenn sich die werte nur selten ändern. je mehr sich tut, je weniger probleme scheints zu geben.

btw - wenn ich veraltet bin ... gibts ein firmwareupdate, dass auch ne geistige linux-nulpe wie ich ohne explodierenden raspi hinbekommt?
→do↑p!dnʇs↓shit←