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

[thburkhart]

Hallo zusammen,

inzwischen habe ich es geschafft meine MAX-Thermostate mit CUL zum Laufen zu bekommen. Auch die Steuerung durch die Fensterkontakte läuft prima.
Das Problem lag darin begründet, dass die Credits nicht ausreichten, wenn man die die Geräte zu schnell hintereinander pairte. Nach eine Pause von mind. 30 min gelang dies.

Nun hänge ich an den Wochenprofilen:

Folgendes habe ich definiert:

Code Auswählen Erweitern

define weekprofile weekprofile
setuuid weekprofile 5df78dd7-f33f-9b0e-9b06-9bc609f869225a9b
attr weekprofile room MAX
attr weekprofile group WeekProfiles
attr weekprofile useTopics 1


und im Devicce:

Code Auswählen Erweitern

define THOMAS_WT MAX WallMountedThermostat 0ccdec
setuuid THOMAS_WT 5de13dfe-f33f-9b0e-2d3a-0b041e173ab9c60d
attr THOMAS_WT userattr weekprofile
attr THOMAS_WT IODev MaxSystem
attr THOMAS_WT alias THOMAS
attr THOMAS_WT comment 0ccdec KEQ0808634
attr THOMAS_WT group Wandthermostat
attr THOMAS_WT room MAX,MAXW,Thomas
attr THOMAS_WT weekprofile default:THOMAS

DeviceOverview
THOMAS
19.2°C

THOMAS_WT
Internals
DEF
WallMountedThermostat 0ccdec
FUUID
5de13dfe-f33f-9b0e-2d3a-0b041e173ab9c60d
IODev
MaxSystem
LASTInputDev
MaxSystem
MSGCNT
410
MaxSystem_MSGCNT
410
MaxSystem_TIME
2019-12-17 18:10:03
NAME
THOMAS_WT
NR
401
RSSI
-62.5
STATE
18.0 °C
TYPE
MAX
addr
0ccdec
backend
MaxSystem
rferror
0
type
WallMountedThermostat
Readings
RSSI
-62.5
2019-12-17 18:12:48
TimeInformationHour
1
2019-11-29 16:49:47
battery
ok
2019-12-17 14:42:05
batteryState
ok
2019-12-17 14:42:05
comfortTemperature
21
2019-11-29 17:19:53
desiredTemperature
18.0
2019-12-17 18:12:48
displayActualTemperature
1
2019-12-17 14:42:05
ecoTemperature
17
2019-12-02 19:20:21
groupid
0
2019-11-29 16:50:14
maximumTemperature
22.0
2019-12-15 02:17:35
measurementOffset
0
2019-12-02 19:20:21
minimumTemperature
10.5
2019-12-15 02:13:46
mode
manual
2019-12-17 14:42:05
msgcnt
65
2019-12-17 14:41:51
panel
unlocked
2019-12-17 14:42:05
rferror
0
2019-12-17 14:42:05
state
18.0 °C
2019-12-17 18:12:48
temperature
19.2
2019-12-17 18:12:48
weekprofile-0-Sat-temp
17.0 °C / 21.0 °C / 17.0 °C
2019-12-16 21:43:25
weekprofile-0-Sat-time
00:00-06:00 / 06:00-22:00 / 22:00-24:00
2019-12-16 21:43:25
weekprofile-1-Sun-temp
17.0 °C / 21.0 °C / 17.0 °C
2019-12-16 21:43:25
weekprofile-1-Sun-time
00:00-06:00 / 06:00-22:00 / 22:00-24:00
2019-12-16 21:43:25
weekprofile-2-Mon-temp
18.0 °C / 21.0 °C
2019-12-16 21:43:25
weekprofile-2-Mon-time
00:00-06:00 / 06:00-24:00
2019-12-16 21:43:25
weekprofile-3-Tue-temp
18.0 °C / 21.0 °C
2019-12-16 21:43:25
weekprofile-3-Tue-time
00:00-06:00 / 06:00-24:00
2019-12-16 21:43:25
weekprofile-4-Wed-temp
17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2019-12-16 21:43:25
weekprofile-4-Wed-time
00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-24:00
2019-12-16 21:43:25
weekprofile-5-Thu-temp
17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2019-12-16 21:43:25
weekprofile-5-Thu-time
00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-24:00
2019-12-16 21:43:25
weekprofile-6-Fri-temp
17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2019-12-16 21:43:25
weekprofile-6-Fri-time
00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-24:00
2019-12-16 21:43:25
windowOpenDuration
15
2019-12-02 19:20:21
windowOpenTemperature
12.0
2019-12-02 19:20:29
THOMAS_WT
MAX,MAXW,Thomas
Attributes
IODev
MaxSystem
deleteattr
alias
THOMAS
deleteattr
comment
0ccdec KEQ0808634
deleteattr
group
Wandthermostat
deleteattr
room
MAX,MAXW,Thomas
deleteattr
userattr
weekprofile
deleteattr
weekprofile
default:THOMAS
deleteattr

