HMCCU: Version 4.3 verfügbar

[zap]

Das Problem liegt irgendwo im veränderten internen Handling von Rückgabewerten im Modul.

Ich verstehe nicht, welche Rückgabewerte du meinst. Die Rückgabe von set Befehlen?

[Ralli]

Seit dem Update (nach 07.09.) tritt folgendes Problem auf:

Zunächst prüft meine Routine in RolloSet (nicht in GenRolloSet), ob wirklich was getan werden muss (also ob der zu setzende Wert sich vom tatsächlichen unterscheidet) und ruft nur dann (!) den eigentlichen Befehl fhem("set $ROLLO $WERT") auf. Muss nichts getan werden, wird die Routine RolloSet stattdessen wieder verlassen und bei Aufruf aus GenRolloSet heraus diese Routine normal abgearbeitet. Wird aber der eigentliche Befehl abgesetzt - und somit in das Modul HMCCU gesprungen, scheint HMCCU nun nach Ausführung etwas zurückzugeben, womit die Listenabarbeitung von @LISTE in GenRolloSet sofort mit dem nächsten kommaseparierten Wert fortgesetzt wird, statt die weiteren Bedingungsabfragen bis zur schließenden geschweiften Klammer noch abzuarbeiten.

Ich habe das tatsächlich akribisch nachvollzogen, nur wenn ich die HMCCU-Dateien auf aktuellen Stand bringe, passiert das, mit allen anderen erneuerten Modulen/Dateien gibt es diese Problematik nicht.

Ich könnte noch probieren, die HMCCU-Dateien einzeln auf neuem Stand einzubinden, um noch näher einzugrenzen, oder geht das sowieso in die Hose, weil die Dateien jeweils versionsmäßig voneinander abhängig sind?

[raimundl]

Das Verhalten als Schalter ist klar. Bei den Thermostaten ist "on" als 30.5 Grad und "off" als 4.5 Grad definiert.

Vermutlich musst Du den richtigen genericDeviceType einstellen und/oder das homebridge mapping anpassen.

Außerdem ist es vermutlich hilfreich, über eventMap einige Befehle zu definieren wie z.B. desired-temp

Aber da bin ich überfragt. Vielleicht stellst Du die Frage nochmal im "Sprachsteuerung" Forum.

Nach vielen probieren (auch lernen) funktioniert es nun - HM-Thermostat über HMCCU und "alexa" mit Temperaturansage und Steuerung der Heizungstemperatur (desired-temp):
list (teilweise gekürzt):

Code Auswählen Erweitern

Internals:
   STATE      Initialized
   TYPE       HMCCUDEV
   ccuaddr    NEQ1521
   ccudevstate active
   ccuif      BidCos-RF
   ccuname    TH_Schlafzimmer
   ccutype    HM-TC-IT-WM-W-EU
   channels   6
   firmware   1.3
   statevals  devstate
READINGS:
     2018-11-01 10:31:09   control         18.0
     2018-11-01 10:31:09   desired-temp    18.0
     2018-11-01 10:31:09   hmstate         Initialized
     2018-10-30 20:14:49   state           Initialized
     2018-11-01 10:28:54   temperature     21.1
Attributes:
   IODev      CCU3
   alexaName  Schlafbereich
   ccureadingfilter (^TEMPERATURE|^SET_TEMPERATURE)
   ccureadingname 1.TEMPERATURE:temperature;2.SET_TEMPERATURE:desired-temp
   controldatapoint 2.SET_TEMPERATURE
   event-on-change-reading .*
   eventMap   control:desired-temp
   genericDeviceType thermostat
   room       alexa
   stripnumber 1
   webCmd     desired-temp
   widgetOverride desired-temp:slider,10,1,25

@zap:

Bitte prüfen, ob obige Einstellungen, die zwar funktionieren, optimal sind.

Danke und LG

[zap]

Seit dem Update (nach 07.09.) tritt folgendes Problem auf:

Zunächst prüft meine Routine in RolloSet (nicht in GenRolloSet), ob wirklich was getan werden muss (also ob der zu setzende Wert sich vom tatsächlichen unterscheidet) und ruft nur dann (!) den eigentlichen Befehl fhem("set $ROLLO $WERT") auf. Muss nichts getan werden, wird die Routine RolloSet stattdessen wieder verlassen und bei Aufruf aus GenRolloSet heraus diese Routine normal abgearbeitet. Wird aber der eigentliche Befehl abgesetzt - und somit in das Modul HMCCU gesprungen, scheint HMCCU nun nach Ausführung etwas zurückzugeben, womit die Listenabarbeitung von @LISTE in GenRolloSet sofort mit dem nächsten kommaseparierten Wert fortgesetzt wird, statt die weiteren Bedingungsabfragen bis zur schließenden geschweiften Klammer noch abzuarbeiten.

Ich habe das tatsächlich akribisch nachvollzogen, nur wenn ich die HMCCU-Dateien auf aktuellen Stand bringe, passiert das, mit allen anderen erneuerten Modulen/Dateien gibt es diese Problematik nicht.

Ich könnte noch probieren, die HMCCU-Dateien einzeln auf neuem Stand einzubinden, um noch näher einzugrenzen, oder geht das sowieso in die Hose, weil die Dateien jeweils versionsmäßig voneinander abhängig sind?

Unterschiedliche Versionen der Module zu verwenden ist keine gute Idee. So wie ich das sehe, wertet Deine Schleife den Rückgabewert des Set Befehls gar nicht aus. Möglicherweise ändern sich aber andere Werte, die in den if Abfragen verwendet werden.

Schick mir mal bitte den kompletten Code (gerne per Mail), also von GenRolloSet und RolloSet

[gloob]

Können eigentlich 2 FHEM Instanzen parallel auf eine CCU zugreifen, Werte auslesen und Parameter setzen?

[zap]

Können eigentlich 2 FHEM Instanzen parallel auf eine CCU zugreifen, Werte auslesen und Parameter setzen?

Klar, kein Problem, sofern die FHEMs auf unterschiedlichen Rechner laufen.

Wenn Du eine CCU2 verwendest, dürfte es irgendwann mal Performance Probleme geben, wenn sich zu viele RPC Server registrieren. Zu meiner CCU3 sind derzeit 2 FHEMs und 1 ioBroker verbunden mit jeweils 4 RPC Servern. Läuft stabil und schnell.

[Ralli]

Schick mir mal bitte den kompletten Code (gerne per Mail), also von GenRolloSet und RolloSet

Sehr gerne. Schickst du mir mal deine Email per PN?

[jsChris]

Hi,

nach Problemen habe ich meine CCU3 auf 3.41.7 updated. Leider kann sich nun der/die RPC Server der HMCCU nicht mehr mit der CCU verbinden. Die neuen Firewalleinstellungen habe ich mal sehr offen gestaltet:

Ports offen, die APIs jedoch eingeschränkt und die IP meines FHEM Servers eingetragen (wie bisher). Ich habe aber auch mal versuchsweise alles auf Vollzugriff gestellt. Bei Sicherheit ist die die "Authentifizierung" aus.

Die Ausgaben im Log sind leider nicht so hilfreich:
2018.11.02 00:14:28 1: HMCCU: [ccu3] No RPC device defined for interface BidCos-RF
2018.11.02 00:14:28 1: HMCCU: [ccu3] Creating new RPC device d_rpcBidCos_RF
2018.11.02 00:14:28 1: HMCCU: [ccu3] Definition of RPC device failed.
2018.11.02 00:14:28 1: HMCCU: [ccu3] d_rpcBidCos_RF already defined, delete it first
2018.11.02 00:14:28 0: HMCCU: [ccu3] Definition of some RPC devices failed
2018.11.02 00:14:28 1: HMCCU: ccu3 Start of RPC server failed

Vielleicht hat jemand eine Idee, was hier falsch läuft?

Danke
Chris

[Jamo]

Bei mir das gleiche problem, nach update auf 3.41.7 laufen die RPC server nicht mehr. Gleiche Fehlermeldungen... In der CCU3 habe ich auch alles auf gemacht, und auch Port 2001 geoeffnet
Zusaetzlich:

