Hinweismeldung nach get RSSI

Begonnen von rob, 31 Oktober 2022, 08:25:20

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: rob am 14 November 2022, 18:26:08
Richtige RSSI gibts beim NRF anscheinend nicht: https://forum.mysensors.org/post/87628.
Das sind keine "new news" (jedenfalls nicht für mich). Es macht aber wenig Sinn, die Sinnhaftigkeit eines vorhandenen Features zu diskutieren.

Um das reporting zu aktivieren, muss man - soweit ich mich entsinne - einfach nur ein compiler-flag setzen.
ZitatWeiß nicht, ob sich das wirklich lohnt auszutesten  :-\
Für mich würde es sich lohnen, weil ich dann dieses Thema wieder als abgeschlossen ansehen kann. Es hat schon mal (im Rahmen der bekannten sachlichen Begrenzungen der Aussagekraft) funktioniert, und ich will es nicht kaputt gemacht haben und/oder Probleme bei irgendjemand verursachen, der das in x Monaten ggf. ausprobiert (und mich dann wieder neu eindenken müssen), that's all...
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

rob

Passt. Sollte auch keine Diskussion sein. Dachte, ich weise besser auf meinen Fund hin in der Annahme, dass es ggf. unbekannt sei  :)

KarlHeinz2000

Habe im NRF24 Node #define MY_SIGNAL_REPORT_ENABLED eingefügt

In FHEM kommt weiterhin sofort:
Your transport type seems not to support asking RSSI values

Im Node wird der RSSI request empfangen und ein -256 zurück geschickt. Ist das ein default Wert?
23:00:44.074 -> 827785 TSF:MSG:READ,0-0-71,s=255,c=3,t=29,pt=0,l=1,sg=0:R
23:00:44.074 -> 827791 TSF:SIR:CMD=0,VAL=65280
23:00:44.074 -> 827799 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:-256


Beim RFM69 gehen dabei mehr Infos hin und her:
22:45:50.500 -> 33570 TSF:MSG:READ,0-0-71,s=255,c=3,t=29,pt=0,l=1,sg=0:R
22:45:50.546 -> 33576 TSF:SIR:CMD=0,VAL=65469
22:45:50.735 -> 33789 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:-67
22:45:50.829 -> 33863 TSF:MSG:READ,0-0-71,s=255,c=3,t=29,pt=0,l=2,sg=0:R!
22:45:51.018 -> 34078 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=30,pt=1,l=1,sg=0,ft=0,st=OK:255
22:45:51.018 -> 34086 TSF:SIR:CMD=1,VAL=65462
22:45:51.300 -> 34330 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:-74
22:45:51.348 -> 34402 TSF:MSG:READ,0-0-71,s=255,c=3,t=29,pt=0,l=1,sg=0:S
22:45:51.348 -> 34408 TSF:SIR:CMD=2,VAL=65280
22:45:51.583 -> 34621 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:-256


Beta-User

-256 ist eine Art "kenne ich nicht"-Rückmeldung (so jedenfalls meine Interpretation). Es muss bei nRF aber noch was anderes geben, und die Kommunikation ist länger als bei RFM, nämlich (7 oder) 8 Stufen. Vermutlich gibt es noch einen weiteren (oder anderen) Schalter.

(Die MySensors-lib ist aktuell?)
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

KarlHeinz2000

Kann es sein, dass FHEM bei -256 abbricht?
Ich habe das ganze mit dem MYSController getestet. Dort muss man alle 7 RSSI Werte einzeln abrufen. Das funktioniert auch. Log anbei. FHEM lief parallel mit und hat die Werte alle empfangen und die Readings angelegt und befüllt.
Alles mit NFR24.

