Autor Thema: [CUL_HM] Probleme mit der vccu  (Gelesen 449 mal)

Offline frank

  • Hero Member
  • *****
  • Beiträge: 9266
[CUL_HM] Probleme mit der vccu
« am: 14 Juni 2020, 14:20:44 »
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.
« Letzte Änderung: 14 Juni 2020, 18:40:26 von frank »
FHEM: 6.0(SVN) => Pi3(stretch)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [hm.js]: https://forum.fhem.de/index.php/topic,106959.0.html