HMCCU: Illegal RPC port 2001
2018.11.02 00:38:25 1: PERL WARNING: Argument "Can't connect to CCU 172.21.0.16 port 32001" isn't numeric in numeric eq (==) at ./FHEM/88_HMCCURPCPROC.pm line 291, <$fh> line 6345.

[zap]

hmm, meine CCU hat gestern gar nicht auf eine neue Version hingewiesen. Möglicherweise hat EQ-3 da etwas an den Schnittstellen Spezifikationen geändert.

wie auch immer: als Sofortmaßnahme rate ich, das Backup von vor dem Software Update einzuspielen, bis ich Zeit finde, mich damit zu befassen.

[jsChris]

Vielen Dank für die schnelle Antwort. Das habe ich schon probiert. Aber vielleicht mache ich auch etwas falsch?

Sobald ich die Firmware ccu3-3.37.8 wieder einspiele, stürzt BidCos-RF ab, "Eine Komponente (BidCos-RF) ist nicht mehr erreichbar..." poppt auf. Allerdings habe ich dann nicht noch mal das Sys-Backup eingespielt, das ich vor dem Update gemacht habe. Die Log-Zeile zum Absturz habe ich mir leider nicht nicht gemerkt, aber ich weiß noch, dass da "irgendetwas mit Java" stand. Daraufhin habe ich geschlossen, dass vielleicht auch andere Systemkomponenten auf der CCU updated wurden, die nicht mehr mit ccu3-3.37.8 kompatibel sind.

Aber ich kenne mich auch viel zu wenig mit der CCU aus. @inoma: konntest du die CCU zurücksetzen? Gibt es noch etwas, das ich unternehmen kann?

Im Changelog zu 3.41.7 stehen leider keine Details, nur

ACHTUNG: Dieses Update enthält relevante Anpassungen der Sicherheitseinstellungen. Diese können sich auf die Funktionen von Zusatzsoftware auswirken. Darunter fallen erweiterte Firewalleinstellungen und die obligatorische Vergabe eines Anmeldepassworts.
Erstellen Sie ein Backup der Zentrale, bevor Sie dieses Update installieren!
[HMCCU3-1860] - Integration HmIP-RCB1 (Homematic IP Fernbedienung mit Montagegurt – 1-Kanal) [HMCCU3-1750] - Integration HmIP-FCI1 (Homematic IP Kontakt-Schnittstelle Unterputz – 1-fach) [HMCCU3-1718] - Integration HmIP-eTRV-C (Homematic IP Heizkörperthermostat – kompakt) [HMCCU3-1383] - Integration HmIP-MP3P (Homematic IP MP3 Kombisignalgeber)
Erweiterungen / Verbesserungen zur CCU3
[HMCCU3-1653] - Einrichtungswizard bei Erstinbetriebnahme
Nach der Installation dieses Updates
 wird jeder Benutzer ohne Passwort aufgefordert, ein Passwort zu vergeben.
 wird ein Administrator zur Überprüfung der Sicherheitseinstellungen aufgefordert.
Das Blinken der Info LED bei Service- u. Alarmmeldungen kann deaktiviert werden. (Einstellung unter Systemsteuerung/Allgemeine Einstellungen)
(https://www.eq-3.de/Downloads/Software/CCU3-Firmware/CCU3-3.41.7/CCU3-Changelog.3.41.7.pdf)

[zap]

die ältere Version über die neue zu installieren war jetzt keine gute Idee. immer einfach das Backup zurück spielen und alles ist wieder wie zuvor

[jsChris]

Ah, ok, danke für den Hinweis. Dann habe ich es jetzt wohl verbockt. Auf jeden Fall bringt es nichts das System-Backup unter 3.41.7 wieder einzuspielen.

Nicht so wild, die CCU ist neu, und steuert zur Zeit nur unsere Rollos, das kann ich auch erst einmal mit einem Homematic Schalter, statt der TabletUI, steuern.

[Ralli]

Hier stehen ein paar mehr Hintergründe zu den Änderungen, die sich wahrscheinlich auch auf den hiesigen RPC-Server-Connect auswirken:

https://homematic-forum.de/forum/viewtopic.php?p=465022#p465022

[Jamo]

Es gibt jetzt auch die XML-RPC Spezifikation zum download:
https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HM_XmlRpc_API.pdf