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

Begonnen von thburkhart, 17 Dezember 2019, 18:28:26

Vorheriges Thema - Nächstes Thema

thburkhart

Zitatkomm 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
1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200

Wzut

Zitat von: thburkhart am 30 September 2020, 17:17:33
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.   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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
1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200

JHo

Zitat von: thburkhart am 01 Oktober 2020, 17:41:57
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
1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120

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
8) Warten
9) warten
10) ggf. ab 7 wiederholen
11) im Erfolgsfall müssten die peerIDs sauber in den Readings angezeigt werden

1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200

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?
1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120

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 :)

Zitat von: thburkhart am 02 Oktober 2020, 12:00:00
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.

Zitat6) 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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

thburkhart

ZitatWorkaround :
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.
1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200

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:
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.

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

1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200

Wzut

Zitat2020-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 ....
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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?
1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200

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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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 ?
1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200

Wzut

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

Zitat von: Wzut am 11 März 2020, 12:57:59
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:
        Time        | Destination | Command        | CUL
--------------------+-------------+----------------+----
2020-01-10 19:43:20 | Test_FK     | AddLinkPartner | CUL
--------------------+-------------+----------------+----


Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher