HMCCU: Version 4.3 verfügbar

Begonnen von zap, 11 September 2018, 10:40:03

Vorheriges Thema - Nächstes Thema

zap

Ich habe gerade die Version 4.3 von HMCCU eingecheckt. Dürfte ab morgen per FHEM Update ausgeliefert werden.

Achtung: Benutzer von HMCCURPC (Attribut ccuflags im I/O Device = extrpc) unbedingt vor dem Update lesen:

Die Version 4.3 unterstützt nicht mehr den Thread basierten RPC Server (Modul HMCCURPC). Die Umstellung auf den Prozess basierten RPC Server (Modul HMCCURPCPROC) erfolgt automatisch beim Neustart von FHEM bzw. des RPC Servers. Um eventuelle Probleme zu minimieren, empfehle ich folgende Vorgehensweise:

  • RPC Server stoppen
  • Device vom Typ HMCCURPC aus FHEM löschen
  • Attribut ccuflags im I/O Device auf procrpc setzen
  • FHEM Update durchführen
  • FHEM neu starten

Beim ersten Start des RPC-Servers wird für jedes genutzte CCU Interface (z.B. BidCos-RF, Hm-IP) ein separates Device vom Typ HMCCURPCPROC angelegt und das Attribut room des I/O Device übernommen. Die einzelnen RPC-Server werden wie bisher über den Befehl 'set rpcserver on/off' im I/O Device gestartet oder gestoppt.

Der interne RPC-Server (Attribut ccuflags im I/O Device = intrpc oder leer) wird noch bis Version 4.4 unterstützt. Ich empfehle trotzdem, schon jetzt auf procrpc zu wechseln. Vorgehen dafür wie oben beschrieben.

Neu in Version 4.3

  • Die CCU3 wird uneingeschränkt unterstützt
  • RPC Server vom Typ 'extrpc' (HMCCURPC) wird nicht mehr unterstützt. Das Flag 'extrpc' entspricht 'procrpc'.
  • Verzögerte Initialisierung von Devices, wenn beim Start von FHEM die CCU nicht verfügbar ist (mehr Infos s. weiter unten)
  • Beim Start werden die Definitionen virtueller Gerätegruppen aus der CCU ermittelt. Dadurch ist die Angabe der einzelnen Gruppendevices bei der Definition mit 'group=' nun optional.
  • Beim Start werden die verfügbaren Programme aus der CCU ermittelt und stehen dann beim Befehl 'set execute' im I/O Device als Auswahlliste zur Verfügung
  • Neue Readings im I/O Device mit Countern für Anzahl Devices, Channels, Interfaces, Programs, Groups
  • Das Attribut 'stripnumber=0' schneidet alle Nachkommastellen eines Readings ab.
  • Der Befehl 'set register' im Modul HMCCURPCPROC registriert den RPC-Server erneut bei der CCU.

Behobene Fehler in Version 4.3

  • CCU Script Befehle werden nun URL kodiert an die CCU geschickt
  • Sporadisch auftretender Fehler bei der Zuordnung des I/O Device wurde per fhem.pl Update behoben.
  • Das Auslesen von CCU Geräten ignoriert nun verwaiste Objekte.
  • Mögliche Divsion durch Null bei der Berechnung des Taupunktes wird nun abgefangen.
  • Fehler bei RPC-Events vom Typ 'UpdateDevice' behoben.

Verzögerte Initialisierung von Devices

Wenn zB nach einem Stromausfall sowohl FHEM als auch die CCU neu gestartet werden, kam es bisher zu Problemen beim FHEM-Start, da die CCU deutlich mehr Zeit für den Start benötigt. In Version 4.3 werden nun die Geräte vom Typ HMCCUCHN und HMCCUDEV in diesem Fall später initialisiert. Solange keine Initialisierung erfolgt ist, haben die Geräte den Status 'pending' und können nicht per Set- oder Get-Befehl angesprochen werden. Die RPC-Server werden in diesem Fall ebenfalls verzögert gestartet. Der FHEM-Start wird durch diese Mechanismen nicht verzögert oder blockiert.

Für die Steuerung der verzögerten Initialisierung gibt es 2 Attribute:

  • ccudelay - Legt fest, wie lange mit der Initialisierung gewartet wird, wenn die CCU beim Start von FHEM nicht erreichbar war. Vorgabe sind 180 Sekunden.
  • delayedinit - Erzwingt die verzögerte Initialisierung nach der angegebenen Anzahl Sekunden, unabhängig davon, ob die CCU erreichbar ist oder nicht.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

daelch

Vielen Dank für Deine Mühen. Ich werde am Wochenende das Update machen.

Skjall

Danke für die Infos. Ich war nach dem Update schon verwundert, dass es nicht ging.
Seltsamerweise musste ich meinen Server komplett durchstarten. Läuft aber wieder.

VG Jan

Volker!

Vielen Dank für die neue Version.
ich habe gleich einmal mit der neuen CCU3 getestet. Ich hatte vorher noch keine CCU eingebunden. Nach dem definieren der CCU habe ich fhem mit "shutdown restart" versucht neu zu starten.
Hat leider nicht geklappt fhem war nicht mehr erreichbar. Manualles starten von fhem in der console funktioniert.