Das Log aus dem MYSController:
15.11.2022 20:06:36 TX 71;0;3;0;29;R
15.11.2022 20:06:36 RX 0;255;3;0;9;147902 TSF:MSG:SEND,0-0-71-71,s=0,c=3,t=29,pt=0,l=1,sg=0,ft=0,st=OK:R
15.11.2022 20:06:36 RX 0;255;3;0;9;147924 TSF:MSG:READ,71-71-0,s=255,c=3,t=31,pt=2,l=2,sg=0:-256
15.11.2022 20:06:36 RX 71;255;3;0;31;-256
15.11.2022 20:06:40 TX 71;0;3;0;29;R!
15.11.2022 20:06:40 RX 0;255;3;0;9;151646 TSF:MSG:SEND,0-0-71-71,s=0,c=3,t=29,pt=0,l=2,sg=0,ft=0,st=OK:R!
15.11.2022 20:06:40 RX 0;255;3;0;9;151668 TSF:MSG:READ,71-71-0,s=255,c=3,t=30,pt=1,l=1,sg=0:255
15.11.2022 20:06:40 RX 0;255;3;0;9;151689 TSF:MSG:READ,71-71-0,s=255,c=3,t=31,pt=2,l=2,sg=0:-29
15.11.2022 20:06:40 RX 71;255;3;0;31;-29
15.11.2022 20:06:43 TX 71;0;3;0;29;S
15.11.2022 20:06:43 RX 0;255;3;0;9;154615 TSF:MSG:SEND,0-0-71-71,s=0,c=3,t=29,pt=0,l=1,sg=0,ft=0,st=OK:S
15.11.2022 20:06:43 RX 0;255;3;0;9;154638 TSF:MSG:READ,71-71-0,s=255,c=3,t=31,pt=2,l=2,sg=0:-256
15.11.2022 20:06:43 RX 71;255;3;0;31;-256
15.11.2022 20:06:43 RX 0;255;3;0;9;154677 TSF:MSG:READ,104-104-0,s=255,c=3,t=22,pt=5,l=4,sg=0:5833457
15.11.2022 20:06:43 RX 104;255;3;0;22;5833457
15.11.2022 20:06:46 TX 71;0;3;0;29;S!
15.11.2022 20:06:46 RX 0;255;3;0;9;157949 TSF:MSG:SEND,0-0-71-71,s=0,c=3,t=29,pt=0,l=2,sg=0,ft=0,st=OK:S!
15.11.2022 20:06:46 RX 0;255;3;0;9;157972 TSF:MSG:READ,71-71-0,s=255,c=3,t=30,pt=1,l=1,sg=0:255
15.11.2022 20:06:46 RX 0;255;3;0;9;157992 TSF:MSG:READ,71-71-0,s=255,c=3,t=31,pt=2,l=2,sg=0:-256
15.11.2022 20:06:46 RX 71;255;3;0;31;-256
15.11.2022 20:06:50 TX 71;0;3;0;29;T
15.11.2022 20:06:50 RX 0;255;3;0;9;161296 TSF:MSG:SEND,0-0-71-71,s=0,c=3,t=29,pt=0,l=1,sg=0,ft=0,st=OK:T
15.11.2022 20:06:50 RX 0;255;3;0;9;161318 TSF:MSG:READ,71-71-0,s=255,c=3,t=31,pt=2,l=2,sg=0:-6
15.11.2022 20:06:50 RX 71;255;3;0;31;-6
15.11.2022 20:06:50 RX 0;255;3;0;9;161390 TSF:MSG:READ,71-71-0,s=255,c=3,t=30,pt=1,l=1,sg=0:255
15.11.2022 20:06:50 RX 0;255;3;0;9;161409 TSF:MSG:READ,71-71-0,s=255,c=3,t=31,pt=2,l=2,sg=0:-256
15.11.2022 20:06:50 RX 71;255;3;0;31;-256
15.11.2022 20:06:53 TX 71;0;3;0;29;P
15.11.2022 20:06:53 RX 0;255;3;0;9;164390 TSF:MSG:SEND,0-0-71-71,s=0,c=3,t=29,pt=0,l=1,sg=0,ft=0,st=OK:P
15.11.2022 20:06:53 RX 0;255;3;0;9;164413 TSF:MSG:READ,71-71-0,s=255,c=3,t=31,pt=2,l=2,sg=0:75
15.11.2022 20:06:53 RX 71;255;3;0;31;75
15.11.2022 20:06:53 RX 0;255;3;0;9;164472 TSF:MSG:READ,71-71-0,s=255,c=3,t=31,pt=2,l=2,sg=0:75
15.11.2022 20:06:53 RX 71;255;3;0;31;75
15.11.2022 20:06:53 RX 0;255;3;0;9;164567 TSF:MSG:READ,71-71-0,s=255,c=3,t=31,pt=2,l=2,sg=0:-6
15.11.2022 20:06:53 RX 71;255;3;0;31;-6
15.11.2022 20:06:53 RX 0;255;3;0;9;164661 TSF:MSG:READ,71-71-0,s=255,c=3,t=31,pt=2,l=2,sg=0:-21
15.11.2022 20:06:53 RX 71;255;3;0;31;-21
15.11.2022 20:06:56 TX 71;0;3;0;29;U
15.11.2022 20:06:56 RX 0;255;3;0;9;167417 TSF:MSG:SEND,0-0-71-71,s=0,c=3,t=29,pt=0,l=1,sg=0,ft=0,st=OK:U
15.11.2022 20:06:56 RX 0;255;3;0;9;167440 TSF:MSG:READ,71-71-0,s=255,c=3,t=31,pt=2,l=2,sg=0:-21
15.11.2022 20:06:56 RX 71;255;3;0;31;-21



