[gelöst] Weekprofile werden nicht übertragen - Credits-Probleme

[thburkhart]

inzwischen ist es mir nach endlosem Reseten von WT und FK gelungen eine weiteren Raum in Gang zu bringen.

eine Frage noch zu assotiate fer FKs:


Probably associated with
EcoTaster_1_notify_auto
active   
notify
EcoTaster_1_notify_eco
active   
notify
EcoTaster_2_notify_auto
active   
notify

dies ist aus dem DeviceOverview des WTs. Man sieht, das die Ecotaster "Probably associated" sind. Der Fensterkontakt erscheint hier nicht. Kann er trotzdem sauber assoziert sein ?

[Wzut]

Du wirfst hier zwei Dinge zusammen die ähnlich klingen aber rein gar nichts gemeinsam haben.
Probably associated with ist in FHEMWEB ein eigener Block den fast jedes Device haben kann und nur anzeigt das dies in Beziehung zu einem anderen steht , in deinem Fall ein notify.
Könnte aber genau so gut ein at, SVG oder oder da stehen.

Thema peering von Max Geräten ( also das set assoiciate xy ) , habe ich schon mehrfach geschrieben das es keine Möglichkeit gibt das irgendwie aus einem Device wieder auszulesen. Wenn du meine Beta benutzt hast du aber zwei neue Readings die dir anzeigen mit wem das Device spricht.

[thburkhart]

Hallo WZut,
mit Begin des Heizens komme ich wieder auf das Thema "Wer spricht mit wem?" und "wer ist der Chef?" zurück.
Inzwischen gibt es ja dankenswerterweise die peers-Reading.

Im Wohnzimmer sie WT-Reading diesbezüglich prima aus:

Code Auswählen Erweitern

Readings
PairedTo 123456 2020-09-25 13:50:21
RSSI -56.5 2020-09-27 17:18:16
SerialNr KEQ0808782 2020-09-25 13:50:21
battery ok 2020-09-27 16:54:16
batteryState ok 2020-09-27 16:54:16
desiredTemperature 21.0 2020-09-27 17:18:16
deviation 0.7 2020-09-27 17:18:16
displayActualTemperature 1 2020-09-27 16:54:16
error Invalid command/argument 81580127 2020-09-25 13:55:03
firmware 1.0 2020-09-25 13:50:21
gateway 1 2020-09-27 16:54:16
groupid 0 2020-09-25 13:51:22
lastTimeSync 2020-09-27 15:28:55 2020-09-27 15:28:55
lastcmd desiredTemperature auto/boost 2020-09-26 06:28:15
mode auto 2020-09-27 16:54:16
msgcnt 23 2020-09-27 15:28:55
panel unlocked 2020-09-27 16:54:16
peerIDs 000000,08a373,08a8f2,16edc5 2020-09-27 17:18:16
peerList Broadcast,Wohnzimmer_O,Wohnzimmer_SO,Wohnzimmer_SW 2020-09-27 17:18:16
rferror 0 2020-09-27 16:54:16
state 21.0°C 2020-09-27 17:18:16
temperature 21.7 2020-09-27 17:18:16
testresult 255 2020-09-25 13:50:2

Es funktioniert auch prima, dass die HTs das tun, was der WT ihnen mitteilt.


Anders sieht es im Bad aus: Reading des WTs:

Code Auswählen Erweitern

Readings
RSSI -77.5 2020-09-27 17:25:25
battery ok 2020-09-27 16:28:56
batteryState ok 2020-09-27 16:28:56
desiredTemperature 22.0 2020-09-27 17:25:25
deviation 1.0 2020-09-27 17:25:25
displayActualTemperature 1 2020-09-27 16:28:56
gateway 1 2020-09-27 16:28:56
lastTimeSync 2020-09-27 16:28:55 2020-09-27 16:28:55
lastcmd set_associate Bad_HT 2020-09-26 11:06:10
mode auto 2020-09-27 16:28:56
msgcnt 8 2020-09-27 16:28:55
panel unlocked 2020-09-27 16:28:56
peerIDs 000000 2020-09-27 17:25:25
peerList Broadcast 2020-09-27 17:25:25
rferror 0 2020-09-27 16:28:56
state 22.0°C 2020-09-27 17:25:25
temperature 23.0 2020-09-27 17:25:25

Zwar reagiert der WT auf den einzigen FK und gibt alles an den HT weiter. In den Readings erschein unter peerList eben nur "Brodcast".

Wie könnte ich diesen (Schönheits)fehler beseitigen ? Könnte das an der relativ weiten Entfernung vom CUL liegen?

Beste Grüße

Thomas

[Wzut]

a. warum sind deine lists so fürchterlich formatiert ? (Zeilenumbruch nach jedem Wert) , die list Ausgabe in FHEMWEB formatiert die doch so schön (Datum/Zeit am Anfang) ich war mal so frei deine zu editieren damit sie halbwegs lesbar werden.

b. wieso hat das Wohnzimmer WT die groupid 0 und beim Bad fehlt sie ganz ?

c. Vermutung : Das Wohnzimmer WT hat in Wahrheit eine "echte" groupid ( !=0 ) und kann daher an jedes Mitglied seiner Gruppe ein Unicast Telegramm schicken. Die "verlorene" groupid ist so ein Grund warum ich immer sage "Leute nutzt die interne Backup Funktion" , denn interne Werte lassen sich bei MAX Geräten nicht zurücklesen ! Schau mal bei den anderen Partnern der Gruppe ob die noch die echte groupid haben und setze sie beim WT neu.