Folgenden Eintrag finde ich im fhem-Logfile ...
Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE extrpc|procrpc/ at ./FHEM/88_HMCCU.pm line 5107.

Vielleicht fällt dir etwas dazu ein.
Falls du noch Infos brauchst gib bitte Bescheid.

zap

#4
Das ist ein Bug.

Update habe ich gerade eingecheckt. Wer nicht bis morgen warten möchte, lädt direkt die 88_HMCCU.pm aus dem SVN runter und installiert die Datei im FHEM-Modulverzeichnis.

Sorry für den Stress. Ich fahre FHEM immer per Script runter. Dabei wird die Shutdown Funktion nicht aufgerufen. Daher habe ich den Fehler nicht bemerkt.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

peter_ul

Habe soeben die neue Version bei einem Update von Fhem installiert und bekomme nun ca. 20 Perl-Warnungen im Logfile:


2018.09.14 09:03:27 1: PERL WARNING: Use of uninitialized value $ccutype in pattern match (m//) at ./FHEM/88_HMCCU.pm line 948, <$fh> line 127.


Die Geräte funktionieren alle einwandfrei. Gibt es hier ggf. eine Einstellung die bei mir noch fehlt?

Viele Grüße
Peter

tatu123

#6
Hallo zusammen,

Version 4.3.001 funktioniert der shutdown von fhem wieder tadellos.  Danke für die schnelle Reaktion.

Bei mir sind weiterhin keine Fehler oder Warnungen im Log.

Technische Date:
fhem - procrpc - ccu2

Dafür habe ich mit meinen HMIP-FROLL jetzt Probleme.

An der Einrichtung wurde zur vorhergehenden HMCCU-Version nichts verändert. Jetzt kommt bei jedem "Fahrbefehl" für das Rolle


HMCCUDEV: d_roll_o Execution of CCU script or command failed


Das Rollo fährt er jedoch. Mir ist jetzt aufgefallen das jedoch KEIN Reading aktualisiert wird. Die Readings stehen unverändert seit dem Neustart von fhem.
Ein Neustart von fhem aktualisiert die Readings dann wieder.

Dieser Fehler kommt nur bei meinen HMIP bei z.B. HM-CC-RT-DN oder HM-TC-IT-WM-W-EU gibt es das Problem nicht.

Hier die Definition des HMIP-FROLL


defmod d_roll_o HMCCUDEV HmIP-FROLL-o
attr d_roll_o IODev d_ccu
attr d_roll_o ccureadingfilter (LEVEL|PROCESS|SECTION|PRESS)
attr d_roll_o ccuscaleval LEVEL:0:1:0:100
attr d_roll_o cmdIcon up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down sonne:fts_shutter_70 nacht:fts_shutter_80
attr d_roll_o controldatapoint 4.LEVEL
attr d_roll_o event-on-change-reading PRESS.*
attr d_roll_o event-on-update-reading .*
attr d_roll_o eventMap /datapoint 4.STOP true:stop/datapoint 4.LEVEL 0:down/datapoint 4.LEVEL 100:up/datapoint 4.LEVEL 35:sonne/datapoint 4.LEVEL 10:nacht/
attr d_roll_o room all,o
attr d_roll_o stateFormat { my $l = ReadingsVal ($name, "3.LEVEL", "na");;;; sprintf "%s", $l =~ /^(open|closed|na)$/ ? "$l" : "$l %";;;; }
attr d_roll_o statedatapoint 3.LEVEL
attr d_roll_o stripnumber 1
attr d_roll_o substexcl control
attr d_roll_o webCmd control:up:stop:down:sonne:nacht
attr d_roll_o widgetOverride control:slider,0,10,100


Nachtrag

Ich hab gerade auf dem Device noch einen "ccuflags trace" mit "verbose 5" gemacht. Hier die Meldungen:


2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=ON_TIME
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=LEVEL
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=ON_TIME
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=LEVEL
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=ON_TIME
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=LEVEL
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=ON_TIME
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=LEVEL
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=ON_TIME
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:29 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=LEVEL
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=ON_TIME
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=LEVEL
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=ON_TIME
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=LEVEL
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=ON_TIME
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=LEVEL
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=ON_TIME
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=LEVEL
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=ON_TIME
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: 3 is a channel number
2018.09.14 13:03:41 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=3, dpt=LEVEL
2018.09.14 13:03:51 2: HMCCUDEV: IsValidDatapoint: 4 is a channel number
2018.09.14 13:03:51 2: HMCCUDEV: IsValidDatapoint: devtype=HmIP-FROLL, chnno=4, dpt=LEVEL
2018.09.14 13:03:51 2: HMCCUDEV: SetDatapoint: param=HmIP-RF.001158A98B293D:4.LEVEL, value=10
2018.09.14 13:03:55 2: HMCCUDEV: SetDatapoint: Addr=001158A98B293D:4 Name=HmIP-FROLL 001158A98B293D:4
2018.09.14 13:03:55 2: HMCCUDEV: SetDatapoint: Script response =
undef
2018.09.14 13:03:55 2: HMCCUDEV: SetDatapoint: Script =
(datapoints.Get("HmIP-RF.001158A98B293D:4.LEVEL")).State(0.1)
2018.09.14 13:03:55 1: HMCCUDEV: d_roll_o Execution of CCU script or command failed

Jamo

#7
Mir ist jetzt aufgefallen das jedoch KEIN Reading aktualisiert wird. Die Readings stehen unverändert seit dem Neustart von fhem.
Das Problem hatte ich auch am Anfang, über etwa 2 Tage. Die Readings aller meiner HM-IP Devices wurden nur 1x am Anfang beim Neustart von FHEM (oder beim neustart der RPC-Server/HMCCU) aktualisiert. Erst ein mehrmaliges abwechselndes 'reboot' von FHEM und der CCU3 hat dann irgendwann geholfen, ich glaube nach dem letztmaligen Reboot der CCU3 ging es dann, seitdem läuft es stabil.

User "Skjall" hat weiter oben auch gemeldet, das er seinen Server komplett neu durchstarten musste, damit alles wieder läuft
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

tatu123

Ok Danke für den Hinweis. Werde mal alles neu starten.

Wunderlich ist nur das jetzige Problem hatte ich bis jetzt noch nie.
mit Version 4.2. hat das immer ohne jegliche Probleme getan.

Grüße

zap

#9
Zitat von: peter_ul am 14 September 2018, 09:11:30
Habe soeben die neue Version bei einem Update von Fhem installiert und bekomme nun ca. 20 Perl-Warnungen im Logfile:


2018.09.14 09:03:27 1: PERL WARNING: Use of uninitialized value $ccutype in pattern match (m//) at ./FHEM/88_HMCCU.pm line 948, <$fh> line 127.



Ein Bug. Zum Glück, sonst wären alle Deine Attribute überbügelt worden ;-)

Update für HMCCUCHN und HMCCUDEV ist im SVN eingecheckt.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

zap

Zitat von: tatu123 am 14 September 2018, 14:29:49
Ok Danke für den Hinweis. Werde mal alles neu starten.

Wunderlich ist nur das jetzige Problem hatte ich bis jetzt noch nie.
mit Version 4.2. hat das immer ohne jegliche Probleme getan.

Grüße

Hast Du mit der Version 4.2 den HMCCURPC verwendet (ccuflags = extrpc)?

Bei der automatischen Umstellung von extrpc auf procrpc kann es Probleme geben, insbesondere wenn nach dem Update FHEM mit "shutdown restart" neu gestartet wird. Hintergrund: Bei shutdown restart kann es sein, dass die RPC Server nicht beendet sind, wenn FHEM wieder startet. Daher ist es besser, bei Umstellung von extrpc auf procrpc FHEM erst mal anzuhalten, dann zu prüfen, ob auch alle Prozesse weg sind und dann FHEM wieder starten. Im Zweifel Rechner neu starten.

Diejenigen, die bereits mit 4.2 auf procrpc waren, sollten davon nicht betroffen sein.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

tatu123

Zitat von: zap am 14 September 2018, 14:54:48
Hast Du mit der Version 4.2 den HMCCURPC verwendet (ccuflags = extrpc)?

Diejenigen, die bereits mit 4.2 auf procrpc waren, sollten davon nicht betroffen sein.

Nein habe schon seit geraumer Zeit procrpc benutzt.

Jetzt habe ich alles neugestartet und der Fehler ist weg. Also alles wie immer "jeder Boot tut gut".

Danke für die Bemühungen. Werde weiter beobachten.


zap

Wie gesagt, kritisch ist shutdown restart. FHEM startet so schnell neu, dass u.U. einer der RPC Subprozesse seinen Port noch nicht freigegeben hat. Dann kommt es beim Neustart zu Problemen. Das gleiche Phänomen habe ich schon bei Sonos und shutdown restart beobachtet. Äußert sich meist mit einer Port in use Meldung im Logfile.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Tresuno

Das selbe Problem habe ich auch.
Zudem beobachte ich, dass das laden vom default settings bei diversen Geräten zu einem Fehler führt.
Das restart Problem tritt bei mir auch noch auf

LG tresuno

zap

Zitat von: Tresuno am 14 September 2018, 20:18:30
Das selbe Problem habe ich auch.
Zudem beobachte ich, dass das laden vom default settings bei diversen Geräten zu einem Fehler führt.
Das restart Problem tritt bei mir auch noch auf

LG tresuno

Welches restart Problem jetzt? Das Problem, das FHEM bei shutdown restart abschmiert, wurde mit 4.3.001 behoben. Das Problem mit Meldungen wie Port in use ist komplizierter ...

Das Problem mit den Defaults tritt auf, wenn man beim Define eines device die Option ,,defaults" angibt. Das behebt das Update, das morgen per update Befehl eingespielt werden kann.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB