Frage zu to-HM Adresse und LazyConfig

[harvey]

Hi,
ich habe zwei identische Sensoren (unterschiedliche HMID/Adresse natürlich), beide arbeiten seit einiger Zeit eher problemlos.
Beide auf Basis HM-UNI-Sensor.
Trotzdem reagiert nur einer auf LazyConfig, der andere ignoriert komplett eine automatische Konfigurationsänderung.

Bei Testen ist mir aufgefallen:
der erste Sendevorgang (msgcount =1) hat das Flag 0x04/BCAST, was dann in der Message zu 0x84 wird. Dies gilt für beide Sensoren.
der zweite Sendevorgang (dann ist msgcount % 20 == 2 !!!) hat das Flag 0x22/BIDI+WKMEUP, in der Message also 0xA2.
Dies gilt allerdings nur für den Sensor, bei dem das LazyConfig erfolgreich ist.
Der andere Sensor sendet in der Message dann 0x86, das kommt wohl aus Zeile 174-180 in Message.h.
Ok, nach weiteren Unterschieden gesucht, ich hatte ja eine Ahnung:
Tatsächlich sendet der erfolgreiche Sensor an die 0x00FFFF Adresse, der NICHT erfolgreiche Sensor an die Adresse 0x000000.
Ups?!? Jedenfalls klar, dass das BIDI gelöscht wird und stattdessen das BCAST trotzdem gesetzt wird.

Aber was bedeuten die 0x00FFFF und die 0x000000 Adressen? Beide Senosoren funktionieren ja, also senden seit langer Zeit zuverlässlich Messwerte.

ein Versuch: den nicht erfolgreichen Sensor noch mal angelernt (im HMWEBGUI), NICHT abgelernt, es gibt ja diverse Verknüpfungen, die beim Ablernen ja verloren gehen. Gemacht, Konfig-Button gedrückt, nichts im Posteingang!

Und Schwupps, schon sendet der ehemals nicht erfolgreiche Sensor auch an die 0x00FFFF Adresse. Und jetzt klappt auch LazyConfig!

Ich verstehe nur die to-Adressen nicht so ganz, was bedeuten 0x00FFFF und 0x000000, warum funktionieren beide, was die Messwerte angeht, unterscheiden sich aber bei den Config-Übernahmen (Übrigens, Übernahme der Config mit Butten funktioniert auch bei dem 0x000000 Sensor).

Nur so kleine Erfahrungen und Fragezeichen. Sachlich für mich gelöst, aber ich werde mal nach weiteren Sensoren mit der to-Adresse 0x000000 suchen und eventuell erneut anlernen.

cu
Harvey

[papa]

Ich versuche es mal kurz zu machen. Lazy-Config funktioniert nur, wenn der Sensor ein Ack anfordert. Dass kann er nur machen, wenn er ordentlich angelernt ist und die Adresse der Zentrale kennt.

[harvey]

Lustig ist halt, das der Sensor (ohne Ack) wunderbar seine Messdaten los wurde, also in Homematic angezeigt wurden.
Ein (erneutes) Anlernen hat den Empfang des Messdaten nicht geändert, daher hatte ich bisher keine Ahnung, warum ich den
in seinen Parametern (Antwortmessage Daten Format) unveränderten Sensor denn überhaupt nochmal anlernen sollte.
Und auch nach dem Anlernen war keine Änderung in Homematic sichtbar, die Messdaten kammen (immer noch genauso wie vorher).
Das Gerät war bekannt und hat auch die Messdaten z.B. an iobroker weiter geschoben. Also optisch alles in Ordnung.
Auch eine Config-Änderung wurde korrekt übertragen, allerdings halt nur mit Drücken der Config-Taste.

Es war also nur mit angeschlossenem FTDI (oder Funkanalyser) zu sehen, dass die Message an 0x0000 ging. Und dass nach einem
erneuten Anlernen, welches in der Homematic nicht sichtbares bewirkte nun die to-Adresse zu 0x00ffff wurde.

Das LazyConfig nicht funktionierte wird mir schon klar, aber warum wurde an 0x000000 gesendet?

Ich versuche noch mal zu ergründen, warum der ja früher angelernte Sensor zwar immer noch bekannt (in homematic GUI) war
und Messdaten entgegengenommen wurden, aber die Adresse zu 0x000000 wurde. Der Sensor war ja mal angelernt worden, sonst
würde er ja garnicht auftauchen. Also hat er vermutlich mal an 0x00ffff gesendet und irgendwann damit aufgehört.

Hmmmmm.

Vielen Dank an @papa
cu
Harvey

[jp112sdl]

0x000000 ist die BCAST Adresse.
Egal, ob ein Gerät angelernt ist, senden Wettersensoren ihre Werte immer an 000000.
Das Pairing kommt nur zum Übertragen von Konfigurationsdaten zum Tragen und um das Gerät in deiner Zentrale anzuzeigen.

Du könntest dir einen Sensor mit 5 Zentralen in deiner Nachbarschaft sogar teilen; ihn nacheinander an jeder einzelne Zentrale anlernen -> anschließend werden trotzdem alle Zentralen Werte empfangen und anzeigen.

Nur jede 20. BIDI Message wird von der zuletzt angelernten Zentrale quittiert.

[stan23]

Kann es sein, dass du den "nicht erfolgreichen Sensor" nach dem ursprünglichen Anlernen noch mal lokal resettet hattest, so dass er nicht mehr wusste dass er mit einer Zentrale verknüpft ist?
Soweit ich die Ausführungen oben verstanden habe, sendet er dann nur noch Broadcasts und verlangt kein ACK bei jeder zwanzigsten Nachricht.
Die Zentrale hingegen kennt ihn noch und zeigt seine Werte weiterhin an.

[harvey]

jooooo, das wäre möglich.
Habe mit viel rumgespielt, da mir die Unterschiede nicht bewusst waren .... und nur der eine LazyConfig konnte.
Das ist manchmal ganz nett. wenn so ein Sensor auf dem Dach schwer erreichbar ist.
Und wird ja auch für Direktverknüpfungen benötigt (nicht das LazyConfig selbst, aber die Config-Änderung muss
irgendwann bestätigt werden).

Erstmal vielen Dank an Alle, das hat mir sehr geholfen.

@ jp112sdl
ANGELERNTE (Wetter-)Sensoren senden schon an die 0x00FFFF, also die Zentrale. Jedenfalls sehe ich alle Pakete
im FTDI-Monitor an diese Adresse, sonst würde ja auch ein ACK (und das damit mögliche LazyConfig) nicht funktionieren?!?

Du meintest sicher, dass im Sketch jede 20. Message (counter % 20 == 2) mit BIDI+WKMEUP gesendet wird, die andern mit BCAST.
So jedenfalls hatte ich die Zeilen im Sketch interpretiert. Damit nach Arduino-Reset auch die 2. Msg, so dass ein Config recht zügig übernommen
wird, eben nach dem ersten TransmitUpdInterval. Gültig wird dann allerdings die Änderung zur nächsten (3.) Msg, da ja das LazyConfig
HINTER der Msg abgehandelt wird. Nur ein Gedanke: sollte eventuell sofort nach LazyConfig ein neuer Zyklus (Messung + Msg) erfolgen?

Schönes Wochenende, und glaubt den Sensoren, es IST WARM!
Harvey

[jp112sdl]

@ jp112sdl
ANGELERNTE (Wetter-)Sensoren senden schon an die 0x00FFFF, also die Zentrale. Jedenfalls sehe ich alle Pakete
im FTDI-Monitor an diese Adresse, sonst würde ja auch ein ACK (und das damit mögliche LazyConfig) nicht funktionieren?!?

Dann ist bei dir was falsch.
Meine ANGELERNTEN Wettersensoren senden ALLE Pakete,mit Ausnahme jedes 20., an 000000.
So wie es auch die originalen HM Wettersensoren machen. Da jedoch wirklich alle, weil es original kein LazyConfig bei Wettersensoren gibt

[harvey]

Hi,
hmmmmm, vielleicht gilt das für ORIGINAL Homematic, aber meine UNI-Sensor-Adaptionen sehen genau so aus:

Code: Alles auswählen

AskSin++ V4.1.0 (Jul 19 2019 18:18:36)
ds18x20 count: 2 // meine Modifikation mit 2*Ds18x20
Sensor setup done
Clock SYSCLOCK
Address Space: 32 - 79
CC init1
CC Version: 14
 - ready
iVcc: 2650 // Spannungsmessung an den 2* NiMH-Akkus
Config Changed: List0
ledMode: 0 // By the way, diese Einstellung habe ich gekapert, um das Delta zu inventieren (da es nur ein DeltaT gibt und nicht +DeltaT, -DeltaT
lowBatLimit: 20
transmitDevTryMax: 6
updCycle: 600
altitude: 0
ID: A5A508  Serial: UNISENS008
Temp-1: 247
Temp-2: 247
Tdelta: 0
Bright: 84 // TEMP6000 als CustomData
<- 17 01 84 70 A5A508 00FFFF 00 F7 00 00 00 00 F7 00 00 00 0A 5A 00 54  - 1062 // !!! Hier ist BCAST-Flag (0x04 + 0x80) im 1. msgcounter an 0x00FFFF
...
// 600 Sekunden später
...
Temp-1: 244
Temp-2: 243
Tdelta: -1
Bright: 81
<- 17 02 A2 70 A5A508 00FFFF 00 F4 00 00 00 00 F3 FF FF 00 0A 5A 00 51  - 2056 // !!! Hier BIDI+WKMEUP (0x22 + 0x80) im msgcounter % 20 ==2 ebenfalls an 0x00FFFF
-> 0A 02 81 02 00FFFF A5A508 00  - 2181 // Prima, da kommt ein ACK
waitAck: 01
-> 10 0B A0 01 00FFFF A5A508 00 05 00 00 00 00 00  - 2205 // und das LazyConfig !!! Hurra !!!
<- 0A 0B 80 02 A5A508 00FFFF 00  - 2328
-> 0D 14 A0 01 00FFFF A5A508 00 08 23 13  - 2363
<- 0A 14 80 02 A5A508 00FFFF 00  - 2480
-> 0B 1D A0 01 00FFFF A5A508 00 06  - 2510
Config Changed: List0
ledMode: 0
lowBatLimit: 20
transmitDevTryMax: 6
updCycle: 600
altitude: 19 // das habe ich mal geändert :-)
<- 0A 1D 82 02 A5A508 00FFFF 00  - 2629

ok, es ist leicht modifiziert Uni-Sensor1, wo anstelle von Brightness eine 2. Temperatur und Temp-Delta übertragen wird, mir
ging es um die Spannungsmessung wegen Experimenten mit Solar + LiIon/NiMH Akkus. Und das an der Solaranlage auf dem Dach,
daher zwei Temperaturen für Vor-Rücklauf .... und das Interesse an LazyConfig, wegen Dach, Bright ist nur TEMT6000 als CustomData
für extrem grobe Helligkeitsabschätzung.

@TomMajor:
müssten eventuell ALLE nicht (msgcounter % 20 == 2) messages, also die, die BCAST senden, nicht an 0x000000 gehen?
und NUR die messages, die BIDI+WKMEUP als Flag haben an die Homematiczentrale gehen, damit ACK und LazyConfig funktionieren?
Dann wäre der UNI-SENSOR1 wohl etwas näher an ORIGINAL Homematic-Wettersensoren.

Aber alles ist gut, alles funktioniert, ich will nur in der Diskussion etwas lernen.
ciao
Harvey

[jp112sdl]

müssten eventuell ALLE nicht (msgcounter % 20 == 2) messages, also die, die BCAST senden, nicht an 0x000000 gehen?

Genau, so wäre es richtig.

Bei der Wetterstation mache ich es so:

Code: Alles auswählen

      if (msgcnt % 20 == 1) {
        device().sendMasterEvent(msg);
      } else {
        device().broadcastPeerEvent(msg, *this);
      }

Ich sehe gerade, dass in meinen uralten Beispielen der Temperatursensoren auch nur

Code: Alles auswählen

device().sendPeerEvent(msg, *this);

passiert.
Jedenfalls deckt sich das mit der Meldung hier:viewtopic.php?f=76&t=51161&p=519170#p519160
Ich war der offensichtlich falschen Annahme, dass die AskSin aus einem sendPeerEvent mit gesetztem BCAST Flag automatisch ein broadcastPeerEvent macht.
Oder war das in der Tat mal so?
Alle meine SHT10-Selbstbausensoren senden an 000000... Oder ich hatte es damals nur in meinen eigenen Sketch geändert. Ist schon zu lange her.

[harvey]

Vielen lieben Dank!

der Kreis schließt sich

vielleicht sollte wirklich der von Dir erwartete Umstand (bei gesetztem BCAST tatsächlich an 0x000000 senden)
eingebaut werden.
Die Umkehrung, also bei gesetzter to-Adresse = HMID::broadcast das BIDI zu entfernen und durch BCAST zu ersetzen
ist ja in Zeilen 174++ in Message.h schon drin. Macht ja auch keinen Sinn, auf eine Antwort von HMID::broadcast zu warten

schönes Wochenende!
Harvey