Beim Bad fehl sie komplett, ich kann jetzt wieder nur raten : sie fehlt auch intern daher kann das WT sie nicht mit Unicasts abarbeiten und muss auf Broadcast ausweichen.

Die ELV MAX Software organisiert die Geräte in Räumen, dieser Raum wird als Nummer intern in den Geräten geführt. Leider hat sich vor Jahren der Autor der MAX Module dafür entschieden diese Nummer groupid zu nennen , roomnumber wäre die bessere Wahl gewesen.
Anyway, alles was zusammen arbeiten soll (HT/WT/FK) muss zwingend die gleiche groupid haben ( am besten ungleich 0 ) und muss in eurem System einzigartig sein.     

[thburkhart]

Asche auf mein Haupt

.. muss als nun mal die groupID aller Geräte feststellen

geht das geräteübergreifend mit deinem List-Befehl?


Ich habe der groupId nie bedeutung bei gemessen.
Ich habe nun alle ensprechend des Raumes gesetzt. Bei den FKs wurde das nicht übernommen.

Shutdown gemacht.

Pendelt sich das nun alles ein ?
Kann ich davon ausgehen, dass die peerlist exact den assozierten Geräten enspricht?

Beste Grüße

Thomas

[thburkhart]

kann es sein, dass die Fensterkontakte zwar korrekt ihren Status auf/zu anzeigen, jedoch in den peerlisten nicht aufttauchen?


peerIDs 000000,08a373,08a8f2,16edc5 2020-09-28 16:30:23
peerList Broadcast,Wohnzimmer_O,Wohnzimmer_SO,Wohnzimmer_SW 2020-09-28 16:30:23

Jedenfals stimmt die Fensterkontakt erkennung nicht:
Nach Öffnen von FK1 sprangen der WT alle 3 HTs auf 12.0
Nachöffner von FK2 die WS auf 17,0 16,5 18,5 nur der WT auf 12.0
Nach schließen beider FKs haben wir folgendes wirre Bild:

Wohnzimmer FK1 Fenster Ost closed
Wohnzimmer FK2 Fenstertüre closed

Wohnzimmer Ost 21.4°C 12.0
Wohnzimmer SO 21.4°C 12.0
Wohnzimmer SW 21.4°C 12.0
WOHNZIMMER WT 21.4°C  12.0

im Log wiederholt sich dies:

Code Auswählen Erweitern

2020.09.28 16:41:20 4: CUL_Parse: CUL_0 Z0C2204420CCDEC0B12B70015CF19 -61.5
2020.09.28 16:41:20 5: CUL_0: dispatch Z0C2204420CCDEC0B12B70015CF
2020.09.28 16:41:20 5: MaxSystem, IODev CUL_0, len 12, msgcnt 22, msgflag 04, msgType WallThermostatControl, src 0ccdec, dst 0b12b7, group 0, payload 15CF, rssi -61.5
2020.09.28 16:41:20 5: MaxSystem: dispatch MAX,0,WallThermostatControl,0ccdec,15CF
2020.09.28 16:41:20 5: MAX_Parse, MAX,0,WallThermostatControl,0ccdec,15CF
2020.09.28 16:41:20 5: THOMAS_WT, desiredTemperature : 10.5, temperature : 20.7
2020.09.28 16:41:21 5: CUL/RAW: /Z0E2202020B12B70CCDEC000118001508

2020.09.28 16:41:21 4: CUL_Parse: CUL_0 Z0E2202020B12B70CCDEC000118001508 -70
2020.09.28 16:41:21 5: CUL_0: dispatch Z0E2202020B12B70CCDEC0001180015
2020.09.28 16:41:21 5: MaxSystem, IODev CUL_0, len 14, msgcnt 22, msgflag 02, msgType Ack, src 0b12b7, dst 0ccdec, group 0, payload 01180015, rssi -70
2020.09.28 16:41:21 5: MaxSystem: dispatch MAX,0,Ack,0b12b7,01180015
2020.09.28 16:41:21 5: MAX_Parse, MAX,0,Ack,0b12b7,01180015
2020.09.28 16:41:21 5: MAX_Parse, MAX2,0,ThermostatState,0b12b7,180015
2020.09.28 16:41:22 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:41:22 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:41:25 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:41:25 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:41:28 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:41:28 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:41:31 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:41:31 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:41:34 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:41:34 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:41:37 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:41:37 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:41:40 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:41:40 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:41:43 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:41:43 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:41:46 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:41:46 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:41:49 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:41:49 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:41:52 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:41:52 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:41:55 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:41:55 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:41:57 5: CUL/RAW: /Z0C4D04420CCD8716EDC50018D61D

2020.09.28 16:41:57 4: CUL_Parse: CUL_0 Z0C4D04420CCD8716EDC50018D61D -59.5
2020.09.28 16:41:57 5: CUL_0: dispatch Z0C4D04420CCD8716EDC50018D6
2020.09.28 16:41:57 5: MaxSystem, IODev CUL_0, len 12, msgcnt 4D, msgflag 04, msgType WallThermostatControl, src 0ccd87, dst 16edc5, group 0, payload 18D6, rssi -59.5
2020.09.28 16:41:57 5: MaxSystem: dispatch MAX,0,WallThermostatControl,0ccd87,18D6
2020.09.28 16:41:57 5: MAX_Parse, MAX,0,WallThermostatControl,0ccd87,18D6
2020.09.28 16:41:57 5: Wohnzimmer_WT, desiredTemperature : 12, temperature : 21.4
2020.09.28 16:41:58 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:41:58 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:42:01 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:42:01 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:42:04 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:42:04 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:42:07 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:42:07 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists
2020.09.28 16:42:10 5: MaxSystem, Send Queue 2 packets in queue
2020.09.28 16:42:10 4: MaxSystem, Send Queue packet for ShutterContact WOHNEN_F1 exists

Wie kriege ich den FK2 ans Lafen?

Ich bitte um Hilfe.

Beste Grüße

Thomas

[Wzut]

mal ganz langsam und der Reihe nach :
Bei den groupid für FKs bin ich mir jetzt selbst unsicher, ich muß da unbedingt wiedermal die Orgnal Cube Wolke aufbauen und nachschauen.
Es ist gut möglich das man bei ihnen die nicht setzen kann bzw. nicht einfach mal eben so da der FK genau wie beim Peering erst geweckt werden muß.
Da du deine FKs nicht aufgeweckt hast stehen nun ewig diese beiden Nachrichten in deiner Sendqeue , bitte löschen damit es wieder Ruhe gibt.

Du blähst deine Logs unnötig auf , bitte am CUL Device und die FK/HT/WT maximal verbose 3 setzen.
Das CUL_MAX kann auf 5 gesetzt werden, da fallen die wichtigen Infos an.

kann es sein, dass die Fensterkontakte zwar korrekt ihren Status auf/zu anzeigen, jedoch in den peerlisten nicht aufttauchen?

peerIDs 000000,08a373,08a8f2,16edc5 2020-09-28 16:30:23
peerList Broadcast,Wohnzimmer_O,Wohnzimmer_SO,Wohnzimmer_SW 2020-09-28 16:30:23

Was sollen mir nun die zwei Zeilen sagen ? Was stimmt da nicht ? In welchen peerlisten sollen denn FKs auftauchen ?
Kein Gerät schickt etwas an einen FK, was denn auch ? Da  die Listen nach Telegrammzielen aufgebaut werden darf im Normalfall keiner eine FK Adresse in seiner Liste haben. Um deinen Fall mit so vielen Geräten im Wohnzimmer ordenlich aufzulösen bleibt dir nur :
a. Normalzustand herstellen
b. ein FK auf -> in Log schauen was er zu wem geschickt hat und wer eine Antwort (ACK) darauf gib , warten , nachauen ob und wie die vier Ziele ihren Status melden, noch etwas warten
c. das selbe Spiel wieder mit dem zweiten FK
 
Tabelle anlegen wer zu wem und was

d. wieder ein FK schliessen und sonst wie b.
e. zweiten FK schliessen und b.
auch das wieder in die Tabelle eintragen.

jetzt solltest du wieder deinen Normalzustand haben und ein schönes langes Logfile.
Wenn nein, schauen wo die Abweichungen sind. 

Aber generell : Bei so einer großen Gruppe würde ich mir genau überlegen wen du mit wem peerst.
Wäre es meine : alle FK/HT mit dem WT , aber keine HT <-> FK peerings
Wäre natürlich interessant zu wissen was die Orginal Software da machen würde, ich kann es jetzt aber leider mangels Test Geräten nicht nachstellen.

[thburkhart]

ok, verstehe ich richtig?  in der peerliste stehen die Geräte, die innerhalb einer Gruppe zuhören und empfangen; also keine FKs. Ich war der irrigen Meinung, dass dort alle Geräte stehen, die untereinander austauschen
In meinen System habe und hatte ich alle betreffenden HTs mit dem WT assoziert und die FK ebenfalls mit dem WT. Mehr nicht.
Ich meinte, dass sich dies in diesen besagten beiden Zeilen bestätigt:

peerIDs 000000,08a373,08a8f2,16edc5 2020-09-28 16:30:23
peerList Broadcast,Wohnzimmer_O,Wohnzimmer_SO,Wohnzimmer_SW 2020-09-28 16:30:23

Lt. oben tauchen hier die FTs nicht.

Nun habe ich versucht nach deiner Anleitung, herauszufinden, was die FKs veranstalten:

FK2 geöffnet ergibt im
Eventmonitor:

Code Auswählen Erweitern

2020-09-29 09:31:25 CUL_MAX MaxSystem CUL_0:ok
2020-09-29 09:31:25 MAX WOHNEN_F2 opened
2020-09-29 09:31:25 MAX WOHNEN_F2 RSSI: -71.5
2020-09-29 09:31:25 MAX WOHNEN_F2 battery: ok
2020-09-29 09:31:25 MAX WOHNEN_F2 batteryState: ok
2020-09-29 09:31:25 MAX WOHNEN_F2 rferror: 0
2020-09-29 09:31:25 MAX WOHNEN_F2 onoff: 1
2020-09-29 09:31:25 CUL_MAX MaxSystem CUL_0:ok
2020-09-29 09:31:30 LaCrosse TX29DTH_06 T: 11.9 H: 81.3
2020-09-29 09:31:32 CUL_MAX MaxSystem CUL_0:ok
2020-09-29 09:31:32 MAX WOHNEN_F2 closed
2020-09-29 09:31:32 MAX WOHNEN_F2 RSSI: -73
2020-09-29 09:31:32 MAX WOHNEN_F2 battery: ok
2020-09-29 09:31:32 MAX WOHNEN_F2 batteryState: ok
2020-09-29 09:31:32 MAX WOHNEN_F2 rferror: 0
2020-09-29 09:31:32 MAX WOHNEN_F2 onoff: 0
2020-09-29 09:31:32 MAX WOHNEN_F2 windowOpen: 0
2020-09-29 09:31:32 CUL_MAX MaxSystem CUL_0:ok