in den Readings sind Werte zu sehen, die ich über andFHEm gesetzt hatte.

Ich nahm an, dass es eine Weile dauert,bis sie durch die Einstellung in weekprofile THOMAS mit 18 Grad durchgängig (Test) überschrieben werden.
Bei anderen Devices mit leerem Profil klappt das auch nicht.
Als versuche ich es händisch mit "send_to device":

Schicke ich den Befehl send_to_device ab, erhalte ich die Fehlermeldung "
Error no devices given and no master device"

was mache ich falsch?

[Wzut]

beim nächsten Post bitte alles in Code Tags (ich habe es editiert) und bitte keine Screenshots.

Was ich nicht verstehe :

Code Auswählen Erweitern

attr THOMAS_WT userattr weekprofile
attr THOMAS_WT weekprofile default:THOMAS
warum ? und wo steht das man das machen soll ?
Das ist eigentlich kein MAX Thema, (gehört nach Frontends -> https://forum.fhem.de/index.php/board,19.0.html) aber fang mal langsam an :
Lege dir ein einziges Profil an (default) und drücke dann in der Übersicht den --> Knopf (send to device ) , wähle nun dein THOMAS_WT aus und dann unten OK.
Was steht danach im Log ?

[thburkhart]

ich danke für deine Hinweise

ich habe das https://wiki.fhem.de/wiki/Weekprofile entnommen; wenn topics gesetzt, sollte dies auch  als default topic angegeben werden ..

dein Tip hat geholfen; die direkte Übertragung aus de Profileditor heraus  löste das Problem

um die Topics kümmere ich mich später

besten Dank !!

Thomas

[Wzut]

ich habe das https://wiki.fhem.de/wiki/Weekprofile entnommen; wenn topics gesetzt, sollte dies auch  als default topic angegeben werden ..

ahh ok , THX Ich habe noch nie mit Topics gearbeitet und kannte es daher bis jetzt nicht. (auch wieder was gelernt )

[thburkhart]

leider ist ein neues Phänomen aufgetaucht:

Die Wochenprofile erscheinen in allen Thermostaten. Mit  set "desiredTemperature" auf "auto" wird auch in 3 Räumen das wochenprofil eingestellt.

Nicht jedoch ein einem Raum "Wohnzimmer". Nach Stellen auf "auto" wird die desiredTempatutre auf 12 Grad gestellt. Alle Fensterkontakte stehen auf "closed".

Woran kann das liegen ?

Code Auswählen Erweitern


DeviceOverview
WOHNZIMMER
20.9°C

Wohnzimmer_WT
Internals
CHANGED
DEF
WallMountedThermostat 0ccd87
FUUID
5de183aa-f33f-9b0e-bcc0-6e8ff0be9e051528
IODev
MaxSystem
LASTInputDev
MaxSystem
MSGCNT
790
MaxSystem_MSGCNT
790
MaxSystem_TIME
2019-12-19 10:19:26
NAME
Wohnzimmer_WT
NR
418
RSSI
-62.5
STATE
12.0 °C
TYPE
MAX
addr
0ccd87
backend
MaxSystem
rferror
0
type
WallMountedThermostat
Readings
RSSI
-62.5
2019-12-19 10:19:26
TimeInformationHour
0
2019-11-29 16:44:56
battery
ok
2019-12-19 10:19:26
batteryState
ok
2019-12-19 10:19:26
comfortTemperature
21
2019-12-02 19:18:50
desiredTemperature
12.0
2019-12-19 10:19:26
displayActualTemperature
1
2019-12-19 10:19:26
ecoTemperature
17.0
2019-12-15 01:56:37
groupid
0
2019-11-29 16:44:45
maximumTemperature
25.0
2019-12-19 09:19:21
measurementOffset
0
2019-12-02 19:18:50
minimumTemperature
12.0
2019-12-15 13:02:31
mode
auto
2019-12-19 10:19:26
msgcnt
114
2019-12-19 10:19:25
panel
unlocked
2019-12-19 10:19:26
rferror
0
2019-12-19 10:19:26
state
12.0 °C
2019-12-19 10:19:26
temperature
20.9
2019-12-19 10:22:21
weekprofile-0-Sat-temp
17.0 °C / 19.0 °C / 21.0 °C / 18.0 °C
2019-12-18 20:07:36
weekprofile-0-Sat-time
00:00-06:00 / 06:00-08:00 / 08:00-22:00 / 22:00-24:00
2019-12-18 20:07:36
weekprofile-1-Sun-temp
17.0 °C / 19.0 °C / 21.0 °C / 18.0 °C
2019-12-18 20:07:36
weekprofile-1-Sun-time
00:00-06:00 / 06:00-08:00 / 08:00-22:00 / 22:00-24:00
2019-12-18 20:07:36
weekprofile-2-Mon-temp
17.0 °C / 19.0 °C / 21.0 °C / 18.0 °C
2019-12-18 20:07:36
weekprofile-2-Mon-time
00:00-06:00 / 06:00-08:00 / 08:00-22:00 / 22:00-24:00
2019-12-18 20:07:36
weekprofile-3-Tue-temp
17.0 °C / 19.0 °C / 21.0 °C / 18.0 °C
2019-12-18 20:07:36
weekprofile-3-Tue-time
00:00-06:00 / 06:00-08:00 / 08:00-22:00 / 22:00-24:00
2019-12-18 20:07:36
weekprofile-4-Wed-temp
17.0 °C / 19.0 °C / 21.0 °C / 18.0 °C
2019-12-18 20:07:36
weekprofile-4-Wed-time
00:00-06:00 / 06:00-08:00 / 08:00-22:00 / 22:00-24:00
2019-12-18 20:07:36
weekprofile-5-Thu-temp
17.0 °C / 19.0 °C / 21.0 °C / 18.0 °C
2019-12-18 20:07:36
weekprofile-5-Thu-time
00:00-06:00 / 06:00-08:00 / 08:00-22:00 / 22:00-24:00
2019-12-18 20:07:36
weekprofile-6-Fri-temp
17.0 °C / 19.0 °C / 21.0 °C / 18.0 °C
2019-12-18 20:07:36
weekprofile-6-Fri-time
00:00-06:00 / 06:00-08:00 / 08:00-22:00 / 22:00-24:00
2019-12-18 20:07:36
windowOpenDuration
15
2019-12-02 19:18:50
windowOpenTemperature
12.0
2019-12-15 12:36:29
Wohnzimmer_WT
MAXW,MAX,Wohnzimmer
Attributes
IODev
MaxSystem
deleteattr
alias
WOHNZIMMER
deleteattr
comment
0ccd87 KEQ0808782
deleteattr
event-on-change-reading
state,temperature
deleteattr
group
Wandthermostat
deleteattr
room
MAXW,MAX,Wohnzimmer
deleteattr
userReadings
temperature,status
deleteattr
userattr
weekprofile
deleteattr
weekprofile
WOHNEN
deleteattr

[Wzut]

Da gibt es eigentlich fast nur eine Erklärung :
Dein WT ist der Meinung mal ein Open Window gehört zu haben und geht auf seine Open Window Temp , i.d.R. sind das 12 °C
das sollte man aber auch am WT sehen , oben rechts das offene Fenster Symbol , ist es da ?
Wenn ja und kein Fenster offen ist würde ich am WT für 1 Min die Batterien rausnehmen, danach sollte er das offene Fenster vergessen haben.
Ist irgend ein echter FK oder fakeSC mit diesem WT gepeert ? Irgendwo her muß er ja mal die Info über ein mit ihm verbundenes offenes Fenster bekommen haben.

[thburkhart]

danke für den Hinweis

ich bin erst heute Abend wieder zuhause

am Sonntag hatte ich im Wohnzimmer festgestellt, dass er das Schliessen /Öffnen der beiden Fensterkontakte nicht sauber erkannte und dann schließlich auf 12  Grad stehen blieb; die Temperatur hatte ich schließlich auf 20 Grad hochgesetzt.
Ich nahm an, das es an den Credits lag.


kann man denn eigentlich irgenwie den openWindows-Status  und den assosiate Status auslesen ? per get ?

[Wzut]

kann man denn eigentlich irgenwie den openWindows-Status  und den assosiate Status auslesen ? per get ?

das wäre schön wenn dem so wäre, würde ich sofort in die Module einbauen. Vllt gibt es wirklich Kommandos die man dem Gerät schicken kann und kommt als Antwort eine Liste interner Parameter so wie bei z.B. bei HM mit set <name> getConfig
Aber entweder können es die Geräte gar nicht oder es hat bis jetzt noch niemand herausgefunden wie es ginge.

[thburkhart]

"Wenn ja und kein Fenster offen ist würde ich am WT für 1 Min die Batterien rausnehmen, danach sollte er das offene Fenster vergessen haben."
das hat geholfen

nun kriege ich nur einen der beiden Fensterkontakte wieder assoziert.

ich habe es so versucht

Set WT associate Festerkontakt1
Set Festerkontakt1 associate  WT
Set Festerkontakt1 associate  HT1
Set Festerkontakt1 associate  HT2
Set HT1 associate Festerkontakt1
Set HT2 associate Festerkontakt1

WT, HT1 und HT2 sind erfolgreich assoziiert

wie gesagt das ging nur für den ersten Fensterkontakt

der Zweite zeigt schön 1x Grün beim Betätigen, wird auch als "open" angezeigt; jedoch reagieren weder WT und die beiden ass. HTs

was mache ich wohl falsch?

[Wzut]

Fensterkontakte sind eindeutig die Maxelines (die Mädchen) der MAX Familie ....
Ich habe da jetzt auch so einige Kämpfe hinter mir. Um wirklich zu sehen was bei dir passiert bzw eben nicht passiert hilft vllt. wenn du du die beiden Test Dateien von mir verwendest und CUL und CUL_MAX Device dann jeweils auf verbose 5 stellst.
Dann mal ein paar Aktionen durchführen und das Log hier posten.

Was ich aber bisher herausgefunden habe :
Es reicht durchaus wenn das associate (peering) nur einseitig durchgefühert wird :

Code Auswählen Erweitern

set WT associate Festerkontakt2 , set HT1 associate Festerkontakt2 & set HT2 associate Festerkontakt2
danach sollten die drei zumindest auf die Broadcast Nachrichten von FK2 hören, auch wenn der FK keine Telegramme direkt zu den dreien schickt.
Hat IMHO nur den Nachteil das er nie rot blinken wird (und keine rf error zeigt) wenn mal ein Telegramm von den anderen nicht gehört wurde.
Meine Testinsel besteht leider nur aus 1 x FK, 1x WT und 2x HT und da ist das wichtigste Element das WT !!!
Das Ding erzählt den beiden HTs schon recht gut was sie zu tun und zu lassen haben.   

[thburkhart]

ok

verstehe; habe 5 Jungs

und teste mal

[Wzut]

Hat IMHO nur den Nachteil das er nie rot blinken wird

man ich Depp, schon wieder dieser Fehler : rot blinkt HM, MAX hat nur eine grüne LED und die blinkt bei Fehler drei mal

[thburkhart]

gibt es denn inzwischen Neuigkeiten zu den Maxelines und deren Stabilität bzgl. associate? 

[Wzut]

Staibil sind und waren sie schon immer und an der Hardware und ihrem Verhalten kann ich eh nichts ändern.
Wo liegt also z.Z. dein Problem ?

[thburkhart]

ich habe im Wohnzimmer
1 WT
3 HTs

2 Fensterkontakte

im Bad
1 WT
1 HT
1 FK


mir ist es nicht gelungen (siehe Post weiter oben), mit Fensteröffnung den WT und damit die HTs auf 12 Grad und mit Schließung wieder auf auto zu setzen.
Ich hatte alle associate-Kombinationen hergestellt.

im Büro mit 1 WT, 2 HT, 2 FK funktioniert es hingegen einwandfrei

Das Grundproblem dürfte also das associate sein
Leider sieht man ja nicht, ob das associate auch tatsächlich vollzogen wurde

[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 ?

[thburkhart]

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 ?

das war ganz bestimmt nicht meine Absicht; ich hatte Sie nach Anleitung (mit Knöpfchendrücken) gepairt und war deswegen etwas verwundert.
Ich werde wohl nach bestehender resetten müssen.

Ich bedanke mich nochmals ausdrücklich für deine aufopfernde Mühe.

Herzliche Grüße

Thomas

[Wzut]

Ich werde wohl nach bestehender resetten müssen.

Warum reset ? Abmontieren und sich damit vor den PC setzen, Eventmonitor mit MAX Filter und Log Haken auf , Knopf drücken und schauen was da so abläuft. Ggf einfach den Knopf wieder drücken bis die Sendqueue leer ist.   

[thburkhart]

ich kann nun Erfolg melden.

Die Auswertung von Logs und der Readings ergab, dass 3 meiner FKs mit eine PeerID anzeigten, die nicht in meinem System existierte.

Ein Löschen der Geräte brachte nichts; sie zeigten sich nach restart immer noch mit der Phantom-ID verheiratet. Ein neuer set associate Versuch wurde mit der Fehlermeldung abgewiesen, man sei ja schon mit besagter ID verheiratet.

Also Batterien raus, und Werkszustand hergestellt, Magnet ran und weg und der FQ war wieder unverheiratet erkannt

Nach jeweils neuem associate lt. Lehrbuch sind die FKs nun richtig mit ihren WTs verheiratet.

Ich danke Wzut nochmals für seine Geduld und Mühe, von der wohl auch weitere profitieren können.

Beste Grüße

Thomas

[JHo]

Die Auswertung von Logs und der Readings ergab, dass 3 meiner FKs mit eine PeerID anzeigten, die nicht in meinem System existierte.

Ein Löschen der Geräte brachte nichts; sie zeigten sich nach restart immer noch mit der Phantom-ID verheiratet. Ein neuer set associate Versuch wurde mit der Fehlermeldung abgewiesen, man sei ja schon mit besagter ID verheiratet.

Vielleicht kann ich mich an dieser Stelle kurz einklinken - ich habe ein ganz ähnliches Phänomen: bei mir werden in mehreren Heizkörperthermostaten Peer-IDs angezeigt (bis zu 6 Stück!), die es in dem System nicht gibt, u.a. 00000e. Die lassen sich mit folgender Fehlermeldung nicht deassoziieren: "Heizung.Kuechenwand, no MAX device found with address MAX_00000e".
Was gibt es für Lösungsmöglichkeiten, um die Peerings zu bereinigen? Hilft nur reset am HT und dann neu pairen?

Danke, Jan

[thburkhart]

Hallo Jan,

ich vermute mal, das auch hier nur eine harte Scheidung hilft.

Ich vergaß zu erwähnen, dass das Ganze wegen der Kreditlimits recht langwierig ist. Bis die ganzen Packets durch waren, hat es bei mir je Gerät 3ca. 40 min gedauerrt.

Dem Tip vom Wzut folgend habe ich 2 Browserfenster aufgemacht und parallelgestellt: Eines zum Senden der Set-Befehle aus dem Device heraus und ein zweites mir dem Eventmonitor auf MAX Geräte. So konnte ich genau verfolgen, wenn alle Packets durch waren.

Um individuelle Einstellungen der Geräte zu erhalten, bin ich wie folgt vorgegangen:

1) zu reparierende Geräte in der fhem.cfg mir Strg-Q auskommentieren.
2) shutdown restart
3)  Gerät auf Werkseinstellungen zurücksetzen
4) Gerät wird neue erlkannt und erscheint am Ende der fhem.cfg. Die Adresse müsste indentisch zum auskommentierten/gelöschen Gerät sein
5) entsprechende Auskommentierungen wieder aktivieren
6) speichen und vorsichshalber shutdown restart
7) entsprechende Set assotioates absetzen und im parallelen Eventmonitor kontrollieren
Warten
9) warten
10) ggf. ab 7 wiederholen
11) im Erfolgsfall müssten die peerIDs sauber in den Readings angezeigt werden

