es gibt ein massives problem mit der io zuteilung nach einem fhem restart.
das wiederum macht probleme beim abarbeiten der queue von statusrequest-wakeup meiner thermostate nach fhem restart. nach 12 std warten noch 5 von 9 thermostate auf den statusrequest:
status request wakeup: Thermostat.AZ Thermostat.Bad Thermostat.Bad.OG Thermostat.GZ Thermostat.SZ
das problem ist folgendes:
die vccu verwaltet 4 io von denen normalerweise 2 nicht verfügbar sind.
nur hmlan1 und cul868 sind zur zeit verfügbar:
2020-06-14 00:37:20 state hmuart1:disconnected,hmlan1:ok,hmusb1:dummy,cul868:ok
Attributes:
.mId FFF0
IODev hmlan1
IOList hmuart1,hmlan1,hmusb1,cul868
IOgrp ccu:hmlan1
12 std nach restart sieht die zuteilung der thermostate wie folgt aus. dabei ist jeweils das erste IODev aus den internals und das 2. ist das attr IODev.
die tabelle zeigt deutlich, dass allen thermostaten, die noch in der queue fest hängen, ein nicht funktionierendes io zugeteilt wurde.
list Thermostat.*:FILTER=DEF=...... i:IODev i:LASTInputDev a:IODev a:IOgrp
Thermostat.AZ IODev hmusb1
LASTInputDev hmlan1
IODev hmusb1
IOgrp ccu:hmlan1,hmuart1
Thermostat.Bad IODev hmusb1
LASTInputDev hmlan1
IODev hmusb1
IOgrp ccu:hmuart1
Thermostat.Bad.OG IODev hmusb1
LASTInputDev hmlan1
IODev hmusb1
IOgrp ccu:hmuart1
Thermostat.GZ IODev hmusb1
LASTInputDev hmlan1
IODev hmusb1
IOgrp ccu:hmuart1
Thermostat.Keller IODev hmlan1
LASTInputDev hmlan1
IODev hmlan1
IOgrp ccu:hmlan1
Thermostat.Kueche IODev hmlan1
LASTInputDev hmlan1
IODev hmlan1
IOgrp ccu:hmuart1
Thermostat.OZ IODev cul868
LASTInputDev hmlan1
IODev hmlan1
IOgrp ccu:cul868
Thermostat.SZ IODev hmusb1
LASTInputDev hmlan1
IODev hmusb1
IOgrp ccu:hmuart1
Thermostat.WZ IODev hmlan1
LASTInputDev hmlan1
IODev hmlan1
IOgrp ccu:hmlan1
1. nach restart nutzen (iodev internal) die thermostate das io welches im attribut IODev steht.
das ist doch aber völlig falsch. dadurch wurde bei 5 von 9 thermostaten das io hmusb zugewiesen, welches schon seit jahren auf attr dummy steht.
a. bei keinem attr IOgrp ist hmusb vorhanden.
b. wie kommt der hmusb in das attr IODev?
das stammt noch aus der zeit von vor ca 4 jahren, als mein fhem auf der fritzbox lief und der hmusb an der fritzbox steckte.
beim umzug auf den pi habe ich lediglich die prefered io angepasst und das hmusb device auf dummy gesetzt.
attr IODev verwaltet ja die vccu. denkste.
c. attr IODev soll man nicht mehr anfassen, aber die vccu scheint es nicht mehr zusetzen.
d. früher wurde das attr IODev von der vccu entsprechend gesetzt, so dass internal und attribut IODev immer synchron waren.
eigentlich waren es sogar 6 von 9 thermostate mit zugewiesenem hmusb.
beim Thermostat.WZ habe ich manuell attr IODev von hmusb1 auf hmlan1 geändert, wodurch das thermostat umgehend den automatischen statusrequest erhalten hat und aus der queue entfernt wurde.
2. warum merkt die vccu nicht irgendwann, dass ein nicht funktionierendes io zugewiesen wurde?
da ich schon gesehen habe, dass die request-wakeup queue leer war, muss es doch einen mechanismus geben, der diese dead loop grundsätzlich auflösst. aber wie gesagt, nach 12 std jedenfalls noch nicht.
ich denke, ich weiss jetzt, was diese blockade grundsätzlich aufgelöst hat: das muss der tägliche timeSync gewesen sein, wodurch dann die vccu ein brauchbares io zugewiesen hat.
3. warum wird nicht einfach ein statusrequest in die cmd-queue der thermostate geworfen?
dadurch würde wahrscheinlich eine io prüfung beim senden durchgeführt werden.
zur zeit wird kein statusreques gestartet, da kein "funktionierendes" io zugeteilt wurde, aber eine prüfung erfolgt auch nicht, da kein cmd gesendet wird. also eine dead loop.