HMCCU: Neue Version 4.2 mit neuem RPC Server verfügbar

[zap]

Hallo,

ich habe gerade die Version 4.2 eingecheckt.

Neu:

Mit dem Modul 88_HMCCURPCPROC steht nun ein Sub-Prozess basierter RPC Server zur Verfügung. Alle User, die aufgrund der Inkompatibilität von JSON mit Perl-Threads bzw. HMCCURPC Probleme haben, sollten auf HMCCURPCPROC umstellen. HMCCURPCPROC arbeitet problemlos mit JSON::XS zusammen. Zur Umstellung bitte so vorgehen:

• RPC Server stoppen
• Im Attribut ccuflags im I/O Device procrpc auswählen und extrpc/intrpc abwählen
• FHEM neu starten
• RPC Server aus dem I/O Device starten, sofern nicht Autostart eingestellt ist

Beim ersten Start des RPC Servers wird für jede im Attribut rpcinterfaces festgelegte Schnittstelle ein Device vom Typ HMCCURPCPROC definiert. Dabei werden die Attribute room und group des I/O Device übernommen. Ggf. bitte nach dem Start einmal die FHEM Config speichern.
Der neue RPC Server ist mindestens genauso schnell wie der bisherige externe (Reaktionszeit < 0,02 Sekunden). Es werden außer RPC::XML::Server/Client keine weiteren Module benötigt (ein niedrigerer Speicherverbrauch durch die Verwendung von fork() anstelle von Threads ist übrigens nicht feststellbar).

HMCCURPCPROC wird mit der nächsten Version sowohl den externen (HMCCURPC) als auch den internen RPC-Server ersetzen! Also bitte testen und Feedback geben, wenn Probleme auftreten!

Weitere Neuerungen Version 4.2:

• Unterstützung von Homematic Virtual Layer (Interface HVL), siehe auch https://homematic-forum.de/forum/viewtopic.php?f=44&t=33848
• Automatische Ermittlung der verfügbaren RPC Interfaces der CCU2
• Neuer Befehl set ackmessages zum Bestätigen von unreachable Meldungen in der CCU2
• Event Timeouts können mit dem Attribut rpcEventTimeout = 0 deaktiviert werden
• Der Befehl set datapoint erlaubt das Setzen mehrere Datenpunkte in einem Aufruf: dp1 value1 dp2 value2 ...
• Das Flag ackState im Attribut ccuflags ersetzt das Attribut ccuackstate
• Das Flag noReadings im Attribut ccuflags ersetzt das Attribut ccureadings im I/O Device

Folgende Fehler wurden behoben:

• Fehler beim Parsen von Adressen korrigiert
• Fehler bei Fehlerausgabe und Fehlerstatus korrigiert
• Fehler bei der Verarbeitung von RPC Events mit String Value korrigiert
• Fehler bei der Deregistrierung eines RPC Servers korrigiert
• Fehler bei einigen ccureadingfilter Parametern korrigiert

[Rewe2000]

Hallo zap,

habe eben von extrpc auf procrpc umgestellt (war nicht betroffen von JSON Problematik), alles läuft bestens, keine Probleme bei der Funktion feststellbar, Geschwindigkeit so wie gewohnt Pfeilschnell.

Ein Schönheitsfehler ist mir jedoch noch aufgefallen, bei mir steht das HMCCU Device ständig auf "running/Initialized" ich denke beim extrpc war es "running/OK".
Woran kann dies liegen, wo muss ich da noch etwas einstellen, oder was passt bei mir nicht?

Code Auswählen Erweitern

defmod CCU2 HMCCU 192.168.1.32 waitforccu=300
attr CCU2 DbLogExclude .*
attr CCU2 ccuflags procrpc
attr CCU2 cmdIcon on:general_an off:general_aus
attr CCU2 eventMap /rpcserver on:on/rpcserver off:off/
attr CCU2 icon hm_ccu
attr CCU2 room Homematic
attr CCU2 rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
attr CCU2 rpcport 2001,2010,9292
attr CCU2 rpcqueue /tmp/ccuqueue
attr CCU2 rpcserver on
attr CCU2 stateFormat rpcstate/state

setstate CCU2 running/Initialized
setstate CCU2 2018-01-30 20:39:45 Watchdog 0
setstate CCU2 2018-01-06 15:20:03 battery_count 56
setstate CCU2 2018-01-06 15:20:03 battery_list Batterien OK
setstate CCU2 2018-01-06 15:20:03 battery_match 0
setstate CCU2 2018-01-06 15:20:03 battery_state ok
setstate CCU2 2018-01-30 20:34:09 rpcstate running
setstate CCU2 2018-01-30 20:33:42 state Initialized

Alle 3 HMCCURPCPROC Device (CCU RPC BidCos-RF, CCU RPC HmIP-RF, CCU RPC VirtualDevices) wurden bei mir angelegt, diese stehen alle auf  "running/OK"

Im Log steht nur eine, für mich auffällige Meldung:

Code Auswählen Erweitern

2018.01.30 21:31:47 2: HMCCURPCPROC: [d_rpcVirtualDevices] Received no events from interface CB9292 for 600.038018941879 seconds

Auch ein Nestart von Fhem ändert an dem state Initialized nichts.

Nachtrag von Mittwoch 16:30 Uhr:
Wurde am pollen der CCU2 Systemvariablen etwas geändert?
Ich verwende eine CCU2 Systemvariable als Watchdog zur Kommunikationsüberwachung zu einer WAGO Steuerung (Modbus).
Die Variable wird in der HMCCU bei den Readings korrekt angezeigt und diese wechselt auch brav regelmäßig ihren Zustand, nur es wird kein Trigger mehr erzeugt (auch im Event Monitor nicht zu sehen). Hab schon mit event-on.... experimentiert, löst aber das Problem mit den fehlenden Trigger nicht.

Versuche ich die CCU2 Systemvariable über die Fhem Kommandozeile mit:

Code Auswählen Erweitern

get CCU2 vars Watchdog
von der CCU2 zu lesen, erhalte ich ein kleines leeres Fenster ohne jeden Inhalt aber auch keine Fehlermeldung.

Wenn nötig gerne mehr Infos von meiner Seite, wenn das Problem nicht nachvollziebar ist.
Danke für deine großartige Arbeit für die Homematic Fraktion!
Gruß Reinhard

[Jamo]

Ja, das habe ich auch. Ich habe von intrpc auf procrpc umgestellt, (war betroffen von JSON Problematik weil ich SONOS benutze, konnte also den extrpc nicht benutzen). Läuft prima bisher, gefühlt stabiler. Auch bei mir steht nach der Umstellung das HMCCU jetzt immer auf 'Initialized' (das 'running/Initialized' kommt vom stateformat (attr CCU2 stateFormat rpcstate/state)).

Aber ich denke das ist vielleicht nur ein Schönheitsfehler, weil die HMCCURPCPROC jetzt auf 'running/OK' stehen? Aber wäre eindeutiger wenn der HMCCU state auch 'OK' wäre wie vorher. Danke für die Arbeit, beste Grüsse!!

[Chris8888]

Hallo Zap,
gerade upgedatet und von ext auf proc umgestellt.
Läuft tadellos!

Superschnell und endlich ist auch mein Disconnect der Fhem-Webseite nach Veränderung eines HmIP-Devices weg.

Im Log ist alles sauber.

Klasse - wie immer!

Viele Grüße
Christian

[zap]

Da bin ich aber froh, dass es grundsätzlich läuft. Habe ziemlich viel umgebaut in der 4.2 und konnte leider nicht alles durchtesten.

Der Status running/initialized ist mir auch aufgefallen. Konnte es auf die schnelle nicht beheben. Werde es mir aber nochmal anschauen.

Events bei Systemvariablen: Das ist ein Bug. Korrektur ist in Arbeit.

[zap]

Die Version 4.2.001 behebt folgende Probleme:

- Kein Event nach Aktualisierung von CCU Systemvariablen mit dem Befehl "get vars"
- state des I/O Device bleibt auf "Initialized" stehen

Morgen per FHEM Update verfügbar.

[Rewe2000]

Hallo zap,

da freu ich mich ja auf Morgen, wenn mein Watchdog über die CCU2 wieder läuft. War aber nicht so eilig, da die Fenster im Gewächshaus derzeit eh nicht geöffnet werden.

Eines ist mir noch aufgefallen:
Wenn ich den RPCSERVER des HMCCU Device mit "set CCU2 rpcserver off" beenden will, bekomme ich auf der Fhem Oberfläche die Meldung "HMCCU: CCU2 Usage: set CCU2 rpcserver {'on'|'off'|'restart'}" angezeigt. Die gleiche Meldung kommt auch beim Start.
Hab auch mal "set CCU2 rpcserver {'on'}" versucht, klappt aber auch nicht.
Nur das starten und beenden über die "cmdIcons" klappt bei mir Problemlos.

Feature oder Schönheitsfehler?

HMCCURPCPROC schnurrt bei mir, mit Ausnahme der beschriebenen Abweichungen, wie ein Kätzchen!
Ich bin immer noch über die sehr schnellen Reaktionszeiten begeistert (war ja bereits seit extrpc so).

Gruß Reinhard

[zap]

Das Problem mit "set rpcserver on/off" kann ich bestätigen. Das liegt am Attribut eventMap. Das macht aus einem

set rpcserver on

ein

set rpcserver rpcserver on

Die Ersetzung bei eventMap funktioniert also in beide Richtungen. Das wusste ich nicht. Mal sehen, wie ich das behebe.

Update: Fehler behoben. Kann es aber erst morgen einchecken. Bis dahin

set on
set off

oder cmdIcons

[Rewe2000]

Hallo zap,

die Anzeige vom Status des Device "HMCCU" passt nun, es wird "running/OK" (state OK) angezeigt.
Auch das get vars klappt wieder so wie es sein soll.

Leider klappt der start/stopp des rpcservers bei mir nicht über "set CCU2 rpcserver on", "set CCU2 on" und auch nicht über die Auswahlfelder neben dem set Befehl über die Oberfläche des Device.
Start/Stop ist bei mir (derzeit) nur über die Buttons "eventMap" und "cmdIcon" möglich.
Sollten die Änderungen hierzu schon in 4.2.001 enthalten sein?

Klär mich doch bitte mal auf, weshalb im Log (Verbose 3) bei mir alle 10 Minuten die Meldungen kommen:

Code Auswählen Erweitern

2018.02.02 16:52:15 2: HMCCURPCPROC: [d_rpcVirtualDevices] Received no events from interface CB9292 for 600.123554944992 seconds

Wurden die Meldungen in der Version vor HMCCURPCPROC nicht angezeigt, denn ich habe unter rpcport, gegenüber früher nichts geändert. So wie ich es sehe, kann ich bei mir den rpcport 9292 komplett löschen, wenn ich keine virtuellen Devices in der CCU2 verwende.

Sehe ich das richtig oder bringe ich da etwas durcheinander?


Grundsätzlich läuft aber alles andere sehr stabil.

Gruß Reinhard

[zap]

In der 4.2.001 ist das set rpcserver on/off noch nicht gefixt. Es ist auch nicht wirklich ein Bug sondern liegt am Attribut eventMap. Wenn du das löschst, gehen zwar die CmdIcons nicht mehr, dafür aber der set rpcserver Befehl.

Aber wie gesagt, mit 4.2.002 wird beides gehen. Habe aber noch einen anderen Bug gefunden. Den fixe ich erst, bevor ich es einchecke.

Die Fehlermeldung im Log kannst Du vermeiden, indem du das Attribut rpcEventTimeout auf 0 setzt (im entsprechenden HMCCURPCPROC Device). Oder du setzt das Attribut auf einen entsprechend hohen Wert. Default ist 600.

Hintergrund: wenn für die angegebene Zeitspanne kein Event kommt und ccuflags auf reconnect steht, registriert sich der RPC Server automatisch neu. Damit kann ein Verbindungsabbruch zur CCU zB bei einem Restart der CCU automatisch behoben werden.

[Ralli]

Hallo zap,

hast du das Attribut jetzt pro RPC-Server implementiert? Das wäre sinnvoll.

[kjmEjfu]

hab heute nach einem FHEM-Restart folgendes in der Motd stehen:

Code Auswählen Erweitern

configfile: d_ccu: unknown attribute ccureadings

[zap]

@Ralli: ja, die RPC Server Attribute sind für die HMCCURPCPROC Devices auch direkt am Device angelegt. Die mehr oder weniger gleichnamigen Attribute in HMCCU gelten nur für den internen RPC Server. Der wird aber demnächst sowieso aus dem Modul verschwinden.

@kjmEjfu: das Attribut ccureadings gibt es nicht mehr im HMCCU Device. Da war der Default sowieso 1 (Readings schreiben). Wenn man im IO Device keine Readings haben möchte, setzt man im Attribut ccuflags die Option ,,noReadings". Sorry, hatte ich im Changelog vergessen zu erwähnen.
Nach dem Starten einmal FHEM Config speichern, dann ist das Attribut raus aus der Config.

[Mave]

Moin zap,

ich nutze bisher den externen RPC.
Muss ich auf den neuen RPC umstellen?

Vielen Dank.

Grüße Mave

[zap]

Moin zap,

ich nutze bisher den externen RPC.
Muss ich auf den neuen RPC umstellen?

Wenn du keine Probleme mit Modulen hast, die JSON verwenden, erst mal nicht. Mit der nächsten HMCCU Version passiert die Umstellung automatisch, d.h. beim ersten Start wird HMCCU dann HMCCURPCPROC Devices anlegen. So der Plan. Wahrscheinlich aber erst irgendwann im März.