und im Log:

Code Auswählen Erweitern

2020.09.29 09:31:25 5: MaxSystem: dispatch MAX,1,ShutterContactState,0cb39d,12
2020.09.29 09:31:25 5: MAX_Parse, MAX,1,ShutterContactState,0cb39d,12
2020.09.29 09:31:25 5: WOHNEN_F2, bat 0, rferror 0, isopen 1, unkbits 0
2020.09.29 09:31:32 5: MaxSystem, IODev CUL_0, len 11, msgcnt 0A, msgflag 00, msgType Ack, src 123456, dst 0cb39d, group 0, payload 00, rssi -74
2020.09.29 09:31:32 4: MaxSystem, packet from ourselves or a other CUL [123456 / 0], - ignoring !
2020.09.29 09:31:32 5: MaxSystem, IODev CUL_0, len 11, msgcnt 0A, msgflag 06, msgType ShutterContactState, src 0cb39d, dst 123456, group 0, payload 10, rssi -73
2020.09.29 09:31:32 5: MaxSystem: dispatch MAX,1,ShutterContactState,0cb39d,10
2020.09.29 09:31:32 5: MAX_Parse, MAX,1,ShutterContactState,0cb39d,10
2020.09.29 09:31:32 5: WOHNEN_F2, bat 0, rferror 0, isopen 0, unkbits 0
2020.09.29 09:32:19 5: MaxSystem, IODev CUL_0, len 12, msgcnt AE, msgflag 04, msgType WallThermostatControl, src 0ccd87, dst 16edc5, group 0, payload 24D4, rssi -59.5
2020.09.29 09:32:19 5: MaxSystem: dispatch MAX,0,WallThermostatControl,0ccd87,24D4
2020.09.29 09:32:19 5: MAX_Parse, MAX,0,WallThermostatControl,0ccd87,24D4
2020.09.29 09:32:19 5: Wohnzimmer_WT, desiredTemperature : 18, temperature : 21.2
2020.09.29 09:32:23 5: MaxSystem, IODev CUL_0, len 12, msgcnt 83, msgflag 04, msgType WallThermostatControl, src 0ccdec, dst 0b12b7, group 0, payload 2ACE, rssi -57.5
2020.09.29 09:32:23 5: MaxSystem: dispatch MAX,0,WallThermostatControl,0ccdec,2ACE
2020.09.29 09:32:23 5: MAX_Parse, MAX,0,WallThermostatControl,0ccdec,2ACE
2020.09.29 09:32:23 5: THOMAS_WT, desiredTemperature : 21, temperature : 20.6
2020.09.29 09:32:23 5: MaxSystem, IODev CUL_0, len 14, msgcnt 83, msgflag 02, msgType Ack, src 0b12b7, dst 0ccdec, group 0, payload 0118032A, rssi -63.5
2020.09.29 09:32:23 4: MaxSystem, ACK from THOMAS_HT1 to THOMAS_WT
2020.09.29 09:32:23 5: MaxSystem: dispatch MAX,0,Ack,0b12b7,0118032A
2020.09.29 09:32:23 5: MAX_Parse, MAX,0,Ack,0b12b7,0118032A
2020.09.29 09:32:23 5: MAX_Parse, MAX2,0,ThermostatState,0b12b7,18032A

jetzt komme ich aber bzgl. FK2 nicht so richtig weiter

Beste Grüße

Thomas

[Wzut]

dein Log ist wieder mal verdammt kurz und der Anfang als du das Fenster aufgemacht hast fehlt.
Das Fenster zu um 9:31:32 ist vollständig , aber schau dir mal die Zeile genau an

Code Auswählen Erweitern

2020.09.29 09:31:32 5: MaxSystem, IODev CUL_0, len 11, msgcnt 0A, msgflag 06, msgType ShutterContactState, src 0cb39d, dst 123456
was fällt dir da auf ?


Was ist das Problem mit FK2 ? Von dem steht nichts im Log.

[thburkhart]

ich bitte als  absoluter Laie um Nachsicht

ich habe FK2 betätigt und dann das Log und den Eventmonitor betrachtet:

bei

2020.09.29 09:31:32 5: MaxSystem, IODev CUL_0, len 11, msgcnt 0A, msgflag 06, msgType ShutterContactState, src 0cb39d, dst 123456

fällt mir als Laie wenig auf; nur das, dass Adresse 0cb39d (das ist der FK2!) eine Nachricht an 123456 gesandt hat. Woher weiß nun der Wohnzimmer WT, dass er samt seinen HTs auf 12 Grad runter soll? und eben nur er..

[Wzut]

leichte Frage , einfache Antwort : gar nicht.
Dein FK2 schickt seinen Status lediglich an 123456 - ich gehe davon aus das ist dein CUL_MAX Device also FHEM. Dem WT wird das relativ wurscht sein da es nicht direkt für ihn ist.
Wenn das WT mit dem FK gepeered ist dann hört das WT auf Nachrichten die direkt an ihn gehen und gleichzeitig vom Absender 0cb39d sind und er hört auf Nachrichten die als Ziel 000000 (Broadcast) haben und auch von 0cb39d  kommen.
Einfach gesagt , das associate (peering) von Device A mit Device B bewirkt lediglich das A Nachrichten von B annimmt und mit ACK quittiert.
Bsp A sei ein HT , B ein WT. Nun schickt das HT regelmäßig seinen Status an das WT, aber das WT kann dem HT nicht sagen das sich sein Soll ändern soll.
Dazu ist das zusätzliche associate B mit A notwendig, dann hört das HT auf Nachrichten vom WT.
Du musst dir unbedingt diese Zusammenhänge und Abgänigkeiten klar machen wenn du in deiner komplexen Umgebung auf Fehlersuche gehen willst oder mal Logs so einfach wie die Bildzeitung lesen möchtest. 

