toggle und readings klappt nicht

Begonnen von grobby, 24 Oktober 2018, 12:53:14

Vorheriges Thema - Nächstes Thema

grobby

Hallo,

also ich grab das Thema mit dem toogle noch mal aus, habe heute wieder ein update gemacht und auch FHEM neugestartet. Leider funktioniert das toogle in Verbindung mit Mysensors nicht. Es wird statt "Aus" zu toogln immer "An" getoogelt. Hat denn noch wer dieses Problem? Version ist nun:

Latest Revision: 17732

File                   Rev   Last Change

fhem.pl                17731 2018-11-11 18:16:45Z rudolfkoenig
96_allowed.pm          17613 2018-10-24 15:37:39Z rudolfkoenig
90_at.pm               17561 2018-10-18 14:45:30Z rudolfkoenig
98_autocreate.pm       17684 2018-11-05 15:52:53Z rudolfkoenig
57_Calendar.pm         17531 2018-10-14 16:19:52Z neubert
00_CUL.pm              17559 2018-10-18 07:45:07Z rudolfkoenig
00_DFPlayerMini.pm     16321 2018-03-03 20:25:45Z kaihs
98_dummy.pm            16965 2018-07-09 07:59:58Z rudolfkoenig
91_eventTypes.pm       14888 2017-08-13 12:07:12Z rudolfkoenig
72_FB_CALLLIST.pm      16433 2018-03-18 08:20:35Z markusbloch
72_FB_CALLMONITOR.pm   16709 2018-05-08 20:14:58Z markusbloch
01_FHEMWEB.pm          17657 2018-11-01 10:34:37Z rudolfkoenig
92_FileLog.pm          17181 2018-08-20 17:23:26Z rudolfkoenig
98_help.pm             15223 2017-10-10 10:14:24Z betateilchen
02_HTTPSRV.pm          16874 2018-06-15 17:18:55Z neubert
49_IPCAM.pm             2626 2013-02-01 19:19:15Z mfr69bs
10_IT.pm               17540 2018-10-15 19:00:42Z bjoernh
00_MYSENSORS.pm        17290 2018-09-06 08:29:45Z Hauswart
10_MYSENSORS_DEVICE.pm 17611 2018-10-24 10:56:06Z Hauswart
91_notify.pm           17225 2018-08-29 12:34:29Z rudolfkoenig
33_readingsGroup.pm    16299 2018-03-01 08:06:55Z justme1968
33_readingsProxy.pm    16299 2018-03-01 08:06:55Z justme1968
14_SD_WS07.pm          16935 2018-07-02 20:22:34Z Sidey
98_statistics.pm       16438 2018-03-18 18:51:57Z tupol
70_STV.pm              12857 2016-12-21 11:59:33Z Zwiebel
99_SUNRISE_EL.pm       16632 2018-04-17 19:00:21Z rudolfkoenig
98_SVG.pm              17457 2018-10-04 12:33:53Z rudolfkoenig
32_SYSSTAT.pm          10567 2016-01-18 21:34:09Z justme1968
98_telnet.pm           17529 2018-10-14 12:57:06Z rudolfkoenig
59_Twilight.pm         16005 2018-01-27 06:05:51Z igami
99_Utils.pm            15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm          15140 2017-09-26 09:20:09Z markusbloch
98_weblink.pm          16293 2018-02-28 21:33:57Z rudolfkoenig

Blocking.pm            17553 2018-10-17 15:56:35Z rudolfkoenig
No Id found for Constants.pm
DevIo.pm               17702 2018-11-07 19:02:28Z rudolfkoenig
FritzBoxUtils.pm       16691 2018-05-05 17:11:26Z rudolfkoenig
GPUtils.pm              6653 2014-10-02 11:59:37Z ntruchsess
HttpUtils.pm           17034 2018-07-27 05:47:13Z rudolfkoenig
No Id found for Message.pm
myUtilsTemplate.pm      7570 2015-01-14 18:31:44Z rudolfkoenig
RTypes.pm              10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm       17100 2018-08-07 07:40:20Z rudolfkoenig
TcpServerUtils.pm      17529 2018-10-14 12:57:06Z rudolfkoenig

fhemweb.js                 17645 2018-10-30 10:27:44Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968



Grobby

grobby

Hallo,

also ich helf mir mal selbst. Ein "request Ack 1" hat bei der Vitrine gefehlt, sonst besteht obiges Problem.

Grobby

Beta-User

Danke für die Rückmeldung.
Wenn es mit ACK klappt, bin ich mir ziemlich sicher, dass die Qualität der Funkverbindung die eigentliche Ursache deiner Probleme ist - die solltest du angehen, das ACK ist nur "second-best". Das gilt vor allem dann, wenn du es wie alru machen willst und die Node als Repeater nutzen.
Just my2ct.
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

alru

Moin,

ich habe übrigens jetzt die geschirmte Version der "NRF24L01+PA+LNA Antenna version" für mein Ethernet - Gateway im Einsatz. Dazu eine Außenantenne, um den hinteren Bereich von meinem Grundstück abzudecken: Und siehe da, jetzt ist die Verbindung zu meinen Node stabil.
Gruß,

Stefan
(Raspi 3B - Stretch / HM-LGW / HomeMatic / MySensors)

grobby

Hallo,

