Hinweismeldung nach get RSSI

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

Vorheriges Thema - Nächstes Thema

rob

Moinssen.

Ich habe ein RFM-Gateway @868MHz im Einsatz und passende Node. Wenn ich im Node-Device ein get RSSI ausführe, verwirrt mich diese Hinweismeldung:

Your transport type seems to be RS485, so asking for RSSI values is not possible

Trotzdem werden die zwei RSSI-Werte brav aktualisiert.

Muss ich da etwas anders einstellen? Ich habe neben dem RFM-GW auch noch das RS485-GW im Einsatz - hängt es ggf. damit zusammen?

Ist nicht tragisch/ eilig. Ich hole nicht ständig die RSSI ab. Wundere mich halt :)

Vielen Dank und beste Grüße
rob




define MYSENSOR_1 MYSENSORS_DEVICE 1
attr MYSENSOR_1 IODev MySensorsGW_03
attr MYSENSOR_1 event-min-interval temperature:300
attr MYSENSOR_1 event-on-change-reading volume1,value11,temperature:1,status2,flow1,SKETCH.*
attr MYSENSOR_1 icon measure_water_meter
attr MYSENSOR_1 mapReading_flow1 1 flow
attr MYSENSOR_1 mapReading_id 0 id
attr MYSENSOR_1 mapReading_power2 2 power
attr MYSENSOR_1 mapReading_status2 2 status
attr MYSENSOR_1 mapReading_temperature 0 temperature
attr MYSENSOR_1 mapReading_text1 1 text
attr MYSENSOR_1 mapReading_value11 1 value1
attr MYSENSOR_1 mapReading_volume1 1 volume
attr MYSENSOR_1 mode node
attr MYSENSOR_1 setReading_status2 on,off
attr MYSENSOR_1 stateFormat Stand:volume1 m³ Temp:temperature°C

Beta-User

Eher ein bug oder ein "normaler" timeout. Muss ich mir ansehen, wird etwas dauern.
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

Beta-User

#2
Anbei eine Testversion, mit der wir dem Thema ggf. etwas häherkommen könnten...

Mein Problem: ich kann grade nicht testen, weil ich keine RFM-RSSI-Nodes habe und von daher nicht weiß, was da (wann) kommt. Diese Art Rückmeldung kam allerdings nur an einer Stelle vor. Scheint so, als gäbe es ggf. dann bei den RFM nur zwei abfragbare Werte? $hash->{I_RSSI} müßte dann auf "2" stehen bleiben?

Wenn das so ist, müßte man den "if"-Teil in #1090 noch um die Abfrage aufbohren, ob das Internal nicht auf diesem Wert steht und ggf. in dem "else"-Fall danach das Internal auch löschen, damit alles "sauber" ist.
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

Danke Dir. Hab die Testversion geladen:
FVERSION   10_MYSENSORS_DEVICE.pm:?/2022-11-02 UNSTABLE
Die Meldung kommt aber noch.

Eigentlich sollte "get ... RSSI" imho nur bei Devices angeboten werden, welche auch dazu fähig sind. NRF und RS485 scheiden damit aus - trotzdem kann man das dort loslassen.
Will sagen: würde man z.B. das model via attr einstellen können auf RFM, dann wäre RSSI angebracht, sonst nicht. Spart man sich ggf. die aufwendige Abprüferei und für alle, die das Attribut nicht haben/ nutzen, bliebe es gleich.
Kann aber nicht sagen, was weniger Aufwand macht.

Was meinst Du dazu?

VG
rob

Beta-User

Zitat von: rob am 02 November 2022, 16:59:41
Was meinst Du dazu?
Auf welchem Wert steht das Internal I_RSSI?

Es ist m.E. aufwändiger, ein weiteres Attribut einzupflegen, zu erklären und dann auch auszuwerten, als ggf. zu schauen, ob die RSSI-Abfrage halt bei bestimmten Typen nicht "voll" durchläuft. Das RSSI-Dingens ist übrigens getestet und entwickelt unter nRF24, da gibt es einen auswertbaren "Pseudo-Wert" und insgesamt eben 8 Werte, die nacheinander abgeholt werden. Anscheinend bei RFM nur 2...
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