[thburkhart]

ich verstehe gaanz langsam ..

bei mir ist es also wohl so, dass der WT mit seinen HTs beidseitig assoziiert ist; also Nachrichten gezielt senden und quittieren können.
Diese set associate habe ich auch entsprechend durchgeführt. richtig?

Was den FT2 konkret betrifft sendet er nicht an seinen WT, obwohl ich ihn mit ihm assoziiert habe; als FT2 an WT.
Muss ich auch umgekehrt WT an FT2 set associate machen? (obwohl der FT nicht quittieren kann)

was die Bildzeitung betrifft ("BILD war dabei und sprach mit der Leiche") müsste ich im Log dann statt "123456"  die Adresse des WT "0ccd87" sehen?
Im Reading des WT und des WTs steht übrigens "PairedTo 123456", also sozusagen an alle.
Nähere ich mich dem Grundverständnis?

[Wzut]

Ich werd als Rentner doch noch ein MAX Buch schreiben, auch wenn ich eigentlich alles schon X Mal hier im Forum geschrieben habe.
Zuerst sollten die Begriffe klar sein , ich habe versucht mich an Homematic Sprachgebrauch zu halten :
Pairing : Kann nur 1x durchgeführt werden und das nur mit einer Zentrale ( Cube bzw CUL_MAX) , die Geräte senden auch wenn sie nicht gepaired sind aber sie nehmen keine Kommandos einer Zentrale an. Der FK spielt hier eine Sonderrolle : Im nicht gepairtem Zustand schickt er jedes oben/close einfach als Broadcast in die Welt ohne von irgend jemand eine Reaktion zu erwarten, d.h. die LED blinkt immer 1 x . Ist der FK mit einer Zentrale gepaired schickt er seine open/close Änderungen an die Zentrale und erwartet eine Quittung. Bleibt diese aus wiederholt er noch 2x mal , bleibt wieder die Qutttung aus blinkt er zum Schluss 3 x .
Zusätzlich schickt er unabhängig von open/close ca. alle Stunde seinen aktuellen Status an die Zentrale.   

Peering , bei MAX leider associate genannt bezeichent die direkte Kommunikation zweier MAX Geräte ( nicht Zentrale !)
Dieses peerren muß bei MAX leider i.d.R. zweimal durchgeführt werden. A mit B und B mit A.
Vorgehen : set Thermo1 assoicate Wandt , bedeutet : Das Telegramm geht via Cube/CUL an Thermo1 und sagt ihm das es ab jetzt einen Partner mit der Adresse <abcd12>  hat und es in Zukunft nun Nachrichten an diesen abcd12 schicken muß und das er auf Nachrichten von abcde12 an ihn reagiert. Statt eines WT kann es auch ein anderes HT oder ein FK sein.
Thermo1 wird nun bei einer Änderung seines Ventils diese Imformation plus der aktuellen Temperatur an abcd12 schicken. abcde12 hat aber keine Ahnung  warum Thermo1 das macht, er kennt ihn auch nicht. Also wird die Nachricht einfach ignoriert und Thermo1 wiederholt noch 2 x . Da Thermo 1 keine LED hat die 3 x blinken kann (wie der FK) blinkt bei einem HT/WT das Antennen (Radio) Symbol im Display. Gibt es eine Zentrale so sieht man das am Device Thermo1 nun das Reading rferror den Wert 1 hat.

Damit nun abcd12 die Nachrichten annimt und auch selbst Nachrichten an Thermo1 verschickt  (Soll Anderung, Wochenprofil Änderung , Fenster offen) muß
set <abcd12 Device Name> associate Thermo1 durchgeführt werden.

Ist abcd12 statt einem WT/HT ein Fensterkontakt kommt wieder eine Eigenart des FK ins Spiel : er schläft normalerweise fast immer, d.h. er wird das Telegramm vom Cube/CUL nicht sehen und daher auch nicht regagieren. Die Zentrale weiß das er ein notorischer Langschläfer ist und behandelt solche Telegramme die als Ziel einen FK haben anderes als solche an HT/WTs : Sie werden erst gar nicht verschickt sondern landen nur in der Sendqueue des CULMAX Device und da können sie recht lange überleben und zwar bis :
a. FHEM neu gestartet wird
b. der User die Queue mit dem Set Kommando löscht
c . Das Telegramm an den FK übertragen wurde   Moment wie soll das gehen ? Eben noch schreib ich es wird erst gar nicht verschickt  ? ! ?
Lösung : FHEM weiss wann der FK wach ist und zwar lange genug wach (weil er auf etwas wartet). Diesen Zustand gibt es nur wenn man den config Knopf am FK drückt. Da führt er ein re-pairing mit seiner Zentrale aus und genau das sieht FHEM und nutzt die Gelegenheit ihm das wartende Telegramm aus der Senqueue unterzuschieben. Verfolgen kann man das Spiel schön im Log bei verbose 5. Man sieht dann auch ob FHEM es geschafft hat die Info erfolgreich loszuwerden oder ob nun doch nach 2x Fehlversuchen das Telegramm aus der Queue gelöscht wird. Statt des config Knopfes kann man auch Batterie entfernen und wieder einlegen, denn auch hier führen die MAX Geräte einen re-pairing Versuch durch. Merke : Power Up = re-pairing Versuch, bei einem HT/WT ist es die Anzeige der Zahl 30 die schnell runterzählt und bei Erfolg sofort verschwindet.
Was aber auf keinen Fall geht und man hier immer wieder liest : einfaches Fenster auf/zu machen !!! 

     
   