Die debug Daten des Node:
20:06:36.672 -> 11401 TSF:MSG:READ,0-0-71,s=0,c=3,t=29,pt=0,l=1,sg=0:R
20:06:36.672 -> 11407 TSF:SIR:CMD=0,VAL=65280
20:06:36.672 -> 11413 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:-256
20:06:40.456 -> 15214 TSF:MSG:READ,0-0-71,s=0,c=3,t=29,pt=0,l=2,sg=0:R!
20:06:40.456 -> 15222 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=30,pt=1,l=1,sg=0,ft=0,st=OK:255
20:06:40.456 -> 15230 TSF:SIR:CMD=1,VAL=65507
20:06:40.456 -> 15237 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:-29
20:06:43.391 -> 18241 TSF:MSG:READ,0-0-71,s=0,c=3,t=29,pt=0,l=1,sg=0:S
20:06:43.391 -> 18247 TSF:SIR:CMD=2,VAL=65280
20:06:43.391 -> 18253 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:-256
20:06:46.702 -> 21639 TSF:MSG:READ,0-0-71,s=0,c=3,t=29,pt=0,l=2,sg=0:S!
20:06:46.750 -> 21647 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=30,pt=1,l=1,sg=0,ft=0,st=OK:255
20:06:46.750 -> 21655 TSF:SIR:CMD=3,VAL=65280
20:06:46.750 -> 21659 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:-256
20:06:50.055 -> 25044 TSF:MSG:READ,0-0-71,s=0,c=3,t=29,pt=0,l=1,sg=0:T
20:06:50.102 -> 25051 TSF:SIR:CMD=4,VAL=65530
20:06:50.102 -> 25057 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:-6
20:06:50.149 -> 25135 TSF:MSG:READ,0-0-71,s=255,c=3,t=29,pt=0,l=2,sg=0:S!
20:06:50.149 -> 25145 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=30,pt=1,l=1,sg=0,ft=0,st=OK:255
20:06:50.194 -> 25153 TSF:SIR:CMD=3,VAL=65280
20:06:50.194 -> 25157 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:-256
20:06:53.171 -> 28200 TSF:MSG:READ,0-0-71,s=0,c=3,t=29,pt=0,l=1,sg=0:P
20:06:53.217 -> 28207 TSF:SIR:CMD=5,VAL=75
20:06:53.217 -> 28211 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:75
20:06:53.264 -> 28272 TSF:MSG:READ,0-0-71,s=255,c=3,t=29,pt=0,l=1,sg=0:P
20:06:53.264 -> 28278 TSF:SIR:CMD=5,VAL=75
20:06:53.264 -> 28284 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:75
20:06:53.358 -> 28368 TSF:MSG:READ,0-0-71,s=255,c=3,t=29,pt=0,l=1,sg=0:T
20:06:53.358 -> 28375 TSF:SIR:CMD=4,VAL=65530
20:06:53.358 -> 28381 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:-6
20:06:53.453 -> 28467 TSF:MSG:READ,0-0-71,s=255,c=3,t=29,pt=0,l=1,sg=0:U
20:06:53.453 -> 28473 TSF:SIR:CMD=6,VAL=65515
20:06:53.453 -> 28479 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:-21
20:06:56.246 -> 31285 TSF:MSG:READ,0-0-71,s=0,c=3,t=29,pt=0,l=1,sg=0:U
20:06:56.246 -> 31291 TSF:SIR:CMD=6,VAL=65515
20:06:56.246 -> 31297 TSF:MSG:SEND,71-71-0-0,s=255,c=3,t=31,pt=2,l=2,sg=0,ft=0,st=OK:-21


Mysensor Lib Version ist 2.4.0

---

Habe den gleichen Node mit RFM69 ausgestattet und nur mit FHEM getestet. Dabei wurden auch nicht alle 7 Readings angelegt, sondern nur 2 (oder 3). Das letzte was empfangen wurde war eine -256, danach war Schluss! Logs habe ich leider keine, war gestern am späten Abend. Passt irgendwie zum NRF Verhalten.

Beta-User

Zitat von: KarlHeinz2000 am 15 November 2022, 20:25:26
Kann es sein, dass FHEM bei -256 abbricht?
Ja, das war aber schon immer so, seit es diese RSSI-Abfrage gibt. Getestet/entwickelt damals mit 2.3.2beta (?). Die Abfragen werden als eine Art "asynchroner Schleife" nacheinander automatisiert rausgesendet, solange was (vermeintlich) sinnvolles kommt, also nicht grade die -256.

Im neuen Code ist die Reihenfolge der Abfrage beibehalten, ob es ggf. sinnvoller wäre, das anders anzuordnen, ist eine der noch ungeklärten Fragen. Sie ergibt sich aus #460 (Start mit "R") und dann #1063.

Kommt irgendwann dazwischen eine -256 und die Anfrage kam aus FHEMWEB, gibt es eben ein Dialogfeld, das anzeigt, was bis dahin empfangen wurde (wenn überhaupt was sinnvolles dabei war) bzw. die Meldung ausgibt, dass da was nicht paßt (falscher Transport?).

Bin grade unschlüssig, wie man weiter vorgehen sollte. Vielleicht mal checken, welche Werte der RFM bei vollständiger Abfrage liefert, die nicht "-256" sind? Dann könnte man die nach vorne holen.
Mir ist nur noch unklar, warum es bei nRF gar nicht klappt.
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

KarlHeinz2000

Kann es nicht sinnvoll sein immer alle Werte zu pollen und wenn eine -256 kommt, den Wert durch ein default '-' o.ä. zu ersetzen? Dann hat man immer ein Set aus 7 Readings und nur die, für die Werte geliefert wurden, haben einen Wert ungeich '-'.

Beta-User

Zitat von: KarlHeinz2000 am 17 November 2022, 10:52:55
Kann es nicht sinnvoll sein immer alle Werte zu pollen und wenn eine -256 kommt, den Wert durch ein default '-' o.ä. zu ersetzen? Dann hat man immer ein Set aus 7 Readings und nur die, für die Werte geliefert wurden, haben einen Wert ungeich '-'.
Empfinde ich als Workaround.
Wenn klar ist, dass es gar keine sinnvollen Werte gibt (RS485), dann braucht man auch nicht so zu tun, als gäbe es welche.
Und die Scheife immer komplett durchzulaufen, obwohl es unnötig ist, gefällt mir auch nicht so richtig.
Muss wohl doch nochmal unter's Auto liegen mit dem Thema; hat aber keine (so) hohe Prio (wie die grade anstehenden Arbeiten auf meinem Dach).
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