[JHo]

Dankeschön. Ich habe schon seit Ewigkeiten "gefühlt" Probleme mit sich selbst verstellenden Soll-Werten, die ich nicht in den Griff bekomme. Dank der PeerList sehe ich ja jetzt deutlich, dass bei manchen Thermostaten einiges im Argen liegt. Am schlimmsten in dem Raum mit den meisten Phantom-Peers. Daher ist ein Reset zwar zeitaufwändig, aber vielleicht parallel auch die Lösung meiner bisherigen Probleme.

Evtl. habe ich das hier überlesen: Warum löschst du (kommentierst aus) die zu resettenden Geräte aus der cfg? Warum können die nicht "stehen" bleiben?

[Wzut]

@JHo, erst war ich etwas verwundert wegen der Fehlermeldung, habe dann aber nochmal in 10_MAX nachgeschaut :
Ich prüfe sowohl bei assoiciate als auch deassociate ob das gewählte Ziel vom TYP MAX ist. Das macht bei assoicate auch Sinn, verhindert aber bei deassiocate das man eine Leiche auch wieder los wird. Ist im nächsten Update gefixt.
Workaround :
a. irgend ein MAX Device von Hand mit der Adresse anlegen, deasso durchführen und dann Gerät wieder aus FHEM löschen.
b. Backup vom HT machen , Werksreset , neu pairen und mittels restore wieder herstellen.Das verbraucht einiges an Credits also bitte nicht alle sechs auf einmal