[thburkhart]

sodele; ich habe mal Hausaufgaben gemacht:

hier die Tabelle über die MAX!-Geräte im Wohnzimmer: (Auswertung der jeweiligen Readings)
                     
                     
Gerät          Typ   Adresse   groupID   PairedTo   PeerIDs   PeerList              peers
WOHNZIMMER   WT   0ccd87   6           123456   "000000
                                                                                 08a373
                                                                                 08a8f2
                                                                                 16edc5   Broadcast
                                                                                                Wohnzimmer_O
                                                                                                Wohnzimmer_SO
                                                                                                Wohnzimmer_SW 054243
                                                                                                                          0cb39d
Wohnzimmer_O   HT    08a8f2   6           123456   "000000
                                                                                 0ccd87"   "Broadcast
                                                                                                 Wohnzimmer_WT"   
Wohnzimmer_SO HT   16edc5   6           123456   "000000
                                                                                 0ccd87"   "Broadcast
                                                                                                 Wohnzimmer_WT"   
Wohnzimmer_SW HT   08a373   6           123456   "000000
                                                                                 0ccd87"   "Broadcast
                                                                                                 Wohnzimmer_WT"   
FensterKontakt 2 SC   0cb39d              123456   kein Eintrag   kein Eintrag   

FensterKontakt 1 SC   054243           kein Eintrag   000000   Broadcast   
                     
MaxSystem via CUL_0                    123456               

und ein Zitat aus der Bildzeitung:
2020.09.30 10:46:38 4: MaxSystem, ACK from Wohnzimmer_SO to Wohnzimmer_WT
2020.09.30 10:46:38 5: MaxSystem: dispatch MAX,0,Ack,16edc5,0158002A
2020.09.30 10:46:38 5: MAX_Parse, MAX,0,Ack,16edc5,0158002A
2020.09.30 10:46:38 5: MAX_Parse, MAX2,0,ThermostatState,16edc5,58002A
also passend zu den Readings

Auffällig: keine Einträge bei den beiden Shutters. FK1 scheint nicht gepairt zu sein und FK2 hat keine peers ?

Das effektive Verhalten ist wie folgt:

a) FK2 öffnen:
    blinkt 1x , WT und alle 3 HT gehen auf 12 Grad
    prima
b) FK2 wieder schließen:
    blinkt 1x , WT und HT_O gehen auf 21 Grad (das ist die korrekte Wunschtemperatur laut weekprofile)
    HT_SO und HT_SW gehen auf 17 Grad (das ist die Nachttemperatur)
    nach einigen Minuten stehen alle Geräte auf der korrekten Wunschtemperatur laut weekprofile.

soweit fast gut

nun zu FK1:

Eventmonitor:
2020-09-30 11:11:45 MAX WOHNEN_F1 opened
2020-09-30 11:11:45 MAX WOHNEN_F1 RSSI: -72
2020-09-30 11:11:45 MAX WOHNEN_F1 battery: ok
2020-09-30 11:11:45 MAX WOHNEN_F1 batteryState: ok
2020-09-30 11:11:45 MAX WOHNEN_F1 rferror: 0
2020-09-30 11:11:45 MAX WOHNEN_F1 onoff: 1
2020-09-30 11:11:45 MAX WOHNEN_F1 peerList: Broadcast
2020-09-30 11:11:45 MAX WOHNEN_F1 peerIDs: 000000

blinkt 1x ; keine Reaktion in der Gruppe

Wohnzimmer_SO scheint unbeeindruckt:

2020-09-30 11:12:22 MAX Wohnzimmer_SO valveposition: 0
2020-09-30 11:12:22 MAX Wohnzimmer_SO 21.0°C (rf error)
2020-09-30 11:12:22 MAX Wohnzimmer_SO desiredTemperature: 21.0
2020-09-30 11:12:22 MAX Wohnzimmer_SO RSSI: -72.5
2020-09-30 11:12:22 MAX Wohnzimmer_SO battery: ok
2020-09-30 11:12:22 MAX Wohnzimmer_SO batteryState: ok
2020-09-30 11:12:22 MAX Wohnzimmer_SO rferror: 1
2020-09-30 11:12:22 MAX Wohnzimmer_SO gateway: 1
2020-09-30 11:12:22 MAX Wohnzimmer_SO mode: auto
2020-09-30 11:12:22 MAX Wohnzimmer_SO panel: unlocked
2020-09-30 11:12:22 MAX Wohnzimmer_SO peerList: Broadcast,Wohnzimmer_WT
2020-09-30 11:12:22 MAX Wohnzimmer_SO peerIDs: 000000,0ccd8
ebenso nach ein paar Minuten die anderen HTs.

