Neues Modul HMCCU für Homematic CCU

[zap]

@cho: sieht schon mal gut aus. D.h. wenn Du den RPC Server aus FHEM heraus startest läuft er und Readings werden regelmäßig aktualisiert (bitte melden, wenn ich das falsch interpretiert habe).

Nächster Test:

- Bitte die FHEM-Config mit rpcserver=on speichern. Dann FHEM beenden mit /etc/init.d/fhem stop.
- Prüfen, dass der RPC-Server nicht mehr läuft mit "ps ax | grep ccurpcd"
- FHEM starten: /etc/init.d/fhem start => RPC-Server muss mit gestartet werden
- FHEM Logfile und ccurpcd Logfile prüfen, ob es so aussieht wie bei Deinem manuellen Test

Wenn das auch funktioniert, hängt es mit dem Booten zusammen.

[cho]

Hallo zap,

der RPC Server wird nicht mit gestartet (auch nach längerem warten nicht).
Entsprechend bleibt RPCstate auf starting stehen und in der fhem log fehlt der Eintrag:

0: HMCCU: Received IN event. RPC server initialized.

Das rpcccud log sieht jetzt so aus:

24.03.2016 23:22:23 Creating file queue
24.03.2016 23:22:23 Initializing RPC server
24.03.2016 23:22:23 Callback server created listening on port 7401
24.03.2016 23:22:23 Adding callback for events
24.03.2016 23:22:23 Adding callback for new devices
24.03.2016 23:22:23 Adding callback for deleted devices
24.03.2016 23:22:23 Adding callback for modified devices
24.03.2016 23:22:23 Adding callback for replaced devices
24.03.2016 23:22:23 Adding callback for readded devices
24.03.2016 23:22:23 Entering server loop. Use kill -SIGINT 947 to terminate program
24.03.2016 23:22:24 ListDevices
24.03.2016 23:22:25 NewDevice: received 114 device specifications
24.03.2016 23:29:24 Received 250 events from CCU since last check
25.03.2016 11:51:51 RPC server terminated
25.03.2016 11:52:51 Creating file queue
25.03.2016 11:52:51 Initializing RPC server
25.03.2016 11:52:51 Callback server created listening on port 7401
25.03.2016 11:52:51 Adding callback for events
25.03.2016 11:52:51 Adding callback for new devices
25.03.2016 11:52:51 Adding callback for deleted devices
25.03.2016 11:52:51 Adding callback for modified devices
25.03.2016 11:52:51 Adding callback for replaced devices
25.03.2016 11:52:51 Adding callback for readded devices
25.03.2016 11:52:51 Entering server loop. Use kill -SIGINT 5123 to terminate program
25.03.2016 11:59:32 Received 250 events from CCU since last check

Allerdings hat er dann aber doch etwas gelesen.
Denn in den Readings finde ich Zeilen mit dem Zeitstempel 2016-03-25 12:12:06

Viele Grüße
Christian

[ToM_ToM]

Hallo Cho, das ist das Gleiche wie bei mir auch. Hatte ich gestern hier gepostet.

zap arbeitet schon daran, herauszufinden woran das liegt.

VG, Thomas

[zap]

Hallo,