1) zu reparierende Geräte in der fhem.cfg mir Strg-Q auskommentieren.

Wo bitte hast du diesen Blödsinn her
a. fhem.cfg wird nicht editiiert , erst recht nicht von Anfängern !
b. es gibt "fast" keinen vernünftigen Grund MAX Geräte aus der config zu nehmen oder zu löschen ! ausser das Device ist defekt und wird entsorgt.

6) speichen und vorsichshalber shutdown restart

speichern ist immer gut ... aber shutdown restart ? FHEM ist kein Windows und solange mann keine Module tauscht gibt es im MAX Umfeld auch keinen Grund dafür.

[thburkhart]

Workaround :
a. irgend ein MAX Device von Hand mit der Adresse anlegen, deasso durchführen und dann Gerät wieder aus FHEM löschen.
b. Backup vom HT machen , Werksreset , neu pairen und mittels restore wieder herstellen.Das verbraucht einiges an Credits also bitte nicht alle sechs auf einmal

Genau dieses Workaround habe ich gestern versucht. Schritt a) (dummydevice) hat schlicht nicht funktioniert.
Deshalb bin so wie von mir beschrieben vorgegangen.

[thburkhart]

nun geht der Ärger (mit den credits) doch weiter :

Ich habe gebrauchte HTs erstanden.
gemäß Anleitung vorgegangen:
1) Auf werkseinstellungen zurückgesetzt
2) mit pairmode 60 angelernt; Gerät erscheint schön im Raum MAX
3) mit boost Adapterfahrt durchgeführt


Im Listing des HT fand und finde ich seit 13:47 nichts Neues:

Code Auswählen Erweitern

Internals:
   DEF        HeatingThermostatPlus 1354b1
   FUUID      5f80599f-f33f-21fb-9d30-f50770df8ef43408
   IODev      MaxSystem
   NAME       DIELE_HT
   NR         627
   NTFY_ORDER 50-DIELE_HT
   STATE      waiting for data
   SVN        22368
   TYPE       MAX
   TimeSlot   5
   addr       1354b1
   devtype    2
   type       HeatingThermostatPlus
   READINGS:
     2020-10-09 13:47:53   PairedTo        000000
     2020-10-09 13:47:53   RSSI            -72.5
     2020-10-09 13:47:53   SerialNr        MEQ1472649
     2020-10-09 13:47:53   boostDuration   25
     2020-10-09 13:47:53   boostValveposition 80
     2020-10-09 13:47:53   comfortTemperature 21.0
     2020-10-09 13:47:53   decalcification Sat 12:00
     2020-10-09 13:47:53   ecoTemperature  17.0
     2020-10-09 13:44:39   error           invalid or missing value  for READING .weekProfile
     2020-10-09 13:47:53   firmware        1.0
     2020-10-09 13:44:39   groupid         0
     2020-10-09 13:47:53   lastcmd         HeatingThermostatConfig
     2020-10-09 13:47:53   maxValveSetting 100
     2020-10-09 13:47:53   maximumTemperature on
     2020-10-09 13:47:53   measurementOffset 0.0
     2020-10-09 13:47:53   minimumTemperature off
     2020-10-09 13:47:53   msgcnt          2
     2020-10-09 13:47:53   peerIDs         000000
     2020-10-09 13:47:53   peerList        Broadcast
     2020-10-09 13:47:53   state           waiting for data
     2020-10-09 13:47:53   testresult      0
     2020-10-09 13:47:53   valveOffset     0
     2020-10-09 13:47:53   weekprofile-0-Sat-temp 17.0 °C  /  21.0 °C  /  17.0 °C
     2020-10-09 13:47:53   weekprofile-0-Sat-time 00:00-06:00  /  06:00-22:00  /  22:00-24:00
     2020-10-09 13:47:53   weekprofile-1-Sun-temp 17.0 °C  /  21.0 °C  /  17.0 °C
     2020-10-09 13:47:53   weekprofile-1-Sun-time 00:00-06:00  /  06:00-22:00  /  22:00-24:00
     2020-10-09 13:47:53   weekprofile-2-Mon-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-10-09 13:47:53   weekprofile-2-Mon-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-10-09 13:47:53   weekprofile-3-Tue-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-10-09 13:47:53   weekprofile-3-Tue-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-10-09 13:47:53   weekprofile-4-Wed-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-10-09 13:47:53   weekprofile-4-Wed-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-10-09 13:47:53   weekprofile-5-Thu-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-10-09 13:47:53   weekprofile-5-Thu-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-10-09 13:47:53   weekprofile-6-Fri-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-10-09 13:47:53   weekprofile-6-Fri-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-10-09 13:47:53   windowOpenDuration 15
     2020-10-09 13:47:53   windowOpenTemperature 12.0
Attributes:
   IODev      MaxSystem
   alias      Diele
   genericDeviceType thermostat
   group      Heizungsthermostat
   model      HeatingThermostatPlus
   room       Diele,MAX,MAXH

im Log erscheint u.a.

Code Auswählen Erweitern

2020.10.09 13:47:53 5: MaxSystem, IODev CUL_0, len 23, msgcnt 00, msgflag 00, msgType PairPing, src 1354b1, dst 000000, group 0, payload 1002004D455131343732363439, rssi -72.5
2020.10.09 13:47:53 4: MaxSystem, PairPing (dst 000000, pairmode 0), firmware 16, type HeatingThermostatPlus, testresult 0, serial MEQ1472649
2020.10.09 13:47:53 3: MaxSystem, Pairing device MAX_1354b1 of type HeatingThermostatPlus with serial MEQ1472649
2020.10.09 13:47:53 5: MaxSystem: dispatch MAX,0,define,1354b1,HeatingThermostatPlus,MEQ1472649,0
2020.10.09 13:47:53 5: MAX_Parse, MAX,0,define,1354b1,HeatingThermostatPlus,MEQ1472649,0
2020.10.09 13:47:53 4: MaxSystem, send -> cmd:PairPong, msgcnt:02, flags:00, Cmd2id:01, src:MAX_123456 , dst:MAX_1354b1 , gid:00 , payload:00 , cul:none
2020.10.09 13:47:53 5: MaxSystem, send packet: 0b0200011234561354b10000
2020.10.09 13:47:53 5: MaxSystem, Send Queue 1 packet in queue
2020.10.09 13:47:53 5: MaxSystem, Send Queue CUL_0 -> needPreamble: 1, necessaryCredit: 110, credit10ms: 572, CUL_0 CMD_LAST_H: 7
2020.10.09 13:47:53 4: MaxSystem, Send Queue packet send : Zs0b0200011234561354b10000 to MAX_1354b1 with CUL_0
2020.10.09 13:47:53 5: MaxSystem: dispatch

Es bleibt also mit "waiting for data" stehen.

Ich dachte erst, dass es mal wieder an Credits fehlt. Aber nun sind ja 4 Stunden vergangen.

Dasselbe passiert mit 2 weiteren HTs.

Ich bin mal wieder ratlos und hoffe auf gnädige Hilfe

[Wzut]

2020-10-09 13:47:53   PairedTo        000000

da steht deine Antwort : das HT ist nicht gepaired !
und wie immer bei dir : da wo es wichtig wird schneidest du die Logs ab ....

[thburkhart]

oh - danke
pairedto 000000 ist nicht gepaired;
123456  gepaired ?

inzwischen habe ich das Teil (ein Plus Thermostat) 2mal reseted und o.g. Prozedur durchgeführt; er läuft nun

mit dem MEDION Heizungsthermostat habe ich es inzwischen 6-ma< versucht; der will immerr noch nicht

gibt's bei MEDION Probleme?

[Wzut]

Wenn ein MAX Device PairedTo 000000 hat dann ist es zurückgesetzt, weitere Resets sind da nicht nötig, einfach nochmal lange die Boost Taste (HT/WT) drücken bis der 30 Sekunden Countdown erscheint. Von Medion habe ich keine Ahnung, müsste man schauen was der so von sich gibt im verbose 5 Log.