Steht bei:

...
#     2022-11-02 16:45:20   R_RSSI_from_Parent -94
#     2022-11-02 16:45:20   R_RSSI_to_Parent -87
...


VG
rob

Beta-User

Na ja, gemeint war eigentlich ein Internal, ist aber auch egal...

Anbei eine Testversion, von der ich aber nicht genau weiß, ob die stressfrei durchläuft. Der output erfolgt jetzt an einer etwas anderen Stelle und wird dynamischer zusammengebastelt. Das könnte also auch noch passen, falls es weitere Transport-Layer geben sollte mit wieder anderen "Macken". Kann übrigens auch sein, dass RFM etwas mehr liefert, weil ich grade auch nicht sicher sagen kann, warum die (Abfrage-) Payloads grade in der Reihenfolge abgearbeitet werden, wie sie das grade werden...
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

Hi Beta-User.

Ja, sorry. Hatte anscheinend zuviel gelöscht im Post und die falschen Werte stehen lassen  ::)

OK. Geladen - fehlerfrei. RSSI geholt und es kommt nun die neue Message
RSSI info: ---------------------------- to parent: -84 from parent: -83 SNR to parent: unknown
Aktualisiert wurde fehlerfrei.

Zur Gegenprüfung habe ich auch beim RS485 Node ein get RSSI losgelassen. Ich weiß, ich bin gemein ;)
RSSI info: ---------------------------- to parent: unknown

Ich lasse es zur Stabilitätsprüfung trotzdem jetzt so laufen.

Viele Grüße
rob

Beta-User

Habe eben mal ein update reingeschubst, Danke für's geduldige Testen. Für mein RS485-Netz kommt jetzt die richtige Antwort, und für den Rest hoffentlich auch...
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

Kein Thema, ich hock' ja nur vorm Kasten und schau rein :)
Das Modul war auch die ganze Zeit unauffällig.

Vielen Dank und beste Grüße
rob

Beta-User

Passt das jetzt eigentlich auch bei dir bzw. mit RFM?
Ansonsten wäre es nett, falls ein nRF-User die Möglichkeit hätte zum testen und dazu Rückmeldung geben könnte.
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


RFM schaut gut aus:
RSSI info: ---------------------------- to parent: -84 from parent: -83

RS485 auch
Your transport type seems not to support asking RSSI values

NRF könnte ich auch testen. Aber ich hab nur die ätzenden Klone. Da gab es bisher keine RSSI-Rückmeldung. Aber wenn es nützt, krame ich die gerne heraus.

Vielen Dank für die flinke Lösung :)

VG
rob


Beta-User

(Einmal mehr:) Danke für's Testen!

Zitat von: rob am 13 November 2022, 22:39:22
NRF könnte ich auch testen. Aber ich hab nur die ätzenden Klone. Da gab es bisher keine RSSI-Rückmeldung. Aber wenn es nützt, krame ich die gerne heraus.
Für nRF hatte ich im Hinterkopf, dass man das im Sketch aktivieren muss, vermutlich muss da was im Hintergrund mitgezählt werden. Ob es auch mit (allen?) Klonen klappt, kann ich nicht sicher sagen, ich hatte das auch nur zu Testzwecken überhaupt in Betrieb...

Wäre jedenfalls klasse, wenn es jemand testen würde, da gibt es nämlich einen geringfügig anderen Ablauf am Ende.
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

Ich habe originale NRF am Laufen und könnte das testen. Wobei ich mich bzgl der Änderungen im Sketch erst noch schlau machen muss. Ich schaue mir das in den nächsten Tagen mal an...

rob

Richtige RSSI gibts beim NRF anscheinend nicht: https://forum.mysensors.org/post/87628. Lag also nicht allein an den Klonen  ;)
Weiß nicht, ob sich das wirklich lohnt auszutesten  :-\

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