jetzt kapier ich gerade gar nichts mehr. Also wenn Ihr den RPC Server wie hier (https://forum.fhem.de/index.php/topic,40189.msg429646.html#msg429646) beschrieben manuell aus FHEM heraus startet: Funktioniert es dann oder nicht?

@cho: In Deinem vorletzten Post war die Meldung "HMCCU: Received IN event. RPC server initialized." doch drin

@ToM_ToM: Geht es bei Dir bei manuellem Start aus FHEM unter den im Link oben beschriebenen Voraussetzungen?

[ToM_ToM]

Hallo zap,

habe es exakt so wie in dem Link beschrieben, durchgeführt. Und es geht leider auch damit nicht.

VG, Thomas

[cho]

Hallo zap,

bei mir startet der RPC Server nur manuell, also mit attr off und attr on.
Dabei ist es egal, ob ich vorher das OS reboote oder nur das Fhem.

Viele Grüße
Christian

[zap]

Hallo zap,

bei mir startet der RPC Server nur manuell, also mit attr off und attr on.
Dabei ist es egal, ob ich vorher das OS reboote oder nur das Fhem.

Viele Grüße
Christian

Ok, dann gehe ich mal davon aus, dass Du und ToM_ToM unterschiedliche Probleme habt. In Deinem Fall könnte es sein, dass die Reihenfolge einiger Befehle in fhem.cfg falsch ist. Bitte führe mal folgenden Befehl aus:

egrep "(define|attr) xxxx" fhem.cfg

Wobei "xxxx" durch den Namen des HMCCU Device in FHEM zu ersetzen ist. Bei mir sieht das (nur als Beispiel) so aus:

Code Auswählen Erweitern


define d_ccu HMCCU homematic
attr d_ccu ccureadingformat name
attr d_ccu ccureadings 0
attr d_ccu devStateIcon (OK|Initialized):10px-kreis-gruen Error:10px-kreis-rot
attr d_ccu event-on-change-reading .*
attr d_ccu icon rc_HOME
attr d_ccu room Homematic
attr d_ccu rpcinterval 5
attr d_ccu rpcport 2001,2010
attr d_ccu rpcserver on
attr d_ccu statevals on:true,off:false
attr d_ccu stripchar :
attr d_ccu stripnumber 1
attr d_ccu updatemode client
attr d_ccu verbose 2


Was mich dabei interessiert ist die Reihenfolge der Befehle.

[cho]

Bei mir sind das viel weniger Einträge:

define CCU2 HMCCU homematic.fritz.box
attr CCU2 ccureadings 1
attr CCU2 group Zentrale
attr CCU2 room 1 HomeMatic
attr CCU2 rpcqueue /opt/fhem/tmp/ccuqueue
attr CCU2 rpcserver on
attr CCU2 updatemode hmccu
attr CCU2 verbose 2

[ToM_ToM]

Hey cho,

übernimm mal die Konfiguration wie von zap.

Das hat bei mir dann funktioniert.

VG, Thomas

[cho]

Hi ToM_ToM,

vielen Dank für den Tipp, jetzt funktioniert es!

Hi zap,

ich habe Deine abweichenden Einstellungen einzeln getestet.
Erfolg hat dann der Eintrag "attr d_ccu rpcport 2001,2010" gebracht.
"attr d_ccu rpcport 2001" alleine hat nichts gebracht. Es liegt also am Port 2010.

Viele Grüße
Christian

[zap]

Bei mir sind das viel weniger Einträge:

define CCU2 HMCCU homematic.fritz.box
attr CCU2 ccureadings 1
attr CCU2 group Zentrale
attr CCU2 room 1 HomeMatic
attr CCU2 rpcqueue /opt/fhem/tmp/ccuqueue
attr CCU2 rpcserver on
attr CCU2 updatemode hmccu
attr CCU2 verbose 2

Nicht alles von mir übernehmen. Aber setze mal folgende Attribute:

attr CCU2 rpcport 2001
attr CCU2 rpcinterval 5

Wenn Du den rpcport auf 2001,2010 setzt, werden 2 RPC-Server gestartet (1x Funk normal, 1x Homematic IP). Wenn Du kein Homematic IP hast, brauchst Du den 2010 nicht.
Ich würde Dir empfehlen, das Attribut updatemode auf "client" oder "both" zu setzen. Mit "hmccu" werden bei interaktiven Updates keine Client-Devices aktualisiert. Bei hmccu oder both könnten sehr viele Readings im HMCCU Device entstehen. Kannst Du nutzen, dann würde ich aber empfehlen, mit ccureadingfilter die Readings einzuschränken.

[zap]

ich habe Deine abweichenden Einstellungen einzeln getestet.
Erfolg hat dann der Eintrag "attr d_ccu rpcport 2001,2010" gebracht.
"attr d_ccu rpcport 2001" alleine hat nichts gebracht. Es liegt also am Port 2010.

Das ist krass! Schön, dass es läuft. Verstehe ich aber nicht. Aber zumindest weiß ich jetzt mal, wo ich suchen muss.

Hier mal eine Beschreibung, was die einzelnen Attribute bedeuten:

# Reading-Namen werden aus dem CCU Kanalnamen gebildet (Alternative "address")
attr d_ccu ccureadingformat name

# Speichere keine Readings im HMCCU Device (dafür gibt es die Client-Devices mit HMCCUDEV und HMCCUCHN)
attr d_ccu ccureadings 0

# Immer eine gute Idee, um FHEM etwas zu entlasten. Sollte man bei jedem HMCC* Device setzen
attr d_ccu event-on-change-reading .*

# Das Intervall, in dem die Queue mit den Statusinfos der CCU gelesen wird
attr d_ccu rpcinterval 5

# Die CCU-Ports (2001=BidCos-RF, 2000=BidCos-Wired, 2010=Homematic-IP)
attr d_ccu rpcport 2001,2010

# Ersetze bei Set-Befehlen on durch true und off durch false (CCU kann mit on/off nichts anfangen)
attr d_ccu statevals on:true,off:false

# Zahlenwerte in Readings nach der 1. Nachkommastelle abschneiden
attr d_ccu stripnumber 1

# Nur Readings der Client-Devices werden aktualisiert (sonst werden im HMCCU-Device sehr viele Readings auflaufen)
attr d_ccu updatemode client

Achtung! Viele der Attribute (statevals, stripnumber, ccureadingformat) müssen in den Client-Devices explizit nochmal gesetzt werden. Die Client-Devices "erben" keine Attribute vom HMCCU- bzw. IO-Device.

Das war ne schwere Geburt. So und jetzt suche ich den Fehler, zum Glück ist heute schlechtes Wetter

[cho]

Hi zap,

vielen Dank noch einmal für Deine Unterstützung und investierte Zeit!!!

Ich habe übrigens nur BidCos-RF (also kein IP).

Viele Grüße
Christian

[zap]

Vielleicht könnt Ihr mir noch einen Gefallen tun. Bitte prüft mal, wie viele RPC-Server laufen:

ps ax | grep ccurpc

oder in FHEM im HMCCU-Device mit "get nnnn rpcstate"

Falls Ihr SSH Zugriff auf Eure CCU habt, würd mich noch folgende Ausgabe auf der CCU interessieren:

netstat -an | grep LISTEN

Also ich habe bei mir jetzt mal testweise die Attribute rpcinterval und rpcport gelöscht. Es funktioniert bei mir trotzdem. Das wird immer seltsamer

[cho]

na klar:

ps ax | grep ccurpc

> 713 ?        S      0:03 /usr/bin/perl ./FHEM/ccurpcd.pl homematic.fritz.box 2001 /opt/fhem/tmp ccuqueue_2001 ./log/ccurpcd_2001.log
> 718 ?        S      0:02 /usr/bin/perl ./FHEM/ccurpcd.pl homematic.fritz.box 2010 /opt/fhem/tmp/ccuqueue_2010 ./log/ccurpcd_2010.log
> 1326 pts/0    S+     0:00 grep --color=auto ccurpc


oder in FHEM im HMCCU-Device mit "get nnnn rpcstate"

> RPC process(es) running with pid(s) 713,718

Falls Ihr SSH Zugriff auf Eure CCU habt, würd mich noch folgende Ausgabe auf der CCU interessieren:

netstat -an | grep LISTEN

> tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
> tcp        0      0 0.0.0.0:7410            0.0.0.0:*               LISTEN     
> tcp        0      0 0.0.0.0:8083            0.0.0.0:*               LISTEN     
> tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
> tcp6       0      0 :::22                   :::*                    LISTEN     

Dafür hätte ich aber auch noch eine Frage:
Ist es möglich, beim dem HMCCU Device in der Übersicht anstelle dem STATE OK den RPCState anzuzeigen?

Viele Grüße
Christian