[thburkhart]

danke, das hat geholfen

habe dabei gelernt, dass durch langes Drücken auch die Readings aktualisiert werden, so auch z.B. die SerienNrn und alte Peers

Die MedionTeile sind recht hartnäckig gegen den Reset-Klammergriff; musste bis zu 3mal wiederholen

Insgesamt braucht man in jedem Fall sehr, sehr viel Geduld. (mind. 30 min je Device) auch für FKs . Da kommt wohl zum Tragen, dass mein MAX-System inzwischen recht ausgedehnt ist. Deshalb traue ich mich gar nicht mehr, die ECO-Taster zu betätigen.

Kann man abgesehen vom EventMonitor irgendwie auflisten lasse, was noch in der Send Queue steht ?

[Wzut]

klar, steht sogar in https://forum.fhem.de/index.php/topic,106258.msg1031078.html#msg1031078

neues Kommando : get <name> showSendQueue
es wurde hier im Forum mehrfach schon der Wunsch laut das man sich gern anschauen möchte was denn noch so in der SendQueue festhängt, diese Befehl macht es nun möglich.
Hier mal eine Beispiel Ausgabe eines wartenden Telegramms für einen Fensterkontakt:

Code Auswählen Erweitern

        Time        | Destination | Command        | CUL
--------------------+-------------+----------------+----
2020-01-10 19:43:20 | Test_FK     | AddLinkPartner | CUL
--------------------+-------------+----------------+----