schließlich wird FK1 wieder geschlossen:
2020-09-30 11:15:42 MAX WOHNEN_F1 closed
2020-09-30 11:15:42 MAX WOHNEN_F1 RSSI: -72
2020-09-30 11:15:42 MAX WOHNEN_F1 battery: ok
2020-09-30 11:15:42 MAX WOHNEN_F1 batteryState: ok
2020-09-30 11:15:42 MAX WOHNEN_F1 rferror: 0
2020-09-30 11:15:42 MAX WOHNEN_F1 onoff: 0
2020-09-30 11:15:42 MAX WOHNEN_F1 windowOpen: 0
2020-09-30 11:15:42 MAX WOHNEN_F1 peerList: Broadcast
2020-09-30 11:15:42 MAX WOHNEN_F1 peerIDs: 000000 

2020-09-30 11:16:20 MAX Wohnzimmer_O valveposition: 0
2020-09-30 11:16:20 MAX Wohnzimmer_O 21.0°C
2020-09-30 11:16:20 MAX Wohnzimmer_O desiredTemperature: 21.0
2020-09-30 11:16:20 MAX Wohnzimmer_O RSSI: -71.5
2020-09-30 11:16:20 MAX Wohnzimmer_O battery: ok
2020-09-30 11:16:20 MAX Wohnzimmer_O batteryState: ok
2020-09-30 11:16:20 MAX Wohnzimmer_O rferror: 0
2020-09-30 11:16:20 MAX Wohnzimmer_O gateway: 1
2020-09-30 11:16:20 MAX Wohnzimmer_O mode: auto
2020-09-30 11:16:20 MAX Wohnzimmer_O panel: unlocked

alles bleibt unverändert
im log findet sich passend dazu:

Code Auswählen Erweitern

2020.09.30 11:15:42 5: MaxSystem: dispatch MAX,0,ShutterContactState,054243,00
2020.09.30 11:15:42 5: MAX_Parse, MAX,0,ShutterContactState,054243,00
2020.09.30 11:15:42 5: WOHNEN_F1, bat 0, rferror 0, isopen 0, unkbits 0
2020.09.30 11:16:00 5: MaxSystem, BroadcastTime payload : 141e0b9040
2020.09.30 11:16:00 5: MaxSystem, Broadcast time to 08a8f2
2020.09.30 11:16:00 4: MaxSystem, send -> cmd:TimeInformation, msgcnt:0d, flags:04, Cmd2id:03, src:MAX_123456 , dst:Wohnzimmer_O , gid:00 , payload:141e0b9040 , cul:none
2020.09.30 11:16:00 5: MaxSystem, send packet: 0f0d040312345608a8f200141e0b9040
2020.09.30 11:16:00 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:00 5: MaxSystem, Send Queue CUL_0 -> needPreamble: 1, necessaryCredit: 113, credit10ms: 900, CUL_0 CMD_LAST_H: 1
2020.09.30 11:16:00 5: MaxSystem, Send Queue updating packet TimeInformation payload
2020.09.30 11:16:00 4: MaxSystem, Send Queue packet send : Zs0f0d040312345608a8f200141e0b9040 to Wohnzimmer_O with CUL_0
2020.09.30 11:16:00 4: MaxSystem, periodical TimeInformation sent to Wohnzimmer_O
2020.09.30 11:16:01 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:01 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:02 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:02 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:03 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:03 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:03 4: MaxSystem, Send Queue retry Wohnzimmer_O for TimeInformation count: 3
2020.09.30 11:16:06 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:06 5: MaxSystem, Send Queue CUL_0 -> needPreamble: 1, necessaryCredit: 113, credit10ms: 794, CUL_0 CMD_LAST_H: 1
2020.09.30 11:16:06 5: MaxSystem, Send Queue updating packet TimeInformation payload
2020.09.30 11:16:06 4: MaxSystem, Send Queue packet send : Zs0f0d040312345608a8f200141e0b9046 to Wohnzimmer_O with CUL_0
2020.09.30 11:16:07 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:08 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:08 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:09 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:09 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:10 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:10 4: MaxSystem, Send Queue retry Wohnzimmer_O for TimeInformation count: 2
2020.09.30 11:16:13 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:13 5: MaxSystem, Send Queue CUL_0 -> needPreamble: 1, necessaryCredit: 113, credit10ms: 688, CUL_0 CMD_LAST_H: 2
2020.09.30 11:16:13 5: MaxSystem, Send Queue updating packet TimeInformation payload
2020.09.30 11:16:13 4: MaxSystem, Send Queue packet send : Zs0f0d040312345608a8f200141e0b904d to Wohnzimmer_O with CUL_0
2020.09.30 11:16:14 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:14 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:15 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:15 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:16 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:16 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:16 4: MaxSystem, Send Queue retry Wohnzimmer_O for TimeInformation count: 1
2020.09.30 11:16:19 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:19 5: MaxSystem, Send Queue CUL_0 -> needPreamble: 1, necessaryCredit: 113, credit10ms: 582, CUL_0 CMD_LAST_H: 3
2020.09.30 11:16:19 5: MaxSystem, Send Queue updating packet TimeInformation payload
2020.09.30 11:16:19 4: MaxSystem, Send Queue packet send : Zs0f0d040312345608a8f200141e0b9053 to Wohnzimmer_O with CUL_0
2020.09.30 11:16:20 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:20 5: MaxSystem, IODev CUL_0, len 14, msgcnt 0D, msgflag 02, msgType Ack, src 08a8f2, dst 123456, group 0, payload 0118002A, rssi -71.5
2020.09.30 11:16:20 5: MaxSystem, ACK from Wohnzimmer_O for cmd TimeInformation , packet will be removed soon
2020.09.30 11:16:20 5: MaxSystem: dispatch MAX,1,Ack,08a8f2,0118002A
2020.09.30 11:16:20 5: MAX_Parse, MAX,1,Ack,08a8f2,0118002A
2020.09.30 11:16:20 5: MAX_Parse, MAX2,1,ThermostatState,08a8f2,18002A
2020.09.30 11:16:21 5: MaxSystem, Send Queue 1 packet in queue
2020.09.30 11:16:21 4: MaxSystem, Send Queue ACK from Wohnzimmer_O for TimeInformation, removing from queue
2020.09.30 11:16:21 5: MaxSystem, Send Queue is now empty
2020.09.30 11:17:00 5: MaxSystem, IODev CUL_0, len 12, msgcnt 7E, msgflag 04, msgType WallThermostatControl, src 07898a, dst 1b0bc0, group 0, payload 22DB, rssi -77.5