es klappt auch wenn ich ACK am Gateway und am Node (Vitrine) auf 0 setze, also beides ACK 0. Funkverbindung, das node ist ca 3m vom Gateway entfernt, verstehe den Zusammenhang nicht so richtig. Muss den zwangsläufig beiderseits 1 oder 0 sein?

Beta-User

Zitat von: alru am 22 November 2018, 08:44:07
Moin,

ich habe übrigens jetzt die geschirmte Version der "NRF24L01+PA+LNA Antenna version" für mein Ethernet - Gateway im Einsatz. Dazu eine Außenantenne, um den hinteren Bereich von meinem Grundstück abzudecken: Und siehe da, jetzt ist die Verbindung zu meinen Node stabil.
Danke für die Rückmeldung!
Zitat von: grobby am 22 November 2018, 10:45:14
Hallo,

es klappt auch wenn ich ACK am Gateway und am Node (Vitrine) auf 0 setze, also beides ACK 0. Funkverbindung, das node ist ca 3m vom Gateway entfernt, verstehe den Zusammenhang nicht so richtig. Muss den zwangsläufig beiderseits 1 oder 0 sein?
Die Entfernung ist nur ein Faktor unter mehreren. Insbesondere Fake-nRF's haben auch bei geringen Entfernungen uU. schlechte Verbindungen, wobei eine erhebliche Serienstreuung bestehen kann (u.A. deswegen auch der Tip mit den geschirmten, da sind wohl bisher keine fakes im Umlauf).

Was ACK angeht, ist die Einstellung am GW eine Art Vorgabe für alle Nodes, die über dieses GW laufen, letztlich maßgebend ist die Einstellung an der Node (steht da was, gilt das, steht nichts, gilt die GW-Einstellung). Das kann also unterschiedlich sein.
Was aber wichtig ist zu wissen: Das Reading wird bei Nicht-ACK-Messages direkt geändert, die message also so behandelt, als käme sie in jedem Fall an, bei ACK-Messages wird es erst aktualisiert, wenn das ACK kommt.

Hoffe, das halbwegs verständlich erläutert zu haben.

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

grobby

Okay, das war gut erklärt, deshalb hat es auch immer on bzw An getoggelt, weil die Rückmeldung nicht kam das es nun An ist und so fhem nicht weiss das als nächstes off bzw Aus an der Reihe ist.

Mal was anderes, timeoutAck und TimeoutAlive kann man auch zeitgleich setzen? Ist10 sek bei timeoutAck ein guter wert? TimeoutAlive hab ich auf mehrere Stunden gesetzt.

Beta-User

Das mit toggle ist eher so, dass FHEM halt von einem Stand ausgeht, und dann das Gegenteil sendet. Kam der vorige Befehl nicht an, passiert eben nichts...

Die timeOuts funktionieren unabhängig voneinander, was ein für dich "vernünftiger" Wert ist, kann ich aber nicht sagen. Bei guter Verbindung kommt das ACK quasi sofort, ein kurzer timeOut (z.B. 2 sec) kann hier also gut zur Fehlersuche genutzt werden. Wenn es darum geht, notify uä. auf "DEAD" anzusetzen, um massive Probleme per Message zu signalisieren, würde ich eher länger wählen. Vorher würde ich mir aber mal den (Pseudo-) RSSI-Wert mal ansehen, die nRF's kennen das zwar nicht direkt, aber dennoch gibt's da HW-ACKs usw.; da hat sich vermutlich jemand Gedanken gemacht, wie er eine Art Indikator daraus basteln kann...

timeoutAlive (in der Forum-Version, ich hoffe, dass ich bald mal zum finalen Testen komme) kann man gut mit heartbeat- und smartsleep-Messages nutzen (es werden nicht mehr Reading-Aktualisierungen verwendet). Da setze ich die Werte auf den 2-3-fachen Erwartungswert + etwas, also bei smartsleep-nodes mit 3-Minuten-Sendeintervall wären das z.B. 9:05 Minuten, bei einer reinen Relay-Node mit 5-Minütigem heartbeat könnte 10:05 ein guter Wert sein. Ich nutze das aber derzeit nur für eine Anzeige in einer ReadingsGroup.

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

grobby

Hallo, danke für die Erklärung. Im Moment habe ich 5 Batteriebetriebene MotionTemp Nodes im Einsatz. Die Temp wird  nach 3h überprüft, gibt es eine Änderung wird gesendet oder halt geprüft wenn der Motionsensor anspricht über interrupt. Ansonsten schicke ich die Nodes in den normalen sleep. Smartsleep hab ich noch nicht getestet bzw brauche ich das zwingend? Funktioniert denn heartbeat in fhem eigentlich? Jedenfalls habe ich TimeoutAlive auf 11000 gestellt und die Nodes sind damit meistens Alice. Mit dem heartbeat das wäre natürlich sehr interessant, was muss ich dafür andern?

Größe Grobby

Beta-User

Heartbeat funktioniert mit der Version hier aus dem Forum (2.0-API).

Muß irgendwann noch hardware basteln, um das mit dem OTA zu testen und ggf. noch umzubauen, aber der Teil mit heartbeat und smartsleep scheint soweit zu passen.

Du müßtest bei den MotionTemp halt noch ein sendHeartbeat() (?) neben der Info über den aktuellen Temperaturwert mit einbauen, das reine Senden der Werte reicht dann nicht mehr für alive.

Bei Fragen bitte den anderen Thread benutzen, da gibt es auch eine kurze Zusammenstellung, was sich geändert hat (z.B. auch der battery-Reading-Name)...
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