die Zentrale schickt also was an Wohnzimmer_O, was jedoch nicht sofort abgesetzt werden kann?

so stellen sich für mich 2 Fragen:

zum Fensterkontakt 2: wie erreiche ich, dass sein Schließen an alle peers geht?   
                                  warum ist seine peerlist leer?

zum Fensterkontakt 1: wie kriege ich den (wieder) gepaired?

noch eine Info dazu:
In den readings des WT steht:

error
invalid or missing value for READING .weekProfile
2020-09-29 09:24:49

die nachfolgende Liste ist jedoch korrekt und vollständig:

weekprofile-0-Sat-temp
17.0 °C / 21.0 °C / 18.0 °C
2020-09-29 09:25:55
weekprofile-0-Sat-time
00:00-07:00 / 07:00-22:00 / 22:00-24:00
2020-09-29 09:25:55
weekprofile-1-Sun-temp
17.0 °C / 21.0 °C / 18.0 °C
2020-09-29 09:25:55
weekprofile-1-Sun-time
00:00-07:00 / 07:00-22:00 / 22:00-24:00
2020-09-29 09:25:55
weekprofile-2-Mon-temp
17.0 °C / 21.0 °C / 18.0 °C
2020-09-29 09:25:55
weekprofile-2-Mon-time
00:00-07:00 / 07:00-22:00 / 22:00-24:00
2020-09-29 09:25:55
weekprofile-3-Tue-temp
17.0 °C / 21.0 °C / 18.0 °C
2020-09-29 09:25:55
weekprofile-3-Tue-time
00:00-07:00 / 07:00-22:00 / 22:00-24:00
2020-09-29 09:25:55
weekprofile-4-Wed-temp
17.0 °C / 21.0 °C / 18.0 °C
2020-09-29 09:25:55
weekprofile-4-Wed-time
00:00-07:00 / 07:00-22:00 / 22:00-24:00
2020-09-29 09:25:55
weekprofile-5-Thu-temp
17.0 °C / 21.0 °C / 18.0 °C
2020-09-29 09:25:55
weekprofile-5-Thu-time
00:00-07:00 / 07:00-22:00 / 22:00-24:00
2020-09-29 09:25:55
weekprofile-6-Fri-temp
17.0 °C / 21.0 °C / 18.0 °C
2020-09-29 09:25:55
weekprofile-6-Fri-time
00:00-07:00 / 07:00-22:00 / 22:00-24:00
2020-09-29 09:25:55
Wohnzimmer_


ich danke für eure Geduld mit mir

Thomas

[Wzut]

Deine Readings und deine Beschreibung passen perfekt zu meiner Erklärung.
Das Reading PairedTo muss immer etwas mit Vorsciht behandelt werden, wenn es fehlt kann sein das verloren ging (selbst schuld wer kein Backup macht) oder das System einfach noch keine Chance hatte es zu erkennen.
Trifft aber in deinem Fall beides nicht zu.

nach einigen Minuten stehen alle Geräte auf der korrekten Wunschtemperatur laut weekprofile

Das ist OK bei mehr als einem HT in einem Raum. Bei meiner Testinsel mit zwei HTs hängt manchmal auch der eine etwas nach bis Chef WT ihn auf die richtige Spur bringt.
Bei mir sind allerdings die beiden HTs noch drekt miteinader gepeerd, dadurch kann man einen manuell verstellen und sein Bruder macht das Spiel sofort mit.

die Zentrale schickt also was an Wohnzimmer_O, was jedoch nicht sofort abgesetzt werden kann?

das war reiner Zufall das du genau den Punkt erwischt hast wo FHEM die interene Uhrzeit des HT synchronisiert. Das Telgramm wurde halt zweimal wiederholt bis es ein ACK bekam, alles gut, kommt vor.

invalid or missing value for READING .weekProfile

kommt vor , einfach so tun als würde ein Tag geändert. Das Reading .weekprofile schüttelt sich schon wieder alleine in Form. Aber wieder so ein Thema für mein Mantra : ach würden die User nur das interne MAX Backup nutzen ...

zu deinen ganzen FK Fragen sag ich jetzt nur soviel :
Ich habe mir gestern echte Mühe gegeben das lang und breit zu erklären. Bitte mach du dir nun auch mal die Mühe es mehrfach zu lesen und versuch es wenigstens im Ansatz zu verstehen !
denn bei Fragen wie

zum Fensterkontakt 1: wie kriege ich den (wieder) gepaired?

komm ich mir dann doch ein bissel vera.... vor
Blöde Gegenfragen  :
Wie hast denn bisher deine MAX Geräte gepaired ?  bzw. was steht denn in jeder MAX Anleitung wie man ein Gerät mit der Zentrale pairen soll ?