HMCCU ist ein Modul für die Kommunikation zwischen FHEM und einer Homematic CCU. Die Module HMCCUDEV und HMCCUCHN werden für die Definition von Client-Devices verwendet. Der integrierte RPC Server sorgt für den Empfang von CCU Events, mit denen Readings in Client-Devices automatisch aktualisiert werden, sobald sich die entsprechenden Werte in der CCU ändern.
Ab Version 4.0 wird mit dem Modul HMCCURPC ein externer RPC-Server bereitgestellt, der auch binary RPC (z.B. für CUxD) unterstützt.
Features:
- Unterstützt BidCos-RF (Funk), BidCos-Wired (drahtgebunden), HMIP-RF (Homematic IP) und CUxD (nur mit HMCCURPC)
- Unterstützt (teilweise mit Einschränkungen) folgende CCU2 Addons: HomeGear, OSRAM Lightify
- Lesen und Schreiben von Datenpunkten von CCU Geräten
- Lesen und Schreiben von CCU Systemvariablen
- Werte aus der CCU werden als Readings in FHEM gespeichert
- Automatische Konvertierung und Skalierung von Werten beim Lesen und Schreiben
- Automatisches Update von Geräten bzw. Readings in FHEM bei Änderungen in der CCU
- Ausführen von CCU Programmen
- Ausführen von beliebigen Homematic CCU Scripts. Ergebnis kann als Readings gespeichert werden
- Lesen und Schreiben von CCU Geräte- und Kanalparametern
- Unterstützung der CCU Gruppen-Devices (Serial INTnnnnnnn)
- Unterstützung von CCU Team-Devices (Adresse *nnnnnn)
HMCCU verwendet Homematic Script und XML-RPC für die Kommunikation mit der CCU. Seit dem 13.09.2016 ist HMCCU Teil des FHEM SVN Zweigs und kann per update Befehl installiert und aktualisiert werden.
Beispiele für Client-Devices gibt es hier (https://forum.fhem.de/index.php/topic,51339.0.html)
Doku im Wiki: https://wiki.fhem.de/wiki/HMCCUWichtig!
Aufgrund der Verwendung von Homematic Script dürfen Namen in der CCU nur einmal verwendet werden, d.h. ein Gerätename in der CCU darf nicht auch für ein Gewerk oder ein anderes Objekt verwendet werden! Homematic Geräte- und Kanalnamen dürfen keine Umlaute verwenden.
Funktion der Module:
- HMCCU - Das ist das IO Device Modul für die Kommunikation mit der CCU. Funktioniert im Prinzip auch ohne die Client-Devices
- HMCCURPC - Externes RPC-Server Modul
- HMCCUDEV - Client-Device Modul für komplette CCU-Geräte (also z.B. für einen Dimmer oder eine Steckdose)
- HMCCUCHN - Client-Device Modul für einen einzelnen Kanal eines CCU-Gerätes.
- HMCCUConf - Default Attribute für einige Homematic Geräte.
Die Befehle der Module akzeptieren folgende Geräte-/Kanal- und Datenpunkt-Angaben:
Device = {Device-Name|[Interface.]Device-Address}
Channel = {Channel-Name|[Interface.]Device-Address:Channel-Number}
Datapoint = {Device|Channel}.Datapoint-NameBeispiel IO Device mit HMCCU:
# IO Device definieren
define d_ccu HMCCU 192.168.10.10
# Alle CCU Geräte einlesen (passiert beim define automatisch)
get d_ccu devicelist
# CCU Variable abholen und als Reading speichern
get d_ccu vars Anwesenheit
# Alle CCU Variablen abholen und als Reading speichern
get d_ccu vars .*
# BidCos-RF und HM-IP RPC Server konfigurieren und starten
attr d_ccu rpcport 2001,2010
attr d_ccu rpcserver on # Automatisch starten
set d_ccu rpcserver on
# Alle Kanäle und Datenpunkte eines CCU Geräts anzeigen (THERMOSTAT_WZ = Device-Name in CCU)
get d_ccu deviceinfo THERMOSTAT_WZ
# Pumpe mit State-Channel = 1
define d_Pumpe HMCCUDEV LEQ1234567 1
# Attribut statevals sorgt dafür, dass man den Gerätestatus ohne devstate setzten kann
attr d_Pumpe statevals on:true,off:false
# Gelesene Werte ersetzen (get Befehle liefern true/false, RPC server liefert 0/1)
attr d_Pumpe substitute true:on,false:off,1:on,0:off
# Pumpe einschalten (2 Varianten, 1. Variante funktioniert wg. Attribut statevals)
set d_Pumpe on
set d_Pumpe devstate on
# TF-Haus-1 ist der Kanalname in der CCU, Device ist readonly (Sensor)
define d_tuer HMCCUCHN TF-Haus-1 readonly
# Gelesen Werte ersetzen (get Befehle liefern true/false, RPC server liefert 0/1)
attr d_tuer substitute true:open,false:closed,1:open,0:closed
Datei /opt/fhem/hmtest.scr anlegen mit HM-Script Code (Ausgabe aller Systemvariablen der CCU). Readings werden nur gesetzt, wenn die Ausgabe des HM-Scripts Wertepaare im Format Reading=Value enthält. Wertepaare müssen durch Newline getrennt sein:
object osysvar;
string ssysvarid;
foreach (ssysvarid, dom.GetObject(ID_SYSTEM_VARIABLES).EnumUsedIDs())
{
osysvar = dom.GetObject(ssysvarid);
WriteLine (osysvar.Name() # "=" # osysvar.Value());
}
Script ausführen:
set d_ccu hmscript /opt/fhem/hmtest.scr
Ich habe leider keine CCU und hab alles an FHEM hab mich aber immer wieder geärgert das ich nicht eine CCU2 einhängen kann. So könnte man die Vorteile aus beiden Welten verbinden. Hoffe das Modul wird immer besser ausgebaut, dann überlege ich zu wechseln :D
Das Modul habe ich sozusagen "aus der Not heraus" entwickelt. Ich fahre schon länger zweigleisig, d.h. alles was geht mache ich mit Homematic und der CCU2. Alles was die CCU nicht kann, habe ich über FHEM realisiert. Nun gibt es aber Szenarien, die eine Kommunikation beider Systeme erforderlich machen.
Beispiel 1: Ich schalte den AV-Receiver ein. Das FHEM Pioneer AVR Modul erkennt das und schaltet über die CCU und die Schaltsteckdose den Bass ein.
Beispiel 2: Ich versorge die CCU aus FHEM mit Wetterinformationen (u.a. aus meiner Wetterstation und Wetter.com). Die CCU nutzt diese Infos z.B. für die Prüfung, ob bei Regen die Dachfenster zu sind.
Zum Thema Ausbau: Was wäre denn interessant? Ich möchte auf jeden Fall noch die Ausführung von CCU Programmen einbauen.
Hey,
Das
Modul hört sich gut in. Ich habe auch teilweise die Ccu2 und Fhem's am laufen.
Bei mir läuft die ccu nur temporär.
Ich werde das Modul ab September mal testen.
Hab gerade wenig Zeit.
Gruß Gerd
Vor dem Ausprobieren das Modul nochmal runterladen. Habe einige Fehler korrigiert.
hört sich sehr interessant an. vor allem vor dem hintergrund dass die ccu2 als bausatz zur zeit billiger ist als das lan modul.
ich benutze eigentlich zwave; aber die heizkörperthermostate arbeitn da nicht so doll.
deshalb überlege ich die heizkörper komplett über homematik laufen zu lassen. läuft denn der datenaustausch zwischen fhem und der ccu2 so, dass ich als infoboard und zur gelegentlich erhöhung der temperatur auf der fhem oberfläche bleiben kann?
grüße horst
Momentan kann man nur STATE der in der CCU definierten Geräte setzen. Die Erweiterung auf andere Datapoints (zB für ein Thermostat) kann ich aber noch einbauen. Die momentan eingebauten Funktionen sind halt die, die ich selbst benötige. Da es aber doch anscheinend den ein oder anderen Interessenten gibt, werde ich das Modul noch etwas ausbauen.
Bei mir liegt der Schwerpunkt auf der CCU, d.h. ich mache nur die Dinge über FHEM, die mit der CCU nicht out of the box gehen. Für den Rest ist mir FHEM enfach zu mühsam, frickelig und zeitaufwändig, insbesondere bei großen Installationen (habe da über Jahre mit FS20 reichlich Erfahrungen gesammelt).
Momentan überlege ich, eine webbasierte Statusanzeige über das Infopanel Modul von FHEM zu realisieren. Dafür hole ich auch Infos per HMCCU aus der CCU ab. Allerdings fehlen da schon wieder so viele Funktionen, dass ich nun vor der Wahl stehe, Infopanel selbst anzupassen (was wieder viel Zeit kosten wird) oder doch auf eine professionelle Lösung wie IP Symcom zu setzen.
UPDATE: Schlechtes Wetter => Viel Zeit => Setzen und Auslesen von Datenpunkten eingebaut :)
Damit kann nun z.B. die Solltemperatur eines Thermostaten in der CCU geändert werden.
Ich frage mich auch gerade ob ich nicht bei dem aktuellen Bausatzpreis für die CCU2 vieles aus FHEM ausgliedern kann. Irgendwie bin ich für mich Klick-mich-zusammen-Logik eigentlich empfänglicher als für die (mächtigere) FHEM-Variante. Aber meine meisten HomeMatic-Geräte reden ohnehin direkt miteinander.
Gehe ich recht in der Annahme, dass bei einem richtigen (also gleichen) Setzen der Zentralen-ID in CCU2 und FHEM den Status der Geräte direkt mitloggen kann und man so den Status weiter direkt in FHEM auswerten kann, ohne die CCU2 dazu zu befragen?
OT: Kann man der CCU2 eigentlich auch eine HMID beibringen oder will die immer ihre "durchsetzen"?
Zitat von: Ralli am 14 September 2015, 19:07:21
OT: Kann man der CCU2 eigentlich auch eine HMID beibringen oder will die immer ihre "durchsetzen"?
Ich glaube, der CCU2 kann man keine bestimmte HMID unterjubeln. Allerdings ist die CCU-Software mittlerweile ja quelloffen und kann so auf anderen Devices (Raspberry o.a.) installiert werden. Das lässt natürlich einiges erwarten für die Zukunft, sofern sich genügend "Freiwillige" finden, die daran arbeiten.
Zitat von: Pfriemler am 14 September 2015, 17:16:55
Ich frage mich auch gerade ob ich nicht bei dem aktuellen Bausatzpreis für die CCU2 vieles aus FHEM ausgliedern kann. Irgendwie bin ich für mich Klick-mich-zusammen-Logik eigentlich empfänglicher als für die (mächtigere) FHEM-Variante. Aber meine meisten HomeMatic-Geräte reden ohnehin direkt miteinander.
Das war auch bei mir der Grund, nach dem Wechsel von FS20 auf Homematic auch gleich die Plattform in Richtung CCU zu wechseln. Warum sich mit kryptischen "defines" rumquälen, wenn man vieles einfach per Mausklick machen kann. Natürlich hat FHEM noch seine Existenzberechtigung wenn es um das Einbinden von Nicht-Homematic Komponenten geht Habe meine Wetterstation, meinen AV-Receiver und die Anwesenheitskontrolle mit FHEM realisiert und per HMCCU Modul mit der CCU "verheiratet". Best of both worlds, wie es so schön heißt.
Zitat
Gehe ich recht in der Annahme, dass bei einem richtigen (also gleichen) Setzen der Zentralen-ID in CCU2 und FHEM den Status der Geräte direkt mitloggen kann und man so den Status weiter direkt in FHEM auswerten kann, ohne die CCU2 dazu zu befragen?
Wenn Du die ID der Zentrale verwendest sollte das funktionieren.
Hallo,
Zitat von: Ralli am 14 September 2015, 19:07:21
OT: Kann man der CCU2 eigentlich auch eine HMID beibringen oder will die immer ihre "durchsetzen"?
Ja, kann man IIRC in /etc/config/ids setzen. Danach die CCU2 rebooten.
Zitat von: zap am 14 September 2015, 19:40:14
Allerdings ist die CCU-Software mittlerweile ja quelloffen und kann so auf anderen Devices (Raspberry o.a.) installiert werden.
Quelloffen ist das leider nicht: https://github.com/eq-3/occu
Nur eine Ansammlung an Blobs für verschiedene Plattformen kompiliert.
Viele Grüße
Michael
Zitat von: zap am 13 September 2015, 11:23:39
Da es aber doch anscheinend den ein oder anderen Interessenten gibt, werde ich das Modul noch etwas ausbauen.
Hej zap,
um den Kreis der Interessenten noch etwas zu erweitern:
Zwar nicht direkt für mich, aber für ein Projekt, das ich betreue, bei dem kommende Heizsaison fertig umgestellt sein soll. :-)
Zitat von: mgernoth am 14 September 2015, 22:13:50
Ja, kann man IIRC in /etc/config/ids setzen. Danach die CCU2 rebooten.
Wird ja immer besser. Muss ich nicht alles neu anlernen in FHEM.
CCU2 ist soeben bestellt.
Zitat von: Mr. P am 14 September 2015, 22:42:00
Hej zap,
um den Kreis der Interessenten noch etwas zu erweitern:
Zwar nicht direkt für mich, aber für ein Projekt, das ich betreue, bei dem kommende Heizsaison fertig umgestellt sein soll. :-)
Datenpunkte setzen geht mittlerweile (z.B. Zieltemperatur für Thermostate). Muss mich mal schlau machen, wie ich den Kram ins SVN Contrib bekomme. Macht die Updates etwas einfacher.
Zitat von: Pfriemler am 14 September 2015, 23:39:10
Wird ja immer besser. Muss ich nicht alles neu anlernen in FHEM.
Ich fürchte, das wirst Du trotzdem tun müssen - woher soll die CCU2 sonst ihre Device-Übersicht her bekommen. Oder legt die CCU2 ein Device an, welches an sie adressiert und welches sie noch nicht in ihrer Liste hat?
Zitat von: mgernoth am 14 September 2015, 22:13:50
Quelloffen ist das leider nicht: https://github.com/eq-3/occu
Nur eine Ansammlung an Blobs für verschiedene Plattformen kompiliert.
Viele Grüße
Michael
Das SDK inklusive der vor compilierten Bins gibt es hier: http://www.eq-3.de/Downloads/Software/Software_Development_Kit/HM-OCCU-SDK-1.0.0.tgz
Zitat von: Ralli am 15 September 2015, 09:19:57
Ich fürchte, das wirst Du trotzdem tun müssen - woher soll die CCU2 sonst ihre Device-Übersicht her bekommen. Oder legt die CCU2 ein Device an, welches an sie adressiert und welches sie noch nicht in ihrer Liste hat?
Natürlich muss man die Geräte an die CCU2 anlernen, d.h. in den Anlernmodus versetzen und in der CCU2 die Suchfunktion nach neuen Geräten starten. Ich glaube, hier ging es eher darum, die Geräte nicht neu in FHEM anlernen zu müssen.
Ich hatte das irgendwie anders verstanden - wenn man bereits Geräte in fhem mit einer definierten HMID angelernt hat, und man kann der (neuen) CCU2 dann die HMID aus der fhem-Installation setzen ...
Eine ccu hat eine hmid. M.w. ist die nicht aenderbar. Pairt man wir diese genommen.
Hmlan ist ein io, die hmid kann man aendern. Damit kann ein hmlan als io der ccu mit deren ID genutzt werden. Fhem nutzt das hmlan identisch.
Da nun die ID der ccu unveränderlich ist müssen sich alle nach ihr richten - so man diesen betrieb will. Also alles an ccu an lernen, hmid der vccu identisch zur ccu einstellen. Fhem IOS der vccu zuordnen.
Zitat von: mgernoth am 14 September 2015, 22:13:50
Ja, kann man IIRC in /etc/config/ids setzen. Danach die CCU2 rebooten.
;)
Nach der Änderung der HM ID in der CCU2 muss man natürlich die Geräte "anlernen", wenn das so geht wie beim Konfigurator, lernt die CCU2 die Konfig von den Geräten ohne diese zu ändern, und sie erkennt auch vorhandene Verknüpfungen. Im Grunde ein getConfig.
Die CCU2 nutzt ihre eigene Funkschnittstelle. Betrieb ausschließlich mit HMLAN ist zwar auch möglich, dann ist aber FHEM taub.
geht nich Gips nich ...
Edit: falsch verstanden: Martin meinte die Zuordnung der IOs zur vccu in FHEM. Ja natürlich, was sonst ...
Ich hab' mir nun auch mal eine bestellt ;D. Einfach mal zum Experimentieren ...
Korrekt, beim an lernen macht die ccu ein (eigenes) getconfig. Was mich stört ist, dass ich es nicht noch einmal starten kann. Wenn ich über fhem ein Register andere ist mir nicht klar, ob die ccu das erkennt. Sollte sie ofline sein kann sie es nicht.
In fhem kann ich einfach ein getconfig machen.... Wenn viel passiert ist einfach in hminfo. Ich kann erkennen, wenn alles wieder gelesen und vollständig ist.
Vieleicht gibt es auch in der ccu etwas vergleichbares. Hier fehlen mir auch die Sicherungen und die Option, diese wieder einzuspielen..... In fhem kann man die Register sichern, kopieren, archivieren und wiederherstellen. Ich habe da gerne den Bodenkontakt, den ich in einer ccu nicht erkenne.
Zitatbeim an lernen macht die ccu ein (eigenes) getconfig. Was mich stört ist, dass ich es nicht noch einmal starten kann.
Der HM-Konfigurator kann das nicht, ich dachte die Zentrale kann es. Nötig hätte sie es eigentlich nicht - sie denkt ja dass sie der Chef vons Janze is und ihr nichts entgehen kann.
ZitatWenn ich über fhem ein Register ändere...
Habe ich dann eigentlich nicht mehr vor - alle Konfigs nur über die CCU2.
ZitatIn fhem kann man die Register sichern, kopieren, archivieren und wiederherstellen. Ich habe da gerne den Bodenkontakt, den ich in einer ccu nicht erkenne.
In zwei Monaten bin ich auch schlauer. Deine Argumente sind sehr richtig und wichtig.
Vielleicht bin ich schneller wieder bei FHEM als ich denke ::)
Aber eigentlich diskutieren wir das Für und Wider in diesem Fred (http://forum.fhem.de/index.php/topic,36284.0.html). Hier sollten wir mal bei ZAPs Modul bleiben.
Tja, das sind eben die Vor- und Nachteile von Open Source Software. Einerseits hat man Zugriff auf das letzte Bit, andererseits verführt das auch dazu, Dinge komplizierter zu machen als eigentlich notwendig. Muss jeder für sich rausfinden, was das Beste ist.
Ich halte es nach dem Prinzip "keep it simple". Der ganze Kram muss auch vom Rest der Familie handlebar sein, wenn ich mal nicht da bin. Und das kann ich mit "Pocket Control" auf meinem iPAD in Verbindung mit der CCU gewährleisten.
direkt nach Eingabe von
define cccu2 HMCCU 192.168.9.154
erhalte ich : Cannot load module HMCCU
(habe das Modul nach Fhem Fhem kopiert wo auch alle anderen pms sind ....
Permissions passen?
FHEM auch neu gestartet oder zumindest das File geladen?
Gesendet von meinem SM-G800F mit Tapatalk
Zitat von: harway2007 am 16 September 2015, 00:56:32
direkt nach Eingabe von
define cccu2 HMCCU 192.168.9.154
erhalte ich : Cannot load module HMCCU
(habe das Modul nach Fhem Fhem kopiert wo auch alle anderen pms sind ....
Falls die Berechtigungen stimmen (siehe vorherige Antwort):
Das Perl Modul XML::Simple wird benötigt. Ist das installiert? Im FHEM Log sollten Fehlermeldungen stehen. Bitte schau mal nach und poste sie hier.
Das Modul funktioniert :).
Ich hätte da aber mal einen anderen Ansatz bzw. eine andere Idee:
Statt die CCU2 über das Modul zu definieren und dann letztendlich immer mit diesem einen definierten Device zu arbeiten, fände ich es deutlich besser und sinnvoller, die tatsächlich in fhem darzustellenden, zu schaltenden bzw. zu nutzenden Geräte wie bislang auch zu definieren und als Typ (und Schnittstelle) das Modul zu nehmen, welches mit der CCU2 kommuniziert.
Anders ausgedrückt:
define MeinSchalter HMCCU MeineCCU2IP:Device DeviceHMID
Das hätte den unschätzbaren Vorteil, die Geräte wie bisher auch in fhem - mit allen Events, Triggern usw. - einbinden zu können, nur dass Schaltbefehle und Requests eben nicht mehr über die IOs für CUL_HM laufen sondern über die CCU2.
habe mit cpan das Modul versucht zu laden
cpan install XML::Simple dann Neustart ...
erhalte dann diese Logfile Meldung und den Fehler Cannot load module HMCCU:
2015.09.21 11:47:33 1: reload: Error:Modul 88_HMCCU deactivated:
Can't locate XML/Simple.pm in @INC (you may need to install the XML::Simple module) (@INC contains: ./FHEM/lib ./lib /etc/perl /usr/local/lib/i386-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/i386-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/i386-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/88_HMCCU.pm line 39.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 39.
2015.09.21 11:47:33 0: Can't locate XML/Simple.pm in @INC (you may need to install the XML::Simple module) (@INC contains: ./FHEM/lib ./lib /etc/perl /usr/local/lib/i386-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/i386-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/i386-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/88_HMCCU.pm line 39.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 39.
erbitte Hilfestellung ..
Was heißt "versucht" ?
Als root bzw. mit sudo nachinstallieren.
Zitat von: Ralli am 21 September 2015, 09:58:56
Ich hätte da aber mal einen anderen Ansatz bzw. eine andere Idee:
Statt die CCU2 über das Modul zu definieren und dann letztendlich immer mit diesem einen definierten Device zu arbeiten, fände ich es deutlich besser und sinnvoller, die tatsächlich in fhem darzustellenden, zu schaltenden bzw. zu nutzenden Geräte wie bislang auch zu definieren und als Typ (und Schnittstelle) das Modul zu nehmen, welches mit der CCU2 kommuniziert.
Anders ausgedrückt:
define MeinSchalter HMCCU MeineCCU2IP:Device DeviceHMID
Das hätte den unschätzbaren Vorteil, die Geräte wie bisher auch in fhem - mit allen Events, Triggern usw. - einbinden zu können, nur dass Schaltbefehle und Requests eben nicht mehr über die IOs für CUL_HM laufen sondern über die CCU2.
mm, Geräte schalten über die CCU aus FHEM heraus geht ja im Moment schon mit HMCCU:
set MeineCCU devstate MeinSchalterKanal true
Bei Deiner Variante wäre der set Befehl minimal einfacher (sprechender?):
set MeinSchalter devstate true
Da ich XML-API verwende, muss FHEM den Status der Homematic Geräte aus der CCU aktiv pollen. Dann werden aber auch Events generiert. Es ist deutlich effektiver und Ressourcen schonender, mit einer Abfrage die Stati aller CCU Geräte zu holen. Wenn das in FHEM einzelne Geräte wären, müsste für jedes Gerät auch eine Statusabfrage an die CCU geschickt werden.
Oder meinst Du, dass die CCU FHEM automatisch bei Statusänderungen benachrichtigen soll? Dann müsste ich auf die RPC Schnittstelle wechseln. Dazu gibt es bereits das Modul HMRPC, das aber nicht mehr weiter entwickelt wird und das Protokoll auch leider nicht vollständig bzw. korrekt implementiert hat.
RPC und CCU ist ein weites Feld. Damit kann man sich die CCU abschiessen. Insofern würde ich gerne bei XML-API bleiben.
@harway2007:
Welche Fehlermeldung wirft "cpan install" ? Oder ist die Installation erfolgreich?
P.S. Bitte beachten: die aktuelle Version des Moduls gibt es ab sofort immer im SVN (Contrib Zweig, siehe Link im ersten Post).
Zitat von: zap am 21 September 2015, 12:37:12
Da ich XML-API verwende, muss FHEM den Status der Homematic Geräte aus der CCU aktiv pollen. Dann werden aber auch Events generiert. Es ist deutlich effektiver und Ressourcen schonender, mit einer Abfrage die Stati aller CCU Geräte zu holen. Wenn das in FHEM einzelne Geräte wären, müsste für jedes Gerät auch eine Statusabfrage an die CCU geschickt werden.
Jain :). Das könntest Du ggf. so lösen, wie es momentan auch mit CUL_HM gelöst ist: Man definiert ein IO (oder eine vCCU mit IOs) und definiert Devices.
Adaptiert wäre das: Man definiert die CCU2 und definiert Devices, die die definierte CCU2 nutzen.
So könnte die definierte CCU2 als SPOC - so wie jetzt in Deinem Modul - für alle an ihr registrierten Devices auf einmal pollen und dann an die Devices verteilen.
Der Vorteil wäre, dass Du so, wie es halt in fhem normal ist, hättest: du kannst jedes Device "schön" in dem entsprechenden Raum und den entsprechenden Gruppen sortieren und in alle DOIFs, IFs usw. einbinden. So wird es ja bspw. nicht nur mit CUL_HM sondern auch mit im Endeffekt allen anderen Protokollen gemacht.
ZitatOder meinst Du, dass die CCU FHEM automatisch bei Statusänderungen benachrichtigen soll? Dann müsste ich auf die RPC Schnittstelle wechseln. Dazu gibt es bereits das Modul HMRPC, das aber nicht mehr weiter entwickelt wird und das Protokoll auch leider nicht vollständig bzw. korrekt implementiert hat.
Wenn ich ehrlich bin, wäre das im Endeffekt die perfekte Lösung. Weg vom (alleinigen) Pollen hin zu der Möglichkeit, auf "Anrufe" der CCU2 zu reagieren.
Edit:
Gerade gesehen, dass dies der Funktionalität von dem "alten" HMRPC-Modul entspricht :o :
http://forum.fhem.de/index.php?topic=12642.0
Edit2:
Und überschneidet sich hiermit:
http://forum.fhem.de/index.php/topic,41060.msg332596.html#msg332596
Vielleicht solltet Ihr Euch zusammentun :).
Zitat von: Ralli am 21 September 2015, 13:05:23
Jain :). Das könntest Du ggf. so lösen, wie es momentan auch mit CUL_HM gelöst ist: Man definiert ein IO (oder eine vCCU mit IOs) und definiert Devices.
Adaptiert wäre das: Man definiert die CCU2 und definiert Devices, die die definierte CCU2 nutzen.
So könnte die definierte CCU2 als SPOC - so wie jetzt in Deinem Modul - für alle an ihr registrierten Devices auf einmal pollen und dann an die Devices verteilen.
Der Vorteil wäre, dass Du so, wie es halt in fhem normal ist, hättest: du kannst jedes Device "schön" in dem entsprechenden Raum und den entsprechenden Gruppen sortieren und in alle DOIFs, IFs usw. einbinden. So wird es ja bspw. nicht nur mit CUL_HM sondern auch mit im Endeffekt allen anderen Protokollen gemacht.
Verstanden. Das mit den Räumen usw. hatte ich nicht bedacht. Die Erweiterung wäre ziemlich einfach. Mal sehen, wie schnell HMRPC einen stabilen Reifegrad erlangt ...
@Ralli
hatte sudo bei cpan ... vergessen HMCCU wird jetzt geladen ...
DANKE ....
Im contrib Zweig in Sourceforge (https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/HMCCU/) gibt es nun ein weiteres Modul 88_HMCCUDEV.pm. Dieses Modul implementiert Client Devices für die CCU. 88_HMCCU.pm ist das IO Device.
Beispiel 1:
define Fenster1 HMCCUDEV WIN-WZ-1
"WIN-WZ-1" ist der Name des Tür-/Fenstersensors in der CCU.
Beispiel 2:
define Steckdose HMCCUDEV STEHLAMPE-WZ
attr Steckdose stateval on:true,off:false
set Steckdose devstate on
Top! Und vielen Dank.
Aber ich hätte zwei Vorschläge:
1)
define Fenster1 HMCCUDEV CCU2:WIN-WZ-1
... wobei CCU2 hier die über das Modul HMCCU definierte CCU2 ist. Warum? Ganz einfach, so kannst Du mehrere CCU2s in fhem integrieren. Das könnte in manchen Situationen sinnvoll sein, wenn bspw. zwei oder mehr "Kreise" genutzt werden.
2)
set Steckdose (devstate) on
... das devstate sollte/könnte eigentlich überflüssig sein. Ich würde es als sinnvoll erachten, wenn Schaltzustände an das Device unmittelbar entsprechend der Standard-Art übermittelt werden könnten (also set Steckdose on, off, 0..100). Das Attribut stateval könnte stattdessen eventmap heissen.
Das mit den 2 CCUs ist jetzt schon möglich. Einfach im Attribut IODev ein anderes HMCCU Device angeben. Standard bei Client bzw. IO- Devices in FHEM.
Statt devstate kann man jetzt auch on und off direkt angeben. Allerdings muss man das Attribut stateval auf on:true,off:false setzen. Sonst wird on bzw off an die CCU geschickt. Die erwartet aber true oder false bei STATE. Das Attribut stateval legt gleichzeitig die möglichen set Befehle über die Texte vor den Doppelpunkten fest. "on:true,off:false,standby:lala" legt also on, off und standby als Set Befehle neben devstate und datapoint fest.
Außerdem kann man nun Devices als readonly, d.h. ohne Set Befehl anlegen. Sinnvoll z.B. für reine Sensoren. Dazu wird beim Anlegen des Devices einfach readonly an das Define Command angehängt, z.B.
define d_fenster HMCCUDEV TF-Wohnzimmer readonly
Hallo zap,
bin jetzt seit längerer Zeit erst nochmal zum Experimentieren gekommen.
http://forum.fhem.de/index.php/topic,42212.msg345535.html#msg345535
Ich bin der Auffassung, dass die eierlegende Wollmilchsau das ideale wäre. Wenn in das HMCCU-Modul noch der HMRPC-Provider mit eingebaut würde und man so diese Möglichkeit (optional) mit nutzen könnte, und im Endeffekt Devices aus/mit beiden Kommunikationssträngen gefüttert und gesteuert werden könnten.
Vorteil: Ein Device definiert, welches echte Events generieren kann und alle Vorteile mit "übersetzten" set's und get's und den sonst von Dir eingebauten Benefits hat.
Ich habe da mal so eine Verständnisfrage. Ich kann ja CCU2 Devices direkt über FHEM ansteuern. Würde ich denn per notify mitbekommen, wenn ein 6 Fach Taster gedrückt wurde? Würde gerne zu denn CCU2 gespeicherten Befehlen noch zusätzliche Aktionen per FHEM starten.
Wenn per HMRPC angebunden, dann ja. Wenn per HMCCU angebunden, dann erst nach einer Zeitspanne X, wenn ein erneutes Polling durchgeführt wurde.
Wie ich schon an anderer Stelle geschrieben habe, glaube ich, dass die direkte Implementierung eines RPC Servers in FHEM zwar möglich, aber mit diversen Unwägbarkeiten verbunden ist (z.B. dass der ein oder andere Event von der CCU verloren geht oder FHEM "bockt").
m.E. wäre ein möglicher Kompromiss die Implementierung eines RPC Servers als separater Daeomon/Prozess, der die Requests der CCU entgegennimmt und in eine Queue (z.B. eine FIFO Pipe) schreibt. Dort könnte dann ein FHEM Modul (HMCCU) die Informationen abholen und an seine Client-Devices verteilen. Das wäre dann zwar auch wieder ein Polling-Verfahren zwischen HMCCU und der Queue, allerdings könnten die Abfragen in viel höherer Frequenz stattfinden (< 10 Sekunden) und so ein Echtzeit naher Informationsfluss zwischen CCU und FHEM ermöglicht werden.
Der Rückweg von FHEM zur CCU ist trivial bzw. mit den vorhandenen Methoden der CCU als HTTP-Request möglich, so wie das HMCCU heute schon macht.
In etwa so:
CCU ---(RPC)---> Collector-Prozess ---> Queue ---(Polling)--->FHEM
Zitat von: zap am 18 Oktober 2015, 13:43:36
m.E. wäre ein möglicher Kompromiss die Implementierung eines RPC Servers als separater Daeomon/Prozess, der die Requests der CCU entgegennimmt und in eine Queue (z.B. eine FIFO Pipe) schreibt. Dort könnte dann ein FHEM Modul (HMCCU) die Informationen abholen und an seine Client-Devices verteilen. Das wäre dann zwar auch wieder ein Polling-Verfahren zwischen HMCCU und der Queue, allerdings könnten die Abfragen in viel höherer Frequenz stattfinden (< 10 Sekunden) und so ein Echtzeit naher Informationsfluss zwischen CCU und FHEM ermöglicht werden.
Dieser Ansatz hört sich interessant an! Ggf. wäre auch da noch nicht einmal ein ständiges Polling notwendig, wenn man eine Möglichkeit findet, einen Interrupt auszulösen, sobald etwas in der Queue liegt. Aber, sei mir nicht gram, ich bin hier nur Theoretiker, mit meinen minimalsten Programmierkenntnissen kenne ich mich in der Struktur von fhem überhaupt nicht aus.
Das erinnert mich ein bisschen an die "normale" Einbindung eines IOs. CUL_HM macht es doch wahrscheinlich auch nicht anders. Die von den IOs empfangenen (und zu sendenden) Messages wandern in einen Stapel und werden der Reihe nach abgeholt und abgearbeitet.
Die Problematik in diesem Fall liegt tiefer in der FHEM Architektur. Für die Bearbeitung der CCU Benachrichtigungen muss FHEM bzw. das HMRPC / HMCCU Modul permanent Netzwerkverbindungen der CCU entgegennehmen und abarbeiten muss. Da FHEM nicht multithreading fähig ist, muss das alles in der großen FHEM Hauptschleife passieren, was FHEM teilweise blockiert oder zu Problemen in der CCU führt.
Ich habe jetzt mal mit einem standalone Programm experimentiert. Grundsätzlich funktioniert die Kommunikation mit der CCU, mit Events gibt es jedoch Probleme (s.a. hendryks thread). Wenn ich das zum Laufen bekommen, steht der oben skiziierten Lösung vermutlich nichts mehr im Wege.
:)
Top - vielen Dank, dass Du Dich weiter darum kümmerst - ich denke, dass das der vielversprechendste Ansatz ist!
So, der RPC Server läuft soweit. Weiß nicht, ob ich mich darüber freuen soll, bedeutet nun noch etwas Arbeit ;):
- Einbindung der RPC Server Ausgabe in HMCCU
- Ergänzung der Device-Names um die benutzerdefinierten Namen aus der CCU (ich mag diese LE00xyz Bezeichnungen nicht)
- Evtl. autocreate von FHEM Devices
- Handling möglicher Fehlersituationen
- ...
Um es gleich vorweg zu sagen: Vermutlich wird die neue Version von HMCCU/HMCCUDEV nur auf Linux und MacOSX laufen. Und auf XML-API will ich auch nicht verzichten, da es Informationen liefert, an die ich per RPC nur schwer oder gar nicht ran komme. Wird also so eine Art Mischbetrieb werden.
Demnächst mehr in diesem Kino.
zap, gaaaanz große Klasse. Vielen vielen Dank!
Und genau so (als Mischbetrieb) hatte ich mir das in meiner theoretischen Naivität vorgestellt :).
Edit:
Da hat eq-3 heute ein paar Spezifikationen neu in den Download-Bereich eingestellt, z.B.
http://www.eq-3.de/Downloads/Software/HM-CCU2-Firmware_Updates/Tutorials/HM_XmlRpc_API.pdf
Ausserdem ist die Firmware 2.15.5 der CCU2 erhältlich.
zap,
das hört sich echt gut an. Falls du Hilfe benötigst, kannst gerne auf mich zu kommen.
grüße
@EdgarM: Danke für das Angebot. Im Moment läuft es aber ganz gut :)
@Ralli: Die Doku kenne ich. RPC ist auch keine Thema mehr. Den RPC-Teil habe ich fertig, d.h. ein separates Perl-Script, das als RPC Server im Hintergrund läuft und für FHEM die Nachrichten der CCU in einer Queue bereitstellt.
Einziges Fragezeichen hier: Der RPC-Init-Call, also die Registrierung der Callback-URL bei der CCU, dauert sehr lange (2-3 Minuten). Keine Ahnung warum. Wäre aber nur beim FHEM Start relevant.
Nun fehlt noch die Verbindung zu HMCCU. Nächste Woche habe ich Urlaub. Da könnte es was werden.
Hallo zap,
viel Erfolg ;).
Um die Devices, die man über HMCCU definiert, auch bspw. in (gemischte!) Strukturen einbinden zu können, wäre es wichtig, die wichtigsten Standard-Kommandos verwenden zu können und den state entsprechend zu setzen. Also bei mir wären das bspw.
set device on
set device off
set device toggle
set device on-for-timer
set device on-till
set device statusRequest
set device 0..100 [x y] # x y für Dimmer mit Rampe und Zeit
set device red|orange|green
set device ilum x y
set device desired-temp 5..30|on|off
set device controlMode auto|manu
usw.
Aber ich meine, das hättest Du - zumindest teilweise - auch schon eingebaut.
Erstmal großes Lob für die Mühe! Nachdem es beim Hausbau noch an der Baugenehmigung hakt habe ich in der Zwischenzeit endlich einen kleinen Rechner als FHEM-Server aufgebaut und bin gerade am Rumspielen mit der CCU2-Einbindung. Aber leider bekomm ichs nicht ans Laufen...irgendwie scheint er die URLs zur Abfrage falsch zusammenzubauen. Wahrscheinlich hab ich nur einen kleinen (Denk-)fehler irgendwo.
Nehmen wir als Beispiel das HM-Thermometer ... meine CCU ist als "CCU2" defined.
Schicke ich nun ein "get CCU2 datapoint BidCos-RF.LEQxxxxxxx:1.TEMPERATURE" los bekomme ich den Fehler "HMCCU: CCU2 Error during CCU request".
Im FHEM-Log sehe ich als Aufruf-URL:
http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:1.TEMPERATURE").DPByHssDP("LEQxxxxxxx:1.TEMPERATURE").Value()
Rufe ich die im Browser auf bekomme ich als Rückgabe im XML:
<r1>BidCos-RF.LEQxxxxxxx:1.TEMPERATURE</r1>
Jetzt habe ich mal etwas rumprobiert und bei Eingabe folgender URL im Browser: http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQ0799970:1.TEMPERATURE").Value() bekomme ich als Rückgabe im XML:
<r1>10.200000</r1>
also den korrekten Temperaturwert.
Hier noch der komplette Log-Auszug:
2015.10.25 00:05:08 4: FHEMWEB:192.168.0.39:54912 POST /fhem&cmd=get+CCU2+datapoint+BidCos-RF.LEQxxxxxxx%3A1.TEMPERATURE; BUFLEN:0
2015.10.25 00:05:08 5: Cmd: >get CCU2 datapoint BidCos-RF.LEQxxxxxxx:1.TEMPERATURE<
2015.10.25 00:05:08 4: HttpUtils url=http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:1").DPByHssDP("LEQxxxxxx:1.TEMPERATURE").Value()
2015.10.25 00:05:08 4: http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:1").DPByHssDP("LEQxxxxxxx:1.TEMPERATURE").Value(): HTTP response code 200
2015.10.25 00:05:08 4: HttpUtils http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:1").DPByHssDP("LEQxxxxxxx:1.TEMPERATURE").Value(): Got data, length: 114
2015.10.25 00:05:08 5: Triggering CCU2 (1 changes)
2015.10.25 00:05:08 5: Notify loop for CCU2 Error
2015.10.25 00:05:08 1: HMCCU: CCU2 Error during CCU request
2015.10.25 00:05:08 4: name: /fhem&cmd=get+CCU2+datapoint+BidCos-RF.LEQxxxxxxx%3A1.TEMPERATURE / RL:1112 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.10.25 00:05:08 4: Connection closed for FHEMWEB:192.168.0.39:54910: EOF
Jetzt frage ich mich, was denn bei mir falsch läuft, dass das nicht klappt. :(
Du gibst im GET Befehl die korrekte Adresse (d.h. vollständige) Adresse eines Datenpunktes an. Das hatte ich bisher in HMCCU nicht berücksichtigt, werde es aber in der kommenden RPC-Version des Moduls einbauen. Bis dahin gilt folgendes Format für die Angabe eines Datenpunktes:
Channel-Name.Datenpunkt
In Deinem Beispiel wäre Datenpunkt=TEMPERATURE. Nun musst Du noch den Namen des Kanals in Deiner CCU rausbekommen. Wenn Du in der CCU "Einstellungen / Geräte" aufrufst, steht der in der Spalte Name. Hier nun den Namen auswählen, der auf den richtigen Kanal (beim Thermostaten HM-TC-IT-WM-W-EU ist das Kanal 1) verweist.
Bei der neuen Modulversion werde ich etwas mehr Intelligenz in die Namens-/Kanal-/Adressangabe einbauen.
Zur Verdeutlichung ein kleiner Auszug aus meiner CCU Konfiguration:
<device name="KL-AZ-TH" ise_id="4927" unreach="false" sticky_unreach="false" config_pending="false">
<channel name="KL-AZ-TH:0" ise_id="4928" visible="" operate="">...</channel>
<channel name="KL-AZ-TH:1" ise_id="4957" visible="true" operate="true">
<datapoint name="BidCos-RF.LEQ1462664:1.TEMPERATURE" type="TEMPERATURE" ise_id="4959" value="18.100000" valuetype="4" valueunit="°C" timestamp="1445769481" operations="5"/>
<datapoint name="BidCos-RF.LEQ1462664:1.HUMIDITY" type="HUMIDITY" ise_id="4958" value="65" valuetype="16" valueunit="%" timestamp="1445769481" operations="5"/>
</channel>
Hinter "datapoint name" steht der Name des Datenpunktes. Adressiert wird der momentan in HMCCU aber über den "channel name", den man in der CCU frei vergeben kann sowie den Teil des datapoint names hinter dem letzten Punkt (hier "TEMPERATURE" oder "HUMIDITY").
Das Ganze ist meiner Faulheit geschuldet, mir die kryptischen Datenpunktnamen merken zu müssen. Ich habe den Kanälen sprechende Namen gegeben. Das kann ich mir leichter behalten ;)
Ich habe eine neue Version von HMCCU (IO-Device) und HMCCUDEV (Client-Devices) im Contrib Zweig abgelegt (Link siehe 1. Post).
Die Adressierung von CCU-Kanälen wurde komplett überarbeitet. Die set und get Befehle akzeptieren nun folgende Angaben:
Channel-Name[.Datapoint]
[Interface.]Channel-Address:Channel-Number[.Datapoint]
Das Modul benötigt die Perl-Module XML::Simple und File::Queue.
Das Modul HMCCU enthält bereits Attribute und Programmcode für die folgende Version, die einen RPC-Server enthalten wird. Die RPC Attribute können noch nicht verwendet werden.
Bei der Definition eines HMCCU Devices in FHEM wird die Devicelist der CCU gelesen. Daher muss nach dem Update auf die aktuelle Version FHEM neu gestartet oder das HMCCU Device neu angelegt werden. Wenn in der CCU ein neues Gerät angelegt wird, muss der Befehl get <name> devicelist in FHEM ausgeführt werden.
Bitte die Datei HMCCU_Readme.txt im Contrib Verzeichnis lesen. Dort ist auch die Verwendung von Client Devices beschrieben.
Noch was: das Attribute stateval wurde in statevals umbenannt.
Hi zap,
danke schon mal für den Ausblick auf die RPC Version ;)
Abermal eine Frage:
Ich habe das neue Modul geholt, alles gelöscht und die hmccu wieder neu erstellt, neu gestartet und get hmccu devicelist augeführt.
Leider sehe ich keinerlei Information, dass etwas passiert. Sollten einträge erstellt werden dadurch? in einer Datei?
grüße
und Danke
Du musst "get devicelist" nur ausführen, wenn sich an Geräten in der CCU etwas geändert hat. Die Geräte werden beim FHEM Define automatisch gelesen.
Sehen kann man das Einlesen am Internal DevCount in der Ansicht des HMCCU Devices. Dort sollte eine Zahl > 0 stehen. Derzeit legt HMCCU nicht automatisch irgendwelche Client Devices (Modul HMCCUDEV) an.
Wenn ein HMCCU Device definiert ist, kannst Du CCU Gerätekanäle bzw. Datenpunkte auslesen, z.B.
get <devname> datapoint <addresse>.<datenpunkt>
get <devname> datapoint <channel-name>.<datenpunkt>
Im HMCCU Device wird der ausgelesene Wert dann als Reading gespeichert. Alternativ können für einzelne Geräte mit HMCCUDEV auch Client Devices angelegt werden.
Wichtig ist nur: get devicelist muss mindestens einmal ausgeführt worden sein. Sonst kennen weder HMCCU noch HMCCUDEV Befehle die Kanalnamen oder Kanaladressen. Dann geht nix. Und wenn man das HMCCU Modul reloaded, muss get devicelist ebenfalls ausgeführt werden.
Zap! Das ist genau das Modul, welches ich vermisst habe. Ich verstehe, dass sich mit der FHEM-Architektur nicht leicht ein XML-RPC für die CCU bauen lässt, aber das hier ist als Übergangslösung perfekt. Ich habe mir eine Zeitlang OpenHAB nur aus dem Grund angeschaut, weil die eine ziemlich gute Anbindung an die CCU haben. Leider ist die Unterstützung für den RFXTRx, weswegen ich hauptsächlich zusätzlich zur CCU etwas brauche, miserabel. Ausserdem ist die Entwicklung für FHEM gefühlt wesentlich aktiver. Die Architektur von OH dahingegen ist natürlich schon nett... Allerdings bin ich mehr Freund von Perl ;) Lassen wir das, ich will hier keine Diskussion FHEM vs. OH vom Zaun brechen, vielleicht baut ja mal jemand eine Brücke...
Worum es mir eigentlich geht: Ich habe eben etwas mit deinem Modul gespielt. Lief leider erstmal nicht. Grund: Ich bekomme einen Timeout bei der Devicelist. Meine CCU ist durchaus ziemlich voll. Das Problem konnte ich schnell lösen, ich habe den Timeout beim entsprechenden GetFileFromURL auf 10 Sekunden gesetzt, das reicht mir. Vielleicht könntest Du dazu einen Parameter bei der Deklaration hinzufügen?
Mein erster Versuch war es, einen Schalter zu setzen. Ich würde nämlich als erstes Projekt gerne etwas mit Homebridge (läuft bereits) bauen um meine Homematic-Aktoren zu steuern. Der erste Versuch sieht so aus:
define CCU HMCCU 192.168.1.10
define Licht_Buero HMCCUDEV JEQ0295121 1
attr Licht_Buero IODev CCU
attr Licht_Buero room Homematic,Homekit
So weit, so gut, die Daten werden von der CCU korrekt ausgelesen, Anbindung passt scheinbar.
Bei einem "set Licht_Buero devstate 1" crasht mir allerdings FHEM:
2015.11.26 10:29:25 4: FHEMWEB:192.168.1.23:9811 POST /fhem&fw_id=67&room=Homematic%2CHomekit&cmd=set++Licht_Buero+devstate+1; BUFLEN:0
2015.11.26 10:29:25 5: Cmd: >set Licht_Buero devstate 1<
2015.11.26 10:29:25 4: HttpUtils url=http://192.168.1.10:8181/do.exe?r1=dom.GetObject("BidCos-RF.JEQ0295121:1.STATE").State("1")
2015.11.26 10:29:25 4: http://192.168.1.10:8181/do.exe?r1=dom.GetObject("BidCos-RF.JEQ0295121:1.STATE").State("1"): HTTP response code 200
2015.11.26 10:29:25 4: HttpUtils http://192.168.1.10:8181/do.exe?r1=dom.GetObject("BidCos-RF.JEQ0295121:1.STATE").State("1"): Got data, length: 115
2015.11.26 10:29:25 5: Triggering CCU (1 changes)
2015.11.26 10:29:25 5: Notify loop for CCU OK
Undefined subroutine &main::usleep called at ./FHEM/88_HMCCUDEV.pm line 208.
Zeile 208 => usleep (100000);
Ich glaube usleep ist ein Teil von Time::HiRes welches ich nicht hatte und welches auch nicht geladen war. Ich habe die beiden usleep-Aufrufe auf sleep(1) geändert, damit klappt es.
Nächste Frage: Kann man FHEM irgendwie sagen, dass es sich dabei um einen Schalter handelt?
Ja, Time::Hires wird benötigt. Was meinst Du mit "Schalter"? Sowas in der Form:
set Licht_Buero on
Das sollte mit der aktuellen Version schon gehen:
attr CCU statevals on:true,off:false
Danach bietet Dir das Device im Webinterface automatisch die Links on und off an.
Aber bevor Du jetzt reihenweise CCU Geräte definierst, warte mal noch 2-3 Tage. Habe die Tests für Version 2.0 gestern abgeschlossen. Die neue Version kommt ohne XML-API aus, was einige Befehle deutlich beschleunigt. Außerdem können mit der neuen Version native Homematic Scripts ausgeführt werden, was das Ganze ziemlich flexibel macht ;-)
Muss nur noch die Doku anpassen.
Zitat von: zap am 26 November 2015, 11:57:17
Aber bevor Du jetzt reihenweise CCU Geräte definierst, warte mal noch 2-3 Tage. Habe die Tests für Version 2.0 gestern abgeschlossen. Die neue Version kommt ohne XML-API aus, was einige Befehle deutlich beschleunigt. Außerdem können mit der neuen Version native Homematic Scripts ausgeführt werden, was das Ganze ziemlich flexibel macht ;-)
Muss nur noch die Doku anpassen.
Ich verbeuge mich ;) !
Neue Version mit RPC Server ist nun verfügbar (s. 1. Post in diesem Thread).
Bitte die Voraussetzungen (Perl-Pakete) insbesondere für den RPC-Server beachten (Datei HMCCU_Readme.txt).
Änderungen / Neuerungen:
- RPC Server als separater Prozess
- Verwendet native Homematic Script für die Kommunikation mit der CCU (kein XML-API mehr erforderlich)
- Separate Module für IO, CCU-Geräte und CCU-Kanäle
- Änderungen an Readings im IO Device können an Client-Devices propagiert werden
- Ausführung beliebiger Homematic Scripts aus FHEM heraus. Ergebnisse werden als Readings gespeichert
Einschränkungen:Die RPC Schnittstelle der CCU unterstützt nur BidCos Geräte. Daher aktualisiert der RPC Server z.B. keine CUxD Geräte. Diese müssen per AT Device mittels get Befehl aktualisiert werden.
Nach dem Starten des RPC-Servers vergehen exakt 3 Minuten, bis die ersten Events aus der CCU in FHEM ankommen. Das scheint eine Eigenart der CCU zu sein. Während dieser 3 Minuten reagiert das Web-Interface der CCU sehr träge bis gar nicht.
Der RPC-Server aktualisiert nur Readings/Datenpunkte von definierten Devices. Alle anderen Events werden ignoriert.
Die Kommunikation zwischen dem RPC-Server und FHEM erfolgt über eine Datei basierte Queue. Wer Angst um seine SD-Karte hat, kann die Queue in eine RAM-Disk legen. Wie das geht, ist in HMCCU_Readme.txt beschrieben.
Hi zap,
danke für die Skripte. Leider kommt es bei mir zum regelmässigem Absturz mit folgender Meldung im Log:
Beim Starten von fhem kommt folgende Info:
Use of each() on hash after insertion without resetting hash iterator results in undefined behavior,
Perl interpreter: 0x162b010 at /usr/local/share/perl/5.20.2/File/Queue.pm line 19.
Beim Absturz das hier:
2015.11.26 23:10:17 1: PERL WARNING: Use of each() on hash after insertion without resetting hash iterator
results in undefined behavior, Perl interpreter: 0x9c3010 at /usr/local/share/perl/5.20.2/File/Queue.pm line 19.
at ./FHEM/88_HMCCU.pm line 1063.
Irgendeine Idee?
Hmm, scheint ein Problem im Paket File::Queue zu sein. Ich schau mal nach, welche Version ich nutze. Dann können wir das abgleichen. Bei mir tritt dieser Fehler nicht auf.
In Zeile 1063 in HMCCU wird die File-Queue geöffnet. Werden denn die Queue Files angelegt (per Default /tmp/ccuqueue.idx und /tmp/ccuqueue.dat) und wenn ja steht was drin (more /tmp/ccuqueue.dat).
Update: Das Problem scheint wirklich in Queue.pm zu liegen (Zeile 19), da hier ein Hash während einer Iteration verändert wird => Das ist sehr "uncool". Statt
# convert to lower case
while( my($key, $val) = each %params)
{
delete $params{$key};
$params{ lc($key) } = $val;
}
wäre besser (Vorsicht, nicht getestet):
# convert to lower case
my @keylist = keys %params;
for my $key (@keylist) {
my $val = $params{$key};
delete $params{$key};
$params{lc($key)} = $val;
}
Warum das Problem bei mir nicht auftritt, weiß ich allerdings nicht. Eventuell habe ich eine andere Version von Queue.pm oder vom Perl Interpreter. In der Queue.pm 1.01 in CPAN ist der Fehler noch drin.
Mal sehen, vielleicht veröffentliche ich hier ein Update für Queue.pm oder ich integriere die notwendigen Funktionen direkt in HMCCU nach dem Motto "wenn es gut werden soll, mach es selbst" ;-). Sind nur ein paar Zeilen Code.
Falls also der Absturz von FHEM bei Dir dadurch verursacht wird (und das ist sehr wahrscheinlich), solltest Du den RPC-Server erst wieder nutzen, wenn der Fehler in Queue.pm behoben wurde. Die anderen Funktionen von HMCCU sind davon nicht betroffen. Das Warning beim Starten von FHEM kann dann ignoriert werden.
Hab es eben mal testweise in die Queue.pm eingefügt, Fehler bleibt leider bestehen. Sehr seltsam ;)
grüße
PS: Sollte die neuen Dateien heute nicht schon per update geholt werden? Habe es gestern von Hand geholt, aber ein update (force) holt die neuen Files noch nicht ab.
Wenn sich an der Fehlermeldung (Queue.pm Zeile 19) nichts ändert, sind Deine Änderungen auch nicht aktiv. Diese Fehlermeldung verweist ja eindeutig auf das "each" in Zeile 19 von Queue.pm. Das ist nach der Änderung ja weg. Hast Du FHEM neu gestartet?
Zum Update: Soweit ich weiß, funktioniert das automatische Abholen per Update Befehl nicht bei Modulen im contrib Verzeichnis.
Hi zap, der Hotfix funktioniert.
Ich habe es auf einem Raspberry neu aufgesetzt, und da ging es dann.
Jetzt versuche ich endlich mal, meine Umgebung aufzusetzen, bin froh, endlich von der CCU GUI wegzukommen.
Wenn ich ne Frage zur Konfiguration habe. soll ich nen neuen Thread aufmachen oder hier fragen?
Ich frag erstmal hier, wird wohl mehrere interessieren die es benutzen möchten.
Ich habe Jetzt mal ein Thermostat eingefügt als HMCCUDEV Device, die Werte werden auch abgefragt und dargestellt:
DEF MEQ0XXXXXX
IODev d_ccu
NAME BadHeizThermostat
NR 119
STATE Initialized
TYPE HMCCUDEV
ccuaddr MEQ0182028
ccuif BidCos-RF
ccuname HeizungBad
ccutype HM-CC-RT-DN
statevals devstate
Readings
TemperaturBad.ACTUAL_TEMPERATURE 23.500.000 27.11.2015 13:48:34
TemperaturBad.BATTERY_STATE 3.000.000 27.11.2015 13:48:34
TemperaturBad.BOOST_STATE 0 27.11.2015 13:48:34
TemperaturBad.CONTROL_MODE 0 27.11.2015 13:48:34
TemperaturBad.FAULT_REPORTING 0 27.11.2015 13:48:34
TemperaturBad.PARTY_START_DAY 1 27.11.2015 13:48:34
TemperaturBad.PARTY_START_MONTH 1 27.11.2015 13:48:37
TemperaturBad.PARTY_START_TIME 0 27.11.2015 13:48:34
TemperaturBad.PARTY_START_YEAR 0 27.11.2015 13:48:37
TemperaturBad.PARTY_STOP_DAY 1 27.11.2015 13:48:37
TemperaturBad.PARTY_STOP_MONTH 1 27.11.2015 13:48:37
TemperaturBad.PARTY_STOP_TIME 0 27.11.2015 13:48:37
TemperaturBad.PARTY_STOP_YEAR 0 27.11.2015 13:48:37
TemperaturBad.PARTY_TEMPERATURE 5.000.000 27.11.2015 13:48:34
TemperaturBad.SET_TEMPERATURE 17.000.000 27.11.2015 13:48:34
TemperaturBad.VALVE_STATE 0 27.11.2015 13:48:34
state Initialized 27.11.2015 13:35:26
allerdings ist mir nicht ganz klar, wie ich jetzt einen Wert ändern kann. Alles, was ich versucht habe, bringt eine Fehlermeldung.
Kann mir jemand einen Hinweis dazu geben bitte?
grüße
und Danke
Die Frage kannst Du ruhig hier stellen. Aber zunächst nochmal zum anderen Problem: Ich verwende Perl 5.14.2, also eine ältere Version als Du. Möglicherweise ist mein Perl bei dem Queue.pm Fehler etwas toleranter. Die Queue.pm Version ist die 1.01, also die mit dem Fehler. Ich werde einen Ersatz für die new() Funktion direkt in HMCCU bzw. ccurpcd.pl einbauen. Dann dürfte sich das erledigt haben.
Zu Deinem Problem mit dem Setzen von Werten: Bei dem Wandthermostat kann man nicht alle Datenpunkte setzen, einige können nur gelesen werden. Was auf jeden Fall gehen sollte ist die Einstellung der gewünschten Raumtemperatur. In Deinem Fall
set BadHeizThermostat datapoint 2.SET_TEMPERATURE 23
Bei einem HMCCUDEV Device ist die Geräteadresse ja schon durch die Definition bekannt. Du musst also nur noch die Kanalnummer und den Datenpunkt angeben. Und natürlich den Wert (hier 23 Grad). Die Angabe des Kanalnames ("TemperaturBad") ist hier nicht zulässig, da diese sowohl Geräteadresse als auch Kanalnummer enthält. Hier könnte ich dem Modul vielleicht noch etwas mehr Toleranz beibringen ;-)
Hi zap,
danke für die Antwort. Das ist aber kein Wandthermostat, sondern das am Heizkörper. Dein Befehl mit der 4 statt der 2 hat dann auch gleich funktioniert.
Danke dafür.
Jetzt kann ich endlich anfangen, das ganze sauber umzusetzen.
grüße
Hi zap,
und wieder ich :-D
Leider scheint der RPC Server ein Problem zu haben. Laut Logfile fliegt er auch die Schnauze, starten kann man ihn dennoch nicht, da er noch läuft, der Prozess wenigstens. Hier der gesamte logauszug:
29.11.2015 16:33:16 Shutdown RPC server
29.11.2015 16:33:16 RPC server terminated
29.11.2015 16:33:31 Creating file queue
29.11.2015 16:33:31 Initializing RPC server
29.11.2015 16:33:31 callback server created
29.11.2015 16:33:31 Adding callback for events
29.11.2015 16:33:31 Adding callback for new devices
29.11.2015 16:33:31 Adding callback for deleted devices
29.11.2015 16:33:31 Adding callback for modified devices
29.11.2015 16:33:31 Registering callback
29.11.2015 16:36:31 RPC callback with URL http://172.23.1.52:7401/fh initialized
29.11.2015 16:36:31 Entering server loop. Use kill -SIGINT 22030 to terminate program
29.11.2015 16:36:31 ListDevices
29.11.2015 16:36:32 NewDevice: received 91 device specifications
29.11.2015 23:30:13 Creating file queue
29.11.2015 23:30:13 Initializing RPC server
29.11.2015 23:30:14 Can't create RPC callback server on port 7401. Port in use?
29.11.2015 23:30:14 Error: Can't initialize RPC server
30.11.2015 09:57:54 Creating file queue
Vielleicht kannst du damit etwas anfangen.
PS: Mein System ist: Ubuntu VM 15.10, fhem snapshot.
grüße
Das sieht doch gar nicht so schlecht aus. Ich füge in das Logfile mal ein paar Kommentare ein. Dann wird vielleicht klarer was das passiert:
# RPC Server wird sauber gestoppt
29.11.2015 16:33:16 Shutdown RPC server
29.11.2015 16:33:16 RPC server terminated
# RPC Server wird gestartet, zunächst die File-Queue anlegen
29.11.2015 16:33:31 Creating file queue
# Der Server wird initialisiert
29.11.2015 16:33:31 Initializing RPC server
29.11.2015 16:33:31 callback server created
# Die Callback-Funktionen werden bei der CCU registriert
29.11.2015 16:33:31 Adding callback for events
29.11.2015 16:33:31 Adding callback for new devices
29.11.2015 16:33:31 Adding callback for deleted devices
29.11.2015 16:33:31 Adding callback for modified devices
# Die Callbacks werden initialisiert. Das dauert 3 Minuten
29.11.2015 16:33:31 Registering callback
# Callback Initialisierung war erfolgreich. Der RPC Server für FHEM wartet auf Calls von der CCU
29.11.2015 16:36:31 RPC callback with URL http://172.23.1.52:7401/fh initialized
29.11.2015 16:36:31 Entering server loop. Use kill -SIGINT 22030 to terminate program
# Die CCU hat die Methode "ListDevices" aufgerufen => Wird ignoriert
29.11.2015 16:36:31 ListDevices
# Die CCU hat Infos über 91 CCU Devices an den RPC Server geschickt => Da wird momentan nix mit gemacht
29.11.2015 16:36:32 NewDevice: received 91 device specifications
# Ab hier empfängt der RPC Server Events für CCU Devices. Das wird nicht separat geloggt.
# Hier wird jetzt versucht, bei einem vermutlich schon laufenden Server den Server nochmal zu starten. Das geht in Hose, weil der Port belegt ist
29.11.2015 23:30:13 Creating file queue
29.11.2015 23:30:13 Initializing RPC server
29.11.2015 23:30:14 Can't create RPC callback server on port 7401. Port in use?
29.11.2015 23:30:14 Error: Can't initialize RPC server
30.11.2015 09:57:54 Creating file queue
Du solltest mal prüfen, ob der Prozesse noch läuft:
ps -ef | grep ccurpcd
Du kannst den laufenden killen mit kill -SIGNIT Id. Dann wird er sauber gestoppt. Sehr zu empfehlen, sonst macht die CCU irgendwann mal die Grätsche.
Dann kannst Du noch prüfen, ob im Queue-File /tmp/ccuqueue.dat was drin steht. Das ist ein Textfile. Hier sollten Updates von der CCU drin stehen (Events fangen mit "EV" an).
Wichtig: Es werden nur Datenpunkte von HMCCUCHN oder HMCCUDEV Devices aktualisiert.
Notiz an mich: Beim Starten vom RPC Server prüfen, ob schon einer läuft und ggf. Meldung ins Log schreiben.
Ich habe ein Update für 88_HMCCU.pm und ccurpcd.pl auf Sourceforge bereitgestellt. Zusätzlich habe ich das Modul RPCQueue.pm hochgeladen. Dieses Modul ersetzt das CPAN Modul File::Queue, das leider einen Fehler hat, der mit Perl ab Version 5.20 zum Absturz von FHEM führt. RPCQueue.pm kommt ebenfalls in das FHEM Unterverzeichnis, in dem auch die 88_HMCCU-Module liegen. RPCQueue.pm ist nichts als eine Kopie von File::Queue ohne den Bug ;-)
Neuerungen:
- File::Queue wird nicht mehr verwendet (zumindest bis der Autor von File::Queue den Bug behoben hat)
- HMCCU und ccurpcd prüfen, ob noch ein RPC Server läuft und schreiben entsprechende Meldungen in die Logfiles
- Bei aktivem RPC Server werden nun auch die vorhandenen Readings im IO Device (HMCCU) aktualisiert.
- Der RPC Server schreibt immer nach 250 Events einen Eintrag in sein Logfile (als Lebenszeichen)
Links und weitere Infos wie immer im 1. Post in diesem Thread.
Ich bitte um Hilfe.
Ich habe die "88_HMCCU* and the RPC daemon ccurpcd.pl" in das Verzeichnis FHEM kopiert und die "packages LWP::UserAgent, Time::HiRes and File::Queue. The RPC server ccurpcd.pl requires the packages File::Queue, RPC::XML::Server, RPC::XML::Client, XML::Simple and IO::Socket::INET" installiert.
Dennoch bringt das Define eine Fehlermeldung.
define CCU2 HMCCU 192.168.200.58
Cannot load module HMCCU
Im Logfile steht:
2015.12.01 09:38:49 1: reload: Error:Modul 88_HMCCU deactivated:
Can't locate RPC/XML/Client.pm in @INC (you may need to install the RPC::XML::Client module) (@INC contains: C:/FHEM/fhem-5.6/perl/site/lib C:/FHEM/fhem-5.6/perl/vendor/lib C:/FHEM/fhem-5.6/perl/lib . ./FHEM) at ./FHEM/88_HMCCU.pm line 48.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 48.
Mein Versuch, in der "portableshell" mit "cpan install RPC::XML::Client" brachte eine Fehlermeldung nach einem umfangreichen Test-Durchlauf:
...
Stopping: 'install' failed for 'RPC::XML::Client'.
Jetzt komme ich nicht mehr weiter.
Ohne RPC::XML::Client läuft das nicht. Gibt cpan install irgendwelche anderen Fehlermeldungen aus? Auf welchem Betriebssystem installierst Du das?
BTW: Für die aktuelle Version in Sourceforge benötigst Du File::Queue nicht. Das hat einen Bug. Daher habe ich RPCQueue.pm bereitgestellt. Das kommt ins gleiche Verzeichnis wir die HMCCU Module.
Auf Windows.
Fehlermeldungen gabes eine lange Liste ..
C:\FHEM\fhem-5.6>cpan install RPC::XML::Client
Loading internal null logger. Install Log::Log4perl for logging messages
CPAN: CPAN::SQLite loaded ok (v0.211)
Database was generated on Tue, 01 Dec 2015 08:06:32 GMT
Running install for module 'RPC::XML::Client'
CPAN: Digest::SHA loaded ok (v5.95)
CPAN: Compress::Zlib loaded ok (v2.068)
Checksum for C:\FHEM\fhem-5.6\cpan\sources\authors\id\R\RJ\RJRAY\RPC-XML-0.79.tar.gz ok
tmp-1204 for tmp-1204: No such file or directory at C:\FHEM\fhem-5.6\perl\lib/CPAN/Distribution.pm line 468.
CPAN: Archive::Tar loaded ok (v2.04)
CPAN: File::Temp loaded ok (v0.2304)
CPAN: YAML::XS loaded ok (v0.59)
CPAN: CPAN::Meta::Requirements loaded ok (v2.133)
CPAN: Parse::CPAN::Meta loaded ok (v1.4417)
CPAN: CPAN::Meta loaded ok (v2.150005)
CPAN: Module::CoreList loaded ok (v5.20150912)
Configuring R/RJ/RJRAY/RPC-XML-0.79.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a dmake-style Makefile
Writing Makefile for RPC::XML
Writing MYMETA.yml and MYMETA.json
RJRAY/RPC-XML-0.79.tar.gz
C:\FHEM\fhem-5.6\perl\bin\perl.exe Makefile.PL -- OK
Running make for R/RJ/RJRAY/RPC-XML-0.79.tar.gz
---- Unsatisfied dependencies detected during ----
---- RJRAY/RPC-XML-0.79.tar.gz ----
DateTime::Format::ISO8601 [requires,optional]
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=lib\Apache\RPC\status
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=methods\identity
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=methods\introspection
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=methods\listMethods
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=methods\methodHelp
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=methods\methodSignature
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=methods\multicall
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=methods\status
cp lib/RPC/XML.pm blib\lib/RPC/XML.pm
cp methods\methodSignature.xpl blib\lib\RPC\XML\methodSignature.xpl
cp methods\identity.xpl blib\lib\RPC\XML\identity.xpl
cp lib/RPC/XML/Procedure.pm blib\lib/RPC/XML/Procedure.pm
cp lib/RPC/XML/Server.pm blib\lib/RPC/XML/Server.pm
cp lib/RPC/XML/Parser/XMLLibXML.pm blib\lib/RPC/XML/Parser/XMLLibXML.pm
cp methods\methodHelp.xpl blib\lib\RPC\XML\methodHelp.xpl
cp lib/Apache/RPC/Status.pm blib\lib/Apache/RPC/Status.pm
cp lib/RPC/XML/Parser.pm blib\lib/RPC/XML/Parser.pm
cp methods\multicall.xpl blib\lib\RPC\XML\multicall.xpl
cp methods\introspection.xpl blib\lib\RPC\XML\introspection.xpl
cp lib/RPC/XML/Client.pm blib\lib/RPC/XML/Client.pm
cp lib/RPC/XML/ParserFactory.pm blib\lib/RPC/XML/ParserFactory.pm
cp lib/Apache/RPC/status.xpl blib\lib/Apache/RPC/status.xpl
cp lib/Apache/RPC/Server.pm blib\lib/Apache/RPC/Server.pm
cp methods\status.xpl blib\lib\RPC\XML\status.xpl
cp methods\listMethods.xpl blib\lib\RPC\XML\listMethods.xpl
cp lib/RPC/XML/Parser/XMLParser.pm blib\lib/RPC/XML/Parser/XMLParser.pm
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" -MExtUtils::Command -e cp -- etc\make_method blib\script\make_method
pl2bat.bat blib\script\make_method
RJRAY/RPC-XML-0.79.tar.gz
C:\FHEM\fhem-5.6\c\bin\dmake.exe -- OK
Running make test
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t/*.t
t/00_load.t ..................... ok
t/10_data.t ..................... ok
t/11_base64_fh.t ................ ok
t/12_nil.t ...................... ok
t/13_no_deep_recursion.t ........ ok
t/14_datetime_iso8601.t ......... skipped: DateTime::Format::ISO8601 not available
t/15_serialize.t ................ ok
t/20_xml_parser.t ............... ok
t/21_xml_libxml.t ............... ok
t/25_parser_negative.t .......... ok
t/29_parserfactory.t ............ ok
t/30_procedure.t ................ ok
t/35_namespaces.t ............... ok
t/40_server.t ................... 24/91
t/40_server.t ................... 30/91 # Failed test 'First live req: Check that $res is not an error'
# at t/40_server.t line 245.
# Failed test ''First live req: parsed $res' isa 'RPC::XML::response''
# at t/40_server.t line 248.
# 'First live req: parsed $res' isn't a 'RPC::XML::response'
t/40_server.t ................... 35/91
t/40_server.t ................... 36/91 # Failed test 'Second live req: Check that $res is not an error'
# at t/40_server.t line 293.
# Failed test ''Second live req: parsed $res' isa 'RPC::XML::response''
# at t/40_server.t line 295.
# 'Second live req: parsed $res' isn't a 'RPC::XML::response'
t/40_server.t ................... 41/91 # Failed test 'Third live req: Check that $res is not an error'
# at t/40_server.t line 323.
# Failed test ''Third live req: parsed $res' isa 'RPC::XML::response''
# at t/40_server.t line 325.
# 'Third live req: parsed $res' isn't a 'RPC::XML::response'
t/40_server.t ................... 47/91 # Failed test 'Fourth live req: Check that $res is not an error'
# at t/40_server.t line 368.
# Failed test ''Fourth live req: parsed $res' isa 'RPC::XML::response''
# at t/40_server.t line 370.
# 'Fourth live req: parsed $res' isn't a 'RPC::XML::response'
t/40_server.t ................... 52/91 # Failed test 'RT29351 live req: $res is not an error'
# at t/40_server.t line 417.
# Failed test ''RT29351 live req: parsed $res' isa 'RPC::XML::response''
# at t/40_server.t line 419.
# 'RT29351 live req: parsed $res' isn't a 'RPC::XML::response'
t/40_server.t ................... 57/91
t/40_server.t ................... 59/91 # Failed test ''system.listMethods response' isa 'RPC::XML::response''
# at t/40_server.t line 475.
# 'system.listMethods response' isn't a 'RPC::XML::response'
t/40_server.t ................... 83/91
# Failed test 'Arg-count testing of procedure types'
t/40_server.t ................... 84/91 # at t/40_server.t line 1107.
# got: 'parse-error,parse-error,parse-error'
# expected: '0,1,0'
t/40_server.t ................... 89/91 # Looks like you planned 91 tests but ran 90.
# Looks like you failed 12 tests of 90 run.
t/40_server.t ................... Dubious, test returned 12 (wstat 3072, 0xc00)
Failed 13/91 subtests
(less 43 skipped subtests: 35 okay)
t/40_server_xmllibxml.t ......... 1/62
t/40_server_xmllibxml.t ......... 14/62 # Failed test 'First live req: Check that $res is not an error'
# at t/40_server_xmllibxml.t line 142.
# Failed test ''First live req: parsed $res' isa 'RPC::XML::response''
# at t/40_server_xmllibxml.t line 145.
# 'First live req: parsed $res' isn't a 'RPC::XML::response'
t/40_server_xmllibxml.t ......... 19/62
t/40_server_xmllibxml.t ......... 20/62 # Failed test 'Second live req: Check that $res is not an error'
# at t/40_server_xmllibxml.t line 190.
# Failed test ''Second live req: parsed $res' isa 'RPC::XML::response''
# at t/40_server_xmllibxml.t line 192.
# 'Second live req: parsed $res' isn't a 'RPC::XML::response'
t/40_server_xmllibxml.t ......... 25/62 # Failed test 'Third live req: Check that $res is not an error'
# at t/40_server_xmllibxml.t line 220.
# Failed test ''Third live req: parsed $res' isa 'RPC::XML::response''
# at t/40_server_xmllibxml.t line 222.
# 'Third live req: parsed $res' isn't a 'RPC::XML::response'
t/40_server_xmllibxml.t ......... 31/62 # Failed test 'RT29351 live req: $res is not an error'
# at t/40_server_xmllibxml.t line 269.
# Failed test ''RT29351 live req: parsed $res' isa 'RPC::XML::response''
# at t/40_server_xmllibxml.t line 271.
# 'RT29351 live req: parsed $res' isn't a 'RPC::XML::response'
t/40_server_xmllibxml.t ......... 36/62
t/40_server_xmllibxml.t ......... 38/62 # Failed test ''system.listMethods response' isa 'RPC::XML::response''
# at t/40_server_xmllibxml.t line 323.
# 'system.listMethods response' isn't a 'RPC::XML::response'
t/40_server_xmllibxml.t ......... 62/62 # Looks like you failed 9 tests of 62.
t/40_server_xmllibxml.t ......... Dubious, test returned 9 (wstat 2304, 0x900)
Failed 9/62 subtests
(less 33 skipped subtests: 20 okay)
t/41_server_hang.t .............. ok
t/50_client.t ................... 11/33
t/50_client.t ................... 16/33 # Failed test 'simple_request/system.identity returns correct value'
# at t/50_client.t line 102.
# got: undef
# expected: 'RPC::XML::Server/1.73'
# Failed test 'simple_request/system.identity left $RPC::XML::ERROR empty'
# at t/50_client.t line 104.
t/50_client.t ................... 18/33 # Failed test ''system.identity response' isa 'RPC::XML::string''
# at t/50_client.t line 109.
# 'system.identity response' isn't a 'RPC::XML::string'
t/50_client.t ................... 20/33 # Failed test ''simple_request/system.bad response' isa 'HASH''
# at t/50_client.t line 130.
# 'simple_request/system.bad response' isn't defined
t/50_client.t ................... 23/33 # Failed test ''send_request/system.bad response' isa 'RPC::XML::fault''
# at t/50_client.t line 153.
# 'send_request/system.bad response' isn't a 'RPC::XML::fault'
t/50_client.t ................... 25/33 # Failed test 'fault_handler correctly set $flag'
# at t/50_client.t line 187.
# Failed test ''fault_handler returned value' isa 'RPC::XML::fault''
# at t/50_client.t line 189.
# 'fault_handler returned value' isn't a 'RPC::XML::fault'
t/50_client.t ................... 28/33
t/50_client.t ................... 30/33 # Failed test ''cmpImg return value' isa 'RPC::XML::boolean''
# at t/50_client.t line 260.
# 'cmpImg return value' isn't a 'RPC::XML::boolean'
t/50_client.t ................... 32/33 # Failed test ''cmpImg return value (compression)' isa 'RPC::XML::boolean''
# at t/50_client.t line 276.
# 'cmpImg return value (compression)' isn't a 'RPC::XML::boolean'
# Looks like you failed 9 tests of 33.
t/50_client.t ................... Dubious, test returned 9 (wstat 2304, 0x900)
Failed 9/33 subtests
(less 7 skipped subtests: 17 okay)
t/51_client_with_host_header.t .. ok
t/60_net_server.t ............... skipped: Net::Server tests not reliable on Windows platform
t/70_compression_detect.t ....... ok
t/90_rt50013_parser_bugs.t ...... ok
t/90_rt54183_sigpipe.t .......... skipped: Skipping *NIX signals-based test on Windows platform
t/90_rt54494_blessed_refs.t ..... ok
t/90_rt58065_allow_nil.t ........ ok
t/90_rt58323_push_parser.t ...... ok
Test Summary Report
-------------------
t/40_server.t (Wstat: 3072 Tests: 90 Failed: 12)
Failed tests: 31-32, 37-38, 42-43, 48-49, 53-54, 59, 84
Non-zero exit status: 12
Parse errors: Bad plan. You planned 91 tests but ran 90.
t/40_server_xmllibxml.t (Wstat: 2304 Tests: 62 Failed: 9)
Failed tests: 15-16, 21-22, 26-27, 32-33, 38
Non-zero exit status: 9
t/50_client.t (Wstat: 2304 Tests: 33 Failed: 9)
Failed tests: 16-18, 20, 23, 25-26, 30, 32
Non-zero exit status: 9
Files=25, Tests=953, 173 wallclock secs ( 0.28 usr + 0.09 sys = 0.37 CPU)
Result: FAIL
Failed 3/25 test programs. 30/953 subtests failed.
dmake.exe: Error code 255, while making 'test_dynamic'
RJRAY/RPC-XML-0.79.tar.gz
C:\FHEM\fhem-5.6\c\bin\dmake.exe test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports RJRAY/RPC-XML-0.79.tar.gz
Stopping: 'install' failed for 'RPC::XML::Client'.
C:\FHEM\fhem-5.6>
Ich befürchte, das wird nix unter Windows. Der Fehler bei der Installation ist wohl bekannt:
Zitat
To paraphrase, there seems to be a 'fork' emulation issue on Windows Perl. The failing code is trying to start a child HTTP listener, but there ends up not being any process or protocol listening on the port
Ein Tipp ist wohl, während der Installation die Firewall abzuschalten. Weiß aber nicht, ob das was bringt.
Außerdem ist es fraglich, ob der RPC Server unter Windows funktioniert, insbesondere das Starten aus dem HMCCU Modul heraus.
Bitte nicht falsch verstehen, soll jetzt nicht demotivieren. Nur um Enttäschungen zu vermeiden, wenn es dass am Ende nicht läuft.
SCHADE.
Trotzdem Dank für Deine Mühen.
Hallo Masie,
was spricht denn dagegen, das FHEM in eine virtuelle Ubuntu umgebung zu installieren.
Vorteile: Bei änderungen / update von Windows lässt es sich einfach mitnehmen.
Nachteil: ( für manche ;) ) ist halt Linux
grüße
Hi zap,
vorweg: Ich versuche ehrlich, soviel zu lesen wie ich kann, aber fhem kann durchaus komplex werden ;)
Ich kann ( wie bereits geschrieben ), die Thermostate auslesen, auch die Werte von Hand verändern.
Mein Setup ist leicht anders jetzt:
Name Heizkörper : HzB
setzen der Temperatur: set HzB datapoint 4.SET_TEMPERATURE 25
Jetzt wollte ich allerdings das Tablet UI benutzen, damit meine Frau mich nicht mehr schimpft, weil sie nichts mehr einstellen kann ;)
Dort schaffe ich es allerdings nicht, auch nur die aktuelle Temperatur anzuzeigen, geschweige denn einzustellen. Überall steht etwas von z.b. desired-temp, aber auch eine google Suche bringt mich immer nur auf die gleichen Seiten, allerdings finde ich keine Beschreibung, wie ich an diese Eigenschaften komme. Auch _Clima ist so ein Treffer, der bei mir nirgendwo was auslöst ;)
Vielleicht kannst Du mir bei meinem Verständnissproblem helfen.
gruß und Danke ( und sorry, für das ständige Fragen )
PS: Wenn erwünscht, würde ich auch eine Beschreibung machen, wie das Modul installiert und eingestellt wird, da in der Wiki ja noch kein Eintrag vorhanden ist.
@EdgarM: Zu Deiner Frage später.
Zunächst eine allgemeine Info: Habe ein Update für 88_HMCCU.pm und 88_HMCCUDEV.pm auf Sourceforge bereitgestellt (Link siehe wie immer 1. Post in diesem Thread).
Neu: Der Befehl get channel bei HMCCU und bei HMCCUDEV akzeptiert nun die Angabe mehrerer Kanäle. Bei einem HMCCUDEV Device kann man nun folgende Abfrage absetzen:
get mydevice channel 0.^UNREACH 1
Mit diesem Befehl wird der Datenpunkt 'UNREACH' von Kanal 0 und alle Datenpunkte von Kanal 1 gelesen.
Für das IO Device sieht der analoge Befehl so aus:
get mydevice channel LEQ1234567:0.^UNREACH LEQ1234567:1
Zitat von: EdgarM am 01 Dezember 2015, 16:17:06
Hi zap,
vorweg: Ich versuche ehrlich, soviel zu lesen wie ich kann, aber fhem kann durchaus komplex werden ;)
Das stimmt. Deshalb mache ich nur die Dinge, die mit der CCU nicht gehen, mit FHEM.
Zitat
Ich kann ( wie bereits geschrieben ), die Thermostate auslesen, auch die Werte von Hand verändern.
D.h. Du hast Readings mit den Werten in Deinen Devices. Das hört sich schon mal gut an.
Zitat
Jetzt wollte ich allerdings das Tablet UI benutzen, damit meine Frau mich nicht mehr schimpft, weil sie nichts mehr einstellen kann ;)
Dort schaffe ich es allerdings nicht, auch nur die aktuelle Temperatur anzuzeigen, geschweige denn einzustellen. Überall steht etwas von z.b. desired-temp, aber auch eine google Suche bringt mich immer nur auf die gleichen Seiten, allerdings finde ich keine Beschreibung, wie ich an diese Eigenschaften komme. Auch _Clima ist so ein Treffer, der bei mir nirgendwo was auslöst ;)
Das mit der Frau kenne ich. Die Darstellung auf einem Tablet ist auch der Grund für die Entwicklung von HMCCU. Allerdings lasse ich es etwas einfacher angehen. Tablet UI ist sicher mit das komplexeste Frontend, aber hat auch die meisten Möglichkeiten. Ich habe mich allerdings noch nicht damit beschäftigt, daher kann ich Dir kaum helfen. Im Zweifel solltest Du Fragen dazu im Bereich "Frontends" stellen.
Ich habe mir mal einige der HTML Beispiel Templates von Tablet-UI angeschaut. Da gibt es Einträge wie:
<div data-type="label" data-devices="xyz" data-get="reading" ...
Damit wird anscheinend ein Textfeld zum Anzeigen eines Readings definiert. Bei data-devices müsste vermutlich "HzB" stehen und bei Reading eben der Name des Wertes, der angezeigt werden soll. Nach diesem Schema scheinen viele Elemente bei Tablet-UI definiert zu werden. Aber wie gesagt: ich kenne mich damit nicht wirklich aus. Ich verwende für die Darstellung das Modul INFOPANEL, das aber lange nicht so flexibel ist wie Tablet UI.
Was ich allerdings nicht verstehe: Warum kann Deine Frau das Thermostat nicht per Hand bedienen? Im Zweifel mach es wie ich und kopple das Thermostat am Heizkörper mit einem Wandthermostat. Damit kann man sehr komfortabel die Heizkörper bedienen.
Hi zap,
die Regierung bestimmt, was wir tun ;)
Wir haben nur ein Wandthermostat im Wohnzimmer, in den restlichen Zimmern lediglich Heizungsthermostate. Früher(TM) haben wir den Hauptzulauf an oder ausgemacht, jetzt bleibt der immer an. Deswegen müßte man alle Heizungen von Hand ändern, und das wäre dann schon nervig. Und mein Hauptargument für SmartHome war ja, dass man das einfach und zentral machen kann. ... Irgendwann :-D
Ich mache es jetzt einfach mal so wie du. Ich fange gerade an, mich in RSS einzulesen, vielleicht verstehe ich dann genug für den nächsten Schritt Und meine Frau kann dann schon mal damit spielen ;)
Danke für Deine freundliche Unterstützung.
grüße
Hi Leute
Ich bin mit meinem Latein am Ende wenn ich die CCU definieren möchte, bekomme ich immer die Fehlermeldung "Cannot load module HMCCU".
Rechte passen, XML::Simple ist auch installiert.
Ich komme nicht mehr weiter, bitte helft mir :D.
In meinem Log steht folgendes:
reload: Error:Modul 88_HMCCU deactivated:
Glob not terminated at ./FHEM/88_HMCCU.pm line 26.
Glob not terminated at ./FHEM/88_HMCCU.pm line 26.
Gruß Chavalaloco
Zitat von: chavalaloco am 02 Dezember 2015, 22:31:16
reload: Error:Modul 88_HMCCU deactivated:
Glob not terminated at ./FHEM/88_HMCCU.pm line 26.
Glob not terminated at ./FHEM/88_HMCCU.pm line 26.
Das ist krass. Die Meldung kommt vom Perl Lexer und besagt eigentlich, dass ein '<' als Start eines HTML-Tags erkannt wurde aber das abschließende '>' fehlt. Nun ist Zeile 26 in 88_HMCCU.pm eine Kommentarzeile. In der wird zwar '<' als Kennzeichnung eines Parameters verwendet. Aber 1. mit abschließendem '>' und 2. in einem Kommentar. Das sollte Perl also eigentlich ignorieren.
Seltsam ist auch, dass das Problem anscheinend nur bei Dir auftritt (wobei ich nicht weiß, wie viele Leute das Modul verwenden). Ich vermute, dass die Datei irgendwie korrupt ist.
Hier nochmal die Zeile mit dem Fehler:
# get <name> parfile [<parfile>]
Frage: Ich nehme an, Du hast die aktuelle Version des Modules aus Sourceforge runter geladen?
Bitte: Kannst Du mit die Datei mal per Mail schicken oder die ersten 30 Zeilen hier posten (bitte nicht die ganze Datei posten).
Wenn Du selbst testen möchtest, wirf einfach alle Kommentarzeilen am Anfang der Datei raus und versuche es nochmal.
BTW: XML::Simple wird nicht mehr benötigt. Bitte aber darauf achten, dass folgende Dateien im FHEM-Modulverzeichnis ( /FHEM) liegen:
88_HMCCU.pm, 88_HMCCUDEV.pm, 88_HMCCUCHN.pm, RPCQueue.pm, ccurpcd.pl
Ich habe im FHEM Sourceforge Repository die Version 2.2 der HMCCU Module bereitgestellt.
Die Module unterstützen nun das
Auslesen und Setzen von Konfigurationsparametern von CCU Geräten und Kanälen. Der Zugriff erfolgt mit RPC (putParamset, getParamset). Daher werden nur BidCos Devices unterstützt.
Folgende Befehle sind für HMCCU-Devices nun verfügbar:
get
devname config {devicename|deviceaddress|channelname|channeladdress}
get
devname configdesc {devicename|deviceaddress|channelname|channeladdress}
set
devname config {devicename|deviceaddress|channelname|channeladdress} parameter=value [...]
Für HMCCUDEV-Devices (Geräteadresse über Definition bekannt):
get
devname config [channelnumber]
get
devname configdesc [channelnumber]
set
devname config [channelnumber] parameter=value [...]
Für HMCCUCHN-Devices (Geräteadresse und Kanalnummer über Definition bekannt):
get
devname config
get
devname configdesc
set
devname config parameter=value [...]
Zu beachten:
- Der Befehl get configdesc zeigt eine Beschreibung der Parameter inklusive Datentyp und Read/Write Flags an. Diese Beschreibung ist nicht für alle Parametersets verfügbar. Also nicht wundern, wenn der Befehl "ins Leere läuft"
- Der Befehl get config liest Parameter und speichert die Werte als Readings mit dem Präfix "R-", sofern das Attribut ccureadings=1 ist. Im Gegensatz zu normalen Datenpunkt bezogenen Readings werden diese nicht an Client-Devices propagiert.
- Beim Setzen von Parametern muss unbedingt auf das korrekte Format der Werte geachtet werden. So müssen z.B. Dezimalwerte manchmal mit 6 Nachkommastellen angegeben werde
- Einige Parameter akzeptieren nur Werte in bestimmten nummerischen Bereichen
- Einige Parameter lassen sich nicht setzen, obwohl sie von get configdesc als beschreibbar ausgegeben werden.
- Thermostate haben eine sehr großen Anzahl an Parametern. Das Auslesen produziert entsprechend viele Readings. Ich denke noch über eine Filterfunktion nach ;-)
Beispiel: Temperaturwerte für bestimmte Tageszeiten in einem Thermostaten setzen
set CCU config KL-SZ-TH P1_TEMPERATURE_FRIDAY_1=17.000000 P1_TEMPERATURE_FRIDAY_2=21.000000
Beispiel für Parameter-Readings:
R-KL-SZ-TH.LOCAL_RESET_DISABLE 0 2015-12-04 17:28:30
R-KL-SZ-TH.LOW_BAT_LIMIT 2.200000 2015-12-04 17:28:30
R-KL-SZ-TH.MANU_MODE_PRIORITIZATION 1 2015-12-04 17:28:30
R-KL-SZ-TH.MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE 0 2015-12-04 17:28:30
R-KL-SZ-TH.MODUS_BUTTON_LOCK 0 2015-12-04 17:28:30
R-KL-SZ-TH.P1_ENDTIME_FRIDAY_1 420 2015-12-04 17:28:30
R-KL-SZ-TH.P1_ENDTIME_FRIDAY_10 1440 2015-12-04 17:28:30
R-KL-SZ-TH.P1_ENDTIME_FRIDAY_11 1440 2015-12-04 17:28:30
R-KL-SZ-TH.P1_ENDTIME_FRIDAY_12 1440 2015-12-04 17:28:30
Hinweis: Die Datei HMCCU_Readme.txt ist noch nicht aktualisiert.
Neue Version von 88_HMCCU.pm eingecheckt. Es steht nun der Befehl "get deviceinfo" zur Verfügung. Der Befehl gibt eine Liste aller Kanäle und Datenpunkte eines CCU Devices aus. Sehr hilfreich bei der Definition und Nutzung von HMCCU Client-Devices in FHEM.
Beispiel:
get CCU deviceinfo KEQ0038200
Ausgabe:
Channel KEQ0038200:0 ST-WZ-Bass:0
DP BidCos-RF.KEQ0038200:0.UNREACH = false
DP BidCos-RF.KEQ0038200:0.STICKY_UNREACH = false
DP BidCos-RF.KEQ0038200:0.CONFIG_PENDING = false
DP BidCos-RF.KEQ0038200:0.LOWBAT = false
DP BidCos-RF.KEQ0038200:0.DUTYCYCLE = false
DP BidCos-RF.KEQ0038200:0.RSSI_DEVICE = 1
DP BidCos-RF.KEQ0038200:0.RSSI_PEER = 207
Channel KEQ0038200:1 ST-WZ-Bass:1
DP BidCos-RF.KEQ0038200:1.STATE = false
DP BidCos-RF.KEQ0038200:1.ON_TIME =
DP BidCos-RF.KEQ0038200:1.INHIBIT = false
Gute Idee!
Hallo,
ich verfolge der Beitrag schon eine weile.
Ich finde die Idee super, das würde heißen man muss das HM Protokoll nicht regenerieren.
Ich hätte drei Fragen dazu.
* Wie ist die Reaktionszeit in FHEM wenn ein Sensor (Taster) gedrückt wird welcher über die CCU eingebunden wurde?
D.h. kann ich diese noch in notify einbinden und in "Echtzeit " damit andere Aktoren schalten.
*Wie ist die Reaktionszeit beim Schalten von Aktoren die mit der CCU gepaired sind und über FHEM schalten möchte?
*Wie würde die Pflege des Moduls aussehen, der Support von Martin für HM ist sensationell.
Ich will hiermit aber niemanden kritisieren :-)
Schöne Grüße
Hannes
Gesendet von meinem SM-T715 mit Tapatalk
Zitat von: AHA1805 am 09 Dezember 2015, 17:35:59
* Wie ist die Reaktionszeit in FHEM wenn ein Sensor (Taster) gedrückt wird welcher über die CCU eingebunden wurde?
D.h. kann ich diese noch in notify einbinden und in "Echtzeit " damit andere Aktoren schalten.
Es gibt bei Einsatz von HMCCU zwei Möglichkeiten, in FHEM vom Drücken eines Tasters zu erfahren:
1) Man definiert ein AT Device und fragt regelmäßig den Zustand eines CCU Gerätes ab. Bei einem Intervall von wenigen Sekunden würde die Zustandsänderung entsprechend schnell in FHEM ankommen.
2) Man nutzt den HMCCU RPC-Server. Dieser Server wird von der CCU sofort benachrichtigt, wenn sich ein Status ändert. Da ich den RPC-Server als externen Prozess implementieren musste (FHEM ist für eine direkte Implementierung nicht so gut geeignet), gibt es auch hier eine Zeitdifferenz. Der RPC-Server schreibt Ereignisse von der CCU (z.B. das Drücken eines Tasters) in eine Queue. Diese Queue wird von HMCCU in definierbaren Intervallen abgefragt. Derzeit sind 3, 5 oder 10 Sekunden vorgesehen. Über den attr Befehl können aber auch andere Intervalle eingestellt werden. Ich würde hier aber nicht unter 2 Sekunden gehen. D.h. FHEM erfährt spätestens 2 Sekunden nach dem Drücken des Tasters davon.
Achtung! Die RPC Schnittstelle der CCU hat den Nachteil, dass sie nur BidCos Devices unterstützt. Wenn Du also CUxD einsetzt, funktioniert die Benachrichtigung über den RPC-Server nicht. Für diese Geräte bleibt nur der AT Befehl.
Zitat
*Wie ist die Reaktionszeit beim Schalten von Aktoren die mit der CCU gepaired sind und über FHEM schalten möchte?
Es gib keine wahrnehmbare Verzögerung. Das Ausführen des Schaltbefehls erfolgt sofort per Homematic Script.
Zitat
*Wie würde die Pflege des Moduls aussehen, der Support von Martin für HM ist sensationell.
Ich habe das Modul entwickelt, da ich es selbst benötige. Alles was von der CCU nicht unterstützt wird, mache ich mit FHEM (und nur das). Da ich gerne eine FHEM basierte einheitliche Bedienoberfläche auf einem Tablet einsetzen möchte, brauchte ich eine Möglichkeit, von FHEM aus mit der CCU zu kommunizieren.
Fehler versuche ich zeitnah zu beheben, da sie vermutlich auch mich direkt betreffen. Ich kann hier aber keine Reaktionszeit garantieren, da ich einen relativ stressigen Job und einige zeitaufwändige Hobbies habe und die Entwicklung nur nebenher läuft.
Über funktionale Erweiterungen würde ich erst mal nachdenken, ob sie für alle Nutzer sinn machen und sie dann (bei vertretbarem Aufwand) umsetzen. Aber da das Ganze Open Source ist, steht es jedem frei, den Code an die eigenen Bedürfnisse anzupassen.
Hallo,
HMCU ist ja genau, was ich gesucht hatte. Ich habe einen raspberry mit fhem laufen, über den ich ein paar Funktsteckdosen, Rolldaären usw ansteuere. Alles nur in Senderichtung: 433Mhz Sender oder FS20 UART Sender. Klappt soweit gut. Jetzt will ich auch ein paar Sensoren (Taster, Fensterkontake usw anschließen). Ich habe mir dazu gerade eine Homatic CCU2 zugelegt und geschaut, wie ich die an meinen PI mit fhem anschließen kann.
Das Anlernen eines Tasters HM-PB-2-WM55 an die CCU hat auch geklappt. Das Auslösen des Tasters soll an FHEM weitergereicht werden und dort halt Vorgänge auslösen. Dazu habe ich HMCCU auf dem PI installiert (btw: die Dokumentation liest sich gut!).
Ich kann auch problemlos eine Systemvariable von FHEM auf der CCU schalten.
Den in der CCU angelernten Taster sehe ich auch in FHEM, soweit so gut.
Aber wie kriege ich ein event mit, wenn der Taster ausgelöst wird?
Mit at abfragen, wird ja wohl nichts werden, der Zustandswechsel ist ja nicht dauerhaft.
Also RPC-Server? Den kriege ich nicht so recht ans Laufen. Wenn ich den anschalte, startet er brav und schreibt ein langweiliges Logfile ohne aufregende Einträge:
13.12.2015 19:49:39 Creating file queue
13.12.2015 19:49:39 Initializing RPC server
13.12.2015 19:49:40 callback server created
13.12.2015 19:49:40 Adding callback for events
13.12.2015 19:49:40 Adding callback for new devices
13.12.2015 19:49:40 Adding callback for deleted devices
13.12.2015 19:49:40 Adding callback for modified devices
13.12.2015 19:49:40 Registering callback
Außerdem scheint er FHEM lahmzulegen. Wenn der RPC-Server läuft, bringt ein
get d_ccu devicelist
den gesamten FHEM-Prozess ohne relevante Einträge im fhem.log ins Nirwana (web-Oberfläche ist tot, kein CPU-Verbrauch). Das File in /tmp enthält nur 1 Byte.
Meine Konfiguration:
define d_ccu HMCCU hm-ccu2
attr d_ccu ccureadings 1
attr d_ccu parfile /opt/fhem/scripts/hmvalues.txt
# hängt, wenn aktiviert
#attr d_ccu rpcinterval 3
#attr d_ccu rpcserver on
attr d_ccu statevals on:true,off:false
attr d_ccu stripchar :
attr d_ccu substitute false:closed,true:open
attr d_ccu verbose 5
define d_hm_dw_window HMCCUDEV T1 readonly
attr d_hm_dw_window IODev d_ccu
attr d_hm_dw_window alias T1
attr d_hm_dw_window ccureadings 1
attr d_hm_dw_window room test
attr d_hm_dw_window substitute false:closed,true:open
attr d_hm_dw_window verbose 5
Was mache ich falsch?
Ach ja, alle 10 Minuten beschwert fhem sich über die leere Parameterfile hmvalues.txt
2015.12.13 20:15:00 1: HMCCU: d_ccu Empty parameter file
2015.12.13 20:15:00 3: at_ccu: HMCCU: d_ccu Empty parameter file
2015.12.13 20:25:00 1: HMCCU: d_ccu Empty parameter file
2015.12.13 20:25:00 3: at_ccu: HMCCU: d_ccu Empty parameter file
Wozu dient diese Datei und wie fülle ich sie?
Noch eine kleine Beobachtung: ich mache gerne ein tail -f auf eine log-Datei. Mache ich das für ccurpcd.log, merkt fhem wohl, dass da jemand einen Finder auf der Datei hat und meckert:
2015.12.13 19:40:17 1: HMCCU: Externally launched RPC server detected. Kill process manually with command kill -SIGINT 32656
Das Vorhandensein einer Daemon-Instanz über ein filehandle auf der Logdatei zu ermitteln, ist kreativ, aber eher unüblich. Da könnte ein Satz in der Doku helfen.
Hallo zap,
Danke für die schnelle Antwort.
Gruß Hannes
Gesendet von meinem SM-T715 mit Tapatalk
Zitat von: mifh am 13 Dezember 2015, 20:52:37
Aber wie kriege ich ein event mit, wenn der Taster ausgelöst wird?
Habe leider keinen Taster, kann es daher nicht testen. RPC Server dürfte beim Schalten einen Event liefern. Die Frage ist, ob es einen Datenpunkt gibt, in dem die CCU den letzten Schaltvorgang speichert. Dann könnte man auch AT nutzen. Die Datenpunkte bekommst Du mit get d_ccu deviceinfo Device-Name/Device-Address
Zitat
Also RPC-Server? Den kriege ich nicht so recht ans Laufen. Wenn ich den anschalte, startet er brav und schreibt ein langweiliges Logfile ohne aufregende Einträge (...) Außerdem scheint er FHEM lahmzulegen. Wenn der RPC-Server läuft, bringt ein
get d_ccu devicelist
den gesamten FHEM-Prozess ohne relevante Einträge im fhem.log ins Nirwana (web-Oberfläche ist tot, kein CPU-Verbrauch). Das File in /tmp enthält nur 1 Byte.
Die Einträge in ccurpcd.log sollten so aussehen, wenn der RPC-Server erfolgreich gestartet wurde:
13.12.2015 19:42:49 Creating file queue
13.12.2015 19:42:49 Initializing RPC server
13.12.2015 19:42:49 callback server created
13.12.2015 19:42:49 Adding callback for events
13.12.2015 19:42:49 Adding callback for new devices
13.12.2015 19:42:49 Adding callback for deleted devices
13.12.2015 19:42:49 Adding callback for modified devices
13.12.2015 19:42:49 Registering callback
13.12.2015 19:45:50 RPC callback with URL http://192.168.1.12:7401/fh initialized
13.12.2015 19:45:50 Entering server loop. Use kill -SIGINT 18261 to terminate program
13.12.2015 19:45:50 ListDevices
13.12.2015 19:45:52 NewDevice: received 176 device specifications
13.12.2015 19:53:29 Received 250 events from CCU since last check
: zwischen "Registering callback" und "RPC callback with ..." vergehen immer exakt 3 Minuten. Während dieser 3 Minuten sollte man die Finger von der CCU Oberfläche lassen und auch keinen HMCCU Befehl von FHEM aus absetzen. Das geht meistens in die Hose ;-). (die RPC Schnittstelle ist ein "zartes Pflänzchen", das sehr sensibel reagiert). Die letzte Meldung "Received 250 ..." kommt alle 250 events von der CCU um anzuzeigen, dass der RPC-Server noch lebt.
Probiere mal folgendes: Stoppe FHEM. Stoppe den RPC-Server, wenn er noch läuft mit kill -SIGINT Prozess-Id. Warte bis er nicht mehr läuft (kann einige Sekunden dauern). Starte nun FHEM mit rpcserver = off bzw. auskommentiertem Attribut. Starte nun den RPC-Server aus FHEM heraus mit attr d_ccu rpcserver on. Warte 3-4 Minuten. Deine Client-Devices sollten nun aktualisiert werden. Falls nicht, prüfe mal ccurpcd.log, ob alles wie oben gelistet aussieht.
Zitat
Ach ja, alle 10 Minuten beschwert fhem sich über die leere Parameterfile hmvalues.txt
Ich nehme an, Du hast einen AT definiert mit dem Befehl "get d_ccu parfile". Mit einer solchen Parameterdatei kannst Du Batch mäßig eine ganze Liste von Kanälen/Datenpunkten auf einmal abfragen. Der Aufbau der Datei ist im Readme beschrieben. Sieht im Prinzip so aus:
{Channel-Name|Channel-Address}[.Datapoint_Expression] [Substitute_Rule]
Also z.B.
# Hole alle Datenpunkte die TEMP enthalten
LEQ1234567:1.TEMP
# Hole alle Datenpunkte, die mit RSSI beginnen
LEQ1212121:0.^RSSI.*
# Hole den Datenpunkt STATE und ersetze die Werte
LEQ3234355:1.^STATE$ true:on,false:off
# Hole alle Datenpunkte
LEQ3434545:2
usw.
Zitat
Noch eine kleine Beobachtung: ich mache gerne ein tail -f auf eine log-Datei. Mache ich das für ccurpcd.log, merkt fhem wohl, dass da jemand einen Finder auf der Datei hat und meckert:
2015.12.13 19:40:17 1: HMCCU: Externally launched RPC server detected. Kill process manually with command kill -SIGINT 32656
Das interpretierst Du falsch. So eine innovative Prozess-Erkennung per Filehandle würde ich mir zwar zutrauen, aber ganz so fies bin ich dann doch nicht ;-)
Die Fehlermeldung besagt nur, dass Du versucht hast, per attr rpcserver on den RPC-Server zu starten, obwohl noch ein Prozess aktiv ist, dessen PID HMCCU nicht kennt. Gründe dafür können sein, dass zwischenzeitlich FHEM abgeschmiert war und neu gestartet wurde, oder dass HMCCU neu geladen wurde, oder dass der RPC-Server manuell von Linux aus gestartet wurde. Kann auch sein, dass der RPC-Server nicht beendet wird, wenn man FHEM anhält. In diesem Fall sorry, muss ich mal testen.
Noch ein paar allgemeine Anmerkungen:
- get devicelist ist nur erforderlich, wenn das Modul HMCCU per reload neu geladen wird oder sich ein Gerät in der CCU geändert hat. Beim define eines HMCCU Device wird get devicelist automatisch ausgeführt. Die erfolgreiche Ausführung ist am Internal "devcount" im HMCCU Device zu erkennen (>0).
- Das Attribut substitute arbeitet im Zusammenhang mit dem RPC-Server leider nicht korrekt bzw. wird ignoriert. Fix dafür inklusive einer deutlichen funktionalen Erweiterung der Ersetzung von Werten heute oder morgen per Update.
Hallo Zap
Das war ja eine fixe Antwort, danke sehr. Das stellt die meisten Profisupporter doch in den Schatten :)
Die Idee mit dem Datenpunkt probiere ich mal aus. Wäre ja schon etwas unelegant, sich die Werte per AT herzupollen und dann auf Änderung zu vergleichen. Aber wenn es ginge...
Vielen Dank für den Hinweis mit dem parfile. Jetzt habe auch ich verstanden, wozu das da ist :)
Leider kriege ich den RPCserver immer noch nicht ans Laufen. Ich habe das so gemacht, wie von Dir beschrieben: FHEM stoppen, Neustart ohne RPC Server, RPC Server manuell starten, Finger weg von FHEM und CCU.
Ich habe das mal mitprotokolliert:
pi@pi3 /opt/fhem $ ps aux | grep perl
fhem 2454 1.2 5.3 25472 23748 ? S 19:49 0:11 perl /opt/fhem/fhem.pl /opt/fhem/fhem.cfg
pi 3039 0.0 0.4 4144 1868 pts/0 S+ 20:04 0:00 grep --color=auto perl
pi@pi3 /opt/fhem $ ps aux | grep perl
pi 3041 0.0 0.4 4144 1832 pts/0 S+ 20:04 0:00 grep --color=auto perl
pi@pi3 /opt/fhem $ /etc/init.d/fhem start
Starting fhem...
Can't open ./log/fhem-2015-12.log: Keine Berechtigung at fhem.pl line 2174.
pi@pi3 /opt/fhem $ !ps
ps aux | grep perl
pi 3048 0.0 0.4 4144 1888 pts/0 S+ 20:05 0:00 grep --color=auto perl
pi@pi3 /opt/fhem $ sudo /etc/init.d/fhem start
Starting fhem...
pi@pi3 /opt/fhem $ ps aux | grep perl
fhem 3052 106 2.4 14520 10864 pts/0 R 20:05 0:03 perl fhem.pl fhem.cfg
pi 3054 0.0 0.3 4144 1772 pts/0 S+ 20:05 0:00 grep --color=auto perl
pi@pi3 /opt/fhem $ ps aux | grep perl
fhem 3052 39.1 5.2 27044 23160 pts/0 S 20:05 0:10 perl fhem.pl fhem.cfg
fhem 3059 87.0 3.8 20300 17020 pts/0 R 20:05 0:07 /usr/bin/perl ./FHEM/ccurpcd.pl hm-ccu2 2001 /tmp/ccuqueue ./log/ccurpcd.log
pi 3065 0.0 0.4 4144 1864 pts/0 S+ 20:05 0:00 grep --color=auto perl
pi@pi3 /opt/fhem $ date
Mo 14. Dez 20:06:06 CET 2015
pi@pi3 /opt/fhem $ cd log
pi@pi3 /opt/fhem/log $ ls -l
insgesamt 1780
-rw-r--r-- 1 fhem dialout 2085 Dez 14 20:05 ccurpcd.log
-rw-r--r-- 1 fhem dialout 6508 Dez 14 20:04 eventTypes.txt
-rw-r--r-- 1 fhem dialout 183926 Okt 31 2014 fhem-2014-10.log
-rw-r--r-- 1 fhem dialout 68297 Nov 30 2014 fhem-2014-11.log
-rw-r--r-- 1 fhem dialout 464297 Dez 31 2014 fhem-2014-12.log
-rw-r--r-- 1 fhem dialout 46116 Jan 31 2015 fhem-2015-01.log
-rw-r--r-- 1 fhem dialout 28078 Feb 28 2015 fhem-2015-02.log
-rw-r--r-- 1 fhem dialout 78534 Mär 31 2015 fhem-2015-03.log
-rw-r--r-- 1 fhem dialout 69695 Apr 30 2015 fhem-2015-04.log
-rw-r--r-- 1 fhem dialout 28717 Mai 31 2015 fhem-2015-05.log
-rw-r--r-- 1 fhem dialout 50367 Jun 30 22:43 fhem-2015-06.log
-rw-r--r-- 1 fhem dialout 43131 Jul 31 22:43 fhem-2015-07.log
-rw-r--r-- 1 fhem dialout 58450 Aug 31 19:24 fhem-2015-08.log
-rw-r--r-- 1 fhem dialout 39423 Sep 30 22:55 fhem-2015-09.log
-rw-r--r-- 1 fhem dialout 5134 Okt 31 22:43 fhem-2015-10.log
-rw-r--r-- 1 fhem dialout 84598 Nov 30 22:43 fhem-2015-11.log
-rw-r--r-- 1 fhem dialout 462448 Dez 14 20:05 fhem-2015-12.log
-rw-r--r-- 1 fhem dialout 3550 Dez 14 20:04 fhem.save
-rw-r--r-- 1 fhem root 847 Sep 3 05:54 report_snd_jl2.log
pi@pi3 /opt/fhem/log $ cat ccurpcd.log
13.12.2015 16:25:35 Creating file queue
13.12.2015 16:25:35 Initializing RPC server
13.12.2015 16:25:36 callback server created
13.12.2015 16:25:36 Adding callback for events
13.12.2015 16:25:36 Adding callback for new devices
13.12.2015 16:25:36 Adding callback for deleted devices
13.12.2015 16:25:36 Adding callback for modified devices
13.12.2015 16:25:36 Registering callback
13.12.2015 19:41:56 Creating file queue
13.12.2015 19:41:56 Initializing RPC server
13.12.2015 19:41:58 callback server created
13.12.2015 19:41:58 Adding callback for events
13.12.2015 19:41:58 Adding callback for new devices
13.12.2015 19:41:58 Adding callback for deleted devices
13.12.2015 19:41:58 Adding callback for modified devices
13.12.2015 19:41:58 Registering callback
13.12.2015 19:49:39 Creating file queue
13.12.2015 19:49:39 Initializing RPC server
13.12.2015 19:49:40 callback server created
13.12.2015 19:49:40 Adding callback for events
13.12.2015 19:49:40 Adding callback for new devices
13.12.2015 19:49:40 Adding callback for deleted devices
13.12.2015 19:49:40 Adding callback for modified devices
13.12.2015 19:49:40 Registering callback
13.12.2015 20:08:07 Creating file queue
13.12.2015 20:08:07 Initializing RPC server
13.12.2015 20:08:08 callback server created
13.12.2015 20:08:08 Adding callback for events
13.12.2015 20:08:08 Adding callback for new devices
13.12.2015 20:08:08 Adding callback for deleted devices
13.12.2015 20:08:08 Adding callback for modified devices
13.12.2015 20:08:08 Registering callback
14.12.2015 19:32:43 Creating file queue
14.12.2015 19:32:43 Initializing RPC server
14.12.2015 19:32:43 Can't connect to CCU
14.12.2015 19:32:43 Error: Can't initialize RPC server
14.12.2015 20:05:43 Creating file queue
14.12.2015 20:05:43 Initializing RPC server
14.12.2015 20:05:45 callback server created
14.12.2015 20:05:45 Adding callback for events
14.12.2015 20:05:45 Adding callback for new devices
14.12.2015 20:05:45 Adding callback for deleted devices
14.12.2015 20:05:45 Adding callback for modified devices
14.12.2015 20:05:45 Registering callback
Wie Du siehst, kommt der nicht über das hinaus: Kein RPC callback with URL http://192.168.1.12:7401/fh initialized zu sehen.
14.12.2015 20:05:43 Creating file queue
14.12.2015 20:05:43 Initializing RPC server
14.12.2015 20:05:45 callback server created
14.12.2015 20:05:45 Adding callback for events
14.12.2015 20:05:45 Adding callback for new devices
14.12.2015 20:05:45 Adding callback for deleted devices
14.12.2015 20:05:45 Adding callback for modified devices
14.12.2015 20:05:45 Registering callback
Sieht ja so aus, als würde die CCU an dieer Stelle nicht antworten:
$client->send_request ("init",$callbackurl,"CB1");
An der CCU sollte der RPC Dienst laufen. Kann man das irgendwo prüfen? In der Anleitung schlägst Du das vor:
http://hm-ccu2/config/xmlapi/devicelist.cgi?show_internal=1
Das beantwortet die CCU mit einem 404.
Hast Du irgend eine Idee dazu?
Gruß
Michael
Ja, der RPC Server wird tatsächlich nicht richtig initialisiert. Muss ich mir mal anschauen ... wird aber heute nix mehr.
Könnte natürlich sein, dass der RPC Prozess auf der CCU abgeschmiert ist. Werde in der kommenden Version einen Check einbauen.
Die Test-URL hat nichts mit dem RPC Server zu tun. Das ist ein XML-API Aufruf zum Auflisten aller CCU Geräte. Damit das geht, muss das XML-API Addon auf der CCU installiert sein. Das und andere Software gibt es z.B. unter homematic-inside.de
BTW: Beim Runterfahren von fhem wird ein laufender RPC-Server tatsächlich nicht gestoppt. Fixe ich noch, hat aber nichts mit Deinem Problem zu tun.
Kleiner Nachtrag:
Ich habe eben mal die CCU auf Werkseinstellungen zurückgesetzt und jetzt scheitn sich was zu tun:
14.12.2015 20:48:20 Creating file queue
14.12.2015 20:48:20 Initializing RPC server
14.12.2015 20:48:22 callback server created
14.12.2015 20:48:22 Adding callback for events
14.12.2015 20:48:22 Adding callback for new devices
14.12.2015 20:48:22 Adding callback for deleted devices
14.12.2015 20:48:22 Adding callback for modified devices
14.12.2015 20:48:22 Registering callback http://192.168.1.25:7401/fh
14.12.2015 21:13:38 RPC callback with URL http://192.168.1.25:7401/fh initialized
14.12.2015 21:13:38 Entering server loop. Use kill -SIGINT 5167 to terminate program
Ich lerne mal den Taster wieder an und schaue weiter.
Gruß Michael
Du kannst auf der CCU prüfen, ob der RPC Prozess läuft:
ps -ef | grep rfd
Außerdem sollte folgender Befehl die Prozess-ID des RPC Prozesses liefern:
fuser 2001/tcp
Wenn hier keine Zahl ausgegeben wird, läuft kein RPC Prozess. Dann einfach die CCU mal neu starten.
Wie man per SSH auf die CCU Command Line kommt, steht hier:
http://www.homematic-inside.de/tecbase/homematic/generell/item/zugriff-auf-das-dateisystem-der-ccu-2
Ich habe gerade eine neue Version der Module sowie des RPC-Servers eingecheckt.
Bugfixes:
- Beim Update von Readings in Client-Devices durch den RPC-Server wurde das Attribut substitute ignoriert
- Beim Stoppen von FHEM wurde der RPC-Server nicht beendet
Erweiterungen:
Der RPC-Server prüft nun beim Starten, ob die RPC-Schnittstelle der CCU erreichbar ist. Falls nicht, wird der Start abgebrochen.
Attribut ccureadingfilter: Legt einen regulären Ausdruck für Datenpunkte fest. Nur wenn ein Datenpunkt zu diesem Ausdruck passt, wird er als Reading gespeichert. Dies reduziert die Anzahl der Readings deutlich.
Beispiel: attr my_dev ccureadingfilter (^STATE$|TEMPERATURE)
Attribut stripnumber: Legt fest, in welchem Format Fließkommazahlen als Reading gespeichert werden. 0=Wie von CCU geliefert, 1=Mit maximal einer Null nach dem Komma, 2=Ohne Null nach dem Komma.
Attribut substitute: Hier gibt es die größten Änderungen. Die bisherige Variante hatte den Nachteil, dass die Ersetzungsregeln immer auf alle gelesenen Datenpunkte angewendet wurden. Nun kann man für bestimmte Datenpunkte eigene Regeln angeben. Das Format ist:
subst_rule[;...]
substrule := [datapoint!]regexp1:substtext1[,...]
Beispiel: Für STATE alle logischen Werte durch on/off ersetzen, für LOWBAT alle durch yes/no ersetzen, für alle anderen durch open/closed ersetzen.
attr mydev substitute STATE!(0|false):off,(1|true):on;LOWBAT!(0|false):no,(1|true):yes;(0|false):closed,(1|true):open
Die Angabe von 0/1 neben true/false ist erforderlich, da die get Befehle für logische Werte true/false liefern während der RPC-Server 0/1 liefert.
Hallo Zap,
ich bin mal wieder am probieren.
Kannst Du Dir evtl. die Sache mit der Startprüfung des ccurpcd.pl noch mal anschauen?
Wenn ich ein tail-f auf dem logfile laufen lassen, kann ich den Prozess reproduzierbar nicht anstarten:
015.12.16 21:04:24 1: HMCCU: Stopping RPC server
2015.12.16 21:04:42 1: HMCCU: Externally launched RPC server detected. Kill process manually with command kill -SIGINT 18647
2015.12.16 21:05:00 1: HMCCU: d_ccu Channel name or address invalid
2015.12.16 21:05:00 3: at_ccu: HMCCU: d_ccu Channel name or address invalid
2015.12.16 21:05:33 1: HMCCU: Externally launched RPC server detected. Kill process manually with command kill -SIGINT 18647
^C
pi@pi3 /opt/fhem/log $ ps aux | grep 18647
pi 18647 0.0 0.3 3936 1472 pts/2 S+ 21:00 0:00 tail -f ccurpcd.log
pi 18906 0.0 0.4 4144 1856 pts/3 S+ 21:06 0:00 grep --color=auto 18647
pi@pi3 /opt/fhem/log $
Die angemeckerte PID ist dabei kein ccurpcd.pl, sondern eben das tail -f.
Gruß
Michael
Mist. An sowas habe ich nicht gedacht. Mein Fehler. Liegt an der Art und Weise, wie ich auf einen laufenden Prozess prüfe.
Wird korrigiert.
Neue Versionen von 88_HMCCU.pm, 88_HMCCUDEV.pm, 88_HMCCUCHN.pm und ccurpcd.pl eingecheckt.
Fixes:
- Fehler bei der Prüfung auf laufenden ccurpcd Prozess behoben
Neue Funktionen:
Erweiterte Formatierung des Internals STATE analog zum Standardattribut 'stateFormat'. Leider unterstützt stateFormat keine Readings mit Doppelpunkt im Namen. Daher gibt es nun für HMCCUDEV und HMCCUCHN das Attribut 'ccustate'. Die Syntax ist identisch zu 'stateFormat', es können jedoch keine Perl-Ausdrücke angegeben werden. Zusätzlich zu 'ccustate' muss noch das Attribut 'stateFormat' auf "{HMCCU_State()}" gesetzt werden. Die Funktion HMCCU_State() wertet 'ccustate' aus und ersetzt Readings durch Werte. Außerdem wird geprüft, ob das Reading 'state' auf 'Error' steht. In diesem Fall wird STATE ebenfalls auf 'Error' gesetzt.
Beispiel:
attr my_dev ccustate T: KLIMA_WOHN:1.TEMPERATURE° H: KLIMA_WOHN:1.HUMIDITY%
attr my_dev stateFormat {HMCCU_State($name)}
Update: Da gerade an anderer Stelle die Diskussion hinsichtlich Sonderzeichen in Readingnames hochkocht, werde ich in der nächsten Version den Doppelpunkt in Readingnames durch ein anderes Zeichen ersetzen.
Diese Kommunkation scheint ja ein ziemlich sensibles Kerlchen zu sein.
der ccurpcd schafft es bei mir immer noch nicht aus der Initialisierung raus. So sieht das Logfile aus:
19.12.2015 16:52:29 Creating file queue
19.12.2015 16:52:29 Initializing RPC server
19.12.2015 16:52:31 callback server created
19.12.2015 16:52:31 Adding callback for events
19.12.2015 16:52:31 Adding callback for new devices
19.12.2015 16:52:31 Adding callback for deleted devices
19.12.2015 16:52:31 Adding callback for modified devices
19.12.2015 16:52:31 Registering callback
Dabei bleibt es dann, bis ich den Prozess mit attr attr d_ccu rpcserver off beende.
Dann (und erst dann) fängt der rfd auf der CCU in /var/log/messages an zu meckern:
ec 19 16:57:58 homematic-ccu2 user.err rfd: XmlRpc transport error calling system.listMethods({"CB1"}) on http://192.168.1.25:7401/fh:
Dec 19 16:57:58 homematic-ccu2 user.err rfd: XmlRpc transport error calling listDevices({"CB1"}) on http://192.168.1.25:7401/fh:
Da der Logeintrag "RPC callback with URL ..." nicht kommt, scheint der ccurpcd ja in dem $client->send_request ("init",$callbackurl,"CB1"); zu hängen.
Ach ja, die drei Minuten warte ich brav ab und das XML-API Addon habe ich auch installiert.
Bediene ich den Taster, ist die Fehlermeldung im message.log auf der CCU entsprechend länger (wieder erst nach dem Beenden!):
Dec 19 17:17:33 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB1","MEQ0399400:1","PRESS_SHORT",true}]}) on http://192.168.1.25:7401/fh:
Dec 19 17:17:33 homematic-ccu2 user.err rfd: XmlRpc transport error
Dec 19 17:17:33 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB1","MEQ0399400:1","INSTALL_TEST",true}]}) on http://192.168.1.25:7401/fh:
Dec 19 17:17:33 homematic-ccu2 user.err rfd: XmlRpc transport error
Kleiner Nachtrag: Weil ich langsam das Problem im Umfeld Raspberry/Perl-Libs vermute, habe ich den ccurpcd mal auf meinem ubuntu-Rechner ausgeführt. Außer der xml-rpc lib braucht der Prozess ja nix. Das hat geklappt, nach 3 Minuten ging er in die Bearbeitungsschleife.
Ich habe dann mal auf dem Rapsberry ein apt-get remove librpc-xml-perl; apt-get automrevmoce; apt-get install librpc-xml-perl gemacht und den ccurpcd ebenfalls direkt gestartet. Hat leider nichts geholfen.
Du hast jetzt aber auf dem Raspi nicht noch das Modul HMRPC aktiv, oder? Was liefert der Befehl
netstat -an | grep 7401
Der rfd auf der CCU erreicht den ccurpcd anscheinend nicht, obwohl zu diesem Zeitpunkt der Listener schon auf Port 7401 lauschen sollte und auch der Handler für listdevices regisitriert ist.
Seltsam, dass es auf Ubuntu läuft und auf dem Raspi nicht.
Der Server ist jedenfalls korrekt bei der CCU registriert, sonst würde die nicht versuchen, Events zu schicken. In einem vorherigen Post hatte das doch schon mal funktioniert. Hast Du was geändert?
Danke für den Tipp.
Ich habe keine Ahnung, warum es lt. logfile nach dem Neuaufsetzen der CCU zweimal geklappt hat und nun nicht.
Auf dem Port 7401 lauscht sonst niemand. Meiner Meinung nach müsste dann auch das Anlegen des callbackservers fehlschlagen.
Die CCU hängt durchaus am callbackserver, so interpretiere ich das zumindest (ich habe den ccurpcd.pl in c.pl umbenannt, Deine Prüfung, ob der Prozess schon läuft schlägt z.B. auch zu, wenn man den Prozess mit sudo startet :D):
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ ps aux | grep perl
pi 11017 0.0 0.4 4144 1884 pts/3 S+ 11:34 0:00 grep --color=auto perl
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ !netstat
netstat -an | grep 7401
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ sudo perl c.pl hm-ccu2 2001 /tmp/ccuqueue ccurpcd.log &
[1] 11023
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp 0 0 0.0.0.0:7401 0.0.0.0:* LISTEN
tcp 262 0 192.168.1.25:7401 192.168.1.30:53035 VERBUNDEN
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ ps aux | grep perl
root 11023 0.0 0.5 5140 2620 pts/3 S 11:35 0:00 sudo perl c.pl hm-ccu2 2001 /tmp/ccuqueue ccurpcd.log
root 11024 18.4 3.9 20684 17520 pts/3 S 11:35 0:08 perl c.pl hm-ccu2 2001 /tmp/ccuqueue ccurpcd.log
pi 11044 0.0 0.4 4144 1868 pts/3 S+ 11:36 0:00 grep --color=auto perl
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp 0 0 0.0.0.0:7401 0.0.0.0:* LISTEN
tcp 262 0 192.168.1.25:7401 192.168.1.30:53035 VERBUNDEN
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp 0 0 0.0.0.0:7401 0.0.0.0:* LISTEN
tcp 262 0 192.168.1.25:7401 192.168.1.30:53035 VERBUNDEN
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp 0 0 0.0.0.0:7401 0.0.0.0:* LISTEN
tcp 262 0 192.168.1.25:7401 192.168.1.30:53035 VERBUNDEN
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp 0 0 0.0.0.0:7401 0.0.0.0:* LISTEN
tcp 262 0 192.168.1.25:7401 192.168.1.30:53035 VERBUNDEN
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ cat ccurpcd.log
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ ps aux | grep perl
pi 11017 0.0 0.4 4144 1884 pts/3 S+ 11:34 0:00 grep --color=auto perl
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ !netstat
netstat -an | grep 7401
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ sudo perl c.pl hm-ccu2 2001 /tmp/ccuqueue ccurpcd.log &
[1] 11023
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp 0 0 0.0.0.0:7401 0.0.0.0:* LISTEN
tcp 262 0 192.168.1.25:7401 192.168.1.30:53035 VERBUNDEN
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ ps aux | grep perl
root 11023 0.0 0.5 5140 2620 pts/3 S 11:35 0:00 sudo perl c.pl hm-ccu2 2001 /tmp/ccuqueue ccurpcd.log
root 11024 18.4 3.9 20684 17520 pts/3 S 11:35 0:08 perl c.pl hm-ccu2 2001 /tmp/ccuqueue ccurpcd.log
pi 11044 0.0 0.4 4144 1868 pts/3 S+ 11:36 0:00 grep --color=auto perl
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp 0 0 0.0.0.0:7401 0.0.0.0:* LISTEN
tcp 262 0 192.168.1.25:7401 192.168.1.30:53035 VERBUNDEN
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp 0 0 0.0.0.0:7401 0.0.0.0:* LISTEN
tcp 262 0 192.168.1.25:7401 192.168.1.30:53035 VERBUNDEN
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp 0 0 0.0.0.0:7401 0.0.0.0:* LISTEN
tcp 262 0 192.168.1.25:7401 192.168.1.30:53035 VERBUNDEN
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp 0 0 0.0.0.0:7401 0.0.0.0:* LISTEN
tcp 262 0 192.168.1.25:7401 192.168.1.30:53035 VERBUNDEN
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ cat ccurpcd.log
19.12.2015 18:12:54 Creating file queue
19.12.2015 18:12:54 Initializing RPC server
19.12.2015 18:12:54 callback server created
19.12.2015 18:12:54 Adding callback for events
19.12.2015 18:12:54 Adding callback for new devices
19.12.2015 18:12:54 Adding callback for deleted devices
19.12.2015 18:12:54 Adding callback for modified devices
19.12.2015 18:12:54 Registering callback
19.12.2015 18:16:56 Creating file queue
19.12.2015 18:16:56 Initializing RPC server
19.12.2015 18:16:56 callback server created
19.12.2015 18:16:56 Adding callback for events
19.12.2015 18:16:56 Adding callback for new devices
19.12.2015 18:16:56 Adding callback for deleted devices
19.12.2015 18:16:56 Adding callback for modified devices
19.12.2015 18:16:56 Registering callback
19.12.2015 18:19:57 RPC callback with URL http://192.168.1.24:7401/fh initialized
19.12.2015 18:19:57 Entering server loop. Use kill -SIGINT 20537 to terminate program
19.12.2015 18:19:57 ListDevices
19.12.2015 18:19:57 NewDevice: received 56 device specifications
19.12.2015 19:06:28 Shutdown RPC server
19.12.2015 19:06:28 RPC server terminated
19.12.2015 20:29:31 Creating file queue
19.12.2015 20:31:59 Error: ccurpcd.pl is already running (PID=7809)
19.12.2015 20:34:04 Error: ccurpcd.pl is already running (PID=7825)
19.12.2015 20:35:00 Error: ccurpcd.pl is already running (PID=7834)
19.12.2015 20:36:36 Creating file queue
19.12.2015 20:36:36 Initializing RPC server
19.12.2015 20:36:38 callback server created
19.12.2015 20:36:38 Adding callback for events
19.12.2015 20:36:38 Adding callback for new devices
19.12.2015 20:36:38 Adding callback for deleted devices
19.12.2015 20:36:38 Adding callback for modified devices
19.12.2015 20:36:38 Registering callback
19.12.2015 21:01:23 Creating file queue
19.12.2015 21:01:23 Initializing RPC server
19.12.2015 21:01:24 callback server created
19.12.2015 21:01:24 Adding callback for events
19.12.2015 21:01:24 Adding callback for new devices
19.12.2015 21:01:24 Adding callback for deleted devices
19.12.2015 21:01:24 Adding callback for modified devices
19.12.2015 21:01:24 Registering callback
19.12.2015 21:01:25 nach listmethods. Sende jetzt:inithttp://192.168.1.25:7401/fhCB1
19.12.2015 21:13:14 Creating file queue
19.12.2015 21:13:14 Initializing RPC server
19.12.2015 21:13:15 callback server created
19.12.2015 21:13:15 Adding callback for events
19.12.2015 21:13:15 Adding callback for new devices
19.12.2015 21:13:15 Adding callback for deleted devices
19.12.2015 21:13:15 Adding callback for modified devices
19.12.2015 21:13:15 Registering callback
19.12.2015 21:13:15 nach listmethods. Sende jetzt:inithttp://192.168.1.25:7401/fhCB1
20.12.2015 11:17:23 Creating file queue
20.12.2015 11:17:23 Initializing RPC server
20.12.2015 11:17:25 callback server created
20.12.2015 11:17:25 Adding callback for events
20.12.2015 11:17:25 Adding callback for new devices
20.12.2015 11:17:25 Adding callback for deleted devices
20.12.2015 11:17:25 Adding callback for modified devices
20.12.2015 11:17:25 Registering callback
20.12.2015 11:17:25 nach listmethods. Sende jetzt:inithttp://192.168.1.25:7401/fhCB1
20.12.2015 11:17:25 RPC callback with URL http://192.168.1.25:7401/fh initialized
20.12.2015 11:17:25 Entering server loop. Use kill -SIGINT 10888 to terminate program
20.12.2015 11:19:01 Shutdown RPC server
20.12.2015 11:19:01 RPC server terminated
20.12.2015 11:19:38 Creating file queue
20.12.2015 11:19:38 Initializing RPC server
20.12.2015 11:19:40 callback server created
20.12.2015 11:19:40 Adding callback for events
20.12.2015 11:19:40 Adding callback for new devices
20.12.2015 11:19:40 Adding callback for deleted devices
20.12.2015 11:19:40 Adding callback for modified devices
20.12.2015 11:19:40 Registering callback
20.12.2015 11:19:40 nach listmethods. Sende jetzt:inithttp://192.168.1.25:7401/fhCB1
20.12.2015 11:35:43 Creating file queue
20.12.2015 11:35:43 Initializing RPC server
20.12.2015 11:35:44 callback server created
20.12.2015 11:35:44 Adding callback for events
20.12.2015 11:35:44 Adding callback for new devices
20.12.2015 11:35:44 Adding callback for deleted devices
20.12.2015 11:35:44 Adding callback for modified devices
20.12.2015 11:35:45 Registering callback
20.12.2015 11:35:45 nach listmethods. Sende jetzt:inithttp://192.168.1.25:7401/fhCB1
20.12.2015 11:19:38 Creating file queue
20.12.2015 11:19:38 Initializing RPC server
20.12.2015 11:19:40 callback server created
20.12.2015 11:19:40 Adding callback for events
20.12.2015 11:19:40 Adding callback for new devices
20.12.2015 11:19:40 Adding callback for deleted devices
20.12.2015 11:19:40 Adding callback for modified devices
20.12.2015 11:19:40 Registering callback
20.12.2015 11:19:40 nach listmethods. Sende jetzt:inithttp://192.168.1.25:7401/fhCB1
20.12.2015 11:35:43 Creating file queue
20.12.2015 11:35:43 Initializing RPC server
20.12.2015 11:35:44 callback server created
20.12.2015 11:35:44 Adding callback for events
20.12.2015 11:35:44 Adding callback for new devices
20.12.2015 11:35:44 Adding callback for deleted devices
20.12.2015 11:35:44 Adding callback for modified devices
20.12.2015 11:35:45 Registering callback
20.12.2015 11:35:45 nach listmethods. Sende jetzt:inithttp://192.168.1.25:7401/fhCB1
192.168.1.25 ist der pi, .30 die CCU.
Du siehst in dem Log-Ausschnitt eine Stelle, wo er die Serverloop erreicht. Da habe ich das send_request("init",... auskommentiert. Dann ist der Server auch da und per brwoeser ansrepchbar (gibt ein 403). Aber natürlich liefert die CCU keine Daten an.
Für mich sieht das so aus:
- unter ubuntu hängt das Hochfahren ziemlich genau 3 Minuten in dem send_request("init" fest, dann geht es weiter, der Server lauscht auf dem Port und die CCU kann senden.
- auf dem pi kommt der Prozess nie aus send_request("init" zurück, daher kann die CCU auch nichts senden und hängt ihrerseits (timeouts scheint es da nicht zugeben oder die sind sehr lang). Wenn ich den ccurpcd dann töte, fällt die Verbindung zusammen und der rfd beschwert sich im Log file.
Ich denke, ich werde das noch mal auf einem anderen Raspberry ausprobieren. Vielleicht habe ich auf diesem hier irgendwas im Netzwerkbereich oder in der Perlinstallation kaputt gespielt.
Wenn ich heute noch dazu komme, suche ich Dir mal die Versionen der relevanten Perl-Module raus, die ccurpcd.pl verwendet.
Update: Direkt von CPAN installiert. RPC::XML Version 0.79
Das wäre toll, denn es ist wohl ein Konfigurationsproblem. Auf einem anderem Raspberry haut es hin.
Ich musste nur die rpc-xml Library installieren. An der hing allerdings noch ziemlich viel Kram dran.
Und so sieht es dann aus:
pi@pi2:/tmp$ tail -f *.log
20.12.2015 17:30:31 Creating file queue
20.12.2015 17:30:31 Initializing RPC server
20.12.2015 17:30:33 callback server created
20.12.2015 17:30:33 Adding callback for events
20.12.2015 17:30:33 Adding callback for new devices
20.12.2015 17:30:33 Adding callback for deleted devices
20.12.2015 17:30:33 Adding callback for modified devices
20.12.2015 17:30:33 Registering callback
20.12.2015 17:33:34 RPC callback with URL http://192.168.1.29:7401/fh initialized
20.12.2015 17:33:34 Entering server loop. Use kill -SIGINT 5147 to terminate program
20.12.2015 17:33:34 ListDevices
20.12.2015 17:33:35 NewDevice: received 56 device specifications
Weiter komme ich auf diesem Pi nicht, denn da läuft kein fhem drauf.
Mal sehen, wie ich die Perl-Installation auf dem anderen Pi wieder sauber kriege.
Im Zweifel erst mal versuchen, RPC::XML neu zu installieren. Aktuelle Version ist 0.79
Interessant.
Auf den Rapsberrys bin ich bei Version 0.76, auf ubuntu bei 0.78.
Die Lib habe ich auch schon de-installiert und neu installiert. Ich habe in der Zwischenzeit sogar einen ganzen Haufen perl-libs mal auf Verdacht deinstalliert. Hat nix gebracht.
Naja, dann habe ich ja endlich den Grund, mal Jessie auszuprobieren. Die meisten meiner PIs sind noch auf Wheezy...
Und wenn alle Stricke reißen, über ein auslesen per at kriege ich das auf jeden Fall hin, das habe ich schon probiert. Aber das wäre irgendwie unsportlich und außerdem will ich in Zukunft noch mehr über die CCU laufen lassen.
Danke erst Mal, ich denke, in der nächsten Woche komme ich nicht so viel voran ;)
Ich habe gerade eine neue Version eingecheckt. In naher Zukunft lässt FHEM keine Reading Names mit Doppelpunkten mehr zu. Daher werden Readings von Homematic CCU Devices ab sofort in folgendem Format gespeichert (abhängig vom Attribut ccureadingformat):
ccureadingformat = 'name': Channel-Name.Datapoint
ccureadingformat = 'address': Interface.Device-Address.Channel-Number.Datapoint
Die Doppelpunkte sowohl im CCU Channel-Name als auch zwischen Device-Address und Channel-Number werden also durch Punkte ersetzt.
Grundsätzlich könnte man für alle Client Devices das Attribut ccureadingformat auf 'datapoint' setzen und damit das Dilemma mit den Doppelpunkten vermeiden. Aber leider gibt es CCU Geräte, die in verschiedenen Kanälen Datenpunkte mit gleichem Namen verwenden. Daher ist die zusätzliche Angabe des Kanals im Reading Name für eine eindeutige Unterscheidung erforderlich.
Ich habe außerdem eine Funktion zur Berechnung des Taupunktes eingebaut, die in Verbindung mit dem Attribut userReadings verwendet werden kann.
Beispiel: Ein Device speichert Temperatur und Luftfeuchte in den Readings WOHNEN_TH.1.TEMPERATURE und WOHNEN_TH.1.HUMIDITY. Dann wird mit folgendem Befehl der Taupunkt im Reading DEWPOINT gespeichert:
attr mydev userReadings DEWPOINT {HMCCU_Dewpoint($name,"WOHNEN_TH.1.TEMPERATURE", "WOHNEN_TH.1.HUMIDITY","n/a")}
Außerdem wurde die Prüfung auf einen bereits laufenden RPC Server Prozess nochmals optimiert und liefert nun hoffentlich eindeutige Ergebnisse.
Hallo,
ich wollte nach der Anleitung das Modul nutzen aber bei mir scheitert es schon bei der Installation der Module.
Wenn ich
cpan install RPC::XML::Client
aufrufe, bekomme ich die folgende Fehlermeldung:
Could not get valid metadata. Error is: CPAN::Meta::Converter version 2.141170 required--this is only version 2.140640 at /root/.cpan/build/Module-Build-0.4214-jUVRMT/blib/lib/Module/Build/Base.pm line 4702.
Ich habe jetzt stundenlang versucht, alle Module zu aktualisieren, aber irgendwie scheint nichts zu funktionieren.
Kann mir hier bitte jemand weiterhelfen? Ich verzweifle noch.
Vielen Dank!
CPAN selbst scheint zu alt zu sein. Das solltest Du zunächst aktualisieren.
Da muss ich dummerweise mal fragen wie ich es aktualisiere.^^
Ich stehe gerade etwas auf dem Schlauch und google konnte mir da auch nicht helfen.
Danke. :)
Versuch mal
cpan CPAN::Meta
oder
cpan CPAN::Meta::Converter
Habe ich ausgeführt.
Wenn ich dann aber wieder versuche RPC::XML::Client zu installieren, bekomme ich wieder die gleiche Fehlermeldung. wie oben beschrieben.
Was ist mit cpan install RPC::XML
Hatte ich auch schon probiert.
Aber hatte nichts gebracht. Ich sitze jetzt schon seit 14 Uhr daran. Habe auch ein komplett neues System aufgesetzt.
Kannst Du irgendein anderes Perl Modul installieren?
Probier mal File::Queue. Wird zwar momentan nicht von HMCCU verwendet, da es ein Bug hat, aber schadet auch nicht.
Keine Ahnung, woher der Fehler kommt. Ich konnte auf meinem Raspberry das problemlos installieren. Vielleicht kann einer der anderen HMCCU Tester mal schreiben, wie er RPC::XML installiert hat.
Okay, ich hatte gerade nochmal parallel das Modul Module::Build installiert und bekomme auch die gleiche Fehlermeldung. Da scheint irgendwas mit meinem CPAN nicht in Ordnung zu sein... oder?
Scheint so. Wenn Du unbedingt die RPC-Module haben willst kannst Du Dir natürlich die .pm Dateien vom CPAN Archiv direkt runterladen und in die Perl Lib Verzeichnisse installieren. Das ist aber übles Gefrickel und Du musst wissen was Du tust. Empfehlen kann ich das nicht wirklich. Bei RPC XML funktioniert das, da es sich um reinen Perl Code handelt.
Womit wir wieder bei der Frage wären, wie man CPAN neu installiert. Google schweigt sich hier aus. CPAN ist ja eigentlich nur ein Perl-Modul.
Hm.. ich brauche es ja um das DEVICE anlegen zu können.
Wenn ich das Modul weglasse, bekomme ich ja bei Ausführung von
define CCU2 HMCCU homematic-ccu2
die folgende Fehlermeldung in der FHEM-Log
2015.12.22 21:08:26 1: reload: Error:Modul 88_HMCCU deactivated:
Can't locate RPC/XML/Client.pm in @INC (you may need to install the RPC::XML::Client module) (@INC contains: /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl . /opt/fhem/FHEM) at /opt/fhem/FHEM/88_HMCCU.pm line 55.
BEGIN failed--compilation aborted at /opt/fhem/FHEM/88_HMCCU.pm line 55.
Das Modul kann nicht weggelassen werden.
Was extrem merkwürdig ist: es wird ja angemeckert, dass CPAN::Meta::Converter veraltet ist. Auf der offiziellen CPAN Seite
http://search.cpan.org/~dagolden/CPAN-Meta-2.140640/lib/CPAN/Meta/Converter.pm
wird aber genau die Version angeboten, die Du installiert hast. Allerdings gibt es hier
http://search.cpan.org/~dagolden/CPAN-Meta-2.141170/
die verlangte Version. Du könntest Dir also von dem letzten Link die Version runterladen und die vorhandenen Module damit überschreiben (mach vorher eine Kopie).
Hey, ich hatte jetzt in der Zwischenzeit noch Make und einen C Compiler installiert.
apt-get install make
apt-get install gcc
apt-get install python-dev
apt-get install expat
cpan install HTTP::Daemon
Und endlich lässt es sich installieren und läuft. :)
Vielen Dank für deine Hilfe. :D
Make ist natürlich zwingend erforderlich. Da wäre ich anhand der Fehlermeldung aber nie drauf gekommen ;)
Bevor Du irgendwelche HMCCU Devices definierst, zieh Dir die neue Version der Module von gestern Abend. Ich musste die Reading-Namen ändern, da FHEM zukünftig für Identifier keine Doppelpunkte mehr zulassen wird.
Ja, ich bin auch nur durch Zufall darauf gekommen als er bei einer anderen Abhängigkeit wegen "Make" gemeckert hatte. ;)
Ich konnte jetzt die HMCCU anlegen und er zeigt mir auch als Status "Ok" an. Aber get devicelist bringt mir keine Ergebnisse. Habe gerade die CCU neu gestartet. Allerdings hängt dort so viel dran dass das mittlerweile ca. 20 Minuten dauert bis die wieder hochgefahren ist.
So, CCU ist neu gestartet und der RPC-Serve läuft auch. Aber get devicelist bringt mir immer noch keine Ergebnisse.
Das sieht doch gut aus. DevCount = 290 ist das Ergebnis von "get devicelist". Der Befehl produziert keine Ausgabe. Du kannst aber mal versuchen, noch ein "dump" anzuhängen, also get xxx devicelist dump. Falls ich das nicht wieder ausgebaut habe, sollte dann eine Liste aller Devices und Channels im FHEM Fenster angezeigt werden.
Bei einem define mit HMCCU wird get devicelist automatisch ausgeführt.
Ansonsten kannst Du los legen und mal per HMCCUDEV ein CCU Geräte oder per HMCCUCHN einen CCU Kanal definieren. Die Datenpunkte sollten dann automatisch vom ccurpcd aktualisiert werden.
Autocreate gibt's (noch) nicht.
Für autocreate einfach ein return "UNDEFINED NeuerDeviceName ModulName Def" zurückgeben ;).
Zitat von: Ralli am 23 Dezember 2015, 12:30:34
Für autocreate einfach ein return "UNDEFINED NeuerDeviceName ModulName Def" zurückgeben ;).
Von wo zurückgeben?
An fhem - aus Deinem Modul (bzw. dem RPCd), was mit mit dem noch nicht definierten Gerät noch nichts anfangen kann.
Hmm, der spärlichen "Doku" entnehme ich, dass das was mit einer Parse Funktion zu zu hat, die unter bestimmten Bedingungen aufgerufen wird. Und die gibt das diesen String zurück.
Von neuen Devices erfährt HMCCU aus einer zeitgesteuerten Funktion, die die Event-Queue auswertet. Da bringt das Zurückgeben dieses Strings nichts. Außerdem gibt es noch 2 Probleme zu lösen:
1. Die RPC Schnittstelle schickt beim NewDevice Event nur die Adresse des Gerätes mit. Leider hat die CCU keinen API Call eingebaut, mit dem ich von der Adresse zum Namen des Gerätes komme. Da bleibt nur das erneute Einlesen aller Geräte. Daher ignoriert HMCCU derzeit die NewDevice Events.
2. Ich habe Bedenken, per autocreate für jedes CCU Device (und vielleicht noch für jeden Kanal?) ein FHEM Device anlegen zu lassen. Das wird schnell unübersichtlich (habe fast 300 Kanäle) und wahrscheinlich benötigt auch nicht jeder alle CCU Devices in FHEM
Hey, also das mit der Ausgabe hat funktioniert.
Ich habe jetzt auch mein erstes Device angelegt (Homematic Thermostat). Aber wie bekomme ich z.B. die Temperatur-Daten in die Readings?
Viele Grüße
Thomas.
Okay, es hat etwas gedauert aber die Readings sind jetzt mittlerweile gefüllt. :)
Aber die Daten sind schon über eine Stunde alt. Es aktualisert sich in FHEM nichts wenn ich am Thermostat die Temperatur ändere.
Wie werden die Events getriggert?
Die CCU schickt die Events an den ccurpcd.pl Prozess. Der schreibt die Events in eine File Queue, standardmäßig /tmp/ccuqueue.dat (und .idx). In HMCCU sorgt dann eine Timer gesteuerte Funktion dafür (alle 3-10 Sekunden, einstellbar), dass die Events aus der File Queue gelesen und an die Client devices in Form von Readings verteilt werden. Zumindest einmal scheint dieser Prozess bei Dir ja funktioniert zu haben. Bei mir vergehen zwischen Aktion in CCU und Reaktion in FHEM nur wenige Sekunden.
Du kannst prüfen, ob Der ccurpcd Events empfängt, indem Du Dir den Zeitstempel der Datei /tmp/ccuqueue.dat anschaust. Der sollte bei Deiner Anzahl an CCU Kanälen nicht älter als 1 Minute sein, denn irgendwas schickt die CCU immer, gerade wenn man Wandthermostate im Einsatz hat. Wenn die Größe der Datei ccuqueue.dat >0 ist, stehen Events drin, die man sich auch z.B. per "tail ccuqueue.dat" anschauen kann. Der RPC Server empfängt immer Events für alle Geräte der CCU, auch wenn für diese kein Device in FHEM existiert.
Falls gar nichts funktioniert wären die letzten Zeilen der Datei /opt/fhem/log/ccurpcd.log interessant. Außerdem eventuelle Meldungen von HMCCU im fhem Log (z.B. dass seit einiger Zeit keine Events von der CCU kamen).
Noch was: nach dem Starten des RPC Servers vergehen exakt 3 Minuten, bevor die ersten Events von der CCU eintreffen. Warum dass so ist, kann vermutlich nur EQ3 beantworten.
Bei mir läuft der RPC Server seit ca. 3 Wochen stabil ohne Performance Probleme.
Hey Zap,
schon mal vielen Dank für deinen wirklich guten Support.
Ich habe mir die Datei angesehen und sie ist leer (0KB Größe) aber der Zeitstempel aktualisiert sich ca. alle 5 Sekunden. Scheint also kein Zugriffsproblem zu sein.
In der Log steht folgendes:
23.12.2015 17:45:21 RPC callback with URL http://192.168.178.58:7401/fh initialized
23.12.2015 17:45:21 Entering server loop. Use kill -SIGINT 1403 to terminate program
23.12.2015 17:45:21 ListDevices
23.12.2015 17:45:23 NewDevice: received 140 device specifications
23.12.2015 17:53:36 Received 250 events from CCU since last check
23.12.2015 18:38:49 Creating file queue
23.12.2015 18:38:49 Initializing RPC server
23.12.2015 18:38:50 callback server created
23.12.2015 18:38:50 Adding callback for events
23.12.2015 18:38:50 Adding callback for new devices
23.12.2015 18:38:50 Adding callback for deleted devices
23.12.2015 18:38:50 Adding callback for modified devices
23.12.2015 18:38:50 Registering callback
23.12.2015 18:41:50 RPC callback with URL http://192.168.178.58:7401/fh initialized
23.12.2015 18:41:50 Entering server loop. Use kill -SIGINT 1403 to terminate program
23.12.2015 18:41:50 ListDevices
23.12.2015 18:41:52 NewDevice: received 140 device specifications
23.12.2015 18:50:59 Received 250 events from CCU since last check
Ich kann in der Log aber nichts Auffälliges feststellen.
Ich hatte FHEM jetzt zwischendrin ein paar Mal neu gestartet.
Wenn ich
get HM_KU_Thermostat channel 4
manuell in FHEM aufrufe, bekomme ich auch die korrekten Daten die ich vorher über die CCU-Weboberfläche gesetzt habe.
Das Problem liegt also irgendwie in der automatischen Übertragung bzw. Aktualisierung.
Wenn sich der Zeitstempel aktualisiert, dürfte alles in Ordnung sein. HMCCU liest ja alle paar Sekunden Events aus der Datei und leert sie dadurch. Auch der Eintrag "received 250 events since last check" im Log passt. Der ccurpcd schreibt immer nach 250 events diese Meldung ins Log. Werden gar keine Readings aktualisiert?
Was mir in dem Logauszug auffällt: es fehlt zwischendrin eine "RPC server terminated" Meldung (nach 17:53). Wenn der ccurpcd korrekt beendet wird, muss er eine entsprechende Meldung ins Log schreiben, also per "attr rpcserver off" oder beim Stoppen von Fhem. Hast Du den Prozess mal anderweitig abgeschossen? Das sollte man nicht zu oft machen, da in diesem Fall der RPC Server nicht korrekt von der CCU abgemeldet wird.
Hast Du ein Wandthermostat? Definiere das mal als HMCCUDEV Device oder einen Tür/Fenster Sensor. Die schicken bei mir sofort Feeback, wenn ich ein Fenster öffne. Auch Temperatur und Feuchte werden alle paar Minuten aktualisiert.
Hast Du bei Deinen Devices irgendwelche Attribute gesetzt? ccureadings darf nicht gesetzt sein oder muss 1 sein.
Hey,
ja ich hatte immer den Pi neu gestartet anstatt die Prozesse zu killen.
Jetzt habe ich mal den RPC Server über das Attribute off gesetzt, FHEM neu gestartet und dann den RPC Server wieder per Attribute aktiviert.
23.12.2015 21:25:55 Received 250 events from CCU since last check
23.12.2015 21:52:36 Shutdown RPC server
23.12.2015 21:53:31 Creating file queue
23.12.2015 21:53:31 Initializing RPC server
23.12.2015 21:53:31 callback server created
23.12.2015 21:53:31 Adding callback for events
23.12.2015 21:53:31 Adding callback for new devices
23.12.2015 21:53:31 Adding callback for deleted devices
23.12.2015 21:53:31 Adding callback for modified devices
23.12.2015 21:53:31 Registering callback
23.12.2015 21:56:31 RPC callback with URL http://192.168.178.58:7401/fh initialized
23.12.2015 21:56:31 Entering server loop. Use kill -SIGINT 1398 to terminate program
23.12.2015 21:56:31 ListDevices
23.12.2015 21:56:33 NewDevice: received 140 device specifications
23.12.2015 22:02:47 Shutdown RPC server
23.12.2015 22:02:47 RPC server terminated
23.12.2015 22:04:08 Creating file queue
23.12.2015 22:04:08 Initializing RPC server
23.12.2015 22:04:08 callback server created
23.12.2015 22:04:08 Adding callback for events
23.12.2015 22:04:08 Adding callback for new devices
23.12.2015 22:04:08 Adding callback for deleted devices
23.12.2015 22:04:08 Adding callback for modified devices
23.12.2015 22:04:08 Registering callback
Ein Wandthermostat habe ich leider nicht.
Aber auch der Fenstersensor aktualisiert sich nich von alleine.
Ich habe die Daten auch manuell abfragen müssen.
Und nachdem ich dann das Fenster geöffnet habe (ca. 2 min auf gelassen) und dann wieder geschlossen, kam auch keine Aktualisierung in der Zwischenzeit.
Ich lade die Tage mal eine Version mit erweiterter Logging Funktion hoch, damit wir das Problem eingrenzen können. In der Zwischenzeit könntest Du bitte mal die Definition der Devices mit Attributen posten oder mir per Forum Mail schicken?
Hallo Zap,
die Definition der Devices sieht so aus
#HMCCU
define CCU2 HMCCU homematic-ccu2
attr CCU2 ccureadingfilter .*
attr CCU2 rpcserver on
#Küche - Thermostat
define HM_KU_Thermostat HMCCUDEV LEQ1076554 4
attr HM_KU_Thermostat IODev CCU2
attr HM_KU_Thermostat statechannel 4
#Küche - Fenster
define HM_KU_Fenster HMCCUDEV MEQ0752141 1
attr HM_KU_Fenster IODev CCU2
attr HM_KU_Fenster statechannel 1
Viele Grüße und frohe Weihnachten.
Ich habe jetzt auch nochmal einen Schalter eingebunden aber auch von dem bekomme ich keine automatischen Events in FHEM.
Die Einrichtung mache ich gerade bei meinen Eltern. Leider bin ich nur über Weihnachten hier und muss danach wieder fahren.
VG, Thomas
Weihnachtsupdate von 88_HMCCU.pm eingecheckt. Bitte unbedingt die neue Version aus Sourceforge installieren! Behebt einen Bug beim Update von Client Devices, der unter bestimmten Konstellationen auftreten kann.
In HMCCU Device das Loglevel auf 1 setzen. Bei Loglevel = 2 werden alle Events vom RPC Server protokollert (nur für Fehlersuche geeignet, produziert je nach Anzahl der CCU Devices viele Logeinträge).
Vergesst das mit dem Logging, muss erst die Module auf Verbose / Log3 umstellen, bevor ich das wieder aktiviere.
@Tom_Tom: Deine Konfig passt soweit. Attribut ccureadingfilter ist per default .*, kann also auch weggelassen werden. Ich würde das Attribut immer nur bei Client-Devices setzen, da sich die sinnvollen Readings je nach Gerätetyp unterscheiden.
Einige Beispiele für den Einsatz der Module:
Definition eines Heizungsthermostaten (Einstellung der Zieltemperatur mit set devstate):
define HM_KL_AZ_HZ HMCCUDEV KL-AZ-HZ
attr HM_KL_AZ_HZ IODev d_ccu
attr HM_KL_AZ_HZ ccureadingfilter (LOWBAT|TEMPERATURE)
attr HM_KL_AZ_HZ ccustate T: KL-AZ-HZ.4.ACTUAL_TEMPERATURE° D: KL-AZ-HZ.4.SET_TEMPERATURE°
attr HM_KL_AZ_HZ stateFormat {HMCCU_State($name)}
attr HM_KL_AZ_HZ statechannel 4
attr HM_KL_AZ_HZ statedatapoint SET_TEMPERATURE
attr HM_KL_AZ_HZ stripnumber 1
Definition eines Wandthermostaten (Ohne Einstellmöglichkeit der Zieltemperatur, nur Auswertung Temperatur und Luftfeuchte):
define HM_KL_AZ_TH HMCCUDEV KL-AZ-TH
attr HM_KL_AZ_TH IODev d_ccu
attr HM_KL_AZ_TH ccureadingfilter (^HUMIDITY|^TEMPERATURE|^SET_TEMPERATURE|^LOWBAT$)
attr HM_KL_AZ_TH ccustate T: KL-AZ-TH.1.TEMPERATURE° H: KL-AZ-TH.1.HUMIDITY% D: KL-AZ-TH.2.SET_TEMPERATT
URE° P: DEWPOINT°
attr HM_KL_AZ_TH devStateIcon OK:10px-kreis-gruen Error:10px-kreis-rot Initialized:10px-kreis-gelb
attr HM_KL_AZ_TH stateFormat {HMCCU_State($name)}
attr HM_KL_AZ_TH statechannel 2
attr HM_KL_AZ_TH statedatapoint TEMPERATURE
attr HM_KL_AZ_TH stripnumber 1
attr HM_KL_AZ_TH substitute LOWBAT!(0|false):no,(1|true):yes
attr HM_KL_AZ_TH userReadings DEWPOINT {HMCCU_Dewpoint($name,"KL-AZ-TH.1.TEMPERATURE", "KL-AZ-TH.1.HUMIDITY","n/a")}
Definition eines Readonly Fenstersensors:
define HM_TF_SZ_Fenster1 HMCCUCHN TF-SZ-Fenster1:1 readonly
attr HM_TF_SZ_Fenster1 IODev d_ccu
attr HM_TF_SZ_Fenster1 devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
attr HM_TF_SZ_Fenster1 substitute STATE!(0|false):closed,(1|true):open;;LOWBAT!(0|false):no,(1|true):yes
Definition einer Schaltsteckdose (ein/ausschalten mit set devstate on/off):
define HM_ST_WZ_Bass HMCCUDEV ST-WZ-Bass
attr HM_ST_WZ_Bass IODev d_ccu
attr HM_ST_WZ_Bass ccureadingfilter (STATE|LOWBAT|ON_TIME)
attr HM_ST_WZ_Bass ccureadings 1
attr HM_ST_WZ_Bass devStateIcon on:10px-kreis-gruen off:10px-kreis-rot Initialized:10px-kreis-gelb
attr HM_ST_WZ_Bass statechannel 1
attr HM_ST_WZ_Bass statevals on:true,off:false
attr HM_ST_WZ_Bass substitute STATE!true:on,false:off,1:on,0:off;;LOWBAT!true:yes,false:no
Hey, ich habe das Weihnachtsupdate installiert, aber leider auch ohne Erfolg.
Habe das System neu gestartet, den RPC Server per attribute gestartet (hat auch eine Prozess-ID und läuft).
Anschließend ca. 5 Minuten gewartet, aber keine Daten kamen.
Dann habe ich get devicelist ausgeführt, einige Minuten gewartet, aber nichts passiert.
Dann im angelegten Device (Thermostat) get channel 4 ausgeführt und die korrekten Readings bekommen.
Ich habe dann am Thermostat die Temperatur verstellt. Diese wird mir auch in der Homematic-Oberfläche korrekt angezeigt. Jedoch leider immer noch nicht in FHEM.
FHEM - Log-Eintrag aktualisiert sich permanent. Aber die Änderungen die ich mache (egal ob am Thermostat oder in der HM-Web-Oberfläche) werden nicht empfangen.
2015.12.25 20:33:28 1: HMCCU: RPC server started with pid 1861
2015.12.25 20:35:19 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:24 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:29 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:34 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:39 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:44 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:49 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:54 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:59 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:36:04 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:36:09 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:36:14 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:36:32 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.CONTROL_MODE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.FAULT_REPORTING
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.BATTERY_STATE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.VALVE_STATE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.BOOST_STATE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.ACTUAL_TEMPERATURE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.SET_TEMPERATURE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_TEMPERATURE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_START_TIME
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_START_DAY
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_START_MONTH
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_START_YEAR
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_STOP_TIME
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_STOP_DAY
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_STOP_MONTH
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_STOP_YEAR
2015.12.25 20:54:17 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:22 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:27 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:32 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:37 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:42 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:47 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:52 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:57 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:02 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:07 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:12 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:18 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:23 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:28 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:33 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:38 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:43 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:48 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:53 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:58 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:56:03 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:56:08 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:56:13 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:56:18 1: HMCCU: Received no events from CCU since 180 seconds
Sorry dass ich dir keine positive Nachricht hinterlassen kann.
Viele Grüße, Thomas.
Hey, ich habe jetzt mal statt des DNS Namens der CCU die IP-Adresse eingetragen und schon geht es. :)
Darauf wäre ich vorher nie gekommen, da er ja die ganze Zeit als Status "Ok" angezeigt hatte.
Viele Grüße und noch schöne Weihnachten :)
Guten Abend zusammen, ich habe jetzt meine "Entwicklungs-/Bastelumgebung" soweit aufgebaut.
Wenn ich via FHEm meinen Aktor in der CCU schalte, schaltet der zwar noch, FHEM stürzt aber ab.
Das Log verweist auf:
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/HMCCU/88_HMCCUDEV.pm#l236
"Undefined subroutine &main::usleep called at ./FHEM/88_HMCCUDEV.pm line 236."
Meine Config:
Zitat
define CCU HMCCU 192.168.20.XXX
attr CCU ccureadings 1
attr CCU rpcserver on
define ccu.AZ.Aktor.Tuer.1 HMCCUDEV XXXXXXXXX 1
attr ccu.AZ.Aktor.Tuer.1 IODev CCU
attr ccu.AZ.Aktor.Tuer.1 statechannel 1
attr ccu.AZ.Aktor.Tuer.1 statevals on:true,off:false
attr ccu.AZ.Aktor.Tuer.1 substitute true:on,false:off,1:on,0:off
Kann mir jemand weiter helfen?
BTW: Ich kann Systemvariablen via FHEM setzen, also die Richtung funktioniert einwandfrei, so wie ich das verstehe, wartet FHEM vergeblich auf eine Bestätigung, dass die Aktion durchgeführt wurde und gibt dann enttäuscht auf?
EDIT #1:
Nach frischer Energie bin ich auf den Trichter gekommen, dass die Funktion usleep() in Time::HiRes steckt; das werde ich noch mal drüber bügeln und berichten.
-> Bringt nix!
EDIT #2:
Edit: Bringt doch was, wenn man es dann in der 88_HMCCUDEV.pm noch "used"
->
Zitatuse Time::HiRes qw( sleep);
noch in den Header und jetzt lüppt et. 8)
Nach meiner kleinen Odyssee im Post darüber habe ich jetzt noch folgende Fragen:
#1 Ich habe vor alle Homematic-Komponenten an der CCU anzumelden und Änderungen an FHEM "gepusht" zu bekommen -> Das funktioniert im Moment so "lala" für mich zeitlich willkürlich.
-> Ich habe es soweit verstanden, dass der RCP-Server quasi die Events gepusht bekommt, diese in die Queue steckt und FHEM sich alle X Zeiteinheiten dort das neuste rausbekommt.
Kann ich jetzt dieses X möglichst klein bestimmen? Ich hätte z.B. einige zeitkritische Sachen die ich gerne direkt in FHEM hätte. Z.B. sobald bei Abwesenheit die Tür auf geht möchte ich bei Dunkelheit Licht einschalten. Diese Logik möchte ich aber (gerne) in FHEM implementieren.(Ich finde das geklicke nicht so schön und es sollen noch IT-Devices mit an gehen).
#2 Das RCPServer Attribut der CCU steht immer wieder auf off, müsste das nicht on sein?
-> Selbst wenn ich es manuell auf on setze ist es einige Minuten später wieder off?!
#3 Eine Mischung aus #1-> Wieso ist der "state" in FHEM nachdem ich ihn via FHEM gesetzt habe bei einem Schaltaktor z.B. "OK" und nich "On" oder "Off"? das müsste mit einem get doch machbar sein oder? Bzw. ist wahrscheinlich schon so eingebaut aber funktioniert bei mir nicht?
Zitat von: lukasbastelpeter am 25 Dezember 2015, 22:19:50
Edit: Bringt doch was, wenn man es dann in der 88_HMCCUDEV.pm noch "used"
-> noch in den Header und jetzt lüppt et. 8)
Keine Ahnung, warum bei mir usleep ohne use Timer::Hires funktioniert. Aber danke für den Hinweis. Baue es ein und checke die neuen Versionen von 88_HMCCUCHN und 88_HMCCUDEV heute noch ein.
Zitat von: lukasbastelpeter am 26 Dezember 2015, 13:56:23
#1 Ich habe vor alle Homematic-Komponenten an der CCU anzumelden und Änderungen an FHEM "gepusht" zu bekommen -> Das funktioniert im Moment so "lala" für mich zeitlich willkürlich.
-> Ich habe es soweit verstanden, dass der RCP-Server quasi die Events gepusht bekommt, diese in die Queue steckt und FHEM sich alle X Zeiteinheiten dort das neuste rausbekommt.
Ja, so funktioniert das. Das X kannst Du per Attribut rpcinterval setzen. Im FHEM GUI lässt das Werte von 3, 5 und 10 Sekunden zu. Default ist 5. Wenn Du das Kommando attr ... direkt eintippst, kannst Du auch andere Werte einsetzen. Wird m.W. nicht geprüft. Bitte beachten: In den ersten drei Minuten nach Starten des RPC Servers kommen keine Events!
Zitat
#2 Das RCPServer Attribut der CCU steht immer wieder auf off, müsste das nicht on sein?
-> Selbst wenn ich es manuell auf on setze ist es einige Minuten später wieder off?!
Da stimmt was nicht. HMCCU prüft alle X Sekunden (siehe oben #1), ob der RPC-Server noch läuft. Wenn nicht setzt er das Attribut auf "off". Außerdem wird das Internal RPCPID in HMCCU auf 0 gesetzt und RPCPRC auf "none". Scheint so, als würde der RPC Server abschmieren. Schau Dir bitte mal die ccurpcd.log und das fhem log an (grep HMCCU). Läuft der RPC Server noch (ps -ef | grep ccurpcd)
Zitat
#3 Eine Mischung aus #1-> Wieso ist der "state" in FHEM nachdem ich ihn via FHEM gesetzt habe bei einem Schaltaktor z.B. "OK" und nich "On" oder "Off"? das müsste mit einem get doch machbar sein oder? Bzw. ist wahrscheinlich schon so eingebaut aber funktioniert bei mir nicht?
Im HMCCU oder in einem HMCCUDEV/HMCCUCHN Device? In HMCCU ist das so. Dafür ist das IO Device auch nicht gedacht. Da bekommt state immer den Status (also OK/Error) des letzten Befehls. In einem HMCCUCHN oder HMCCUDEV Device sollte state allerdings tatsächlich den Status des Gerätes annehmen. Dazu solltest Du zunächst mit "attr statechannel" den Kanal definieren, der den Status liefert bzw. den Status setzt. Wenn der zugehörige Datenpunkt nicht "STATE" heißt, kannst Du den mit dem Attribut "statedatapoint" bestimmen. Hier nochmal zwei Beispiele:
Zunächst eine einfache Schaltsteckdose (nur die State relevanten Attribute):
define HM_ST_WZ_Bass HMCCUDEV ST-WZ-Bass
# Der folgende Kanal enthält den Datenpunkt STATE
attr HM_ST_WZ_Bass statechannel 1
# Im set devstate Befehl werden on/off in true/false übersetzt und an die CCU geschickt
attr HM_ST_WZ_Bass statevals on:true,off:false
# Im get devstate Befehl (und bei Events) werden true/1/false/0 durch on/off ersetzt und in state gespeichert
attr HM_ST_WZ_Bass substitute STATE!true:on,false:off,1:on,0:off;;LOWBAT!true:yes,false:no
Ein Heizthermostat mit SET_TEMPERATURE als State-Datenpunkt:
define HM_G_AZ_HZ HMCCUDEV G-AZ-HZ
attr HM_G_AZ_HZ statechannel 4
attr HM_G_AZ_HZ statedatapoint SET_TEMPERATURE
# Bei Anzeige der Zieltemperatur in state soll nur eine Nachkommastelle angezeigt werden
attr HM_G_AZ_HZ stripnumber 1
Ok, nach einigen Boots scheint der RCP durch zu laufen.
Wenn ich in der HMCCU ein get devicelist mache, was passiert dann?
Werden die Devices dann irgendwo aufgelistet?
Bei mir nicht :(
In den Bildern habe ich das jetzt mal umgesetzt, in dem Reading scheint der STATE anzukommen,
aber leider nicht als "State"... HILFE! :o ;)
Hallo Zusammen,
ich versuche gerade die Daten in der TabletUI anzuzeigen. Aber ich weiß nicht so recht was ich abfragen muss.
Kann mir jemand helfen?
<div data-type="thermostat"
data-device="HM_KU_Thermostat"
data-get="datapoint 4.SET_TEMPERATURE"
data-set="datapoint 4.SET_TEMPERATURE"
data-temp="HM-CC-RT-DN%20LEQ1076554.4.ACTUAL_TEMPERATURE"
data-min="0"
data-max="50"
class="cell">
</div>
Ich habe jetzt alle möglichen Kombinationen ausprobiert.
Zitat von: ToM_ToM am 26 Dezember 2015, 17:33:00
Hallo Zusammen,
ich versuche gerade die Daten in der TabletUI anzuzeigen. Aber ich weiß nicht so recht was ich abfragen muss.
Kann mir jemand helfen?
<div data-type="thermostat"
data-device="HM_KU_Thermostat"
data-get="datapoint 4.SET_TEMPERATURE"
data-set="datapoint 4.SET_TEMPERATURE"
data-temp="HM-CC-RT-DN%20LEQ1076554.4.ACTUAL_TEMPERATURE"
data-min="0"
data-max="50"
class="cell">
</div>
Ich habe jetzt alle möglichen Kombinationen ausprobiert.
In "data-get" und "data-temp" kommt nur das Reading rein, während in "data-set" der Befehl angegeben werden muss. Bei mir sieht ein Wandthermostat (Vorsicht, andere Kanäle als das Heizkörperthermostat) in Tablet-UI so aus:
<div data-type="thermostat"
data-device="HM_KL_SZ_TH"
data-get="KL-SZ-TH.2.SET_TEMPERATURE"
data-temp="KL-SZ-TH.1.TEMPERATURE"
data-set="datapoint 2.SET_TEMPERATURE"
Und so sehen meine Readings aus:
Readings:
2015-12-26 17:47:16 DEWPOINT 11.4
2015-12-26 17:47:16 KL-SZ-TH.1.HUMIDITY 63
2015-12-26 17:47:16 KL-SZ-TH.1.TEMPERATURE 18.6
2015-12-26 17:46:55 KL-SZ-TH.2.SET_TEMPERATURE 21.0
2015-12-26 17:47:16 state 18.6
Ein Problem in Deinem Fall könnte das Leerzeichen im Readingname von "data-temp" sein. Hast Du mal %20 durch ein einfaches Blank ersetzt?
Zitat von: lukasbastelpeter am 26 Dezember 2015, 17:29:47
Wenn ich in der HMCCU ein get devicelist mache, was passiert dann?
Werden die Devices dann irgendwo aufgelistet?
Bei mir nicht :(
get devicelist erzeugt keine Ausgabe. Es wird lediglich das Internal "DevCount" im IO Device auf die Anzahl der von der CCU gelesenen Geräte und Kanäle gesetzt. Mit get devicelist dump erfolgt eine Auflistung aller Kanäle im FHEM Fenster.
get devicelist wird beim Define des IO Devices automatisch ausgeführt. Nach einem Reload von 88_HMCCU muss es manuell ausgeführt werden. Ebenso, wenn in der CCU ein neues Gerät angelernt wurde oder sich an einem vorhandenen Gerät etwas geändert hat.
Zitat
In den Bildern habe ich das jetzt mal umgesetzt, in dem Reading scheint der STATE anzukommen,
aber leider nicht als "State"... HILFE! :o ;)
mmm, darüber muss ich etwas nachdenken ... aber mach schon mal beim Attribut substitute aus den 2 Semikolon vor LOWBAT eins. Die zwei Semikolon kommen daher, dass ich meine Beispiele aus der fhem.cfg kopiert habe.
Alles klar, das mit dem dump habe ich wohl überlesen in der Doku :-X
Alles klar, ich versuche auch mal via debugging weiter zu kommen, aber es kommt auch kein "Event" wenn ich schalte.
Scheint so als würde das reading von Fhem selbst gesetzt...?!- Also ohne entsprechenden input der ccm?
Kann ich verhindern, dass das:
"2015.12.26 16:33:42 1: HMCCU: Received no events from CCU since 180 seconds"
nicht jede Sekunde geloggt wird?
Zitat von: lukasbastelpeter am 26 Dezember 2015, 17:58:21
Alles klar, das mit dem dump habe ich wohl überlesen in der Doku :-X
Alles klar, ich versuche auch mal via debugging weiter zu kommen, aber es kommt auch kein "Event" wenn ich schalte.
Scheint so als würde das reading von Fhem selbst gesetzt...?!- Also ohne entsprechenden input der ccu?
Ja, das ist so. Wenn Du von FHEM aus in der CCU etwas schaltest, wird direkt nach dem set ein get ausgeführt und so das Ergebnis des set überprüft. Ich vermute mal, dass ich an dieser Stelle das Ergebnis nicht in state kopiere. Das sollte der wenige Sekunden später kommende Event erledigen. Du scheinst also doch noch Probleme mit dem RPC Server zu haben. Ich poste demnächst mal ein kleines Howto zum RPC Server mit einigen Tipps, worauf man bei Problemen achten soll. Du kannst aber schon mal prüfen, ob die Datei /tmp/ccuqueue.dat aktualisiert wird. Außerdem vielleicht mal irgendwelche fhem Log Einträge prüfen, die "HMCCU" enthalten.
P.S. und mach aus ;; im substitute bitte ein ;
P.S.P.S Bin nur froh, dass der RPC Server anscheinend auch bei ToM_ToM läuft, sonst würde ich langsam wirklich Zweifel bekommen. Bei mir läuft das Ding völlig problemlos.
Alles klar,
die ccuqueue.dat ist leer! Kann es sein, dass der Server keine Rechte hat dahin zu schreiben? Wenn ja, wie geb ich ihm die?
Zitat von: lukasbastelpeter am 26 Dezember 2015, 18:09:26
Alles klar,
die ccuqueue.dat ist leer! Kann es sein, dass der Server keine Rechte hat dahin zu schreiben? Wenn ja, wie geb ich ihm die?
Da der RPC-Server die ccuqueue.dat anlegt, sollte er die Rechte haben. Dass sie leer ist, hat ebenfalls nichts zu sagen. Es ist ja eine Queue, d.h. der RPC-Server schreibt seine Events rein (=> Datei wird größer) und das HMCCU IO Device in FHEM liest die Events aus der Datei (=> Datei wird kleiner bis 0).
Du musst auf die Zeitstempel der Datei achten (ls -l ccuqueue.dat). Werden die aktualisiert? Gibt es in fhem log Meldungen der Art "received no events since 180 seconds" oder so ähnlich?
Hallo Zap,
ja ich habe es mit und ohne %20 probiert. Aber leider ohne Erfolg.
@lukasbastelpeter:
Schau mal ob sich die "last write time" der Datei ändert.
Um die Rechte zu ändern google mal nach "CHMOD". Ich arbeite mit WinSCP. Das ist ein Dateimanager und damit geht das ziemlich einfach.
Und kleiner Tip: Mach dir mal die Mühe auch die anderen Seiten dieses Beitrags zu lesen. Die meisten deiner Fragen wurden hier schon beantwortet.
VG, Thomas
Erstmal danke für den super, und fixen Support an solchen Tagen :)...
Ja, die Meldung habe ich sekündlich im Log... Der Timestamp ist auch aktuell...
Daher die Frage ob ich die Meldung unterdrücken kann :)... Meine arme SD-Karte...
Zitat
2015.12.26 18:39:01 1: HMCCU: 500 Can't connect to 192.168.20.XXX:8181
2015.12.26 18:39:01 1: HMCCU: RPC server started with pid 590
2015.12.26 18:39:02 1: define AZ.Deckenlampe HMCCUDEV XXX 1: CCU device name not found for XXX
2015.12.26 18:39:02 1: configfile: CCU device name not found for XXXstatefile: Please define AZ.Deckenlampe first
Jemand Ideen?
Zitat von: lukasbastelpeter am 26 Dezember 2015, 18:28:25
Erstmal danke für den super, und fixen Support an solchen Tagen :)...
Ja, die Meldung habe ich sekündlich im Log... Der Timestamp ist auch aktuell...
Daher die Frage ob ich die Meldung unterdrücken kann :)... Meine arme SD-Karte...
Jemand Ideen?
Schalte erst mal den RPC Server wieder ab (damit die Meldungen aufhören) oder setze loglevel auf irgendwas > 1. Dein Problem liegt an anderer Stelle.
Die Meldung "HMCCU: 500 Can't connect to 192.168.20.XXX:8181" besagt, dass ein Homematic Script nicht ausgeführt werden kann, weil HMCCU die CCU auf Port 8181 nicht erreichen kann. Ist die IP-Adresse korrekt? Vermutlich passiert der Fehler beim Definieren des IO Devices in FHEM mit dem Modul HMCCU. Dabei wird get devicelist ausgeführt. Das schlägt mit o.g. Fehlermeldung fehl. Deshalb funktioniert auch das folgende Define der Deckenlampe nicht, da im internen Speicher von HMCCU das CCU-Gerät nicht bekannt ist (das hätte eben get devicelist geliefert).
IP stimmt auf jeden Fall, da bin ich im WebInterface unterwegs.
Das Gerät gibt es auch auf jeden Fall, denn genau mit der Konfiguration hat es ja funktioniert?! Manchmal nimmt er es nach einem Boot so an, manchmal nicht...
Wenn ich es dann zwei,drei,vier mal versuche, akzeptiert er es dann irgendwann...
Zitat von: ToM_ToM am 26 Dezember 2015, 18:26:35
Hallo Zap,
ja ich habe es mit und ohne %20 probiert. Aber leider ohne Erfolg.
In Deinem Beispiel mit dem Screenshot hast Du zwei Readings stehen:
HM-CC-RT-DN: Wert = LEQ1076554.4.ACTUAL_TEMPERATURE
HM-CC-RT-DN LEQ1076554.4.ACTUAL_TEMPERATURE: Wert = Temperatur
Wie kam das 1. Reading zustande? Da scheint irgendwas mit dem Leerzeichen schief gelaufen zu sein.
Du könntest im Frontend Forum im Tablet-UI Thread mal die Frage stellen, ob Tablet-UI Probleme hat, wenn in Reading-Names Leerzeichen vorkommen bzw. wie man damit umgehen muss. Oder Du könntest bei Deinen CCU Geräten auf Leerzeichen verzichten. Oder Du benutzt das Attribut "ccureadingformat" und setzt es auf address. Dann haben die Readings grundsätzlich die Adresse der CCU-Geräte als Name. Das sollte dann funktionieren.
Funktioniert eigentlich der Befehl get datapoint im IO Device (HMCCU) wenn der CCU Gerätename ein Leerzeichen enthält? Musst Du den Namen dann in doppelten Hochkomma angeben? Also irgendwie ist das mit den Leerzeichen in der Gerätenamen keine so gute Idee ...
UPDATE: Ich werde in HMCCU bei Readingnames die Leerzeichen automatisch durch Unterstriche ersetzen (neue Version kommt aber nicht vor Montag). Und zwar deshalb:
http://forum.fhem.de/index.php/topic,45788.msg376767.html#msg376767
D.h. FHEM wird keine Leerzeichen mehr als Readingnames zulassen.
Ich mal wieder,
ich habe die Doku und den Thread durchforstet, Systemvariablen werden nicht gepusht oder?
Zitat von: lukasbastelpeter am 26 Dezember 2015, 20:18:02
Ich mal wieder,
ich habe die Doku und den Thread durchforstet, Systemvariablen werden nicht gepusht oder?
Nein, die RPC Schnittstelle der CCU unterstützt keine Systemvariablen. Dafür (und auch für CUxD Geräte in der CCU) musst Du Dir mit einem at Device in FHEM behelfen, das regelmäßig einen "get <iodev_name> vars <muster>" absetzt.
Nochmal zu Deinen Problemen mit der CCU Verbindung: Scheinen mir Netzwerkprobleme zu sein. Hat m.E. nichts mit dem Modul HMCCU zu tun. Nutzt du WLAN? Welches Betriebssystem verwendest Du?
Hi, ok. Das mit den Systemvariablen läuft bei mir jetzt schon so.
Gestern habe ich das Problem mal vorführen wollen. Mit dem Ergebnis, dass alles perfekt funktioniert hat.
Bis zu einem Reboot -.-...
Das ist aber immer so oder? BZW anscheinend kann man FHEM keine states und readings über den Boot behalten. Denn immer wenn ich neu boote meckert er, dass er die Devices in der CCU nicht kennt, d.h. Entweder schaffe ich es dass FHEM sich auch das Ergebnis von get devicelist merkt, oder ich definiere die ganzen HMCCUDevs mit einem at erst 5 Minuten nach booten.
Die Kiste läuft auf einem Raspberry B+, via Kabel an dem gleichen Switch wie die CCU wird gefüttert von einer Fritzbox.
Mein Macbook hängt via SSH in dem FritzboxWlan.
Hallo zusammen, ich hab das gleiche "Leiden" wie lukasbastelpeter im Post # 141:
Beim Auslösen eines Schaltbefehls auf dem HMW-IO-12-Sw7-DR wird dieser ausgeführt, FHEM "schmiert" aber ab und kann nur mit "sudo /etc/init.d/fhem start" wiederbelebt werden. Im Log steht:
ZitatUndefined subroutine &main::usleep called at ./FHEM/88_HMCCUDEV.pm line 238
Die Änderungen von zap aus Antwort #143 sind eingespielt!
define HMCCU2 HMCCU 192.168.xxx.240
attr HMCCU2 ccureadings 1
attr HMCCU2 room HM
attr HMCCU2 rpcserver on
define hm_licht HMCCUDEV MEQ0064384 14
attr hm_licht IODev HMCCU2
attr hm_licht room HM
attr hm_licht statechannel 14
attr hm_licht statevals on:true,off:false
attr hm_licht substitute true:on,false:off,1:on,0:off
Hat jemand Ideen, wo ich noch suchen kann? (hab grad den Pi und Perl geupdatet, hat auch bloß nix gebracht)
Danke vom Harz
Zitat von: lukasbastelpeter am 27 Dezember 2015, 11:36:57
Hi, ok. Das mit den Systemvariablen läuft bei mir jetzt schon so.
Gestern habe ich das Problem mal vorführen wollen. Mit dem Ergebnis, dass alles perfekt funktioniert hat.
Bis zu einem Reboot -.-...
Das ist aber immer so oder? BZW anscheinend kann man FHEM keine states und readings über den Boot behalten. Denn immer wenn ich neu boote meckert er, dass er die Devices in der CCU nicht kennt, d.h. Entweder schaffe ich es dass FHEM sich auch das Ergebnis von get devicelist merkt, oder ich definiere die ganzen HMCCUDevs mit einem at erst 5 Minuten nach booten.
Die CCU Geräte und Kanäle werden in internen Variablen gespeichert. Wie auch Internals überleben diese einen Neustart von FHEM nicht. Lediglich Readings werden zwischengespeichert und stehen nach dem Neustart wieder zur Verfügung.
Allerdings wird bei einem Neustart von FHEM ja das cfg File abgearbeitet, d.h. das HMCCU IO Device wird definiert und dabei auch "get devicelist" ausgeführt. Genau da passiert bei Dir aber der Fehler (zumindest nach den Fehlermeldungen im Log). Beim Versuch, die Geräte der CCU einzulesen, kommt der Fehler, dass die CCU nicht erreicht werden kann.
Hast Du etwas anderes laufen, das auch die TCL-Rega Schnittstelle der CCU nutzt? Läuft der REGA Prozess auf der CCU (wahrscheinlich, sonst würde es nie funktionieren und nicht nur sporadisch).
Zitat von: RainerG am 27 Dezember 2015, 17:55:13
Hallo zusammen, ich hab das gleiche "Leiden" wie lukasbastelpeter im Post # 141:
Beim Auslösen eines Schaltbefehls auf dem HMW-IO-12-Sw7-DR wird dieser ausgeführt, FHEM "schmiert" aber ab und kann nur mit "sudo /etc/init.d/fhem start" wiederbelebt werden. Im Log steht:Die Änderungen von zap aus Antwort #143 sind eingespielt!
Bitte prüfe, ob am Anfang der Dateien 88_HMCCUDEV.pm und 88_HMCCUCHN.pm tatsächlich "use Time::HiRes;" steht (Zeilen 45 bzw. 42). Falls nicht, lade die beiden Dateien von Sourceforge und kopiere sie ins Modulverzeichnis.
Falls der Use-Befehl schon vorhanden ist: Hast Du die Module neu geladen, nachdem Du die Updates im Modulverzeichnis installiert hast (reload 88_HMCCUDEV und reload 88_HMCCUCHN) ?
Der Fehler in Deinem Fall ist definitiv, dass use Time::HiRes fehlt und damit usleep nicht bekannt ist.
So, wie versprochen hier einige
Tipps und Hinweise zum RPC-Server. Dieser Beitrag ist auch im 1. Posts dieses Threads verlinkt.
Der RPC-Server ccurpcd.pl wird mit dem Befehl "set rpcserver on/off" gestartet oder gestoppt. Das Attribut rpcserver legt fest, ob der RPC Server beim Start von FHEM automatisch gestartet wird. Sollte es notwendig sein, den RPC-Server manuell zu beenden, so kann die durch einen manuellen Aufruf von ccurpcd.pl mit folgender Syntax erfolgen:
ccurpcd.pl shutdown <ccu_host_or_ip> <port> <pid>
Reload von 88_HMCCU: Vor dem Reload des Moduls 88_HMCCU muss der RPC-Server auf jeden Fall beendet werden, da durch den Reload die Internals RPCPID und RPCPRC verloren gehen und somit das IO-Device den Bezug zum RPC-Server verliert.
FHEM neu starten: Der RPC-Server wird beim Stoppen von FHEM korrekt beendet. Allerding muss vor dem erneuten Starten von FHEM gewartet werden, bis der RPC-Server Prozess nicht mehr läuft. Daher sollte der Befehl "/etc/init.d/fhem restart" bzw. "shutdown restart" nicht bei aktivem RPC-Server verwendet werden, da hier vor dem Starten nicht lange genug gewartet wird. Besser ist "/etc/init.d/fhem stop", dann warten bis RPC-Server auch gestoppt wurde ("ps -ef | grep ccurpcd.pl") und dann starten mit "/etc/init.d/fhem start". In neueren Version von HMCCU funktioniert "shutdown restart" korrekt.
Fehlersuche:
RPC-Server Start: Wenn der RPC-Server mit dem Befehl "set rpcserver on" aus FHEM heraus korrekt gestartet wurde, werden folgende Internals des HMCCU IO Device gesetzt:
RPCPID = Unix Prozess-ID(s) des/der RPC-Server Prozesse(s) (ccurpcd.pl)
RPCPRC = Dateiname des RPC-Server Prozesses
Das Reading "rpcstate" zeigt den Status des RPC servers an.
Wenn der RPC-Server nicht läuft oder das IO-Device aus irgendwelchen Gründen den Bezug zum RPC-Servers verloren hat, ist RPCPID = 0 und RPCPRC = "none".
Der Start des RPC-Servers wird in der Datei ccurpcd_
Port.log im FHEM Log-Verzeichnis protokolliert. Ein korrekter Start des RPC-Servers sieht z.B. so aus:
26.12.2015 16:57:58 callback server created
26.12.2015 16:57:58 Adding callback for events
26.12.2015 16:57:58 Adding callback for new devices
26.12.2015 16:57:58 Adding callback for deleted devices
26.12.2015 16:57:58 Adding callback for modified devices
26.12.2015 16:57:58 Registering callback
26.12.2015 17:00:58 RPC callback with URL http://192.168.1.12:7401/fh initialized
26.12.2015 17:00:58 Entering server loop. Use kill -SIGINT 14211 to terminate program
26.12.2015 17:00:58 ListDevices
26.12.2015 17:01:00 NewDevice: received 179 device specifications
: Zwischen "Registering callback" und "RPC callback with URL ..." vergehen 3 Minuten! Während dieser 3 Minuten sollte man es vermeiden, auf das GUI der CCU zuzugreifen. Danach erhält der RPC-Server eine Liste der CCU Geräte bzw. Kanäle, was mit "NewDevice: ..." protokollert wird.
File-Queue: Der RPC-Server schreibt die von der CCU empfangenen Events in eine File-Queue (Standard /tmp/ccuqueue_
Port.dat und /tmp/ccuqueue_
Port.idx). Das HMCCU IO Device in FHEM liest die Events regelmäßig (einstellbar über Attribut "rpcinterval") aus dieser Queue und verteilt sie an die Client-Devices (HMCCUCHN, HMCCUDEV).
Prüfen auf CCU-Events: Ein Indiz für das Funktionieren des RPC-Servers ist die permanente Aktualisierung des Zeitstempels der Datei ccuqueue.dat. Dies kann durch wiederholtes Ausführen des Befehls "ls -l /tmp/ccuqueue.dat" verifiziert werden. Es ist normal, dass ccuqueue.dat meistens die Größe 0 Byte hat, da eventuelle Events relativ schnell von HMCCU gelesen werden und dadurch die Datei geleert wird. Sofern zufällig Events in der Datei stehen, können sie mit dem Befehl "cat /tmp/ccuqueue.dat" ausgegeben werden (ein tail -f auf die Datei sollte man vermeiden).
Events bleiben aus: Wenn HMCCU bei aktivem RPC-Server für 300 Sekunden keine Events erhält, schreibt es eine Meldung in das FHEM Logfile ("HMCCU: Received no events from CCU since 300 seconds").
Manueller Test: Je nach Fehlerbild kann es sinnvoll sein, den RPC-Server einmal manuell zu starten, um den Fehler eingrenzen zu können, möglichst als User "root". Dazu gibt man auf der Kommandozeile folgenden Befehl ein (bitte Pfade ggf. ändern):
/opt/fhem/FHEM/ccurpcd.pl ccu-ip 2001 /tmp/testqueue /tmp/ccurpcd.log &
Wichtig ist, nicht die Standard Queue- und Log-Files zu verwenden, da es sonst beim regulären Start aus FHEM zu Zugriffsproblemen kommen kann.
Da beim manuellen Start des RPC-Servers keine Events von FHEM aus der Queue gelesen werden, kann man (nach 3 Minuten) mit dem Befehl "cat /tmp/testqueue.dat" die Events anschauen und so feststellen, ob die Kommunikation zwischen CCU und dem RPC-Server funktioniert. Zum Beenden des RPC-Servers den Befehl "kill -SIGINT prozess-id" verwenden.
Zitat von: zap am 27 Dezember 2015, 18:10:15
Bitte prüfe, ob am Anfang der Dateien 88_HMCCUDEV.pm und 88_HMCCUCHN.pm tatsächlich "use Time::HiRes;" steht (Zeilen 45 bzw. 42). Falls nicht, lade die beiden Dateien von Sourceforge und kopiere sie ins Modulverzeichnis.
Falls der Use-Befehl schon vorhanden ist: Hast Du die Module neu geladen, nachdem Du die Updates im Modulverzeichnis installiert hast (reload 88_HMCCUDEV und reload 88_HMCCUCHN) ?
Der Fehler in Deinem Fall ist definitiv, dass use Time::HiRes fehlt und damit usleep nicht bekannt ist.
Leider muß es noch eine Ursache geben:
Deine Dateien sind ok und Time::HiRes scheint auch richtig installiert zu sein:
Zitatcpan[1]> install Time::HiRes
Reading '/root/.cpan/Metadata'
Database was generated on Sun, 27 Dec 2015 05:17:02 GMT
Time::HiRes is up to date (1.9728).
Und trotzdem schmiert FHEM weiter ab.
Habt Ihr noch Ideen? - Danke Rainer
Hallo Rainer,
Ich hatte das gleiche Problem. Die Perl Version ist zu alt und hat das Time::HiRes Modul noch nicht standardmäßig mitgeliefert.
Die einfachste Lösung besteht darin, die Anweisung usleep(100000) durch ein sleep (1) zu ersetzen.
Zitat von: hometux am 28 Dezember 2015, 02:42:57
Hallo Rainer,
Ich hatte das gleiche Problem. Die Perl Version ist zu alt und hat das Time::HiRes Modul noch nicht standardmäßig mitgeliefert.
Die einfachste Lösung besteht darin, die Anweisung usleep(100000) durch ein sleep (1) zu ersetzen.
Das geht natürlich und ich überlege, das auch so in die offiziellen Module aufzunehmen. Allerdings wird damit die Wartezeit zwischen set und nachfolgendem get verzehnfacht (100 ms => 1 s). Im Prinzip ist das usleep() und das get nur erforderlich, wenn kein RPC-Server verwendet wird, denn der RPC-Server wird durch das Set sowieso ein Event mit dem geänderten Wert von der CCU bekommen.
Die Fehlermeldung bei RainerG besagt eindeutig, dass usleep nicht gefunden wurde. Deshalb schmiert FHEM ab. Ich vermute immer noch, dass hier zwar die aktuellen Module und auch Time::HiRes installiert wurden, die Module aber mangels Reload bzw. FHEM-Neustart (Reload genügt normalerweise) nicht verwendet werden.
Aufpassen beim Neustart von FHEM bei aktivem RPC-Server: Nicht mit /etc/init.d/fhem restart neu starten. Dabei wird zwischen Stop und Start nicht lange genug gewartet und der RPC-Server wird versucht zu starten, bevor er richtig beendet wurde. Also immer erst Stop, warten bis der RPC-Server nicht mehr läuft und dann Start.
UPDATE: Neue Version von 88_HMCCU.pm eingecheckt. In allen Reading Names, die auf CCU Geräten oder Kanälen basieren werden alle Zeichen ersetzt, die keine gültigen Zeichen für FHEM Reading Names sind. Konkret: Doppelpunkte werden durch Punkte ersetzt. Alle Zeichen, die nicht zum Ausdruck [A-Za-z\d_\.-] passen, werden durch Unterstriche ersetzt.
Hallo zap,
Erst einmal ganz vielen Dank für die schon super gute Funktionalität. HMCCU schließt m.E. die entscheidende Lücke in der HM-Unterstützung.
Ich nutze neben den drahtlosen Komponten auch verschiedene Wired Komponenten. Dafür stellt die CCU eine zweite RPC Schnittstelle unter der Portnummer 2000 zur Verfügung.
Ich habe einmal probehalber die Portnummer für den RPC Port auf 2000 gesetzt. Das funktioniert auch grundsätzlich, natürlich nun ohne die Wireless Komponenten. Probleme scheint es beim HM-Input Modul mit vielen Kanälen zu geben. Diese werden offenbar nicht einzeln ausgewertet und aktualisieren immer gemeinsam- das muss ich allerdings noch genauer untersuchen.
Meine konkrete Frage: spricht etwas prinzipiell dagegen, 2 RPC-Prozesse gleichzeitig laufen zu lassen (gegen Port 2000 und 2001 der ccu)? Im Moment ist das ja offenkundig programmtechnisch geblockt.
Hallo zusammen, zunächst einmal meine Variante aus der CCU heraus Fhem-Befehle auszuführen, für alle die es interessiert:
-> Für "komplexere" Dinge wie z.B. Wetterberichte, die ich nicht unbedingt via http aufrufen will...
1. In der CCU gibt es zwei Systemvariablen,
Fhem.A.value und Fhem.A.state
Das A steht für einen Index und ist einfach nur falls ich mal mehrere "interfaces" brauche, genau wie Fhem.A.state
(Die Überlegung ist halt, wenn ein CCU-Programm abläuft checkt es: ist ...A.state=readyToReceive? Wenn ja, dann Befehl in Fhem.A.value, ansonsten versuche es entsprechend mit Fhem.B)
2. Mein Fhem holt sich sekündlich via RCP die Variablen aus der CCU ab, darunter auch Fhem.A.value, und speichert mir das in den Fhem-Dummy CCU.CMD.A
-> Auf Änderungen des States von A reagiert ein notify, dies führt dann "doCmd("A")" aus.
das sieht so aus:
Zitat
sub
doCmd($){
my ($i) =@_;
my $cmd=Value("CCU.CMD.".$i);
fhem ($cmd);
fhem ("set CCU var Fhem.".$i."state 1");
}
Es guckt also in den Dummy Befehl A, nimmt den Inhalt, führt ihn aus und setzt in der CCU das Interfaces A wieder auf readyToReceive(1).
Das wäre vielleicht noch etwas für das Modul?
Ansonsten vielen Dank für den Nerv, zap! +1
Ich habe jetzt mal scharf nachgedacht was da lost ist, und mein Problem ist glaube ich folgendes:
CCU und Raspberry hängen am gleichen Netzteil, wenn ich nun das Netzteil rausziehe, der Raspberry hochfährt ist der deutlich vor der CCU fertig, die CCU kann dem Raspberry also nicht antworten :D und der get devicelist wartet vergeblich auf eine Antwort...
Vielleicht könnte man in das Modul noch einbauen, dass es den start so lange verzögert bis die CCU hochgefahren ist? Keine Ahnung was man da als Indikator nimmt, bzw. wie man dann ALLES umbauen müsste, damit die CCU-Geschichten erst "defined" werden wenn die CCU am start ist?
VG
Bei mir läuft der Spaß jetzt eigentlich ganz gut! Noch mal +1 :D
Super, Super, Super, Danke!
PS: Ich habe einen 4-Fach Aktor, und einige 2-Fach Aktoren definiert, da funktioniert der Status per RCP nicht so schön, alle Devices des Aktors bekommen den gleichen State, das statechannel-Attribut habe ich gesetzt... ?! -> Anscheinend bekommen alle Kanäle des Aktors den State der letzten "Schaltung"
Zitat von: hometux am 29 Dezember 2015, 18:19:22
Probleme scheint es beim HM-Input Modul mit vielen Kanälen zu geben. Diese werden offenbar nicht einzeln ausgewertet und aktualisieren immer gemeinsam- das muss ich allerdings noch genauer untersuchen.
Du meinst das HMCCU Modul? Die Auswertung der Events von der CCU läuft ja zeitgesteuert in dem mit rpcinterval festgelegten Intervall. Dabei werden immer bis zu 20(?) Events aus der Queue gleichzeitig ausgewertet. Diese Limitierung habe ich drin, um FHEM nicht auszubremsen. Das kann bei sehr vielen Kanälen aber dazu führen, dass Events erst beim 2. Intervall ausgewertet werden. Ich denke, ich kann den Wert etwas nach oben korrigieren. An der Gleichzeitigkeit vieler Events aufgrund der zeitgesteuerten Auswertung wird sich dadurch aber nicht viel ändern.
Zitat
Meine konkrete Frage: spricht etwas prinzipiell dagegen, 2 RPC-Prozesse gleichzeitig laufen zu lassen (gegen Port 2000 und 2001 der ccu)? Im Moment ist das ja offenkundig programmtechnisch geblockt.
Prinzipiell spricht nichts gegen 2 Prozesse. Habe das nicht berücksichtigt, da ich keine wired Komponenten habe. Die CCU2 unterstützt seit kurzem aber auch Homematic IP (noch in Beta). Ich vermute mal, dass hierfür auch ein separater Port verwendet werden wird. Ich ziehe also die Unterstützung mehrerer RPC-Server in Erwägung, da ich plane, einige IP-Komponenten einzusetzten (z.B. die schicken Steckdosen) ... ;)
Zitat von: lukasbastelpeter am 29 Dezember 2015, 18:49:43
Hallo zusammen, zunächst einmal meine Variante aus der CCU heraus Fhem-Befehle auszuführen, für alle die es interessiert:
-> Für "komplexere" Dinge wie z.B. Wetterberichte, die ich nicht unbedingt via http aufrufen will...
Eine alternative Möglichkeit zum Ausführen beliebiger FHEM Befehle aus der CCU heraus habe ich in HMCCU_Readme.txt in Abschnitt 6.2 beschrieben. Aber Deine Variante geht natürlich auch.
Zitat
Vielleicht könnte man in das Modul noch einbauen, dass es den start so lange verzögert bis die CCU hochgefahren ist? Keine Ahnung was man da als Indikator nimmt, bzw. wie man dann ALLES umbauen müsste, damit die CCU-Geschichten erst "defined" werden wenn die CCU am start ist?
Eine Wartefunktion wäre keine große Sache. Allerdings wird das natürlich den Start von FHEM ausbremsen. Die Frage ist, wie lange man FHEM warten lässt. Das könnte man über einen weiteren Parameter im define von HMCCU bestimmen mit Default = 0, d.h. gar nicht warten. Ich denke mal drüber nach. Du könntest auch das fhem Startscript /etc/init.d/fhem anpassen und dort in einer Schleife per ping checken, ob die CCU da ist.
Zitat
PS: Ich habe einen 4-Fach Aktor, und einige 2-Fach Aktoren definiert, da funktioniert der Status per RCP nicht so schön, alle Devices des Aktors bekommen den gleichen State, das statechannel-Attribut habe ich gesetzt... ?! -> Anscheinend bekommen alle Kanäle des Aktors den State der letzten "Schaltung"
Poste mal bitte die Definitionen. Sollte nicht so sein.
zunächst hier die defs:
Zitatdefine CCU HMCCU 192.168.XXX.XXX
attr CCU alias CCU-IO
attr CCU event-on-change-reading state
attr CCU group IOs
attr CCU loglevel 6
attr CCU room System
attr CCU rpcinterval 1
attr CCU rpcserver on
2-Fach Aktor
define F.DeckenLampe.Tuer HMCCUDEV XXXXX 1
attr F.DeckenLampe.Tuer userattr Licht Licht_map structexclude
attr F.DeckenLampe.Tuer IODev CCU
attr F.DeckenLampe.Tuer Licht F.Licht
attr F.DeckenLampe.Tuer alias Deckenlampe Tür
attr F.DeckenLampe.Tuer group Licht
attr F.DeckenLampe.Tuer room Flur
attr F.DeckenLampe.Tuer statechannel 1
attr F.DeckenLampe.Tuer statevals on:true,off:false
attr F.DeckenLampe.Tuer substitute true:on,false:off,1:on,0:off
define F.DeckenLampe.Innen HMCCUDEV XXXXX 2
attr F.DeckenLampe.Innen userattr Licht Licht_map structexclude
attr F.DeckenLampe.Innen IODev CCU
attr F.DeckenLampe.Innen Licht F.Licht
attr F.DeckenLampe.Innen alias Deckenlampe Innen
attr F.DeckenLampe.Innen group Licht
attr F.DeckenLampe.Innen room Flur
attr F.DeckenLampe.Innen statechannel 2
attr F.DeckenLampe.Innen statevals on:true,off:false
attr F.DeckenLampe.Innen substitute true:on,false:off,1:on,0:off
4-Fach Aktor:
define SZ.BettLampe.Tuer HMCCUDEV XXX 4
attr SZ.BettLampe.Tuer userattr Licht Licht_map structexclude
attr SZ.BettLampe.Tuer IODev CCU
attr SZ.BettLampe.Tuer Licht SZ.Licht
attr SZ.BettLampe.Tuer alias Bettlampe Tür
attr SZ.BettLampe.Tuer group Licht
attr SZ.BettLampe.Tuer room Schlafzimmer
attr SZ.BettLampe.Tuer statechannel 4
attr SZ.BettLampe.Tuer statevals on:true,off:false
attr SZ.BettLampe.Tuer substitute true:on,false:off,1:on,0:off
define SZ.BettLampe.Fenster HMCCUDEV XXX 3
attr SZ.BettLampe.Fenster userattr Licht Licht_map structexclude
attr SZ.BettLampe.Fenster IODev CCU
attr SZ.BettLampe.Fenster Licht SZ.Licht
attr SZ.BettLampe.Fenster alias Bettlampe Fenster
attr SZ.BettLampe.Fenster group Licht
attr SZ.BettLampe.Fenster room Schlafzimmer
attr SZ.BettLampe.Fenster statechannel 3
attr SZ.BettLampe.Fenster statevals on:true,off:false
attr SZ.BettLampe.Fenster substitute true:on,false:off,1:on,0:off
define SZ.Standby.Tag HMCCUDEV XXX 1
attr SZ.Standby.Tag IODev CCU
attr SZ.Standby.Tag alias Standby: Ladegeräte Wecker
attr SZ.Standby.Tag group Energie Management
attr SZ.Standby.Tag room Schlafzimmer
attr SZ.Standby.Tag statechannel 1
attr SZ.Standby.Tag statevals on:true,off:false
attr SZ.Standby.Tag substitute true:on,false:off,1:on,0:off
define SZ.Standby.Nacht HMCCUDEV XXX 2
attr SZ.Standby.Nacht IODev CCU
attr SZ.Standby.Nacht alias Standby: Sonos
attr SZ.Standby.Nacht group Energie Management
attr SZ.Standby.Nacht room Schlafzimmer
attr SZ.Standby.Nacht statechannel 2
attr SZ.Standby.Nacht statevals on:true,off:false
attr SZ.Standby.Nacht substitute true:on,false:off,1:on,0:off
Der Timer wäre als Reading ganz nett, ich hatte zwischenzeitlich überlegt den FHEM start abhängig vom Ping der CCU zu machen, bis jetzt bin ich in der Phase, in der mich ein Stromausfall nicht interessiert, aber wenn das mal passiert und alles gleichzeitig wieder an geht, steht man da :)...
Zitat von: lukasbastelpeter am 30 Dezember 2015, 10:32:22
zunächst hier die defs:
2-Fach Aktor
define F.DeckenLampe.Tuer HMCCUDEV XXXXX 1
attr F.DeckenLampe.Tuer statechannel 1
attr F.DeckenLampe.Tuer statevals on:true,off:false
attr F.DeckenLampe.Tuer substitute true:on,false:off,1:on,0:off
define F.DeckenLampe.Innen HMCCUDEV XXXXX 2
attr F.DeckenLampe.Innen statechannel 2
attr F.DeckenLampe.Innen statevals on:true,off:false
attr F.DeckenLampe.Innen substitute true:on,false:off,1:on,0:off
Alles klar, ich nehme an, die beiden XXXXX beim ersten und zweiten Device sind identisch, oder? In dem Fall hast Du zwar 2 Client Devices definiert, allerdings mit der gleichen CCU Geräteadresse, d.h. es handelt sich um das gleiche Gerät. Die Aktualisierung der Readings erfolgt bei Client Devices vom Typ HMCCUDEV über die Geräteadresse, nicht über die Kanaladresse. Daher überschreiben sich die STATEs gegenseitig.
Wie heißen denn die Datenpunkte bei den beiden Kanälen, die jeweils in STATE landen sollen? Ggf. geht was über das Attribut statedatapoint.
Ansonsten: Versuche es mal bitte mit HMCCUCHN. Die Defines sehen dann so aus:
define F.DeckenLampe.Tuer HMCCUCHN Name/Adresse_Channel1
define F.DeckenLampe.Innen HMCCUCHN Name/Adresse_Channel2
Dann werden die Client-Devices bei der Aktualisierung getrennt betrachtet (hoffentlich, sonst ist es ein Bug).
BTW: Statt
attr F.DeckenLampe.Innen substitute true:on,false:off,1:on,0:off
geht auch
attr F.DeckenLampe.Innen substitute (true|1):on,(false|0):off
Hallo Zap,
sorry dass ich mich jetzt erst wieder melde.
ZitatDu könntest im Frontend Forum im Tablet-UI Thread mal die Frage stellen, ob Tablet-UI Probleme hat, wenn in Reading-Names Leerzeichen vorkommen bzw. wie man damit umgehen muss. Oder Du könntest bei Deinen CCU Geräten auf Leerzeichen verzichten. Oder Du benutzt das Attribut "ccureadingformat" und setzt es auf address. Dann haben die Readings grundsätzlich die Adresse der CCU-Geräte als Name. Das sollte dann funktionieren.
Ich hatte die Umstellung auf "address" vorgenommen und es hat super funktioniert. Was leider nicht funktioniert hatte, war das Schalten des Thermostates. Mein TabletUI hat zwar die Schaltung abesetzt (sieht man ja an der kurzen Toast message) aber direkt darauf kam als Toast message "Error: error". Das Thermostat hat die Daten trotzdem empfangen und die Wunschtemperatur geändert, aber FHEM ist danach komplett abgestürzt. Allerdings hatte ich keine Fehlermeldung im Log. Da ich selbst keine CCU2 habe, kann ich das erst in ein paar Monaten wieder weiter basteln und testen. Bis dahin hast du sicher wieder ein paar neue Versionen eingecheckt. ;)
Finde das Modul aber bisher echt klasse. :D
VG, Thomas
Hallo tux,
Meine Beobachtung bei HMWired (es handelt sich übrigens um das 12-fach Input-Modul HMW-Sen-SC-12-DR, bei dem die einzelnen Kanäle :1 bis :12 ausgelesen werden) und die von lukasbastelpeter laufen wohl in dieselbe Richtung.
Ich habe die einzelnen Kanäle aktuell als einzelne HMCCUDEV Devices definiert und beobachte eine gemeinsame Aktualisierung, sobald ein Eingang aktualisiert wird. Allerdings ist dann jeweils auch der gelesene Status für die betroffenen Geräte identisch. Das Verhalten tritt vermutlich nur bei Ereignissen auf, die über den RPC Prozess einlaufen. Aktualisiere ich die Werte manuell über getstate, sehe ich keinen Fehler.
Du hattest ja zu HMCCUCHN geschrieben:
Zitat"Dann werden die Client-Devices bei der Aktualisierung getrennt betrachtet (hoffentlich, sonst ist es ein Bug)."
Ich hatte das schon versucht, und die Ports als HMCCUCHN oder auch probehalber als HMCCUDEV readonly definiert, das hat bisher jedoch nicht funktioniert. Möglicherweise gibt es hier noch ein Problem mit dem statedatapoint SENSOR. Darauf deutet für mich der folgende Eintrag aus dem Logfile hin:
(bei Definition als HMCCUCHN)
Zitat2015.12.29 20:23:54 1: HMCCU: Error URL = http://XXX.168.178.5:8181/do.exe?r1=dom.GetObject("BidCos-Wired.LEQXXX4691:1.SENSOR").State()
2015.12.29 20:23:54 1: HMCCUCHN: Fenster_OG_Schlafzimmer Execution of CCU script failed
---
(bei Definition als HMCCUDEV readonly)
Zitat2015.12.29 20:27:52 1: HMCCU: Error URL = http://XXX.168.178.5:8181/do.exe?r1=dom.GetObject("BidCos-Wired.LEQXXX4691:1.SENSOR").State()
2015.12.29 20:27:52 1: HMCCUDEV: Fenster_OG_Schlafzimmer Execution of CCU script failed
Das abweichende Verhalten zwischen den Einstellungen HMCCUDEV und HMCCUCHN deutet für mich in Richtung Bug hin.
Hallo hometux,
ich verwende das selbe Homematic wired Modul.
Zitat(bei Definition als HMCCUCHN)
Zitat
2015.12.29 20:23:54 1: HMCCUCHN: Fenster_OG_Schlafzimmer Execution of CCU script failed
Den gleichen Fehler hatte ich auch, habe jetzt bei
attr substitute 0:closed,1:open,false:closed,true:open, seit dem läuft es.
Zitat von: mw77 am 31 Dezember 2015, 18:49:55
Hallo hometux,
ich verwende das selbe Homematic wired Modul.Den gleichen Fehler hatte ich auch, habe jetzt bei attr substitute 0:closed,1:open,false:closed,true:open, seit dem läuft es.
Das kann nicht die Lösung des Fehlers sein. Die Ersetzung per substitute greift erst nach der erfolgreichen Ausführung des GET Befehls.
@hometux: Reden wir hier von einem GET oder SET? Bitte führe mal den Befehl "get deviceinfo" bei dem HMCCUDEV Device aus. Funktioniert der? Wie sieht die Ausgaben aus?
Gibt es eine Fehlermeldung in /var/log/messages der CCU?
Für die korrekte Aktualisierung eines Aktors mit mehreren Schaltkanälen müssen auf jeden Fall für jeden Schaltkanal HMCCUCHN Devices definiert werden, da diese vom RPC-Server über ihre Kanaladresse aktualisiert werden. HMCCUDEV Devices werden hingegeben über die Geräteadresse aktualisiert. Da diese für alle Schaltkanäle identisch ist, überschreiben sich die Statusänderungen gegenseitig.
Das Problem ist gelöst und funktioniert jetzt einwandfrei, vielen Dank an alle.
Wie zap schon geschrieben hat, muss bei Geräten die mehrere Kanäle verwenden, jeder Kanal als HMCCUCHN definiert werden. Verwendet man stattdessen (fälschlich) HMCCUDEV, so werden die Kanäle nicht separat ausgewertet. Bei den HM-Wired Geräten mit 12 Eingängen z.B. führt dies zu falschen Auslesewerten und unbefriedigenden Ergebnissen.
Mein zwischenzeitlicher Fehler war, dass ich Geräte einfach von HMCCUDEV auf HMCCUCHN umdefiniert habe. Das funktioniert aber nicht sofort (stattdessen tritt die oben beschriebene Fehlermeldung im Log auf), sondern erst nachdem die Geräteinfo der CCU neu gelesen wurde. Für das HMCCUCHN Device gibt es dazu allerdings keinen Befehl get deviceinfo. Man muss über HMCCU aktualisieren.
Ergänzend ist vielleicht der Hinweis interessant, dass es (natürlich) für HMCCUCHN kein statechannel attribut mehr gibt. Definiert man zusätzlich die Geräte als readonly gibt es auch kein attribut statevals.
Insgesamt jedenfalls eine tolle Sache. Das einzige was ich mir im Moment noch vorstellen könnte, ist eine bequemere Art, beim Start von fhem alle aktuellen Gerätestati auf einmal einzulesen.
Zitat von: hometux am 03 Januar 2016, 15:35:11
Das Problem ist gelöst und funktioniert jetzt einwandfrei, vielen Dank an alle.
Wie zap schon geschrieben hat, muss bei Geräten die mehrere Kanäle verwenden, jeder Kanal als HMCCUCHN definiert werden. Verwendet man stattdessen (fälschlich) HMCCUDEV, so werden die Kanäle nicht separat ausgewertet. Bei den HM-Wired Geräten mit 12 Eingängen z.B. führt dies zu falschen Auslesewerten und unbefriedigenden Ergebnissen.
Das führt nur dann zu Problemen, wenn mehrere Kanäle die gleichen Datenpunkte verwenden. Leider ist das bei praktisch allen Homematic Geräten mit mehreren Ein- oder Ausgängen so. Ein Schließerkontakt hat z.B. 3 Kanäle, wobei jeder einen STATE Datenpunkt hat. In dem Fall kann in HMCCUDEV eben nicht entschieden werden, welcher jetzt der ist, der in das FHEM Device STATE übernommen werden soll.
Zitat
Mein zwischenzeitlicher Fehler war, dass ich Geräte einfach von HMCCUDEV auf HMCCUCHN umdefiniert habe. Das funktioniert aber nicht sofort (stattdessen tritt die oben beschriebene Fehlermeldung im Log auf), sondern erst nachdem die Geräteinfo der CCU neu gelesen wurde. Für das HMCCUCHN Device gibt es dazu allerdings keinen Befehl get deviceinfo. Man muss über HMCCU aktualisieren.
Das muss was anderes gewesen sein. Der Befehl get deviceinfo listet einfach nur alle Kanäle und Datenpunkte eines CCU Gerätes auf. Da passiert sonst nix, nur reine Bildschirmausgabe. Da HMCCUCHN sich nur auf einen Kanal bezieht, gibt es natürlich keine DeviceInfo.
Zitat
Insgesamt jedenfalls eine tolle Sache. Das einzige was ich mir im Moment noch vorstellen könnte, ist eine bequemere Art, beim Start von fhem alle aktuellen Gerätestati auf einmal einzulesen.
Das geht derzeit nur per "get parfile" im HMCCU Modul. Zugegeben, das ist umständlich und man muss immer das Parfile aktuell halten. Muss ich mal drüber nachdenken. Das Problem ist, dass die Module beim Starten von FHEM nicht wissen, wann alles korrekt definiert und initialisiert ist (z.B. wann alle Attribute definiert sind).
Neue Version der Module / Dateien eingecheckt. Link siehe 1. Post.
Bei der Installation beachten: Vor dem Reload der Module den RPC-Server stoppen, dann "reload", danach "get devicelist" (IOdev), dann RPC-Server wieder starten.
Bug fixes:Fehler beim Prüfen auf laufenden RPC Server Prozess unter MacOS behoben.
Neue Funktionen:
- In jedem Client Device (definiert über HMCCUDEV oder HMCCUCHN) steht nun der Befehl "get update" zur Verfügung. Dieser Befehl aktualisiert alle Datenpunkte / Readings eines Client Devices unter Berücksichtigung der Attribute "ccureadings" und "ccureadingfilter". Der Befehl kann z.B. direkt nach der Definition eines Client Devices ausgeführt werden, um den aktuellen Zustand abzufragen (der RPC Server aktualisiert die Client Devices nur bei Änderungen).
- Im IO Device (HMCCU) steht ebenfalls der Befehl "get update" zur Verfügung. Dieser Befehl aktualisiert alle Datenpunkte / Readings aller Client Devices. Die zu aktualisierenden Client Devices können durch die optionale Angabe eines Filters für den FHEM Devicename eingeschränkt werden. Es bietet sich an, diesen Befehl als Reaktion auf den globalen FHEM Event "INITIALIZED" per Notify auszuführen, um nach dem Start von FHEM alle Client Devices auf den aktuellen Stand zu bringen.
- Beim Update der Stati von Client Devices vom Typ HMCCUDEV (Attribute "statechannel" und "statedatapoint") wird nun auch der Statechannel berücksichtigt. Dadurch werden die Stati von Client-Devices korrekt aktualisiert, die mehrere Kanäle mit identischen Datenpunkten haben (z.B. Schließerkontakte). D.h. es können nun z.B. für einen Schließerkontakt 3 Client-Devices vom Typ HMCCUDEV definiert werden, die sich jedoch im Attribut "statechannel" unterscheiden müssen. Trotz dieser neuen Funktion empfehle ich, in solchen Fällen auf das Modul HMCCUCHN zurück zu greifen und für jeden Kanal ein eigenes Device in FHEM zu definieren.
Testversion des RPC Servers für Wired und Funk:Als Attachment gibt es eine "Probierversion" eines RPC-Servers, der hoffentlich in der Lage ist, BidCos-RF und Wired Events gleichzeitig zu empfangen. Vielleicht kann das mal jemand testen, der beide Arten von Komponenten in Betrieb hat. Zur Installation:
- RPC-Server im IO Device stoppen
- Kopie der Orginaldatei anlegen
- Attachment ccurpcmpd.pl unter dem Namen ccurpcd.pl im FHEM Modulverzeichnis speichern (Rechte setzen!)
- Für das IO Device das Attribut "rpcport" auf "2001,2000" setzen
- RPC-Server im IO Device starten
Wenn es funktioniert oder auch nicht wäre Feedback schön. Bei Fehlern möglichst mit der ccurpcd.log
Zitat von: zap am 28 Dezember 2015, 09:28:54
Das geht natürlich und ich überlege, das auch so in die offiziellen Module aufzunehmen. Allerdings wird damit die Wartezeit zwischen set und nachfolgendem get verzehnfacht (100 ms => 1 s). Im Prinzip ist das usleep() und das get nur erforderlich, wenn kein RPC-Server verwendet wird, denn der RPC-Server wird durch das Set sowieso ein Event mit dem geänderten Wert von der CCU bekommen.
Die Fehlermeldung bei RainerG besagt eindeutig, dass usleep nicht gefunden wurde. Deshalb schmiert FHEM ab. Ich vermute immer noch, dass hier zwar die aktuellen Module und auch Time::HiRes installiert wurden, die Module aber mangels Reload bzw. FHEM-Neustart (Reload genügt normalerweise) nicht verwendet werden.
Hi zap!
Ich hab gestern angefangen Dein Werk bei mir einzuarbeiten (erstmal dickes
DANKE für die viele Arbeit!!)
Ich habe Rainers Problem - Time::HiRes ist auf Version 1.9728 und der RPi und damit auch FHEM haben schon mehrere Neustarts hinter sich... sollte ich auch auf sleep gehen oder kannst Du noch was ändern?
Danke und VG
Hallo zap,
Das ist ja ein richtig tolles Weihnachtsgeschenk - ganz vielen Dank.
Ich konnte eben nur ganz kurz einen ersten Probelauf durchführen.
Es sieht erst einmal toll aus, wenn nach einem get ccu update alle Geräte sofort mit Daten da sind. Das funktioniert offensichtlich.
Ein Problem habe ich noch bei der Aktivierung des 2. RPC Dienstes. Hier führt das Eintragen der beiden Ports zu einem Fehler, in dessen Folge sich der RPC Dienst beendet. Sieht mir aber eher nach Kleinigkeit aus.
Zitat2016.01.05 20:31:14 1: Including fhem.cfg
2016.01.05 20:31:14 3: WEB: port 8083 opened
2016.01.05 20:31:14 3: WEBphone: port 8084 opened
2016.01.05 20:31:14 3: WEBtablet: port 8085 opened
2016.01.05 20:31:14 2: eventTypes: loaded 1648 events from ./log/eventTypes.txt
"my" variable $value masks earlier declaration in same scope at ./FHEM/88_HMCCU.pm line 1747, <$fh> line 54.
2016.01.05 20:31:16 1: HMCCU: RPC server started with pid 10659
Argument "2001,2000" isn't numeric in addition (+) at ./FHEM/ccurpcd.pl line 129.
Error: Can't initialize RPC server
2016.01.05 20:31:16 1: Including ./log/fhem.save
2016.01.05 20:31:16 0: Featurelevel: 5.7
2016.01.05 20:31:16 0: Server started with 128 defined entities (fhem.pl:10220/2015-12-21 perl:5.018002 os:linux user:fhem pid:10657)
2016.01.05 20:32:16 1: HMCCU: RPC server has been shut down. f=0
Wie gesagt, ich konnte eben nur kurz probieren, morgen weiss ich mehr.
Hi FitzZZ, sorry ich bin grad unterwegs, suche mal in dem Thread nach meiner Lösung mit
Use Time:Res ...
Das hinter Time::Res war bei mir das ausschlaggebende.
Nochmals vielen Dank an zap!
Btw: wie muss ich einen Dimmer "set"en damit er an oder aus oder vielleicht sogar auf einen bestimmten Wert geht?
Danke!
Zum Thema Time::Hires
Ich werfe das usleep morgen raus. Wer heute schon ne Lösung will: in den .pm Files nach usleep suchen und entweder die Zeile rauswerfen oder, wenn man den RPC Server nutzt, sowohl usleep als auch das folgende Get löschen. Alternativ kann man auch usleep() durch sleep(1) ersetzen.
Zitat von: lukasbastelpeter am 05 Januar 2016, 21:50:34
Hi FitzZZ, sorry ich bin grad unterwegs, suche mal in dem Thread nach meiner Lösung mit
Use Time:Res ...
Das hinter Time::Res war bei mir das ausschlaggebende.
Zitat von: zap am 05 Januar 2016, 21:56:54
Zum Thema Time::Hires
Ich werfe das usleep morgen raus. Wer heute schon ne Lösung will: in den .pm Files nach usleep suchen und entweder die Zeile rauswerfen oder, wenn man den RPC Server nutzt, sowohl usleep als auch das folgende Get löschen. Alternativ kann man auch usleep() durch sleep(1) ersetzen.
Danke euch beiden! :-)
Zitat von: lukasbastelpeter am 05 Januar 2016, 21:50:34
Btw: wie muss ich einen Dimmer "set"en damit er an oder aus oder vielleicht sogar auf einen bestimmten Wert geht?
Schau mal hier und suche nach "dimmer":
http://www.eq-3.de/Downloads/PDFs/Dokumentation_und_Tutorials/HM_Script_Teil_4_Datenpunkte_1_503.pdf
Scheint im Kanal 1 (abhängig vom Gerätetyp) der Datenpunkt LEVEL zu sein. Den kannst Du auf Werte zwischen 0.0 und 1.0 setzen. Ruf doch einfach mal "get deviceinfo" für den Dimmer auf, dann siehst Du alle Datenpunkte mit den aktuellen Werten.
Zum Thema Time::Hires
Bei meinen Versuchen auf raspberry wheezy 3.9.40 mit perl 5.14.2 stürzte fhem immer bei den Aufrufen usleep ab.
Ich habe dann in 88_HMCCUDEV.pm use Time::HiRes durch use Time::Hires qw(gettimeofday usleep); ersetzt/ergänzt.
Seitdem läuft es bei mir.
Zitat von: hjjk am 06 Januar 2016, 16:02:24
Zum Thema Time::Hires
Bei meinen Versuchen auf raspberry wheezy 3.9.40 mit perl 5.14.2 stürzte fhem immer bei den Aufrufen usleep ab.
Ich habe dann in 88_HMCCUDEV.pm use Time::HiRes durch use Time::Hires qw(gettimeofday usleep); ersetzt/ergänzt.
Seitdem läuft es bei mir.
Jep. Mittlerweile bin ich auch drauf gekommen. Updates habe ich gerade eingecheckt. Damit sollte das usleep() Thema hoffentlich erledigt sein (betraf nur HMCCUDEV und HMCCUCHN). Außerdem habe ich noch einen kleinen Bug in HMCCU gefixt.
@hometux: Die Fehlermeldung beim Starten des RPC-Servers für Wired/Wireless ist seltsam. Bei mir funktioniert das. Anbei eine neue Version mit einem zusätzlichen Log-Statement. Bitte dann mal die letzten Zeilen der ccurpcd.log posten. Wie sieht bei Dir das Attribut "rpcport" aus? Falls Du statt 2001,2002 da "2001,2002" (in Anführungszeichen) stehen hast, lass die mal weg.
Hallo zap,
Es funktioniert!
Das Problem lag wohl daran, dass in einem alten Post noch ein anderer Name für den RPC-Server angegeben war. Dadurch blieb der alte RPC Dienst weiterhin in Betrieb. Nachdem ich dies heute abend bereinigt habe, läuft der neue RPC Dienst ohne Fehler und sieht auch bisher sehr gut aus.
Eine kleine Auffälligkeit mit HMCCUDEV habe ich bein Testen noch gefunden (ist kein wirkliches Problem, aber evtl. Indiz für eine Unschärfe). Ich versuche einmal, es zu beschreiben:
a) HM-Sec-TiS (Neigungssensor) liefert als HMCCUDEV beim "get xxx update" Befehl (interessanterweise auch bei "get ccu update") einen Fehler (nur im Dialog, nicht im Logfile). Führt man stattdessen den "get xxx devstate" Befehl aus, wird der Status korrekt gelesen und substituiert. Ich habe daraufhin den Sensor als HMCCUCHN definiert. Anschließend funktioniert auch der get xxx update Befehl einwandfrei. In beiden Fällen war übrigens die Definition als readonly erfolgt.
b) HM-Sec-SD (Rauchmelder) liefert als HMCCUDEV readonly mit "get xxx devstate" einen auswertbaren Status (0/1). Ruft man stattdessen den "get xxx update" Befehl auf, so wird kein Wert geliefert, allerdings auch kein Fehler. Der Status verbleibt auf initialized. In diesem Fall brachte ein Umstellen auf HMCCUCHN nichts.
Das Verhalten wirkt so ähnlich wie ein entsprechender Readingsfilter.
Ansonsten bin ich hoch begeistert. Es sieht einfach toll aus, wenn einem nach dem Start jetzt der vollständige Status entgegenleuchtet.
Zitat von: hometux am 06 Januar 2016, 19:16:10
Hallo zap,
Es funktioniert!
D.h. Es werden sowohl wired als auch bidcosrf Devices vom RPC Server aktualisiert? Wenn dem so ist, werde ich den neuen Server einchecken.
Zitat
Das Problem lag wohl daran, dass in einem alten Post noch ein anderer Name für den RPC-Server angegeben war. Dadurch blieb der alte RPC Dienst weiterhin in Betrieb. Nachdem ich dies heute abend bereinigt habe, läuft der neue RPC Dienst ohne Fehler und sieht auch bisher sehr gut aus.
Das war ja so gedacht, dass die Datei ccurpcmpd.pl aus dem Attachment in meinem Post die bisherige ersetzen soll, und zwar unter dem Namen ccurpcd.pl. Nur die kennt HMCCU.
Zu den get update Problemen: Hast Du die 88_HMCCU.pm von heute nochmal runtergeladen? In get update gab es beim Substitute noch einen Fehler.
Ansonsten poste bitte mal die Definition des problematischen Devices und die Ausgabe von get deviceinfo mit dem Fehler.
Hallo zap,
Das Update von heute habe ich eingespielt. Auch damit beobachte ich das Update Problem.
Ich würde das Verhalten gerne noch einen Tag beobachten, bis ich ein Gesamtbild habe. Zeitweilig hatte ich das Gefühl, dass Aktualisierungen später kommen, aber das kann auch der Einlesephase geschuldet sein.
Zitat von: hometux am 06 Januar 2016, 21:51:19
Hallo zap,
Das Update von heute habe ich eingespielt. Auch damit beobachte ich das Update Problem.
Ich würde das Verhalten gerne noch einen Tag beobachten, bis ich ein Gesamtbild habe. Zeitweilig hatte ich das Gefühl, dass Aktualisierungen später kommen, aber das kann auch der Einlesephase geschuldet sein.
Schau Dir mal die Zeitstempel für die Startphase des RPC-Servers in der Datei ccurpcd.log an. Normalerweise lässt sich die CCU für die Registrierung der Callback-Funktion exakt 3 Minuten Zeit. Da Du nun 2 Ports (2000 und 2001) registrierst, könnte sich diese Zeit verdoppeln. D.h. in den ersten 6 Minuten nach dem Start des RPC-Servers kommen keine Events (Vermutung, habe kein Wired und nutze nur einen Port).
Ansonsten wird die Aktualisierungsfrequenz durch das Attribut rpcinterval bestimmt.
Hallo zap,
Hier die Ergebnisse meiner heutigen Probeläufe. Es scheint leider doch noch Probleme bei 2 parallelen RPC Prozessen zu geben.
Ich hatte zunächst die Einstellung
rpcport 2000,2001Damit schienen alle
Wired Ereignisse anzukommen. Wireless Ereignisse kamen nicht an, bzw. ich hatte den Eindruck das ganz selten einmal welche durchkamen.
Ich habe dann die Einstellung vertauscht. Bei der Einstellung
rpcport 2001,2000kamen nach meinem Eindruck alle
Wireless Ereignisse an. Wired Ereignisse habe ich nicht gesehen, allerdings hatte ich auch hier den Eindruck, dass ganz selten einmal doch eines "durchkam".
Im Logfile gab es keine Fehlermeldungen. Der (neue) rpc Prozess startete ohne Fehlermeldungen und blieb den ganzen Tag aktiv.
Zu der vorher beschriebenen HMCCUDEV Anomalie habe ich am Beispiel des Neigesensors HM-Sec-TiS (Verschluss_Schwingtor) folgendes Verhalten dokumentieren können. Wie gesagt, durch Definition als HMCCUCHN kann man das Problem einfach umgehen, aber es ist m.E. dennoch merkwürdig:
Vorgehen:
get ccu updateliefert Fehlerdialog:
103 client devices successfully updated. Update for 1 client devices failedget Verschluss_Schwingtor updateliefert Fehlerdialog:
HMCCUDEV: Verschluss_Schwingtor Execution of CCU script failedReadings:
state Error
get Verschluss_Schwingtor devstateist erfolgreich
Readings:
Schwingtor_Zustand.STATE zu
state zu
get Verschluss_Schwingtor deviceinfoliefert Fehlerdialog:
HMCCUDEV: Verschluss_Schwingtor Execution of CCU script failed (das steht auch im Logfile)
Die fhem.cfg dazu:
Zitatdefine Verschluss_Schwingtor HMCCUDEV LEQXXX6818 1 readonly
attr Verschluss_Schwingtor IODev ccu
attr Verschluss_Schwingtor devStateIcon auf:fts_garage_door_10@green zu:fts_garage_door_100@red .*:fts_garage_door_50@grey
attr Verschluss_Schwingtor fp_Grundriss_Garten 159,485,5, ,Verschluss_Schwingtor
attr Verschluss_Schwingtor group Verschluss
attr Verschluss_Schwingtor icon fts_garage
attr Verschluss_Schwingtor room Garage
attr Verschluss_Schwingtor statedatapoint STATE
attr Verschluss_Schwingtor substitute true:auf,false:zu,1:auf,0:zu
attr Verschluss_Schwingtor statechannel 1
Logfilemeldung lautet bei Fehler jeweils:
Zitat2016.01.07 18:29:30 1: HMCCU: Error URL = http://XX.XX.XX.XX:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQXXX6818:1.STATE").State()
2016.01.07 18:29:30 1: HMCCUDEV: Verschluss_Schwingtor Execution of CCU script failed
Jetzt habe ich das HMCCUDEV zu einem HMCCUCHN umdefiniert. Damit funktionieren die Befehle:
get ccu update
get Verschluss_Schwingtor update
get Verschluss_Schwingtor devstateget Verschluss_Schwingtor deviceinfo gibt es hier nicht, kann also auch keinen Fehler melden
Die fhem.cfg jetzt:
Zitatdefine Verschluss_Schwingtor HMCCUCHN LEQXXX6818:1 readonly
attr Verschluss_Schwingtor IODev ccu
attr Verschluss_Schwingtor devStateIcon auf:fts_garage_door_10@green zu:fts_garage_door_100@red .*:fts_garage_door_50@grey
attr Verschluss_Schwingtor fp_Grundriss_Garten 159,485,5, ,Verschluss_Schwingtor
attr Verschluss_Schwingtor group Verschluss
attr Verschluss_Schwingtor icon fts_garage
attr Verschluss_Schwingtor room Carport
#attr Verschluss_Schwingtor statechannel 1
attr Verschluss_Schwingtor statedatapoint STATE
attr Verschluss_Schwingtor substitute true:auf,false:zu,1:auf,0:zu
Danke für das Testen des RPC Servers. Das war ein Versuch, 2 Schnittstellen über einen Server abzufrühstücken. Funktioniert anscheinend nicht. Hatte ich befürchtet. Dann muss ich wohl den aufwändigeren Weg gehen und 2 Prozesse implementieren. In dem Fall musst Du noch etwas Geduld haben.
Zu dem Update Problem komme ich erst morgen.
Eine Frage: Du schreibst, dass "get Verschluss_Schwingtor devstate" funktioniert (auch über HMCCUDEV). Weiter unten schreibst Du aber, dass im Log eine Fehlermeldung auftaucht:
2016.01.07 18:29:30 1: HMCCU: Error URL = http://XX.XX.XX.XX:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQXXX6818:1.STATE").State()
2016.01.07 18:29:30 1: HMCCUDEV: Verschluss_Schwingtor Execution of CCU script failed
Das widerspricht sich m.E., zumal die erste Meldung von HMCCU kommt. Wird diese Meldung wirklich als Reaktion auf "get devstate" für ein HMCCUDEV Device geschrieben? Auch seltsam: beide Meldungen kommen zur gleichen Zeit.
Verstehe ich das richtig: "get update" funktioniert für alle HMCCUDEV Geräte, nur nicht für das Schwingtor?
Hintergrund meiner Fragen: Die Meldung "Execution of script failed" kann nur von meinem "get update", "get channel" oder "get deviceinfo" kommen. Die Meldung "Error URL ..." hingegen nur von einem "get devstate" oder "get datapoint".
Ich habe eine neue Version von 88_HMCCU.pm eingecheckt (Link siehe 1. Post).
Es gibt nun ein neues Attribut "ccutrace", das eine bessere Fehleranalyse ermöglicht. Mit dem Attribut wird ein regulärer Ausdruck für CCU Geräteadressen und/oder CCU Gerätenamen festgelegt. Bei Ausführung der Befehle "get datapoint", "get devstate", "get update" oder "get deviceinfo" werden für die festgelegten Geräte ausführliche Informationen in das FHEM Logfile geschrieben (Loglevel 1).
@hometux: In Deinem Fall solltest Du das Attribut wie folgt setzen:
attr ccu ccutrace (LEQXXX6818|name_in_ccu)
XXX und name_in_ccu durch entsprechende Werte ersetzen.
Dann "get Verschluss_Schwingtor update" und "get Verschluss_Schwingtor deviceinfo" ausführen (für HMCCUDEV Device) und die Ausgabe in fhem Log per Forum-Mail an mich (damit Du die Orginaladressen und Namen nicht hier im Forum posten musst).
Neue Version der Module 88_HMCCU* sowie vom RPC-Server ccurpcd.pl eingecheckt.
Fehlerbehebungen:
- Befehl get rpcstate lieferte u.U. falsche Aussage über laufenden RPC-Server Prozess
Neue Funktionen:
- Mit dem Attribut "rpcport" kann nun eine Liste von CCU Ports angegeben werden, um gleichzeitig Ereignisse von BidCos-RF (Port 2001) und Wired Devices (Port 2000) zu empfangen (attr name rpcport 2001,2000). Es werden dann 2 RPC-Server Prozesse gestartet. An den Namen der Queue-Files sowie an den Namen des RPC Server Logfiles wird die Portnummer angehängt, d.h. die Prozesse verwenden separate Dateien (z.B. ccurpcd_2000.log und ccurpcd_2001.log).
- Mit dem Attribut "ccuget" kann die Methode festgelegt werden ("State" oder "Value"), mit der die get Befehle Datenpunkte auslesen. Per Default wird "Value" verwendet. Diese Methode liest die Werte von Datenpunkten aus der CCU. Die Methode "State" erzwingt hingegen das direkte Abfragen der Geräte. Das dauert zwar länger und belastet die Batterien der Geräte, es kann jedoch bei einigen Geräten notwendig sein, um korrekte Werte zu erhalten. Wenn in einem Client Device "ccuget" nicht gesetzt ist, aber im IO-Device, dann wird das Attribut vom IO-Device verwendet. Ich empfehle, das Attribut ccuget = "State" nur Device bezogen zu verwenden, d.h. bei den Devices, bei denen 'Value' nicht korrekt funktioniert.
- Bei den Befehlen "get update" und "get deviceinfo" kann optional die Abfragemethode "State" oder "Value" angegeben werden (derzeit nur per Kommandozeile). Auf diese Weise kann getestet werden, ob das Setzen des Attributs "ccuget" sinnvoll ist. Der direkt im Befehl angegebene Parameter hat Vorrang vor dem Attribut 'ccuget'.
Beispiel für HMCCUDEV/HMCCUCHN Devices:
get mydevice update State
Beispiel für globales Update aller Devices (Vorsicht, stresst die CCU bei vielen Devices, die Angabe .* ist notwendig, da man beim update Befehl von HMCCU einen Device-Filter angeben kann):
get myIOdevice update .* State
Es wäre schön, wenn mal jemand mit BidCos und Wired Devices den Parallelbetrieb von 2 RPC-Servern testen könnte, d.h. die automatische Aktualisierung der Readings in FHEM (ich habe keine Wired Komponenten).
P.S. Die Doku HMCCU_Readme.txt habe ich noch nicht aktualisiert.
Kleiner Bugfix für 88_HMCCU.pm eingecheckt. Befehl "get devstate" sollte nun wieder funktionieren. Sorry. Hatte gestern Abend alles getestet bis auf get devstate. Und genau da einen riesen Bock eingebaut ;-)
Hallo zap,
Das neue Release sieht richtig gut aus! get devstate funktioniert wie erwartet und der rpc Dienst arbeitet mit Wired und Wireless Port gleichzeitig.
Herzlichen Dank!
Habe gerade neue Versionen der Module (88_HMCCU*) eingecheckt. Ich nenne die Version jetzt mal die "Rauchmelder Version". hometux weiß, wovon ich rede ;-)
Hintergrund: Aus mir unerfindlichen Gründen funktioniert die Homematic Script Funktion EnumUsedIds() bei Rauchmeldern für die Datenpunkte im Kanal 1 (hier liegt STATE) nicht. Das hatte Auswirkungen auf die Befehle "get update", "get channel" und "get deviceinfo". Der Fehler tritt interessanterweise auch bei XML-API auf. Das habe ich nun behoben, d.h. diese Funktion wird einfach nicht mehr verwendet. Ich denke, das ist ein Bug in der CCU Software.
Außerdem habe ich noch eine neue Funktion eingebaut: HMCCU berücksichtigt nun auch RPC Delete Device Events. D.h. wenn in der CCU ein Gerät gelöscht wird, das in FHEM als Device vorhanden ist, wird dieses Device als "Deleted" markiert und kann nicht mehr für Set/Get Aktionen verwendet werden. Das FHEM Device bleibt jedoch bis zum nächsten Restart (ohne Funktion) erhalten.
Hallo zap,
welche Attribute müssen gesetzt werden, um den HM-LC-BL1-FM Funk-Jalousieaktor aus FHEM mit dem HMCCUDEV bedienen zu können? Mir fehlt die Möglichkeit per Schieberegler die Position bestimmen zu können.
Gruß,
Christoph
Hmm, damit habe ich mich noch nicht beschäftigt. Ich nutze Tablet-UI. Dort genügt es, im Widget den entsprechenden Datenpunkt anzugeben.
HMCCU ist sehr generisch gehalten, d.h. die verschiedenen Homematic Typen erfahren keine Sonderbehandlung wie z.B. un CUL_HM.
Ich weiß nicht, was hier mit FHEM Bordmitteln wie webCmd usw. möglich ist.
Der Kanal und Datenpunkt, über den die Steuerung erfolgt, ist Dir bekannt?
Hallo zap,
ja, dass ist mir bekannt. Funktioniert auch mit set super, hatte gedacht ich hätte was übersehen.
Gruß,
Christoph
Ich habe gerade eine neue Version von 88_HMCCUDEV.pm eingecheckt. Das ist ein erster Versuch, für einen Datenpunkt eines Devices alternative Steuerelemente (z.B. Slider) bereitzustellen. Es gibt nun ein neues Attribut "controldatapoint". Damit wird eine Datenpunkt festgelegt, der mit dem Befehl "set xxx control Wert" gesetzt werden kann. Format des Datenpunktes ist Kanalnummer.Datenpunkt.
Beispiel: Bei einem Heizungsthermostaten soll ein Slider zur Einstellung der Zieltemperatur angezeigt werden.
1) Zunächst das Attribut "controldatapoint" auf den Kanal/Datenpunkt setzen, mit dem die Zieltemperatur eingestellt wird:
attribute mydev controldatapoint 2.SET_TEMPERATURE
2) Webcmd und WidgetOverride definieren:
attribute mydev webCmd control
attribute mydev widgetOverride control:slider,10,1,30
Der Befehl "set mydev control nn" setzt den Datenpunkt 2.SET_TEMPERATURE auf den gewünschten Wert nn.
Analoge Vorgehensweise für einen Rolladenaktor. Da ich mich mit dem webCmd-Konstrukt nicht auskenne, weiß ich leider nicht, wie man den Slider dazu bringt, immer den aktuell eingestellten Wert anzuzeigen. Bei mir zeigt er immer irgendeinen Wert an. Wenn ich den Slider bewege, wird aber der eingestellte Datenpunkt korrekt gesetzt. Vielleicht hat ja jemand einen Tipp ...
So richtig überzeugt mich die antiquierte FHEM Oberfläche nicht. Möglicherweise werfe ich das Feature wieder raus.
Hallo zap,
vielen Dank für die schnelle Unterstützung. Leider funktioniert das Modul noch nicht richtig mit dem Rolladenaktor. Die Werte für den Rolladenaktor müssen im Wertebereich von 0 bis 1 liegen, der Slider übermittelt aber nur Werte von 1 bis 100.
Hier mein Code:
define Rolladen.Wohnzimmer HMCCUDEV Rolladen_Wohnzimmer 1
attr Rolladen.Wohnzimmer IODev CCU2
attr Rolladen.Wohnzimmer controldatapoint 1.LEVEL
attr Rolladen.Wohnzimmer statechannel 1
attr Rolladen.Wohnzimmer statedatapoint LEVEL
attr Rolladen.Wohnzimmer webCmd control
attr Rolladen.Wohnzimmer widgetOverride control:slider,0,0.000001,1
Danke,
Christoph
Zitat von: christoph_j am 21 Januar 2016, 21:43:28
Hallo zap,
vielen Dank für die schnelle Unterstützung. Leider funktioniert das Modul noch nicht richtig mit dem Rolladenaktor. Die Werte für den Rolladenaktor müssen im Wertebereich von 0 bis 1 liegen, der Slider übermittelt aber nur Werte von 1 bis 100.
Hier mein Code:
attr Rolladen.Wohnzimmer widgetOverride control:slider,0,0.000001,1
Hat vermutlich mit den Werten <1 zu tun. Lies mal das hier:
http://forum.fhem.de/index.php/topic,44104.msg359791.html#msg359791
und versuche mal folgendes (auf jeden Fall bei Start und Ende die ".0" mit angeben:
attr Rolladen.Wohnzimmer widgetOverride control:slider,0.0,0.01,1.0
BTW: Bist Du sicher, dass Du so kleine Schritte einstellen möchtest? m.E. sollten ganze Prozentschritte reichen (s. Beispiel).
Wie gesagt, kenne mich damit nicht wirklich aus und habe derzeit keinen Rolladen-Aktor im Einsatz.
Hallo zap,
jetzt funktioniert es. Am ende fehlte noch ne 1:
attr Rolladen.Wohnzimmer widgetOverride control:slider,0.00,0.01,1.00,1
Das sind jetzt 100 Positionen die eingestellt werden können.
Gruß,
Christoph
Die 3 HMCCU Module unterstützen nun FHEM Widgets (z.B. Slider Controls). Dazu wurde in HMCCUDEV und HMCCUCHN ein neues Attribut "controldatapoint" eingeführt. Mit diesem Attribut wird der Datenpunkt festgelegt, der mit dem Widget geändert werden soll. Wenn dieses Attribut gesetzt ist, wird beim Aktualisieren des Datenpunkts ein Reading "control" gesetzt. Dies ist erforderlich, damit das Widget den aktuellen Wert anzeigt.
Beispiel: Ein Wandthermostat hat im Kanal 2 einen Datenpunkt SET_TEMPERATURE, mit dem die Zieltemperatur gesetzt wird. Die Einstellung soll mit einem Slider in 1 Grad Schritten zwischen 10 und 25 Grad erfolgen:
attr mydev controldatapoint 2.SET_TEMPERATURE
attr mydev webCmd control
attr mydev widgetOverride control:slider,10,1,25
Bitte beachten: Bei Devices vom Typ HMCCUCHN muss für "controldatapoint" nur ein Datenpunkt angegeben werden, da der Kanal bereits durch das Device vorgegeben ist.
Der Screenshot zeigt 3 Wandthermostate mit den aktuellen Werten für Temperatur, Luftfeuchte, Zieltemperatur und Taupunkt sowie einem Slider zum Einstellten der Zieltemperatur.
Hall zap,
Mit dem RM-Release werden bei mir seit ca. einer Woche die Rauchmelder richtig ausgelesen - Vielen Dank!
Danke erstmal für die klasse Arbeit...
Kann es sein, dass es Probleme mit Homematic Device Namen gibt wenn diese ein " " also quasi ne Leerstelle enthalten? Ich kann sie nämlich nur über die Adresse einbinden. Wenn ich dann aber was schalten will, gibt es einen "script fehler".
Wo finde ich die scripte auf dem raspi?
Zitat von: luke666s am 28 Januar 2016, 16:07:16
Kann es sein, dass es Probleme mit Homematic Device Namen gibt wenn diese ein " " also quasi ne Leerstelle enthalten? Ich kann sie nämlich nur über die Adresse einbinden. Wenn ich dann aber was schalten will, gibt es einen "script fehler".
Habe jetzt mal mit einer Steckdose, die ich noch rumliegen hatte getestet. Die Steckdose habe ich als "TEST LICHT" in der CCU angelernt. Dann in FHEM im HMCCU Modul ein "get devicelist".
Folgender Befehl funktioniert dann
nicht:
define testlicht HMCCUDEV TEST LICHT 1
Leider trennt FHEM in der Kommandozeile bei jedem Leerzeichen gnadenlos. Ich habe es mit " und ' versucht. Ich habe vor das Leerzeichen ein oder zwei \ eingefügt und auch das Leerzeichen durch %20 ersetzt. Bringt alles nix. Beim Define muss also die Adresse verwendet werden, sofern der CCU Gerätename Leerzeichen enthält (ja, ich könnte im Modul alles in einen String joinen, das wird aber beliebig komplex, weil ja auch noch die Angabe des Statechannels möglich sein soll). Ich hoffe, man kann mit dieser Unannehmlichkeit leben.
Das Schalten funktioniert bei mir aus HMCCUDEV heraus jedoch einwandfrei. Habe folgendes getestet:
attr testlicht statevals on:true,off:false
set testlicht on
set testlicht datapoint 1.STATE off
Kannst Du bitte mal Deine Gerätedefinition posten? Bei welchem Befehl kommt der Script Error?
In HMCCU direkt gibt es natürlich wieder die Problematik mit der Parameter-Trennung bei Leerzeichen.
Zitat
Wo finde ich die scripte auf dem raspi?
Als Dateien gar nicht. Die Scripte sind direkt im Modulcode als Textstrings hinterlegt.
also... ja passt man kann die devices an der ccu ja auch umbenennen... mit . statt " " passt es... fast...
ich dachte naiv ein guter fhem name sei "ccu2_Schlafzimmer_Licht_am_Bett" und wollte das CCU Device "Schlafzimmer.Licht.am.Bett" nehmen... das klappte aber auch nicht...
wenn ich das Kürze passt es...
ich habe jetzt nur das Problem wenn ich bei der definition der ccu den rpcserver auf on setzte... dauert es nicht lange und die ccu reagiert nicht mehr....
Punkte im CCU Gerätenamen machen Probleme. Mich wundert, dass die CCU das überhaupt akzeptiert. Grund: Der Punkt wird als Abgrenzung in der CCU Geräte/Datenpunkt Notation verwendet. Ein Datenpunkt wird in der CCU wie folgt adressiert:
Interface.Kanal-Name.Datenpunkt (z.B. "BidCos-RF.LICHT-SCHLAFZIMMER:1.STATE")
oder
Interface.Kanal-Adresse.Datenpunkt (z.B. "BidCos-RF.ABC1234567:1.STATE")
Zum RPC-Server: Nach dem Setzen von rpcserver=on meldet sich der RPC-Server Prozess bei der CCU an. Diese Anmeldung dauert 3 Minuten. Während dieser Zeit ist die CCU nicht zu gebrauchen, d.h. ein Zugriff auf das Webinterface geht - wenn überhaupt - extrem schleppend. Meinst Du das mit "nicht reagieren"? Wenn ich meine CCU während der 3 Minuten in Ruhe lasse, läuft der RPC-Server und die CCU problemlos (mein Rekord liegt bei 2 Wochen, nur unterbrochen, weil ich FHEM upgedated habe).
Du kannst Dir aber mal das CCU Logfile anschauen, ob da Fehlermeldungen drin stehen: /var/log/messages
Kann man entweder über die Oberfläche der CCU runterladen oder direkt nach Anmeldung per SSH an der CCU anschauen.
ahhh... wieder was gelernt :)
ja, das meinte ich mit nicht reagieren.... genau... hatte aber auch keine 3 min gewartet... bin ja ehrlich... ich hatte das gestern abend alles so mehr oder minder im parallel betreib gemacht und mich geärgert, dass sobald rpcserver auf on war die ccu "weg" war...
dann geht es heute abend weiter :)
Die 3 Minuten sind mir auch ein Rätsel. Der RPC-Server schickt den Init an die CCU und dann dauert es exakt 3 Minuten, bis dieser Aufruf "zurückkehrt". Warum da so ist weiß wohl nur EQ-3.
neee.... irgendwas passt da nicht... das ding (ccu2) hängt jetzt über schon über 15 minuten... und die einzige änderung zu vorher war: rpcserver on als attr der ccu2 im fhem.
fhem.log
(http://i.imgur.com/QnNqUES.png)
ccurpcd_2001.log
(http://i.imgur.com/xu9SRgf.png)
/var/log/mesages auf der ccu
(http://i.imgur.com/KAIDabb.png)
Im ccurpcd_2001.log kommt nach dem "Registering callback ..." nix mehr? Das ist schlecht. Das ist genau die Stelle, wo es nach 3 Minuten weiter gehen sollte mit der Anzahl der Kanäle in der CCU.
Was mich wundert: Im Logfile auf der CCU tauchen Meldungen "rfd: Event ..." auf, die darauf hindeuten, dass die CCU events rausschickt. Hast Du noch was anderes laufen, das sich an die RPC-Schnittstelle der CCU andockt (obwohl das eigentlich funktionieren sollte, wenn es nicht gerade auch auf dem Raspi läuft)?
Ich muss mir das heute Abend auf meiner CCU mal anschauen und die Meldungen vergleichen.
neee.. nix.. hab auch auf der ccu2 nur noch den CuxD als Plugin (welcher ja auch über rpc kommuniziert) drin.. allles andere habe ich schon raus geschmissen...
Die firmware auf der ccu2 ist 2.15.5, und auf dem frisch installierten raspi läuft fhem 5.7 als dpkg installiert und die HHCCU sachen habe ich ausm SVN
CUxD hab ich auch, ist also kein Thema. Bei mir schreibt die CCU überhaupt keine Meldungen in /var/log/messages, wenn ich den RPC Server starte. Du kannst mal auf der CCU prüfen, ob der RFD richtig läuft:
# ps -ef | grep `fuser 2001/tcp`
311 root /bin/rfd -d -f /etc/config/rfd.conf -l 5
Ich teste das jetzt mal bei mir mit vollem Logging auf der CCU. Und hier das Ergebnis: Nichts zu finden, was auf einen Fehler hindeutet. Beim "Registering Callback ..." steht im CCU Log "user.debug rfd: PlatformInit()". Dann kommt 3 Minuten nichts und danach geht der Event-traffic los.
Das ist bei Dir der letzte Eintrag. Hast Du mal die CCU neu gestartet?
UPDATE: Lies mal ab hier http://forum.fhem.de/index.php/topic,40189.msg376774.html#msg376774
die Beiträge von mifh. Der hatte das gleiche Problem. Scheint mit den Versionen der Perl RPC Module zusammen zu hängen (Evtl.)
die beiträge kannte ich schon 8) das paket war schon installiert und PRC::XML ist v1.60 laut cpan
317 root /bin/rfd -d -f /etc/config/rfd.conf -l 1
läuft auch...
Edit 22:07:
AAAAABER... ich schaue mir grad dein code an... Welche Perl Version hast du? bzw auf welchem OS arbeitest du? raspbian mit wheezy hat nur perl 5.14 FindBin ist aber erst ab 5.2 erhältlich...
ich versuch mal ein neues perl über cpan zu bauen oder hat jemand nen backport???
next edit:
perl über cpan updaten geht nicht : :-[ oh man dann halt ein debian upgrade... könnte alles so leicht sein, wenn der microsd/sd adapter nicht auf der arbeit liegen würde...
Elapsed: 5809 sec
u=44.58 s=10.55 cu=2357.70 cs=92.32 scripts=2208 tests=707885
SHAY/perl-5.22.1.tar.bz2
/usr/bin/make test -- OK
Running make install
make: *** No rule to make target '/usr/include/arm-linux-gnueabihf/bits/predefs.h', needed by 'perlmini.o'. Schluss.
SHAY/perl-5.22.1.tar.bz2
/usr/bin/make install -- NOT OK
root@raspi:/opt/fhem#
Problem gelöst!!!
Update auf Debian Jessie und mit 5.2er perl und FindBin klappts...
komischerweise kam bei wheezy mit 5.16 ohne FindBin keine Fehlermeldung....
Zitat von: luke666s am 30 Januar 2016, 19:19:09
Problem gelöst!!!
Update auf Debian Jessie und mit 5.2er perl und FindBin klappts...
komischerweise kam bei wheezy mit 5.16 ohne FindBin keine Fehlermeldung....
Freut mich, dass es läuft!
Ich glaube nicht, dass es am FindBin lag. Das wird nur benötigt, damit das folgende "use RPCQueue" das Modul RPCQueue.pm findet. RPCQueue.pm wiederum hat nichts mit der CCU Kommunikation zu tun sondern kümmert sich nur um das Schreiben/Lesen der File-Queue.
Vermutlich wurden durch das Update auf Jessie mit neuem Perl einige Probleme im RPC-Umfeld behoben. Der Vollständigkeit halber hier noch die von mir verwendete Umgebung:
- Debian Wheezy (brauche ich, da es sich bei meinem Raspi eigentlich um eine Meteohub Installation handelt, auf die ich FHEM mit drauf gepackt habe)
Perl 5.14.2
RPC::XML::Server.pm 1.73
RPC::XML::Client.pm 1.42
Entwicklung unter MacOSX, Kontakt zu Linux vermeide ich wenn es geht aufgrund negativer Erfahrungen mit der Library- bzw. Version- bzw. Dependency-Hölle ;-)
Hallo,
ich verwende seit ein paar Tagen auch die neuste Version des HMCCU-Modul und möchte meine Thermostate (HM-CC-RT-DN) auslesen und steuern. Nach dem Update auf die aktuellste Version hab ich die Thermostate als HMCCUCHN angelegt. Das sieht so aus:
<FHZINFO>
<HMCCUCHN_LIST>
<HMCCUCHN name="HM_BZ_Thermostat" state="23.0" sets="config datapoint devstate:" attrs="verbose:0,1,2,3,4,5 room group comment:textField-long alias eventMap userReadings:textField-long IODev ccureadingfilter ccureadingformat:name,address,datapoint ccureadings:0,1 ccustate ccuget:State,Value controldatapoint statedatapoint statevals substitute stripnumber:0,1,2 loglevel:0,1,2,3,4,5,6 event-on-change-reading event-on-update-reading event-aggregator event-min-interval stateFormat cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride userattr">
<INT key="CFGFN" value=""/>
<INT key="CHANGED" value=""/>
<INT key="DEF" value="LEQxxxxxxx:4"/>
<INT key="NAME" value="HM_BZ_Thermostat"/>
<INT key="NR" value="97153"/>
<INT key="STATE" value="23.0"/>
<INT key="TYPE" value="HMCCUCHN"/>
<INT key="ccuaddr" value="LEQxxxxxxx:4"/>
<INT key="ccudevstate" value="Active"/>
<INT key="ccuif" value="BidCos-RF"/>
<INT key="ccuname" value="BZ_Heizung"/>
<INT key="ccutype" value="HM-CC-RT-DN"/>
<INT key="channels" value="1"/>
<INT key="statevals" value="devstate"/>
<INT key="IODev" value="hmccu2"/>
<ATTR key="IODev" value="hmccu2"/>
<ATTR key="ccureadingfilter" value="(SET_TEMPERATURE|ACTUAL_TEMPERATURE|CONTROL_MODE|FAULT_REPORTING|BATTERY_STATE)"/>
<ATTR key="ccureadings" value="1"/>
<ATTR key="group" value="Heizung"/>
<ATTR key="room" value="Bad"/>
<ATTR key="statedatapoint" value="SET_TEMPERATURE"/>
<ATTR key="stripnumber" value="1"/>
<ATTR key="substitute" value="CONTROL_MODE!0:Auto,1:Manual,2:Party,3:Boost;;FAULT_REPORTING!0:Ok,4:CommError,6:LowBat,(1|2|3|5|7):GenError"/>
<STATE key="BZ_Heizung.ACTUAL_TEMPERATURE" value="26.7" measured="2016-02-07 18:55:47"/>
<STATE key="BZ_Heizung.BATTERY_STATE" value="2.7" measured="2016-02-07 18:55:47"/>
<STATE key="BZ_Heizung.CONTROL_MODE" value="Auto" measured="2016-02-07 18:55:47"/>
<STATE key="BZ_Heizung.FAULT_REPORTING" value="Ok" measured="2016-02-07 18:55:47"/>
<STATE key="BZ_Heizung.SET_TEMPERATURE" value="23.0" measured="2016-02-07 18:55:47"/>
<STATE key="state" value="23.0" measured="2016-02-07 18:55:47"/>
</HMCCUCHN>
</HMCCUCHN_LIST>
</FHZINFO>
Soweit ok. Ich kann die Temperatur setzen:
set HM_BZ_Thermostat devstate 22
Dann ist die Temperatur bei 22°. Prima. Jetzt würde ich aber auch gerne noch die Thermostate in "Manuell", "Automatik" oder "Boost" setzen. Das klappt zwar, aber ich erhalte in FHEM einen Fehler. Der Befehl ist (manuell/aus):
set HM_BZ_Thermostat datapoint MANU_MODE 4.5
Im Logfile steht dann:
HMCCU: Error URL = http://192.168.2.21:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:4.AUTO_MODE").Value()
HMCCUCHN: HM_BZ_Thermostat Execution of CCU script failed
Ich hab etwas im Homematic-Forum gesucht und der Befehl zum Setzen des "AUTO_MODE" müsste so aussehen:
http://192.168.2.21:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:4.AUTO_MODE").State(1);
Unterstützen die HMCCU-Module das Setzen des Modus eines Thermostat ? Wenn ja, was muss ich tun ?
Vielen Dank schonmal,
Gruß,
David
Könnte sein, dass das ein Fehler im Modul ist. Setze bitte mal testweise das Attribut ccuget auf State und versuch das nochmal.
Kann das leider erst morgen abend testen.
Das seh ich gerade erst, was spricht gegen
set HM_BZ_Thermostat datapoint AUTO_MODE 1
Hi Zap,
klasse - das funktioniert. Nach Setzen von ccuget=State klappt es:
Manueller Modus
set HM_BZ_Thermostat datapoint MANU_MODE 4.5
Automatik Modus
set HM_BZ_Thermostat datapoint AUTO_MODE 1
Wenn ich das jetzt für 7 Thermostate einstelle, wird dann die Kommunikation zwischen FHEM/CCU verlangsamt (wie es in der Doku beschrieben ist) ? Wird die direkte Kommunikation zum Thermostat nach setzen von ccuget=State auch für die Aktualisierung der Readings ausgeführt oder nur beim SET von Datenpunkten ?
Vielen Dank und Gruß,
David
Ich muss mir das morgen trotzdem nochmal anschauen. Das Setzen des Datenpunktes wird nämlich immer mit State() ausgeführt. Nach jedem Set wird aber nochmal per get der Wert abgefragt (ein Überbleibsel aus der Vor-RPC-Server Ära). Und hier kommt das Attribut ccuget zum Einsatz. Vermutlich hat das Setzen also vorher auch schon funktioniert, nur das Abfragen nicht. Wenn ich das richtig verstehe, erfolgt das Abfragen per Datenpunkt CONTROL_MODE erfolgt.
Habe zwar einige Thermostate, fahre meine aber immer im Auto Mode. Daher muss ich es mir erst mal anschauen ....
So, habe mit jetzt mal die Doku zu den Datenpunkten des Thermostaten angeschaut. Unter
http://www.eq-3.de/Downloads/PDFs/Dokumentation_und_Tutorials/HM_Script_Teil_4_Datenpunkte_1_503.pdf
steht folgende Tabelle:
Name Typ Zugriff
----------------------------------------------
CONTROL_MODE option lesend
FAULT_REPORTING option lesend
BATTERY_STATE float lesend
VALVE_STATE integer lesend
BOOST_STATE integer lesend
ACTUAL_TEMPERATURE float lesend
SET_TEMPERATURE float lesend/schreibend
AUTO_MODE action schreibend
MANU_MODE float schreibend
BOOST_MODE action schreibend
COMFORT_MODE action schreibend
LOWERING_MODE action schreibend
Bedeutet: Den aktuellen Modus liest Du über CONTROL_MODE aus. Gesetzt wird er aber über AUTO_MODE, MANU_MODE, BOOST_MODE, COMFORT_MODE und LOWERING_MODE. Damit ist auch klar, wie der Fehler im Log zustande kam. Der AUTO_MODE wurde zwar gesetzt, allerdings ist der folgende Lesebefehl für die Verifikation fehlgeschlagen, da AUTO_MODE nur schreibenden Zugriff erlaubt.
Ich werfe diese Leseverifikation in der nächsten Version raus oder mache sie zumindest optional per Attribut einstellbar. Wenn der RPC-Server aktiv ist, braucht man das nicht.
Alle weiteren Parameter (wie z.B. Zeiten, Wochenprogramm, usw.) können nur über "set config" eingestellt werden. Dabei gibt es aber gerade bei den Zeiteinstellungen vieles zu beachten, da man immer komplette Wochenprogramme übertragen muss.
Ich habe gerade die Version 2.7 eingecheckt. Achtung! Die Source-Forge Adresse hat sich geändert (als Vorbereitung für eine zukünftige Installation per "update"). Sie lautet jetzt
https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/HMCCU/FHEM/
Neue / geänderte Funktionen:
- Der Logging-Mechanismus wurde auf Log3/verbose umgestellt. Das Attribut loglevel funktioniert daher nicht mehr. Bitte verbose benutzen
- Wenn für ein Client-Device mindestens 2 Zustände über das Attribut statevals definiert sind (z.B. statevals = on:true,off:false) kann mit dem Befehl set devname toggle zwischen diesen Zuständen umgeschaltet werden. Es werden auch mehr als 2 Zustände unterstützt.
- Mit dem neuen Attribut ccuverify kann gesteuert werden, ob nach einem Set-Befehl für den gleichen Datenpunkt automatisch ein Get ausgeführt wird. Das ist nur sinnvoll, wenn der RPC-Server nicht genutzt wird, daher ist diese Funktion per Default ausgeschaltet (=0).
- Der RPC-Server kann nun mit dem Befehl set devname restartrpc neu gestartet werden.
- Der Zustand des RPC-Servers wird im Internal RPCState angezeigt. Folgende Zustände sind möglich: "stopped", "starting"; "running", "stopping", "restarting".
- Im RPCState "starting", "stopping" oder "restarting" akzeptieren die Client-Devices und das IO-Device keinerlei Befehle, da die CCU beim Starten und Stoppen des RPC-Servers ausgelastet ist. Ein get/set Befehl liefert dann die Meldung "CCU busy" zurück und STATE wird auf "busy" gesetzt.
- In einigen Fällen generiert HMCCU nun Events, auf die mit notify reagiert werden kann (s.u.)
Events:
"RPC server restarting" - Der RPC-Server wird gerade neu gestartet.
"RPC server starting" - Der RPC-Server wird gerade gestartet.
"RPC server running" - Der RPC-Server wurde gestartet. Darauf könnte man mit einem "get update" reagieren, um einmalig alle Gerätestati zu aktualisieren.
"RPC server stopped" - Der RPC-Server wurde gestoppt.
"No events from CCU since 300 seconds" - In den letzten 5 Minuten gab es keine Updates von den CCU. Darauf könnte man mit einem "set restartrpc" reagieren, da evtl. die CCU neu gestartet wurde und deshalb keine Events mehr geschickt werden.
"nn devices deleted in CCU" - In der CCU wurden nn Geräte gelöscht. Darauf könnte man mit einem "get devicelist" reagieren.
"nn devices added in CCU" - In der CCU wurden nn Geräte angelernt. Reaktion wie oben (get devicelist).
Vorgehensweise für das Update:
- FHEM stoppen: /etc/init.d/fhem stop
- Prüfen/warten, bis der RPC-Server gestoppt wurde: ps -ef | grep "ccurpcd"
- Neue Dateien ins FHEM Modulverzeichnis kopieren
- FHEM starten: /etc/init.d/fhem start
- Ca. 3 Minuten warten, bis im HMCCU IO-Device RPCState = "running" ist (sofern der RPC-Server genutzt wird)
Abkündigung:Das Attribut
ccustate wird in einer der nächsten Versionen wegfallen. Ebenso die dazu gehörende Funktion HMCCU_State(). Durch die Umbenennung der Readingnames in FHEM konforme Namen sind diese Funktionen nicht mehr notwendig. Falls jemand Einwände hat, bitte melden.
Neue Version der Module im Contrib Pfad eingecheckt. Eigentlich sollte ab dieser Version der FHEM Update-Mechanismus unterstützt werden. Leider habe ich übersehen, dass der beim contrib Verzeichnis nicht greift. Werde daher demnächst auf Github umziehen. Bis dahin bitte weiter den Download Link aus dem 1. Beitrag verwenden.
Zunächst ein wichtiger Hinweis: EQ3 hat eine neue CCU-Firmware mit Homematic IP Unterstützung veröffentlicht. Leider hatte ich noch keine Zeit, die zu testen. Aufgrund der Vielzahl von Änderungen (auch bei der RPC Schnittstelle) könnte es zu Problemen im Zusammenspiel mit HMCCU kommen. Im Zweifel also bitte mit dem CCU Update noch ein paar Tage warten.
Wenn möglich wird die nächste Version von HMCCU Homematic IP unterstützen!Nun zu den Neuerungen:
- HMCCU gibt es einen neuen Befehl get updateccu. Dieser Befehl arbeitet wie get update, d.h. es werden alle Datenpunkte/Readings aller FHEM-Devices aktualisiert. Einziger Unterschied: Der optionale Device-Filter bei get update bezieht sich auf FHEM Devicenames während der Filter bei get updateccu sich auf CCU Devicenames bezieht
- Das Attribut ccustate wurde gestrichen
- Die Unterstützung von CCU Gerätegruppen in HMCCUDEV wurde verbessert (s. Bsp. unten). Wenn ein Datenpunkt eines Mitglieds einer Gerätegruppe aktualisiert wird, werden auch die entsprechenden Readings im HMCCUDEV Gruppen-Device aktualisiert.
- HMCCUDEV unterstützt nun virtuelle Devices (das sind Gerätegruppen ohne Gegenstück in der CCU (s. Bsp. unten)
- Das Attribut ccureadingfilter unterstützt nun mehrere Filterregeln durch , getrennt. Die Regeln können auf bestimmte CCU Gerätekanäle eingeschränkt werden (s. Bsp. untern)
- Neues Attribut mapdatapoints für HMCCUDEV Gruppen-Devices. Da der RPC-Server Gruppen-Devices nicht automatisch aktualisiert, kann mit einem Mapping der Datenpunkte der echten Devices auf die Gruppen-Device Datenpunkte eine Aktualisierung ermöglicht werden. Syntax für das Mapping: Channel-Name.Datapoint=Group-Channel-Name.Datapoint[,...] (s. Bsp. unten)
Beispiel für ein CCU Gruppendevice bestehend aus einem Wand- und einem Heizkörperthermostaten:
# G-AZ-HZ=Gruppenname in CCU.
# KL-AZ-HZ=CCU-Name Heizkörperthermostat
# KL-AZ-TH=CCU-Name Wandthermostat.
# Explizite Angabe der echten CCU Geräte mit group= notwendig! Alternativ kann mit groupexp= ein
# regulärere Ausdruck für die CCU Gerätenamen angegeben werden
define HM_G_AZ_HZ HMCCUDEV G-AZ-HZ group=KL-AZ-HZ,KL-AZ-TH
# Nur einige Datenpunkte als Readings speichern. ccureadingfilter erlaubt jetzt die Angabe von CCU Channel names
attr HM_G_AZ_HZ ccureadingfilter G-AZ-HZ:1!(CONTROL_MODE|SET_TEMPERATURE),^KL-AZ!(^SET_TEMPERATURE|^TEMPERATURE|^HUMIDITY|LOWBAT$|^VALVE|^CONTROL)
# Nach Setzen der Zieltemperatur Wert per Abfrage verifizieren
attr HM_G_AZ_HZ ccuverify 1
# Steuerung der Zieltemperatur per Slider Widget ermöglichen
attr HM_G_AZ_HZ controldatapoint 1.SET_TEMPERATURE
attr HM_G_AZ_HZ webCmd control
attr HM_G_AZ_HZ widgetOverride control:slider,10,1,25
# Datenpunkte der echten Geräte auf die Datenpunkte der Gruppe mappen
attr HM_G_AZ_HZ mapdatapoints KL-AZ-TH:2.SET_TEMPERATURE=G-AZ-HZ:1.SET_TEMPERATURE,KL-AZ-TH:2.CONTROL_MODE=G-AZ-HZ:1.CONTROL_MODE
# Für den Befehl get devstate
attr HM_G_AZ_HZ statechannel 1
attr HM_G_AZ_HZ statedatapoint SET_TEMPERATURE
# Bei Zahlen 1 Stelle hinter dem Komma als Reading speichern
attr HM_G_AZ_HZ stripnumber 1
# Werte aus CCU in Readings ersetzen
attr HM_G_AZ_HZ substitute LOWBAT!(0|false):no,(1|true):yes;;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST
# Userreadings
# Funktion HMCCU_Dewpoint() berechnet den Taupunkt aus Temperatur und Luftfeuchte
# Funktion HMCCU_AggReadings() aggregiert die Werte identischer Datenpunkte. Hier werden alle LOWBAT Datenpunkte
# der echten Geräte UND verknüpft. Wenn alle "no" sind, ist das Ergebnis auch "no". Wenn mindestens einer "yes" ist,
# ist das Ergebnis "yes".
attr HM_G_AZ_HZ userReadings DEWPOINT {HMCCU_Dewpoint($name,"KL-AZ-TH.1.TEMPERATURE", "KL-AZ-TH.1.HUMIDITY","n/a")}, LOWBAT_STATE:(KL-AZ-TH.0.LOWBAT|KL-AZ-HZ.0.LOWBAT) {HMCCU_AggReadings($name, "KL.*LOWBAT","and","no","yes")}, LOWBAT_COUNT:(KL-AZ-TH.0.LOWBAT|KL-AZ-HZ.0.LOWBAT) {HMCCU_AggReadings($name, "KL.*LOWBAT","cnt","yes","")}
Virtuelle Devices ohne Gegenstück in der CCU (ohne CCU Gerätegruppe) definieren:
define myvirtdev HMCCUDEV virtual group=Dev[,...]
define myvirtdev HMCCUDEV virtual groupex=DevExp
Virtuelle Devices sind immer read only.
BTW: So ein Gruppen-Device "schmiegt" sich sehr harmonisch in ein FHEM Tablet UI Thermostat Widget ein (das war der Hauptgrund, dass ich das implementiert habe):
<div data-type="thermostat" data-device="HM_G_AZ_HZ"
data-get="G-AZ-HZ.1.SET_TEMPERATURE"
data-set="datapoint 1.SET_TEMPERATURE"
data-valve="KL-AZ-HZ.4.VALVE_STATE"
data-unit="%B0"
class="large">
</div>
Hi Zap,
vielen Dank für die neuen Funktionen im Modul. Hab auch virtuelle Gruppen in Benutzung und fange gerade mit TabletUI an. Probiere die neuen Funktionen am Wochenende mal aus.
Viele Grüße,
David
So, nach einem schweißtreibenden Update meiner CCU auf 2.17.14 (Homematic IP Unterstützung) hier einige Infos zum Thema bzw. HM-IP:
- HMCCU läuft mit der CCU2 Firmware 2.17.14
- HM-IP Devices werden von HMCCU (noch) nicht unterstützt. Die Gründe sind vielfältig. Hauptgrund ist aber, dass sich das Format der Geräteadressen / Seriennummern für HM-IP Geräte geändert hat. Das muss ich HMCCU erst beibringen => Viel Arbeit.
Die 2.17.14 Firmware ist m.E. übles Gefrickel. Ich habe das Update nach der empfohlenen Methode durchgeführt, d.h. Backup, dann Factory Reset, dann 2.17.14 einspielen, dann Restore. Läuft alles, Performance ist ok. Allerdings werden immer wieder Fehler ins Log geschrieben. Ich habe eine simple IP Steckdose angelernt (HMIP-PS). Sollte von 2.17.14 unterstützt werden. Bedienung ist zwar möglich, allerdings wird im WebUI die Steckdose als "unbekanntes Gerät vom Typ DEVICE" dargestellt.
Ich denke, wer nicht unbedingt HM-IP benötigt, sollte mit dem Update noch warten. Ich werde es drauf lassen. Brauche schließlich was zum Entwickeln.
P.S. Habe durch die HM-IP Testerei endlich den Grund gefunden, warum der RPC Server nach dem Starten 3 Minuten Bedenkzeit benötigt, bis er seine Arbeit aufnimmt. Was soll ich sagen: der Grund war eher vor dem Bildschirm zu suchen. Zu meiner Verteidigung kann ich nur vorbringen, dass die Doku an dieser Stelle unscharf (oder beschissen) ist. Wie auch immer: Vor dem HM-IP Release wird es noch ein Update für den RPC-Server geben, damit wenigstens das mal richtig funktioniert.
Hast Du nun 2.17.4 oder 2.17.14 drauf? Das ist ein himmelweiter Unterschied!
RPC-Server: system.multicall? Oder was war das Problem?
Zitat von: Ralli am 11 März 2016, 17:59:43
Hast Du nun 2.17.4 oder 2.17.14 drauf? Das ist ein himmelweiter Unterschied!
RPC-Server: system.multicall? Oder was war das Problem?
2.17.14, habe gerade meinen vorherigen Beitrag korrigiert.
Nein, Multicall war nicht das Problem. Das wird von RPC::XML::Server unterstützt. Das Problem ist das Handshaking, also der Verbindungsaufbau mit der CCU. Ich hatte das Init als Request losgeschickt. Und dann hat es 3 Minuten gedauert, bis dieser Request zurückkam. Danach habe ich den Server-Loop gestartet, um CCU Events entgegen zu nehmen.
Der Denkfehler: Der Init-Request ist deshalb nicht gleich zurückgekehrt, weil die CCU während der Initialisierung eine Anfrage an dem RPC-Server schickt. Zu dem Zeitpunkt lief aber auf HMCCU Seite noch nix. Daher hat die CCU 3 Minuten auf eine Antwort gewartet. Dann hat ein Timeout zugeschlagen und der Init-Call kam zurück.
Jetzt mache ich es anders. Der RPC Server wird gestartet. Dann wird erst der Init-Request an die CCU geschickt. Jetzt klappt Init und auch Stop ohne Verzögerung.
Ich habe Probleme mit dem RPC-Server.
Wenn ich ihn über attr d_ccu rpcserver on starte,
wird die Verbindung zur CCU korrekt initialisert.
Aber nach exakt einer Minute erscheint im FHEM-Log, das der Server wieder gestoppt wurde.
z.B.
2016.03.12 21:06:59 0: HMCCU: RPC server started with pid 29873
2016.03.12 21:07:59 0: HMCCU: All RPC servers stopped
In Wirklichkeit läuft der RPC-Server aber weiter, und empfängt auch weiter Daten von der CCU,
die nach ccuqueue_2001.dat geschrieben werden.
Nur FHEM bekommt da nichts von mit, weil es davon ausgeht, das der RPC-Server nicht läuft.
Irgendeine Idee, an welcher Stelle ich den Fehler suchen muss?
Danke und Gruß
Jürgen
Ok, habe das Problem gefunden.
Es ist die Funktion HMCCU_CheckProcess in 88_HMCCU.pm
Dort wird mit "ps -ef" die Prozessliste ermittelt.
Ich habe aber FHEM in einer Jail unter freeBSD laufen,
dort liefert ps -ef was anderes als unter Linux.
Deswegen findet FHEM die ProzessID nicht.
Nach anpassen der Funktion läuft es.
Viele Grüße
Jürgen
Hallo,
bitte poste hier mal Deine Änderungen. Ich wollte heute sowieso eine neue Version einchecken, die das Starten des RPC-Servers optimiert (3 Minuten Pause entfällt). Da kann ich das einbauen.
Bin auch nicht sehr glücklich mit der ps -ef Lösung. Momentan wird nur Debian und MacOS berücksichtigt.
Ich prüfe derzeit die Umstellung auf Proc::Processtable. Hat eben den Nachteil, dass ein weiteres Perl Modul installiert werden muss. Dafür ist das dann Plattform unabhängig.
Hier die Änderungen.
sub HMCCU_CheckProcess ($$)
{
my ($hash, $port) = @_;
my $name = $hash->{NAME};
my $modpath = AttrVal ('global', 'modpath', '/usr/local/fhem');
my $rpcserver = $modpath."/FHEM/ccurpcd.pl";
### ps -a
my $pdump = `ps -a | grep $rpcserver | grep -v grep`;
my @plist = split "\n", $pdump;
foreach my $proc (@plist) {
# Remove leading blanks, fix for MacOS. Thanks to mcdeck
$proc =~ s/^\s+//;
my @procattr = split /\s+/, $proc;
### Indizes anpassen
return $procattr[0] if ($procattr[0] != $$ && $procattr[4] =~ /perl$/ &&
$procattr[5] eq $rpcserver && $procattr[7] eq "$port");
}
return 0;
}
Ich muss aber dazu sagen, ich bin kein freeBSD-Experte.
Auf der Maschine bin ich auch nur Gast mit meiner jail :)
Eine neue Version von HMCCU steht ab sofort im contrib Verzeichnis (Link siehe erster Beitrag).
Fehlerbehebung:
- Der RPC-Server wird nun praktisch ohne Verzögerung gestartet und gestoppt. Insbesondere die 3 Minuten Wartezeit nach dem Start wurde auf 10 Sekunden reduziert. Wenn das stabil ist, werden auch die 10 Sekunden entfallen.
- Die Methode zum Prüfen laufender RPC-Server wurde geändert. Es wird nun die BSD kompatible Syntax 'ps ax' verwendet. Das sollte mit FreeBSD, Debian und MacOS funktionieren.
Die neue Version ist kompatibel mit der aktuellen CCU2 Firmware 2.17.14. Homematic-IP wird allerdings noch nicht unterstützt. Hier bitte ich noch um ein paar Tage Geduld. Ich kann aber jetzt schon sagen, dass HMCCU Homematic-IP unterstützen und damit diesen Gerätezweig für FHEM erschließen wird.
Ja, was soll ich sagen. Funktioniert :)
An der Stelle auch nochmal ein dickes Danke für das Modul.
Viele Grüße
Jürgen
Ich habe gerade die Version 3.0 eingecheckt. Diese Version unterstützt nun
Homematic IP.
Voraussetzung (nur bei Verwendung von Homematic IP):
CCU2 Firmware 2.17.15Die Get/Set Befehle unterstützen HM-IP Geräte. Damit auch Updates/Events von HM-IP Geräten automatisch an FHEM geschickt werden, muss ein zweiter RPC-Server konfiguriert werden. Dies erfolgt mit dem Befehl attr rpcport. Mit diesem Attribut wird eine Liste der Interfaces festgelegt, die HMCCU unterstützen soll:
- 2000: BidCos-Wired
- 2001: BidCos-RF
- 2010: HMIP-RF
Beispiel: RPC-Server für BidCos-RF und HMIP-RF konfigurieren:
attr my_ccu rpcport 2001,2010
Nach der Konfiguration die RPC-Server mit
attr rpcserver on starten. HMCCU startet für jeden rpcport automatisch einen Prozess.
Weitere Neuerungen in dieser Version:
- Für Client-Devices vom Typ HMCCUDEV steht der Set-Befehl on-timer zur Verfügung, sofern das Device einen Datenpunkt ON_TIME besitzt, mit dem Attribut statevals Werte für 'on' und 'off' festgelegt sind und ein statechannel definiert ist.
- Mit dem Befehl get dump devtypes im Modul HMCCU kann man sich eine Liste der CCU Gerätetypen anzeigen lassen.
- Mit dem Befehl get dump datapoints im Modul HMCCU kann man sich eine Liste aller CCU Gerätetypen mit allen Datenpunkten anzeigen lassen. Für jeden Datenpunkt wird der Datentyp sowie die zulässigen Operationen (Read, Write, Event) angezeigt.
- Der Befehl get deviceinfo in den Modulen HMCCUDEV und HMCCU zeigt nun ebenfalls die Datentypen, Operationen sowie den aktuellen Wert der Datenpunkte eines Devices an.
- Bei den Befehlen get datapoint und set datapoint wird nun geprüft, ob der angegebene Datenpunkt existiert und die Operation (Setzen/Lesen) zulässig ist. Im Webinterface wird bei get datapoint eine Auswahlliste der gültigen Datenpunkte angezeigt. Die Datenpunküberprüfung kann mit attr ccuflags dptnocheck im Modul HMCCU global ausgeschaltet werden
- Mit dem Attribut ccuflags im Modul HMCCU können verschiedene Flags (durch Komma getrennt) gesetzt werden. Das Flag 'singlerpc' sorgt dafür, dass auch bei mehreren RPC-Ports nur ein RPC-Server Prozess gestartet wird. Das ist mit Vorsicht zu genießen, da je nach Auslastung von FHEM und Anzahl der CCU Events Nachrichten verloren gehen können.
Für die Installation der CCU Firmware 2.17.15 geht man am besten wie folgt vor:
- Backup erstellen
- CCU in Recovery Modus booten
- CCU auf Werkseinstellungen zurücksetzen
- Firmware 2.17.15 installieren
- Ggf. Zusatzsoftware installieren (z.B. CUxD)
- Backup einspielen
Wenn CUxD installiert werden soll, muss es unbedingt die Version 1.5.1 sein!
Hallo zap,
bekommst Du über die XML-RPC-Schnittstelle der CCU eine HMIP-Steckdose geschaltet?
Ich kann mit dem HMRPC-Modul machen was ich will, ich bekomme immer ein -5 (Invalid parameter or value). Der Aufruf ist korrekt, im Log der CCU steht nix besonderes, eine Dubug von einem CCU-internen Schaltvorgang bestätigt mir, dass die Syntax richtig ist.
In HMCCU wird XML-RPC nur für das Setzen/Lesen von Geräteparametern verwendet. Alles andere läuft über Homematic Script. Damit funktioniert das Ein-/Ausschalten von HM-IP Steckdosen einwandfrei. Der RPC-Server liefert dann den neuen Status zurück.
Ich teste mal heute abend, ob ich per RPC Parameter der Steckdose lesen bzw. verändern kann. Getestet habe ich das bei HM-IP noch nicht (shame on me).
Würde mich aber nicht wundern, wenn EQ-3 hier noch ein gewisses Defizit hätte ;-)
Zitat von: Ralli am 22 März 2016, 11:31:54
Hallo zap,
bekommst Du über die XML-RPC-Schnittstelle der CCU eine HMIP-Steckdose geschaltet?
Ich kann mit dem HMRPC-Modul machen was ich will, ich bekomme immer ein -5 (Invalid parameter or value). Der Aufruf ist korrekt, im Log der CCU steht nix besonderes, eine Dubug von einem CCU-internen Schaltvorgang bestätigt mir, dass die Syntax richtig ist.
So, gerade getestet. Das Setzen eines MASTER Parameters der Steckdose Typ HMIP-PS (z.B. LONG_PRESS_TIME=0.5) funktioniert bei mir ohne Code Änderung. Ich gehe davon aus, dass dann auch das Setzen eines VALUES funktioniert. Aber wie gesagt, das kann ich nicht testen, da ich dafür Homematic Script verwende.
Problem gefunden und gelöst.
Der XML-RPC-Server für HMIP ist etwas zickiger weniger tolerant als für Standard-Homematic.
Will sagen: nach wie vor kann auf der Standard-Homematic-Schnittstelle ein setValue oder ein putParamset für eine Variable, deren Typ Boolean ist, der XML-Request ohne große Verrenkungen gesendet werden. Im Standard-XML-Request ist zwar der Variablen-Typ mit String angegeben, das interessiert die Schnittstelle aber nicht. Auf der HMIP-Schnittstelle sieht das hingegen anders aus. Hier möchte die Schnittstelle im XML-Request tatsächlich auch den Variablen-Typ Boolean definiert haben. Das gleiche gilt auch für die Float und die Integer.
Siehe auch https://forum.fhem.de/index.php/topic,41060.msg429362.html#msg429362 .
Hallo Zusammen,
ich habe gerade mal wieder mein FHEM sowie die HMCCU files geupdated und nun sehe ich dass die get- und set-Befehle aus dem CCU-device HMCCU entfernt wurden.
Auch der RPCState bleibt im Status "starting".
Hat jemand eine Idee?
Die CCU2 hat noch die Firmware 2.15.5.
Vielen Dank
Thomas
Okay, wenn ich die Portangabe weglase und die Definition nur so lautet, kann ich wieder get und set ausführen.
define CCU2 HMCCU 192.168.178.42
attr CCU2 rpcserver on
Allerdings bekommt der RPC Server immer nach starting den Status stopped.
Ein anschließendes get CCU2 devicelist dump liefert aber dennoch ca. 190 Ergebnisse.
VG, Thomas.
Solange der RPC Server startet, stoppt oder neu startet, werden die Set und Get Befehle deaktiviert. Da. Wenn in diesem Zustand trotzdem per Eingabefeld ein Befehl abgsetzt wird, wird er ignoriert und STATE des IO Devices geht auf "busy". Das habe ich eingebaut, da CCU Zugriffe während der o.g. Phasen sehr unzuverlässig sind. Allerdings sollte in der aktuellen Version das Starten nur noch 10 Sekunden dauern.
Bitte schau Dir mal das FHEM Logfile sowie das Logfile des RPC Servers an (ccurpc*log) und poste evtl. Fehlermeldungen. Der RPC Server wird offensichtlich nicht richtig gestartet.
Hi Zap,
anbei das FHEM-Log:
2016.03.23 21:06:25 0: HMCCU: RPC server started with pid 1577
2016.03.23 21:06:25 1: HMCCU: Registering callback http://192.168.178.58:7401/fh2001 with ID CB2001
2016.03.23 21:06:25 1: HMCCU: RPC callback with URL http://192.168.178.58:7401/fh2001 initialized
...
2016.03.23 21:06:35 2: HMCCU: Can't open file queue /tmp/ccuqueue_2001
2016.03.23 21:06:35 0: HMCCU: All RPC servers stopped
2016.03.23 21:06:59 0: Server shutdown
2016.03.23 21:06:59 1: HMCCU: Deregistering RPC server http://192.168.178.58:7401/fh2001
2016.03.23 21:06:59 0: HMCCU: RPC server not running
Es gibt aber 2 Dateien /tmp - Verzeichnis - beide Dateien auch mit aktuellem Änderungs-Timestamp.
ccuqueue_2001.dat
ccuqueue_2001.idx
Logfile des RPC-Servers:
23.03.2016 14:18:27 Creating file queue
23.03.2016 15:05:43 Creating file queue
23.03.2016 15:11:10 Creating file queue
23.03.2016 15:21:16 Creating file queue
23.03.2016 15:26:39 Creating file queue
23.03.2016 15:33:51 Creating file queue
23.03.2016 15:55:14 Creating file queue
23.03.2016 20:04:40 Creating file queue
23.03.2016 20:18:39 Creating file queue
23.03.2016 20:20:07 Creating file queue
23.03.2016 21:06:25 Creating file queue
Ich hoffe, du kannst damit mehr anfangen als ich...? ;)
LG, Thomas
ich kann dir bestimmt helfen, da ich das gleiche Problem hatte. Schau mal bitte nach welche Rechte die Dateien ccuqueue_2001.dat ccuqueue_2001.idx haben
--w---x--T 1 fhem dialout 0 Mär 22 13:06 /tmp/ccuqueue_2001.dat
--w---x--T 1 fhem dialout 1 Mär 22 13:06 /tmp/ccuqueue_2001.idx
so sahen meine aus
richtig
-rw-r--r-- 1 fhem dialout 0 Mar 22 17:09 /tmp/ccuqueue_2001.dat
-rw-r--r-- 1 fhem dialout 1 Mar 22 17:09 /tmp/ccuqueue_2001.idx
Lösung
chmod 744 /tmp/ccu*
update :
da diese Dateien bei dir auch warscheinlich im tmp ordner liegen und bei einen Geräteneustart gelöscht werden empfiehlt es sich den chmod Befehl in rc.local zu schreiben
Hallo,
ich habe eine CCU2 mit verschiedenen Aktoren und Sensoren im Einsatz.
Jetzt versuche ich gerade, einen Heizkörperthermostat in Fhem mit HMCCU (auf einem Raspberry Pi) einzurichten:
define CCU2 HMCCU homematic.fritz.box
attr CCU2 ccureadings 1
attr CCU2 group Zentrale
attr CCU2 room HomeMatic
attr CCU2 rpcqueue /opt/fhem/tmp/ccuqueue
attr CCU2 rpcserver on
define HKT_Arbeitszimmer HMCCUDEV HM-CC-RT-DN_xxxxxxxxxx 4
attr HKT_Arbeitszimmer IODev CCU2
attr HKT_Arbeitszimmer controldatapoint HM-CC-RT-DN_xxxxxxxxxx.SET_TEMPERATURE
attr HKT_Arbeitszimmer group Arbeitszimmer
attr HKT_Arbeitszimmer room HomeMatic
attr HKT_Arbeitszimmer statechannel 4
attr HKT_Arbeitszimmer statedatapoint ACTUAL_TEMPERATURE
attr HKT_Arbeitszimmer webCmd control
attr HKT_Arbeitszimmer widgetOverride control:slider,10,1,25
Ich wollte damit gerne den aktuellen Temperaturwert angezeigt bekommen und gleichzeitig den Sollwert für die Temperatur einstellen können. (Den Code habe ich in der HMCCU_README.txt grfunden.)
Die Installation hat soweit funktioniert, die Readings werden angezeigt. Aber die Tempetratur läßt sich nicht ändern.
Die Anzeige sieht so aus:
Arbeitszimmer
HKT_Arbeitszimmer 19.600000 control
Zentrale
CCU2 OK
Wenn ich nun control drücke, erscheint folgende Meldung:
HMCCUDEV: CCU busy
Hat vielleicht einer eine Idee, was ich falsch mache?
Viele Grüße
Christian
@cho: Versuch mal das (ich glaube, bei einem Heizkörperthermostat ist der Datenpunkt SET_TEMPERATURE in Kanal 4, ansonsten korrigieren):
attr HKT_Arbeitszimmer controldatapoint 4.SET_TEMPERATURE
Das Attribut controldatapoint erwartet folgende Syntax: Kanalnummer.Datenpunkt (also nicht Kanal.Datenpunkt, Kanal würde ja auf Kanaladresse:Kanalnummer verweisen).
@ALL (insbesondere cho, mAr86sEb05, ToM_ToM):Mit der Version 3.0 habe ich die Filequeue Funktionen in HMCCU integriert, um die Abhängigkeit von RPCQueue los zu werden. Dabei scheint mir ein Fehler unterlaufen zu sein, der sich nur bemerkbar macht, wenn die Queue-Dateien in /tmp neu angelegt werden. Ich muss das allerdings heute Abend nochmal bei mit nachvollziehen. Ob Ihr betroffen seid, könnt Ihr wie von mAr86sEb05 oben beschrieben prüfen.
Hintergrund: Wenn die Queue-Dateien in /tmp bei Euch nicht "rw" für den User fhem gesetzt haben, wird der RPC-Server nicht korrekt gestartet bzw. HMCCU bekommt nicht mit, dass er gestartet wurde, da es keinen Zugriff auf die Queue hat. In diesem Fall wartet HMCCU endlos auf einen Event "IN|INIT". Da beim Starten des RPC-Servers alle Set/Get Befehle deaktiviert werden, kommt es zu der Meldung "CCU busy".
Sorry dafür. Ich hoffe, ich kann heute Abend einen Fix bereit stellen.
Temporärer Workaround:
- Prüfen, ob der RPC-Server läuft (ps ax | grep ccurpc). Ggf. mit attr rpcserver off beenden oder mit kill -SIGINT <PID> nachhelfen.
- Wie von mAr86sEb05 beschrieben die Rechte der Queue-Files anpassen (geht bei Reboot wieder verloren)
Hallo zap,
vielen Dank für die schnelle Antwort!
Für das Problem mit der ccuqueue Datei hatte ich schon folgenden Workaround gefunden:
- neues Verzeichnis /opt/fhem/tmp anlegen und hier .dat/.idx manuell mit rw Rechten versehen
- in Fhem mit "attr CCU2 rpcqueue /opt/fhem/tmp/ccuqueue" bekannt geben
- damit gibt es dann auch keine Probleme beim Reboot
ps ax | grep ccurpc findet entsprechend:
4251 ? S 1:34 /usr/bin/perl ./FHEM/ccurpcd.pl homematic.fritz.box 2001 /opt/fhem/tmp/ccuqueue_2001 ./log/ccurpcd_2001.log
Das ccurpcd_2001.log sieht so aus:
24.03.2016 09:31:17 RPC server terminated
24.03.2016 09:31:49 Creating file queue
24.03.2016 09:31:49 Initializing RPC server
24.03.2016 09:31:49 Callback server created listening on port 7401
24.03.2016 09:31:49 Adding callback for events
24.03.2016 09:31:49 Adding callback for new devices
24.03.2016 09:31:49 Adding callback for deleted devices
24.03.2016 09:31:49 Adding callback for modified devices
24.03.2016 09:31:49 Adding callback for replaced devices
24.03.2016 09:31:49 Adding callback for readded devices
24.03.2016 09:31:49 Entering server loop. Use kill -SIGINT 712 to terminate program
Das fhem-2016-03.log ist sauber ohne Fehlermeldung.
Den controldatapoint habe ich wie angegeben geändert.
Aber ich bekomme nach wie vor die Meldung CCU busy.
Ich warte jetzt erst einmal auf Deinen Fix.
Viele Grüße
Christian
ich habe die Dateien in einer Ramdisk tmpfs da ich eine SSD als Festplatte habe und bei jedem Statuswechsel werden die Dateien neu geschrieben bzw gelesen und aus der Ramdisk fliegen sie nach jeden Neustart des Servers raus
Zitat von: cho am 24 März 2016, 09:37:22
Das fhem-2016-03.log ist sauber ohne Fehlermeldung.
Den controldatapoint habe ich wie angegeben geändert.
Aber ich bekomme nach wie vor die Meldung CCU busy.
Ich warte jetzt erst einmal auf Deinen Fix.
Viele Grüße
Christian
Bitte schau nochmal, ob im fhem log beim Starten des RPC-Servers irgendwelche Meldungen von HMCCU auftauchen. Insbesondere ""HMCCU: Received IN event. RPC server initialized."
Kannst Du nur den Control Befehl nicht ausführen? Was wird im HMCCU Device im Internal RPCState angezeigt ("starting", "running", ...) ?
Hallo mAr86sEb05, hallo zap,
vielen Dank für eure Antworten.
Ich habe das jetzt mal so gemacht wie aufgeführt.
Der eintrag in der rc.local greift nach dem Neustart nicht da der Inahlt des tmp - Verzeichnis ja beim Neustart gelöscht wird.
Nach dem Starten des RPC Servers werden die Dateien mit falschen CHMOD angelegt. Ich korrigiere die dann sofort und der RPC-Server bleibt nun nicht mehr im Status "Starting" hängen sondern geht nach einigen Sekunden in den Status "Stopped".
@zap: Du schreibst hier was von FHEM-User... Bei mir läuft alles als root, um diverse Probleme zu umgehen. Ich hoffe, das stellt hier kein Problem da...?
VG, Thomas
aber der fhem service (etc/init.d/fhem) sollte da schon ausgeführt worden sein, zumindest ist das bei mir so
Okay, also bei mir läuft der RPC-Server nun endlich nachdem ich den Owner der 2 Dateien im /tmp-Verzeichnis von fhem auf root geändert habe.
Hallo zap,
die Frage nach dem RPCState hat mich auf die richtige Spur gebracht:
Nach dem OS Reboot bleibt er im Status Starting hängen. In den Logfiles finden sich aber keine Einträge dazu.
Mit rpcserver=off und rpcserver=on kann ich ihn dann manuell starten. Und damit funktioniert auch das Einstellen der Temperatur wie gewünscht.
Nur nach dem nächsten OS Reboot startet er (auch nach längerer Zeit) nicht automatisch.
Die Frage wäre jetzt also, was muss ich für das automatische Starten beim Reboot konfigurieren?
Viele Grüße
Christian
Ich wollte jetzt mein Thermostat anbinden. Die Readings zeigen mir auch sämtliche Werte korrekt an.
Aber wenn ich
get HM_KU_Thermostat deviceinfo
ausführe, bekomme ich die Fehlermeldung:
HMCCUDEV: HM_KU_Thermostat Execution of CCU script or command failed
Woran kann das liegen? Wird das vielleicht auch mit Version 3 behoben sein? :)
VG, Thomas
Zunächst die gute Nachricht für Euch (weniger gut für mich, weil es Arbeit bedeutet ;-). Ich kann das Rechteproblem bei den Queue-Files bei mir nachvollziehen. Habe es nicht bemerkt, da mein Raspi seit ca. 6 Monaten nicht mehr neu gestartet wurde und daher auch die Dateien nicht neu angelegt wurden. Lösung ist in Arbeit.
Ich behebe jetzt erst mal das Problem. Dann schauen wir mal, ob die anderen Effekte immer noch auftreten.
@ToM_ToM: schick mir bitte mal die Ausgabe von "list HM_KU_Thermostat" und das gleiche nochmal für "list <hmccu_device>". Gerne auch per Forum Mail.
Hey zap, habe dir eine Forum-Mail gesendet.
list HM_KU_Thermostat" und "list <hmccu_device>...?
Also das Zweite ist doch im Prinzip nur die Syntax des Ersten.
Oder wolltest du es für die CCU?
Falls ja, habe ich es vorsichtshalber mitgesendet. ;)
VG, Thomas
Danke, passt so. Problem gefunden. Du hast Post.
Umlaute in CCU Gerätenamen sind keine gute Idee ;-)
Anderer Fehler ist auch gefunden. Update checke ich demnächst ein.
Ich habe gerade einen Bugfix für 88_HMCCU.pm eingecheckt. Der Fix behebt einen Fehler, der das Starten des RPC-Servers verhindert hat. Die Berechtigungen für die Queue-Files wurden falsch gesetzt.
Es genügt, die Datei 88_HMCCU.pm zu installieren.
Danach am besten FHEM anhalten, die alten Queue-Files löschen (normalerweise /tmp/ccuqueue*) und dann FHEM wieder starten. Vorher mit "ps ax | grep ccurpc" noch prüfen, dass kein alter RPC server mehr läuft.
Sorry nochmal für die Probleme. Was für ein blöder Fehler :'(
@cho: Bitte mal testen, ob Deine RPC Startprobleme damit behoben sind.
Hallo zap,
Danke für den Fix. Das Problem mit der ccuqueue ist jetzt bei mir behoben.
Aber der automatische Start des RPC Servers funktioniert noch nicht.
Mir ist aber noch etwas dazu eingefallen: Ich habe einen Raspberry Pi 3 laufen.
Beim Installieren von Fhem musste ich in der /etc/init.d/fhem vor dem Starten von Fhem ein sleep 10 einfügen. Ansonsten lief Fhem in alle möglichen Fehler.
Kann es sein, dass der Pi 3 "zu schnell" ist, und deshalb der Autostart des RPC Servers nicht funktioniert?
Das spätere manuelle Starten macht ja keine Probleme.
Kann ich zum Testen irgendwo irgendwie in Deinem Modul eine zusätzliche Verzögerung einfügen?
Viele Grüße
Christian
Sieh Dir mal die /etc/init.d/fhem an. Dort solltest Du in der Zeile
# Required-Start: $local_fs $remote_fs
noch ein $network anfügen, so dass im Endeffekt
# Required-Start: $local_fs $remote_fs $network
da steht.
Der Tipp mit dem $network hat funktioniert.
Danke dafür! Ich habe mein sleep 10 jetzt wieder gelöscht.
Aber das Problem mit dem RPC Server löst es nicht.
Im fhem log steht immer noch nicht "HMCCU: Received IN event. RPC server initialized."
Und im RPCState steht "starting".
Grüße
Christian
Hallo zap,
ich habe gerade das Update auf deine neue Datei gemacht.
Allerdings legt der die Dateien bei mir wieder mit CHMOD rw-r--r-- an und Owner ist wieder fhem.
Somit bleibt das der Prozess-State bei "Starting" hängen.
Ist es nicht möglich, die Dateien mit vollen Schreibrechten zu erstellen? Oder siehst du da ein Sicherheitsproblem?
VG, Thomas
@cho: Zu schnell kannst Du ausschließen. Läuft bei mir auch auf nem Core i7 iMac. Der ist schneller ;-) Tritt das problem nur auf, wenn Du den Raspi neu startest oder auch bei einem Start von FHEM aus bereits laufendem Linux heraus?
Ich denke, wir müssen das in Deinem Fall systematisch angehen:
Setze zunächst mal in HMCCU das Attribut rpcserver auf off und speichere die fhem Konfiguration hab.
Dann stoppe FHEM.
Dann prüfen, ob noch ein RPC Server läuft: ps ax | grep ccurpcd
Falls noch ein Prozess läuft manuell stoppen: kill -SIGINT processid
Nun FHEM starten
Prüfen, was im HMCCU Device im Internal DevCount angezeigt wird. Muss grösser 0 sein
Prüfen, dass das Internal RPC State "stopped" anzeigt und RPCPID 0
Das Attribut verbose auf 2 setzen
Mit Attribut rpcserver on den RPC Server starten
Nach 10-11 Sekunden die Ansicht aktualisieren. Die Set und Get Befehle sollten wieder angezeigt werden und in RPCPID die ProzessID stehen. rPCstate muss "running" zeigen
Fallls das nichts bringt, schicke mit die Ausgabe von "list <hmccudev>" sowie die Ausgabe von folgendem Unix Befehl:
grep "HMCCU" <fhemlogfile> | tail -100
Sowie das ccurpcd_*log File.
Zitat von: ToM_ToM am 24 März 2016, 20:41:47
Ist es nicht möglich, die Dateien mit vollen Schreibrechten zu erstellen? Oder siehst du da ein Sicherheitsproblem?
VG, Thomas
Lässt sich schon machen, wenn Du Dich bis morgen gedulden kannst. Allerdings verstehe ich es nicht: wenn die Datei den Owner fhem bekommt, müsste eigentlich auch Dein FHEM mit diesem User laufen. Du hast aber glaube ich vorhin mal geschrieben, dass es mit root läuft. Dann müsste aber das Schreiben erst recht funktionieren.
Aber wie gesagt: ich ändere die Flags.
Hi zap,
ich habe mein FHEM jetzt soweit umgestellt dass es durch einen User namens fhem gestartet wird.
- dann System neu gebootet mit rpcserver = off.
- anschließend attr rpcserver on gesetzt
Dateien im tmp Verzeichnis werden erzeugt und auch alle paar Sekunden aktualisiert,
RPCPID ist vorhanden aber RPCState bleibt weiterhin auf "Starting".
Clients :HMCCUDEV:HMCCUCHN:
DEF 192.168.178.42
DelDevices 0
DevCount 290
NAME CCU2
NR 34
NewDevices 0
RPCPID 1435
RPCPRC /opt/fhem/FHEM/ccurpcd.pl
RPCState starting
STATE OK
TYPE HMCCU
host 192.168.178.42
jetzt bekomme ich den Fehler im Log HMCCU: 500 Can't connect to 172.27.217.18:8181
@Thomas: Steht im fhem log folgende Meldung?
HMCCU: Received IN event. RPC server initialized."
Wenn ja, bist Du schon der zweite mit diesem Effekt
Werden die Readings der CCU Devices aktualisiert?
Die FHEM Anzeige hast Du mal aktualisiert?
Zitat von: mAr86sEb05 am 24 März 2016, 21:18:35
jetzt bekomme ich den Fehler im Log HMCCU: 500 Can't connect to 172.27.217.18:8181
Und die CCU läuft? Benutzt Du WLAN oder Ethernet?
Hi zap,
nein das FHEM-LOG sieht gut aus.
2016.03.24 21:20:52 0: HMCCU: RPC server started with pid 1948
2016.03.24 21:20:52 1: HMCCU: Registering callback http://192.168.178.58:7401/fh2001 with ID CB2001
2016.03.24 21:20:52 1: HMCCU: RPC callback with URL http://192.168.178.58:7401/fh2001 initialized
2016.03.24 21:21:02 2: HMCCU: Received no events from CCU since 300 seconds
2016.03.24 21:21:07 2: HMCCU: Received no events from CCU since 300 seconds
2016.03.24 21:21:12 2: HMCCU: Received no events from CCU since 300 seconds
Und auch die Readings im Device alle paar Minuten aktualisiert.
VG, Thomas
hat sich erledigt hatte das $network in die init.d eingefügt es scheint das auch das Problem mit dem configfile: Invalid or unknown CCU device name or address
statefile: Please define BM_Ein firstweg ist
Zitat von: ToM_ToM am 24 März 2016, 21:25:20
Hi zap,
nein das FHEM-LOG sieht gut aus.
2016.03.24 21:20:52 0: HMCCU: RPC server started with pid 1948
2016.03.24 21:20:52 1: HMCCU: Registering callback http://192.168.178.58:7401/fh2001 with ID CB2001
2016.03.24 21:20:52 1: HMCCU: RPC callback with URL http://192.168.178.58:7401/fh2001 initialized
2016.03.24 21:21:02 2: HMCCU: Received no events from CCU since 300 seconds
2016.03.24 21:21:07 2: HMCCU: Received no events from CCU since 300 seconds
2016.03.24 21:21:12 2: HMCCU: Received no events from CCU since 300 seconds
Und auch die Readings im Device alle paar Minuten aktualisiert.
VG, Thomas
Nein sieht leider nicht gut aus. Es feht das "received IN event. RPC server initialized
Bitte schick mal die letzten Zeilen aus dem ccurpcd_*log
Zitat von: mAr86sEb05 am 24 März 2016, 21:29:11
hat sich erledigt hatte das $network in die init.d eingefügt es scheint das auch das Problem mit dem configfile: Invalid or unknown CCU device name or address
statefile: Please define BM_Ein firstweg ist
D.h. Bei Dir läuft jetzt alles, auch der RPC Server (RPCState "running"). Das wäre mal ein Lichtblick. Bei anderen Usern bleibt der Server auf "starting"
BTW: vergesst die Meldungen "Received no events from CCU ...". Das ist auch noch en Bug. Hat aber keine Auswirkungen. Ist einfach nur ne Falschmeldung
Habe jetzt mal die Firmware der CCU aktualisiert und alles nochmal von vorne gestartet.
Aber es bleibt weiterhin der Status bei "Starting"
Was steht in ccurpcd_2001.log ? Daraus kann man ersehen, ob die CCU überhaupt etwas schickt.
Und bitte daran denken: Nach dem Start des RPC Servers mindestens 10 Sek warten, dann die FHEM Ansicht aktualisieren.
Hey, in der Log steht
24.03.2016 22:08:51 Creating file queue
24.03.2016 22:08:51 Initializing RPC server
24.03.2016 22:08:51 Callback server created listening on port 7401
24.03.2016 22:08:51 Adding callback for events
24.03.2016 22:08:51 Adding callback for new devices
24.03.2016 22:08:51 Adding callback for deleted devices
24.03.2016 22:08:51 Adding callback for modified devices
24.03.2016 22:08:51 Adding callback for replaced devices
24.03.2016 22:08:51 Adding callback for readded devices
24.03.2016 22:08:51 Entering server loop. Use kill -SIGINT 1478 to terminate program
VG, Thomas
Wie vermutet: die CCU schickt nichts. Das müsste am Ende so aussehen:
26.12.2015 17:00:58 RPC callback with URL http://192.168.1.12:7401/fh initialized
26.12.2015 17:00:58 Entering server loop. Use kill -SIGINT 14211 to terminate program
26.12.2015 17:00:58 ListDevices
26.12.2015 17:01:00 NewDevice: received 179 device specifications
Mal ins Blaue geraten: wenn Du nicht das Attribut rpcport gesetzt hast, setze es mal bitte auf 2001.
Hi zap,
richtig geraten. ;) Das Attribut hatte ich nicht gesetzt.
Habe den RPCServer gestoppt, Attribut gesetzt, RPCServer wieder gestartet, aber bleibt leider wieder im Status "Starting" hängen.
VG, Thomas
Ok, dann muss ich morgen eine Version mit ein paar zusätzlichen log statements einchecken, damit der Startvorgang granularer dargestellt wird.
Okay,
wenn ich dir noch behilflich sein kann, sag Bescheid. ;)
VG, Thomas
Tritt das problem nur auf, wenn Du den Raspi neu startest oder auch bei einem Start von FHEM aus bereits laufendem Linux heraus?
> ich habe bisher immer nur den Raspi - also Linux und Fhem - gebootet
Ich denke, wir müssen das in Deinem Fall systematisch angehen:
> für einen sauberen Start habe ich die log Files gelöscht und den Raspi rebootet
Setze zunächst mal in HMCCU das Attribut rpcserver auf off und speichere die fhem Konfiguration hab.
Dann stoppe FHEM.
> RPCState=stopped
Dann prüfen, ob noch ein RPC Server läuft: ps ax | grep ccurpcd
Falls noch ein Prozess läuft manuell stoppen: kill -SIGINT processid
> es wird nur noch der grep Prozeß selber angezeigt, kill nicht notwendig
Nun FHEM starten
> sudo /etc/init.d/fhem start
Prüfen, was im HMCCU Device im Internal DevCount angezeigt wird. Muss grösser 0 sein
> CCU2 DevCount=134
Prüfen, dass das Internal RPC State "stopped" anzeigt und RPCPID 0
> RPCstate=stopped und RPCPID=0
Das Attribut verbose auf 2 setzen
Mit Attribut rpcserver on den RPC Server starten
Nach 10-11 Sekunden die Ansicht aktualisieren. Die Set und Get Befehle sollten wieder angezeigt werden und in RPCPID die ProzessID stehen. rPCstate muss "running" zeigen
> RPCstate=running, RPCPID=947, Set und Get passt
Fallls das nichts bringt, schicke mit die Ausgabe von "list <hmccudev>" sowie die Ausgabe von folgendem Unix Befehl:
> siehe extra File
grep "HMCCU" /opt/fhem/log/fhem-2016-03.log | tail -100
> Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1138, <$fh> line 52.
> Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1138, <$fh> line 52.
> Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2646, <$fh> line 52.
> Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2646, <$fh> line 52.
> 2016.03.24 23:09:04 0: HMCCU: RPC server started with pid 710
> 2016.03.24 23:09:04 1: HMCCU: Registering callback http://192.168.178.125:7401/fh2001 with ID CB2001
> 2016.03.24 23:09:04 1: HMCCU: RPC callback with URL http://192.168.178.125:7401/fh2001 initialized
> 2016.03.24 23:11:17 1: HMCCU: Deregistering RPC server http://192.168.178.125:7401/fh2001
> 2016.03.24 23:11:17 0: HMCCU: Stopping RPC server with PID 710
> 2016.03.24 23:11:20 0: HMCCU: All RPC servers stopped
> 2016.03.24 23:22:24 0: HMCCU: RPC server started with pid 947
> 2016.03.24 23:22:24 1: HMCCU: Registering callback http://192.168.178.125:7401/fh2001 with ID CB2001
> 2016.03.24 23:22:24 1: HMCCU: RPC callback with URL http://192.168.178.125:7401/fh2001 initialized
> 2016.03.24 23:22:34 0: HMCCU: Received IN event. RPC server initialized.
Sowie das ccurpcd_2001.log File.
> 24.03.2016 23:08:47 RPC server terminated
> 24.03.2016 23:09:04 Creating file queue
> 24.03.2016 23:09:04 Initializing RPC server
> 24.03.2016 23:09:17 Callback server created listening on port 7401
> 24.03.2016 23:09:17 Adding callback for events
> 24.03.2016 23:09:17 Adding callback for new devices
> 24.03.2016 23:09:17 Adding callback for deleted devices
> 24.03.2016 23:09:17 Adding callback for modified devices
> 24.03.2016 23:09:17 Adding callback for replaced devices
> 24.03.2016 23:09:17 Adding callback for readded devices
> 24.03.2016 23:09:17 Entering server loop. Use kill -SIGINT 710 to terminate program
> 24.03.2016 23:11:17 RPC server terminated
> 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
@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.
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
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
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?
Hallo zap,
habe es exakt so wie in dem Link beschrieben, durchgeführt. Und es geht leider auch damit nicht.
VG, Thomas
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
Zitat von: cho am 25 März 2016, 13:07:32
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:
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.
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
Hey cho,
übernimm mal die Konfiguration wie von zap.
Das hat bei mir dann funktioniert.
VG, Thomas
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
Zitat von: cho am 25 März 2016, 13:41:22
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.
Zitat von: cho am 25 März 2016, 14:05:29
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 ;-)
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
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
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
Hallo zap,
ps ax | grep ccurpc
root@bananapi ~ # clear
root@bananapi ~ # ps ax | grep ccurpc
8187 pts/0 S 0:03 /usr/bin/perl /opt/fhem/FHEM/ccurpcd.pl 192.168.178.42 2001 /tmp/ccuqueue_2001 /opt/fhem/log/ccurpcd_2001.log
9070 pts/0 S+ 0:00 grep --color=auto ccurpc
root@bananapi ~ #
VG, Thomas
und das mit rpcport=2001,2010 ?? Wenn ja, hast Du vieleicht ccuflags auf "singlerpc" gesetzt?
wo kann ich das nachsehen?
Zitat von: cho am 25 März 2016, 15:10:06
wo kann ich das nachsehen?
Wieviele RPC-Server laufen? Ich denke, bei Dir dürften es 2 sein (ps ax | grep ccurpc). Du hattest Deine Einstellungen ja schon gepostet.
Nein, bei ToM_ToM interessieren mich rpcport und ccufliags, weil bei ihm nur 1 Server läuft. Du hast ja geschrieben, dass es bei Dir nur mit rpcport=2001,2010 funktioniert. Wenn das bei ToM_ToM mit rpcport=2001 funktioniert, wäre das interessant.
Habe jetzt mal meine Config angepasst und bei mir läuft es auch nur mit dem Port 2001.
#HMCCU
define CCU2 HMCCU 192.168.178.42
# Reading-Namen werden aus dem CCU Kanalnamen gebildet (Alternative "address")
attr CCU2 ccureadingformat name
# Speichere keine Readings im HMCCU Device (dafür gibt es die Client-Devices mit HMCCUDEV und HMCCUCHN)
attr CCU2 ccureadings 0
attr CCU2 devStateIcon (OK|Initialized):10px-kreis-gruen Error:10px-kreis-rot
# Immer eine gute Idee, um FHEM etwas zu entlasten. Sollte man bei jedem HMCC* Device setzen
attr CCU2 event-on-change-reading .*
attr CCU2 icon rc_HOME
# Das Intervall, in dem die Queue mit den Statusinfos der CCU gelesen wird
attr CCU2 rpcinterval 5
# Die CCU-Ports (2001=BidCos-RF, 2000=BidCos-Wired, 2010=Homematic-IP)
attr CCU2 rpcport 2001
attr CCU2 rpcserver on
# Ersetze bei Set-Befehlen on durch true und off durch false (CCU kann mit on/off nichts anfangen)
attr CCU2 statevals on:true,off:false
attr CCU2 stripchar :
# Zahlenwerte in Readings nach der 1. Nachkommastelle abschneiden
attr CCU2 stripnumber 1
# Nur Readings der Client-Devices werden aktualisiert (sonst werden im HMCCU-Device sehr viele Readings auflaufen)
attr CCU2 updatemode client
attr CCU2 verbose 2
#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.
Gibt es eigentlich eine Art Wiki in der viele der gängigen Komponenten als Beispile schon angelegt sind?
Also Thermostat, Fenstersensor, Schalter, etc.
Momentan muss ich viel durch ausprobieren herausfinden und starte dann den RPC-Server immer neu - funktioniert ja jetzt super. ;)
Aber eine Beispielsammlung wäre toll.
VG, Thomas
Möglicherweise hat cho vergessen die FHEM Config zu speichern, nachdem er rpcport auf 2001 gesetzt hatte.
Das Wiki steht ganz oben auf meiner TODO Liste. Im Moment teste ich die nächste Version, die ohne den ccurpcd auskommen soll. Hier gibt es aber noch große Probleme mit Timeouts.
Aber ich werde mal einige meiner Definitionen hier bereitstellen.
Hallo zap,
das kann ich leider ausschliessen (vergessen zu speichern).
Und ich habe gerade noch einmal ein paar Varianten getestet.
funktioniert nicht:
ohne Angabe von rpcport
rpcport=2001
rpcport=2000
rpcport=2010
funktioniert:
rpcport=2001,2010
rpcport=2001,2000
rpcport=2000,2010
rpcport=2010
Es scheint also immer zu funktionieren, wenn entweder 2 Ports angegeben werden - wobei egal ist welche - oder der Port 2010 einzeln angegeben ist.
Vielleicht hilft Dir das ja weiter.
Viele Grüße
Christian
Einige Beispiele für Gerätedefinitionen:
https://forum.fhem.de/index.php/topic,51339.0.html
Zitat von: cho am 25 März 2016, 15:44:09
Es scheint also immer zu funktionieren, wenn entweder 2 Ports angegeben werden - wobei egal ist welche - oder der Port 2010 einzeln angegeben ist.
Wenn Du BidCos-RF und kein Homematic IP verwendest, wird Dir 2010 alleine nichts bringen, da über diesen Port nur Homematic IP Geräte aktualisiert werden.
Da 2001 anscheinend bei Dir gar nicht geht, vermute ich, dass die Ursache auf CCU Seite liegt. Werden denn BidCos-RF Client Device Readings bei Dir aktualisiert? Vorsicht: Nach dem Starten des RPC-Servers werden automatisch einmalig alle Geräte aktualisiert. Daher sind kurz darauf erst mal die Timestamps aktuell. Die Frage ist, ob nach 1-3 Minuten auch noch einzelne Readings aktualisiert werden.
Den netstat Befehl vorhin hättest Du auf der CCU ausführen sollen (ssh root@homematic.fritz.box). Im Zweifel empfehle ich Dir, die CCU mal neu zu starten. Ich vermute dass der Prozess für den Port 2001 nicht mehr (richtig) läuft.
Hey zap,
vielen Dank für die Beispiele.
Übrigens ist mir gerade noch was anderes aufgefallen. Nachdem ich nun mehrfach meinen Pi neu gestartet habe, bleibt der Status wieder in "Starting" hängen.
Obwohl ich vor jedem reboot per Attribute off, den Server beendet habe.
Werde wohl dann die CCU nochmal durchbooten müssen.
VG, Thomas
Hallo zap,
oh, das war mein Fehler - Entschuldigung!
netstat auf der CCU gibt folgendes aus:
tcp 0 0 0.0.0.0:9292 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:1999 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8181 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2010 0.0.0.0:* LISTEN
unix 2 [ ACC ] SEQPACKET LISTENING 267 /run/udev/control
Mit den Ports hast Du recht. Da habe ich von der Anzeige "running" täuschen lassen.
Meine Aussage bezog sich nur auf den Wechsel der Anzeige von "starting" auf "running".
Die Steuerung der CCU funktioniert übrigens problemlos, mit der aktuellen Enstellung 2001,2010.
Und das sowohl beim Lesen (Fensterkontakte, Thermostate) als auch beim Schreiben (Thermostate).
Viele Grüße
Christian
Das Setzen und Lesen per get/set Befehl ist vom RPC-Server völlig unabhängig.
Zu netstat: Da beide Ports auftauchen, scheint alles in Ordnung zu sein. Trotzdem rätselhaft, warum 2001 alleine nicht funktioniert.
Hey, jetzt habe ich das gleiche Problem dass ich den Server nicht mehr zum Laufen bekommen habe.
Auch nach Neustart der CCU nicht.
Erst als ich auch die Ports von 2001 auf 2001,2010 geändert habe, ging es wieder.
VG, Thomas
Hi zap,
bei mir scheint es jetzt mit der Angabe der beiden Ports stabil zu laufen.
Falls Du noch irgendwelche Infos von mir brauchst oder ich etwas testen soll, gib mir einfach Bescheid.
Kannst Du mir bitte noch meine Frage von weiter oben beantworten:
Ist es möglich, beim dem HMCCU Device in der Übersicht anstelle dem STATE (OK) den RPCState (starting/running/stopped) anzuzeigen?
Danke und Grüße
Christian
Verwende dafür das Attribut stateFormat.
RPCState ist ein Internal. Du musst stateFormat wie folgt setzen:
{ $defs{$name}{RPCState} }
Danke!
Hallo Zusammen,
irgendwie geht nachdem ich meinen Pi heute neugestartet habe, auch der RPC-Server nicht wenn beide Ports angegeben sind.
Das muss doch irgendein anderes Problem sein. Werde die CCU wohl später wieder neu starten müssen.
Aber mal eine andere Frage. Ist es möglich dass die Config die ganzen mühevoll angelegten Devices auch nach einem Neustart behält und ich die nicht alle wieder neu hinzufügen muss?
Zum Glück habe ich gestern ein Backup meiner alten Config gemacht.
Viele Grüße und schon Mal ein frohes Osterfest vorab, Thomas
Mein Problem ist, dass ich dieses Verhalten überhaupt nicht nachvollziehen kann. Egal, ob ich einen oder zwei Ports angebe, es wird immer alles korrekt gestartet, auch bei einem Reboot. Von anderen Usern weiß ich, dass es bei ihnen auch läuft.
Und was meinst Du mit Speichern? Man legt die Devices in FHEM an und speichert mit Save. Allerdings: wenn beim Starten von FHEM das HMCCU IO-Device nicht angelegt werden kann, werden auch die Client Devices nicht angelegt. In dem Fall sollten aber einige Fehlermeldungen im FheM Log stehen. In der Oberfläche fehlen dann die Devices.
Die Definitionen sind aber trotzdem noch in fhem.cfg vorhanden. Du darfst nur nicht den Fehler machen, Save zu drücken. Dann wird der fehlerhafte Zustand in fhem.cfg gespeichert und alles ist weg.
Wenn Du die CCU neu startest geht alles wieder? Seltsam.
Du hast nicht noch eines der anderen HM RPC Module gleichzeitig aktiv? Das geht auf keinen Fall.
Verwendest Du auch die aktuelle Version von ccurpcd.pl? Einige Funktionen sind von dort in 88_HMCCU.pm gewandert.
Hallo zap,
ich versuche gerade, Gruppen einzurichten. Aber ich blicke es leider nicht.
Auf der CCU2 habe ich z.B. eine Gruppe INT0000001 eingerichtet, zu der ein Wandthermostat (HM-TC-IT-WM-W-EU_aaa), zwei Heizkörperthermostate (HM-CC-RT-DN_bbb und HM-CC-RT-DN_ccc) und ein Fensterkontakt (HM-Sec-SCo_ddd) gehören.
Auf der CCU2 habe ich auf diese Gruppen datumsabhängig Wochenprogramme per TCL Skript so eingespielt
> xmlrpc http://127.0.0.1:9292/groups putParamset [list string INT0000001] [list string "MASTER"] [list struct {P1_ENDTIME_SATURDAY_1} {int 1440}} {P1_TEMPERATURE_SATURDAY_1 {string 18.0}}]
(vereinfachtes Beispiel für einen Wochentag)
Diese würde ich jetzt gerne auf Fhem und HMCCU übertragen.
Die Gruppe lege ich dann in Fhem so an
> define GR_INT0000001 HMCCUDEV INT0000001 group=HM-TC-IT-WM-W-EU_aaa,HM-CC-RT-DN_bbb,HM-CC-RT-DN_ccc,HM-Sec-SCo_ddd
Wenn ich danach dann
> set GR_INT0000001 config P1_ENDTIME_SATURDAY_1=1440 P1_TEMPERATURE_SATURDAY_1=18.0
ausführe, bekomme ich aber diese Fehlermeldung im WebUI
> HMCCUDEV: GR_INT0000001 Execution of CCU script or command failed
und diese Einträge im fhem log
> 2016.03.26 23:11:46 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 2939.
> 2016.03.26 23:11:46 1: HMCCUDEV: GR_INT0000001 Execution of CCU script or command failed
Ich denke mal, ich mache nur einen Anfängerfehler.
Aber wie geht es richtig?
Viele Grüße
Christian
[/list][/list][/list]
Es gibt nur wenige MASTER Parameter, die direkt im Device liegen. Bei den meisten muss man nach "config" im set Befehl noch eine Kanalnummer angeben.
Aber: das scheint nicht das einzige Problem zu sein. Der Fehler im Log bedeutet, dass die grundlegende URL für die Verbindung zur CCU nicht richtig zusammen gebaut wird. In dem Fall wird der Befehl nie funktionieren. Hast Du im HMCCU Device ein Internal "host" mit dem Namen der CCU?
Aber bevor Du jetzt hier ne Menge Zeit investierst, lass mich das heute abend mal testen. Ich habe das Thema Config Parameter (v.a. die Temperaturen und Zeiten bei Themostaten) bisher etwas vernachlässigt, da ich das immer direkt in der CCU einstelle und dann maximal noch das Wochenprogramm per FHEM auswähle.
Ja, hab ich:
Internals
Clients :HMCCUDEV:HMCCUCHN:
DEF homematic.fritz.box
DelDevices 0
DevCount 134
NAME CCU2
NR 33
NewDevices 0
RPCPID 714,719
RPCPRC ./FHEM/ccurpcd.pl
RPCState running
STATE running
TYPE HMCCU
host homematic.fritz.box
Attributes
ccureadings 0
group Zentrale
room 1 HomeMatic
rpcport 2010,2001
rpcqueue /opt/fhem/tmp/ccuqueue
rpcserver on
stateFormat { $defs{$name}{RPCState} }
updatemode both
Gerade nochmal kurz remote getestet und dabei mein FHEM abgeschossen. Da ist wohl ein größerer Bug drin. Erst mal bitte nicht mehr testen. Muss das heute Abend mal analysieren ...
Grundsätzlich: Es ist denkbar, dass das Setzen und Lesen von Config Parametern bei Gruppen gar nicht geht, da die RPC-Schicht der CCU gar keine Gruppen kennt. Die gibt es nur in der Logik-Schicht. In dem Fall müsste man die Parameter über das Wand-Thermostat (sofern vorhanden) oder das Heizkörper-Thermostat setzen. Wenn es ein Wand-Thermostat in einer Gruppe gibt, ist das der Master, d.h. gibt die Werte für die Gruppe vor.
UPDATE: Morgen gibt es eine neue Version mit funktionierendem set/get config.
Ich habe die Version 3.1 der Module eingecheckt (Link siehe 1. Beitrag). Bitte unbedingt alle Dateien 88_HMCCU* sowie ccurpcd.pl updaten!Änderungen:
Queue-FilesDie Queue-Files werden nun mit der Berechtigung 0666 (-rw-rw-rw-) angelegt.
Statusanzeige RPC-ServerIm HMCCU-Device wird der Status des RPC-Servers nun auch im Reading "rpcstate" angezeigt. Um diesen Status in STATE zu übernehmen, kann das Attribut "stateFormat" auf "rpcstate" gesetzt werden.
Start RPC Server:
Der RPC Server wird nicht mehr über "attr rpcserver" gestartet. Dazu gibt es nun in HMCCU den Befehl "set rpcserver on/off". Das Attribut rpcserver dient nur noch dazu festzulegen, ob der RPC Server beim Starten von FHEM automatisch gestartet wird.
Beim Starten von FHEM wird der RPC Server erst gestartet, wenn FHEM den globalen Event "INITIALIZED" triggert. Das könnte dazu beitragen, dass die Startprobleme bei einigen Benutzern behoben werden.
Setzen von Config-Parametern:Das Setzen von Config-Parametern sollte nun funktionieren. Folgendes Beispiel setzt 3 Zeitintervalle für ein Wandthermostat. Das Thermostat ist als HMCCUDEV Device mit dem Namen HM_KL_SZ angelegt:
set HM_KL_SZ P1_ENDTIME_SATURDAY_1=420 P1_ENDTIME_SATURDAY_2=1260 P1_ENDTIME_SATURDAY_3=1440
Beim Setzen der Zeiten für ein Thermostat sollte immer ein kompletter Tag definiert werden.
Wichtig zu wissen für das Setzen und Lesen von Config-Parametern:
- Wenn beim Setzen ein nicht existierender Parameter angegeben wird, ignoriert die CCU diesen und gibt keine Fehlermeldung zurück
- Die RPC-Schnittstelle unterstützt keine Homematic Gruppen-Geräte (Adresse INT...), da diese in der Logikschicht der CCU abgebildet werden. Wenn z.B. Zeiten oder Temperaturen einer Heizungsgruppe gesetzt werden sollen, muss das Wandthermostat verwendet werden (oder das Heizkörperthermostat, falls kein Wandthermostat vorhanden ist).
- Nicht alle Geräte unterstützen das Auslesen der Parameter-Beschreibung mit "get configdesc" (z.B. die Wandthermostate bieten diesen Funktion nicht an).
SonstigesDie Warnung "experimental::smartmatch" sollte nun nicht mehr im Log auftauchen.
Hallo zap,
vielen Dank für das Update!
Der RPC Server startet bei mir jetzt - auch wenn ich nur Port 2001 angebe.
Und das setzen der Statusanzeige ist so auch viel einfacher.
Ich bekomme beim Booten allerdings immernoch diese Warnungen im fhem log:
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 52.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 52.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 52.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 52.
Das Setzen der Config Parameter funktioniert bei mir jetzt auch.
Schade, dass das nur für die Geräte selber funktioniert, nicht aber für Gruppen.
Wie gesagt, auf der CCU2 funktioniert es via TCL Skript auch bei Gruppen:
load tclrpc.so
xmlrpc http://127.0.0.1:9292/groups putParamset [list string INT0000001] [list string "MASTER"] [list struct {P1_ENDTIME_SATURDAY_1} {int 1440}} {P1_TEMPERATURE_SATURDAY_1 {string 18.0}}]
Aber das scheint dann ja leider über eine andere RPC Schnittstelle zu laufen?
Ich habe die Wochenprogramme bisher immer auf Gruppenebene gesetzt. Die Gruppe hat die Einstellungen dann vererbt: Gruppe -> Wandthermostat, Wandthermostat -> Heizkörper Thermostat bzw. Gruppe -> Heizkörper Thermostat.
Ich frage mich gerade, was passiert, wenn ich die Wochenprogramme nur noch an die Wandthermostat und Heizkörper Thermostate übertrage. Die Gruppen (mit dann abweichenden Wochenprogrammen) bleiben ja bestehen. Nicht, daß die Gruppen dann meine neu übertragenen Wochenprogramme auf den Geräten wieder überschreiben. Das muss ich jetzt erst einmal testen und beobachten.
Viele Grüße
Christian
[/list][/list][/list]
Schön, dass es nun läuft. Möglicherweise hattest Du beim letzten Mal den RPC-Server ccurpcd.pl nicht mit aktualisiert(?). Aber egal. Würde mich interessieren, ob auch bei ToM_ToM das jetzt rund läuft.
Zitat von: cho am 28 März 2016, 23:14:50
Ich bekomme beim Booten allerdings immernoch diese Warnungen im fhem log:
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 52.
Ich hatte gestern Abend nochmal ein Update von 88_HMCCU.pm nachgeschoben. Kannst Du bitte prüfen, ob am Anfang der Datei (nach dem Kommentar-Header) folgende Zeile vorhanden ist:
no if $] >= 5.017011, warnings => 'experimental::smartmatch';
Zitat
Schade, dass das nur für die Geräte selber funktioniert, nicht aber für Gruppen.
Wie gesagt, auf der CCU2 funktioniert es via TCL Skript auch bei Gruppen:
load tclrpc.so
xmlrpc http://127.0.0.1:9292/groups putParamset [list string INT0000001] [list string "MASTER"] [list struct {P1_ENDTIME_SATURDAY_1} {int 1440}} {P1_TEMPERATURE_SATURDAY_1 {string 18.0}}]
Aber das scheint dann ja leider über eine andere RPC Schnittstelle zu laufen?
Definitiv, die CCU schickt auch keine Aktualisierungen für Gruppen an den RPC-Server. Ist die Datei "xmlrpc" standardmäßig auf der CCU vorhanden? Dann schaue ich mir das mal an.
Zitat
Ich frage mich gerade, was passiert, wenn ich die Wochenprogramme nur noch an die Wandthermostat und Heizkörper Thermostate übertrage. Die Gruppen (mit dann abweichenden Wochenprogrammen) bleiben ja bestehen. Nicht, daß die Gruppen dann meine neu übertragenen Wochenprogramme auf den Geräten wieder überschreiben. Das muss ich jetzt erst einmal testen und beobachten.
Wenn ein Wandthermostat in der Gruppe ist und man ändert Parameter des Wandthermostats, ändern sich auch die Gruppen-Parameter. Ich verstehe das so, dass eine Gruppe keine eigenen Parameter hat sondern die des Wandthermostats bzw. des Heizkörperthermostats verwendet und darstellt. Für diese Theorie spricht auch, dass die Meldung kommt "Daten werden an das Gerät übertragen" sobald man im CCU WebUI einen Gruppenparameter ändert.
P.S. wo kommt eigentlich dieses "list, list, list" am Ende des Beotrags her. Ich bekomme das nicht weg.
[/list][/list][/list]
Hallo Zusammen,
bei mir läuft es jetzt seit einigen Tagen wunderbar, weshalb ich mich kaum traue, zu aktualisieren. ;)
Da ich das Ganze bei meinen Eltern eingerichtet habe, morgen wieder abreise und nur ca. alle 5 Monate dazu komme daran weiterzubasteln, bin ich gerade froh dass es so gut läuft.
Ich kann die Heizungsthermostate schalten, Klimasensoren abfragen... - alles wunderbar.
Hier übrigens ein Beispiel für nen Klimasensor:
define HM_DB_Klimasensor HMCCUDEV LEQXXXXXXXX 1
attr HM_DB_Klimasensor IODev CCU2
attr HM_DB_Klimasensor ccureadingfilter (LOWBAT|HUMIDITY|TEMPERATURE|CONTROL)
attr HM_DB_Klimasensor ccureadingformat name
attr HM_DB_Klimasensor event-on-change-reading .*
attr HM_DB_Klimasensor statechannel 1
attr HM_DB_Klimasensor stripnumber 1
attr HM_DB_Klimasensor substitute LOWBAT!(0|false):no,(1|true):yes
VG, Thomas
In dem Fall würde ich vielleicht auch nach dem Prinzip "never touch a running system" verfahren. Das Setzen von Config-Parametern (z.B. Heizzeiten) wird mit der alten Version aber nicht funktionieren. Da ist ein Bug drin.
P.S. Schon mal über einen VPN-Tunnel zwecks Remote-Zugriff nachgedacht?
Hallo zap,
VPN ist an sich kein Thema, allerdings müsste ich das Tablet dann auch über VPN konfigurieren. Und soweit ich weiß, geht das per TeamViewer nur mit der kommerziellen Version.
Naja ich habe auch mit meinem System daheim schon genug Arbeit. ;)
Heizdaten an sich setze ich aktuell nicht. von daher passt es.
Kennst du diese Lautsprecher von Homematic die man in die Steckdose steckt und die dann mp3-files von einer darin enthaltenen SD-Karte abspielen?
Mich würde noch interessieren wie man so ein Gerät anspricht. :)
Aber das mache ich dann beim nächsten Mal.
Habe es übrigens jetzt doch mal gewagt das Update durchzuführen und bisher läuft es super. :)
Kann nur sagen, super Arbeit von dir.
VG, Thomas
Hallo zap,
ob ich beim letzten mal vergessen hatte, die ccurpcd.pl zu aktualisieren, kann ich nicht mehr überprüfen. Ich glaube es aber eigentlich nicht. Wie auch immer, jetzt funktioniert es ja.
Ich habe gerade auch noch einmal nachgesehen. Ich habe Dein letztes Update 3.1 mit der 88_HMCCU.pm mit der Zeile "no if..." laufen. Sind die Warnungen eigentlich problematisch?
Die Datei "xmlrpc" ist standardmäßig auf der CCU vorhanden. Ich weiß dazu auch nur, dass auf der CCU2 für Gruppen ein eigener XML-RPC-Server mit der Adresse http://127.0.0.1:9292/groups läuft. Die Info findet man in verschieden Foren Beiträgen, z.B. hier:
http://homematic-forum.de/forum/viewtopic.php?f=26&t=20875#p189304
P.S. Wo das "list, list, list" herkommt, kann ich Dir leider auch nicht sagen. Es war nach dem Speichern ("Schreiben") einfach da und ließ sich über "Ändern" auch nicht wieder löschen?
Viele Grüße
Christian
Zitat von: cho am 29 März 2016, 19:30:34
Ich habe gerade auch noch einmal nachgesehen. Ich habe Dein letztes Update 3.1 mit der 88_HMCCU.pm mit der Zeile "no if..." laufen. Sind die Warnungen eigentlich problematisch?
Nein, kein Problem. Sind nur Warnungen. Dann ersetzte ich mal "~~" durch "grep" in der nächsten Version. Dann ist das erledigt.
Zitat
Die Datei "xmlrpc" ist standardmäßig auf der CCU vorhanden. Ich weiß dazu auch nur, dass auf der CCU2 für Gruppen ein eigener XML-RPC-Server mit der Adresse http://127.0.0.1:9292/groups läuft. Die Info findet man in verschieden Foren Beiträgen, z.B. hier:
Vielen Dank für den Hinweis.
Hallo,
nachdem ich mich entschieden habe meine Anforderungen über HMCCU einzupflegen habe ich begonnen das Modul zu installieren. Klappte soweit auh ganz gut allerdings bekomme ich es nicht gestartet. Wahrscheinlich habe ich doch irgendetwas überlesen :-(
Die Fehler im Log lauten - was hab ich verbockt ? (ich hoffe ist okay hier die Frage zu stellen):
2016.03.30 13:37:08 1: Including fhem.cfg
2016.03.30 13:37:08 1: reload: Error:Modul 88_HMCCU deactivated:
Can't modify constant item in predecrement (--) at ./FHEM/88_HMCCU.pm line 2, near "Server:"
syntax error at ./FHEM/88_HMCCU.pm line 2, near "Server:"
syntax error at ./FHEM/88_HMCCU.pm line 4317, near ">)"
syntax error at ./FHEM/88_HMCCU.pm line 4318, near "/div><div id="l438" class="code_block"> <span class="p">}</span"
syntax error at ./FHEM/88_HMCCU.pm line 4320, near ""l440" class"
syntax error at ./FHEM/88_HMCCU.pm line 4322, near ">)"
syntax error at ./FHEM/88_HMCCU.pm line 4325, near "</div"
syntax error at ./FHEM/88_HMCCU.pm line 4326, near ""l446" class"
syntax error at ./FHEM/88_HMCCU.pm line 4326, near ">)"
Unmatched right curly bracket at ./FHEM/88_HMCCU.pm line 4328, at end of line
./FHEM/88_HMCCU.pm has too many errors.
2016.03.30 13:37:08 0: Can't modify constant item in predecrement (--) at ./FHEM/88_HMCCU.pm line 2, near "Server:"
syntax error at ./FHEM/88_HMCCU.pm line 2, near "Server:"
syntax error at ./FHEM/88_HMCCU.pm line 4317, near ">)"
syntax error at ./FHEM/88_HMCCU.pm line 4318, near "/div><div id="l438" class="code_block"> <span class="p">}</span"
syntax error at ./FHEM/88_HMCCU.pm line 4320, near ""l440" class"
syntax error at ./FHEM/88_HMCCU.pm line 4322, near ">)"
syntax error at ./FHEM/88_HMCCU.pm line 4325, near "</div"
syntax error at ./FHEM/88_HMCCU.pm line 4326, near ""l446" class"
syntax error at ./FHEM/88_HMCCU.pm line 4326, near ">)"
Unmatched right curly bracket at ./FHEM/88_HMCCU.pm line 4328, at end of line
./FHEM/88_HMCCU.pm has too many errors.
2016.03.30 13:37:08 1: Including /opt/fhem/FHEM/dsHutAktorM1.cfg
2016.03.30 13:37:08 1: Including /opt/fhem/FHEM/dsTeich.cfg
2016.03.30 13:37:08 1: Including /opt/fhem/FHEM/dsH20detect.cfg
2016.03.30 13:37:08 1: Including /media/usbhdd/FHEM/FHEM_Statefile/fhem.save
2016.03.30 13:37:16 1: PERL WARNING: Use of uninitialized value $val in substitution (s///) at fhem.pl line 1483.
2016.03.30 13:37:16 1: PERL WARNING: Use of uninitialized value $val in substitution (s///) at fhem.pl line 1484.
2016.03.30 13:37:16 1: PERL WARNING: Use of uninitialized value $val in concatenation (.) or string at fhem.pl line 1485.
Ich vermute, da ist beim Download von Sourceforge etwas schief gegangen. In Sourceforge die Datei anzeigen lassen und dann "Download this file" klicken.
Jo scheint so. Hab sie runtergalden und nun hab ich anderen Fehler (ich habe aber alle cpan Module installiert wie in der Anleitung):
2016.03.30 15:34:57 1: reload: Error:Modul 88_HMCCU deactivated:
Can't locate RPC/XML/Client.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/88_HMCCU.pm line 72, <$fh> line 32.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 72, <$fh> line 32.
2016.03.30 15:34:57 0: Can't locate RPC/XML/Client.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/88_HMCCU.pm line 72, <$fh> line 32.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 72, <$fh> line 32.
2016.03.30 15:34:58 1: Including /opt/fhem/FHEM/dsHutAktorM1.cfg
2016.03.30 15:34:58 1: Including /opt/fhem/FHEM/dsTeich.cfg
2016.03.30 15:34:59 1: Including /opt/fhem/FHEM/dsH20detect.cfg
2016.03.30 15:34:59 1: Including /media/usbhdd/FHEM/FHEM_Statefile/fhem.save
2016.03.30 15:34:59 1: configfile: Cannot load module HMCCU
FunkSchaltaktor_Leistung: unknown IODev specified
RPC::XML::Client ist nicht installiert (ggf. auch der Rest von RPC).
Ja da magst du wohl recht haben. Die Logs besagen mir, dass bei der Installation von den CPAN Modulen was schief läuft. Fehlermeldungen ala "cannot find tar file". Irgendwas kollidiert da grad gewaltig.
Using Tar:/bin/tar xf "libwww-perl-6.15.tar":
Couldn't untar libwww-perl-6.15.tar: 'Cannot allocate memory'
ETHER/libwww-perl-6.15.tar.gz
Had problems unarchiving. Please build manually
Die Meldung "cannot allocate memory" liest sich nicht gut.
Entweder der Speicher ist aus oder ein Filesystem ist voll. Das tar braucht jedenfalls irgendwo temporären Platz um was auszupacken.
Yep sehe ich genauso :-( Da hab ich wohl momentan zu viele "Testsysteme" laufen :-( Speicher voll ? Filesystem hat noch genug
Kann man da noch was frei schaufeln ?
Dass das physikalische Memory fast voll ist, heißt bei Unix gar nichts. Swap ist auch noch genügend vorhanden. Sieht bei mir auf dem Raspi auch nicht anders aus. Aber Du kannst für die Dauer der Installation mal ein paar Dinge stoppen.
Oder Du schaust mal, ob Du ein Linux Paket für RPC findest. Lässt sich vielleicht einfacher installieren.
Das könnte passen: librpc-xml-perl
Uh, das ist ein guter Hinweis .... bin ich gar nicht selbst drauf gekommen. Werde es morgen ausprobieren --> heute habe ich anscheinend schon eckige Augen :-)
DANKE zap !
Ich werde berichten
Guten Morgen!
hat natürlich geklappt ! Nun sind alle Module installiert.
Beim ersten define liest er ja nun alle Geräte ein und anscheinend stockt er bei einem:
FunkSchaltaktor_Leistung: unknown IODev specified
kennt er den nicht oder was sagt mir das ?
Du musst zuerst das IO Device definieren:
define my_ccu HMCCU host_or_ip
Die Liste der Geräte wird nur bei der Definition des IO Device eingelesen.
Wenn das passiert ist, kannst du mit den Modulen HMCCUDEV und HMCCUCHN die Devices für die einzelnen Homematic Komponenten anlegen.
Okay, hab auch jetzt einen Beitrag gelesen wo die "attr" drin sind.
Da ich ein bestehendes System habe mit ca. 30 Aktoren muss ich die alle erstmal über HMCCUDEV und HMCCUCHN definieren ?
Den rpcserver bekomme ich erstmal nicht gestartet da läuft er auf den fehler --> please define rpcserver first. Owohl im log steht:
2016.03.31 09:36:43 0: Server started with 173 defined entities (fhem.pl:11144/2016-03-29 perl:5.014002 os:linux user:fhem pid:21877)
2016.03.31 09:37:53 0: HMCCU: RPC server not running
die Definition lautet:
# IO Device definieren
define d_HMCCU2 HMCCU 192.168.40.xxx
attr d_HMCCU2 ccureadings 1
attr d_HMCCU2 room 90_System
attr d_HMCCU2 rpcserver on
UPDATE 10:40:
rpcserver läuft erstmal --> datei war nicht ausführbar gemacht von mir. Ich teste weiter !
In der aktuellen Version wird der RPC-Server nicht mehr direkt nach Ausführung von "attr rpcserver on" gestartet. Dieses Attribut sorgt nur noch dafür, dass der RPC-Server beim Starten von FHEM automatisch gestartet wird.
Manuell kann der RPC-Server mit dem Befehl "set rpcserver on" (im IO Device) gestartet werden.
Und ja: Du musst für alle Geräte, die Du per FHEM ansprechen willst, ein Device mit HMCCUDEV oder HMCCUCHN definieren.
Schau Dir mal die HMCCU_Readme.txt an (ist im 1. Beitrag verlinkt). Die ist zwar nicht brandaktuelle (z.B. Starten des RPC Servers ist noch nicht aktualisiert), aber grundsätzlich ein guter Einstieg (hoffe ich).
Auf autocreate von Devices habe ich bewusst verzichtet. Viele Nutzer haben eine sehr große Homematic Umgebung (ich z.B. ;-). Da wollte ich nicht unkontrolliert Devices in FHEM anlegen lassen.
Ja, das habe ich auch festgestellt dass der rpc-server nicht automatisch startet --> steht ja auch in der Readme so, allerdings wusste ich nicht genau wie ich den starte. Dann hab ichs gelesen --> in fhem manuell starten oder in die "Oberfläche" von HMCCU und dann dort über die Vorauswahlen konfigurieren und bestätigen!
Es gibt also kein Autocreate wie es zB bei der HM_CUL gemacht wurde ?
Mhhh okay verstehe ich gerade wenn man viele devices hat. Dann wäre aber eine kleine Liste gut welche Parameter man denn setzen kann. bei der HM_CUL waren Dinge dabei wie
.devInfo, actCycle, actStatus, alias, autoReadReg, expert, firmware, group, model, peerIDs, room, serialNr, subType
die Abfrage in FHEM mit "attr xyz ?" ergibt (ist es das was man an Parametern hat?):
choose one of verbose room group comment alias eventMap userReadings IODev ccureadingfilter ccureadingformat ccureadings ccuget ccuverify disable mapdatapoints statevals substitute statechannel statedatapoint controldatapoint stripnumber event-on-change-reading event-on-update-reading event-aggregator event-min-interval stateFormat cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride userattr
Die möglichen Parameter siehst Du wie in FHEM üblich entweder per "?" Angabe oder im Webinterface in der Auswahlliste hinter set/get/attrib.
FHEM bietet ja auch das Klonen von Devices an. So kannst Du z.B. einen Fenstersensor definieren, alle notwendigen Attribute setzen und dann das FHEM Device klonen. Danach in der Kopie nochmal "DEF" anklicken und noch die Adresse anpassen. Ggf. noch das ein oder andere Attribut korrigieren, sofern erforderlich. Fertig. Das ist jedenfalls schneller, als jeden Sensor einzeln zu definieren und v.a. die Attribute zu setzen.
Sobald Du mal wieder ein Update in FHEM machst, wird auch die HMCCU Hilfe in der lokalen FHEM Online Hilfe verfügbar. Da sind fast alle Parameter und Befehle beschrieben.
Okay die Hilfe ist jetzt drin durch das update!
nur schmeisst der mir immer noch raus --> please define rpcserver first wenn ich denn über das device per attr starten will. Komisch. So ganz blicke ich da auch noch nicht durch.
Ich muss jetzt anscheinend für ein device in der CCU das HMCCUDEV und HMCCUCHN definieren gemäß der help:
define window_living HMCCUCHN WIN-LIV-1 readonly
define temp_control HMCCUCHN BidCos-RF.LEQ1234567:1
define window_living HMCCUDEV WIN-LIV-1 readonly
define temp_control HMCCUDEV BidCos-RF.LEQ1234567 1
Warum einmal mit ":" und einmal ohne ?
Was ist wenn das Device mehr als einen Kanal hat also zB mein Hutschienenkator hat 4 ?
Was meinst du ist die beste Vorgehensweise: Mein bisheriger fhem Aufbau war über HM_CUL --> wenn ich das jetzt auf HMCCU umstelle ist besser bei null anzufangen und Schritt für Schritt "umzuschreiben" ?
Zitat von: tuppertasse am 31 März 2016, 20:52:28
nur schmeisst der mir immer noch raus --> please define rpcserver first wenn ich denn über das device per attr starten will. Komisch. So ganz blicke ich da auch noch nicht durch.
Ich vermute, Du versuchst "set rpcserver on" auszuführen. Da fehlt dann der Name des HMCCU IO Device, "rpcserver" ist ja nur der Befehl. Wenn Dein IO-Device z.B. "meine_schoene_CCU" heißt, lautet der Befehl "set meine_schoene_CCU rpcserver on".
Zitat
Ich muss jetzt anscheinend für ein device in der CCU das HMCCUDEV und HMCCUCHN definieren gemäß der help:
Nein, eine doppelte Definition mit HMCCUCHN und HMCCUDEV kann man zwar machen, ist aber nicht sinnvoll (auch wenn es grundsätzlich unterstützt wird). Hier hatte ich mal ein paar Beispieldefinitionen gepostet: https://forum.fhem.de/index.php/topic,51339.msg429984.html#msg429984
HMCCUCHN ist eine einfachere Form von HMCCUDEV. D.h. wenn Du bei einem Homematic Gerät nur einen Kanal benötigst (z.B. bei einem Tür-/Fenstersensor reicht Kanal 1), dann definierst Du das FHEM Device am besten über HMCCUCHN. Als Parameter wird dann entweder der Name des Kanals in der CCU oder die Adresse des Kanals angegeben. Die Kanaladresse ist immer
Geräteadresse:Kanalnummer. Wenn Du den Kanalnamen verwendest, ist nur dann ein Doppelpunkt anzugeben, wenn auch der Kanalname in der CCU einen Doppelpunkt enthält. Es ist eben der Name in der CCU, nicht mehr und nicht weniger. Bei den Tür-/Fenstersensoren macht auch der Parameter "readonly" Sinn, da es hier nichts zu schalten gibt.
Bei allen anderen Geräten würde ich HMCCUDEV empfehlen. Die damit angelegten FHEM Devices enthalten alle Kanäle. Bei HMCCUDEV wird dann auch der Gerätename in der CCU oder die Geräteadresse (ohne Doppelpunkt und Kanalnummer) angegeben.
Gut nachvollziehen kannst Du das, wenn Du bei einem FHEM Geräte (egal ob HMCCUDEV oder HMCCUCHN) den Befehl "get deviceinfo" ausführst. Dann zeigt Dir FHEM eine Liste aller Kanäle und Datenpunkte an. Bei einem HMCCUCHN Gerät ist das genau ein Kanal, bei einem HMCCUDEV Gerät alle Kanäle.
Zitat
Was meinst du ist die beste Vorgehensweise: Mein bisheriger fhem Aufbau war über HM_CUL --> wenn ich das jetzt auf HMCCU umstelle ist besser bei null anzufangen und Schritt für Schritt "umzuschreiben" ?
Wenn die Geräte sowohl in FHEM per CUL sichtbar sind als auch in der CCU, kannst Du schrittweise migrieren. Grundsätzlich ist es möglich, die Geräte in beiden Welten zu sehen. Da kenne ich mich aber nicht so gut aus (Frage wurde hier im Forum aber schon mal behandelt).
P.S. Habe ehrlich gesagt nicht damit gerechnet, dass jemand tatsächlich von CUL auf HMCCU umstellt. Wenn es hier mehr Bedarf gibt, schreibe ich vielleicht mal sowas wie einen "Migration Guide".
Zitat von: zap am 01 April 2016, 09:11:01
P.S. Habe ehrlich gesagt nicht damit gerechnet, dass jemand tatsächlich von CUL auf HMCCU umstellt. Wenn es hier mehr Bedarf gibt, schreibe ich vielleicht mal sowas wie einen "Migration Guide".
Tja, ich hätte es auch nicht gedacht da ich vor bestimmt einem Jahr mein FHEM eingedampft habe. Warum ? Naja für mich ist es zwar ein sehr mächtiges Werkzeug aber für einen "Nicht-Programmierer ala Linux & Perl" einfach zu "kryptisch". Die Fehlersuche hat mich Zeit ohne Ende gekostet. Und bei Einspielen von Updates hatte ich wieder Probleme weil es wahrscheinlich nicht sauber programmiert war (klar ist meine Schuld aber wenn man mehrere Wege zum Ziel hat und sich dann anscheinend für den "falschen" entscheidet dann ist das frustrierend).
Somit bin ich auch die CCU2 umgesprungen und habe mir super einfach über KLICKIBUNTI alles zusammengemacht. Für einen Linux-NOOB wie ich es bin genau das richtige. Jetzt kam der Wunsch auf alles das was die CCU2 nicht kann wieder über FHEM abzufahren und bin auf deine Möglichkeit gestossen. Daher kann ich nun meine gesicherte FHEM Umgebung schrittweise anpassen was ich noch brauche und was nicht :-) Das ist der Hintergrund und nochmal ein RIESENLOB an deine Kooperation / Erstellung / Hilfestellung hier zu dem Thema HMCCU !
Ich hätte nie gedacht wieder mal zurück nach FHEM zu kommen --> DANKE
Nun zu meinem aktuellen Stand.
RPCSERVER läuft - die ersten Datenpunkte habe ich auch mal eingelesen. Sie sind nur statisch also werden nicht, wenn sich der Datenpunkt ändert, autoamtisch auch in FHEM abgezeigt sondern nur wenn ich zB auf get xxx channel gehe.
Frage daher: Wie aktualisiere ich die Datenpunkte ? Über HMCCU get update ?
Früher wurden die Anzeige in Logfiles geschrieben um eine Historie zu haben (Filelog); wie ist das bei HMCCU ?
UPDATE 11:46:RPCServer lief nicht mehr --> wurde im Log terminated warum auch immer. habe ihn neu gestartet und nun kommen auch events on change des devices an !
Zitat von: tuppertasse am 01 April 2016, 10:37:28
RPCSERVER läuft - die ersten Datenpunkte habe ich auch mal eingelesen. Sie sind nur statisch also werden nicht, wenn sich der Datenpunkt ändert, autoamtisch auch in FHEM abgezeigt sondern nur wenn ich zB auf get xxx channel gehe.
Frage daher: Wie aktualisiere ich die Datenpunkte ? Über HMCCU get update ?
Früher wurden die Anzeige in Logfiles geschrieben um eine Historie zu haben (Filelog); wie ist das bei HMCCU ?
Wenn der RPC Server richtig läuft, müssen die Readings automatisch aktualisiert werden. Die Befehle get xxx channel und get xxx update sind für manuelle Updates gedacht. Ein get update im IO Device aktualisiert global galaktisch alle definierten CCU Devices. Ein get update in einem Client-Device eben nur die Readings des entsprechenden Device.
Um zu prüfen, ob der RPC Server korrekt läuft, kannst Du mal folgendes ausprobieren:
- Im Internal RPCPID des IO Device muss (mindestens) 1 Zahl > 0 stehen, nämlich die Prozess-ID des RPC Servers
- Im Internal RPCState muss "running" stehen
- Im Verzeichnis /tmp sollten zwei Dateien existieren: ccuqueue_2001.dat und ccuqueue_2001.idx. Der Zeitstempel dieser Dateien sollte alle paar Sekunden aktualisiert werden. Meistens haben diese Dateien eine Größe von 0 oder 1.
- Interessant für die Fehlersuche ist auch die Datei /opt/fhem/log/ccurpcd_2001.log sowie sämtliche Einträge in der fhem Logdatei, die "HMCCU:" enthalten. Die kannst Du mir gerne per Forum-Mail schicken
Zitat von: zap am 01 April 2016, 11:51:23
- Im Internal RPCPID des IO Device muss (mindestens) 1 Zahl > 0 stehen, nämlich die Prozess-ID des RPC Servers
Ja größer NullZitat von: zap am 01 April 2016, 11:51:23
- Im Internal RPCState muss "running" stehen
state = runningZitat von: zap am 01 April 2016, 11:51:23
- Im Verzeichnis /tmp sollten zwei Dateien existieren: ccuqueue_2001.dat und ccuqueue_2001.idx. Der Zeitstempel dieser Dateien sollte alle paar Sekunden aktualisiert werden. Meistens haben diese Dateien eine Größe von 0 oder 1.
Ja ist so !Zitat von: zap am 01 April 2016, 11:51:23
- Interessant für die Fehlersuche ist auch die Datei /opt/fhem/log/ccurpcd_2001.log sowie sämtliche Einträge in der fhem Logdatei, die "HMCCU:" enthalten. Die kannst Du mir gerne per Forum-Mail schicken
Die werde ich dir mal per Mail schicken !
Nachtrag:
Der rpcserver scheint sich nach einiger Zeit zu beenden. Im Log steht folgendes nachdem einige Perl Warnungen ausgegeben werden:
2016.04.01 17:17:06 1: PERL WARNING: Use of uninitialized value $pdump in split at ./FHEM/88_HMCCU.pm line 1558.
2016.04.01 17:17:06 0: HMCCU: All RPC servers stopped
Der Prozess-Check schlägt fehl. Welches Betriebssystem verwendest Du? Wie sieht die Ausgabe von folgendem Befehl aus:
ps ax | grep fhem | grep -v grep
Moment läuft der rpcserver nicht und trotzdem habe ich diese Einträge (grübelgrübel):
446 ? S 56:09 perl fhem.pl fhem.cfg
29924 ? S 0:00 perl fhem.pl fhem.cfg
der Befehl
ps -ef | grep ccurpcd.pl
bringt folgendes Ergebnis:
fhem 559 446 0 Apr01 ? 00:13:44 /usr/bin/perl ./FHEM/ccurpcd.pl 192.168.xx.yyy 2001 /tmp/ccuqueue_2001 ./log/ccurpcd_2001.log
pi 30164 29910 0 08:30 pts/0 00:00:00 grep --color=auto ccurpcd.pl
Der RPC Server läuft, aber HMCCU merkt das nicht. Bitte mal folgenden Befehl ausführen und die Ausgabe posten:
ps ax | grep ccurpcd
Welches Berriebssystem?
Betriebssystem ist Debian Wheezy 7.9
proc ergibt:
Linux version 4.1.20-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) )
Abfrage ergibt:
559 ? S 14:34 /usr/bin/perl ./FHEM/ccurpcd.pl 192.168.xx.yyy 2001 /tmp/ccuqueue_2001 ./log/ccurpcd_2001.log
4366 pts/0 S+ 0:00 grep --color=auto ccurpcd
Die Ausgabe passt. Ist mir ein Rätsel, warum die Prozessprüfung in HMCCu fehl schlägt (ich meine die "pdump" Fehlermeldung in Deinem Logfile).
Einzige verbleibende Möglichkeit: HMCCU findet den ps Befehl nicht bzw. der User fhem darf den nicht ausführen. Das würde mich doch aber sehr wundern. Das ist schwierig zu testen, muss ich erst mal drüber nachdenken.
Nachgedacht: Gib mal bitte in der Eingabezeile der FHEM Oberfläche folgende Zeile ein:
{`ps ax | grep ccurpcd`}
Es sollte der RPC Prozess angezeigt werden. Bitte beachten: Die Anführungszeichen sind umgedreht, im Zweifel die Zeile oben einfach kopieren.
Hallo anbei das Ergebnis der Abfrage:
559 ? S 17:14 /usr/bin/perl ./FHEM/ccurpcd.pl 192.168.40.141 2001 /tmp/ccuqueue_2001 ./log/ccurpcd_2001.log
23003 ? S 0:00 sh -c ps ax | grep ccurpcd
23005 ? S 0:00 grep ccurpcd
Verstehen tue ich das grad nicht. Ich frag mich nur ob es richtig ist dass noch ein Prozess gestartet wird wenn ich den rpcserver starte und FHEM mir dann auch running und OK anzeigt. grübelgrübel
Wenn ich es richtig verstanden habe, startest Du den RPC-Server. In FHEM wird "running" angezeigt. Aber nach kurzer Zeit geht die Anzeige auf "stopped". Trotzdem läuft der Prozess ccurpcd.pl weiter.
Hintergrund zu der ganzen Testerei: HMCCU prüft alle paar Sekunden, ob der Prozess ccurpcd.pl noch läuft. Dazu wird der Unix-Befehl "ps" verwendet. Aus irgendwelchen Gründen funktioniert bei Dir diese Prüfung nicht richtig. Darauf deutet die Fehlermeldung mit dem "pdump" im Logfile von FHEM hin.
Meine Vermutung war nun, dass der Nutzer "fhem" nicht die notwendigen Rechte hat, um "ps" auszuführen oder die Datei nicht findet. Daher die manuelle Ausführung über die Kommandozeile von FHEM. Da da funktioniert hat, liegt das Problem woanders.
Blöd ist: Du bist der einzige mit diesem Problem.
Oder kann ich Dein Frage so interpretieren, dass es nun doch läuft und nun nicht "stopped" sondern "running" angezeigt wird?
Zitat von: zap am 04 April 2016, 07:47:21
Blöd ist: Du bist der einzige mit diesem Problem.
:o immer ich :o
Zitat von: zap am 04 April 2016, 07:47:21
Oder kann ich Dein Frage so interpretieren, dass es nun doch läuft und nun nicht "stopped" sondern "running" angezeigt wird?
Nein ist weiterhin so. Allerdings könnte ich schwören, dass wenn ich jetzt in FHEM den befehl eingebe um die rpcserver zu starten wird ein ZWEITER Prozess gestartet. Ich meine mich zu erinnern, dass dann noch ein Prozess gestartet wird, der dann irgendwann abbricht. Die Frage ist woher und wer7was/wo startet den jetzigen Prozess ??? :o :o :o
ERGÄNZUNG 08.08:Den Prozess bekomme ich aus FHEM nicht mehr gestoppt --> siehe Filelog Eintrag:
2016.04.04 08:04:40 1: HMCCU: Externally launched RPC server(s) detected. Kill process(es) manually with command kill -SIGINT pid for pid=559
2016.04.04 08:04:40 1: HMCCU: d_HMCCU2 Start of RPC server failed
2016.04.04 08:05:25 0: HMCCU: RPC server not running
2016.04.04 08:05:43 1: HMCCU: Externally launched RPC server(s) detected. Kill process(es) manually with command kill -SIGINT pid for pid=559
2016.04.04 08:05:43 1: HMCCU: d_HMCCU2 Start of RPC server failedDie Frage ist also liefen zwei Prozesse oder ist der rpcserver mit Fehler ausgestiegen und konnte nicht beendet werden. Das weiss ich nicht. Ich kille den Prozess jetzt und starte nochmal den rpcserver
Update 08:15:Prozess konnte nur mit
kill -9 beendet werden.
Neu gestartet mit FHEM ohne Probleme. Test läuft also
Hallo zusammen,
bin ganz neu in der FHEM Welt und habe auch so meine Spässe mit dem rpc Dämon. Auch bei mir beendet sich
der RPC Prozess automatisch. Zusätzlich wirft er mir jetzt seit gestern aber 21.51 Uhr noch einen Fehler im Log aus, mit dem ich nichts anfangen kann.
Würde mich über Unterstützung sehr freuen.
Hier das Log:
2016.04.04 05:17:27 1: Including fhem.cfg
2016.04.04 05:17:27 3: telnetPort: port 7072 opened
2016.04.04 05:17:29 3: WEB: port 8083 opened
2016.04.04 05:17:29 3: WEBphone: port 8084 opened
2016.04.04 05:17:29 3: WEBtablet: port 8085 opened
2016.04.04 05:17:29 2: eventTypes: loaded 6 events from ./log/eventTypes.txt
2016.04.04 06:13:08 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
2016.04.04 06:13:33 1: Including ./log/fhem.save
2016.04.04 06:13:33 1: in INITIALIZED
2016.04.04 06:13:33 0: HMCCU: Autostart of RPC server after FHEM initialization in 10 seconds
2016.04.04 06:13:33 1: usb create starting
2016.04.04 06:13:34 3: Probing CUL device /dev/ttyAMA0
2016.04.04 06:13:35 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.04 06:13:35 1: usb create end
2016.04.04 06:13:35 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.04 06:13:35 0: Featurelevel: 5.7
2016.04.04 06:13:35 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 835)
2016.04.04 06:13:35 3: ipc fronthem:127.0.0.1:52477 (ws): ws alive with pid 987
2016.04.04 06:13:44 1: PERL WARNING: Can't exec "./FHEM/ccurpcd.pl": Keine Berechtigung at ./FHEM/88_HMCCU.pm line 1359.
Died at ./FHEM/88_HMCCU.pm line 1362.
2016.04.04 06:13:46 0: HMCCU: RPC server started with pid 1177
2016.04.04 06:13:46 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001
2016.04.04 06:13:46 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.04 06:13:56 0: HMCCU: All RPC servers stopped
2016.04.04 06:17:35 1: in ATTR
2016.04.04 06:17:37 1: in SAVE
2016.04.04 06:18:00 1: HMCCUDEV: Rollo_wohnzimmer_vorn Usage: get Rollo_wohnzimmer_vorn channel {channel-number}[.{datapoint-expr}] [...]
2016.04.04 06:25:39 1: HMCCU: Error URL = http://192.168.178.101:8181/do.exe?r1=dom.GetObject("BidCos-RF.KEQ0879052:1.STATE").Value()
2016.04.04 06:25:39 1: HMCCUDEV: Rollo_wohnzimmer_vorn Execution of CCU script or command failed
2016.04.04 20:37:18 1: HMCCU: Error URL = http://192.168.178.101:8181/do.exe?r1=dom.GetObject("BidCos-RF.KEQ0879052:1.STATE").Value()
2016.04.04 20:37:18 1: HMCCUDEV: Rollo_wohnzimmer_vorn Execution of CCU script or command failed
2016.04.04 20:37:33 1: in SHUTDOWN
2016.04.04 20:37:33 0: Server shutdown
2016.04.04 20:37:33 0: HMCCU: RPC server not running
2016.04.04 20:37:39 1: Including fhem.cfg
2016.04.04 20:37:39 3: telnetPort: port 7072 opened
2016.04.04 20:37:39 3: WEB: port 8083 opened
2016.04.04 20:37:39 3: WEBphone: port 8084 opened
2016.04.04 20:37:39 3: WEBtablet: port 8085 opened
2016.04.04 20:37:39 2: eventTypes: loaded 16 events from ./log/eventTypes.txt
2016.04.04 20:37:40 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
2016.04.04 20:37:45 1: Including ./log/fhem.save
2016.04.04 20:37:45 1: in INITIALIZED
2016.04.04 20:37:45 0: HMCCU: Autostart of RPC server after FHEM initialization in 10 seconds
2016.04.04 20:37:46 1: usb create starting
2016.04.04 20:37:46 3: Probing CUL device /dev/ttyAMA0
2016.04.04 20:37:46 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.04 20:37:46 1: usb create end
2016.04.04 20:37:46 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.04 20:37:46 0: Featurelevel: 5.7
2016.04.04 20:37:46 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 22719)
2016.04.04 20:37:46 3: ipc fronthem:127.0.0.1:54530 (ws): ws alive with pid 22722
2016.04.04 20:37:56 1: PERL WARNING: Can't exec "./FHEM/ccurpcd.pl": Keine Berechtigung at ./FHEM/88_HMCCU.pm line 1359.
Died at ./FHEM/88_HMCCU.pm line 1362.
2016.04.04 20:37:58 0: HMCCU: RPC server started with pid 22733
2016.04.04 20:37:58 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001
2016.04.04 20:37:58 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.04 20:38:08 0: HMCCU: All RPC servers stopped
2016.04.04 20:40:07 1: in ATTR
2016.04.04 20:42:14 1: in ATTR
2016.04.04 20:43:18 1: in ATTR
2016.04.04 20:43:22 1: HMCCUDEV: Rollo_wohnzimmer_vorn Invalid name or address
2016.04.04 20:43:26 1: HMCCUDEV: Rollo_wohnzimmer_vorn Invalid name or address
2016.04.04 20:45:27 1: in DELETEATTR
2016.04.04 20:45:36 1: in SAVE
2016.04.04 20:46:06 1: in DELETEATTR
2016.04.04 20:46:09 1: in DELETED
2016.04.04 20:46:22 0: HMCCU: RPC server not running
2016.04.04 20:46:25 1: in DELETED
2016.04.04 20:47:51 1: in DEFINED
Quantifier follows nothing in regex; marked by <-- HERE in m/* <-- HERE / at ./FHEM/88_HMCCU.pm line 2636.
2016.04.04 20:51:23 1: Including fhem.cfg
2016.04.04 20:51:23 3: telnetPort: port 7072 opened
2016.04.04 20:51:24 3: WEB: port 8083 opened
2016.04.04 20:51:24 3: WEBphone: port 8084 opened
2016.04.04 20:51:24 3: WEBtablet: port 8085 opened
2016.04.04 20:51:25 2: eventTypes: loaded 16 events from ./log/eventTypes.txt
2016.04.04 20:51:37 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
2016.04.04 20:52:02 1: Including ./log/fhem.save
2016.04.04 20:52:02 1: in INITIALIZED
2016.04.04 20:52:02 0: HMCCU: Autostart of RPC server after FHEM initialization in 10 seconds
2016.04.04 20:52:02 1: usb create starting
2016.04.04 20:52:03 3: Probing CUL device /dev/ttyAMA0
2016.04.04 20:52:03 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.04 20:52:03 1: usb create end
2016.04.04 20:52:03 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.04 20:52:03 0: Featurelevel: 5.7
2016.04.04 20:52:03 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 910)
2016.04.04 20:52:03 3: ipc fronthem:127.0.0.1:59342 (ws): ws alive with pid 1041
2016.04.04 20:52:12 1: PERL WARNING: Can't exec "./FHEM/ccurpcd.pl": Keine Berechtigung at ./FHEM/88_HMCCU.pm line 1359.
Died at ./FHEM/88_HMCCU.pm line 1362.
2016.04.04 20:52:14 0: HMCCU: RPC server started with pid 1233
2016.04.04 20:52:14 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001
2016.04.04 20:52:14 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.04 20:52:25 0: HMCCU: All RPC servers stopped
2016.04.04 20:53:46 1: in DELETED
2016.04.04 21:00:04 1: in DEFINED
2016.04.04 21:01:53 1: in ATTR
2016.04.04 21:02:18 1: in SAVE
2016.04.04 21:02:27 1: in SAVE
2016.04.04 21:02:45 1: in ATTR
2016.04.04 21:02:47 1: in SAVE
2016.04.04 21:22:45 1: in ATTR
2016.04.04 21:23:09 1: in ATTR
2016.04.04 21:23:12 1: in SAVE
2016.04.04 21:25:17 1: in ATTR
2016.04.04 21:42:53 1: HMCCU: d_ccu Usage: set d_ccu rpcserver {on|off}
2016.04.04 21:43:27 1: in SHUTDOWN
2016.04.04 21:43:27 0: Server shutdown
2016.04.04 21:43:27 0: HMCCU: RPC server not running
2016.04.04 21:43:33 1: Including fhem.cfg
2016.04.04 21:43:33 3: telnetPort: port 7072 opened
2016.04.04 21:43:34 3: WEB: port 8083 opened
2016.04.04 21:43:34 3: WEBphone: port 8084 opened
2016.04.04 21:43:34 3: WEBtablet: port 8085 opened
2016.04.04 21:43:34 2: eventTypes: loaded 19 events from ./log/eventTypes.txt
2016.04.04 21:43:34 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
2016.04.04 21:43:39 1: Including ./log/fhem.save
2016.04.04 21:43:39 1: in INITIALIZED
2016.04.04 21:43:39 0: HMCCU: Autostart of RPC server after FHEM initialization in 10 seconds
2016.04.04 21:43:39 1: usb create starting
2016.04.04 21:43:39 3: Probing CUL device /dev/ttyAMA0
2016.04.04 21:43:39 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.04 21:43:39 1: usb create end
2016.04.04 21:43:39 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.04 21:43:39 0: Featurelevel: 5.7
2016.04.04 21:43:39 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 2477)
2016.04.04 21:43:39 3: ipc fronthem:127.0.0.1:59601 (ws): ws alive with pid 2479
2016.04.04 21:43:49 1: PERL WARNING: Can't exec "./FHEM/ccurpcd.pl": Keine Berechtigung at ./FHEM/88_HMCCU.pm line 1359.
Died at ./FHEM/88_HMCCU.pm line 1362.
2016.04.04 21:43:51 0: HMCCU: RPC server started with pid 2492
2016.04.04 21:43:51 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001
2016.04.04 21:43:51 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.04 21:44:01 0: HMCCU: All RPC servers stopped
2016.04.04 21:56:47 1: in SHUTDOWN
2016.04.04 21:56:47 0: Server shutdown
2016.04.04 21:56:47 0: HMCCU: RPC server not running
2016.04.04 21:56:53 1: Including fhem.cfg
2016.04.04 21:56:53 3: telnetPort: port 7072 opened
2016.04.04 21:56:54 3: WEB: port 8083 opened
2016.04.04 21:56:54 3: WEBphone: port 8084 opened
2016.04.04 21:56:54 3: WEBtablet: port 8085 opened
2016.04.04 21:56:54 2: eventTypes: loaded 19 events from ./log/eventTypes.txt
2016.04.04 21:56:54 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
2016.04.04 21:56:58 1: Including ./log/fhem.save
2016.04.04 21:56:58 1: in INITIALIZED
2016.04.04 21:56:58 0: HMCCU: Autostart of RPC server after FHEM initialization in 10 seconds
2016.04.04 21:56:58 1: usb create starting
2016.04.04 21:56:58 3: Probing CUL device /dev/ttyAMA0
2016.04.04 21:56:58 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.04 21:56:59 1: usb create end
2016.04.04 21:56:59 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.04 21:56:59 0: Featurelevel: 5.7
2016.04.04 21:56:59 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 2802)
2016.04.04 21:56:59 3: ipc fronthem:127.0.0.1:59635 (ws): ws alive with pid 2803
2016.04.04 21:57:10 0: HMCCU: RPC server started with pid 2811
2016.04.04 21:57:10 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001
Glob not terminated at /opt/fhem/FHEM/RPCQueue.pm line 26.
Compilation failed in require at ./FHEM/ccurpcd.pl line 41.
BEGIN failed--compilation aborted at ./FHEM/ccurpcd.pl line 41.
2016.04.04 21:57:10 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.04 21:57:20 0: HMCCU: All RPC servers stopped
2016.04.05 05:20:10 1: in SHUTDOWN
2016.04.05 05:20:10 0: Server shutdown
2016.04.05 05:20:10 0: HMCCU: RPC server not running
2016.04.05 05:20:16 1: Including fhem.cfg
2016.04.05 05:20:16 3: telnetPort: port 7072 opened
2016.04.05 05:20:16 3: WEB: port 8083 opened
2016.04.05 05:20:16 3: WEBphone: port 8084 opened
2016.04.05 05:20:16 3: WEBtablet: port 8085 opened
2016.04.05 05:20:16 2: eventTypes: loaded 19 events from ./log/eventTypes.txt
2016.04.05 05:20:16 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
2016.04.05 05:20:20 1: Including ./log/fhem.save
2016.04.05 05:20:20 1: in INITIALIZED
2016.04.05 05:20:20 0: HMCCU: Autostart of RPC server after FHEM initialization in 10 seconds
2016.04.05 05:20:20 1: usb create starting
2016.04.05 05:20:20 3: Probing CUL device /dev/ttyAMA0
2016.04.05 05:20:20 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.05 05:20:20 1: usb create end
2016.04.05 05:20:20 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.05 05:20:20 0: Featurelevel: 5.7
2016.04.05 05:20:20 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 11440)
2016.04.05 05:20:20 3: ipc fronthem:127.0.0.1:60599 (ws): ws alive with pid 11441
2016.04.05 05:20:32 0: HMCCU: RPC server started with pid 11453
2016.04.05 05:20:32 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001
Glob not terminated at /opt/fhem/FHEM/RPCQueue.pm line 26.
Compilation failed in require at ./FHEM/ccurpcd.pl line 41.
BEGIN failed--compilation aborted at ./FHEM/ccurpcd.pl line 41.
2016.04.05 05:20:32 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.05 05:20:42 0: HMCCU: All RPC servers stopped
Viele Grüße
Nic
@zap:
heute Nacht stieg der rpcserver grundlos wieder aus. Einzige Fehlermeldung im Log:
2016.04.05 02:40:17 2: HMCCU: Unknown RPC event type [ EV]
:-\
Zitat von: tuppertasse am 05 April 2016, 05:42:01
@zap:
heute Nacht stieg der rpcserver grundlos wieder aus. Einzige Fehlermeldung im Log:
2016.04.05 02:40:17 2: HMCCU: Unknown RPC event type [EV]
Ist der RPC Server wirklich abgebrochen? Dann müsste es noch eine Meldung wie "All RPC servers stopped" geben bzw. mit dem Befehl "get rpcstate" für das HMCCU IO-Device dürften keine Prozesse mehr angezeigt werden.
Diese "unknown RPC event type" Meldung hatte ich auch schon mal, als nachts mein DSL Anschluss resettet wurde. Führt aber normalerweise nicht dazu, dass der RPC server abbricht. Der unbekannte Event wird verworfen und der Server läuft weiter.
Zitat von: Nic0205 am 05 April 2016, 05:26:15
Hallo zusammen,
bin ganz neu in der FHEM Welt und habe auch so meine Spässe mit dem rpc Dämon. Auch bei mir beendet sich
der RPC Prozess automatisch. Zusätzlich wirft er mir jetzt seit gestern aber 21.51 Uhr noch einen Fehler im Log aus, mit dem ich nichts anfangen kann.
Würde mich über Unterstützung sehr freuen.
Zuerst hattest Du wohl die Execute-Rechte für ccurpcd.pl nicht gesetzt, das dann aber nachgeholt. Die letzten Einträge deuten darauf hin, dass beim Laden von RPCQueue.pm ein Fehler auftritt. Ich vermute, da ist beim Download der Datei aus Sourceforge etwas schief gelaufen. Entweder nochmal runterladen oder mal hier die ersten 30 Zeilen reinstellen.
Zitat von: zap am 05 April 2016, 07:20:45
Ist der RPC Server wirklich abgebrochen? Dann müsste es noch eine Meldung wie "All RPC servers stopped" geben bzw. mit dem Befehl "get rpcstate" für das HMCCU IO-Device dürften keine Prozesse mehr angezeigt werden.
Diese "unknown RPC event type" Meldung hatte ich auch schon mal, als nachts mein DSL Anschluss resettet wurde. Führt aber normalerweise nicht dazu, dass der RPC server abbricht. Der unbekannte Event wird verworfen und der Server läuft weiter.
Also, komplette Kommunikation auch mit dem CCU IO device war tot. Prozesse liefen komplett nicht mehr :-\
Bevor ich alles manuell neustartete habe ich mich für ein RPi-reboot entschieden. Momentan hab ich fhem nicht gestartet sondern gestoppt, da ich immer Probleme habe wenn ich fhem starte insb. den rpcserver aktiviere. das mache ich jetzt nur noch "on demand".
Ebenso habe ich überprüft wann mein DSL Anschluss neu gestartet wird und das ist imer so gegen 03:30 nachts. gegengeprüft wann ich eine neue IP bekommen habe --> 03:31 !
Absturz des Prozesses war um 02.40 laut Logfile.
Zitat von: Nic0205 am 05 April 2016, 05:26:15
Hier das Log:
Hi Nic,
sieht nach fehlerhaften Download der Dateien aus. Hatte ich auch. In der tat musst du jedes File anklicken und dann per "save file as" (links ziemlich Weit obene) das File runterladen.
Anscheinend geht mit der Formatierung irgendwas "kaputt".
In den nächsten 1-2 Wochen wird es ein Update geben, das wahlweise ohne den externen RPC-Server auskommt (verwendet dann einen internen Sub-Prozess).
Wenn das bei allen stabil läuft, werfe ich den externen RPC-Server komplett raus. Das ist dann die Voraussetzung, dass das Modul in den offiziellen FHEM Modulzweig reinkommt. Dann ist das manuelle Runterladen Geschichte.
Hi zap,
wenn ich das richtig verstehe und interpretiere, dann warte ich mal auf dieses neue Update. Vielleicht klappt es mit diesem internen Prozess ja besser (da hat man ja alles selber in der Hand).
So lange keine Experimente mehr bei mir :-) hatte schon etwas geschockt heute morgen das Ganze "ertragen müssen" ;D
Und ..... so viel Zeit muss sein ..... wie immer tolle Kommunikation / Hilfestellung von Dir zap :-) DANKE
Hallo zusammen,
der erneute download der Dateien hat mich ein bisschen weiter gebracht.
Der RPC Server läuft jetzt:
05.04.2016 20:54:53 Creating file queue
05.04.2016 20:54:53 Initializing RPC server
05.04.2016 20:54:54 Callback server created listening on port 7401
05.04.2016 20:54:54 Adding callback for events
05.04.2016 20:54:54 Adding callback for new devices
05.04.2016 20:54:54 Adding callback for deleted devices
05.04.2016 20:54:54 Adding callback for modified devices
05.04.2016 20:54:54 Adding callback for replaced devices
05.04.2016 20:54:54 Adding callback for readded devices
05.04.2016 20:54:54 Entering server loop. Use kill -SIGINT 1229 to terminate program
05.04.2016 20:56:41 RPC server terminated
05.04.2016 20:56:41 RPC server received 92 (93) events
Dafür startet FHEM nicht mehr :-(
Das Log sagt folgendes:
2016.04.05 20:58:33 1: Including fhem.cfg
2016.04.05 20:58:33 3: telnetPort: port 7072 opened
2016.04.05 20:58:44 3: WEB: port 8083 opened
2016.04.05 20:58:44 3: WEBphone: port 8084 opened
2016.04.05 20:58:44 3: WEBtablet: port 8085 opened
2016.04.05 20:58:44 2: eventTypes: loaded 11 events from ./log/eventTypes.txt
2016.04.05 20:58:46 2: fronthem: ipc listener opened at port 16384
Undefined subroutine &main::HMCCU_IsValidDevice called at ./FHEM/88_HMCCUDEV.pm line 99, <$fh> line 40.
Könnt Ihr mir noch einmal helfen und mir einen Tip geben, was jetzt schief läuft?
Ich verstehe den Zusammenhang zwischen beiden Logs nicht. Um 20:54 wurde der RPC-Server gestartet, allerdings nicht richtig initialisiert (Meldungen "New Devices" und "ListDevice" fehlen). Um 20:56 wurde er beendet. Hast Du ihn da manuell gestoppt oder hast Du FHEM runtergefahren oder wurde er automatisch beendet?
Zum Fehler beim Starten von FHEM: Kommt daher, dass das Modul HMCCU nicht geladen wurde und ein Gerät mit dem Modul HMCCUDEV angelegt werden soll. Gibt es weiter vorne im Log noch andere Meldungen?
Bitte schicke mir mal die Ausgabe von folgendem Befehl (auszuführen im Verzeichnis, in dem die Datei fhem.cfg liegt):
grep HMCCU fhem.cfg
Idealerweise alle Einträge (defines, attr) aus der fhem.cfg, die sich auf Geräte der Module HMCCU, HMCCUDEV, HMCCUCHN beziehen. Bitte in der Reihenfolge, wie sie in der fhem.cfg auftauchen.
Hallo,
trotz aller Bemühungen, ist es mir nicht gelungen das HMCCU in Fhem zu integrieren, vom Verzeichnis ./contrib habe ich das Modul in ./FHEM kopiert, doch es taucht immer noch nicht in
der Commandref auf, hat jemand eine Lösung für mein Problem?
Fhem Version 5.7
Mach einfach mal ein update von FHEM. Am Ende des Updates baut FHEM die lokale Commandref neu zusammen. Das wird mit dem Perl-Script commandref_join.pl gemacht. Ob und wie man das manuell ausführt, weiß ich nicht.
Jedenfalls nach dem Update hast Du in der lokalen Commandref die Einträge für HMCCU, HMCCUDEV und HMCCUCHN.
Update und darauffolgend shutdown restart habe ich schon durchgeführt, leider ohne Erfolg! Auch der komplette Neustart von Ubuntu brachte keinen Erfolg!
Nochmal zu Deinem vorherigen Post: Du hast das Modul aus ./contrib nach ./FHEM kopiert? Wie kam es denn nach contrib?
Du solltest auf jeden Fall die Dateien aus folgendem Sourceforge Verzeichnis runterladen und im Unterverzeichnis FHEM ablegen:
https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/HMCCU/FHEM/
Dazu klickst Du jede Datei einzeln an und klickst dann links oben auf "Download this file" (88_HMCCU.pm, 88_HMCCUDEV.pm, 88_HMCCUCHN.pm, RPCQueue.pm, ccurpcd.pl)
Wenn Du dann alles im FHEM-Verzeichnis hast, musst Du noch für die Datei die Execute Rechte setzen:
chmod +x ccurpcd.pl
Ok, werde es so wie Du es mir erklärt hast machen! Bin gespannt ob es klappt!
Ich kann bestätigen, dass die Installationsanleitung (gemäß HMCCU_README.txt Kapitel 1.2 HMCCU Requirements & Installation) grundsätzlich funktioniert. Mir sind beim installieren aber folgende Dinge aufgefallen, die zu Fragen meinerseits geführt haben und ggf. in der Anleitung ergänzt werden könnten:
Wie soll ich Module wie LWP::UserAgent, Time::HiRes, RPC::XML::Client installieren? Die Antwort ist zwar durch weitere Recherche ermittelbar, ein Hinweis im Readme wäre aber wünschenswert. Ich habe es dann mit "sudo cpan install LWP::UserAgent" usw. gemacht. Da kommt ein ganzer Haufen an Modulen mit und das dauert, bis man alle benötigten Komponenten installiert hat bestimmt eine gefühlte Ewigkeit.... (Bemerkung: RPC::XML::Server hat bei mir auch gleich den RPC::XML::Client installiert. Also scheint es eine gewisse Empfehlung für die Reihenfolge der zu installierenden Komponenten zu geben...)
Eindeutiger fände ich im Readme folgende Beschreibung:
sudo cpan install Time::HiRes
sudo cpan install LWP::UserAgent
sudo cpan install RPC::XML::Server
sudo cpan install RPC::XML::Client
sudo cpan install IO::Socket::INET
am Besten noch in der Reihenfolge, wie es den meisten Sinn macht. Statt des mich in die Irre führenden Textes :"The FHEM module requires the packages LWP::UserAgent, Time::HiRes, RPC::XML::Client and RPCQueue." Dann braucht man nicht nach einem package "RPCQueue" zu suchen.
Die Sonderstellung des "Moduls RPCQueue": Das ist nicht mit cpan zu installieren, sondern damit ist wohl die Datei "RPCQueue.pm" gemeint. Die ist natürlich nicht mit cpan zu installieren. Es gibt im Readme hierzu folgenden Hinweis, den ich erst spät gesehen habe; "NOTE: RPCQueue.pm is a bug fixed copy of File::Queue and part of the HMCCU installation
package. It's not available via CPAN!".
Leider läuft die Installation bei mir noch nicht, da der rpcserver nicht startet und ich bekomme beim "shutdown restart" von FHEM folgende Meldungen im fhem.log:
2016.04.07 13:24:56 0: Server shutdown
2016.04.07 13:24:57 1: PERL WARNING: Use of uninitialized value $pid in numeric gt (>) at ./FHEM/88_HMCCU.pm line 1431.
2016.04.07 13:24:58 0: HMCCU: RPC server not running
und weiter unten im fhem.log finde ich dann:
2016.04.07 13:28:47 1: HMCCU: 500 Can't connect to meineCCU2-IP-Adresse:8181 (Die Wartezeit für die Verbindung ist abgelaufen)
...
2016.04.07 13:29:28 0: HMCCU: Autostart of RPC server after FHEM initialization in 10 seconds
...
2016.04.07 13:32:17 0: HMCCU: All RPC servers stopped
...
Ein manueller Versuch, den rpcserver mittels "set myCCU2 rpcserver on" zu starten brachte dann folgende Logmeldungen:
2016.04.07 13:37:30 1: HMCCU: myCCU2 Start of RPC server failed
2016.04.07 13:37:42 0: HMCCU: All RPC servers stopped
2016.04.07 13:37:45 1: FHEMWEB SSL/HTTPS error:
2016.04.07 13:39:55 1: Can't connect to CCU port 2001
2016.04.07 13:39:56 1: HMCCU: myCCU2 Start of RPC server failed
2016.04.07 13:40:08 0: HMCCU: All RPC servers stopped
Habe ich noch etwas übersehen? Was kann/muss ich tun?
Sorry für die ungenaue Beschreibung bei den notwendigen Modulen. Die Module LWP::Useragent und IO::Socket::Inet werden von vielen FHEM-Modulen benötigt. Bei denen ist die Wahrscheinlichkeit hoch, dass sie schon installiert sind. Viele User bevorzugen auch die Installation der fertigen Debian-Pakete gegenüber CPAN. Aber ich werde die Anleitung nochmal überarbeiten. Vielleicht komme ich auch endlich mal dazu, den ein oder andern Wiki Artikel zu schreiben (so viele Hobbies, so wenig Zeit ;-)
Zu Deinem Problem: Kannst Du bitte mal den define Befehl von dem HMCCU Device posten? Wenn Du hier den Hostname der CCU statt der IP-Adress verwendest, muss dieser auflösbar sein (entweder per DNS oder mittels Eintrag in /etc/hosts). Ich vermute mal, die CCU ist unter dem angegebenen Namen nicht erreichbar.
Kannst Du aber auch mal per ping testen. Wenn also das define so aussieht
define myCCU HMCCU CCUName
muss folgender Befehl funktionieren:
ping CCUName
Das Warning beim Shutdown ist nicht so tragisch. Das kommt daher, dass vorher kein RPC-Server gelaufen ist. Werde ich in der nächsten Version korrigieren.
Missverständnis: Mein define erfolgt mit der IP-Adresse, nicht mit dem logischen Namen, der über /etc/hosts aufgelöst werden soll....
define myCCU2 HMCCU 192.168.179.16
Anbei die komplette Definition als list myCCU2:
Internals:
Clients :HMCCUDEV:HMCCUCHN:
DEF 192.168.179.16
DelDevices 0
DevCount -1
NAME myCCU2
NR 1232
NTFY_ORDER 50-myCCU2
NewDevices 0
RPCPID 0
RPCPRC none
RPCState stopped
STATE Error
TYPE HMCCU
host 192.168.179.16
Readings:
2016-04-07 13:40:08 rpcstate stopped
2016-04-07 13:39:56 state Error
Hmccu:
eventtime 0
rpccount 0
updatetime 0
Rpc:
Cb2001:
Attributes:
room 07_Settings
rpcserver on
Ping liefert auch vernünftige Werte, siehe beigefügter Screen-Shot.
Nutzt Du wireless Komponenten, Wired oder Homematic-IP ? Der Port 2001 ist für wireless.
Vielleicht hilft es, wenn Du das Attribut rpcport auf 2001 setzt (nur ne Vermutung, wäre ein Bug in HMCCU, aber wer weiß ...)
Außerdem habe ich das nie mit der IP-Adresse als Parameter getestet. Du könntest also mal einen Eintrag für 192.168.179.16 in der /etc/hosts machen und dann den festgelegten Namen im define verwenden.
ZitatIch verstehe den Zusammenhang zwischen beiden Logs nicht. Um 20:54 wurde der RPC-Server gestartet, allerdings nicht richtig initialisiert (Meldungen "New Devices" und "ListDevice" fehlen). Um 20:56 wurde er beendet. Hast Du ihn da manuell gestoppt oder hast Du FHEM runtergefahren oder wurde er automatisch beendet?
Zum Fehler beim Starten von FHEM: Kommt daher, dass das Modul HMCCU nicht geladen wurde und ein Gerät mit dem Modul HMCCUDEV angelegt werden soll. Gibt es weiter vorne im Log noch andere Meldungen?
Bitte schicke mir mal die Ausgabe von folgendem Befehl (auszuführen im Verzeichnis, in dem die Datei fhem.cfg liegt):
Code: [Auswählen]
grep HMCCU fhem.cfg
Idealerweise alle Einträge (defines, attr) aus der fhem.cfg, die sich auf Geräte der Module HMCCU, HMCCUDEV, HMCCUCHN beziehen. Bitte in der Reihenfolge, wie sie in der fhem.cfg auftauchen.
So, jetzt habe ich die fhem.cfg als ausgemistet und alles nochmal neu angelegt - funktioniert jetzt soweit. Aber schon wieder ist das nächste Problem aufgetaucht.
Bei jedem Klick auf "on" oder "off" bekomme ich jetzt die Fehlermeldung
HMCCUDEV: CCU busy Das Log ist zugefüllt von folgendem Eintrag:
2016.04.07 20:10:29 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.07 20:10:34 2: HMCCU: Received no events from CCU since 300 seconds
Habt Ihr eine Idee, woran das liegen könnte?
Grüße
Nic
Danke für die schnelle Hilfe... Geholfen hat nun wirklich:
Definition meiner CCU2 in /etc/hosts
danach in fhem Modifikation des define in "define myCCU2 HMCCU myCCU2" und neues straten des rpcserver über "set myCCU2 rpcserver on".... Dann steht im fhem-logfile:
2016.04.07 20:05:31 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/88_HMCCU.pm line 1724.
2016.04.07 20:05:53 0: HMCCU: RPC server started with pid 14898
2016.04.07 20:05:53 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001
2016.04.07 20:05:53 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
Folgendes Ergebnis bei list myCCU2:
Internals:
Clients :HMCCUDEV:HMCCUCHN:
DEF myCCU2
DelDevices 0
DevCount 79
NAME myCCU2
NR 1232
NTFY_ORDER 50-myCCU2
NewDevices 0
RPCPID 14898
RPCPRC ./FHEM/ccurpcd.pl
RPCState starting
STATE OK
TYPE HMCCU
host myCCU2
Readings:
2016-04-07 20:05:53 rpcstate starting
2016-04-07 20:05:54 state OK
.....
Ist normal, dass "rpcstate" bei "starting" verbleibt? Ich hätte nun "started" erwartet....
Scheint jetzt dank deiner Hilfe zu laufen.... Du könntest nun auch den Fall berücksichtigen, dass man das define mit der IP-Adresse macht.... Nur so als Anregung....
Anscheinend habt Ihr ähnliche Probleme: der RPC Server startet nicht. Ist mir ein Rätsel, wieso das bei manchen Usern problemlos läuft und bei anderen nicht. Schaut Euch bitte mal die Datei ccurpcd_2001.log im FHEM Logverzeichnis an. Da sollten am Ende Einträge wie ListDevices, Newdevices stehen. Außerdem sollten in /tmp Dateien ccuqueue_2001.dat und .idx stehen, die permanent aktualisiert werden.
Wächst die .dat Datei oder bleibt die bei 0 Byte und nur der Zeitstempel wird aktualisiert?
@Achiim: hier findest Du eine funktionierende Config eines anderen Users, der bei HMCCU die IP angibt.
https://forum.fhem.de/index.php/topic,40189.msg429972.html#msg429972
bitte mal unbedingt das Attribut rpcport auf 2001 setzen. Ich vermute, da geht beim Setzen des Defaultwertes etwas schief.
Hier der Ihnalt meiner ccurpcd_2001.log
07.04.2016 20:06:07 Creating file queue
07.04.2016 20:06:07 Initializing RPC server
07.04.2016 20:06:12 Callback server created listening on port 7401
07.04.2016 20:06:12 Adding callback for events
07.04.2016 20:06:12 Adding callback for new devices
07.04.2016 20:06:12 Adding callback for deleted devices
07.04.2016 20:06:12 Adding callback for modified devices
07.04.2016 20:06:12 Adding callback for replaced devices
07.04.2016 20:06:12 Adding callback for readded devices
07.04.2016 20:06:12 Entering server loop. Use kill -SIGINT 14898 to terminate program
07.04.2016 20:23:34 RPC server terminated
07.04.2016 20:23:34 RPC server received 0 (1) events
07.04.2016 20:27:10 Creating file queue
07.04.2016 20:27:10 Initializing RPC server
07.04.2016 20:27:21 Callback server created listening on port 7401
07.04.2016 20:27:21 Adding callback for events
07.04.2016 20:27:21 Adding callback for new devices
07.04.2016 20:27:21 Adding callback for deleted devices
07.04.2016 20:27:21 Adding callback for modified devices
07.04.2016 20:27:21 Adding callback for replaced devices
07.04.2016 20:27:21 Adding callback for readded devices
07.04.2016 20:27:21 Entering server loop. Use kill -SIGINT 15705 to terminate program
07.04.2016 20:37:40 Creating file queue
07.04.2016 20:37:40 Initializing RPC server
07.04.2016 20:37:49 Callback server created listening on port 7401
07.04.2016 20:37:49 Adding callback for events
07.04.2016 20:37:49 Adding callback for new devices
07.04.2016 20:37:49 Adding callback for deleted devices
07.04.2016 20:37:49 Adding callback for modified devices
07.04.2016 20:37:49 Adding callback for replaced devices
07.04.2016 20:37:49 Adding callback for readded devices
07.04.2016 20:37:49 Entering server loop. Use kill -SIGINT 15790 to terminate program
07.04.2016 20:56:25 RPC server terminated
07.04.2016 20:56:25 RPC server received 86 (87) events
Hinweis:
Ich habe fhem zwischen durch neu gestart mit "shutdown restart" und mit "service fhem stop" und anschließendem "service fhem start".....
Der rpcserver läuft noch nicht stabil bei mir....
Und hier der Inhalt von ccuqueue_2001.dat:
EV|MEQ0714259:1|LEVEL|1.000000
EV|MEQ0714259:1|WORKING|0
EV|MEQ0714259:1|DIRECTION|0
EV|MEQ0714259:1|ERROR_REDUCED|0
EV|MEQ0714259:1|ERROR_OVERLOAD|0
EV|MEQ0714259:1|ERROR_OVERHEAT|0
EV|MEQ0714259:1|LEVEL_REAL|1.000000
EV|MEQ0714259:2|LEVEL_REAL|1.000000
EV|MEQ0714259:3|LEVEL_REAL|1.000000
EX|SHUTDOWN|15790|CB2001
Die Datei ccuqueue_2001.idx ist 1Byte lang. Und es steht eine "0" drin.
Ok, die Events von der CCU kommen, aber der Init nicht. Deshalb wechselt der Status nicht von Starting auf Running. Das ist ein Timing Problem. Abhilfe morgen.
Ich habe noch einen Hinweis:
Wenn ich den rpcserver mit "set myCCU2 rpcserver on" starte, erhalte ich folgende fhem-log-Einträge:
2016.04.07 22:34:08 0: HMCCU: RPC server started with pid 16659
2016.04.07 22:34:08 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001
2016.04.07 22:34:08 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.07 22:34:19 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2016.04.07 22:34:22 1: HMCCU: Externally launched RPC server(s) detected. Kill process(es) manually with command kill -SIGINT pid for pids 16659 f=1
2016.04.07 22:34:22 0: HMCCU: RPC server(s) with PID(s) 16636 shut down. f=1
2016.04.07 22:34:23 0: HMCCU: All RPC servers stopped
Das sieht für mich so aus, alsob er den soeben gestarteten Prozess nicht als den eigenen erkennt und sich selbt dann wieder beendet...
Hinweis 1:
Das Attribut rpcport habe ich, wie gewünscht, auf 2001 gesetzt. Keine Änderung des Verhaltens.
Hinweis 2:
Ich habe das define meiner HMCCU wieder zurück auf die IP-Adresse umgestellt. Das klappt auch, bis auf die Tatsache, dass der rpcserver im Status "starting" verbleibt.
Hinweis 3:
Im Zustand "starting" fehlen in der FHEM-Web-Oberfläche dann die get und set Kommandos. Blendest Du die aus, solange der rpcserver nicht gestartet ist? Oder was ist das für ein Phänomen? Siehe screen-shot..
So, sorry, war gestern schon im Bett ;D
Das ist meine ccurpcd_2001.log:
05.04.2016 20:50:54 Creating file queue
05.04.2016 20:50:54 Initializing RPC server
05.04.2016 20:50:54 Callback server created listening on port 7401
05.04.2016 20:50:54 Adding callback for events
05.04.2016 20:50:54 Adding callback for new devices
05.04.2016 20:50:54 Adding callback for deleted devices
05.04.2016 20:50:54 Adding callback for modified devices
05.04.2016 20:50:54 Adding callback for replaced devices
05.04.2016 20:50:54 Adding callback for readded devices
05.04.2016 20:50:54 Entering server loop. Use kill -SIGINT 1233 to terminate program
05.04.2016 20:52:07 RPC server terminated
05.04.2016 20:52:07 RPC server received 90 (91) events
05.04.2016 20:52:36 Creating file queue
05.04.2016 20:52:36 Initializing RPC server
05.04.2016 20:52:36 Callback server created listening on port 7401
05.04.2016 20:52:36 Adding callback for events
05.04.2016 20:52:36 Adding callback for new devices
05.04.2016 20:52:36 Adding callback for deleted devices
05.04.2016 20:52:36 Adding callback for modified devices
05.04.2016 20:52:36 Adding callback for replaced devices
05.04.2016 20:52:36 Adding callback for readded devices
05.04.2016 20:52:36 Entering server loop. Use kill -SIGINT 1509 to terminate program
05.04.2016 20:52:52 RPC server terminated
05.04.2016 20:52:52 RPC server received 0 (1) events
05.04.2016 20:54:53 Creating file queue
05.04.2016 20:54:53 Initializing RPC server
05.04.2016 20:54:54 Callback server created listening on port 7401
05.04.2016 20:54:54 Adding callback for events
05.04.2016 20:54:54 Adding callback for new devices
05.04.2016 20:54:54 Adding callback for deleted devices
05.04.2016 20:54:54 Adding callback for modified devices
05.04.2016 20:54:54 Adding callback for replaced devices
05.04.2016 20:54:54 Adding callback for readded devices
05.04.2016 20:54:54 Entering server loop. Use kill -SIGINT 1229 to terminate program
05.04.2016 20:56:41 RPC server terminated
05.04.2016 20:56:41 RPC server received 92 (93) events
05.04.2016 22:24:56 Creating file queue
05.04.2016 22:24:56 Initializing RPC server
05.04.2016 22:24:56 Callback server created listening on port 7401
05.04.2016 22:24:56 Adding callback for events
05.04.2016 22:24:56 Adding callback for new devices
05.04.2016 22:24:56 Adding callback for deleted devices
05.04.2016 22:24:56 Adding callback for modified devices
05.04.2016 22:24:56 Adding callback for replaced devices
05.04.2016 22:24:56 Adding callback for readded devices
05.04.2016 22:24:56 Entering server loop. Use kill -SIGINT 2165 to terminate program
05.04.2016 22:29:04 Received 250 events from CCU since last check
05.04.2016 22:33:38 RPC server terminated
05.04.2016 22:33:38 RPC server received 490 (490) events
05.04.2016 22:35:03 Creating file queue
05.04.2016 22:35:03 Initializing RPC server
05.04.2016 22:35:03 Callback server created listening on port 7401
05.04.2016 22:35:03 Adding callback for events
05.04.2016 22:35:03 Adding callback for new devices
05.04.2016 22:35:03 Adding callback for deleted devices
05.04.2016 22:35:03 Adding callback for modified devices
05.04.2016 22:35:03 Adding callback for replaced devices
05.04.2016 22:35:03 Adding callback for readded devices
05.04.2016 22:35:03 Entering server loop. Use kill -SIGINT 1241 to terminate program
05.04.2016 22:40:37 Received 250 events from CCU since last check
05.04.2016 22:43:41 RPC server terminated
05.04.2016 22:43:41 RPC server received 427 (427) events
05.04.2016 22:44:04 Creating file queue
05.04.2016 22:44:04 Initializing RPC server
05.04.2016 22:44:04 Callback server created listening on port 7401
05.04.2016 22:44:04 Adding callback for events
05.04.2016 22:44:04 Adding callback for new devices
05.04.2016 22:44:04 Adding callback for deleted devices
05.04.2016 22:44:04 Adding callback for modified devices
05.04.2016 22:44:04 Adding callback for replaced devices
05.04.2016 22:44:04 Adding callback for readded devices
05.04.2016 22:44:04 Entering server loop. Use kill -SIGINT 2073 to terminate program
05.04.2016 22:48:36 Received 250 events from CCU since last check
07.04.2016 20:19:53 RPC server terminated
07.04.2016 20:19:53 RPC server received 32642 (32642) events
07.04.2016 20:20:18 Creating file queue
07.04.2016 20:20:18 Initializing RPC server
07.04.2016 20:20:18 Callback server created listening on port 7401
07.04.2016 20:20:18 Adding callback for events
07.04.2016 20:20:18 Adding callback for new devices
07.04.2016 20:20:18 Adding callback for deleted devices
07.04.2016 20:20:18 Adding callback for modified devices
07.04.2016 20:20:18 Adding callback for replaced devices
07.04.2016 20:20:18 Adding callback for readded devices
07.04.2016 20:20:18 Entering server loop. Use kill -SIGINT 22416 to terminate program
07.04.2016 20:24:51 Received 250 events from CCU since last check
07.04.2016 20:35:49 RPC server terminated
07.04.2016 20:35:49 RPC server received 826 (826) events
07.04.2016 20:37:04 Creating file queue
07.04.2016 20:37:04 Initializing RPC server
07.04.2016 20:37:04 Callback server created listening on port 7401
07.04.2016 20:37:04 Adding callback for events
07.04.2016 20:37:04 Adding callback for new devices
07.04.2016 20:37:04 Adding callback for deleted devices
07.04.2016 20:37:04 Adding callback for modified devices
07.04.2016 20:37:04 Adding callback for replaced devices
07.04.2016 20:37:04 Adding callback for readded devices
07.04.2016 20:37:04 Entering server loop. Use kill -SIGINT 1250 to terminate program
07.04.2016 20:42:17 Received 250 events from CCU since last check
Hier die ccuqueue_2001.dat:
cat ccuqueue_2001.dat
EV|LEQ0002140:2|ACTUAL_TEMPERATURE|18.000000
EV|LEQ0002140:2|ACTUAL_HUMIDITY|52.000000
EV|LEQ0002140:2|SET_TEMPERATURE|4.500000
EV|HEQ0508540:1|TEMPERATURE|19.100000
EV|HEQ0508540:1|HUMIDITY|65
Die ccuqueue_2001.idx: hat bei mir auch 1 byte und enthält auch bei mir nur eine 0.
Hallo Achiim,
ich hatte vor einiger Zeit ähnliche Probleme wie du.
Jedoch ging bei mir auschließlich define HMCCU mit der IP-Adresse und nicht mit dem Namen.
ZitatHinweis 3:
Im Zustand "starting" fehlen in der FHEM-Web-Oberfläche dann die get und set Kommandos. Blendest Du die aus, solange der rpcserver nicht gestartet ist? Oder was ist das für ein Phänomen? Siehe screen-shot..
Solange dein RPCServer nicht ordnungsgemäß läuft, hast du die "get" und "set" Befehle nicht zur Verfügung.
Kleiner Tipp meinerseits: Oftmals hilft folgendes:
- RPC Server Stoppen
- Autostart RPC Server deaktivieren
- FHEM stoppen
- CCU sauber neustarten und warten bis sie wieder voll hochgefahren und die Oberfläche erreichbar ist (kann bei vielen Geräten einige Minuten dauern)
- FHEM starten
- Aus FHEM heraus über dein HMCCU device den RPC Server starten
Viele Grüße
Thomas
@Nic0205, Achiim: Die Ursache für Eure Probleme dürfte die gleiche sein. Kurze Erläuterung zum Start des RPC-Servers:
1. Befehl "set rpcserver on" wird abgesetzt
2. HMCCU startet ccurpcd.pl als separaten Prozess. In diesem Prozess wird ein RPC-Server initialisiert, der auf einem TCP-Port LISTENed und auf Daten der CCU wartet.
3. HMCCU wartet nach Step 2 für 2 Sekunden und regisitriert dann den RPC-Server bei der CCU, damit die weiß, wo sie ihre Events hinschicken soll.
4. Die CCU schickt nun diverse Anfragen an den RPC-Server (u.a. ListDevices). Wenn HMCCU dieses "ListDevices" empfängt, wechselt der Status von "starting" auf "running".
Das Problem tritt vermutlich zwischen Step 2 und 3 auf. Die CCU schickt schon ihre Initilaisierungs-Events, der RPC-Server ist aber noch nicht im LISTENing Mode. Daher geht z.B. "ListDevices" ins Leere und der Status bleibt "running". Die später gesendeten normalen Events für die Geräte kommen dann an.
@Achiim: Die get/set Befehle blende ich aus, so lange der RPCState nicht "stopped" oder "running" ist. Grund: während der Initialisierung der Verbindung ist die CCU stark ausgelastet, sodass Befehle nicht zuverlässig ausgeführt werden. Normalerweise geht der Start aber so schnell, dass das nicht relevant ist.
Die Fehlermeldung "Externally launched ..." besagt, dass noch ein ccurpcd.pl Prozess läuft. Vermutlich hast Du FHEM neu gestartet während der RPCState noch "starting" war. Der Prozess wurde dann nicht korrekt beendet. Ich werde die Stop Prozedur des RPC-Servers so ändern, dass grundsätzlich alle Prozesse gekillt werden.
Noch ein Tipp:
Um einen RPC-Server Prozess (ccurpcd.pl) sauber zu beenden, kann man von der Unix-Kommandozeile aus folgenden Befehl nutzen:
ccurpcd.pl shutdown <ccuhost_or_ip> <port> <pid>
Port ist der RPC-Port (bei wireless 2001), pid die Prozess-ID (siehe Log oder ps ax | grep ccurpcd)
Der Vorteil: Bei dieser Methode wird der RPC-Server bei der CCU sauber abgemeldet. Normalerweise wechselt dann auch der Status in HMCCU wieder von "Starting" auf "Stopped".
Wie gesagt: Die Timing Probleme versuche ich noch heute zu beheben. Ist nur etwas aufwändig, da bei mir schon die neue Version läuft (ist aber noch nicht für die Allgemeinheit tauglich). Muss jetzt erst die alte wieder aktivieren, das Problem beheben, testen ...
Danke für die Unterstützung und wertvollen Tipps. Aber ich komme nicht weiter..
Ich glaube es bestehen zwei Probleme:
Problem 1:
Wie es zap beschreibt, das Timeingproblem beim Start des rpcserver. Hier warte ich ab, ob die von zap angekündigte neue Version eine Besserung bringt.
Problem 2:
Ich habe die von Euch beschriebenen Tipps angewand, aber ich bringe den rpcserver nicht dazu nach dem Start bestehen zu bleiben. Er beendet sich immer wieder (von selbst?)....
Ich habe meine CCU und FHEM wie angeraten neu gestartet, kontrolliert dass kein rpcserver Prozess in Linux läuft und dann über "set myCCU2 rpcserver on" den RPC-Server gestartet und im FHEM-Log sehe ich folgendes:
2016.04.08 11:56:22 0: HMCCU: RPC server started with pid 4246
2016.04.08 11:56:22 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001
2016.04.08 11:56:23 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.08 11:56:42 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2016.04.08 11:56:44 1: HMCCU: Externally launched RPC server(s) detected. Kill process(es) manually with command kill -SIGINT pid for pids 4246 f=1
2016.04.08 11:56:44 0: HMCCU: RPC server(s) with PID(s) 4175 shut down. f=1
2016.04.08 11:56:44 0: HMCCU: All RPC servers stopped
a) der RPC server wird mit der PID 4246 gestartet
b) es wird ein "Externally launched RPC server(s) detected" und zwar mit der PID 4246
Das ist der der gerade gestartete Prozess und kein "Externally launched RPC server"..
Danach werden alle Prozesse wieder beendet und der RPC-Server ist wieder weg.
Hat das auch mit dem Timeing zu tun oder ist das ein anderes Problem?
Ich habe einen ersten Teilerfolg erzielt...
Ich hatte bisher nur meine CCU2 definiert mit: "define myCCU2 HMCCU 192.....". Nachdem ich nun auch ein erstes Device definiert habe mit: "define d_Stehlampe HMCCUDEV MEQ... 1" habe sogar Statuswerte von diesem Gerät erhalten, obwohl definitiv kein rpcserver lief.
Internals:
CFGFN
DEF MEQ0714259 1
IODev myCCU
NAME d_Stehlampe
NR 1392
STATE Error
TYPE HMCCUDEV
ccuaddr MEQ0714259
ccudevstate Active
ccuif BidCos-RF
ccuname HM-LC-Dim1T-Pl-3 MEQ0714259
ccutype HM-LC-Dim1T-Pl-3
channels 4
statevals devstate|on|off
Readings:
2016-04-08 13:36:03 HM-LC-Dim1T-Pl-3_MEQ0714259.1.DIRECTION 0
2016-04-08 13:36:03 HM-LC-Dim1T-Pl-3_MEQ0714259.1.ERROR_OVERHEAT false
2016-04-08 13:36:03 HM-LC-Dim1T-Pl-3_MEQ0714259.1.ERROR_OVERLOAD false
2016-04-08 13:36:03 HM-LC-Dim1T-Pl-3_MEQ0714259.1.ERROR_REDUCED false
2016-04-08 13:36:03 HM-LC-Dim1T-Pl-3_MEQ0714259.1.INHIBIT false
2016-04-08 13:36:03 HM-LC-Dim1T-Pl-3_MEQ0714259.1.LEVEL 0.000000
2016-04-08 13:36:03 HM-LC-Dim1T-Pl-3_MEQ0714259.1.LEVEL_REAL 0.000000
2016-04-08 13:36:03 HM-LC-Dim1T-Pl-3_MEQ0714259.1.WORKING false
2016-04-08 13:36:22 HM-LC-Dim1T-Pl-3_MEQ0714259.2.DIRECTION 0
2016-04-08 13:36:22 HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_OVERHEAT false
2016-04-08 13:36:22 HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_OVERLOAD false
2016-04-08 13:36:22 HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_REDUCED false
2016-04-08 13:36:22 HM-LC-Dim1T-Pl-3_MEQ0714259.2.INHIBIT false
2016-04-08 13:36:22 HM-LC-Dim1T-Pl-3_MEQ0714259.2.LEVEL 0.000000
2016-04-08 13:36:22 HM-LC-Dim1T-Pl-3_MEQ0714259.2.LEVEL_REAL 0.000000
2016-04-08 13:36:22 HM-LC-Dim1T-Pl-3_MEQ0714259.2.WORKING false
2016-04-08 13:43:23 state Error
Attributes:
IODev myCCU
room HMCCU
statechannel 1
statevals on:true,off:false
substitute true:on,false:off,1:on,0:off
Ich habe dann die CCU neu gestartet und den RPS-Server dann mit "set myCCU rpcserver on" gestartet. Dann ist er tatsächlich losgelaufen und oben geblieben. Siehe Logfile-Auszug.
2016.04.08 15:04:52 0: HMCCU: RPC server started with pid 4320
2016.04.08 15:04:52 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001
2016.04.08 15:04:54 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.08 15:05:04 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:10 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:16 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:21 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:27 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:33 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:39 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:45 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:51 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:57 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:03 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:09 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:15 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:21 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:27 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:33 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:39 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:45 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:51 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:56 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:03 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:09 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:15 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:21 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:27 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:33 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:39 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:45 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:51 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:57 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:03 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:09 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:15 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:21 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:27 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:33 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:39 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:45 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:51 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:57 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:03 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:09 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:15 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:21 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:27 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:33 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:39 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:44 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:50 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:56 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:02 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:08 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:14 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:20 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:26 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:38 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:44 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:50 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:56 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:01 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:07 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:14 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:20 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:26 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:33 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:39 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:46 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:52 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:58 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:12:03 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:12:09 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:12:14 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:12:20 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:12:26 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:12:32 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:12:38 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2016.04.08 15:12:39 0: HMCCU: RPC server(s) with PID(s) 4320 shut down. f=1
2016.04.08 15:12:39 0: HMCCU: All RPC servers stopped
Der Status des RPC-Server in "starting" verbleibt, habe ich dann den rpcserver mit "ccurpcd.pl shutdown <ccuhost_or_ip> <port> <pid>" beendet. Das sieht man auch um Log "...4320 shut down..."
Kann das sein, dass ohne die Definition eines Devices der RPC-Server nicht läuft?
Die Meldung mit den 300s kommt alle 6 Sekunden. Hier könnte der Code auch noch optimiert werden.
Hallo RPC Prozess Opfer!
Als Attachment eine neue Version der Datei 88_HMCCU.pm. Bitte im ./FHEM Verzeichnis speichern. Ich stelle die erst mal nicht in Sourceforge bereit. Erst wenn ich weiß, dass Eure Probleme damit behoben sind.
Funktional hat sich nichts geändert. Lediglich das Starten des RPC-Servers habe ich zeitlich entzerrt.
Bitte vor Tests mit der neuen Version aufräumen, soll heißen: Prüfen, dass alle ccurpcd Prozesse beendet sind. Falls noch welche laufen, diese wie weiter oben beschrieben beenden, damit die Schnittstelle sauber in der CCU deregistriert wird.
Dann die neue Version installieren und FHEM durchstarten. Darauf achten, dass das Attribut rpcserver auf 'off' steht und den RPC Server erst mal manuell starten.
So sieht es aus (im FHEM Log), wenn der RPC-Server (in diesem Fall sind es 2 wg. wireless und HM-IP) sauber gestartet wird:
2016.04.08 15:35:12 0: HMCCU: RPC server started with pid 18064
2016.04.08 15:35:13 0: HMCCU: RPC server started with pid 18065
2016.04.08 15:35:20 1: HMCCU: Registering callback http://192.168.1.12:7401/fh2001 with ID CB2001 at http://homematic:2001/
2016.04.08 15:35:21 1: HMCCU: RPC callback with URL http://192.168.1.12:7401/fh2001 initialized
2016.04.08 15:35:21 1: HMCCU: Registering callback http://192.168.1.12:7410/fh2010 with ID CB2010 at http://homematic:2010/
2016.04.08 15:35:21 1: HMCCU: RPC callback with URL http://192.168.1.12:7410/fh2010 initialized
2016.04.08 15:35:26 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.08 15:35:26 0: HMCCU: Received IN event. RPC server CB2010 initialized.
Entscheidend ist "Received IN event ..."
Das Ganze im ccurpcd_2001.log:
08.04.2016 15:35:13 Creating file queue
08.04.2016 15:35:13 Initializing RPC server
08.04.2016 15:35:13 Callback server created listening on port 7401
08.04.2016 15:35:13 Adding callback for events
08.04.2016 15:35:13 Adding callback for new devices
08.04.2016 15:35:13 Adding callback for deleted devices
08.04.2016 15:35:13 Adding callback for modified devices
08.04.2016 15:35:13 Adding callback for replaced devices
08.04.2016 15:35:13 Adding callback for readded devices
08.04.2016 15:35:13 Entering server loop. Use kill -SIGINT 18064 to terminate program
08.04.2016 15:35:20 ListDevices CB2001. Sending init to HMCCU
08.04.2016 15:35:23 NewDevice: received 228 device specifications
Entscheidend hier "ListDevices ... Sendind init to HMCCU"
Alles wird gut!
Leider noch keine entscheidende Änderung:
Ich habe das neue Modul getestet und den RPCserver manuell gestartet, wie gewünscht
2016.04.08 17:33:10 0: HMCCU: RPC server started with pid 7390
2016.04.08 17:33:17 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001 at http://192.168.178.16:2001/
2016.04.08 17:33:18 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.08 17:37:39 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2016.04.08 17:37:39 0: HMCCU: RPC server(s) with PID(s) 7390 shut down. f=1
2016.04.08 17:37:40 0: HMCCU: All RPC servers stopped
Da sich nach 4 Minuten Warten nichts gezeigt hat, habe ich den RPSserver kontrolliert beendet, damit mein HMCCU auf "stopped" geht.
Folgendes habe ich in der ccu...2001.log:
08.04.2016 17:33:24 Creating file queue
08.04.2016 17:33:24 Initializing RPC server
08.04.2016 17:33:28 Callback server created listening on port 7401
08.04.2016 17:33:28 Adding callback for events
08.04.2016 17:33:28 Adding callback for new devices
08.04.2016 17:33:28 Adding callback for deleted devices
08.04.2016 17:33:28 Adding callback for modified devices
08.04.2016 17:33:28 Adding callback for replaced devices
08.04.2016 17:33:28 Adding callback for readded devices
08.04.2016 17:33:28 Entering server loop. Use kill -SIGINT 7390 to terminate program
08.04.2016 17:37:38 RPC server terminated
08.04.2016 17:37:38 RPC server received 0 (1) events
Dann habe ich die CCU neu gestartet und den Test wiederholt:
2016.04.08 17:46:04 0: HMCCU: RPC server started with pid 7614
2016.04.08 17:46:11 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001 at http://192.168.178.16:2001/
2016.04.08 17:46:11 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.08 17:46:16 2: HMCCU: Received no events from CCU since 300 seconds
Und dann nichts mehr... (An dieser Stelle kann positiv hervorgehoben werden, dass die Logmeldung mit den 300s nur einmal kommt.... :) obwohl, seit dem Start des Prozesses sind erst 12s vergangen, da wundert sich der Leihe wie man da seit 300s auf etwas warten kann ??? ???)
In der ccu...2001.log:
08.04.2016 17:46:20 Creating file queue
08.04.2016 17:46:20 Initializing RPC server
08.04.2016 17:46:23 Callback server created listening on port 7401
08.04.2016 17:46:23 Adding callback for events
08.04.2016 17:46:23 Adding callback for new devices
08.04.2016 17:46:23 Adding callback for deleted devices
08.04.2016 17:46:23 Adding callback for modified devices
08.04.2016 17:46:23 Adding callback for replaced devices
08.04.2016 17:46:23 Adding callback for readded devices
08.04.2016 17:46:23 Entering server loop. Use kill -SIGINT 7614 to terminate program
Ich erhalte kein "IN Event" von der CCU auf die Intiialisierung...
Hinweis:
Meine CCU hat den Firmwarestand: 2.17.15
Die ccuqueue_2001.dat ist bei mir jetzt leer.
(Ich fühle mich (noch) nicht als Opfer. Die Idee mit dem Modul HMCCU finde ich genial, wenn's denn mal läuft.... 8))
BTW: :) :) Was sind eigentlich readded devices? Sterben die nach dem Lesen? Das ist dem "ccurpcd_2001.log" zu entnehmen..."Adding callback for readded devices" ;) ;) ;D
Die Zeitstempel in der ccurpcd_2001.log liegen immer nach denen im FHEM-Log. Das ist gelinde gesagt "strange". So kann das nicht funktionieren.
Die Meldung "Entering server loop" im ccurpcd_2001.log muss zeitlich vor der Meldung "Registering callback ..." im FHEM-Log liegen. Sonst lauscht der RPC-Server noch nicht, wenn die CCU schon anfängt, Daten zu schicken. Dann geht der IN verloren.
Bei Dir wird der RPC-Server Prozess um 17:33:10 geforkt. Um 17:33:17 beginnt die Registrierung an der CCU. Die erste Meldung von dem gestarteten Prozess im ccurpcd_2001.log ist aber erst von 17:33:24 und der Server-Loop startet dann 4 Sekunden später. Nun frage ich mich: Was macht Deine Kiste 14 Sekunden lang?
Wenn Du das mal mit meinen Logs vergleichst: Da liegen die Meldungen in ccurpcd_2001.log VOR den Registrierungsmeldungen im FHEM Log.
Alleine von "Creating File Queue" bis "Entering Server Loop" vergehen bei Dir 4 Sekunden, während das bei mir 0 Sekunden dauert.
Also immer noch Timing Probleme. Ist Dein Server so ausgelastet? Schreib mal ein paar Infos zu Deinem System (Hardware, Betriebssystem).
Das ist ein pi 2 B mit debian auf dem FHEM mit allen Komponenten die in meiner Fusszeile zu finden sind läuft... Anbei ein aktueller Screen-Shot der TOP-Prozesse..
:)
Wenn ich's richtig verstanden habe, dann muss FHEM mit dem HMCCU Modul solange warten, bis sich der RPCserver in der Event-Loop befindet.... Das kann nicht Zuverlässig mit einer Wartezeit von x Sekunden gelöst werden. Hierzu solltest Du ein Signal vom RPC-Server an das FHEM-Modul HMCCU senden. Erst wenn dieses Signal da ist, ist das System "betriebsbereit"....
Hallo zap,
bei mir sieht es sehr ähnlich aus. Ich habe die gleiche Hardwarebasis (Pi 2B) und folgende Logs:
rpc-log
08.04.2016 19:14:42 RPC server terminated
08.04.2016 19:14:42 RPC server received 41920 (41920) events
08.04.2016 19:32:55 Creating file queue
08.04.2016 19:32:55 Initializing RPC server
08.04.2016 19:32:56 Callback server created listening on port 7401
08.04.2016 19:32:56 Adding callback for events
08.04.2016 19:32:56 Adding callback for new devices
08.04.2016 19:32:56 Adding callback for deleted devices
08.04.2016 19:32:56 Adding callback for modified devices
08.04.2016 19:32:56 Adding callback for replaced devices
08.04.2016 19:32:56 Adding callback for readded devices
08.04.2016 19:32:56 Entering server loop. Use kill -SIGINT 1236 to terminate program
08.04.2016 19:32:59 ListDevices
08.04.2016 19:33:02 NewDevice: received 220 device specifications
fhem log
2016.04.08 19:29:34 1: in SHUTDOWN
2016.04.08 19:29:34 0: Server shutdown
2016.04.08 19:29:35 0: HMCCU: RPC server not running
2016.04.08 19:29:40 1: Including fhem.cfg
2016.04.08 19:29:40 3: telnetPort: port 7072 opened
2016.04.08 19:29:41 3: WEB: port 8083 opened
2016.04.08 19:29:41 3: WEBphone: port 8084 opened
2016.04.08 19:29:41 3: WEBtablet: port 8085 opened
2016.04.08 19:29:41 2: eventTypes: loaded 17 events from ./log/eventTypes.txt
2016.04.08 19:29:41 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2827, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2827, <$fh> line 40.
2016.04.08 19:29:45 1: Including ./log/fhem.save
2016.04.08 19:29:45 1: statefile: Please define CCU2 first
2016.04.08 19:29:45 1: in INITIALIZED
2016.04.08 19:29:45 1: usb create starting
2016.04.08 19:29:45 3: Probing CUL device /dev/ttyAMA0
2016.04.08 19:29:45 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.08 19:29:45 1: usb create end
2016.04.08 19:29:45 2: Error messages while initializing FHEM: statefile: Please define CCU2 first
2016.04.08 19:29:45 0: Featurelevel: 5.7
2016.04.08 19:29:45 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 1551)
2016.04.08 19:29:45 3: ipc fronthem:127.0.0.1:33426 (ws): ws alive with pid 1552
2016.04.08 19:30:19 1: in ATTR
2016.04.08 19:31:01 1: in SAVE
2016.04.08 19:31:23 1: in SHUTDOWN
2016.04.08 19:31:23 0: Server shutdown
2016.04.08 19:31:23 0: HMCCU: RPC server not running
2016.04.08 19:32:00 1: Including fhem.cfg
2016.04.08 19:32:00 3: telnetPort: port 7072 opened
2016.04.08 19:32:02 3: WEB: port 8083 opened
2016.04.08 19:32:02 3: WEBphone: port 8084 opened
2016.04.08 19:32:02 3: WEBtablet: port 8085 opened
2016.04.08 19:32:13 2: eventTypes: loaded 19 events from ./log/eventTypes.txt
2016.04.08 19:32:15 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 34.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 34.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2827, <$fh> line 34.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2827, <$fh> line 34.
2016.04.08 19:32:39 1: Including ./log/fhem.save
2016.04.08 19:32:39 1: in INITIALIZED
2016.04.08 19:32:39 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.08 19:32:39 1: usb create starting
2016.04.08 19:32:40 3: Probing CUL device /dev/ttyAMA0
2016.04.08 19:32:40 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.08 19:32:40 1: usb create end
2016.04.08 19:32:40 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.08 19:32:40 0: Featurelevel: 5.7
2016.04.08 19:32:40 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 897)
2016.04.08 19:32:40 3: ipc fronthem:127.0.0.1:50723 (ws): ws alive with pid 1049
2016.04.08 19:32:52 0: HMCCU: RPC server started with pid 1236
2016.04.08 19:32:59 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.08 19:33:00 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.08 19:33:05 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.08 19:44:02 2: HMCCU: Received no events from CCU since 300 secondsns
ich habe ein HMDEV Gerät angelegt und den Status (ist ein Schalter) ein paar mal mit set kueche_wandleuchte on set kueche_wandleuchte off an und aus gemacht. aber der rpc scheint davon nichts mitzubekommen, bzw. scheint er nicht mehr richtig zu laufen. das log sieht dann so aus:
2016.04.08 20:40:10 1: HMCCUDEV: Kueche_wandleuchte Execution of CCU script or command failed
2016.04.08 20:40:14 1: HMCCUDEV: Kueche_wandleuchte Execution of CCU script or command failed
2016.04.08 20:40:18 1: HMCCUDEV: Kueche_wandleuchte Execution of CCU script or command failed
2016.04.08 20:40:28 1: HMCCUDEV: Kueche_wandleuchte Execution of CCU script or command failed
@Nico0205: Bei Dir läuft der RPC Server korrekt. Es scheint auch nicht an der Aktualisierung zu scheitern sondern schon beim Schalten selbst. Bitte poste mal die Definiton von der Lampe (list kueche_wandleuchte). Außerdem bitte noch Name und Adresse des zugehörigen Devices in der CCU.
@Achiim: Habe auch einen Raspi 2b. Auf meinem läuft neben FHEM noch ein Apache Webserver und ein Meteohub Wettestations Server. Meine CPU Last liegt bei <2%, die Load bei <0.3 und das bei ca. 150 Tasks.
Die Idee mit der Signalisierung kurz vor dem Serverloop hatte ich schon mal in einer der ersten Versionen eingebaut, das aber wieder als überflüssig verworfen, weil ich der Meinung war, dass 2-3 Sekunden Warten reichen sollte um einen Perl-Prozess zu starten. Scheinbar doch sinnvoll, kommt also wieder rein.
Trotzdem würde ich mir an Deiner Stelle mal Gedanken machen, was Deinen Rechner ausbremst. 4 Sekunden für die Ausführung von nicht mal 50 Zeilen Perlcode sind schon eine Hausnummer.
UPDATE: Gerade gesehen, dass Du anscheinend einen Desktop bzw. X-Server laufen hast. Das erklärt die Last. Habe ich mir gespart.
Hallo zap,
so ist die Definition:
Internals:
DEF KEQ0170945 1
IODev d_ccu
NAME Kueche_wandleuchte
NR 24
STATE false
TYPE HMCCUDEV
ccuaddr KEQ0170945
ccudevstate Active
ccuif BidCos-RF
ccuname K�che Wandleuchten
ccutype HM-LC-Sw1PBU-FM
channels 2
statevals devstate|on|off
Readings:
2016-04-08 21:50:54 K_che_Wandleuchten.0.AES_KEY 0
2016-04-08 21:50:54 K_che_Wandleuchten.0.CONFIG_PENDING false
2016-04-08 21:50:54 K_che_Wandleuchten.0.DEVICE_IN_BOOTLOADER false
2016-04-08 21:50:54 K_che_Wandleuchten.0.DUTYCYCLE false
2016-04-08 21:50:54 K_che_Wandleuchten.0.LOWBAT false
2016-04-08 21:50:54 K_che_Wandleuchten.0.RSSI_DEVICE 1
2016-04-08 21:50:54 K_che_Wandleuchten.0.RSSI_PEER 177
2016-04-08 21:50:54 K_che_Wandleuchten.0.STICKY_UNREACH false
2016-04-08 21:50:54 K_che_Wandleuchten.0.UNREACH false
2016-04-08 21:50:54 K_che_Wandleuchten.0.UPDATE_PENDING false
2016-04-08 21:50:54 K_che_Wandleuchten.INHIBIT false
2016-04-08 21:50:54 K_che_Wandleuchten.INSTALL_TEST N/A
2016-04-08 21:50:54 K_che_Wandleuchten.ON_TIME N/A
2016-04-08 21:50:54 K_che_Wandleuchten.STATE false
2016-04-08 21:50:54 K_che_Wandleuchten.WORKING false
2016-04-08 21:50:54 state false
Attributes:
IODev d_ccu
statechannel 1
statevals on:true,off:false
ERFOLG
Nachdem ich auf einen PI3 umgezogen bin und den Test wiederholt habe, startet der RPCserver und geht in den Status "Running". Siehe Screen-Shot. Es ist spät geworden... Morgen mehr...
zum Stand der Dinge:
- RPCserver läuft grundsätzlich (leider nur auf dem "schnelleren" PI3 und das "Timing-Problem" beim Start sollte noch gelöst werden)
- HMCCU-Device geht auf Error
Folgende Hinweise:
a) im FHEM Log finde ichSmartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2827.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2827.
b) Bug?wenn man HMCCU definiert, dann werden die set/get Kommandos in FHEM sichtbar. Leider fehlt dann bei "set myCCU2 rpcserver" der Parameter "on" bzw. "off". Die Liste it leer. Erst wenn man das Attribut rpcport setzt (ich habe wie gewünscht auf 2001 gesetzt") weden die Parameter "on" bzw. "off" sichtbar.
c) Betriebsbereitschaft nach dem StartvorgangAuch wenn ich jetzt auf dem PI3 den RPCserver starten konnte, stehe ich zum Test der "Signalisierung" auf dem PI2 zur Verfügung, falls Du eine neue Version hast.
d) HMCCU Device geht auf ErrorJetzt habe ich den Zustand ähnlich wie Nic0205. Meine d_Stehlampe geht auf "Error" sobald ich den Status mit "get d_Stehlampe devstat" abfrage. Hier die Definiton:
Internals:
DEF MEQ0714259 1
IODev myCCU2
NAME d_Stehlampe
NR 64
STATE Initialized
TYPE HMCCUDEV
ccuaddr MEQ0714259
ccudevstate Active
ccuif BidCos-RF
ccuname HM-LC-Dim1T-Pl-3 MEQ0714259
ccutype HM-LC-Dim1T-Pl-3
channels 4
statevals devstate|on|off
Readings:
2016-04-09 03:14:13 HM-LC-Dim1T-Pl-3_MEQ0714259.1.DIRECTION off
2016-04-09 03:14:13 HM-LC-Dim1T-Pl-3_MEQ0714259.1.ERROR_OVERHEAT off
2016-04-09 03:14:13 HM-LC-Dim1T-Pl-3_MEQ0714259.1.ERROR_OVERLOAD off
2016-04-09 03:14:13 HM-LC-Dim1T-Pl-3_MEQ0714259.1.ERROR_REDUCED off
2016-04-09 03:14:13 HM-LC-Dim1T-Pl-3_MEQ0714259.1.LEVEL 0.000000
2016-04-09 03:14:13 HM-LC-Dim1T-Pl-3_MEQ0714259.1.LEVEL_REAL 0.000000
2016-04-09 03:14:13 HM-LC-Dim1T-Pl-3_MEQ0714259.1.WORKING off
2016-04-09 01:28:53 HM-LC-Dim1T-Pl-3_MEQ0714259.2.DIRECTION 0
2016-04-09 01:28:53 HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_OVERHEAT 0
2016-04-09 01:28:53 HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_OVERLOAD 0
2016-04-09 01:28:53 HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_REDUCED 0
2016-04-09 01:28:53 HM-LC-Dim1T-Pl-3_MEQ0714259.2.LEVEL 0.000000
2016-04-09 03:14:13 HM-LC-Dim1T-Pl-3_MEQ0714259.2.LEVEL_REAL 0.000000
2016-04-09 01:28:53 HM-LC-Dim1T-Pl-3_MEQ0714259.2.WORKING 0
2016-04-09 01:28:53 HM-LC-Dim1T-Pl-3_MEQ0714259.3.DIRECTION 0
2016-04-09 01:28:53 HM-LC-Dim1T-Pl-3_MEQ0714259.3.ERROR_OVERHEAT 0
2016-04-09 01:28:53 HM-LC-Dim1T-Pl-3_MEQ0714259.3.ERROR_OVERLOAD 0
2016-04-09 01:28:53 HM-LC-Dim1T-Pl-3_MEQ0714259.3.ERROR_REDUCED 0
2016-04-09 01:28:53 HM-LC-Dim1T-Pl-3_MEQ0714259.3.LEVEL 0.000000
2016-04-09 03:14:13 HM-LC-Dim1T-Pl-3_MEQ0714259.3.LEVEL_REAL 0.000000
2016-04-09 01:28:53 HM-LC-Dim1T-Pl-3_MEQ0714259.3.WORKING 0
2016-04-09 09:35:06 state Initialized
Attributes:
IODev myCCU2
statechannel 1
statevals on:true,off:false
substitute true:on,false:off,1:on,0:off
Im Log steht dann:
2016.04.09 09:48:41 1: HMCCU: Error URL = http://192.168.178.16:8181/do.exe?r1=dom.GetObject("BidCos-RF.MEQ0714259:1.STATE").Value()
2016.04.09 09:48:41 1: HMCCUDEV: d_Stehlampe Execution of CCU script or command failed
Zitat von: Nic0205 am 08 April 2016, 22:04:57
Hallo zap,
so ist die Definition:
ccuname K�che Wandleuchten
Das Problem ist der Umlaut im CCU Devicename. Dieser wird zwischen CCU und FHEM falsch gemapt. Einzige Abhilfe derzeit: Device in der CCU (auch die Kanäle) umbenennen. Das Problem haben andere auch, allerdings habe ich dafür noch keine echte Lösung, da je nach verwendeter Umgebung für FHEM das Mapping anders sein muss. Nach der Umbenennung in der CCU einmalig "get d_ccu devicelist" ausführen.
Noch ein Tipp: Du solltest noch das Attribut substitute für das Device setzen:
attr Kueche_wandleuchte substitute STATE!true:on,false:off,1:on,0:off
Dann werden auch die Werte, die von der CCU kommen entsprechend übersetzt.
Zitat von: Achiim am 09 April 2016, 09:50:12
Das "Timing-Problem" beim Start sollte noch gelöst werden
Ist in Arbeit.
Zitat
im FHEM Log finde ich
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191.
Warnings wg. Verwendung des Perl Operators ~~. Kann ignoriert werden. In der nächsten Version verzichte ich darauf.
Zitat
wenn man HMCCU definiert, dann werden die set/get Kommandos in FHEM sichtbar. Leider fehlt dann bei "set myCCU2 rpcserver" der Parameter "on" bzw. "off". Die Liste it leer. Erst wenn man das Attribut rpcport setzt (ich habe wie gewünscht auf 2001 gesetzt") weden die Parameter "on" bzw. "off" sichtbar.
Ist bei mir nicht so. Hast Du mal die Webseite von FHEM refreshed? In der Set-Funktion wird bei ? der ganz normale String mit allen möglichen Befehlen zurückgegeben.
Zitat
Auch wenn ich jetzt auf dem PI3 den RPCserver starten konnte, stehe ich zum Test der "Signalisierung" auf dem PI2 zur Verfügung, falls Du eine neue Version hast.
Kommt.
Zitat
Jetzt habe ich den Zustand ähnlich wie Nic0205. Meine d_Stehlampe geht auf "Error" sobald ich den Status mit "get d_Stehlampe devstat" abfrage. Hier die Definiton:
Attributes:
IODev myCCU2
statechannel 1
statevals on:true,off:false
substitute true:on,false:off,1:on,0:off
Im Log steht dann:
2016.04.09 09:48:41 1: HMCCU: Error URL = http://192.168.178.16:8181/do.exe?r1=dom.GetObject("BidCos-RF.MEQ0714259:1.STATE").Value()
2016.04.09 09:48:41 1: HMCCUDEV: d_Stehlampe Execution of CCU script or command failed
Problem ist, dass "set devstate" per Default versucht, den Datenpunkt STATE zu setzen bzw. zu lesen. Der fehlt aber bei einem Dimmer. Ich habe zwar keinen, vermute aber, dass der Datenpunkt LEVEL passen würde und hier 0 = aus und 1.0 = an ist. Wenn das so ist, kannst Du mal folgendes probiere:
attr d_Stehlampe statedatapoint LEVEL
attr d_Stehlampe statevals on:1.0,off:0.0
Dann sollte "get devstate" funktionieren. Alternativ geht "get/set datapoint 1.LEVEL" auch ohne die Attribute oben.
Für die dynamische Einstellung
attr d_Stehlampe controldatapoint 1.LEVEL
attr d_Stehlampe webCmd control
attr d_Stehlampe widgetOverride control:slider,0.0,0.1,1.0
Wobei ich mir bei der slider Syntax nicht ganz sicher bin. Ich glaube, bei Nicht-Ganzzahlen muss man da noch was beachten.
Neue Testversion von 88_HMCCU.pm und ccurpcd.pl hängt an. Die Ausführung auf 2 Raspis gleichzeitig wird vermutlich funktionieren, aber die CCU ziemlich belasten.
Um Seiteneffekte auszuschließen, würde ich es nur auf einem starten.
Danke für deine Hilfe. Mit der Definition des "statedatapoint" hat es geklappt. Das sieht bei mir jetz so aus
Internals:
DEF MEQ0714259 1
IODev myCCU2
NAME d_Stehlampe
NR 64
STATE 1.000000
TYPE HMCCUDEV
ccuaddr MEQ0714259
ccudevstate Active
ccuif BidCos-RF
ccuname HM-LC-Dim1T-Pl-3 MEQ0714259
ccutype HM-LC-Dim1T-Pl-3
channels 4
statevals devstate|on|off
Readings:
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.0.AES_KEY closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.0.CONFIG_PENDING closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.0.DEVICE_IN_BOOTLOADER closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.0.DUTYCYCLE closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.0.RSSI_DEVICE open
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.0.RSSI_PEER 44
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.0.STICKY_UNREACH closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.0.UNREACH closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.0.UPDATE_PENDING closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.2.DIRECTION closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_OVERHEAT closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_OVERLOAD closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_REDUCED closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.2.INHIBIT closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.2.INSTALL_TEST N/A
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.2.LEVEL 0.000000
2016-04-09 15:12:35 HM-LC-Dim1T-Pl-3_MEQ0714259.2.LEVEL_REAL 1.000000
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.2.OLD_LEVEL N/A
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.2.ON_TIME N/A
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.2.RAMP_STOP N/A
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.2.RAMP_TIME N/A
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.2.WORKING closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.3.DIRECTION closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.3.ERROR_OVERHEAT closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.3.ERROR_OVERLOAD closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.3.ERROR_REDUCED closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.3.INHIBIT closed
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.3.INSTALL_TEST N/A
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.3.LEVEL 0.000000
2016-04-09 15:12:35 HM-LC-Dim1T-Pl-3_MEQ0714259.3.LEVEL_REAL 1.000000
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.3.OLD_LEVEL N/A
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.3.ON_TIME N/A
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.3.RAMP_STOP N/A
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.3.RAMP_TIME N/A
2016-04-09 15:00:36 HM-LC-Dim1T-Pl-3_MEQ0714259.3.WORKING closed
2016-04-09 15:12:35 WZ-Stehlampe-1.DIRECTION closed
2016-04-09 15:12:35 WZ-Stehlampe-1.ERROR_OVERHEAT closed
2016-04-09 15:12:35 WZ-Stehlampe-1.ERROR_OVERLOAD closed
2016-04-09 15:12:35 WZ-Stehlampe-1.ERROR_REDUCED closed
2016-04-09 15:00:36 WZ-Stehlampe-1.INHIBIT closed
2016-04-09 15:00:36 WZ-Stehlampe-1.INSTALL_TEST N/A
2016-04-09 15:12:35 WZ-Stehlampe-1.LEVEL 1.000000
2016-04-09 15:12:35 WZ-Stehlampe-1.LEVEL_REAL 1.000000
2016-04-09 15:00:36 WZ-Stehlampe-1.OLD_LEVEL N/A
2016-04-09 15:00:36 WZ-Stehlampe-1.ON_TIME N/A
2016-04-09 15:00:36 WZ-Stehlampe-1.RAMP_STOP N/A
2016-04-09 15:00:36 WZ-Stehlampe-1.RAMP_TIME N/A
2016-04-09 15:12:35 WZ-Stehlampe-1.WORKING closed
2016-04-09 15:12:35 state 1.000000
Attributes:
IODev myCCU2
statechannel 1
statedatapoint LEVEL
statevals on:1.0,off:0.0
substitute STATE!(0|false):off,(1|true):on;LOWBAT!(0|false):no,(1|true):yes;(0|false):closed,(1|true):open
Nunja, die Definition des "substitude" habe ich auch von einem Beispiel übernommen. Das erscheint mir für den Dimmer auch nicht unbedingt zu passen.
Hinweis:
Als weitere Optimierung habe ich nun auch die RAM-Disk für /tmp auf dem PI3 eingerichtet....
Jetzt schau ich erst mal Bundesliga und werden deine neuen Module nachher mal testen.
Mit dem Substitute musst Du mal rumtesten. Vielleicht so:
LEVEL!1.000000:on,0.000000:off
Du kannst auch stripnumbers auf 1 setzen, dann schneidet er alles nach der 1. Nachkommastelle ab.
Ich empfehle auch, eventonchangereading auf .* zu setzen, da sonst sehr viele Events generiert werden.
Hallo zap,
ich sage mal fast... ::)
Ich habe den Test nur auf dem PI2 gemacht.
2016.04.09 21:43:17 0: HMCCU: RPC server started with pid 2556
2016.04.09 21:43:25 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001 at http://192.168.178.16:2001/
2016.04.09 21:43:25 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.09 21:43:37 2: HMCCU: Unknown RPC event type [SL]
Leider bleibt der RPCserver wieder im Status "starting" hängen, aber ein Event vom typ SL habe ich bisher noch nicht gesehen...
Hinweise:
ccuqueue_2001.dat ist leer
ccuqueue_2001.idx ist 1 Byte gross
Es hat etwas gedauert, bis ich den Test machen konnte. Sorry... aber ich musste erst ein bisschen mit der funktionierenden Installation auf dem PI3 "spielen" und habe mir die tollen Möglichkeiten angeschaut und teilweise vorgestellt, was ich damit alles machen will.... Da ist das Kopfkino bei mir angesprungen.... ;D
Ich habe es gleich nochmal versucht. Das Verhalten scheint reproduzierbar.
Verständnisfrage: Das Ergebnis von get d_Stehlampe deviceinfo wird in einem Fenster angezeigt als:
CHN MEQ0714259:0 HM-LC-Dim1T-Pl-3 MEQ0714259:0
DPT {b} BidCos-RF.MEQ0714259:0.UNREACH = false [RE]
DPT {b} BidCos-RF.MEQ0714259:0.STICKY_UNREACH = false [RWE]
DPT {b} BidCos-RF.MEQ0714259:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.MEQ0714259:0.DUTYCYCLE = false [RE]
DPT {8} BidCos-RF.MEQ0714259:0.RSSI_DEVICE = 1 [RE]
DPT {8} BidCos-RF.MEQ0714259:0.RSSI_PEER = 44 [RE]
DPT {b} BidCos-RF.MEQ0714259:0.DEVICE_IN_BOOTLOADER = false [RE]
DPT {b} BidCos-RF.MEQ0714259:0.UPDATE_PENDING = false [RE]
DPT {8} BidCos-RF.MEQ0714259:0.AES_KEY = 0 [R]
CHN MEQ0714259:1 WZ-Stehlampe-1
DPT {6} BidCos-RF.MEQ0714259:1.LEVEL = 1.000000 [RWE]
DPT {b} BidCos-RF.MEQ0714259:1.OLD_LEVEL = [W]
DPT {f} BidCos-RF.MEQ0714259:1.LEVEL_REAL = 1.000000 [RE]
DPT {f} BidCos-RF.MEQ0714259:1.RAMP_TIME = [W]
DPT {f} BidCos-RF.MEQ0714259:1.ON_TIME = [W]
DPT {b} BidCos-RF.MEQ0714259:1.RAMP_STOP = [W]
DPT {b} BidCos-RF.MEQ0714259:1.INHIBIT = false [RWE]
DPT {b} BidCos-RF.MEQ0714259:1.ERROR_REDUCED = false [RE]
DPT {b} BidCos-RF.MEQ0714259:1.ERROR_OVERLOAD = false [RE]
DPT {b} BidCos-RF.MEQ0714259:1.ERROR_OVERHEAT = false [RE]
DPT {i} BidCos-RF.MEQ0714259:1.DIRECTION = 0 [RE]
DPT {b} BidCos-RF.MEQ0714259:1.INSTALL_TEST = [W]
DPT {b} BidCos-RF.MEQ0714259:1.WORKING = false [RE]
CHN MEQ0714259:2 HM-LC-Dim1T-Pl-3 MEQ0714259:2
DPT {6} BidCos-RF.MEQ0714259:2.LEVEL = 0.000000 [RWE]
DPT {b} BidCos-RF.MEQ0714259:2.OLD_LEVEL = [W]
DPT {f} BidCos-RF.MEQ0714259:2.LEVEL_REAL = 1.000000 [RE]
DPT {f} BidCos-RF.MEQ0714259:2.RAMP_TIME = [W]
DPT {f} BidCos-RF.MEQ0714259:2.ON_TIME = [W]
DPT {b} BidCos-RF.MEQ0714259:2.RAMP_STOP = [W]
DPT {b} BidCos-RF.MEQ0714259:2.INHIBIT = false [RWE]
DPT {b} BidCos-RF.MEQ0714259:2.ERROR_REDUCED = false [RE]
DPT {b} BidCos-RF.MEQ0714259:2.ERROR_OVERLOAD = false [RE]
DPT {b} BidCos-RF.MEQ0714259:2.ERROR_OVERHEAT = false [RE]
DPT {i} BidCos-RF.MEQ0714259:2.DIRECTION = 0 [RE]
DPT {b} BidCos-RF.MEQ0714259:2.INSTALL_TEST = [W]
DPT {b} BidCos-RF.MEQ0714259:2.WORKING = false [RE]
CHN MEQ0714259:3 HM-LC-Dim1T-Pl-3 MEQ0714259:3
DPT {6} BidCos-RF.MEQ0714259:3.LEVEL = 0.000000 [RWE]
DPT {b} BidCos-RF.MEQ0714259:3.OLD_LEVEL = [W]
DPT {f} BidCos-RF.MEQ0714259:3.LEVEL_REAL = 1.000000 [RE]
DPT {f} BidCos-RF.MEQ0714259:3.RAMP_TIME = [W]
DPT {f} BidCos-RF.MEQ0714259:3.ON_TIME = [W]
DPT {b} BidCos-RF.MEQ0714259:3.RAMP_STOP = [W]
DPT {b} BidCos-RF.MEQ0714259:3.INHIBIT = false [RWE]
DPT {b} BidCos-RF.MEQ0714259:3.ERROR_REDUCED = false [RE]
DPT {b} BidCos-RF.MEQ0714259:3.ERROR_OVERLOAD = false [RE]
DPT {b} BidCos-RF.MEQ0714259:3.ERROR_OVERHEAT = false [RE]
DPT {i} BidCos-RF.MEQ0714259:3.DIRECTION = 0 [RE]
DPT {b} BidCos-RF.MEQ0714259:3.INSTALL_TEST = [W]
DPT {b} BidCos-RF.MEQ0714259:3.WORKING = false [RE]
Wie kann ich das in Verbindung bringen zu den in der CCU angezeigten Werten?
Den Slider habe ich nun so definiert:
define d_Stehlampe HMCCUDEV MEQ0714259 1
attr d_Stehlampe IODev myCCU2
attr d_Stehlampe ccureadings 1
attr d_Stehlampe controldatapoint 1.LEVEL
attr d_Stehlampe event-on-change-reading .*
attr d_Stehlampe statechannel 1
attr d_Stehlampe statedatapoint LEVEL
attr d_Stehlampe statevals on:1.0,off:0.0
attr d_Stehlampe stripnumber 1
attr d_Stehlampe substitute 1.0:on,0.0:off
attr d_Stehlampe webCmd control
attr d_Stehlampe widgetOverride control:slider,0,0.25,1,1
substitute hat noch keine Wirkung.
Heute habe ich meinen PI2 mit der Testversion von gestern (neues 88_HMCCU.pm und ccurpcd.pl ) neu gestartet und im FHEM-Log folgendes entdeckt:
2016.04.10 10:32:06 0: Server shutdown
2016.04.10 10:32:08 0: HMCCU: RPC server not running
Signal 18 (CONT) caught by ps (procps-ng version 3.3.3).
ps:display.c:59: please report this bug
Keine Ahnung, ob das eine Meldung von HMCCU ist....
Solange der RPCServer auf meiner zentralen FHEM-Installation nicht läuft, habe ich mir wie folgt beholfen... Auch wenn's vielleicht etwas übertrieben erscheint.... ::) ::) ::)
1 Ich habe meine programmierbare HM Fernbedienung (HM-RC-Dis-H-x-EU) über die CCU2 angemeldet, da ich mit der Konfiguration dieser über FHEM nicht klar kam. Dort habe ich mir zwei Funktionen (Rolladen hoch und Rolladen runter) auf die Fernbedienung gelegt.
2 Die CCU2 meldet nun über den registrierten rpcserver, der bei mir leider nur im Keller auf dem piKeller (PI3) läuft, jeden Tastendruck der Fernbedienung.
3 Über eine FHEM2FHEM-Verbingung habe ich mein FHEM auf dem piHägelesweg mit dem FHEM auf dem piKeller gekoppelt. Alle Ereignisse der Fernbedienung werden darüber zum zentralen FHEM übermittelt.
4 Über ein notify werden nun auf dem piHägelesweg alle Tastendrücke der HM-Fernbedienung registriert und ich steuere je nach gedrückter Taste den Rademacherrolladen im Wohnzimmer.
Kaum zu glauben, aber das funktioniert.... Herzlichen Dank für dieses tolle Modul ---> und es stimmt was zap uns hier verspricht: "best of both worlds approach"
Hallo Achiim,
gerade nach Hause gekommen. Muss Deine Posts erst mal sortieren ...
Also der SL Event ist neu. Damit meldet ccurpcd.pl an HMCCU, dass er kurz davor ist, den RPC Server Loop zu starten. Eigentlich sollte HMCCU den Event kennen, vielleicht habe ich aber auch die falsche Version angehängt. Bist Du sicher, dass Du die Version 3.1b runtergeladen, installiert und auch in FHEM geladen hast?? Bei mir funktioniert das nämlich und die Meldung "unknown event" kommt auch nicht.
HMCCU bzw. HMCCUDEV/CHN liefern die offiziellen Datenpunkt-Namen, die man auch folgendem Dokument entnehmen kann:
http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/hm_devices_Endkunden.pdf
Leider unterscheiden sich die Bezeichnungen in der CCU Weboberfläche von den Datenpunktnamen. Bei einigen kann man den Zusammenhang ableiten, bei anderen hilft nur ausprobieren. Dein Screenshot zeigt übrigens nicht die Datenpunkte sondern die Konfigurationsparameter. Diese werden mit get/set config gelesen oder gesetzt. Die Werte aus den Datenpunkten findest Du in der CCU z.B. unter "Status und Bedienung/Geräte".
Die Ausgabe von get deviceinfo ist übrigens sehr hilfreich, wenn man die interessanten Datenpunkte herausfinden möchte, um z.B. das Attribut ccureadingfilter zu setzen. Insbesondere die Angaben in den eckigen Klammern sind nützlich: R=Read, W=Write, E=Event. Bei einem Datenpunkt, der kein W hat, ist ein set Befehl sinnlos. Umgekehrt: Fehlt das R, kann man diesen Datenpunkt bei get ignorieren.
Ein gutes Beispiel sind Thermostate: Hier gibt es den Datenpunkt CONTROL_MODE, mit dem man den aktuellen Steuermodus auslesen kann [RE]. Eingestellt wird der Modus aber über MANU_MODE oder AUTO_MODE, beide [W].
Die folgende Meldung hat nichts mit HMCCU zu tun (ich schreibe immer "HMCCU:" davor):
Signal 18 (CONT) caught by ps (procps-ng version 3.3.3).
ps:display.c:59: please report this bug
zum substitute beim Dimmer: Das kann nicht funktionieren, da substitute Fließkommazahlen ignoriert (sonst hat das unangenehme Seiteneffekte auf alle nummerischen Readings). Aber ich überlege mal, was man da machen kann. Blöd ist halt, dass der Dimmer kein STATE mit true oder false für ein / aus hat.
Also:
Ich habe die Versions geprüft und habe unterschiedliche Angaben gefunden ....
In FHEM kommt mit ... "version 88_*"
File Rev Last Change
88_HMCCU.pm 11140 2016-03-28 16:57:53Z fhemzap
No Id found for 88_HMCCUDEV.pm
In der von Dir gestern gelieferten 88_HMCCU.pm steht:
# 88_HMCCU.pm
#
# $Id: 88_HMCCU.pm 11140 2016-03-28 16:57:53Z fhemzap $
#
# Version 3.1b
#
# Module for communication between FHEM and Homematic CCU2.
# Supports BidCos-RF, BidCos-Wired, HmIP-RF.
#
# (c) 2016 zap (zap01 <at> t-online <dot> de)
#
Im Code von 88_HMCCU.pm ist nur eine Stelle, die aus SL reagiert:
elsif ($Tokens[0] eq 'SL') {
#### RPC Server going to start server loop ###
Log3 $name, 0, "HMCCU: Received SL event. RPC server ".$Tokens[2]." starting server loop.";
$hash->{hmccu}{rpc}{$Tokens[2]}{loop} = 1;
InternalTimer (gettimeofday()+$HMCCU_INIT_INTERVAL1, 'HMCCU_RPCRegisterCallback', $hash, 0);
return;
}
Das scheint alles okay und auch an der richtigen Stelle installiert zu sein... dann probiere ich es eben nochmal....
2016.04.10 20:07:05 0: HMCCU: RPC server started with pid 2552
2016.04.10 20:07:29 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.10 20:07:34 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001 at http://192.168.178.16:2001/
2016.04.10 20:07:35 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.10 20:07:40 0: HMCCU: Received IN event. RPC server CB2001 initialized.
Und siehe da... der RPC-Server läuft und läuft und läuft.....
Ich habe nix geändert... Einfach nochmal probiert und es tut.... :o 8)
War wohl irgendwie mein Fehler.... Gestern ist es spät geworden... Danke.
Datenpunkte? Also für meine Stehlampe finde ich in der CCU unter "Status und Bedienung/Geräte":
Bezogen auf die komische Meldung
Signal 18 (CONT) caught by ps (procps-ng version 3.3.3).
ps:display.c:59: please report this bug
habe ich folgenden Hinweis gefunden:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1055551 (https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1055551)
Kann es sein dass die Meldung indirekt von Dir ist, da Du vermutlich mit ps prüfst, ob noch ein rpcserver läuft...
Benutzt Du denn zsh statt bash? Nur da soll dieser Fehler auftreten.
Aber grundsätzlich: ja, ich nutze ps für die Prozessprüfung.
Zu den Datenpunkten: ja das meine ich. Das ansteigende Dreieck ist der Datenpunkt LEVEL. Du solltest Dir mal die PDF anschauen, die ich verlinkt hatte. Da wird für jedes Gerät jeder Datenpunkt mit Funktion beschrieben. Darauf greifst Du mit "get datapoint" oder "set datapoint" zu. set devstate ist nur ein Sonderfall von set datappoint eben für den statedatapoint.
Daneben gibt es noch die Config-Parameter. Hier werden interne Parameter der Geräte festgelegt, die keinen direkten Effekt auslösen sondern das generelle Verhalten eines Gerätes beeinflussen.
In der CCu werden die Datenpunkte möglichst einfach und grafisch dargestellt. Letztendlich greift die Weboberfläche aber auch nur auf Datenpunkte und Config Parameter zu.
Danke nochmal fürs Testen. Werde das morgen einchecken.
Langsam verstehe ich die Bedeutung der Readings.... Aber intuitiv ist anders.... Das liegt aber eher an eQ3...
Noch eine Kleinigkeit..
Wie angeraten nutzte ich den ccureadingfilter und zwar mit der Einstellung: "^WZ-Stehlampe-1!(LEVEL|ON_TIME|RAMP_TIME|RAMP_STOP). Dieser Filter zeigt etwas mehr als ich erwartet hätte. Warum kommen auch die Readings "WZ-Stehlampe-1.LEVEL_REAL" und "WZ-Stehlampe-1.OLD_LEVEL" durch? Siehe screenshot.
Zitat von: Achiim am 10 April 2016, 23:28:18
Langsam verstehe ich die Bedeutung der Readings.... Aber intuitiv ist anders.... Das liegt aber eher an eQ3...
Die Reading-Namen werden aus den Datenpunkt-Namen oder den Namen der Config-Parameter gebildet (dann mit "R_" davor, weil das CUL_HM auch so macht). Vielleicht noch gut zu wissen: Der RPC-Server aktualisiert nur Datenpunkte, keine Config-Parameter (kein Fehler sondern "ist halt so (EQ3)"). Aber ich denke, im täglichen Betrieb wird man die Config-Parameter eher selten nutzen. Wenn ich da was einstellen muss, mache ich das direkt in der CCU.
Zitat
Wie angeraten nutzte ich den ccureadingfilter und zwar mit der Einstellung: "^WZ-Stehlampe-1!(LEVEL|ON_TIME|RAMP_TIME|RAMP_STOP). Dieser Filter zeigt etwas mehr als ich erwartet hätte. Warum kommen auch die Readings "WZ-Stehlampe-1.LEVEL_REAL" und "WZ-Stehlampe-1.OLD_LEVEL" durch? Siehe screenshot.
Der reguläre Ausdruck LEVEL matched alle Datenpunkte, die LEVEL enthalten. So dürfte es funktionieren:
^WZ-Stehlampe-1!(^LEVEL$|ON_TIME|RAMP_TIME|RAMP_STOP)
Wenn Du sowieso nur einen Kanal (hier WZ-Stehlampe-1) betrachtest, kannst Du "^WZ-Stehlampe-1!" auch weglassen. Dann bezieht sich der Filter auf alle Kanäle.
Eine weitere Vereinfachung, wenn Du bei einem Gerät nur einen Kanal verwendest, wäre HMCCUCHN statt HMCCUDEV effizienter. Dann sparst Du Dir z.B. bei set datapoint die Angabe der Kanalnummer.
In HMCCUDEV:
set xyz datapoint 1.LEVEL 0.5
In HMCCUCHN:
set xyz datapoint LEVEL 0.5
Zitat von: zap am 05 April 2016, 08:15:16
In den nächsten 1-2 Wochen wird es ein Update geben, das wahlweise ohne den externen RPC-Server auskommt (verwendet dann einen internen Sub-Prozess).
Hi zap,
klappt das diese Woche mit deinem angekündigten Update ?
frage nur nach, da ich das wenn sofort ausprobieren wollte :-)
Verständnisfrage:
Wie definiere ich eine Rauchmeldergruppe? Gemäß Anleitung (Readme) finde ich folgendes:
Define a new client device group:
define <name> HMCCUDEV <ccu-group-device> [<state-channel>] [readonly]
{group={<device>|<channel>}[,...]|groupexp=<expression>}
meine Interpretation dieser Syntax war wie folgt:
define d_Rauchmelderteam HMCCUDEV *MEQ0257246 1 group=MEQ0257246,NEQ0197808
oder
define d_Rauchmelderteam HMCCUDEV Rauchmeldeteam 1 group=MEQ0257246,NEQ0197808
Beides liefert in FHEM: Invalid or unknown CCU device name or address
Update: Oh, da war ein Schreibfehler drin... Jetzt mit "r"
define d_Rauchmelderteam HMCCUDEV Rauchmelderteam 1 group=MEQ0257246,NEQ0197808
liefert in FHEM: CCU device address not found for Rauchmelderteam
Die devicelist der HMCCU (get myCCU devicelist dump) sieht wie folgt aus:
Rauchmelderteam
Rauchmelderteam:0
Rauchmelderteam:1
HM-RCV-50 BidCoS-RF
HM-RCV-50 BidCoS-RF:0
HM-RCV-50 BidCoS-RF:1
HM-RCV-50 BidCoS-RF:10
HM-RCV-50 BidCoS-RF:11
HM-RCV-50 BidCoS-RF:12
HM-RCV-50 BidCoS-RF:13
HM-RCV-50 BidCoS-RF:14
HM-RCV-50 BidCoS-RF:15
HM-RCV-50 BidCoS-RF:16
HM-RCV-50 BidCoS-RF:17
HM-RCV-50 BidCoS-RF:18
HM-RCV-50 BidCoS-RF:19
HM-RCV-50 BidCoS-RF:2
HM-RCV-50 BidCoS-RF:20
HM-RCV-50 BidCoS-RF:21
HM-RCV-50 BidCoS-RF:22
HM-RCV-50 BidCoS-RF:23
HM-RCV-50 BidCoS-RF:24
HM-RCV-50 BidCoS-RF:25
HM-RCV-50 BidCoS-RF:26
HM-RCV-50 BidCoS-RF:27
HM-RCV-50 BidCoS-RF:28
HM-RCV-50 BidCoS-RF:29
HM-RCV-50 BidCoS-RF:3
HM-RCV-50 BidCoS-RF:30
HM-RCV-50 BidCoS-RF:31
HM-RCV-50 BidCoS-RF:32
HM-RCV-50 BidCoS-RF:33
HM-RCV-50 BidCoS-RF:34
HM-RCV-50 BidCoS-RF:35
HM-RCV-50 BidCoS-RF:36
HM-RCV-50 BidCoS-RF:37
HM-RCV-50 BidCoS-RF:38
HM-RCV-50 BidCoS-RF:39
HM-RCV-50 BidCoS-RF:4
HM-RCV-50 BidCoS-RF:40
HM-RCV-50 BidCoS-RF:41
HM-RCV-50 BidCoS-RF:42
HM-RCV-50 BidCoS-RF:43
HM-RCV-50 BidCoS-RF:44
HM-RCV-50 BidCoS-RF:45
HM-RCV-50 BidCoS-RF:46
HM-RCV-50 BidCoS-RF:47
HM-RCV-50 BidCoS-RF:48
HM-RCV-50 BidCoS-RF:49
HM-RCV-50 BidCoS-RF:5
HM-RCV-50 BidCoS-RF:50
HM-RCV-50 BidCoS-RF:6
HM-RCV-50 BidCoS-RF:7
HM-RCV-50 BidCoS-RF:8
HM-RCV-50 BidCoS-RF:9
AZ-Rauchmelder
AZ-Rauchmelder:0
AZ-Rauchmelder:1
HM-RC-Dis-H-x-EU MEQ0670565
HM-RC-Dis-H-x-EU MEQ0670565:0
Stehlampe an-dim:1
HM-RC-Dis-H-x-EU MEQ0670565:10
HM-RC-Dis-H-x-EU MEQ0670565:11
HM-RC-Dis-H-x-EU MEQ0670565:12
HM-RC-Dis-H-x-EU MEQ0670565:13
HM-RC-Dis-H-x-EU MEQ0670565:14
HM-RC-Dis-H-x-EU MEQ0670565:15
HM-RC-Dis-H-x-EU MEQ0670565:16
HM-RC-Dis-H-x-EU MEQ0670565:17
HM-RC-Dis-H-x-EU MEQ0670565:18
HM-RC-Dis-H-x-EU MEQ0670565:19
Stehlampe aus-dim:2
HM-RC-Dis-H-x-EU MEQ0670565:20
WZ-Rolladen-hoch:3
WZ-Rolladen-runter:4
HM-RC-Dis-H-x-EU MEQ0670565:8
HM-RC-Dis-H-x-EU MEQ0670565:9
HM-LC-Dim1T-Pl-3 MEQ0714259
HM-LC-Dim1T-Pl-3 MEQ0714259:0
WZ-Stehlampe-1
HM-LC-Dim1T-Pl-3 MEQ0714259:2
HM-LC-Dim1T-Pl-3 MEQ0714259:3
SZ-Rauchmelder
SZ-Rauchmelder:0
HM-Sec-SD NEQ0197808:1
Leider gibt es die Option "dump" in der FHEM-Oberfläche für "devicelist" nicht, sodass man das über die Komandozeile eingeben muss, wenn man eine Liste der in HMCCU bekannten Geräte haben will.
Hinweis:
In der CCU sieht die Definition der Rauchmeldergruppe so wie auf dem Screenshot aus.
Zitat von: tuppertasse am 11 April 2016, 08:23:51
Hi zap,
klappt das diese Woche mit deinem angekündigten Update ?
frage nur nach, da ich das wenn sofort ausprobieren wollte :-)
Das Timing Problem mit dem RPC-Server Start hat mich ziemlich viel Zeit und Nerven gekostet. Ich muss die Änderungen jetzt erst mal in meine (eigentlich schon lauffähige) neue Version integrieren, damit nach dem nächsten Update das Problem nicht wieder da ist. Mal sehen ;-)
Hängt auch vom Wetter ab: Schlechtes Wetter => FHEM Entwicklung. Gutes Wetter => Mountain Bike.
@Achiim: Muss ich mir zuhause mal anschauen. Habe keine Rauchmeldergruppe, nur Heizungsgruppen. Wenn Du die Adresse der Gruppe verwendest, muss jedenfalls der "*" weggelassen werden.
Prinzipiell sehen Deine defines aber gut aus.
Was sagt denn "get
myCCU deviceinfo Rauchmelderteam" ?
Auf ... get myCCU deviceinfo Rauchmelderteam .... kommt:
CHN *MEQ0257246:1 Rauchmelderteam:1
DPT {b} BidCos-RF.*MEQ0257246:1.STATE = false [RE]
DPT {b} BidCos-RF.*MEQ0257246:1.INSTALL_TEST = [E]
Problem scheint gelöst zu sein. Ich habe es virtuell definiert. Dann hat es sich anlegen lassen mit ... define d_Rauchmelderteam virtual 1 group=AZ-Rauchmelder,SZ-Rauchmelder ... ging es und zeigt mir folgende Werte an:
Internals:
CFGFN
DEF virtual 1 group=AZ-Rauchmelder,SZ-Rauchmelder
IODev myCCU
NAME d_Rauchmelderteam
NR 4295
STATE false
TYPE HMCCUDEV
ccuaddr VIR0000001
ccudevstate Active
ccugroup MEQ0257246,NEQ0197808
ccuif VirtualDevices
ccuname none
ccutype
channels 0
statevals readonly
Readings:
2016-04-11 15:08:24 AZ-Rauchmelder.0.CONFIG_PENDING false
2016-04-11 15:08:24 AZ-Rauchmelder.0.DEVICE_IN_BOOTLOADER false
2016-04-11 15:08:24 AZ-Rauchmelder.0.DUTYCYCLE false
2016-04-11 15:08:24 AZ-Rauchmelder.0.LOWBAT false
2016-04-11 15:08:24 AZ-Rauchmelder.0.RSSI_DEVICE 1
2016-04-11 15:08:24 AZ-Rauchmelder.0.RSSI_PEER 37
2016-04-11 15:08:24 AZ-Rauchmelder.0.STICKY_UNREACH false
2016-04-11 15:08:24 AZ-Rauchmelder.0.UNREACH false
2016-04-11 15:08:24 AZ-Rauchmelder.0.UPDATE_PENDING false
2016-04-11 15:08:24 AZ-Rauchmelder.1.INSTALL_TEST N/A
2016-04-11 15:08:24 AZ-Rauchmelder.1.STATE false
2016-04-11 15:08:25 SZ-Rauchmelder.0.CONFIG_PENDING false
2016-04-11 15:08:25 SZ-Rauchmelder.0.DEVICE_IN_BOOTLOADER false
2016-04-11 15:08:25 SZ-Rauchmelder.0.DUTYCYCLE false
2016-04-11 15:08:25 SZ-Rauchmelder.0.LOWBAT false
2016-04-11 15:08:25 SZ-Rauchmelder.0.RSSI_DEVICE 1
2016-04-11 15:08:25 SZ-Rauchmelder.0.RSSI_PEER 53
2016-04-11 15:08:25 SZ-Rauchmelder.0.STICKY_UNREACH false
2016-04-11 15:08:25 SZ-Rauchmelder.0.UNREACH false
2016-04-11 15:08:25 SZ-Rauchmelder.0.UPDATE_PENDING false
2016-04-11 15:08:25 SZ-Rauchmelder.1.INSTALL_TEST N/A
2016-04-11 15:08:25 SZ-Rauchmelder.1.STATE false
2016-04-11 15:08:25 state false
Attributes:
IODev myCCU
ccureadings 1
statechannel 1
Update:
Ist das so gedacht mit "virtuell"? Ich vermisse den unter FHEM möglichen Team_Call für Rauchmelder, die in einem Team sind. Gibt es den irgendwie auch über die XML-Schnittstelle?
Neues Problem: get myCCU update löst auch mein notify aus, da der update so tut als ob gerade von allen Geräten Events kommen. Das kann im Eventmonitor mitverfolgt werden.... War das im Sinne des Erfinders? Besser wäre, wenn "update" nur die Readings setzt und gut ist.... Oder habe ich etwas nicht bedacht?
Hinweis: Das Attribut updatemode habe ich bei meiner HMCCU nicht gesetzt. Kann das Verhalten etwa darüber beeinflusst werden?
Die Wirkung bei mir war, dass die Rolläden plötzlich runtergefahren sind.... Da ich auf eines der beim update generierten Ereignisse ein notify gesetzt habe. ;D Ist zum Glück nix passiert, da die Katze und die Frau gerade Mittagsschlaf machen.... ::)
Dann ist mir noch aufgefallen, dass das update einen Fehler wirft und "1 client device" nicht aktualisieren konnte. Im FHEM Log ist keine Meldung in diesem Zusammenhang zu finden. Siehe Screen-Shot. Kann es sein, dass dass mein soeben definiertes "virutelles" Device ist, das nicht aktualisiert wird. Die Meldung ist zu spärlich, um genaueres sagen zu können. Hier wäre ein Hinweis wünschenswert, welches Device nicht ging.
Zu der Gruppe: Mit einem virtuellen Gerät funktioniert das natürlich, da diese Gruppen reine HMCCU Gruppen sind. Von denen weiß die CCU nichts. Daher kommt auch die Fehlermeldung beim "get update", da diese virtuellen Geräte keine gültige Adresse haben, zumindest keine, die die CCU kennt (to be fixed)
Mich würde mal interessieren, ob Deine Rauchmeldergruppe in der CCU unter Einstellungen->Gruppen auftaucht und wenn ja, mit welchem Namen und Adresse. Ich vermute, bei den Rauchmeldergruppen kocht EQ3 wieder mal ein Extra-Süppchen.
Es wäre schöner, Du könntest die Gruppe wie in Deinem ersten Versuch definieren. Diese Gruppen werden nämlich in der nächsten Version von HMCCU ebenfalls per RPC-Server aktualisiert. Grundsätzlich funktioniert das auch mit den virtuellen Geräten, nur kennt die die CCU eben nicht.
Das mit dem Notify habe ich noch nicht verstanden: Bezieht sich das Notify auf das HMCCU-Device? Dann könnte ein updatemode = client helfen. Das sorgt dann auch dafür, dass im IO Device keine Readings gesetzt werden.
Bei den Events musst Du unterscheiden zwischen CCU-Events und FHEM-Events. Ein FHEM-Event (und damit auch ein zugeordnetes Notify) wird immer ausgelöst, wenn ein Reading gesetzt wird. Mit event-on-change-reading und event-on-update-reading kannst Du aber einstellen, ob das FHEM-Event nur kommen soll, wenn ein Readingwert aktualisiert wird oder nur, wenn er sich geändert hat.
Ich habe gerade die Version 3.1b eingecheckt. Wer Version 3.1 nutzt, muss nur die Dateien 88_HMCCU.pm und ccurpcd.pl aktualisieren. Vor Version 3.1 müssen alle Dateien aktualisiert werden.
Diese Version behebt Timing-Probleme beim Start des RPC-Servers auf langsamen Systemen. Diese führten dazu, dass der RPC-Server im Status "starting" stecken blieb.
Zu der Rauchmeldergruppe:
In der CCU ist die als Gerät definiert, nicht als Gruppe. Die Definition hatte ich bereits in Antwort #417 als Screenshot angehängt. Dort habe ich auch den Stern vor dem Namen her.
zum set ... update und notify:
Mein notify geht auf zwei Kanäle meiner HM-Fernbedienung. Die Kanäle heißen in FHEM c_WZ_Rolladen_hoch und c_WZ_Rolladen_runter...
Hier der code des notify:
c_WZ_Rolladen_hoch:.*|c_WZ_Rolladen_runter:.* {
Log (3,"HM_Fernbedienung-Notify: $NAME, $EVTPART0, $EVTPART1");
if ($EVTPART0 eq "WZ-Rolladen-hoch.3.PRESS_SHORT:")
{
fhem("set Wohnzimmer_Rolladen_Essen up");
fhem("set Wohnzimmer_Rolladen_Sofa up");
}
if ($EVTPART0 eq "WZ-Rolladen-hoch.3.PRESS_LONG:")
{
fhem("set Wohnzimmer_Rolladen_Essen stop");
fhem("set Wohnzimmer_Rolladen_Sofa stop");
}
if ($EVTPART0 eq "WZ-Rolladen-runter.4.PRESS_SHORT:")
{
fhem("set Wohnzimmer_Rolladen_Essen down");
fhem("set Wohnzimmer_Rolladen_Sofa down");
}
if ($EVTPART0 eq "WZ-Rolladen-runter.4.PRESS_LONG:")
{
fhem("set Wohnzimmer_Rolladen_Essen stop");
fhem("set Wohnzimmer_Rolladen_Sofa stop");
}
}
Hier die Definition der Kanäle c_WZ_Rolladen_hoch und c_WZ_Rolladen_runter
Internals:
CFGFN
DEF WZ-Rolladen-hoch:3
IODev myHomematicCCU
NAME c_WZ_Rolladen_hoch
NR 4213
STATE Initialized
TYPE HMCCUCHN
ccuaddr MEQ0670565:3
ccudevstate Active
ccuif BidCos-RF
ccuname WZ-Rolladen-hoch:3
ccutype HM-RC-Dis-H-x-EU
channels 1
statevals devstate
Readings:
2016-04-11 20:09:19 WZ-Rolladen-hoch.3.INSTALL_TEST 1
2016-04-11 20:09:19 WZ-Rolladen-hoch.3.PRESS_CONT 1
2016-04-11 20:09:17 WZ-Rolladen-hoch.3.PRESS_LONG 1
2016-04-11 20:09:20 WZ-Rolladen-hoch.3.PRESS_LONG_RELEASE 1
2016-04-11 20:09:17 WZ-Rolladen-hoch.3.PRESS_SHORT 1
2016-04-11 14:31:53 state Initialized
Attributes:
IODev myCCU
devStateIcon ok:10px-kreis-gruen alarm:10px-kreis-rot Initialized:10px-kreis-gelb
event-on-change-reading .*
group Fernbedieung
room HMCCU
-------------------------------------------------------------------------------------------
Internals:
CFGFN
DEF WZ-Rolladen-runter:4
IODev myHomematicCCU
NAME c_WZ_Rolladen_runter
NR 4216
STATE Initialized
TYPE HMCCUCHN
ccuaddr MEQ0670565:4
ccudevstate Active
ccuif BidCos-RF
ccuname WZ-Rolladen-runter:4
ccutype HM-RC-Dis-H-x-EU
channels 1
statevals devstate
Readings:
2016-04-11 20:06:25 WZ-Rolladen-runter.4.INSTALL_TEST false
2016-04-11 20:06:25 WZ-Rolladen-runter.4.PRESS_CONT false
2016-04-11 20:06:25 WZ-Rolladen-runter.4.PRESS_LONG false
2016-04-11 20:06:25 WZ-Rolladen-runter.4.PRESS_LONG_RELEASE false
2016-04-11 20:06:25 WZ-Rolladen-runter.4.PRESS_SHORT false
2016-04-11 14:32:40 state Initialized
Attributes:
IODev myCCU
devStateIcon ok:10px-kreis-gruen alarm:10px-kreis-rot Initialized:10px-kreis-gelb
event-on-change-reading .*
group Fernbedieung
room HMCCU
Trotz setzen von event-on-change-reading auf .* bei den beiden Kanälen reagiert das notify. event-on-update-reading habe ich bei beiden nicht gesetzt. Oder habe ich das falsch verstanden.
Rauchmelder: wieder ein EQ3 Spezialfall. Statt die Gruppen zu verwenden wie bei der Heizung bilden sie hier die Gruppen als Spezialdevice mit Steenchenadresse ab. Mal sehen, wie ich das einfange. Aktuell fällt das Sternchen durch die Syntaxprüfung, daher funktioniert das nicht. Ich werde wohl meine HM Rauchmelder aus der Elektroschrottkiste holen und nochmal anlernen müssen, um das nachzustellen.
event-on-change-reading ist ja eine Standard FHEM Funktion. Für mich sieht Deine Def gut aus. Wie verhält sich das Notify, wenn Du "get update" lokal für einen Rolladen aufrufst?
Für das Setzen der Readings verwende ich FHEM Standardfunktionen. Da lässt sich nichts dran drehen.
Mm, grundsätzlich greift das Notify bei jedem Reading. Erst die IFs filtern dann auf die entsprechenden Tasten. Ich halte IF und DOIF sowieso in FHEM für Teufelszeug. Wie ist es, wenn Du für jede Taste ein eigenes Notify spendierst und in die Bedingung die Taste mit reinpackst?
ZitatWie verhält sich das Notify, wenn Du "get update" lokal für einen Rolladen aufrufst?
Ääähhhh. Das ist ein Rademacher Rolladenaktor, der hat kein get update... Falls Du das get update auf dem Kanal der Fernbedienung meinst (c_WZ_Rolladen_runter), so kann ich das heute Abend nciht mehr machen, da die Frau unten auf der Coach fern sieht und ich Ärger kriege, wenn sich der Rolladen schon wieder bewegt.... :'( >:(
Wie heißt es doch so schön in der Werbung... "Meine Frau hat gesagt er soll bitte nicht so dominant sein", daraufhin der Verkäufer "Dann nehmen sie den, der ist auch nicht sooo dominant". ;D ;D ;D
Ja, ich kenne das. Der WAF ist bei meiner Smart Home Umgebung auch ein ganz großes Thema. Du könntest 3 Dinge probieren:
1. get update auf den FB-Kanal, z.B. get c_WZ_Rolladen_hoch update
2. Ein notify für eine FB-Aktion definieren
3. DOIF verwenden (das aber als letzte Möglichkeit, das Forum ist voll von DOIF-Fragen)
Dann wäre noch die Frage, warum Du überhaupt ein get update machst. Der RPC-Server liefert doch die Änderungen automatisch. Allerdings führt HMCCU beim Starten des RPC-Servers einmalig ein get update aus, um alle Devices in FHEM mit der CCU zu synchronisieren. Da würden dann ggf. Deine Rolläden hoch/runter fahren => auch blöd.
Eine FB habe ich glaube ich auch noch rumliegen. Muss ich mal testen.
Kann es sein, dass das Setzen von
event-on-change-reading auf .* ein wenig dauert, bis es wirkt oder gar ein reboot von FHEM benötigt, um zu wirken? Jedenfalls habe ich heute überhaupt keine events mehr für den Rolladen bekommen, auch nicht wenn ich die Fernbedienung gedrückt habe....
Da habe ich mal überlegt, was ich hier eigentlich konfiguriert habe.... :D
- die Definition der Kanäle c_WZ_Rolladen_hoch und c_WZ_Rolladen_runter hat jeweils ein event-on-change-reading .*
- event-on-change-reading auf .* gesetzt bedeutet doch, dass nur Wertänderungen von allen Readings dieses device oder chanel ein Event erzeugen sollen
- das Reading auf das ich triggere ist z.B. WZ-Rolladen-hoch.3.PRESS_SHORT und hat bei einem Tastendruck den Wert "1"
Der Wert des Readings WZ-Rolladen-hoch.3.PRESS_SHORT ändert sich aber nicht, wenn die Taste wieder losgelassen oder gar nochmal gedrückt wird, sondern verbleibt bei "1". Es ändert sich bei einem Tastendruck nur die Farbe des Readingwertes in FHEM auf rot und die Zeitangabe.
Bei einem langen Tastendruck ist es ähnlich. Hier geht WZ-Rolladen-hoch.3.PRESS_LONG auf "1" und bleibt auf "1". Dafür ändert sich aber der Wert von WZ-Rolladen-hoch.3.PRESS_LONG_RELEASE auf "1", wenn die Taste nach einem langen Tastendruck wieder losgelassen wird. Bei einem kurzen Tastendruck gibt es kein Signal über das Loslassen der Taste. Soweit das was ich beobachtet habe.
Nun eine mögliche Behandlung für die Fernbedienungsherausforderung:
- Statt der "1", die bei jedem Tastendruck im Reading landet, könnte es ein Zähler sein, der sich bei jedem Tastendruck um 1 erhöht
- Dann würde sich das Reading bei jedem Tastendruck auch ändern und das Setzten von event-on-change-reading auf .* würde wieder Sinn machen
- Wenn der rpcserver hochfährt und das update macht bzw. wenn man manuell ein update macht, sollt der Zähler nicht hochgezählt werden
- Dann würde update auch kein Event auslösen, wenn event-on-change-reading auf .* gesetzt ist
Ist meine Überlegung nachvollziehbar und eine mögliche Option zur Implementierung?
update:
Ich habe noch beobachtet, dass
bei gesetztem event-on-change-reading auf .*, der Kanäle c_WZ_Rolladen_hoch und c_WZ_Rolladen_runter, folgendes Verhalten auftritt:
- set c_WZ_Rolladen_hoch update setzt mir alle readings auf "false"
- wenn ich die Fernbedieungstasten drücke, gehen die entsprechenden Readings auf "1"
Das ist auch ein für mich nicht nachvollziehbares Verhalten. Welche Bedeutung hat das? Ist das so gewünscht?
Anbei noch die Definition meines Kanals:
Internals:
CFGFN
DEF WZ-Rolladen-hoch:3
IODev myHomematicCCU
NAME c_WZ_Rolladen_hoch
NR 4213
STATE Initialized
TYPE HMCCUCHN
ccuaddr MEQ0670565:3
ccudevstate Active
ccuif BidCos-RF
ccuname WZ-Rolladen-hoch:3
ccutype HM-RC-Dis-H-x-EU
channels 1
statevals devstate
Readings:
2016-04-12 17:25:31 WZ-Rolladen-hoch.3.INSTALL_TEST false
2016-04-12 17:25:31 WZ-Rolladen-hoch.3.PRESS_CONT false
2016-04-12 17:25:31 WZ-Rolladen-hoch.3.PRESS_LONG false
2016-04-12 17:25:31 WZ-Rolladen-hoch.3.PRESS_LONG_RELEASE false
2016-04-12 17:25:31 WZ-Rolladen-hoch.3.PRESS_SHORT false
2016-04-11 14:31:53 state Initialized
Attributes:
IODev myCCU
devStateIcon ok:10px-kreis-gruen alarm:10px-kreis-rot Initialized:10px-kreis-gelb
event-on-change-reading .*
group Fernbedienung
room HMCCU
Wie kann das passieren?
HMCCUDEV: Arbeitszimmer_Deckenlicht Execution of CCU script or command failed
Ich habe meinen "slider" für meinen Dimmer im Arbeitszimmer mehrmahls hin- und hergeschoben. Beim 3.mal kam obige Meldung und es ging kein Befehl mehr an die CCU durch. Ich habe die Lampe dann direkt in der CCU aus- und eingeschaltet, dann konnte ich sie auch wieder über das HMCCUDEV steuern....
Komisch? :'(
Anbei die Definition des Dimmers
Internals:
CFGFN
DEF AZ-Deckenlicht 1
IODev myHomematicCCU
NAME Arbeitszimmer_Deckenlicht
NR 4710
STATE OK
TYPE HMCCUDEV
ccuaddr JEQ0207451
ccudevstate Active
ccuif BidCos-RF
ccuname AZ-Deckenlicht
ccutype HM-LC-Dim1TPBU-FM
channels 4
statevals devstate|on|off
Readings:
2016-04-12 19:54:02 AZ-Deckenlicht.0.CONFIG_PENDING false
2016-04-12 19:54:02 AZ-Deckenlicht.0.DEVICE_IN_BOOTLOADER false
2016-04-12 19:54:02 AZ-Deckenlicht.0.DUTYCYCLE false
2016-04-12 19:54:02 AZ-Deckenlicht.0.RSSI_DEVICE 128
2016-04-12 19:54:02 AZ-Deckenlicht.0.RSSI_PEER 182
2016-04-12 19:54:02 AZ-Deckenlicht.0.STICKY_UNREACH false
2016-04-12 19:54:02 AZ-Deckenlicht.0.UNREACH false
2016-04-12 19:54:02 AZ-Deckenlicht.0.UPDATE_PENDING false
2016-04-12 20:05:32 AZ-Deckenlicht.1.DIRECTION 0
2016-04-12 20:05:32 AZ-Deckenlicht.1.ERROR_OVERHEAT 0
2016-04-12 20:05:32 AZ-Deckenlicht.1.ERROR_OVERLOAD 0
2016-04-12 20:05:32 AZ-Deckenlicht.1.ERROR_REDUCED 0
2016-04-12 19:54:02 AZ-Deckenlicht.1.INHIBIT false
2016-04-12 19:54:02 AZ-Deckenlicht.1.INSTALL_TEST N/A
2016-04-12 20:05:31 AZ-Deckenlicht.1.LEVEL 1.000000
2016-04-12 20:05:32 AZ-Deckenlicht.1.LEVEL_REAL 1.000000
2016-04-12 19:54:02 AZ-Deckenlicht.1.OLD_LEVEL N/A
2016-04-12 19:54:02 AZ-Deckenlicht.1.ON_TIME N/A
2016-04-12 19:54:02 AZ-Deckenlicht.1.RAMP_STOP N/A
2016-04-12 19:54:02 AZ-Deckenlicht.1.RAMP_TIME N/A
2016-04-12 20:05:32 AZ-Deckenlicht.1.WORKING 0
2016-04-12 20:05:31 control 1.000000
2016-04-12 20:05:24 state OK
Attributes:
IODev myHomematicCCU
ccureadingfilter ^AZ-Deckenlicht!(.*)
controldatapoint 1.LEVEL
group Arbeitszimmer_Licht
icon light_ceiling
room 02_Oben,HMCCU
statechannel 1
statevals on:1.000000,off:0.000000
webCmd control
widgetOverride control:slider,0,0.050000,1,1
Zitat von: Achiim am 12 April 2016, 17:12:36
Kann es sein, dass das Setzen von event-on-change-reading auf .* ein wenig dauert, bis es wirkt oder gar ein reboot von FHEM benötigt, um zu wirken? Jedenfalls habe ich heute überhaupt keine events mehr für den Rolladen bekommen, auch nicht wenn ich die Fernbedienung gedrückt habe....
Nein, event-on-change-reading greift sofort. Vermutlich bekommst Du Events beim Drücken der Taste, aber der Wert der Readings ändert sich nicht. Das kannst Du prüfen, indem Du statt ...-on-change... das Attribut event-on-update-reading setzt (nicht beide!). Dann sollte sich beim Drücken einer Taste der Zeitstempel des Readings ändern.
Ich habe zwar eine Fernbedienung, aber leider keine Zeit, das momentan zu testen.
Zitat
Nun eine mögliche Behandlung für die Fernbedienungsherausforderung:
...
Ist meine Überlegung nachvollziehbar und eine mögliche Option zur Implementierung?
Wie gesagt, bevor ich das nicht selbst nachvollzogen habe, kann ich da nichts versprechen. Allerdings habe ich mit HMCCU von Anfang an einen generischen Ansatz verfolgt. Da passt eine Sonderbehandlung für einen Gerätetyp nicht so recht rein. Das wäre dann der Ansatz von CUL_HM.
Zitat
Ich habe noch beobachtet, dass bei gesetztem event-on-change-reading auf .*, der Kanäle c_WZ_Rolladen_hoch und c_WZ_Rolladen_runter, folgendes Verhalten auftritt:
- set c_WZ_Rolladen_hoch update setzt mir alle readings auf "false"
- wenn ich die Fernbedieungstasten drücke, gehen die entsprechenden Readings auf "1"
Das ist auch ein für mich nicht nachvollziehbares Verhalten. Welche Bedeutung hat das? Ist das so gewünscht?
Ein get update liefert bei Datenpunkten vom Typ bool entweder true oder false zurück (liegt am verwendeten Homematic Script). Der RPC-Server liefert hingegen 1 oder 0. Daher das unterschiedliche Verhalten und deshalb auch solche Definitionen in meinen Beispielen für substitute: (true|1):an,(false|0):aus. Theoretisch ginge auch 1:true,0:false. Damit werden die RPC-Werte durch Homematic Script Werte ersetzt.
Ich habe übrigens auch mal get update beim HMCCU IO Device getestet. Bei mir verhält sich event-on-change-reading korrekt, d.h. nur geänderte Werte werden upgedated.
Zitat von: Achiim am 12 April 2016, 20:15:30
Wie kann das passieren?
HMCCUDEV: Arbeitszimmer_Deckenlicht Execution of CCU script or command failed
Ich habe meinen "slider" für meinen Dimmer im Arbeitszimmer mehrmahls hin- und hergeschoben. Beim 3.mal kam obige Meldung und es ging kein Befehl mehr an die CCU durch. Ich habe die Lampe dann direkt in der CCU aus- und eingeschaltet, dann konnte ich sie auch wieder über das HMCCUDEV steuern....
Komisch? :'(
Bei vielen schnellen Sets kommen sich vermutlich die Sets mit den RPC-Server Updateevents ins Gehege. Du könntest im HMCCU Device das Attribut rpcinterval auf 3 setzen (Default ist 5 Sekunden). Ob das hilft weiß ich nicht.
Anwendungsfall "Fernbedienungstastendruck durch notify auswerten"Ich habe jetzt eine Lösung dank deiner Hinweise implementiert. Ausgenutzt habe ich dabei folgende Sachverhalte:
- rpcserver liefert unterschiedliche Werte bei update und bei einem echten Event aus der CCU ("1" bei echtem Tastendruck; "false" bei get c_WZ_Rolladen_... update)
- rpcserver aktualisiert die Readings sowohl bei echten Events als auch bei "get ... update" oder beim "Start des rpcserver"
Es werden auf der Fernbedienung zwei Kanäle verwendet und damit zwei Tasten (eine für hoch und eine für runter) mit kurzem oder langem Tastendruck (der lange Tastendruck wird bei beiden Tasten als "stop" der Rolladenfahrt genutzt:
- c_WZ_Rolladen_hoch:WZ-Rolladen-hoch.3.PRESS_SHORT ==> Rolladen hoch
- c_WZ_Rolladen_hoch:WZ-Rolladen-hoch.3.PRESS_LONG ==> Rolladen stop
- c_WZ_Rolladen_runter:WZ-Rolladen-runter.4.PRESS_SHORT ==> Rolladen runter
- c_WZ_Rolladen_runter:WZ-Rolladen-runter.4.PRESS_LONG ==> Rolladen stop
Ich habe das notify, nun auf genau diese 4 Events ausgelegt und mit der Prüfung von Parameter
$EVTPART1 eq "1" festgestellt, dass eine Taste auf der Fernbedieung das Event ausgelöst hat und nicht ein update oder ein Start des rpcserver.
c_WZ_Rolladen_hoch:WZ-Rolladen-hoch.3.PRESS_SHORT:.*|c_WZ_Rolladen_hoch:WZ-Rolladen-hoch.3.PRESS_LONG:.*|c_WZ_Rolladen_runter:WZ-Rolladen-runter.4.PRESS_SHORT:.*|c_WZ_Rolladen_runter:WZ-Rolladen-runter.4.PRESS_LONG:.* {
Log (3,"HM_Fernbedienung-Notify: $NAME, $EVTPART0, $EVTPART1");
# #################################################
# ### nur wenn eine Taste gedrückt wird
# ### dann ist $EVTPART1 = "1" bei update "false"
# #################################################
if ($EVTPART1 eq "1"){
if ($EVTPART0 eq "WZ-Rolladen-hoch.3.PRESS_SHORT:")
{
Log (3,"HM_Fernbedienung-Notify: Rolladen hochfahren");
# fhem("set Wohnzimmer_Rolladen_Essen up");
# fhem("set Wohnzimmer_Rolladen_Sofa up");
}
if ($EVTPART0 eq "WZ-Rolladen-hoch.3.PRESS_LONG:")
{
Log (3,"HM_Fernbedienung-Notify: Rolladen stop(hoch)");
# fhem("set Wohnzimmer_Rolladen_Essen stop");
# fhem("set Wohnzimmer_Rolladen_Sofa stop");
}
if ($EVTPART0 eq "WZ-Rolladen-runter.4.PRESS_SHORT:")
{
Log (3,"HM_Fernbedienung-Notify: Rolladen runterfahren");
# fhem("set Wohnzimmer_Rolladen_Essen down");
# fhem("set Wohnzimmer_Rolladen_Sofa down");
}
if ($EVTPART0 eq "WZ-Rolladen-runter.4.PRESS_LONG:")
{
Log (3,"HM_Fernbedienung-Notify: Rolladen stop(runter)");
# fhem("set Wohnzimmer_Rolladen_Essen stop");
# fhem("set Wohnzimmer_Rolladen_Sofa stop");
}
}
}
:
Setzt man beim HMCCUCHN das Attribut
event-on-change-reading auf .*, so wird ein Event nur ausgelöst, wenn sich der Wert des Readings von "false" auf "1" ändert oder umgekehrt. Das passiert im Normalbetrieb (eine manuells update wird wohl im Normalbetrieb nicht erfolgen) nur, wenn der rpcserver gestartet wird und dann beim ersten Tastendruck. Alle weiteren Tastendrucke lösen kein Event mehr aus, da sich der Wert des Readings nicht ändert. Somit ist das Setzen von "event-on-change-reading auf .*" ungeeignet für diesen Anwendugnsfall.
Setzt man beim HMCCUCHN das Attribut
event-on-update-reading auf .*, so wird immer ein Event ausgelöst. Bei jedem Tastendruck, beim update und beim rpcserver-Start. Das Verhalten ist allerdings auch so, wenn event-on-update-reading und event-on-change-reading garnicht gesetzt sind.
Ergo: Für diesen Anwendungsfall "Fernbedienungstastendruck durch notify auswerten" erscheint das Setzten von event-on-update-reading und event-on-change-reading nicht sinnvoll.
ZitatBei vielen schnellen Sets kommen sich vermutlich die Sets mit den RPC-Server Updateevents ins Gehege. Du könntest im HMCCU Device das Attribut rpcinterval auf 3 setzen (Default ist 5 Sekunden). Ob das hilft weiß ich nicht.
Mit gesetztem Attribut rpcinterval auf 3 konnte ich keine Verklemmung mehr provozieren, auch wenn ich im Sekundentakt den Dimmwert verändert habe.
Hallo zusammen,
Ich versuche mich immer mehr in die FHEM Welt einzuarbeiten und dabei dieses tolle Modul für meine Bedürfnisse zu nutzen.
Ich habe viel gelesen und bekomme es auch hin, einzelne Devices anzulegen, die werte abzufragen und auch der RPC läuft mittlerweile. Was ich mich aber frage ist, ob es eine Art Best practice Ansatz gibt. Beispiel : Aktuell lege ich jedes einzelne Homematic Device manuell an. Da gibt es doch bestimmt eine Funktion mit der ich alle Geräte aus der CCU als FHEM Devices auf einen Schlag anlege - oder z.B. das auxh selektiv für nur einzelne Gerätetyp wie z.B. jalousie Aktoren. Geht so etwas?
Und dann noch eine allgemeine Frage: was sind readings? Und wie definiert man diese mit hmdev? Kann man das auxh automatisieren ? Bitte seht mir meine vielleicht blöden Fragen nach, aber in diesem langen Thread habe ich die Antworten leider nicht gefunden. Viele grüße Nic
von unterwegs gesendet
Zitat von: Nic0205 am 13 April 2016, 06:00:34
Was ich mich aber frage ist, ob es eine Art Best practice Ansatz gibt. Beispiel : Aktuell lege ich jedes einzelne Homematic Device manuell an. Da gibt es doch bestimmt eine Funktion mit der ich alle Geräte aus der CCU als FHEM Devices auf einen Schlag anlege - oder z.B. das auxh selektiv für nur einzelne Gerätetyp wie z.B. jalousie Aktoren. Geht so etwas?
Auf ein Autocreate aller CCU Devices in FHEM habe ich bewusst verzichtet, da dies bei größeren Homematic Installationen zu einer Flut von FHEM Devices geführt hätte. Du kannst aber z.B. ein Device für einen Fenstersensor anlegen und das dann mit dem FHEM Befehl "copy" kopieren. Danach musst Du in der Oberfläche von FHEM in der Detailansicht der Kopie nochmal auf "DEF" klicken und die Adresse bzw. den Namen entsprechend dem 2. Fenstersensor anpassen. Andere Möglichkeit wäre, fhem.cfg direkt anzupassen. Davon rate ich aber ab, gerade wenn man mit FHEM noch nicht so vertraut ist.
Best Practice aus meiner Sicht: Je Typ ein Device in FHEM definieren. Die anderen vom gleichen Typ mit copy anlegen und nachträglich die Adresse anpassen.
Übrigens: HMCCUxxx hat kein Problem damit, wenn sich mehrere FHEM-Devices auf ein CCU-Device beziehen. Ich habe z.B. die Steckdosen mit eingebautem Energiezähler im Einsatz. Dafür habe ich ein Read-Only Device mit HMCCUCHN definiert, das nur die Messwerte darstellt und ein weiteres mit HMCCUDEV, über das ich die Steckdose schalte.
Zitat
Und dann noch eine allgemeine Frage: was sind readings? Und wie definiert man diese mit hmdev? Kann man das auxh automatisieren ? Bitte seht mir meine vielleicht blöden Fragen nach, aber in diesem langen Thread habe ich die Antworten leider nicht gefunden.
Kein Thema, jeder fängt mal an. Readings sind veränderliche Werte eines Gerätes. Das können Messwerte wie Temperatur oder Luftfeuchte sein oder auch Zusände wie offen oder geschlossen. Bei HMCCU, HMCCUDEV und HMCCUCHN entsprechen die Readings den Datenpunkten und Konfigurationsparameter der CCU Devices. Die Readings werden automatisch generiert, wenn Du einen get Befehl ausführts oder der RPC-Server Updates von der CCU empfängt. Da einige Homematic Geräte sehr viele Datenpunkte / Parameter haben und meist nur wenige davon wirklich interessant sind, macht es sinn, diese mit dem Attribut ccureadingfilter zu filtern. Außerdem sollte man das Attribut event-on-change-reading auf .* setzen. Sonst werden eine Menge FHEM Events generiert und die Performance leidet.
Zitat von: Achiim am 12 April 2016, 23:52:25
Ich habe jetzt eine Lösung dank deiner Hinweise implementiert. Ausgenutzt habe ich dabei folgende Sachverhalte:
- rpcserver liefert unterschiedliche Werte bei update und bei einem echten Event aus der CCU ("1" bei echtem Tastendruck; "false" bei get c_WZ_Rolladen_... update)
- rpcserver aktualisiert die Readings sowohl bei echten Events als auch bei "get ... update" oder beim "Start des rpcserver"
Schön, dass es jetzt funktioniert. Nur um das nochmal klar zu stellen: Die Updates durch get Befehle und die Updates durch den RPC-Server sind 2 völlig verschiedene Dinge. Das läuft in der CCU in 2 getrennten Schichten ab. Ein "get update" oder auch ein "get datapoint" fragt in der CCU Logikschicht den Zustand von Datenpunkten ab und setzt die Readings in FHEM entsprechend.
Unterhalb der Logikschicht werkelt die RPC-Schicht. Diese schickt bei Änderungen an CCU Devices die geänderten Werte an alle registrierten RPC-Server (einer davon ist der von HMCCU). Die RPC-Schicht weiß nichts von der Logikschicht, kennt z.B. nicht mal die Namen der Geräte in der CCU sondern nur die Adressen.
Wenn Du jetzt z.B. mit "set datapoint" einen Wert in der Logikschicht änderst, merkt das die RPC-Schicht und schickt den geänderten Wert an die registrierten RPC-Server (u.a. HMCCU) zurück. D.h. Du setzt z.B. einen Wert mit set datapoint auf true und der RPC-Server erhält von der CCU quasi als Bestätigung 1 zurück.
Grundsätzlich sollten Nutzer von CUL_HM bei Fernbedienungen vor ähnlichen Fragestellungen stehen. Du könntest also mal in diesem Forum suchen, wie CUL_HM Nutzer diese Thematik (Notifies) gelöst haben.
Ich habe mal im cul_hm Forum nach der Problematik gesucht und folgendes gefunden: https://forum.fhem.de/index.php?topic=43726.0 (https://forum.fhem.de/index.php?topic=43726.0). Da versucht MiWe58 eigentlich genau das, was ich auch tun will. Homematic-Fernbedienung und nicht-Homematic-Rolladen über FHEM zu "verbinden". Also genau das, was eine Stärke von FHEM sein soll, auszunutzen. Die Lösung bestand allerdings darin, statt des notify DOIF zu verwenden. Davon hattest Du mir ja abgeraten...
Es mit cul_hm umzusetzten war auch mein erster Ansatz, der ist aber ähnlich gescheitert, wie es MiWe58 erlebt hat. Eine zufriedenstellende Lösung habe ich nicht hinbekommen. Zumal ich das damals ohne CCU versucht hatte und schon an der korrekten Konfiguration der HM-RC-Dis-H-x-EU gescheitert war. Mehr als 3-4 Tasten konnte ich beim besten Willen (und vielen Fehlversuchen) nicht konfigurieren.... Das mag ja auch an mir und meinen ungenügenden Kenntnissen über HM gelegen haben. Jetzt mit CCU2 und dem Modul HMCCU kommt FHEM seinem Anspruch als Integrator eigentlich inkompatibler Systeme zu agieren wieder einen ganzen Schritt näher...
Erkenntnisse zur Verwendung von Fernbedienungen:
Ich habe nun mal den 2-fach Taster HM-PB-2-WM55 mit HMCCUDEV getestet.
1. Alle Datenpunkte (PRESS_SHORT, PRESS_LONG usw.) haben die Flags Write und Event, nicht jedoch Read gesetzt (s.a. get deviceinfo). Bedeutet: Ein get update liefert undefinierte bzw. unzuverlässige Ergebnisse, da ein explizites Lesen der Datenpunkte nicht erlaubt ist. Man ist also darauf angewiesen, dass die CCU Zustandsänderungen als Event an den RPC-Server schickt.
2. Die CCU schickt beim Drücken der Tasten am Taster nur dann Events, wenn die Tasten mit einem anderen Gerät verknüpft sind oder in einem CCU-Programm verwendet werden. Dieses Verhalten ist bekannt und einige User legen sich in der CCU Dummy-Programme an, die die Tastenzustände abfragen und eine Systemvariable auf irgendeinen Wert setzen um das Senden von Events zu erzwingen.
3. Die Events der CCU (z.B. zu PRESS_SHORT oder PRESS_LONG) enthalten immer eine 1 = Taste gedrückt. Einen Event "Taste nicht gedrückt" gibt es nicht. Konsequenz: event-on-change-reading darf nicht verwendet werden, stattdessen besser event-on-update-reading.
4. Die Datenpunkte PRESS_CONT und PRESS_LONG_RELEASE haben zumindest bei HM-PB-2-WM55 keine Funktion.
5. Bei jedem Tastendruck wird der Datenpunkt / Reading INSTALL_TEST mit 1 aktualisiert (könnte man auch als Tastendruckerkennung im Notify nutzen)
6. Ich würde für jede Taste bzw. jeden Kanal einer Fernbedienung ein HMCCUCHN Device definieren. Das hat den Vorteil, dass man den Zustand einer Taste über STATE darstellen kann.
In der nächsten Version wird der get update Befehl nur noch Datenpunkte / Readings aktualisieren, die das Flag "Readable" gesetzt haben. Damit dürften bei get update in Zusammenhang mit Fernbedienungen keine Probleme mehr auftreten.
Ein kleines Beispiel (Taste 1 = CCU Kanal FB-BA-1):
define HM_FB_BA_1 HMCCUCHN FB-BA-1
attribute HM_FB_BA_1 substitute 1:pressed
attribute HM_FB_BA_1 statedatapoint PRESS_SHORT
attribute HM_FB_BA_1 statevals press:true
Setzt STATE/state auf "pressed" wenn die Taste kurz gedrückt wird. Taste kann mit dem Befehl "set HM_FB_BA_1 press" kurz gedrückt werden.
Erkenntnisse zu Rauchmelder-Teams:
1. Rauchmelder-Teams sind keine CCU-Gruppen, sondern "Teams" ;-). Dementsprechend kann ein Rauchmelderteam in HMCCU bzw. HMCCUDEV nicht als Gruppen-Device (Zusatz group=...) angelegt werden. Das Anlegen einer reinen HMCCUDEV Gruppe ohne Bezug zur CCU ist zwar möglich, m.E. aber nicht sinnvoll.
2. Rauchmelder-Teams werden in der CCU wie ein eigener Gerätetyp behandelt. Die Adresse eines Teams ist die Adresse des Master-Rauchmelders mit einem Sternchen (*) davor. Momentan unterstützt HMCCU diese speziellen Adressen nicht. In der nächsten Version wird das aber der Fall sein.
3. Die Verwendung einzelner Rauchmelder wird jetzt schon von HMCCU uneingeschränkt unterstützt.
Hallo zap,
ich habe gerade einmal versucht meinen Raumthermostaten (noch den alten) einzubinden, scheitere aber irgendwie daran.
Bei State wird mir folgendes angezeigt:
Wohnzimmer_Heizung
T: Wohnzimmer_Heizung.1.TEMPERATURE° H: Wohnzimmer_Heizung.1.HUMIDITY% D: Wohnzimmer_Heizung.2.SETPOINT° P: n/a°
Meine config sieht so aus:
attr Wohnzimmer_Heizung IODev d_ccu
attr Wohnzimmer_Heizung ccureadingfilter (^HUMIDITY|^TEMPERATURE|^SETPOINT|^LOWBAT$|^WINDOW_OPEN|^UNREACH)
attr Wohnzimmer_Heizung controldatapoint Wohnzimmer_Heizung.SETPOINT
attr Wohnzimmer_Heizung devStateIcon OK:10px-kreis-gruen Error:10px-kreis-rot Initialized:10px-kreis-gelb
attr Wohnzimmer_Heizung event-on-change-reading .*
attr Wohnzimmer_Heizung stateFormat T: Wohnzimmer_Heizung.1.TEMPERATURE° H: Wohnzimmer_Heizung.1.HUMIDITY% D: Wohnzimmer_Heizung.2.SETPOINT° P: DEWPOINT°
attr Wohnzimmer_Heizung statechannel 2
attr Wohnzimmer_Heizung stripnumber 1
attr Wohnzimmer_Heizung substitute LOWBAT!(0|false):no,(1|true):yes;;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed
attr Wohnzimmer_Heizung userReadings DEWPOINT {HMCCU_Dewpoint($name,"Wohnzimmer_Heizung.1.TEMPERATURE", "Wohnzimmer_HeizungH.1.HUMIDITY","n/a")}
Kannst Du erkennen, was ich falsch mache?
Und wie würde ich den "statedatapoint" richtig setzen?
Ich hoffe Du kannst mir nochmal helfen.
Viele Grüße
Nic
Zitat von: Nic0205 am 15 April 2016, 06:25:03
Hallo zap,
ich habe gerade einmal versucht meinen Raumthermostaten (noch den alten) einzubinden, scheitere aber irgendwie daran.
Hallo Nic,
ich brauche den Typ des Thermostaten. Der wird in der Detailansicht des FHEM Devices im Feld "Internals" als "ccutype" angezeigt.
Wenn möglich noch die Ausgabe von "get Wohnzimmer_Heizung deviceinfo"
Hier die daten:
ccutype: HM-CC-TC
Ubd hier Device Info:
CHN IEQ0171822:0 Heizung Wohnzimmer:0 DPT {b} BidCos-RF.IEQ0171822:0.UNREACH = false [RE] DPT {b} BidCos-RF.IEQ0171822:0.STICKY_UNREACH = false [RWE] DPT {b} BidCos-RF.IEQ0171822:0.CONFIG_PENDING = false [RE] DPT {b} BidCos-RF.IEQ0171822:0.LOWBAT = false [RE] DPT {8} BidCos-RF.IEQ0171822:0.RSSI_DEVICE = 1 [RE] DPT {8} BidCos-RF.IEQ0171822:0.RSSI_PEER = 180 [RE] CHN IEQ0171822:1 Raumklima Wohnzimmer DPT {f} BidCos-RF.IEQ0171822:1.TEMPERATURE = 19.000000 [RE] DPT {i} BidCos-RF.IEQ0171822:1.HUMIDITY = 57 [RE] CHN IEQ0171822:2 Soll Temperatur Wohnzimmer DPT {f} BidCos-RF.IEQ0171822:2.SETPOINT = 19.000000 [RWE] DPT {i} BidCos-RF.IEQ0171822:2.ADJUSTING_COMMAND = 0 [RE] DPT {i} BidCos-RF.IEQ0171822:2.ADJUSTING_DATA = 3 [RE] DPT {b} BidCos-RF.IEQ0171822:2.STATE = [W]
OK
von unterwegs gesendet
Also grundsätzlich falsch ist da nichts (außer das Attribut controldatapoint). Werden denn die Readings gesetzt/angzeigt (z.B. Wohnzimmer_Heizung.1.TEMPERATURE) ?
Für die Attribute hätte ich noch folgende Tipps:
attr Wohnzimmer_Heizung ccureadingfilter (^HUMIDITY|^TEMPERATURE|^SETPOINT|^LOWBAT$|^UNREACH)
attr Wohnzimmer_Heizung statedatapoint SETPOINT
attr Wohnzimmer_Heizung controldatapoint 2.SETPOINT
attr Wohnzimmer_Heizung statevals on:100.0,off:0.0
Der Datenpunkt SETPOINT akzeptiert 2 spezielle Werte: 0=Ventil zu, 100=Ventil komplett offen. Ansonsten geht der Wertebereich von 6 bis 30 Grad. Daher die Empfehlung mit dem Attribut statevals. Dann kannst Du z.B. mit "set Wohnzimmer_Heizung off" das Ventil komplett schließen.
Hallo,
kann einer von Euch Spezialisten einem verzweifelnden Newbie bitte erklären, wie man an einen Dimmer einen Drehknopf drangenagelt bekommt?
Ich habe mich schon tot gegoogelt, komme aber leider nicht weiter.
Mein letzter kläglicher Versuch ging so:
attr SZDimmer webCmd state
attr SZDimmer widgetOverride state:knob,min:0,max:1,step:0.1,lineup:round
attr SZDimmer statevals state:.*
Das zeigt mir zwar den Drehknopf an, aber jetzt weiß ich nicht, was ich bei statevals angeben muss, damit der Wert auch zurück geschossen wird.
Ich check das nicht.
Danke für Hilfe!
Normalerweise sollte ein Dimmer einen Datenpunkt LEVEL haben, über den die Helligkeit gesteuert wird. Das kannst Du mit dem Befehl "get SZDimmer deviceinfo" rausbekommen, der Dir alle Datenpunkte Deines Devices anzeigt.
Angenommen, Dein Dimmer hat einen Datenpunkt LEVEL in Kanal 1, sollte folgendes funktionieren:
attr SZDimmer controldatapoint 1.LEVEL
attr SZDimmer statechannel 1
attr SZDimmer statedatapoint LEVEL
attr SZDimmer statevals on:1.0,off:0.0
attr SZDimmer webCmd control
attr SZDimmer widgetOverride control:knob,min:0,max:1,step:0.1,lineup:round
Das Attribut statevals ermöglicht Dir in diesem Fall, den Dimmer mit "set SZDimmer on/off" komplett ein- oder auszuschalten.
Zitat
1. Alle Datenpunkte (PRESS_SHORT, PRESS_LONG usw.) haben die Flags Write und Event, nicht jedoch Read gesetzt (s.a. get deviceinfo). Bedeutet: Ein get update liefert undefinierte bzw. unzuverlässige Ergebnisse, da ein explizites Lesen der Datenpunkte nicht erlaubt ist. Man ist also darauf angewiesen, dass die CCU Zustandsänderungen als Event an den RPC-Server schickt.
Das ist auch so bei meiner Fernbedieung (
HM-RC-Dis-H-x-EU). Siehe den Output von deviceinfo:
CHN MEQ0670565:0 HM-Fernbedienung:0
DPT {b} BidCos-RF.MEQ0670565:0.UNREACH = false [RE]
DPT {b} BidCos-RF.MEQ0670565:0.STICKY_UNREACH = false [RWE]
DPT {b} BidCos-RF.MEQ0670565:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.MEQ0670565:0.LOWBAT = false [RE]
DPT {8} BidCos-RF.MEQ0670565:0.RSSI_DEVICE = 1 [RE]
DPT {8} BidCos-RF.MEQ0670565:0.RSSI_PEER = 197 [RE]
DPT {b} BidCos-RF.MEQ0670565:0.DEVICE_IN_BOOTLOADER = false [RE]
DPT {b} BidCos-RF.MEQ0670565:0.UPDATE_PENDING = false [RE]
DPT {8} BidCos-RF.MEQ0670565:0.AES_KEY = 0 [R]
CHN MEQ0670565:1 Stehlampe an-dim:1
DPT {b} BidCos-RF.MEQ0670565:1.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.MEQ0670565:1.PRESS_LONG = false [WE]
DPT {b} BidCos-RF.MEQ0670565:1.INSTALL_TEST = false [E]
DPT {b} BidCos-RF.MEQ0670565:1.PRESS_CONT = false [E]
DPT {b} BidCos-RF.MEQ0670565:1.PRESS_LONG_RELEASE = false [E]
...
Zitat
In der nächsten Version wird der get update Befehl nur noch Datenpunkte / Readings aktualisieren, die das Flag "Readable" gesetzt haben. Damit dürften bei get update in Zusammenhang mit Fernbedienungen keine Probleme mehr auftreten.
Prima. Das wäre genau das, was ich brauche. Dann beeinflusst, ein get update auch nicht mehr vorhandene notifies, die auf Readings lauschen....
Hallo zap,
ZitatAlso grundsätzlich falsch ist da nichts (außer das Attribut controldatapoint). Werden denn die Readings gesetzt/angzeigt (z.B. Wohnzimmer_Heizung.1.TEMPERATURE) ?
ich mache mal einen Screenshot, wie es aussieht, irgendwie passt der State nicht.
Zitat von: zap am 15 April 2016, 18:32:45
Normalerweise sollte ein Dimmer einen Datenpunkt LEVEL haben, über den die Helligkeit gesteuert wird. Das kannst Du mit dem Befehl "get SZDimmer deviceinfo" rausbekommen, der Dir alle Datenpunkte Deines Devices anzeigt.
Angenommen, Dein Dimmer hat einen Datenpunkt LEVEL in Kanal 1, sollte folgendes funktionieren:
attr SZDimmer controldatapoint 1.LEVEL
attr SZDimmer statechannel 1
attr SZDimmer statedatapoint LEVEL
attr SZDimmer statevals on:1.0,off:0.0
attr SZDimmer webCmd control
attr SZDimmer widgetOverride control:knob,min:0,max:1,step:0.1,lineup:round
Das Attribut statevals ermöglicht Dir in diesem Fall, den Dimmer mit "set SZDimmer on/off" komplett ein- oder auszuschalten.
Danke zap!
So funktioniert's.
Das mit dem statedatapoint hatte ich schon rausgefunden. Aber nicht das mit dem controldatapoint.
Warum muss ich bei controldatapoint 1.LEVEL angeben und bei statedatapoint nur LEVEL?
VG Alex
P.S.: Die beschriebene Methode scheint auch nur zu funktionieren, wenn man das Gerät mit HMCCUDEV definiert. Mit HMCCUCHN geht's nicht.
Zitat von: Nic0205 am 15 April 2016, 22:23:53
Hallo zap,
ich mache mal einen Screenshot, wie es aussieht, irgendwie passt der State nicht.
Ah ja! Die Attribute stateformat und userreadings sind falsch. In beiden Attributen musst Du die Reading-Namen so verwenden, wie sie in FHEM angezeigt werden. stateformat ersetzt einfach die Readingnamen durch die Werte. So sollte es funktionieren:
attr Wohnzimmer_Heizung stateFormat T: Raumklima_Wohnzimmer.TEMPERATURE° H: Raumklima_Wohnzimmer.HUMIDITY% D: Soll_Temperatur_Wohnzimmer.SETPOINT° P: DEWPOINT°
attr Wohnzimmer_Heizung userReadings DEWPOINT {HMCCU_Dewpoint($name,"Raumklima_Wohnzimmer.TEMPERATURE", "Raumklima_Wohnzimmer.HUMIDITY","n/a")}
Zitat von: aski71 am 15 April 2016, 23:40:46
Danke zap!
So funktioniert's.
Das mit dem statedatapoint hatte ich schon rausgefunden. Aber nicht das mit dem controldatapoint.
Warum muss ich bei controldatapoint 1.LEVEL angeben und bei statedatapoint nur LEVEL?
Weil die Attribute statedatapoint und statechannel älter sind. controldatapoint habe ich erst später eingeführt und da beide Angaben in einem Attribut zusammengelegt. Werde ich vielleicht bei statedatapoint noch einbauen, ist aber nicht so einfach, da die Abwärtskompatibilität gewährleistet sein muss. Grund für 2 unterschiedliche Attribute ist, dass einige Homematic Geräte unterschiedliche Datenpunkte für das Setzen und Lesen von Werten verwenden (z.B. Thermostate).
Zitat
P.S.: Die beschriebene Methode scheint auch nur zu funktionieren, wenn man das Gerät mit HMCCUDEV definiert. Mit HMCCUCHN geht's nicht.
Grundsätzlich ist HMCCUCHN eine auf einen Kanal limitierte Variante von HMCCUDEV. Auch funktional ist das nicht so umfangreich wie HMCCUDEV. Das Attribut controldatapoint wird aber unterstützt. Da der Kanal bei HMCCUCHN bereits durch das Define festgelegt ist, wird bei controldatapoint nur der Datenpunkt ohne die Kanalnummer davor angegeben. Beispiel:
Bei HMCCUDEV: controldatapoint 1.LEVEL
Bei HMCCUCHN: controldatapoint LEVEL
Diese Inkonsistenz mit state und control ist mir auch schon aufgefallen. Um die Abwärsksompatibilität und auch Transparenz für den Benutzer zu sichern, könnte auch folgendes gemacht werden:
statedatapoint ... wie bisher
statechannel ... wie bisher
controldatapoint ... unterstützt Eingaben mit und ohne Kanalnummer
controlchannel ... neu, legt den Kanal des controldatapoint fest (und überschreibt ggf. die im controldatapoint definierte Kanalnummer)
Dann könnte man auch den Sonderfall
Zitat
Grund für 2 unterschiedliche Attribute ist, dass einige Homematic Geräte unterschiedliche Datenpunkte für das Setzen und Lesen von Werten verwenden (z.B. Thermostate).
mit diesen Attributen transparent für den Anwender beschreiben.
Wie kann ein Ralladenaktor: Funk- Jalousieaktor HM-LC-Bl1PBU-FM über HMCCU... gesteuert werden?
Ich habe folgende Readings beim HMCCUDEV:
Readings:
2016-04-16 21:36:29 AZ-Rolladen.0.AES_KEY 0
2016-04-16 21:36:29 AZ-Rolladen.0.CONFIG_PENDING false
2016-04-16 21:36:29 AZ-Rolladen.0.DEVICE_IN_BOOTLOADER false
2016-04-16 21:36:29 AZ-Rolladen.0.DUTYCYCLE false
2016-04-16 21:36:29 AZ-Rolladen.0.RSSI_DEVICE 189
2016-04-16 21:36:29 AZ-Rolladen.0.RSSI_PEER 196
2016-04-16 21:36:29 AZ-Rolladen.0.STICKY_UNREACH false
2016-04-16 21:36:29 AZ-Rolladen.0.UNREACH false
2016-04-16 21:36:29 AZ-Rolladen.0.UPDATE_PENDING false
2016-04-16 21:36:29 AZ-Rolladen.1.DIRECTION 0
2016-04-16 21:36:29 AZ-Rolladen.1.INHIBIT false
2016-04-16 21:36:29 AZ-Rolladen.1.INSTALL_TEST N/A
2016-04-16 21:36:29 AZ-Rolladen.1.LEVEL 0.720000
2016-04-16 21:36:29 AZ-Rolladen.1.STOP N/A
2016-04-16 21:36:29 AZ-Rolladen.1.WORKING false
2016-04-16 23:59:42 state OK
In der Schnittstellenbeschreibung finde ich zusätzlich die Erläuterung für den Parameter DIRECTION:
Parameter DIRECTION lesend
Werteliste:
0 = NONE (Standard)
1 = UP
2 = DOWN
3 = UNDEFINED
Kann man damit irgendwie die Funktionen: UP, DOWN und STOP umsetzen? Bisher kann ich nur On und Off über das Reading LEVEL setzen....
Grundsätzlich sollte LEVEL=50 den Rolladen auf halbe Höhe fahren. Voraussetzung ist, dass der Rolladen kalibiriert ist, d.h. die richtige Fahrtzeit eingestellt ist. Funktioniert das?
Außerdem kann man wohl in den Geräteeinstellungen in der CCU 2 interne Schalter aktivieren, über die dann die Steuerung erfolgt. Danach sollte get deviceinfo mehr Datenpunkte liefern.
Leider alles Theorie, da meine Rolladenschalter aufgrund von Umbauarbeiten derzeit ausgebaut sind.
Da mich einige Nachfragen erreicht haben, wann denn die neue Version mit dem versprochenen internen RPC Server kommt, hier mal ein kurzes Update nach 2 Tagen zeit- und nervenintensivem Testen mit internen RPC Prozessen unter Verwendung des Moduls SubProcess.pm:
Grundsätzlich läuft es nun ohne ccurpcd.pl. Die in SubProcess.pm eingebaute Interprozess Kommunikation scheitert jedoch, wenn zu viele Homematic Geräte benutzt werden. FHEM scheint die Daten von der CCu in seiner Read-Schleife nicht schnell genug verarbeiten zu können. Dadurch gehen Events der CCU verloren. Das darf natürlich nicht sein. Ich teste beim mir mit 45 Devices, ca. 350 Kanälen und einer vermutlich mittleren 4 Stelligen Zahl an Datenpunkten. Entsprechend viele Events schickt die CCU. Mein Fazit: Für sowas ist Perl einfach nicht geeignet.
Die Version 3.2 wird also (zunächst optional) ohne ccurpcd.pl auskommen. Subprocess.pm wird dann für die Ausführung der RPC Serverprozesse verwendet, nicht jedoch für die interne Kommunikation. Die wird weiter über die Filequeues laufen. Das läuft stabil und skaliert gut.
ZitatGrundsätzlich sollte LEVEL=50 den Rolladen auf halbe Höhe fahren. Voraussetzung ist, dass der Rolladen kalibiriert ist, d.h. die richtige Fahrtzeit eingestellt ist. Funktioniert das?
Ja, das geht. Allerdings ist bei mir der obere und der untere Endpunkt vertauscht. Wenn der Rolladen komplett offen ist, dann wird er in der CCU als komplett geschlossen angezeigt... Ist das
falsch verkabelt oder
falsch parametriert? Siehe Bild:
ZitatAußerdem kann man wohl in den Geräteeinstellungen in der CCU 2 interne Schalter aktivieren, über die dann die Steuerung erfolgt. Danach sollte get deviceinfo mehr Datenpunkte liefern.
Ich habe in der CCU2 einmal auf "Experten-Mode" umgestellt. Ich vermute mal, das war gemeint. Hierzu habe ich in der Benutzerverwaltung die Checkbox ,,Modus vereinfachte Verknüpfungskonfiguration aktivieren" deaktiviert. Danach habe ich bei HMCCU die Deviceliste neu eingelesen und bei meinem Rolladen das HMCCUDEV mit get update neu gelesen.
=>
keine neuen, erweiterten Readings sichtbar....
Dass beim LEVEL Datenpunkt oben und unten vertauscht ist, ist bekannt. In CUL_HM gibt es dafür extra eine Option, um das zu vertauschen. Aber ich hatte ja schon meine Abneigung gegen Speziallösungen für einzelne Geräte erwähnt ;-) Mal sehen ...
Hier mal einige Infos zu dem Teil:
http://www.fhemwiki.de/wiki/HM-LC-Bl1PBU-FM_Unterputz-Jalousieaktor
Im Prinzip kennt CUL_HM auch nicht mehr Readings. Ich schaue mir das mal in 10_CUL_HM.pm an.
UPDATE: Womöglich kann man gar nicht angeben, ob er hoch oder runter fahren soll. Im Prinzip reicht LEVEL ja aus. Es sein denn, man möchte während der Fahrt abbrechen.
UPDATE2: Das Abbrechen der Fahrt geht vermutlich über den Datenpunkt STOP (Write Only). Der Datentyp ist ACTION, die Frage ist, welcher Wert die Fahrt stoppt.
UPDATE3: Du solltest die Fahrt eines Rolladens mit "set AZ-Rolladen 1.STOP true" abbrechen können. Starten der Fahrt wie gesagt mit LEVEL. Etwas vereinfacht:
attr AZ-Rolladen statechannel 1
attr AZ-Rolladen statedatapoint LEVEL
attr AZ-Rolladen statevals up:100,down:0
Dann dürfte folgendes möglich sein:
set AZ-Rolladen up
set AZ-Rolladen down
set AZ-Rolladen devstate 50
Ich habe den Rolladen wie folgt definiert:
Internals:
CFGFN
DEF AZ-Rolladen 1
IODev myHomematicCCU
NAME Arbeitszimmer_Rolladen
NR 3305
STATE 1.0
TYPE HMCCUDEV
ccuaddr LEQ1032012
ccudevstate Active
ccuif BidCos-RF
ccuname AZ-Rolladen
ccutype HM-LC-Bl1PBU-FM
channels 2
statevals devstate|up|down
Readings:
2016-04-17 19:52:13 AZ-Rolladen.0.AES_KEY 0
2016-04-17 19:52:13 AZ-Rolladen.0.CONFIG_PENDING false
2016-04-17 19:52:13 AZ-Rolladen.0.DEVICE_IN_BOOTLOADER false
2016-04-17 19:52:13 AZ-Rolladen.0.DUTYCYCLE false
2016-04-17 19:52:13 AZ-Rolladen.0.RSSI_DEVICE 189
2016-04-17 19:52:13 AZ-Rolladen.0.RSSI_PEER 196
2016-04-17 19:52:13 AZ-Rolladen.0.STICKY_UNREACH true
2016-04-17 19:52:13 AZ-Rolladen.0.UNREACH false
2016-04-17 19:52:13 AZ-Rolladen.0.UPDATE_PENDING false
2016-04-17 19:52:13 AZ-Rolladen.1.DIRECTION 0
2016-04-17 19:52:13 AZ-Rolladen.1.INHIBIT false
2016-04-17 19:52:13 AZ-Rolladen.1.INSTALL_TEST N/A
2016-04-17 19:52:13 AZ-Rolladen.1.LEVEL 1.0
2016-04-17 19:52:13 AZ-Rolladen.1.STOP N/A
2016-04-17 19:52:13 AZ-Rolladen.1.WORKING false
2016-04-17 19:52:13 control 1.0
2016-04-17 19:52:13 state 1.0
Attributes:
IODev myHomematicCCU
controldatapoint 1.LEVEL
group Arbeitszimmer
icon fts_shutter_1w
room 02_Oben,HMCCU
statechannel 1
statedatapoint LEVEL
statevals up:0.0,down:1.0
stripnumber 1
webCmd control
widgetOverride control:slider,0,0.050000,1,1
"set Arbeitszimmer_Rolladen 1.STOP true" oder "set Arbeitszimmer_Rolladen AZ-Rolladen.1.STOP true" liefert leider:
HMCCUDEV: Unknown argument 1.STOP, choose one of config control datapoint devstate up down toggle
oder
HMCCUDEV: Unknown argument AZ-Rolladen.1.STOP, choose one of config control datapoint devstate up down toggle
Hallo zap,
ich versuche gerade, das Schalten des CONTROL_MODE bei einem Heizkörperthermostat HM-CC-RT-DN einzurichten. Ich scheitere daran, dass ich einerseits 1.CONTROL_MODE [RE] lesen kann, aber andererseits 1.AUTO_MODE [W], 1.MANU_MODE [W] oder 1.BOOST_MODE [W] schalten muss. Kannst Du mir bitte zeigen, wie das geht?
Danke und viele Grüße
define HM_Control_Mode HMCCUDEV HM_Gruppe group=HM-CC-RT-DN
attr HM_Control_Mode IODev HM_CCU2
attr HM_Control_Mode ccureadingfilter HM_Gruppe:1!(CONTROL_MODE),HM-CC-RT-DN:4!(CONTROL_MODE)
attr HM_Control_Mode controldatapoint 1.CONTROL_MODE
attr HM_Control_Mode event-on-change-reading .*
attr HM_Control_Mode mapdatapoints HM-CC-RT-DN:4.CONTROL_MODE=HM_Gruppe:1.CONTROL_MODE
attr HM_Control_Mode stateFormat HM_Gruppe.1.CONTROL_MODE
attr HM_Control_Mode substitute CONTROL_MODE!(0):Auto,(1):Manu,(2):Party,(3):Boost
attr HM_Control_Mode webCmd control
attr HM_Control_Mode widgetOverride control:uzsuSelectRadio,Auto,Manu,Boost
Zitat von: Achiim am 17 April 2016, 20:00:45
"set Arbeitszimmer_Rolladen 1.STOP true" oder "set Arbeitszimmer_Rolladen AZ-Rolladen.1.STOP true" liefert leider:
HMCCUDEV: Unknown argument 1.STOP, choose one of config control datapoint devstate up down toggle
oder
HMCCUDEV: Unknown argument AZ-Rolladen.1.STOP, choose one of config control datapoint devstate up down toggle
Du musst dem Device schon sagen, welchen Befehl es ausführen soll, wenn Du nur einen Datenpunkt angibst (in dem Fall "datapoint"):
set Arbeitszimmer_Rolladen datapoint 1.STOP true
Falls es mit "true" nicht tut, versuche "1".
Für die Attribute: Bist Du sicher, dass LEVEL im Bereich 0-1 liegt und nicht 0-100 ?
LEVEL ist beim Blind 0 .. 1 und zwar als Float!
Zitat von: cho am 17 April 2016, 21:13:54
Hallo zap,
ich versuche gerade, das Schalten des CONTROL_MODE bei einem Heizkörperthermostat HM-CC-RT-DN einzurichten. Ich scheitere daran, dass ich einerseits 1.CONTROL_MODE [RE] lesen kann, aber andererseits 1.AUTO_MODE [W], 1.MANU_MODE [W] oder 1.BOOST_MODE [W] schalten muss. Kannst Du mir bitte zeigen, wie das geht?
Da muss ich Dich - momentan - leider enttäuschen. Das geht so nicht. Das Problem ist, dass sich in Deinem Fall 1 Steuerelement (die Radio Buttons) auf 3 Datenpunkte beziehen. control und controldatapoint sind aber dafür gedacht, den Werte für genau einen Datenpunkt per Widget einzustellen. Wenn also z.B. die Zieltemperatur per Radio-Button einstellen wolltest, würde das so aussehen (Devicename habe ich weggelassen):
attr controldatapoint 2.SET_TEMPERATURE
attr widgetOverride control:uzsuSelectRadio,20,25,30
Aber mal sehen. Vielleicht fällt mir ja noch was ein dazu.
UPDATE: Zwar nicht unbedingt das, was Du möchtest, aber zumindest etwas komfortabler (Devicename muss nach attr noch ergänzt werden):
attr eventmap /datapoint 2.AUTO_MODE 1:Auto/datapoint 2.BOOST_MODE 1:Boost/
attr controldatapoint 2.SET_TEMPERATURE
attr webCmd control:Auto:Boost
attr widgetOverride control:slider,10,1,25
Damit steht Dir in der Geräteübersicht in FHEM ein Slider für die Zieltemperatur zur Verfügung. Neben dem Slider Werden Links "Auto" und "Boost" angezeigt. Außerdem kennt FHEM dann die Befehle set Auto und set Boost.
Statt den Links kann man sich auch Icons anzeigen lassen:
attr cmdIcon Auto:sani_heating_automatic Boost:sani_heating_boost
Das sieht dann aus wie im Anhang (wobei die Icons anklickbar sind und dann den Mode einstellen)
Ach ja: aufpassen! Die richtigen Kanalnummern verwenden. Ich bin von einem Wandthermostaten ausgegangen. Da liegen die Datenpunkte in Kanal 2. Könnte bei Dir anders sein bzw. wenn ich das richtig gesehen habe, ist es bei Dir Kanal 1.
Der MANU_MODE fehlt mit Absicht. Dieser Modus wird nämlich aktiviert, indem man dem Datenpunkt MANU_MODE eine Temperatur zuweist. Um die Sache noch komplizierter zu machen, gibt es die speziellen Temperaturen 4.5 und 30.5. Erstere dreht das Ventil komplett zu während letztere das Ventil zu 100% öffnet (also im Prinzip ein on und off).
Das könnte man ausnutzen und sich noch mit eventmap einen on und off Befehl bauen sowie einen Manu Befehl, der die Temperatur auf 20 Grad einstellt:
attr eventmap /datapoint 2.AUTO_MODE 1:Auto/datapoint 2.BOOST_MODE 1:Boost/datapoint 2.MANU_MODE 4.5:off/datapoint 2.MANU_MODE 30.5:on/datapoint 2.MANU_MODE 20:Manu/
attr cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
attr webCmd control:Auto:Boost:Manu:on:off
Hallo zap,
ich habe mir eben mal die aktuellen Dateien gedownloaded.
Jetzt geht bei mir der RPC Server gar nicht mehr.
So sehen die Logs aus:
ccurpc
17.04.2016 20:57:07 Entering server loop. Use kill -SIGINT 28332 to terminate program
17.04.2016 20:57:12 ListDevices
17.04.2016 20:57:14 NewDevice: received 220 device specifications
17.04.2016 21:01:31 Received 250 events from CCU since last check
17.04.2016 21:05:14 RPC server terminated
17.04.2016 21:05:14 RPC server received 445 (447) events
17.04.2016 21:06:43 Creating file queue
17.04.2016 21:06:43 Initializing RPC server
17.04.2016 21:06:44 Callback server created listening on port 7401
17.04.2016 21:06:44 Adding callback for events
17.04.2016 21:06:44 Adding callback for new devices
17.04.2016 21:06:44 Adding callback for deleted devices
17.04.2016 21:06:44 Adding callback for modified devices
17.04.2016 21:06:44 Adding callback for replaced devices
17.04.2016 21:06:44 Adding callback for readded devices
17.04.2016 21:06:44 Entering server loop. Use kill -SIGINT 1221 to terminate program
17.04.2016 21:06:46 ListDevices
17.04.2016 21:06:50 NewDevice: received 220 device specifications
17.04.2016 21:10:43 Received 250 events from CCU since last check
18.04.2016 19:58:50 RPC server terminated
18.04.2016 19:58:50 RPC server received 616 (618) events
fhemlog:
2016.04.17 20:56:53 0: Server started with 26 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 28314)
2016.04.17 20:56:53 3: ipc fronthem:127.0.0.1:52732 (ws): ws alive with pid 28315
2016.04.17 20:57:05 0: HMCCU: RPC server started with pid 28332
2016.04.17 20:57:12 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.17 20:57:13 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.17 20:57:18 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.17 20:59:37 1: HMCCUCHN: Arbeitszimmer_Fenster Execution of CCU script or command failed
2016.04.17 21:03:06 1: HMCCUCHN: Bad_Fenster Execution of CCU script or command failed
2016.04.17 21:04:50 1: in DEFINED
2016.04.17 21:04:58 1: in SAVE
2016.04.17 21:05:14 1: in SHUTDOWN
2016.04.17 21:05:14 0: Server shutdown
2016.04.17 21:05:14 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.17 21:05:14 0: HMCCU: Stopping RPC server CB2001 with PID 28332
2016.04.17 21:05:14 0: HMCCU: Stopping RPC server with PID 28332
2016.04.17 21:05:46 1: Including fhem.cfg
2016.04.17 21:05:46 3: telnetPort: port 7072 opened
2016.04.17 21:05:48 3: WEB: port 8083 opened
2016.04.17 21:05:48 3: WEBphone: port 8084 opened
2016.04.17 21:05:48 3: WEBtablet: port 8085 opened
2016.04.17 21:06:00 2: eventTypes: loaded 117 events from ./log/eventTypes.txt
2016.04.17 21:06:02 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2827, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2827, <$fh> line 40.
2016.04.17 21:06:24 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.17 21:06:24 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2016.04.17 21:06:25 1: Including ./log/fhem.save
2016.04.17 21:06:26 1: in INITIALIZED
2016.04.17 21:06:26 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.17 21:06:26 1: usb create starting
2016.04.17 21:06:27 3: Probing CUL device /dev/ttyAMA0
2016.04.17 21:06:27 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.17 21:06:27 1: usb create end
2016.04.17 21:06:27 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.17 21:06:27 0: Featurelevel: 5.7
2016.04.17 21:06:27 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 900)
2016.04.17 21:06:27 3: ipc fronthem:127.0.0.1:44803 (ws): ws alive with pid 1050
2016.04.17 21:06:39 0: HMCCU: RPC server started with pid 1221
2016.04.17 21:06:46 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.17 21:06:47 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.17 21:06:52 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.17 21:25:31 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.18 19:58:50 1: in SHUTDOWN
2016.04.18 19:58:50 0: Server shutdown
2016.04.18 19:58:50 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.18 19:58:50 0: HMCCU: Stopping RPC server CB2001 with PID 1221
2016.04.18 19:58:50 0: HMCCU: RPC server not running
2016.04.18 19:59:21 1: Including fhem.cfg
2016.04.18 19:59:21 3: telnetPort: port 7072 opened
2016.04.18 19:59:23 3: WEB: port 8083 opened
2016.04.18 19:59:23 3: WEBphone: port 8084 opened
2016.04.18 19:59:23 3: WEBtablet: port 8085 opened
2016.04.18 19:59:23 2: eventTypes: loaded 128 events from ./log/eventTypes.txt
2016.04.18 19:59:25 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 40.
2016.04.18 19:59:48 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.18 19:59:48 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2016.04.18 19:59:49 1: Including ./log/fhem.save
2016.04.18 19:59:49 1: in INITIALIZED
2016.04.18 19:59:49 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.18 19:59:49 1: usb create starting
2016.04.18 19:59:50 3: Probing CUL device /dev/ttyAMA0
2016.04.18 19:59:50 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.18 19:59:50 1: usb create end
2016.04.18 19:59:50 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.18 19:59:50 0: Featurelevel: 5.7
2016.04.18 19:59:50 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 912)
2016.04.18 19:59:50 3: ipc fronthem:127.0.0.1:46817 (ws): ws alive with pid 1046
2016.04.18 20:01:04 0: HMCCU: RPC server started with pid 1302
RPCQueue.pm did not return a true value at ./FHEM/ccurpcd.pl line 42.
BEGIN failed--compilation aborted at ./FHEM/ccurpcd.pl line 42.
2016.04.18 20:01:10 0: HMCCU: All RPC servers stopped
Ich nehme an, Du hast entweder ccurpcd.pl oder RPCQueue.pm nicht korrekt über den Download Link herunter geladen. Du musst die Dateien anzeigen lassen und dann links oben "download this file" auswählen.
danke -das wars :-)
Sorry für die Unannehmlichkeiten beim Download. Es nervt mich ja auch. Das wird sich ändern. Habe bereits einen Github Account und werde HMCCU wohl erst mal bei Github unterbringen. Dann klappts auch mit dem Update (Befehl).
Leider unterstützt das FHEM Update den contrib Zweig nicht und in den FHEM-Zweig darf das Modul (noch) nicht, weil ccurpcd.pl (noch) als externe Datei dabei ist.
Daher temporär erst mal der Umweg über Github, wie das andere Modul-Entwickler auch machen.
Danke zap, das war's:
ZitatDu musst dem Device schon sagen, welchen Befehl es ausführen soll, wenn Du nur einen Datenpunkt angibst (in dem Fall "datapoint"):
set Arbeitszimmer_Rolladen datapoint 1.STOP true
set Arbeitszimmer_Rolladen datapoint 1.STOP true funktioniert...
Zitat
Für die Attribute: Bist Du sicher, dass LEVEL im Bereich 0-1 liegt und nicht 0-100 ?
Ja, das Reading LEVEL liefert Werte zwischen 0.0 und 1.0. Z.B.
AZ-Rolladen.1.LEVEL 0.6. Siehe ein aktuelles list vom Arbeitszimmer_Rolladen...
Internals:
CFGFN
DEF AZ-Rolladen 1
IODev myHomematicCCU
NAME Arbeitszimmer_Rolladen
NR 3305
STATE OK
TYPE HMCCUDEV
ccuaddr LEQ1032012
ccudevstate Active
ccuif BidCos-RF
ccuname AZ-Rolladen
ccutype HM-LC-Bl1PBU-FM
channels 2
statevals devstate|up|down
Readings:
2016-04-19 08:36:11 AZ-Rolladen.0.AES_KEY 0
2016-04-19 08:36:11 AZ-Rolladen.0.CONFIG_PENDING false
2016-04-19 08:36:11 AZ-Rolladen.0.DEVICE_IN_BOOTLOADER false
2016-04-19 08:36:11 AZ-Rolladen.0.DUTYCYCLE false
2016-04-19 08:36:11 AZ-Rolladen.0.RSSI_DEVICE 193
2016-04-19 08:36:11 AZ-Rolladen.0.RSSI_PEER 197
2016-04-19 08:36:11 AZ-Rolladen.0.STICKY_UNREACH false
2016-04-19 08:36:11 AZ-Rolladen.0.UNREACH false
2016-04-19 08:36:11 AZ-Rolladen.0.UPDATE_PENDING false
2016-04-19 08:36:11 AZ-Rolladen.1.DIRECTION 0
2016-04-19 08:36:11 AZ-Rolladen.1.INHIBIT false
2016-04-19 08:36:11 AZ-Rolladen.1.INSTALL_TEST N/A
2016-04-19 08:36:11 AZ-Rolladen.1.LEVEL 0.6
2016-04-19 08:36:11 AZ-Rolladen.1.STOP N/A
2016-04-19 08:36:11 AZ-Rolladen.1.WORKING false
2016-04-19 08:36:11 control 0.6
2016-04-19 08:35:56 state OK
Attributes:
IODev myHomematicCCU
controldatapoint 1.LEVEL
group Arbeitszimmer
icon fts_shutter_1w
room 02_Oben,HMCCU
statechannel 1
statevals up:0.0,down:1.0
stripnumber 1
webCmd control
widgetOverride control:slider,0,0.050000,1,1
Wie ich das gestern schon für cho's Thermostatfrage beantwortet hatte kannst Du Dir mit eventmap recht einfache Abkürzungen für up, down und stop bauen:
attr Arbeitszimmer_Rolladen eventmap /datapoint 1.STOP 1:stop/datapoint 1.LEVEL 0:down/datapoint 1.LEVEL 1:up/
Dann kannst Du folgendes machen:
set Arbeitszimmer_Rolladen up
set Arbeitszimmer_Rolladen down
set Arbeitszimmer_Rolladen stop
Anbei nun das komplette Beispiel für die Definition eines Rolladenaktors: HM-LC-Bl1PBU-FM
Internals:
CFGFN
DEF AZ-Rolladen 1
IODev myHomematicCCU
NAME Arbeitszimmer_Rolladen
NR 3305
STATE OK
TYPE HMCCUDEV
ccuaddr LEQ1032012
ccudevstate Active
ccuif BidCos-RF
ccuname AZ-Rolladen
ccutype HM-LC-Bl1PBU-FM
channels 2
statevals devstate|up|down
Readings:
2016-04-19 08:36:11 AZ-Rolladen.0.AES_KEY 0
2016-04-19 08:36:11 AZ-Rolladen.0.CONFIG_PENDING false
2016-04-19 08:36:11 AZ-Rolladen.0.DEVICE_IN_BOOTLOADER false
2016-04-19 08:36:11 AZ-Rolladen.0.DUTYCYCLE false
2016-04-19 08:36:11 AZ-Rolladen.0.RSSI_DEVICE 193
2016-04-19 08:36:11 AZ-Rolladen.0.RSSI_PEER 197
2016-04-19 08:36:11 AZ-Rolladen.0.STICKY_UNREACH false
2016-04-19 08:36:11 AZ-Rolladen.0.UNREACH false
2016-04-19 08:36:11 AZ-Rolladen.0.UPDATE_PENDING false
2016-04-19 08:36:11 AZ-Rolladen.1.DIRECTION 0
2016-04-19 08:36:11 AZ-Rolladen.1.INHIBIT false
2016-04-19 08:36:11 AZ-Rolladen.1.INSTALL_TEST N/A
2016-04-19 08:36:11 AZ-Rolladen.1.LEVEL 0.6
2016-04-19 08:36:11 AZ-Rolladen.1.STOP N/A
2016-04-19 08:36:11 AZ-Rolladen.1.WORKING false
2016-04-19 08:36:11 control 0.6
2016-04-19 17:33:51 state OK
Attributes:
IODev myHomematicCCU
cmdIcon up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down
controldatapoint 1.LEVEL
eventMap /datapoint 1.STOP 1:stop/datapoint 1.LEVEL 1:down/datapoint 1.LEVEL 0:up/
group Arbeitszimmer
icon fts_shutter_1w
room 02_Oben,HMCCU
statechannel 1
statevals up:0.0,down:1.0
stripnumber 1
webCmd control:up:stop:down
widgetOverride control:slider,0,0.05,1,1
Danke für alle Hinweise und Ratschläge. Das Ergebnis gefällt mir...
Noch eine Kleinigkeit: wenn ich den Rolladen mit dem Slider (control) in eine neue Position fahre, dann ändert sich der Slider "unschön"
Das Verhalten/die Bedienung ist wie folgt:
- Die Bedienung des Sliders erfolg in der WebCmd-View (siehe Bild im vorigen Post), also nicht in der Detailansicht des Rolladenaktor.
- Es wird nur der Slider verschoben und dann gewartet was passiert
- Slider z.B. von 0.10 (10%) auf 0.80 (80%) verschieben
- Slider loslassen, dann fängt der Rolladen an zu fahren
- während der Rolladen fährt, zeigt der Slider plötzlich wieder 0.10 (10%) an
- sobald der Rolladen an der gewünschten Position angekommen ist, bleibt er stehen
- der Slider steht immer noch bei 0.10 (10%)
- kurze Zeit später wechselt der Slider dann wieder auf die zuvor eingestellten 0.80 (80%)
- dann ist der Vorgng abgeschlossen
Schöner wäre, wenn der Slider beim Verschieden auf 0.80 (80%) dort "verharren" würde.
In der Detailansicht des Rolladenaktor ist das Verhalten ähnlich:
- während der Ralladen fährt, bewegt sich der Slider zunächst auf 0.0 (0%)
- dann bewegt er sich wieder auf 0.10 (10%)
- schließlich bewegt er sich auf 0.80 (80%)
Hallo Achiim,
ZitatAnbei nun das komplette Beispiel für die Definition eines Rolladenaktors: HM-LC-Bl1PBU-FM
Könntest Du auch noch die Befehle für die Definition posten? Ich möchte gerade genau den gleichen Aktor einbinden :-)
Gruß
Nic
Spezial Service für Nic0205
define Arbeitszimmer_Rolladen HMCCUDEV AZ-Rolladen 1
attr Arbeitszimmer_Rolladen IODev myHomematicCCU
attr Arbeitszimmer_Rolladen cmdIcon up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down
attr Arbeitszimmer_Rolladen controldatapoint 1.LEVEL
attr Arbeitszimmer_Rolladen eventMap /datapoint 1.STOP 1:stop/datapoint 1.LEVEL 1:down/datapoint 1.LEVEL 0:up/
attr Arbeitszimmer_Rolladen group Arbeitszimmer
attr Arbeitszimmer_Rolladen icon fts_shutter_1w
attr Arbeitszimmer_Rolladen room 02_Oben,HMCCU
attr Arbeitszimmer_Rolladen statechannel 1
attr Arbeitszimmer_Rolladen statevals up:0.0,down:1.0
attr Arbeitszimmer_Rolladen stripnumber 1
attr Arbeitszimmer_Rolladen webCmd control:up:stop:down
attr Arbeitszimmer_Rolladen widgetOverride control:slider,0,0.05,1,1
Zitat von: Achiim am 19 April 2016, 18:10:22
Noch eine Kleinigkeit: wenn ich den Rolladen mit dem Slider (control) in eine neue Position fahre, dann ändert sich der Slider "unschön"
Schöner wäre, wenn der Slider beim Verschieden auf 0.80 (80%) dort "verharren" würde.
Der Slider zeigt den Wert des Readings "LEVEL" an. Mit dem Verschieben des Sliders änderst Du nicht den Wert des Readings, sondern legst den neuen Wert fest, der an die CCU für den Datenpunkt LEVEL geschickt wird. Sobald Du den Slider los lässt, schickt HMCCU das Set-Kommando an die CCU. Zu diesem Zeitpunkt ist aber das Reading LEVEL in FHEM noch nicht aktualisiert (das Web-Interface macht das nicht automatisch). Das Reading (und damit der Slider) wird erst auf das neue LEVEL aktualisiert, wenn HMCCU das Event von der CCU bekommt (quasi als Bestätigung, dass der Befehl ausgeführt wurde). Daher "fällt" das LEVEL bzw. der Slider wieder auf den Ausgangswert zurück.
Die Häufigkeit, mit der HMCCU Events von der CCU aus der Filequeue liest, kann mit dem Attribut rpcinterval im IO Device eingestellt werden. Default ist 5 Sekunden. Unter 3 Sekunden würde ich nicht gehen, da sonst FHEM zu sehr ausgebremst wird (gerade bei vielen CCU Devices). Aber Du kannst ja mal testweise 2 Sekunden einstellen (geht nur per Kommandozeile, im Webinterface nur 3,5,10 Sekunden).
Mal überlegen ... ich müsste im Prinzip vor dem Absetzen des set Befehls das Reading mit dem neuen Wert aktualisieren ...
Danke für das Beispiel. Wenn Du nichts dagegen hast, übernehme ich das in meine Beispielsammlung.
ZitatDanke für das Beispiel. Wenn Du nichts dagegen hast, übernehme ich das in meine Beispielsammlung.
Dafür sind Beispiele da.
Für Dein Problem mit der späten Aktualisierung des Sliders könntest Du mal das Attribut ccuverify für den Rolladen auf 1 setzen. Das bewirkt, dass direkt nach dem Setzen des Ziellevels der Wert von der CCU abgefragt und das Reading aktualisiert wird.
Die Frage ist nur, welchen Wert die CCU liefert, solange der Rolladen fährt.
Hinweis: Wenn Du das Attribut setzt, wird zwischen set und get ein usleep() aufgerufen. Das benötigt das Modul Time::HiRes
Auch mit ccuverify für den Rolladen auf 1 ist das Verhalten des Sliders wie oben beschrieben. Ich kann kein geändertes Verhalten feststellen... Hättest du erwartet, dass der Slider sich nun langsam mit dem fahrenden Rolladen mitbewegt?
Zitat von: Achiim am 21 April 2016, 23:35:48
Auch mit ccuverify für den Rolladen auf 1 ist das Verhalten des Sliders wie oben beschrieben. Ich kann kein geändertes Verhalten feststellen... Hättest du erwartet, dass der Slider sich nun langsam mit dem fahrenden Rolladen mitbewegt?
Nein, ich habe gehofft, dass der Slider während der Fahrt zumindest bei 0.8 stehen bleibt und nicht erst wieder auf 0.1 zurück fällt. In dem Fall ist wohl der Datenpunkt LEVEL in der CCU beim Fahren nicht aktualisiert. Vermutlich macht die CCU das erst am Ende der Fahrt.
Einziger Workaround, den ich anbieten kann: Ich baue das so um, dass das Reading LEVEL in FHEM direkt nach dem SET Befehl auf den Zielwert gesetzt wird. Dann fällt der Slider zumindest nicht auf 0.1 zurück. Das kann dann zum Problem werden, wenn der SET Befehl (aus welchen Gründen auch immer) nicht bei der CCU bzw. dem Rolladenaktor ankommt. Dann würde der Slider einen falschen Wert anzeigen.
Eines könntest Du noch testen: Das Attribut ccuverify auf 1 setzen und das Attribut ccuget auf "State". Letzteres bewirkt, dass das Abfragen von Datenpunkten direkt an den Aktor geht. Default ist hier "Value": da werden die Datenpunkte aus der CCU gelesen. State ist etwas langsamer als Value und belastet die Batterien beim Aktor (was aber beim Rolladen eh keine Rolle spielt).
Hallo zusammen.
Wie bekomme ich den die 50 virtuellen Kanäle der CCU eingebunden?
Meine Türkontakte und Systemvariablen laufen soweit.
Nur beim befehl
define test HMCCUCHN BidCoS-RF:1 readonly
bekomme ich immer
Invalid or unknown CCU channel name or address
Anbei noch meine devicelist dump
DIN-W93-CCU2
DIN-W93-CCU2:0
HM-RCV-50 BidCoS-RF:1
HM-RCV-50 BidCoS-RF:10
HM-RCV-50 BidCoS-RF:11
HM-RCV-50 BidCoS-RF:12
HM-RCV-50 BidCoS-RF:13
HM-RCV-50 BidCoS-RF:14
HM-RCV-50 BidCoS-RF:15
HM-RCV-50 BidCoS-RF:16
HM-RCV-50 BidCoS-RF:17
HM-RCV-50 BidCoS-RF:18
HM-RCV-50 BidCoS-RF:19
HM-RCV-50 BidCoS-RF:2
HM-RCV-50 BidCoS-RF:20
HM-RCV-50 BidCoS-RF:21
HM-RCV-50 BidCoS-RF:22
HM-RCV-50 BidCoS-RF:23
HM-RCV-50 BidCoS-RF:24
HM-RCV-50 BidCoS-RF:25
HM-RCV-50 BidCoS-RF:26
HM-RCV-50 BidCoS-RF:27
HM-RCV-50 BidCoS-RF:28
HM-RCV-50 BidCoS-RF:29
HM-RCV-50 BidCoS-RF:3
HM-RCV-50 BidCoS-RF:30
HM-RCV-50 BidCoS-RF:31
HM-RCV-50 BidCoS-RF:32
HM-RCV-50 BidCoS-RF:33
HM-RCV-50 BidCoS-RF:34
HM-RCV-50 BidCoS-RF:35
HM-RCV-50 BidCoS-RF:36
HM-RCV-50 BidCoS-RF:37
HM-RCV-50 BidCoS-RF:38
HM-RCV-50 BidCoS-RF:39
HM-RCV-50 BidCoS-RF:4
HM-RCV-50 BidCoS-RF:40
HM-RCV-50 BidCoS-RF:41
HM-RCV-50 BidCoS-RF:42
HM-RCV-50 BidCoS-RF:43
HM-RCV-50 BidCoS-RF:44
HM-RCV-50 BidCoS-RF:45
HM-RCV-50 BidCoS-RF:46
HM-RCV-50 BidCoS-RF:47
HM-RCV-50 BidCoS-RF:48
HM-RCV-50 BidCoS-RF:49
HM-RCV-50 BidCoS-RF:5
HM-RCV-v50
HM-RCV-50 BidCoS-RF:6
HM-RCV-50 BidCoS-RF:7
HM-RCV-50 BidCoS-RF:8
HM-RCV-50 BidCoS-RF:9
Alarmsteuerung
Alarmsteuerung:0
HM-RC-Sec4-2 MEQ0077995:1
HM-RC-Sec4-2 MEQ0077995:2
HM-RC-Sec4-2 MEQ0077995:3
HM-RC-Sec4-2 MEQ0077995:4
Sirene
Sirene:0
HM-LC-Sw1-Ba-PCB MEQ0593893:1
Terrassent�re
Terrassent�re:0
HM-Sec-SCo NEQ0063373:1
Haust�re
Haust�re:0
HM-Sec-SCo NEQ0063864:1
Vielen Dank im vorraus
Markus
Theoretisch müsste es wohl so heißen:
define test HMCCUCHN HM-RCV-50 BidCoS-RF:1
Denn der Name des Kanals beinhaltet "HM-RCV-50". Schlecht ist, dass FHEM hier nicht mitspielt, da Leerzeichen als Parameter nicht unterstützt bzw. als 2 Parameter behandelt werden. Du hast 2 Möglichkeiten:
1. Du benennst den Kanal in der CCU um (ohne Leerzeichen)
2. Du versuchst, beim define statt dem Kanalnamen die Adresse anzugeben
Anderes Thema: In Deiner Geräteliste tauchen Kanäle mit Umlauten auf. Das ist für die Verwendung in FHEM nicht so gut. Wie Du siehst, werden die Umlaute durch kryptische Zeichen ersetzt. Damit funktioniert HMCCU nicht richtig (für die betroffenen Kanäle). Du solltest daher diese Geräte in der CCU umbenennen, wenn Du sie in FHEM ansprechen willst.
Hallo zap,
irgendwie werden der RPC Server und ich keine Freunde mehr.
Nachdem ich den FHEM neu gestartet habe, klappt alles super. ich bekomme aktuelle Status zu meinen devices - alles wie es sein soll.
Nur danach erhalte ich keine updates mehr. Ich habe z.B. gerade um 19.55 Uhr ein Fenster geöffnet, davon bekommt der RPC Server aber nichts mit.
So sieht das rpc log aus:
19.04.2016 21:56:04 ListDevices CB2001. Sending init to HMCCU
19.04.2016 21:56:06 NewDevice: received 220 device specifications
20.04.2016 05:14:50 RPC server terminated
20.04.2016 05:15:18 Creating file queue
20.04.2016 05:15:18 Initializing RPC server
20.04.2016 05:15:19 Callback server created listening on port 7401
20.04.2016 05:15:19 Adding callback for events
20.04.2016 05:15:19 Adding callback for new devices
20.04.2016 05:15:19 Adding callback for deleted devices
20.04.2016 05:15:19 Adding callback for modified devices
20.04.2016 05:15:19 Adding callback for replaced devices
20.04.2016 05:15:19 Adding callback for readded devices
20.04.2016 05:15:19 Entering server loop. Use kill -SIGINT 1231 to terminate program
20.04.2016 05:15:25 ListDevices CB2001. Sending init to HMCCU
20.04.2016 05:15:28 NewDevice: received 220 device specifications
22.04.2016 06:16:02 RPC server terminated
22.04.2016 06:16:31 Creating file queue
22.04.2016 06:16:31 Initializing RPC server
22.04.2016 06:16:31 Callback server created listening on port 7401
22.04.2016 06:16:31 Adding callback for events
22.04.2016 06:16:31 Adding callback for new devices
22.04.2016 06:16:31 Adding callback for deleted devices
22.04.2016 06:16:31 Adding callback for modified devices
22.04.2016 06:16:31 Adding callback for replaced devices
22.04.2016 06:16:31 Adding callback for readded devices
22.04.2016 06:16:31 Entering server loop. Use kill -SIGINT 2199 to terminate program
22.04.2016 06:16:38 ListDevices CB2001. Sending init to HMCCU
22.04.2016 06:16:40 NewDevice: received 220 device specifications
und so das fhem.log:
2016.04.19 06:21:14 1: in DELETED
2016.04.19 06:21:16 1: in SAVE
2016.04.19 06:22:39 1: in SHUTDOWN
2016.04.19 06:22:39 0: Server shutdown
2016.04.19 06:22:39 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 06:22:39 0: HMCCU: Stopping RPC server CB2001 with PID 3769
2016.04.19 06:22:40 0: HMCCU: RPC server not running
2016.04.19 06:22:46 1: Including fhem.cfg
2016.04.19 06:22:46 3: telnetPort: port 7072 opened
2016.04.19 06:22:46 3: WEB: port 8083 opened
2016.04.19 06:22:46 3: WEBphone: port 8084 opened
2016.04.19 06:22:46 3: WEBtablet: port 8085 opened
2016.04.19 06:22:46 2: eventTypes: loaded 136 events from ./log/eventTypes.txt
2016.04.19 06:22:47 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 06:22:56 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 06:22:56 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2016.04.19 06:22:56 1: Including ./log/fhem.save
2016.04.19 06:22:56 1: in INITIALIZED
2016.04.19 06:22:56 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 06:22:56 1: usb create starting
2016.04.19 06:22:57 3: Probing CUL device /dev/ttyAMA0
2016.04.19 06:22:57 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 06:22:57 1: usb create end
2016.04.19 06:22:57 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.19 06:22:57 0: Featurelevel: 5.7
2016.04.19 06:22:57 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 5476)
2016.04.19 06:22:57 3: ipc fronthem:127.0.0.1:48354 (ws): ws alive with pid 5477
2016.04.19 06:23:08 0: HMCCU: RPC server started with pid 5490
2016.04.19 06:23:13 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 06:23:18 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 06:23:19 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 06:23:24 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.19 06:24:08 1: in DEFINED
2016.04.19 06:24:33 1: in DELETED
2016.04.19 06:25:44 1: in SAVE
2016.04.19 18:39:30 1: HMCCU: ChannelNo undefined: Addr=KEQ1023911
2016.04.19 18:39:30 1: PERL WARNING: Use of uninitialized value $c in string ne at ./FHEM/88_HMCCU.pm line 909.
2016.04.19 18:39:30 1: PERL WARNING: Use of uninitialized value $c in string eq at ./FHEM/88_HMCCU.pm line 912.
2016.04.19 18:39:50 1: HMCCU: ChannelNo undefined: Addr=KEQ1023911
2016.04.19 18:46:02 1: HMCCU: ChannelNo undefined: Addr=KEQ1023911
2016.04.19 18:46:02 1: HMCCU: ChannelNo undefined: Addr=KEQ1023911
2016.04.19 20:09:49 1: in DEFINED
2016.04.19 20:11:27 1: HMCCUDEV: Kueche_Rollo Execution of CCU script or command failed
2016.04.19 20:11:36 1: in DELETED
2016.04.19 20:11:43 1: in DEFINED
2016.04.19 20:13:17 1: in SHUTDOWN
2016.04.19 20:13:17 0: Server shutdown
2016.04.19 20:13:17 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 20:13:17 0: HMCCU: Stopping RPC server CB2001 with PID 5490
2016.04.19 20:13:17 0: HMCCU: RPC server not running
2016.04.19 20:13:24 1: Including fhem.cfg
2016.04.19 20:13:24 3: telnetPort: port 7072 opened
2016.04.19 20:13:24 3: WEB: port 8083 opened
2016.04.19 20:13:24 3: WEBphone: port 8084 opened
2016.04.19 20:13:24 3: WEBtablet: port 8085 opened
2016.04.19 20:13:24 2: eventTypes: loaded 179 events from ./log/eventTypes.txt
2016.04.19 20:13:25 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 20:13:30 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 20:13:30 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2016.04.19 20:13:30 1: Including ./log/fhem.save
2016.04.19 20:13:30 1: statefile: Please define Kueche_Rollo first
2016.04.19 20:13:30 1: in INITIALIZED
2016.04.19 20:13:30 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 20:13:30 1: usb create starting
2016.04.19 20:13:31 3: Probing CUL device /dev/ttyAMA0
2016.04.19 20:13:31 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 20:13:31 1: usb create end
2016.04.19 20:13:31 2: Error messages while initializing FHEM: statefile: Please define Kueche_Rollo first
2016.04.19 20:13:31 0: Featurelevel: 5.7
2016.04.19 20:13:31 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 28049)
2016.04.19 20:13:31 3: ipc fronthem:127.0.0.1:50248 (ws): ws alive with pid 28051
2016.04.19 20:13:42 0: HMCCU: RPC server started with pid 28063
2016.04.19 20:13:47 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 20:13:48 1: in DEFINED
2016.04.19 20:13:52 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 20:13:53 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 20:13:58 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.19 20:23:53 1: in SHUTDOWN
2016.04.19 20:23:53 0: Server shutdown
2016.04.19 20:23:53 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 20:23:53 0: HMCCU: Stopping RPC server CB2001 with PID 28063
2016.04.19 20:23:53 0: HMCCU: RPC server not running
2016.04.19 20:24:00 1: Including fhem.cfg
2016.04.19 20:24:00 3: telnetPort: port 7072 opened
2016.04.19 20:24:00 3: WEB: port 8083 opened
2016.04.19 20:24:00 3: WEBphone: port 8084 opened
2016.04.19 20:24:00 3: WEBtablet: port 8085 opened
2016.04.19 20:24:00 2: eventTypes: loaded 192 events from ./log/eventTypes.txt
2016.04.19 20:24:01 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 20:24:06 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 20:24:06 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2016.04.19 20:24:06 3: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 20:24:06 1: Including ./log/fhem.save
2016.04.19 20:24:06 1: configfile: Wohnzimmer_rollo_vorn: unknown IODev specifiedstatefile: Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
2016.04.19 20:24:06 1: in INITIALIZED
2016.04.19 20:24:06 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 20:24:06 1: usb create starting
2016.04.19 20:24:07 3: Probing CUL device /dev/ttyAMA0
2016.04.19 20:24:07 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 20:24:07 1: usb create end
2016.04.19 20:24:07 2: Error messages while initializing FHEM: configfile: Wohnzimmer_rollo_vorn: unknown IODev specifiedstatefile: Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first
2016.04.19 20:24:07 0: Featurelevel: 5.7
2016.04.19 20:24:07 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 28757)
2016.04.19 20:24:07 3: ipc fronthem:127.0.0.1:50293 (ws): ws alive with pid 28758
2016.04.19 20:24:18 0: HMCCU: RPC server started with pid 28769
2016.04.19 20:24:23 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 20:24:28 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 20:24:29 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 20:24:34 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.19 20:28:21 1: in SHUTDOWN
2016.04.19 20:28:21 0: Server shutdown
2016.04.19 20:28:21 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 20:28:54 0: HMCCU: Stopping RPC server CB2001 with PID 28769
2016.04.19 20:28:54 0: HMCCU: RPC server not running
2016.04.19 20:29:00 1: Including fhem.cfg
2016.04.19 20:29:00 3: telnetPort: port 7072 opened
2016.04.19 20:29:01 3: WEB: port 8083 opened
2016.04.19 20:29:01 3: WEBphone: port 8084 opened
2016.04.19 20:29:01 3: WEBtablet: port 8085 opened
2016.04.19 20:29:01 2: eventTypes: loaded 195 events from ./log/eventTypes.txt
2016.04.19 20:29:01 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 20:29:07 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 20:29:07 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2016.04.19 20:29:07 3: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 20:29:07 1: Including ./log/fhem.save
2016.04.19 20:29:07 1: configfile: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 20:29:07 1: in INITIALIZED
2016.04.19 20:29:07 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 20:29:07 1: usb create starting
2016.04.19 20:29:08 3: Probing CUL device /dev/ttyAMA0
2016.04.19 20:29:08 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 20:29:08 1: usb create end
2016.04.19 20:29:08 2: Error messages while initializing FHEM: configfile: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 20:29:08 0: Featurelevel: 5.7
2016.04.19 20:29:08 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 29047)
2016.04.19 20:29:08 3: ipc fronthem:127.0.0.1:50328 (ws): ws alive with pid 29048
2016.04.19 20:29:20 0: HMCCU: RPC server started with pid 29060
2016.04.19 20:29:25 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 20:29:30 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 20:29:30 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 20:29:35 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.19 20:34:54 1: in SHUTDOWN
2016.04.19 20:34:54 0: Server shutdown
2016.04.19 20:34:54 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 20:34:54 0: HMCCU: Stopping RPC server CB2001 with PID 29060
2016.04.19 20:34:54 0: HMCCU: RPC server not running
2016.04.19 20:35:00 1: Including fhem.cfg
2016.04.19 20:35:00 3: telnetPort: port 7072 opened
2016.04.19 20:35:01 3: WEB: port 8083 opened
2016.04.19 20:35:01 3: WEBphone: port 8084 opened
2016.04.19 20:35:01 3: WEBtablet: port 8085 opened
2016.04.19 20:35:01 2: eventTypes: loaded 195 events from ./log/eventTypes.txt
2016.04.19 20:35:02 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 20:35:06 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 20:35:06 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2016.04.19 20:35:07 3: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 20:35:07 1: Including ./log/fhem.save
2016.04.19 20:35:07 1: configfile: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 20:35:07 1: in INITIALIZED
2016.04.19 20:35:07 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 20:35:07 1: usb create starting
2016.04.19 20:35:07 3: Probing CUL device /dev/ttyAMA0
2016.04.19 20:35:08 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 20:35:08 1: usb create end
2016.04.19 20:35:08 2: Error messages while initializing FHEM: configfile: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 20:35:08 0: Featurelevel: 5.7
2016.04.19 20:35:08 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 29436)
2016.04.19 20:35:08 3: ipc fronthem:127.0.0.1:50369 (ws): ws alive with pid 29437
2016.04.19 20:35:19 0: HMCCU: RPC server started with pid 29449
2016.04.19 20:35:24 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 20:35:29 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 20:35:30 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 20:35:35 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.19 21:07:05 3: Unregistering HTTPSRV TABLETUI for URL /ftui...
2016.04.19 21:07:05 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 21:07:05 0: HMCCU: Stopping RPC server CB2001 with PID 29449
2016.04.19 21:07:05 0: HMCCU: RPC server not running
2016.04.19 21:07:06 1: Including fhem.cfg
2016.04.19 21:07:06 3: telnetPort: port 7072 opened
2016.04.19 21:07:06 3: WEB: port 8083 opened
2016.04.19 21:07:06 3: WEBphone: port 8084 opened
2016.04.19 21:07:06 3: WEBtablet: port 8085 opened
2016.04.19 21:07:06 2: eventTypes: loaded 195 events from ./log/eventTypes.txt
2016.04.19 21:07:06 2: fronthem: ipc listener opened at port 16385
2016.04.19 21:07:07 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 21:07:07 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2016.04.19 21:07:08 3: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 21:07:08 1: Including ./log/fhem.save
2016.04.19 21:07:08 1: in REREADCFG
2016.04.19 21:07:08 1: in SHUTDOWN
2016.04.19 21:07:08 0: Server shutdown
2016.04.19 21:07:08 0: HMCCU: RPC server not running
2016.04.19 21:07:51 1: Including fhem.cfg
2016.04.19 21:07:51 3: telnetPort: port 7072 opened
2016.04.19 21:07:52 3: WEB: port 8083 opened
2016.04.19 21:07:52 3: WEBphone: port 8084 opened
2016.04.19 21:07:52 3: WEBtablet: port 8085 opened
2016.04.19 21:08:13 2: eventTypes: loaded 195 events from ./log/eventTypes.txt
2016.04.19 21:08:16 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 21:08:42 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 21:08:42 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2016.04.19 21:08:42 3: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 21:08:43 1: Including ./log/fhem.save
2016.04.19 21:08:43 1: configfile: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 21:08:43 1: in INITIALIZED
2016.04.19 21:08:43 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 21:08:43 1: usb create starting
2016.04.19 21:08:44 3: Probing CUL device /dev/ttyAMA0
2016.04.19 21:08:44 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 21:08:44 1: usb create end
2016.04.19 21:08:44 2: Error messages while initializing FHEM: configfile: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 21:08:44 0: Featurelevel: 5.7
2016.04.19 21:08:44 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 918)
2016.04.19 21:08:44 3: ipc fronthem:127.0.0.1:60111 (ws): ws alive with pid 1055
2016.04.19 21:08:55 0: HMCCU: RPC server started with pid 1239
2016.04.19 21:09:06 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 21:09:11 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 21:09:11 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 21:09:16 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.19 21:14:12 1: in SHUTDOWN
2016.04.19 21:14:12 0: Server shutdown
2016.04.19 21:14:12 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 21:14:12 0: HMCCU: Stopping RPC server CB2001 with PID 1239
2016.04.19 21:14:12 0: HMCCU: RPC server not running
2016.04.19 21:14:18 1: Including fhem.cfg
2016.04.19 21:14:19 3: telnetPort: port 7072 opened
2016.04.19 21:14:19 3: WEB: port 8083 opened
2016.04.19 21:14:19 3: WEBphone: port 8084 opened
2016.04.19 21:14:19 3: WEBtablet: port 8085 opened
2016.04.19 21:14:19 2: eventTypes: loaded 195 events from ./log/eventTypes.txt
2016.04.19 21:14:20 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 21:14:25 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 21:14:25 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2016.04.19 21:14:25 1: Including ./log/fhem.save
2016.04.19 21:14:25 1: in INITIALIZED
2016.04.19 21:14:25 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 21:14:25 1: usb create starting
2016.04.19 21:14:26 3: Probing CUL device /dev/ttyAMA0
2016.04.19 21:14:26 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 21:14:26 1: usb create end
2016.04.19 21:14:26 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.19 21:14:26 0: Featurelevel: 5.7
2016.04.19 21:14:26 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 1799)
2016.04.19 21:14:26 3: ipc fronthem:127.0.0.1:60277 (ws): ws alive with pid 1800
2016.04.19 21:14:37 0: HMCCU: RPC server started with pid 1812
2016.04.19 21:14:42 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 21:14:47 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 21:14:48 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 21:14:53 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.19 21:55:29 1: in SHUTDOWN
2016.04.19 21:55:29 0: Server shutdown
2016.04.19 21:55:29 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 21:55:29 0: HMCCU: Stopping RPC server CB2001 with PID 1812
2016.04.19 21:55:29 0: HMCCU: RPC server not running
2016.04.19 21:55:35 1: Including fhem.cfg
2016.04.19 21:55:36 3: telnetPort: port 7072 opened
2016.04.19 21:55:36 3: WEB: port 8083 opened
2016.04.19 21:55:36 3: WEBphone: port 8084 opened
2016.04.19 21:55:36 3: WEBtablet: port 8085 opened
2016.04.19 21:55:36 2: eventTypes: loaded 196 events from ./log/eventTypes.txt
2016.04.19 21:55:37 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 21:55:41 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 21:55:41 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2016.04.19 21:55:42 1: Including ./log/fhem.save
2016.04.19 21:55:42 1: in INITIALIZED
2016.04.19 21:55:42 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 21:55:42 1: usb create starting
2016.04.19 21:55:42 3: Probing CUL device /dev/ttyAMA0
2016.04.19 21:55:42 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 21:55:43 1: usb create end
2016.04.19 21:55:43 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.19 21:55:43 0: Featurelevel: 5.7
2016.04.19 21:55:43 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 4521)
2016.04.19 21:55:43 3: ipc fronthem:127.0.0.1:60397 (ws): ws alive with pid 4522
2016.04.19 21:55:54 0: HMCCU: RPC server started with pid 4535
2016.04.19 21:55:59 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 21:56:04 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 21:56:05 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 21:56:10 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.20 05:14:50 1: in SHUTDOWN
2016.04.20 05:14:50 0: Server shutdown
2016.04.20 05:14:50 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.20 05:14:50 0: HMCCU: Stopping RPC server CB2001 with PID 4535
2016.04.20 05:14:50 0: HMCCU: RPC server not running
2016.04.20 05:14:57 1: Including fhem.cfg
2016.04.20 05:14:57 3: telnetPort: port 7072 opened
2016.04.20 05:14:57 3: WEB: port 8083 opened
2016.04.20 05:14:57 3: WEBphone: port 8084 opened
2016.04.20 05:14:57 3: WEBtablet: port 8085 opened
2016.04.20 05:14:57 2: eventTypes: loaded 196 events from ./log/eventTypes.txt
2016.04.20 05:14:58 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.20 05:15:02 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.20 05:15:02 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2016.04.20 05:15:03 1: Including ./log/fhem.save
2016.04.20 05:15:03 1: in INITIALIZED
2016.04.20 05:15:03 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.20 05:15:03 1: usb create starting
2016.04.20 05:15:03 3: Probing CUL device /dev/ttyAMA0
2016.04.20 05:15:04 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.20 05:15:04 1: usb create end
2016.04.20 05:15:04 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.20 05:15:04 0: Featurelevel: 5.7
2016.04.20 05:15:04 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 1206)
2016.04.20 05:15:04 3: ipc fronthem:127.0.0.1:33136 (ws): ws alive with pid 1208
2016.04.20 05:15:15 0: HMCCU: RPC server started with pid 1231
2016.04.20 05:15:20 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.20 05:15:25 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.20 05:15:26 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.20 05:15:31 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.20 09:04:12 2: HMCCU: Unknown RPC event type [EV]
2016.04.20 13:26:49 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.22 06:16:02 1: in SHUTDOWN
2016.04.22 06:16:02 0: Server shutdown
2016.04.22 06:16:02 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.22 06:16:02 0: HMCCU: Stopping RPC server CB2001 with PID 1231
2016.04.22 06:16:02 0: HMCCU: RPC server not running
2016.04.22 06:16:08 1: Including fhem.cfg
2016.04.22 06:16:08 3: telnetPort: port 7072 opened
2016.04.22 06:16:09 3: WEB: port 8083 opened
2016.04.22 06:16:09 3: WEBphone: port 8084 opened
2016.04.22 06:16:09 3: WEBtablet: port 8085 opened
2016.04.22 06:16:09 2: eventTypes: loaded 202 events from ./log/eventTypes.txt
2016.04.22 06:16:10 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.22 06:16:15 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.22 06:16:15 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2016.04.22 06:16:15 1: Including ./log/fhem.save
2016.04.22 06:16:15 1: in INITIALIZED
2016.04.22 06:16:15 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.22 06:16:15 1: usb create starting
2016.04.22 06:16:16 3: Probing CUL device /dev/ttyAMA0
2016.04.22 06:16:16 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.22 06:16:16 1: usb create end
2016.04.22 06:16:16 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.22 06:16:16 0: Featurelevel: 5.7
2016.04.22 06:16:16 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 2180)
2016.04.22 06:16:16 3: ipc fronthem:127.0.0.1:39720 (ws): ws alive with pid 2181
2016.04.22 06:16:28 0: HMCCU: RPC server started with pid 2199
2016.04.22 06:16:33 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.22 06:16:38 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.22 06:16:38 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.22 06:16:43 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.22 06:21:34 1: in DEFINED
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:22:05 1: in DEFINED
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:20 1: in DEFINED
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:30 1: in DEFINED
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:39 1: in DEFINED
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:47 1: in DEFINED
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:23:00 1: in DEFINED
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:24 1: in DELETED
2016.04.22 06:23:26 1: in SAVE
2016.04.22 07:21:25 2: HMCCU: Received no events from CCU since 300 seconds
Hast Du eine Idee woran das liegt?
Grüße
Nic
Das sieht von RPC-Server Seite her gut aus. Alles wie es sein soll. Vielleicht stimmt etwas bei der Device Definition des Fensters nicht. Schick mal bitte die Ausgabe von list <Fensterdev-Name>.
Ich nehme mal an, Du hast mehr als ein CCU Geräte Device definiert. Wird bei keinem davon ein Reading aktualisiert?
Gehe ins Verzeichnis /tmp und führe mehrmals hintereinander den Befehl "ls -lrt" aus. Die Datei ccuqueue_2001.dat sollte immer wieder aktualisiert werden und die Größe sollte zwischen 0 und wenigen 100 Byte wechseln.
Dass der RPC Server irgendwann aufhört Daten zu schicken ist sehr ungewöhnlich. Entweder geht gleich der Start oder die Initialisierung in die Hose oder er läuft ... bei mir wochenlang ohne Probleme (ich habe sogar 3 parallel laufen)
list-ausgabe:
Internals:
CHANGED
DEF MEQ0723295:1 readonly
IODev d_ccu
NAME WZ_vorn_Fenster
NR 54
STATE closed
TYPE HMCCUCHN
ccuaddr MEQ0723295:1
ccudevstate Active
ccuif BidCos-RF
ccuname Fenster Wohnzimmer vorn
ccutype HM-Sec-SCo
channels 1
statevals readonly
Readings:
2016-04-22 06:46:16 Fenster_Wohnzimmer_vorn.ERROR 0
2016-04-22 06:46:16 Fenster_Wohnzimmer_vorn.LOWBAT no
2016-04-22 06:46:16 Fenster_Wohnzimmer_vorn.STATE closed
2016-04-22 06:46:16 state closed
Attributes:
IODev d_ccu
ccureadingfilter (ERROR|LOWBAT|STATE)
devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
event-on-change-reading .*
substitute STATE!(0|false):closed,(1|true):open;LOWBAT!(0|false):no,(1|true):yes
bei ls -lrt ändert sich nichts - ccuqueue_2001.dat ist 0 Byte groß und bleibt es auch:
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi pi 4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout 1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout 0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi pi 4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout 1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout 0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi pi 4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout 1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout 0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi pi 4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout 1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout 0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi pi 4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout 1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout 0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi pi 4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout 1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout 0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi pi 4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout 1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout 0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi pi 4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout 1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout 0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi pi 4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout 1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout 0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi pi 4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout 1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout 0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi pi 4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout 1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout 0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi pi 4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi pi 4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi pi 0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout 1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout 0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ cat ccuqueue_2001.idx
0pi@LiNaDo_Home:/tmp $ cat ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ cat ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $
Kann ich irgendwo so was wie ein erweitertes Logging aktivieren?
Und der RPC-Prozess läuft?
ps -ef | grep ccurpc
ja, sieht so aus:
pi@LiNaDo_Home:/tmp $ ps -ef | grep ccurpc
fhem 2199 2180 0 06:16 ? 00:01:25 /usr/bin/perl ./FHEM/ccurpcd.pl 192.168.178.101 2001 /tmp/ccuqueue_2001 ./log/ccurpcd_2001.log
pi 3630 24103 0 22:51 pts/0 00:00:00 grep --color=auto ccurpc
p
ZitatEines könntest Du noch testen: Das Attribut ccuverify auf 1 setzen und das Attribut ccuget auf "State". Letzteres bewirkt, dass das Abfragen von Datenpunkten direkt an den Aktor geht. Default ist hier "Value": da werden die Datenpunkte aus der CCU gelesen. State ist etwas langsamer als Value und belastet die Batterien beim Aktor (was aber beim Rolladen eh keine Rolle spielt).
Damit kann ich auch keinen Unterschied im Verhalten feststellen. der Slider springt immer während der Fahrt auf 0.0 und wenn die Fahrt zu Ende ist, springt er ein paar Sekunden danach auf den zuvor eingestellten Wert.
Wenn das okay ist, solltest du die vorgeschlagene Lösung mit dem Setzten des Readings "auf Verdacht" einbauen, bis eine bessere Lösung identifiziert ist. Ich stehe hierzu wieder zum Testen bereit.
Habe alles installiert, und trotzdem bekomme ich ich die Meldung Cannot load HMCCU Modul, rechte sind auch gesetzt! Was mache ich falsch?
Zitat von: bunni am 23 April 2016, 11:29:47
Habe alles installiert, und trotzdem bekomme ich ich die Meldung Cannot load HMCCU Modul, rechte sind auch gesetzt! Was mache ich falsch?
Dazu gibt es vermutlich eine Fehlermeldung im fhem Logfile. Die brauche ich, dann kann ich Dir wahrscheinlich mehr zur Ursache sagen
Liege leider zur Zeit im Krankenhaus, sobald ich zu Hause bin werde ich das Log File posten! Danke Dir!
Das tut mir leid. Dann wünsche ich Dir baldige Genesung!
Hallo zap,
Zitatja, sieht so aus:
Code: [Auswählen]
pi@LiNaDo_Home:/tmp $ ps -ef | grep ccurpc
fhem 2199 2180 0 06:16 ? 00:01:25 /usr/bin/perl ./FHEM/ccurpcd.pl 192.168.178.101 2001 /tmp/ccuqueue_2001 ./log/ccurpcd_2001.log
pi 3630 24103 0 22:51 pts/0 00:00:00 grep --color=auto ccurpc
p
Beitrag editieren
der pc server scheint ja vermeintlich noch zu laufen. Ich habe heute morgen einmal hem restarted. Daraufhin leif alles super bis ca. 17.35.
Ich vermute, dass es genau ab diese Meldung im Log nicht mehr geht:
HMCCU: Received no events from CCU since 300 secondsKannst Du dadurch das Problem eingrenzen?
Grüße
Nic
Hallo nochmal,
etwas ist mir noch aufgefallen:
Ich habe hier einen alten Thermostaten konfiguriert (mit Absicht mal ganz rudimentär):
IODev
d_ccu
NAME
Bad_Heizung
NR
155
STATE
Initialized
TYPE
HMCCUDEV
ccuaddr
HEQ0508540
ccudevstate
Active
ccuif
BidCos-RF
ccuname
Heizung Bad
ccutype
HM-CC-TC
channels
4
statevals
devstate
Readings
Raumklima_Bad.HUMIDITY
53
2016-04-24 11:48:27
Raumklima_Bad.TEMPERATURE
18.600000
2016-04-24 11:48:27
Soll_Temperatur_Bad.ADJUSTING_COMMAND
0
2016-04-24 11:48:48
Soll_Temperatur_Bad.ADJUSTING_DATA
0
2016-04-24 11:48:48
state
Initialized
2016-04-24 11:42:34
Ich bekomme diesen aber nie vom state "initialized" weg.
Durch die Attribute:
statechannel 1
statedatapoint Raumklima_Bad.TEMPERATURE
sollte doch eigentlich der State gleich TEMPERATURE sein. Ich habe das Gefühl (kann mich aber auch täuschen), dass das den RPC Server auch in den "Wahnsinn" treibt und deswegen nicht immer alle Statusänderungen verarbeitet werden.
Bei einem get Bad_Heizung update werden auch alle Readings aktualisiert, aber eben state ändert sich nichts.
die Readings sehen so aus:
Heizung_Bad.0.CONFIG_PENDING
false
2016-04-24 11:48:03
Heizung_Bad.0.LOWBAT
false
2016-04-24 11:48:03
Heizung_Bad.0.RSSI_DEVICE
1
2016-04-24 11:48:03
Heizung_Bad.0.RSSI_PEER
188
2016-04-24 11:48:03
Heizung_Bad.0.STICKY_UNREACH
false
2016-04-24 11:48:03
Heizung_Bad.0.UNREACH
false
2016-04-24 11:48:03
Raumklima_Bad.HUMIDITY
53
2016-04-24 11:54:20
Raumklima_Bad.TEMPERATURE
18.600000
2016-04-24 11:54:20
Soll_Temperatur_Bad.ADJUSTING_COMMAND
0
2016-04-24 11:54:40
Soll_Temperatur_Bad.ADJUSTING_DATA
0
2016-04-24 11:54:40
Soll_Temperatur_Bad.SETPOINT
1.000000
2016-04-24 11:48:03
Soll_Temperatur_Bad.STATE
N/A
2016-04-24 11:48:03
state
Initialized
2016-04-24 11:42:34
Hat jemand noch einen Tip für mich? Kann es sein, dass es das Attribut "State" im Thermostaten einfach nicht gibt, HMCCU aber verzweifelt versucht dieses Attribut auf "State" in FHEM zu mappen?
Hallo Nic,
Du darfst bei statedatapoint nur den Datenpunkt angeben, also z.B. TEMPERATURE. Der entsprechende Kanal (Nummer) wird über statechannel festgelegt. HMCCU mappt diesen Datenpunkt auf STATE. Das beeinträchtigt den RPC Server nicht.
Das ist leider noch etwas unschön, zumal bei controldatapoint die Kanalnummer und der Datenpunkt zusammen angegeben werden. Ist leider nicht so einfach zu ändern, ohne die Kompatibilität zu verlieren.
Zu Deinem RPC Server Problem: Du hast also FHEM morgens gestartet und damit auch den RPC Server. Dann wurden bis nach 17:00 Uhr auch die Readings immer wieder automatisch aktualisiert, nicht nur einmalig beim Starten?? Und dann hat die Aktualisierung plötzlich aufgehört?
Die Meldung im Log "received no events since 300 seconds besagt nur, dass seit 5 Minuten keine Aktualisierung von der CCU mehr über den RPC Server in FHEM ankam. Das ist also das Symptom, nicht die Ursache.
Falls möglich schau Dir mal /var/log/messages in der CCU an. Gibt es da Fehlermeldungen?
Hallo zap,
ZitatDu darfst bei statedatapoint nur den Datenpunkt angeben, also z.B. TEMPERATURE. Der entsprechende Kanal (Nummer) wird über statechannel festgelegt. HMCCU mappt diesen Datenpunkt auf STATE. Das beeinträchtigt den RPC Server nicht.
Das ist leider noch etwas unschön, zumal bei controldatapoint die Kanalnummer und der Datenpunkt zusammen angegeben werden. Ist leider nicht so einfach zu ändern, ohne die Kompatibilität zu verlieren.
Das war es - jetzt funktioniert auch das Mapping - danke!
Hast Du noch einen Tip für mich, wie ich jetzt z.B. TEMPERATURE in FHEM-Tablet-UI anspreche (was nehme ich denn als data-device)?
ZitatZu Deinem RPC Server Problem: Du hast also FHEM morgens gestartet und damit auch den RPC Server. Dann wurden bis nach 17:00 Uhr auch die Readings immer wieder automatisch aktualisiert, nicht nur einmalig beim Starten?? Und dann hat die Aktualisierung plötzlich aufgehört?
Die Meldung im Log "received no events since 300 seconds besagt nur, dass seit 5 Minuten keine Aktualisierung von der CCU mehr über den RPC Server in FHEM ankam. Das ist also das Symptom, nicht die Ursache.
Falls möglich schau Dir mal /var/log/messages in der CCU an. Gibt es da Fehlermeldungen?
Ja genau so war es. Leider ist var/log/messages bei mir nur 1 Tag - und heute habe ich schon zig mal restarted. Ich beobachte das mal.
Gruß
Nic
Zitat von: Nic0205 am 24 April 2016, 15:13:43
Hast Du noch einen Tip für mich, wie ich jetzt z.B. TEMPERATURE in FHEM-Tablet-UI anspreche (was nehme ich denn als data-device)?
Du gibst als data-device den Namen des FHEM-Devices an, dessen Reading Du darstellen möchtest. In Deinem vorherigen Beispiel wäre das "Bad_Heizung".
ZitatDu gibst als data-device den Namen des FHEM-Devices an, dessen Reading Du darstellen möchtest. In Deinem vorherigen Beispiel wäre das "Bad_Heizung".
Das funktioniert für TEMPERATURE prima, wenn ich jetzt aber z.B. "HUMIDITY" anzeigen will, klappt das nicht.
<div data-type="label" class="narrow darker" data-device="Bad_Heizung.HUMIDITY"></div> zeigt einfach nichts.
<div data-type="label" class="narrow darker" data-device="Bad_Heizung"></div> zeigt mir TEMPERATURE
... ich habe raus gefunden.
so funktioniert es:
<div data-type="label" class="narrow darker" data-device="Bad_Heizung" data-get="Raumklima_Bad.HUMIDITY"></div>
Wobei Raumklima_Bad der Name des Channels 1 in der CCU ist.
Was ich trotzdem nicht verstehe ist, warum statt data-get="Raumklima_Bad.HUMIDITY" nicht auch data-get="1.HUMIDITY"
funktioniert...
Zitat von: Nic0205 am 24 April 2016, 21:11:46
Wobei Raumklima_Bad der Name des Channels 1 in der CCU ist.
Was ich trotzdem nicht verstehe ist, warum statt data-get="Raumklima_Bad.HUMIDITY" nicht auch data-get="1.HUMIDITY"
funktioniert...
Weil "Raumklima_Bad" in Deinem Beispiel zwar zufällig mit dem Namen des Kanals in der CCU identisch ist, bei data-get aber prinzipiell der Reading-Name angegeben werden muss. Und "1.HUMIDITY" ist eben kein Reading-Name.
Hallo,
bin wieder zu Hause, das scheißt mir das Logfile raus, wenn ich versuche das HMCCU-Modul zu definieren:
2016.04.26 10:04:06 1: reload: Error:Modul 88_HMCCU deactivated:
Can't locate File/Queue.pm in @INC (you may need to install the File::Queue module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/88_HMCCU.pm line 49.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 49.
2016.04.26 10:04:06 0: Can't locate File/Queue.pm in @INC (you may need to install the File::Queue module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/88_HMCCU.pm line 49.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 49.
Es wird das Modul File::Queue benötigt. Allerdings scheinst Du eine etwas ältere Version von HMCCU zu verwenden. File::Queue wird schon geraume Zeit nicht mehr verwendet, d.h. Du musst das nicht über CPAN installieren. Lade bitte mal die aktuellen Versionen runter (Link siehe 1. Post):
88_HMCCU.pm, 88_HMCCUDEV.pm, 88_HMCCUCHN.pm, RPCQueue.pm, ccurpcd.pl
Die Datei RPCQueue.pm ersetzt im Prinzip File::Queue.
ZitatZu Deinem RPC Server Problem: Du hast also FHEM morgens gestartet und damit auch den RPC Server. Dann wurden bis nach 17:00 Uhr auch die Readings immer wieder automatisch aktualisiert, nicht nur einmalig beim Starten?? Und dann hat die Aktualisierung plötzlich aufgehört?
Die Meldung im Log "received no events since 300 seconds besagt nur, dass seit 5 Minuten keine Aktualisierung von der CCU mehr über den RPC Server in FHEM ankam. Das ist also das Symptom, nicht die Ursache.
Falls möglich schau Dir mal /var/log/messages in der CCU an. Gibt es da Fehlermeldungen?
Hallo zap,
heute habe ich tatsächlich das Log der CCU noch erwischt.
So sieht fhem-Log aus:
2016.04.26 20:46:41 1: Including fhem.cfg
2016.04.26 20:46:41 3: telnetPort: port 7072 opened
2016.04.26 20:46:41 3: WEB: port 8083 opened
2016.04.26 20:46:41 3: WEBphone: port 8084 opened
2016.04.26 20:46:41 3: WEBtablet: port 8085 opened
2016.04.26 20:46:42 2: eventTypes: loaded 438 events from ./log/eventTypes.txt
2016.04.26 20:46:43 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.26 20:46:48 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.26 20:46:48 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2016.04.26 20:46:48 1: Including ./log/fhem.save
2016.04.26 20:46:48 1: in INITIALIZED
2016.04.26 20:46:48 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.26 20:46:48 1: usb create starting
2016.04.26 20:46:49 3: Probing CUL device /dev/ttyAMA0
2016.04.26 20:46:49 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.26 20:46:49 1: usb create end
2016.04.26 20:46:49 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.26 20:46:49 0: Featurelevel: 5.7
2016.04.26 20:46:49 0: Server started with 34 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 2883)
2016.04.26 20:46:49 3: ipc fronthem:127.0.0.1:53142 (ws): ws alive with pid 2884
2016.04.26 20:47:01 0: HMCCU: RPC server started with pid 2898
2016.04.26 20:47:06 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.26 20:47:11 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.26 20:47:11 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.26 20:47:16 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.26 21:45:36 2: HMCCU: Unknown RPC event type [EV]
2016.04.26 21:56:39 2: HMCCU: Unknown RPC event type [EV]
2016.04.26 23:41:08 2: HMCCU: Unknown RPC event type [EV]
2016.04.27 00:39:29 2: HMCCU: Unknown RPC event type [EV]
2016.04.27 01:08:24 2: HMCCU: Unknown RPC event type [EV]
2016.04.27 03:12:30 2: HMCCU: Received no events from CCU since 300 secondsund so /var/log/messages auf der CCU:
Apr 27 03:12:07 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","IEQ0171822:2","ADJUSTING_COMMAND",0}],[methodName:"event",par
Apr 27 03:12:07 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:12:07 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","IEQ0171822:2","ADJUSTING_COMMAND",0}],[methodName:"event",params
Apr 27 03:12:07 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:12:27 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","IEQ0173109:1","VALVE_STATE",0}],[methodName:"event",params:{"
Apr 27 03:12:27 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:12:27 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","IEQ0173109:1","VALVE_STATE",0}],[methodName:"event",params:{"CB2
Apr 27 03:12:27 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:12:34 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","HEQ0508540:2","ADJUSTING_COMMAND",0}],[methodName:"event",par
Apr 27 03:12:34 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:12:34 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","HEQ0508540:2","ADJUSTING_COMMAND",0}],[methodName:"event",params
Apr 27 03:12:34 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:12:36 homematic-ccu2 user.debug setclock: Wed Apr 27 03:12:36 CEST 2016
Apr 27 03:12:48 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","HEQ0510129:1","TEMPERATURE",19.000000}]}) on binary://192.168
Apr 27 03:12:48 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:12:48 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","HEQ0510129:1","TEMPERATURE",19.000000}]}) on http://192.168.178.
Apr 27 03:12:48 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:13:01 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","HEQ0510129:1","HUMIDITY",63}],[methodName:"event",params:{"Bi
Apr 27 03:13:01 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:13:01 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","HEQ0510129:1","HUMIDITY",63}],[methodName:"event",params:{"CB200
Apr 27 03:13:01 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:13:21 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","LEQ0081955:2","ACTUAL_TEMPERATURE",14.600000}],[methodName:"e
Apr 27 03:13:21 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:13:21 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","LEQ0081955:2","ACTUAL_TEMPERATURE",14.600000}],[methodName:"even
Apr 27 03:13:21 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:13:27 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","HEQ0510129:2","ADJUSTING_COMMAND",0}],[methodName:"event",par
Apr 27 03:13:27 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:13:27 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","HEQ0510129:2","ADJUSTING_COMMAND",0}],[methodName:"event",params
Apr 27 03:13:27 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:13:33 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","KEQ0729410:4","CONTROL_MODE",1}],[methodName:"event",params:{
Apr 27 03:13:33 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:13:33 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","KEQ0729410:4","CONTROL_MODE",1}],[methodName:"event",params:{"CB
Apr 27 03:13:33 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:13:36 homematic-ccu2 user.debug setclock: Try to get time from ntp.homematic.com
Apr 27 03:13:39 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","KEQ0519697:4","CONTROL_MODE",1}],[methodName:"event",params:{"CB
Apr 27 03:13:39 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:13:39 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","KEQ0519697:4","CONTROL_MODE",1}],[methodName:"event",params:{
Apr 27 03:13:39 homematic-ccu2 user.err rfd: XmlRpc transport error
Apr 27 03:13:45 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","LEQ0002140:2","ACTUAL_TEMPERATURE",18.700000}],[methodName:"even
Kannst Du damit etwas anfangen?
Viele Grüße Nie
Hallo Nic,
das sieht in der Tat so aus, als würde ab einem bestimmten Zeitpunkt der RPC-Server seine Arbeit einstellen. Die Fehlermeldungen in der CCU bedeuten, dass die CCU die Events an FHEM bzw. den RPC-Server schicken möchte, dieser aber keine Verbindung akzeptiert.
Das kann verschiedene Ursachen haben (ich gehe jetzt mal davon aus, dass der ccurpcd.pl Prozess noch läuft):
- Überlast auf dem FHEM Server
- Problem mit dem Perl-Modul RPC::Server
Bei meinen Tests ist das auch schon aufgetreten. Allerdings erst dann, wenn ich 3 CCU RPC-Schnittstellen (Wireless, Wired und Homematic IP) auf einen RPC-Server Prozess in FHEM losgelassen habe. Dann sind einige Events verloren gegangen und ich hatte die gleichen Meldungen im CCU Log. Ganz am Anfang habe ich auch mit dem FHEM-Webserver als RPC-Server experimentiert. Auch da gab es hin und wieder diese Meldungen im CCU-Log und es sind Events verloren gegangen. In beiden Fällen kam es aber nie vor, dass der RPC-Server komplett aufgegeben hat.
Wenn das Problem auftritt, könntest Du auf dem FHEM-Server mal den Befehl "netstat -an" ausführen. Die Ausgabe würde mich interessieren, insbesondere die Verbindungen mit Status "LISTEN" oder auch "TIME_WAIT", "SYN_WAIT".
Bzgl. Version RPC::Server muss ich erst mal bei mir nachschauen, welche ich benutze.
Nachtrag: Was ich auch interessant finde, sind die "Unknown event type" Meldungen für "EV". Das ist kein unknown Event-Type sondern der Standardtyp ... mysteriös.
Hallo zap,
So sieht das netstat dann aus:
pi@LiNaDo_Home:~ $ netstat -an
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:3777 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5544 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:7401 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2121 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8081 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8082 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:8084 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8085 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:16384 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:7072 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:52582 127.0.0.1:16384 VERBUNDEN
tcp 0 0 192.168.178.82:5544 192.168.178.101:51084 TIME_WAIT
tcp 5844 0 192.168.178.82:7401 192.168.178.101:53861 CLOSE_WAIT
tcp 0 0 127.0.0.1:42692 127.0.0.1:9000 VERBUNDEN
tcp 0 0 192.168.178.82:5544 192.168.178.101:51126 TIME_WAIT
tcp 0 0 192.168.178.82:8083 192.168.178.201:34351 TIME_WAIT
tcp 4415 0 192.168.178.82:7401 192.168.178.101:53854 CLOSE_WAIT
tcp 0 0 192.168.178.82:5544 192.168.178.101:51094 TIME_WAIT
tcp 0 0 192.168.178.82:5544 192.168.178.101:51074 TIME_WAIT
tcp 0 0 192.168.178.82:5544 192.168.178.101:51110 TIME_WAIT
tcp 0 3808 192.168.178.82:22 192.168.178.201:39749 VERBUNDEN
tcp 0 0 192.168.178.82:7401 192.168.178.101:53745 VERBUNDEN
tcp 0 0 127.0.0.1:42678 127.0.0.1:9000 VERBUNDEN
tcp 0 0 192.168.178.82:41394 192.168.178.101:2001 VERBUNDEN
tcp 0 0 127.0.0.1:9000 127.0.0.1:42692 VERBUNDEN
tcp 0 0 192.168.178.82:8083 192.168.178.201:34350 TIME_WAIT
tcp 5844 0 192.168.178.82:7401 192.168.178.101:53872 CLOSE_WAIT
tcp 0 0 192.168.178.82:5544 192.168.178.101:51112 TIME_WAIT
tcp 0 0 192.168.178.82:5544 192.168.178.101:51117 TIME_WAIT
tcp 0 0 192.168.178.82:5544 192.168.178.101:51092 TIME_WAIT
tcp 4415 0 192.168.178.82:7401 192.168.178.101:53844 CLOSE_WAIT
tcp 0 0 192.168.178.82:5544 192.168.178.101:51115 TIME_WAIT
tcp 0 0 192.168.178.82:5544 192.168.178.101:51103 TIME_WAIT
tcp 0 0 127.0.0.1:9001 127.0.0.1:48437 VERBUNDEN
tcp 0 0 192.168.178.82:5544 192.168.178.101:51101 TIME_WAIT
tcp 0 0 192.168.178.82:5544 192.168.178.101:51128 FIN_WAIT2
tcp 0 0 127.0.0.1:48437 127.0.0.1:9001 VERBUNDEN
tcp 6675 0 192.168.178.82:7401 192.168.178.101:53828 CLOSE_WAIT
tcp 6675 0 192.168.178.82:7401 192.168.178.101:53813 CLOSE_WAIT
tcp 0 0 192.168.178.82:8083 192.168.178.201:34352 VERBUNDEN
tcp 0 0 127.0.0.1:48422 127.0.0.1:9001 VERBUNDEN
tcp 0 0 127.0.0.1:9000 127.0.0.1:42678 VERBUNDEN
tcp 0 0 127.0.0.1:16384 127.0.0.1:52582 VERBUNDEN
tcp 0 0 127.0.0.1:9001 127.0.0.1:48422 VERBUNDEN
tcp 0 0 192.168.178.82:5544 192.168.178.101:51089 TIME_WAIT
tcp 0 0 192.168.178.82:5544 192.168.178.101:51107 TIME_WAIT
tcp6 0 0 :::9123 :::* LISTEN
tcp6 0 0 :::8101 :::* LISTEN
tcp6 0 0 127.0.0.1:32936 :::* LISTEN
tcp6 0 0 :::139 :::* LISTEN
tcp6 0 0 :::8080 :::* LISTEN
tcp6 0 0 :::80 :::* LISTEN
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 :::8443 :::* LISTEN
tcp6 0 0 :::445 :::* LISTEN
tcp6 1 0 192.168.178.82:50447 192.168.178.68:81 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40626 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:50150 192.168.178.79:54963 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40585 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40616 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40640 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40563 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40570 72.30.202.51:80 CLOSE_WAIT
tcp6 0 0 192.168.178.82:9123 192.168.178.101:48009 TIME_WAIT
tcp6 1 0 192.168.178.82:34405 192.168.178.1:49000 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40630 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40559 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40621 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40573 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40612 72.30.202.51:80 CLOSE_WAIT
tcp6 0 0 192.168.178.82:9123 192.168.178.101:47996 TIME_WAIT
tcp6 0 0 192.168.178.82:9123 192.168.178.101:47970 TIME_WAIT
tcp6 1 0 192.168.178.82:40601 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40613 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:39674 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40564 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40594 72.30.202.51:80 CLOSE_WAIT
tcp6 0 0 192.168.178.82:40656 72.30.202.51:80 VERBUNDEN
tcp6 1 0 192.168.178.82:40627 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40628 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40654 72.30.202.51:80 CLOSE_WAIT
tcp6 0 0 192.168.178.82:9123 192.168.178.101:48001 TIME_WAIT
tcp6 0 0 192.168.178.82:9123 192.168.178.101:47990 TIME_WAIT
tcp6 0 0 192.168.178.82:9123 192.168.178.101:47984 TIME_WAIT
tcp6 1 0 192.168.178.82:40577 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40610 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40606 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40575 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40611 72.30.202.51:80 CLOSE_WAIT
tcp6 0 0 192.168.178.82:9123 192.168.178.101:48015 FIN_WAIT2
tcp6 1 0 192.168.178.82:40595 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40648 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40651 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40636 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40581 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40634 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40587 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40629 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40589 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40635 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40565 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40614 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40566 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:49216 192.168.178.87:8091 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40645 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40608 72.30.202.51:80 CLOSE_WAIT
tcp6 0 0 192.168.178.82:9123 192.168.178.101:47973 TIME_WAIT
tcp6 1 0 192.168.178.82:40619 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40599 72.30.202.51:80 CLOSE_WAIT
tcp6 0 0 192.168.178.82:9123 192.168.178.101:47993 TIME_WAIT
tcp6 0 0 192.168.178.82:9123 192.168.178.101:48006 TIME_WAIT
tcp6 1 0 192.168.178.82:40576 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40644 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40579 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40617 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40562 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:34408 192.168.178.1:49000 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40641 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40593 72.30.202.51:80 CLOSE_WAIT
tcp6 0 0 192.168.178.82:40659 72.30.202.51:80 VERBUNDEN
tcp6 1 0 192.168.178.82:40604 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40609 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40586 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:34404 192.168.178.1:49000 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40623 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40618 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40647 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40600 72.30.202.51:80 CLOSE_WAIT
tcp6 0 0 192.168.178.82:9123 192.168.178.101:47987 TIME_WAIT
tcp6 1 0 192.168.178.82:40633 72.30.202.51:80 CLOSE_WAIT
tcp6 0 0 192.168.178.82:40657 72.30.202.51:80 VERBUNDEN
tcp6 1 0 192.168.178.82:40572 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40631 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40638 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40605 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40583 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40622 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40591 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40574 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40607 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40637 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40588 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40571 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40590 72.30.202.51:80 CLOSE_WAIT
tcp6 0 0 192.168.178.82:40658 72.30.202.51:80 VERBUNDEN
tcp6 1 0 192.168.178.82:40567 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40561 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40620 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40582 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40642 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40639 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40592 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40632 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40558 72.30.202.51:80 CLOSE_WAIT
tcp6 0 0 192.168.178.82:9123 192.168.178.101:48004 TIME_WAIT
tcp6 1 0 192.168.178.82:40603 72.30.202.51:80 CLOSE_WAIT
tcp6 0 0 192.168.178.82:9123 192.168.178.101:47979 TIME_WAIT
tcp6 1 0 192.168.178.82:40649 72.30.202.51:80 CLOSE_WAIT
tcp6 0 0 192.168.178.82:9123 192.168.178.101:47963 TIME_WAIT
tcp6 1 0 192.168.178.82:40655 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40598 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40560 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40643 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40615 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40580 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40584 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40650 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40578 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40646 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:40602 72.30.202.51:80 CLOSE_WAIT
tcp6 1 0 192.168.178.82:47238 192.168.178.69:46511 CLOSE_WAIT
udp 0 0 0.0.0.0:32814 0.0.0.0:*
udp 0 0 0.0.0.0:68 0.0.0.0:*
udp 0 0 0.0.0.0:68 0.0.0.0:*
udp 0 0 192.168.178.82:123 0.0.0.0:*
udp 0 0 127.0.0.1:123 0.0.0.0:*
udp 0 0 0.0.0.0:123 0.0.0.0:*
udp 0 0 192.168.178.255:137 0.0.0.0:*
udp 0 0 192.168.178.82:137 0.0.0.0:*
udp 0 0 0.0.0.0:137 0.0.0.0:*
udp 0 0 192.168.178.255:138 0.0.0.0:*
udp 0 0 192.168.178.82:138 0.0.0.0:*
udp 0 0 0.0.0.0:138 0.0.0.0:*
udp 0 0 0.0.0.0:5353 0.0.0.0:*
udp 0 0 0.0.0.0:1900 0.0.0.0:*
udp 0 0 0.0.0.0:9116 0.0.0.0:*
udp6 0 0 :::52796 :::*
udp6 0 0 :::56908 :::*
udp6 0 0 :::45162 :::*
udp6 0 0 fe80::b179:1b02:e95:123 :::*
udp6 0 0 ::1:123 :::*
udp6 0 0 :::123 :::*
udp6 0 0 :::5353 :::*
udp6 0 0 :::42804 :::*
udp6 0 0 192.168.178.82:34114 :::*
udp6 0 0 :::38744 :::*
udp6 0 0 :::1900 :::*
udp6 0 0 :::56257 :::*
raw6 0 0 :::58 :::* 7
Aktive Sockets in der UNIX-Domäne (Server und stehende Verbindungen)
Proto RefCnt Flags Type State I-Node Pfad
unix 4 [ ] DGRAM 22539 /run/wpa_supplicant/wlan0
unix 2 [ ACC ] STREAM HÖRT 9684 @/tmp/.X11-unix/X0
unix 2 [ ACC ] STREAM HÖRT 8502 /var/run/avahi-daemon/socket
unix 2 [ ACC ] STREAM HÖRT 8504 /var/run/dbus/system_bus_socket
unix 2 [ ] DGRAM 8526 /var/run/thd.socket
unix 2 [ ACC ] STREAM HÖRT 11530 /tmp/ssh-RQzjsqm2RGzQ/agent.1024
unix 2 [ ] DGRAM 22577 /tmp/libdhcpcd-wpa-1020.4
unix 2 [ ] DGRAM 22578 /tmp/libdhcpcd-wpa-1020.5
unix 2 [ ACC ] STREAM HÖRT 7051 /var/run/dhcpcd.sock
unix 2 [ ACC ] STREAM HÖRT 7053 /var/run/dhcpcd.unpriv.sock
unix 2 [ ACC ] STREAM HÖRT 10881 /tmp/.pcmanfm-socket--0-pi
unix 2 [ ACC ] STREAM HÖRT 9750 @/tmp/dbus-9cHuB7oc2I
unix 2 [ ] DGRAM 4787 /run/systemd/journal/syslog
unix 2 [ ACC ] STREAM HÖRT 9685 /tmp/.X11-unix/X0
unix 2 [ ACC ] STREAM HÖRT 9745 /tmp/ssh-5Qb0Ylc5rYzK/agent.876
unix 2 [ ACC ] STREAM HÖRT 9120 /tmp/.menu-cached-:0-pi
unix 2 [ ] DGRAM 1245 /run/systemd/notify
unix 2 [ ACC ] STREAM HÖRT 8926 /var/run/samba/nmbd/unexpected
unix 2 [ ACC ] STREAM HÖRT 1247 /run/systemd/private
unix 2 [ ] DGRAM 1263 /run/systemd/shutdownd
unix 14 [ ] DGRAM 1265 /run/systemd/journal/dev-log
unix 2 [ ACC ] SEQPAKET HÖRT 1269 /run/udev/control
unix 2 [ ] DGRAM 9721 /run/user/1000/systemd/notify
unix 2 [ ACC ] STREAM HÖRT 1273 /run/systemd/journal/stdout
unix 2 [ ACC ] STREAM HÖRT 9723 /run/user/1000/systemd/private
unix 6 [ ] DGRAM 1275 /run/systemd/journal/socket
unix 2 [ ACC ] STREAM HÖRT 9126 @/dbus-vfs-daemon/socket-l7grkNtl
unix 3 [ ] STREAM VERBUNDEN 11030
unix 3 [ ] STREAM VERBUNDEN 9097 /run/systemd/journal/stdout
unix 2 [ ] DGRAM 10880
unix 3 [ ] STREAM VERBUNDEN 8520
unix 2 [ ] DGRAM 10270
unix 3 [ ] STREAM VERBUNDEN 11026
unix 3 [ ] STREAM VERBUNDEN 9846
unix 3 [ ] STREAM VERBUNDEN 9814 /var/run/dbus/system_bus_socket
unix 3 [ ] STREAM VERBUNDEN 11654
unix 3 [ ] STREAM VERBUNDEN 5921
unix 3 [ ] STREAM VERBUNDEN 9110
unix 2 [ ] DGRAM 21515
unix 3 [ ] STREAM VERBUNDEN 9095 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM VERBUNDEN 10726 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM VERBUNDEN 7142
unix 3 [ ] STREAM VERBUNDEN 10885 /run/systemd/journal/stdout
unix 3 [ ] STREAM VERBUNDEN 11590
unix 3 [ ] STREAM VERBUNDEN 9114  
hmm, was mir auffällt sind die vielen CLOSE_WAITs auf dem RPC-Server Port 7401. Bei mir sieht das so aus (gefiltert auf die 7401):
netstat -an | grep 7401
tcp 0 0 0.0.0.0:7401 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.12:7401 192.168.1.11:41120 ESTABLISHED
D.h. Eine aufgebaute Verbindung der CCU und der Server, der auf eingehende Verbindungen wartet. Keine CLOSE_WAITs.
Ist Dein FHEM per WLAN im Netz?
Dann fällt mir noch auf, dass Deine CCU (müsste die IP mit der 101 hinten sein) Verbindungen zum Port 5544 aufbaut. Außerdem scheint ein Prozess auf dem FHEM-System auf Port 5544 zu lauschen. Läuft da parallel noch eine andere Kommunikation mit der CCU? Das kannst Du wie folgt rausbekommen:
netstat -tulpn | grep 5544
In der letzten Spalte steht der Name des Prozesses, der den Port nutzt.
Hallo zap,
Zitathmm, was mir auffällt sind die vielen CLOSE_WAITs auf dem RPC-Server Port 7401. Bei mir sieht das so aus (gefiltert auf die 7401):
Code: [Auswählen]
netstat -an | grep 7401
tcp 0 0 0.0.0.0:7401 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.12:7401 192.168.1.11:41120 ESTABLISHED
D.h. Eine aufgebaute Verbindung der CCU und der Server, der auf eingehende Verbindungen wartet. Keine CLOSE_WAITs.
Ist Dein FHEM per WLAN im Netz?
Ja, ist die Testmaschine, die ist per WLAN im Netz. ist das schlimm?
ZitatDann fällt mir noch auf, dass Deine CCU (müsste die IP mit der 101 hinten sein) Verbindungen zum Port 5544 aufbaut. Außerdem scheint ein Prozess auf dem FHEM-System auf Port 5544 zu lauschen. Läuft da parallel noch eine andere Kommunikation mit der CCU? Das kannst Du wie folgt rausbekommen:
Code: [Auswählen]
netstat -tulpn | grep 5544
In der letzten Spalte steht der Name des Prozesses, der den Port nutzt.
Stimmt, das war noch eine alte IP Symcon Testversion. habe ich jetzt mal Deaktiviert und den fhem server neu gestartet.
Jetzt nach dem Neustart sieht es wie folgt aus.
netstat:
pi@LiNaDo_Home:~ $ netstat -an | grep 7401
tcp 0 0 0.0.0.0:7401 0.0.0.0:* LISTEN
tcp 0 0 192.168.178.82:7401 192.168.178.101:37755 VERBUNDEN
Wenn das WLAN stabil läuft, ist das kein Problem. Blöd ist nur, wenn ab und zu die Verbindung abbricht. Das könnte sich negativ auf den RPC-Server auswirken.
Aber ich habe eher IP-Symcon im verdacht. Das registriert sich ja auch bei der CCU, und zwar für den gleichen Port (2001) und mit der gleichen Ziel-IP (Deinem FHEM). Das könnte zu Konflikten führen.
Bin gespannt, ob es nun ohne Abbruch läuft.
Hallo zusammen,
habe heute bei der CCU2 ein Firmwareupdate auf V2.19.9. Das Modul funktioniert in fhem weiterhin ;-)
VG
klaso
Ich habe gerade eine neue Version (Link siehe 1. Beitrag) eingecheckt. Die neue Version besteht nun aus folgenden Dateien:
88_HMCCU.pm 88_HMCCUDEV.pm, 88_HMCCUCHN.pm, HMCCUConf.pm, RPCQueue.pm, ccurpcd.pl
Neu ist die Datei HMCCUConf.pm. Sie enthält Default-Attribute für eine Reihe von Homematic Devices (s.u. Befehl 'set defaults'). Außerdem benötigt HMCCU ab sofort das FHEM Standardmodul SubProcess.pm (Teil von FHEM).
Neue Funktionen und Änderungen in der Version 3.2:
- Homematic Gruppen werden nun uneingeschränkt unterstützt und vom RPC-Server aktualisiert. Hierzu muss das Attribut rpcport im IO Device (HMCCU) um den Port 9292 ergänzt werden. Das Attribut mapdatapoint in HMCCUDEV Devices wird damit obsolet.
- Unterstützung für Rauchmeldergruppen (CCU Adressen beginnen mit einem '*')
- Das Modul 88_HMCCU enthält nun einen RPC-Server. Um diesen zu aktivieren muss beim IO Device das Attribut ccuflags auf 'intrpc' gesetzt werden. Dann wird ccurpcd.pl nicht mehr verwendet.
- Das Attribut ccuverify bei HMCCUDEV Devices kennt nun den Wert 2. Dieser bewirkt, dass beim Setzen eines Datenpunktes in der CCU das zugehörige Reading in FHEM sofort (d.h. noch vor der Rückmeldung durch den RPC Server) aktualisiert wird. Dadurch könnte das "Springen" des Sliders bei der Bedienung eines Jalousienaktors über das Webinterface vermieden werden (bitte testen!)
- Mit dem Attribut 'substitute' können nun auch Fließkommawerte ersetzt werden, sofern sich eine Regel auf einen bestimmten Datenpunkt (Präfix 'Name!') bezieht.
- Das Attribut 'statedatapoint' akzeptiert nun die gleiche Notation wie 'controldatapoint', d.h. <channelnumber>.<datapoint>
Hinweis: Ich habe in dieser Version ziemlich viel geändert (und dementsprechend lange getestet). Bugs sind trotzdem nicht ausgeschlossen. Daher macht Euch bitte eine Kopie der alten Module, bevor Ihr die neuen installiert, damit der Rückweg einfach ist. Bitte HMCCUConf.pm bei der Installation nicht vergessen.
Bitte insbesondere den eingebauten RPC Server (ccuflags = intrpc) intensiv testen. In der nächsten Version soll nur noch dieser verwendet werden. Dann entfallen ccurpcd.pl und RPCQueue.pm.Die Verwendung des internen RPC Servers ist daran zu erkennen, dass statt ccurpcd.pl einer oder mehrere FHEM Prozesse laufen. Ansonsten ist das Verhalten identisch (Logfiles, Prozess-IDs im IO Device usw.).
Wenn jemand gerne weitere Default-Attribute in HMCCUConf.pm hätte, bitte Meldung an mich mit exaktem Homematic Gerätetyp und den Attribut-Werten. Dann nehme ich das auf. Erleichtert die Definition neuer Geräte ungemein.
Zitat von: zap am 22 Mai 2016, 19:13:09
- Das Attribut ccuverify bei HMCCUDEV Devices kennt nun den Wert 2. Dieser bewirkt, dass beim Setzen eines Datenpunktes in der CCU das zugehörige Reading in FHEM sofort (d.h. noch vor der Rückmeldung durch den RPC Server) aktualisiert wird. Dadurch könnte das "Springen" des Sliders bei der Bedienung eines Jalousienaktors über das Webinterface vermieden werden (bitte testen!)
Jalousienaktor: auf den ersten Blick ja. :-)
Dimmaktor: auf den ersten Blick nein. :-)
VG Alex
Zitat von: aski71 am 24 Mai 2016, 23:19:04
Jalousienaktor: auf den ersten Blick ja. :-)
Dimmaktor: auf den ersten Blick nein. :-)
VG Alex
Habe leider keinen Dimmaktor um das zu testen. Bei meinen Heizungsthermostaten funktioniert es (sogar mit ccuverify = 0). Muss mal ein paar Log-Statements einbauen, um mehr Infos zu erhalten, was da beim Dimmer anders läuft. Werde eine spezielle Debug-Version in den nächsten Tagen bereit stellen.
Welchen Wert hat bei Dir das Attribut rpcinterval im IO Device?
rpcinterval ist bei mir 3.
Hallo,
ich musste gerade meine CCU2 neustarten.
Danach hatte fhem keine richtige Verbindung mehr.
Erst nach einem "set ccu2 rpcserver off" und "set ccu2 rpcserver on" ging es wieder.
VG Alex
Ich hoffe, der CCU Neustart wurde nicht wg. HMCCU notwendig.
Das von Dir beschriebene Verhalten bei Neustart der CCU ist normal. Grund: wenn der RPC Server gestartet wird, registriert er sich bei der CCU als Empfänger von Nachrichten. Leider vergisst die CCU beim Neustart ihre registrierten Empfänger. Daher sollte man vor einem CCU Neustart den RPC Server stoppen und später wieder starten.
Merkt der RPC Server nicht irgendwie, dass die CCU Registrierung weg ist? Bei einem Stromausfall etc wäre es gut, wenn man nicht händisch eingreifen müsste.
Gruß
Julian
Nein, der RPC Server ist rein passiv. Er meldet sich aber per Notification, wenn für eine bestimmte Zeit keine Events von der CCU kamen: "No events from CCU since xxx seconds". Das xxx legt man mit dem Attribut rpcevtimeout fest. Dann kann man per notify mit einem "set rpcserver restart" darauf reagieren.
Andere Möglichkeit: per ping device die Erreichbarkeit der CCU checken und bei Fehler mit mindestens 1 Minute Verzögerung den RPC Server neu starten.
Hm, gehört so eine Logik nicht besser ins Modul, anstatt dass die sich jeder für sich (und doch wieder irgendwie gleich) zusammenstellt?
Gruß
Julian
Mm ... ja. Könnte ich machen. So in der Art: wenn Attribut rpcevtimeout gesetzt ist, wird bei Ausbleiben der Events der RPC Server neu bei der CCU registriert. Das wäre auch effektiver als die Prozesse komplett neu zu starten.
Ist für die nächste Version vorgemerkt.
Super, danke!
Dafür hätte ich auch plädiert. :D
Vielleicht sogar mit einem sinnvollen Default-Wert für rpcevtimeout vorbelegt?
Zitat von: zap am 27 Mai 2016, 22:52:45
Ist für die nächste Version vorgemerkt.
Klingt gut :-)
Hätte hier noch etwas zu fixen:
Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE UNREACH|^HUMIDITY|^TEMPERATURE|^LOWBAT20 20/ at ./FHEM/88_HMCCU.pm line 976.
Hatte zuvor per set-Default ein paar Standard-Configs eingespielt (dürfte hier von einem TH sein).
Gruß
Julian
Dürfte ein TH vom Typ HM-WDS40-TH-I sein. Kannst Du das FHEM Device rausfinden? Mich interessiert der Wert des Attributs ccureadingfilter. Sieht irgendwie seltsam aus in der Fehlermeldung mit dem "^LOWBAT20 20" am Ende. Der Default Wert für dieses Attribut endet eigentlich auf "^LOWBAT$".
Möglicherweise ist da beim Download der Datei HMCCUconf.pm etwas schief gegangen.
Gibt es denn die Möglichkeit die Readings umzubenennen? Ich würde z.B. gerne "FL_Motion-1.LEVEL" gerne nur als "pct" haben, damit es dem Fhem Standard entspricht und man es mit :FILTER Ausdrücken einfacher/übersichtlicher hat. Ist denn angedacht die Readings irgendwie zu mappen? Meine vorher schön übersichtlichen DOIFs verkomplizieren sich extrem, vor allem auch wegen der Abhängigkeit den Devicenamen mit im Reading zu haben, wenn es sich um ein HMCCUDEV Device handelt.
Es ist ja prima, dass man schon so viel einstellen kann über die Attribute. Aber es ist schon sehr aufwändig das für jedes Gerät einzustellen. Könnte man beim zentralen HMCCU Device nicht einen get-Befehl (zwecks User-Absicherung kein set-Befehl) machen, der aus einer Liste alle in der CCU verfügbaren Geräte anbietet und man diese einfach auswählen und anlegen kann? Dabei könnte man auch hinterlegen ob es jetzt sinnvoller ist ein HMCCUDEV oder HMCCUCHN Device anzulegen. So richtig optimal scheint mir beides nicht immer zu sein, manchmal möchte man bei so simplen Geräten wie einem Fenstersensor eigentlich Kanale 0+1 als Kombination haben, es aber trotzdem als HMCCUCHN anlegen, um die ganzen Präfixes bei den Readings zumindest los zu werden.
Ich weiß, der setter "defaults" soll hier eigentlich helfen. Neben dem, dass er besser als getter aufgehoben wäre, damit normale User die Konfig nicht mutwillig verpfuschen können, gilt es hier wohl die Datenbank etwas zu füttern. Dazu würde ich gerne etwas beisteuern. Nur scheitere ich schon daran mit eine zufriedenstellende Konfig zusammen zu schrauben bzw. bin mir bisher bei keinem Device sicher, ob das tatsächlich nicht besser geht. Die bisherigen Defaults und Beispiele hier im Forum fand ich alle eher weniger praxistauglich :-/
Könnte man auch die Doppelbelegung von STATE als Reading auflösen (ist zB bei Fenstersensoren drin)? Ich weiß, es kommt wohl so aus der CCU heraus. Ist aber in Fhem so nicht gut aufgehoben.
Die grundsätzliche Anbindung der CCU finde ich schon gut gelöst. Wie ist denn der Plan das rund zu machen, um es produktiv nutzbar zu machen?
Gruß
Julian
Zitat von: Loredo am 01 Juni 2016, 21:33:47
Die grundsätzliche Anbindung der CCU finde ich schon gut gelöst. Wie ist denn der Plan das rund zu machen, um es produktiv nutzbar zu machen?
Dein Beitrag hilft mir schon sehr, das "rund" zu machen. Auf solchen Input von Nutzern bin ich angewiesen, da ich bisher v.a. meine eigenen Anforderungen umgesetzt habe (ich nutze es bei mir in Verbindung mit Tablet-UI produktiv).
HMCCU verfolgt ein anderes Konzept als CUL_HM. HMCCU ist ein generischer Ansatz, in dem alle Feinheiten über Attribute definiert werden. Das hat den Vorteil, dass auch neue Homematic Geräte sofort genutzt werden können. Bei CUL_HM hingegen ist jeder Gerätetyp speziell implementiert. Das macht die Konfiguration für den Nutzer einfacher. Allerdings muss man bei neuen Geräten warten, bis die Unterstützung eingebaut ist und der Code wird extrem aufwändig (ok, das ist ein Problem des Entwicklers bzw. die Verlagerung der Komplexität in den Code).
Für einige Deiner Punkte kann ich mir zumindest Workarounds vorstellen. Mehr dazu demnächst. Die Geschichte mit den Devicenamen im Readingname bei HMCCUDEVs ist entstanden, da bei einigen Homematic Devices Datenpunkte mehrfach vorkommen. Zur Abgrenzung müsste ich zumindest die Kanalnummer in den Readingname aufnehmen. Bei HMCCUCHN ist das nicht notwendig, da sich das ja immer auf genau einen Kanal bezieht.
Aber danke für die Anregungen. Während die Finger das schreiben, arbeitet das Hirn schon daran ;-)
Zitat von: zap am 02 Juni 2016, 07:46:39
Aber danke für die Anregungen. Während die Finger das schreiben, arbeitet das Hirn schon daran ;-)
Klasse 8)
Auch wenn mein Feedback nicht so strukturiert war und mir noch 1000 andere Dinge durch den Kopf gegangen sind. Ich schaue mal weiter, brauche aber irgendwie recht fix eine Lösung meine Grundfunktionen daheim wieder ans laufen zu kriegen. Die Reading Namen sind dabei nur ein Randschauplatz.
Ich habe wohl eine Menge Geräte, die noch keine Defaults haben. Ich würde dafür auch gerne Defaults liefern, tue mich aber sehr schwer herauszufinden wie ich die überhaupt definiere. Beispielsweise habe ich einen Dimmaktor und möchte dabei neben dem eigentlichen Dimmwert auch die Hochdimmzeit sowie eine Ausschaltzeit definieren. Über CUL_HM geht das ganz einfach und soweit ich weiß werden diese Werte auch alle an den HM Aktor übertragen und nichts davon bleibt in Fhem. Da stellt sich nun die Frage wie ich das mit HMCCU löse? Ich kann zwar den LEVEL-Wert übergeben, aber wie übergebe ich gleichzeitig noch andere Werte? Natürlich wäre es schön, wenn die ganzen Setter irgendwie kompatibel wären und auch so heißen. Den generischen control-Setter kann es ja trotzdem geben und ich finde den Ansatz, dass alle Geräte direkt funktionieren können sollen sehr gut. Für die Praxis braucht es aber irgendwie mehr Kompatibilität/Interoperabilität.
Kannst du mir irgendwie helfen, um da besser rein zu kommen, damit ich dann auch mithelfen kann die Defaults-Datenbank zu vergrößern?
Ich erlaube mir mal, auf https://forum.fhem.de/index.php/topic,41060.msg429362.html#msg429362 zu verweisen und die Folgebeiträge. Inwieweit sich das hier mit HMCCU adaptieren lässt, weiß ich nicht.
Über einen XML-RPC-Aufruf geht das mit einem putParamset. Allerdings ist bei dem Dimmer wichtig, dass das putParamset in zwei Etappen durchgeführt wird, darum habe ich für das eigentlich einfache putParamset einen neuen Befehl implementiert, der das entsprechend aufteilt und durchführt.
Zitat von: Loredo am 02 Juni 2016, 16:40:32
Ich habe wohl eine Menge Geräte, die noch keine Defaults haben. Ich würde dafür auch gerne Defaults liefern, tue mich aber sehr schwer herauszufinden wie ich die überhaupt definiere.
Grundsätzlich solltest Du für jedes Gerät folgende Attribute festlegen:
ccureadingfilter: Einige Gerätetypen liefern eine Unmenge an Datenpunkten. Ohne den Filter würde das zu sehr vielen Readings führen. Eine Liste der verfügbaren Datenpunkte liefert "get deviceinfo". In den Filter müssen nur Datenpunkte aufgenommen werden, die die Flags R=Read oder E=Event gesetzt haben. Die anderen sind Write Only.
statechannel bzw.
statedatapoint: Legt fest, über welchen Kanal bzw. welchen Datenpunkt die Befehle "get devstate" und "set devstate" auf ein Gerät zugreifen. Wenn das nicht festgelegt ist, kann devstate nicht verwendet werden (Zugriff per get/set datapoint geht natürlich immer).
stripnumber: Legt fest. ob Fließkommawerte abgeschnitten oder mit allen Nachkommastellen in Readings gespeichert werden. Empfehlung wäre 1, d.h. 1 Nachkommastelle, wobei 2 nicht für 2 Nachkommastellen sondern für 0 Nachkommastellen steht.
substitute: Ersetzt bestimmte Werte aus der CCU durch sprechende Texte (z.B. true/1 => on, false/0 => off)
statevals: Umkehr von substitute, d.h. ersetzt FHEM Werte vor dem Senden an die CCU (z.B. on => true, off => false)
Das sind wie gesagt die Attribute, die ich immer für ein Device setze. Wenn ich etwas mehr Komfort in der FHEM Oberfläche haben möchte, kommen noch Attribute wie controldatapoint, widgetOverride, cmdIcon usw. dazu.
Zitat
Beispielsweise habe ich einen Dimmaktor und möchte dabei neben dem eigentlichen Dimmwert auch die Hochdimmzeit sowie eine Ausschaltzeit definieren. Über CUL_HM geht das ganz einfach und soweit ich weiß werden diese Werte auch alle an den HM Aktor übertragen und nichts davon bleibt in Fhem. Da stellt sich nun die Frage wie ich das mit HMCCU löse? Ich kann zwar den LEVEL-Wert übergeben, aber wie übergebe ich gleichzeitig noch andere Werte?
Habe leider keinen Dimmer, daher hier einige theoretische Tipps, die Du ggf. mal testen könntest: Wenn ein Homematic Gerät einen Datenpunkt ON_TIME anbietet (s.a. get deviceinfo), stellt HMCCUDEV automatisch einen Set-Befehl on-for-timer bereit, mit dem das Gerät für eine bestimmte Zeit eingeschaltet werden kann. Sollte bei einem Dimmer funktionieren, tut es aber leider nicht, weil ich da noch einen Bug drin habe (gerade gefunden).
Wenn zusätzlich noch die Ramp-Time mitgegeben werden soll, müsstest Du 2 bzw. 3 Befehle absetzen. Beispiel (LEVEL muss zuletzt gesetzt werden):
set mydev datapoint 1.RAMP_TIME 3.0
set mydev datapoint 1.ON_TIME 600
set mydev datapoint 1.LEVEL 0.7
oder
attr mydev statechannel 1
attr mydev statedatapoint LEVEL
attr mydev statevals on:1.0,off:0.0,half:0.5
set mydev datapoint 1.RAMP_TIME 3.0
set mydev datapoint 1.ON_TIME 600
set mydev half
Umbenennen von Readings: Wenn Du sofort eine Lösung brauchst, kann ich Dir momentan nur die Definition eines Userreadings empfehlen (umständlich, ich weiß). Aber ich arbeite daran, zumal es mich selbst stört, dass ich aufgrund des Devicenames im Reading einige sinnvolle Defaults nicht definieren kann.
Sorry, dass ich eine Zeit lang nicht mehr online war... Aber nun meine erste Rückmeldung zu den neuen Funktionen und Änderungen:Zitat von: zap am 22 Mai 2016, 19:13:09
Neue Funktionen und Änderungen in der Version 3.2:
- Homematic Gruppen werden nun uneingeschränkt unterstützt und vom RPC-Server aktualisiert. Hierzu muss das Attribut rpcport im IO Device (HMCCU) um den Port 9292 ergänzt werden. Das Attribut mapdatapoint in HMCCUDEV Devices wird damit obsolet.
- Unterstützung für Rauchmeldergruppen (CCU Adressen beginnen mit einem '*')
- Das Modul 88_HMCCU enthält nun einen RPC-Server. Um diesen zu aktivieren muss beim IO Device das Attribut ccuflags auf 'intrpc' gesetzt werden. Dann wird ccurpcd.pl nicht mehr verwendet.
- Das Attribut ccuverify bei HMCCUDEV Devices kennt nun den Wert 2. Dieser bewirkt, dass beim Setzen eines Datenpunktes in der CCU das zugehörige Reading in FHEM sofort (d.h. noch vor der Rückmeldung durch den RPC Server) aktualisiert wird. Dadurch könnte das "Springen" des Sliders bei der Bedienung eines Jalousienaktors über das Webinterface vermieden werden (bitte testen!)
- Mit dem Attribut 'substitute' können nun auch Fließkommawerte ersetzt werden, sofern sich eine Regel auf einen bestimmten Datenpunkt (Präfix 'Name!') bezieht.
- Das Attribut 'statedatapoint' akzeptiert nun die gleiche Notation wie 'controldatapoint', d.h. <channelnumber>.<datapoint>
Port 9292:Habe ich zusätzlich zu 2001 gesetzt und keine "Auswirkung" wahrgenommen.
RauchmeldergruppenKann jetzt definiert und der Status ausgelesen werden. Diese Gruppe kann als HMCCUDEV definiert werden. Dann hat sie 2 Channels. Den Channel 0 und 1. Channel 1 kann ausgelesen werden. Channel 0 geht imemr auf Error. In der CCU hat die Rauchmeldergruppe nur einen Channel. Siehe auch screenshot im Anhang. Komisch, ist da noch in Bug?
ccuverify Wert 2Der Rolladenaktor springt immer noch. Auch bei einem Dimmer ist das so.
ccuflags auf 'intrpc' gesetztIch erhalte bisher nicht bekannte Einträge im logfile, die ich gerne verstehen würde.
2016.06.12 11:35:53 2 : HMCCU: Create child process with timeouts 0.01 and 0.25
2016.06.12 11:35:53 0 : HMCCU: Child process for server CB2001 started with PID 22639
2016.06.12 11:35:53 2 : HMCCU: Create child process with timeouts 0.01 and 0.25
2016.06.12 11:35:53 0 : HMCCU: Child process for server CB9292 started with PID 22640
2016.06.12 11:35:53 0 : RPC server(s) starting
2016.06.12 11:35:56 0 : HMCCU: Received SL event. RPC server CB2001 enters server loop
2016.06.12 11:36:03 1 : HMCCU: Registering callback http://192.168.178.15:7401/fh2001 with ID CB2001 at http://192.168.178.16:2001/
2016.06.12 11:36:05 1 : HMCCU: RPC callback with URL http://192.168.178.15:7401/fh2001 initialized
2016.06.12 11:36:08 0 : HMCCU: Received IN event. RPC server CB2001 initialized.
2016.06.12 11:36:08 0 : HMCCU: Received SL event. RPC server CB9292 enters server loop
2016.06.12 11:36:15 1 : HMCCU: Registering callback http://192.168.178.15:14692/fh9292 with ID CB9292 at http://192.168.178.16:9292/groups
2016.06.12 11:36:25 1 : HMCCU: RPC callback with URL http://192.168.178.15:14692/fh9292 initialized
2016.06.12 11:36:31 0 : HMCCU: Received IN event. RPC server CB9292 initialized.
2016.06.12 11:36:31 2 : HMCCU: Update of device VIR0000001 failed
2016.06.12 11:36:31 2 : HMCCU: Device *MEQ0257246:0 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Device LTK0044162:2 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Device LTK0044162:1 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Updated devices. Success=13 Failed=4
2016.06.12 11:36:31 1 : HMCCU: All RPC servers running
Was bedeutet z.B.: "HMCCU: Update of device VIR0000001 failed"???
Den Rest habe ich noch nicht getestet. Weiters Feedback folgt.
Zitat von: Achiim am 11 Juni 2016, 16:03:04
Habe ich zusätzlich zu 2001 gesetzt und keine "Auswirkung" wahrgenommen.
Ich gehe jetzt mal davon aus, dass Du in der CCU2 eine Gruppe definiert hast (z.B. einen Thermostaten und einen Fenstersensor). Wenn Du nun in FHEM ein HMCCUDEV Device für diese Gruppe anlegst, sollten die Readings entsprechend aktualisiert werden. Diese Aktualisierung läuft bei Gruppen über den Port 9292.
Beispiel: listing einer meiner Gruppen mit einem Heizungsthermostat und einem Wandthermostat. Die Mitglieder müssen bei der Definition mit "group=" angegeben werden.
Internals:
DEF G-AZ-HZ group=KL-AZ-HZ,KL-AZ-TH
IODev d_ccu
NAME HM_G_AZ_HZ
NR 123
STATE T: 23.5° H: 60% D: 4.5° P: 15.3° V: 0% MANU
TYPE HMCCUDEV
ccuaddr INT0000001
ccudevstate Active
ccugroup LEQ0851979,LEQ1462664
ccuif VirtualDevices
ccuname G-AZ-HZ
ccutype HM-CC-VG-1
channels 3
statevals devstate
Readings:
2016-06-14 16:53:14 DEWPOINT 15.3
2016-05-26 21:31:24 G-AZ-HZ.0.LOWBAT no
2016-06-14 16:53:14 G-AZ-HZ.1.CONTROL_MODE MANU
2016-06-14 16:53:14 G-AZ-HZ.1.SET_TEMPERATURE 4.5
2016-05-26 21:31:25 KL-AZ-HZ.0.LOWBAT no
2016-06-14 16:53:13 KL-AZ-HZ.4.CONTROL_MODE MANU
2016-06-14 16:53:14 KL-AZ-HZ.4.SET_TEMPERATURE 4.5
2016-06-14 16:53:14 KL-AZ-HZ.4.VALVE_STATE 0
2016-05-26 21:31:24 KL-AZ-TH.0.LOWBAT no
2016-06-14 16:52:43 KL-AZ-TH.1.HUMIDITY 60
2016-06-14 16:52:43 KL-AZ-TH.1.TEMPERATURE 23.5
2016-06-14 16:41:58 KL-AZ-TH.2.CONTROL_MODE MANU
2016-06-14 16:52:23 KL-AZ-TH.2.SET_TEMPERATURE 4.5
2016-06-14 16:41:58 KL-AZ-TH.2.WINDOW_OPEN_REPORTING closed
2016-04-21 18:27:52 LOWBAT_COUNT 0
2016-04-21 18:27:52 LOWBAT_STATE no
2016-06-14 16:53:14 control 4.5
2016-06-14 16:53:14 state 4.5
Attributes:
IODev d_ccu
ccureadingfilter (^SET_TEMPERATURE|^TEMPERATURE|^HUMIDITY|LOWBAT$|^VALVE|^CONTROL|^WINDOW_OPEN)
cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
controldatapoint 1.SET_TEMPERATURE
event-on-change-reading .*
eventMap /datapoint 1.MANU_MODE 20.0:Manu/datapoint 1.AUTO_MODE 1:Auto/datapoint 1.BOOST_MODE 1:Boost/datapoint 1.MANU_MODE 4.5:off/datapoint 1.MANU_MODE 30.5:on/
group Heizung Arbeitszimmer
icon rc_HOME
room Homematic
stateFormat T: KL-AZ-TH.1.TEMPERATURE° H: KL-AZ-TH.1.HUMIDITY% D: KL-AZ-TH.2.SET_TEMPERATURE° P: DEWPOINT° V: KL-AZ-HZ.4.VALVE_STATE% G-AZ-HZ.1.CONTROL_MODE
statechannel 1
statedatapoint SET_TEMPERATURE
stripnumber 1
substitute LOWBAT!(0|false):no,(1|true):yes;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed
userReadings DEWPOINT {HMCCU_Dewpoint($name,"KL-AZ-TH.1.TEMPERATURE", "KL-AZ-TH.1.HUMIDITY","n/a")}, LOWBAT_STATE:(KL-AZ-TH.0.LOWBAT|KL-AZ-HZ.0.LOWBAT) {HMCCU_AggReadings($name, "KL.*LOWBAT","and","no","yes")}, LOWBAT_COUNT:(KL-AZ-TH.0.LOWBAT|KL-AZ-HZ.0.LOWBAT) {HMCCU_AggReadings($name, "KL.*LOWBAT","cnt","yes","")}
webCmd control:Auto:Manu:Boost:on:off
widgetOverride control:slider,10,1,25
Zitat
Rauchmeldergruppen
Kann jetzt definiert und der Status ausgelesen werden. Diese Gruppe kann als HMCCUDEV definiert werden. Dann hat sie 2 Channels. Den Channel 0 und 1. Channel 1 kann ausgelesen werden. Channel 0 geht imemr auf Error. In der CCU hat die Rauchmeldergruppe nur einen Channel. Siehe auch screenshot im Anhang. Komisch, ist da noch in Bug?
Den Kanal 0 fügt die CCU bei jedem Gerät hinzu. Darin werden Datenpunkte wie UNREACH oder RSSI verwaltet. Der Kanal 0 kann normalerweise nur gelesen werden. Bitte definiere das Rauchmelderteam mal mit HMCCUDEV statt mit HMCCUCHN. Könnte sein, dass das besser funktioniert.
[quote ]
ccuverify Wert 2
Der Rolladenaktor springt immer noch. Auch bei einem Dimmer ist das so.
[/quote]
Schade. Bei einem Slider für einen Thermostaten funktioniert es. Aber ich gebe noch nicht auf ;-)
Zitat
2016.06.12 11:36:31 2 : HMCCU: Update of device VIR0000001 failed
2016.06.12 11:36:31 2 : HMCCU: Device *MEQ0257246:0 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Device LTK0044162:2 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Device LTK0044162:1 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Updated devices. Success=13 Failed=4
2016.06.12 11:36:31 1 : HMCCU: All RPC servers running
Was bedeutet z.B.: "HMCCU: Update of device VIR0000001 failed"???
Die Startmeldungen sehen gut aus. Das Device LTK... ist vermutlich ein Schalter oder Taster. Daher die Meldung "no readable datapoints".
Das Device *M... ist der Kanal 0 der Rauchmeldergruppe. Hier gibt es anscheinen wirklich ein Problem. Eigentlich müssten gerade der Kanal lesbare Datenpunkte enthalten. Wie gesagt, muss ich testen.
Das Device VIR... ist die Adresse einer HMCCUDEV Gruppe, die keine Entsprechung in der CCU hat. Das Gruppieren in FHEM mit HMCCUDEV funktioniert grundsätzlich, jedoch habe ich noch keinen sinnvollen Anwendungsfall gefunden. Diese reinen FHEM Gruppen haben die Adresse VIR... während CCU Gruppen die Adress INT... haben. Beim Starten werden alle Devices einmal aktualisiert, d.h. die aktuellen Werte aus der CCU geholt. Das funktioniert für reine FHEM Gruppen nicht, da es ja kein Pendant in der CCU gibt.
Moin zusammen,
vorweg, ich bin Anfänger bzw. ich habe bei den ganzen Möglichkeiten/Parametern nicht den Durchblick.
Im FHEM habe ich u.a. eine Jalousie die ich steuern kann:
# Jalousiensteuerung
define Jalousien_Kueche_klein GenShellSwitch /home/pi/fernotron-control/FernotronRemote.sh 1 u d
attr Jalousien_Kueche_klein cmdIcon on:black_up off:black_down
attr Jalousien_Kueche_klein group Jalousien
attr Jalousien_Kueche_klein room Küche
Die meisten Jalousien laufen bei mir allerdings über die CCU2.
Ich hätte jetzt gerne, dass ich mit der CCU2 eine Verbindung zum FHEM herstelle und diese eine Jalousie über die CCU2 runterfahren kann.
Ist das HMCCU dafür "zu mächtig"? Gibt es vielleicht eine einfachere Lösung?
Ich möchte die Profis hier nicht stören, aber vielleicht kann mir jemand einen Tipp/Link/HowTo geben wie ich das realisieren kann?
Gruß
Frank
Keine Sorge, Du störst nicht.
Dafür ist HMCCU nicht geeignet. Mit dem Modul kannst Du von FHEM aus die CCU bzw. daran angeschlossene Geräte steuern. Also das genaue Gegenteil von Deiner Anforderung.
Wenn ich das jetzt richtig verstehe, ist die Jalousie kein Homematic Gerät.
Du kannst von der CCU aus FHEM Befehle absetzen. Dazu benötigst Du das Tool "socat" oder "nc" auf der CCU. Die Tools gibt es hier:
http://homematic-forum.de/forum/viewtopic.php?f=26&t=13299
Die Tools kopierst Du auf der CCU z.B. in das Verzeichnis /etc/config/addons/scripts.
Dann legst Du Dir ein Shellscript an, z.B.
#!/bin/sh
FHEM_SERVER="192.168.1.11"
FHEM_PORT=7072
if [ $# -ne 1 ]; then
echo "Usage: fhem.sh Command"
exit 1
fi
echo -e "$1\nquit\n" | /etc/config/addons/scripts/nc $FHEM_SERVER $FHEM_PORT
Wenn Dein Script fhem.sh heißt, kannst Du nun mit folgendem Befehl Deine Jalousie von der CCU aus in FHEM ansprechen:
fhem.sh "set Jalousien_Kueche_klein on"
Die Einbindung von Shellscripts in die CCU Oberfläche (z.B. per CUxD und Virtuellem oder auch echtem Taster) wird an vielen Stellen beschrieben. Das würde jetzt hier zu weit führen. Einfach mal googeln.
Chaka! Es funktioniert tatsächlich! 8)
Vielen Dank für den Tipp!
Wenn das mal jemand nachbauen möchte der genau so wenig Ahnung hat wie ich, dann sollte er darauf achten, den set-Befehl in Hochkomma zu setzen, damit kann man sich ein paar Stunden rumtüffteln ersparen. ;)
dom.GetObject("CUxD.CUX2801001:3.CMD_EXEC").State("/usr/local/addons/scripts/fhem.sh 'set Jalousien_Kueche_klein on'");
Alles in allem genau das was mir noch fehlte, vielen Dank noch mal!
Gruß
Frank
Hallo Zap,
ich bin gerade mal wieder bei meinen Eltern und habe es gewagt dein Modul zu updaten. Und es läuft wunderbar - sogar noch schneller als vorher.
Wirklich grandiose Arbeit von dir. :)
Da alles so gut läuft, wollte ich nun auch versuchen, ein HM Programm einzubinden. Geht das schon und hast du da evtl. ein Beispiel?
Das Programm wurde von meinem Bruder in der CCU aufgebaut. Ich sehe nur so viel wie auf dem Bild.
Zum Hintergrund: Das Programm schaltet eine Wasserpumpe und Bewässerungsanlagen an.
Viele Grüße
Thomas
Die Programme findest Du in der CCU unter "Programme und Verknüpfungen" / "Programme und Zentraleverknüpfungen"
Wenn dann Dein Programm z.B. "SicherheitsCheck" heißt und dein CCU Device in FHEM "d_ccu" kannst Du das Programm wie folgt ausführen:
set d_ccu execute SicherheitsCheck
In Deinem Fall scheint es so zu sein, dass das Programm mit einer virtuellen CCU Taste verknüpft wurde. Grundsätzlich müsste es auch möglich sein, von FHEM aus diese virtuellen Tasten anzusprechen. Das habe ich aber noch nicht getestet. Werde ich bei Gelegenheit mal versuchen. Aber die erste Variante oben sollte funktionieren.
Das "HM-RCV-50 BidCoS-RF:34" ist ein Kanal für einen virtuellen Taster der CCU. Davon gibt es m.W. 50 Stück. Du kannst versuchen, diesen Kanal mal mit HMCCUCHN in FHEM nutzbar zu machen. Dazu musst Du aber den Kanal umbenennen (wegen Leerzeichen im Namen) oder die Kanaladresse verwenden. Ich befürchte aber, dass das nicht funktioniert, da diese virtuellen Taster ein anderes Adressierungsschema haben (BidCoS-RF:Kanalnummer). Dieses Schema wird derzeit von HMCCU nicht unterstützt.
Hi zap, vielen Dank!
Und wie ist es, wenn der Programm-Name Leerzeichen enthält?
Viele Grüße
Thomas
Zitat von: ToM_ToM am 20 Juni 2016, 09:21:48
Und wie ist es, wenn der Programm-Name Leerzeichen enthält?
Das wird nicht funktionieren. Hintergrund: FHEM hat ein grundsätzliches Problem mit Leerzeichen in Parametern. Bei einem Befehl wie
set d_ccu execute Mein Programm
bekommt ein Modul von FHEM 2 Parameter "Mein" und "Programm" übergeben.
Leider unterstützt FHEM auch keine Parameter in Hochkomma wie z.B.
set d_ccu execute "Mein Programm"
Bei CCU Programmen bleibt also nur der Verzicht auf Leerzeichen im Namen.
BTW: Nutzt Du eigentlich den internen RPC-Server (ccuflags = intrpc) oder nach wie vor ccurpcd.pl ? (ich frage, weil ich ccurpcd.pl früher oder später beerdigen möchte, damit HMCCU endlich in das FHEM Update rein kann)
Hi zap,
vielen Dank. Ich habe noch ccurpcd.pl verwendet, aber jetzt gerade umgestellt. Und läuft weiterhin top. :)
Kann ich eig. auf die Systemvariablen irgendwie reagieren? Also sobald sie sich ändern? Dazu müsste ich diese ja irgendwie in den Readings hinein bekommen.
Mir ist auch noch was bei einem Sensor aufgefallen. Der ist als HMCCUCHN angelegt und aktualisiert sich nicht von alleine.
Viele Grüße
Thomas
Variablen werden über das IO Device abgefragt. Beispiel
get d_ccu vars XY.*
Liest alle Variablen, die mit XY beginnen.
Dann noch das Attribut ccureadings auf 1 setzen, damit auch im IO Device Readings angelegt werden und den get vars Befehl per FHEM AT Device regelmäßig ausführen lassen (leider unterstützt die CCU nicht die Aktualisierung von Variablen per RPC-Server).
Dann kanst Du per Notify auf Änderung der Readings reagieren.
Für den Sensor, dessen Werte nicht aktualisiert werden: Schick mal bitte die Ausgabe von "list <devname>"
Hi zap,
ich nutze auch Dein Modul und bin ganz happy, dass es gut funktioniert. 3 Fragen habe ich, zu denen ich Rat suche:
- Mir fällt auf, dass der RPCServer (ich nutze den internen) regelmässig stoppt, wobei das entsprechende Reading "rpcserver" nicht aktualisiert wird, wohl aber der Eintrag in den Internals "RPCServer". State wird dabei auf "Initialized" gesetzt. Ist das ein bekanntes Phänomen? Ich hab mir so geholfen, dass ich ein notify drauf setze und den RPCServer neu starte - dann geht wieder alles für eine Weile.
- Die Readings der eingelesenen Geräte sind sehr lang. Bei einem Device-Name "Garten.Bewegung" (und einem Channel-1-Namen "Garten-Bewegung.1" bekomme ich z.B. das Reading "Garten.Bewegung.1.BRIGHTNESS" - handlicher wäre, wenn man nur "BRIGHTNESS" bekommen würde. Ist sowas machbar?
- Der Status wird bei einigen Geräten nicht gesetzt, sondern lautet dann meist "Initialized". Bei 2 Temperatursensoren würde ich gerne im Status via einer dewpoint-Definition T: H: D: mit zugehörigen Angaben haben. Bei Bewegungsmeldern würde ich gerne motion/noMotion im Status ablesen, so wie das beim HM-CFG-LAN Adapter funktioniert hat. Gibt es dazu Möglichkeiten?
VG Yil
Zitat von: Yil am 21 Juni 2016, 15:28:01
Mir fällt auf, dass der RPCServer (ich nutze den internen) regelmässig stoppt, wobei das entsprechende Reading "rpcserver" nicht aktualisiert wird, wohl aber der Eintrag in den Internals "RPCServer".
Den Effekt hatte bisher noch niemand. Entweder der RPC-Server bleibt gleich nach dem Start stehen oder er läuft stabil. Hast Du irgendwelche Fehlermeldungen ("HMCCU:") im FHEM Logfile ?
Zitat
Die Readings der eingelesenen Geräte sind sehr lang. Bei einem Device-Name "Garten.Bewegung" (und einem Channel-1-Namen "Garten-Bewegung.1" bekomme ich z.B. das Reading "Garten.Bewegung.1.BRIGHTNESS" - handlicher wäre, wenn man nur "BRIGHTNESS" bekommen würde. Ist sowas machbar?
Für Devices vom Type HMCCUCHN (einzelne Kanäle) geht das schon mit dem Attribute ccureadingformat=name. Für die HMCCUDEV Devices wird es ab der nächsten Version gehen.
Zitat
Der Status wird bei einigen Geräten nicht gesetzt, sondern lautet dann meist "Initialized". Bei 2 Temperatursensoren würde ich gerne im Status via einer dewpoint-Definition T: H: D: mit zugehörigen Angaben haben. Bei Bewegungsmeldern würde ich gerne motion/noMotion im Status ablesen, so wie das beim HM-CFG-LAN Adapter funktioniert hat. Gibt es dazu Möglichkeiten?
Wenn STATE gesetzt werden soll, musst Du mit den Attributen statechannel und statedatapoint den Kanal und den Datenpunkt festlegen, der in STATE übernommen werden soll. Wenn z.B. der Datenpunkt TEMPERATURE im Kanal 2 liegt und nach STATE soll, sieht das so aus:
attr devname statechannel 2
attr devname statedatapoint TEMPERATURE
Oder kürzer:
attr devname statedatapoint 2.TEMPERATURE
Wenn Du mehrere Werte in STATE haben möchtest, nimmst Du das FHEM Standardattribut stateFormat. Z.B.
attr devname stateFormat T: KL-BO-TH.1.TEMPERATURE° H: KL-BO-TH.1.HUMIDITY% D: KL-BO-TH.2.SET_TEMPERATURE° P: DEWPOINT°
Das Reading DEWPOINT ist ein userreading:
attr devname userReadings DEWPOINT {HMCCU_Dewpoint($name,"KL-BO-TH.1.TEMPERATURE", "KL-BO-TH.1.HUMIDITY","n/a")}
In den Beispielen musst Du eigentlich nur die Namen der Kanäle und Datenpunkte durch Deine ersetzen. Dann sollte es funktionieren.
Wenn Deine Bewegungsmelder nicht "motion/nomotion" in einem Datenpunkt liefern sonder true/false oder 1/0 kannst Du diese Werte mit dem Attribut substitute konvertieren lassen bevor sie in STATE geschrieben werden:
attr devname substitute (true|1):motion,(false|0):nomotion
Oder bechränkt auf einen bestimmten Datenpunkt MOTION
attr devname substitute MOTION!(true|1):motion,(false|0):nomotion
Sehr cool - danke für die Hilfe. Funktioniert alles sauber bei mir bis auf das userreading DEWPOINT. Den Kanalnamen habe ich durch meinen ersetzt, aber er zeigt es leider nicht an.
Ist nur ne Kleinigkeit, aber wie kann ich im reading stateFormat aus "19.300000°" 19,3° machen? Ich hab mit sprintf herumprobiert, bin aber nicht drauf gekommen.
Zum RPC-Server habe ich (immer mal wieder) folgendes im Log (verbose 5):
2016.06.21 15:02:49 1: HMCCU: Deregistering RPC server http://192.168.1.100:7401/fh2001 at http://192.168.1.15:2001/
2016.06.21 15:02:49 0: HMCCU: Stopping RPC server CB2001 with PID 13963
2016.06.21 15:02:49 0: CCURPC: CB2001 Server loop terminated
2016.06.21 15:02:49 2: CCURPC: Eventcount DD = 0
2016.06.21 15:02:49 2: CCURPC: Eventcount EV = 1
2016.06.21 15:02:49 2: CCURPC: Eventcount EX = 1
2016.06.21 15:02:49 2: CCURPC: Eventcount IN = 1
2016.06.21 15:02:49 2: CCURPC: Eventcount ND = 152
2016.06.21 15:02:49 2: CCURPC: Eventcount RA = 0
2016.06.21 15:02:49 2: CCURPC: Eventcount RD = 0
2016.06.21 15:02:49 2: CCURPC: Eventcount SL = 1
2016.06.21 15:02:49 2: CCURPC: Eventcount UD = 0
2016.06.21 15:02:49 2: CCURPC: Eventcount total = 156
2016.06.21 15:02:49 2: CCURPC: Eventcount writeerror = 0
2016.06.21 15:02:51 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2016.06.21 15:02:51 0: HMCCU: RPC server(s) with PID(s) 13963 shut down. f=1
2016.06.21 15:02:51 2: HMCCU: Eventcount DD = 0
2016.06.21 15:02:51 2: HMCCU: Eventcount EV = 1
2016.06.21 15:02:51 2: HMCCU: Eventcount EX = 1
2016.06.21 15:02:51 2: HMCCU: Eventcount IN = 1
2016.06.21 15:02:51 2: HMCCU: Eventcount ND = 152
2016.06.21 15:02:51 2: HMCCU: Eventcount RA = 0
2016.06.21 15:02:51 2: HMCCU: Eventcount RD = 0
2016.06.21 15:02:51 2: HMCCU: Eventcount SL = 1
2016.06.21 15:02:51 2: HMCCU: Eventcount ST = 0
2016.06.21 15:02:51 2: HMCCU: Eventcount UD = 0
2016.06.21 15:02:51 2: HMCCU: Eventcount total = 156
2016.06.21 15:02:51 0: HMCCU: Periodical check found no RPC Servers
2016.06.21 15:02:51 0: HMCCU: All RPC servers stopped
Was auffällt ist, dass der RPCServer jedesmal aussteigt, wenn ich die fhem.cfg editiere.
Auf die nächste Version freue ich mich schon ;D
Zitat von: Yil am 21 Juni 2016, 23:37:17
Ist nur ne Kleinigkeit, aber wie kann ich im reading stateFormat aus "19.300000°" 19,3° machen? Ich hab mit sprintf herumprobiert, bin aber nicht drauf gekommen.
Das Attribut stripnumber ist Dein Freund. Hier kannst Du folgende Werte angeben:
0 = Alle Nachkommastellen
1 = Eine Nachkommastelle
2 = Keine Nachkommastelle
Beim userreading für den DEWPOINT musst Du die Readings angeben, nicht die Kanalnamen. Sorry, hatte ich falsch beschrieben.
Zitat
Was auffällt ist, dass der RPCServer jedesmal aussteigt, wenn ich die fhem.cfg editiere.
Die Logfile Einträge weisen nicht auf einen Fehler hin. Sieht aus als würde der RPC-Server normal gestoppt werden. Wenn Du das cfg File editierst, wirst Du vermutlich FHEM neu starten oder? Beim Shutdown von FHEM wird der RPC-Server natürlich auch gestoppt. Wenn dann beim Starten nicht das Attribut rpcserver = on ist, wird er auch nicht automatisch gestartet.
Hi zap,
ich hatte gehofft, ich könnte das mit dem at umgehen. ;)
Zu meinem Problem mit dem Sensor: Ich bin leider wieder abgereist und kann diese Info jetzt nicht mehr nachliefern.
Am gleichen Abend hatte ich aber auch noch festgestellt dass FHEM auch nicht mehr die Info über "Fenster auf/zu" automatisch bekommt.
Daraufhin hatte ich dann alles nochmal neu gestartet und dann ging es. Evtl. ist das Problem mit dem Sensor damit auch behoben. Dies hatte ich aber nicht mehr geprüft.
Viele Grüße
Thomas
ZitatDie Logfile Einträge weisen nicht auf einen Fehler hin. Sieht aus als würde der RPC-Server normal gestoppt werden. Wenn Du das cfg File editierst, wirst Du vermutlich FHEM neu starten oder? Beim Shutdown von FHEM wird der RPC-Server natürlich auch gestoppt. Wenn dann beim Starten nicht das Attribut rpcserver = on ist, wird er auch nicht automatisch gestartet.
Folgendes konnte ich nachstellen:
- Sobald ich die fhem.cfg öffne und anschließend speichere, wird der RPCServer beendet. Typischerweise starte ich dann FHEM nicht neu, so dass es auch zu keinem Shutdown kommt. Das Atrtribut rpcserver on ist gesetzt.
- Folgende Werte ergeben sich: Interner Wert RPCPID: <nicht mehr vorhanden>; interner Wert RPCPRC: <nicht mehr vorhanden>; interner Wert RPCState = stopped; internern Wert STATE = Initialized; reading rpcstate = running (und nicht: stopped); reading state = Initialized (der RPCServer verliert also die internen Werte RPCPID und RPCPRC)
- Der Befehl set HMCCU2 rpcserver on führt in den normalen Zustand zurück
Wenn ich hingegen den RPCServer manuell stoppe, dann lauten die internen Werte anders:
Interner Wert RPCPID: 0; interner Wert RPCPRC: none; interner Wert RPCState = stopped; internern Wert STATE = busy; reading rpcstate = running; reading state = busy
Ich hab mal 2 Screenshots angehängt. Dieses Verhalten ist beliebig oft reproduzierbar. Hilft das weiter bei der Fehlersuche?
Hört sich fast so an als würde das Modul neu geladen werden wenn die cfg gespeichert wird. Muss ich bei mir mal ausprobieren. Vielleicht weiss ja jemand, ob das ein Feature von FHEM ist.
Hi,
ich habe da mal ein Problem, wo ich nicht weiß, ob ich mich einfach nur zu dämlich anstelle:
Ich benutze einen Homematic Dimmer und zwei Aufputz-Rolladenaktoren.
Die Readings, die da kommen (z.B. 1.LEVEL) sind immer Real-Zahlen: also von 0.000000 bis 1.000000.
Nun ist es so, dass Steuerelemente, wie knob gerne mit den Prozenten arbeiten würden: also 0 - 100.
Das kann man wiederum ganz gut parametrieren, indem man min, max und step-Werte angibt.
Allerdings führt das immer wieder zu Klimmzügen.
Bei der Siri-Anbindung über Homebridge bin ich nun leider vollends gescheitert, weil die intern CurrentPosition und TargetPosition als Integers fahren. Also nur 0-100 möglich ist. Oder auch 0 und 1. Also Markise auf oder zu. Was auch nicht im Sinne des Erfinders ist. :D
Ich habe nirgends gesehen, dass das Problem sonst einer hätte.
Mach ich ggf. irgendwas falsch, dass bei mir 0.00 bis 1.00 verwendet wird, statt 0-100 Prozent?
Schlau wäre tatsächlich, wenn man Dimmer und Rolladenaktoren mit Prozentwerten ansteuern könnte und die Readings (1.LEVEL) auch Prozentwerte (also 0-100) zurück liefern würden.
Hoffe auf Hilfe.
VG Alex
Ich verstehe Dein Problem, habe allerdings derzeit keine Lösung dafür. HMCCU reicht momentan numerische Werte der Datenpunkte 1:1 an die Readings weiter (ok, bei Bedarf kann man die Nachkommastellen abschneiden lassen).
Da müsste ich was implementieren, so eine Art "scale" Attribut, das in beide Richtungen (Get/Set) arbeitet. Ich schreibe es auf die Liste.
Wenn es nur um die Darstellung in den Readings ginge, könntest Du einfach ein Userreading definieren, das den Wert eines Datenpunktes mit 100 multipliziert. Das hilft aber nicht beim Setzen der Werte.
Ich könnte mir in der nächsten Version folgendes vorstellen:
attr <dev> scale 1.LEVEL:100,1.TEMPERATURE:10
Das geht über eventMap. Sowohl hin als auch zurück.
Zitat von: Ralli am 22 Juni 2016, 18:56:13
Das geht über eventMap. Sowohl hin als auch zurück.
Und wie?
https://forum.fhem.de/index.php/topic,43023.msg350289.html#msg350289
Hi Ralli,
ich hatte auch daran gedacht, wollte es aber nicht vorschlagen, weil es schon irgendwie hässlich ist ;-)
Aber ok, als Workaround funktioniert es bis ich eine etwas elegantere Lösung in HMCCU eingebaut habe.
Das ist jetzt bestimmt eine dumme Frage, aber hat jemand mal ein komplettes define-Statement für einen Dimmer mit dem Modul HMCCU? Meiner will nicht ... :o
VG Yil
Ich glaube ein Dimmer wurde irgendwo in diesem Thread schon mal behandelt. Langsam wird der Beitrag hier auch etwas unübersichtlich.
Jedenfalls hier erst mal die Erklärung für das Stoppen des RPC Servers beim Editieren der fhem.cfg
https://forum.fhem.de/index.php/topic,54890.0.html
Was will denn nicht beim Dimmer? Poste doch mal ein list Devname , wenn zumindest der Define klappt. Auch ein " get devname deviceinfo " ist manchmal aufschlussreich
Hi zap,
danke für's Recherchieren - jetzt ist's mir klar, warum das so dermaßen deutlich zu reproduzieren war. Ich weiß, dass es viele unverständige Blicke gibt, wenn man preisgibt, dass man die fhem.cfg von Hand editiert. Schlechte Angewohnheit, die jedoch viel Flexibilität beinhaltet. Ich versuche "umzulernen" ;)
Dimmer mache ich in einem separaten Post. Ggf. könnte man aber Geräte, die als HMCCUDEV definiert werden, auch hier behandeln: https://forum.fhem.de/index.php/topic,51339.0.html - was meinst Du?
Meiner Meinung nach ist das HMCCU-Modul eines der ganz wichtigen Module der Zukunft in Sachen Homematic, wenn der klassische und weit verbreitete HMLAN ausstirbt (was zwangsläufig der Fall sein wird, nachdem die Produktion eingestellt und das Gerät "end-of-life" ist (alles sehr aktuell lt. Hersteller EQ3). Hier lohnt es sich früh, Knowhow aufzubauen und breit zu streuen. An der Stelle ein Danke, dass Du Dich darum kümmerst!
VG Yil
Was daran verwerflich sein soll, die fhem.cfg von Hand zu editieren (wenn man weiß, was man tut und auch ein Backup hat), weiß ich nicht.
Ich mache das auch oft. Vor allem, wenn ich ein neues Gerät in Betrieb nehme und dafür ein vorhandenes einfach klonen kann. ;)
Dimmer: Ich poste mal mein Beispiel in den von Yil angegebenen anderen Thread. :)
Skalierung der Prozentwerte: Da gibt es jetzt eine Lösung für die homebridge, das die 0..1 Werte auf 0..100 aufbläst und umgekehrt wieder die Luft rauslässt. (Ich poste das in dem Dimmerbeispiel gleich mit.)
Wäre dennoch schön, wenn man das auch in HMCCUDEV/HMCCUCHN machen könnte. :)
Hi aski71, danke für Deine moralische Unterstützung. Ich habe von einigen sehr erfahrenen fhem-Anwendern fast schon böse und abfällige Kommentare geerntet, als ich mich als fhem-Editor geoutet habe. Ich bin so "aufgewachsen", einen ordentlich lesbaren und strukturierten Code zu haben und es seit vielen Jahren gewohnt, direkt im Code zu arbeiten.
Vorteil, wenn man das NICHT tut, ist wohl, dass die Änderungen sofort greifen, denn beim Speichern der fhem.cfg wird ein rereadcfg ausgelöst, dass temporäre Verbindungen kappt (hat zap für mich recherchiert). Im Ergebnis verliere ich z.B. immer die Verbindung zur HMCCU und muss diese neu starten (RPCServer). Ein anderer Vorteil ist, dass auch Änderung in aus der fhem.cfg ausgelagerten Dateien, die dann über include eingebunden werden, sofort greifen. Ändert man diese include-Datein manuell, muss fhem komplett neu gestartet werden.
Dimmer-Beispiel: sehr cool, vielen Dank.
Ich könnte außerdem noch Hilfe bei der Definition der 3 Rauchmelder und des TeamLeaders gebrauchen, denn diese Geräte hängen bei mir noch am (mittlerweile außer Betrieb genommenen, da defekten) HMLAN-Adapter und müssen ebenfalls auf die neue HMCCU umgebaut werden. Aber dazu melde ich mich im anderen Post separat.
VG Yil
Ja, das ist mir auch schon aufgefallen mit dem PRCServer. Aber wenn man das weiß ist es ja kein Beinbruch. Muss man halt einen "set ccu2 rpcserver on" nach dem Speichern und neu laden hinterher schicken und alles ist gut.
Prima, wenn das Dimmer-Beispiel hilft. Bei Rauchmeldern und TeamLeader (was ist letzteres überhaupt :D ) kann ich leider nicht weiter helfen. Hab noch keine Rauchmelder... :o In Bayern erst Nachrüstepflicht bis Anfang 2018. ;D
VG Alex
Tja, in Sachen Rauchmeldern hat BW da die Nase vorn ;)
Bei Rauchmeldern kocht eQ3 leider wieder ein separates Süppchen. Eine Rauchmeldergruppe hat nichts mit einer normalen CCU Devicegruppe zu tun. Ein Rauchmelder ist der Master. So eine Gruppe hat ein Sternchen am Ende der Adresse.
ich würde für die Gruppe einfach mal ein Device anlegen und schauen, was man damit anfangen kann. Auch hier einfach mal get deviceinfo benutzen.
Kann das leider nicht testen, da ich meine HM Rauchmelder nach diversen Fehlalarmen entsorgt und durch Gira Melder mit HomeMatic Schliesserkontakt ersetzt habe. Ok, war scheiss teuer, aber die Nachtruhe war es mir wert
Ist zwar jetzt ein wenig off topic, aber: Welche Hm-Rauchmelder hattest Du?
Die aktuellen 10-Jahres-Dinger im 3er Pack?
Oder ältere?
Hab das mit den Fehlalarmen schin öfter gehört....
ich hatte die älteren. Für die neuen liegen mir bzgl. Fehlalarme noch keine Infos vor.
Bei den älteren gabe es 1-2 lange Threads im Homematic Forum.
An sich ist die Gruppen-Funktion ja eine schöne Sache. Allerdings nicht, wenn man ständig Fehlalarme hat und dann im ganzen Haus die Dinger angehen. Einen habe ich dann mal nachts in den Garten gefeuert und die anderen am nächsten Tag abgebaut.
Ich kenne allerdings auch Leute, die mit den alten nie Fehlalarme hatten. Mir scheint, da war die Serienstreuung enorm. Und ja, ich habe alle EQ3 Anweisungen befolgt (regelmäßig Kalibrieren usw.).
Danke für die Info.
Da ich immer wieder Nachfragen dazu erhalte, hier mal die HMCCU Roadmap für die nächsten 1-2 Versionen:
- Integration in den FHEM SVN Hauptzweig (standard update Funktion)
- Verkürzte Reading-Names auch bei HMCCUDEV Devices
- Skalierung von Reading-Werten
- Unterstützung von RAMP_TIME bei set Befehlen (sofern das Device das unterstützt)
- Unterstützung von virtuellen Tasten der CCU (50 Kanäle)
- CCU Heartbeat Mechanismus
Das sind die Dinge, an denen ich gerade aktiv arbeite.
Danke für die Roadmap - da ist einiges drin, auf was ich mich freue.
Aber eine andere Frage in dem Zusammenhang: wozu sind denn die HMCCUCHN gut - sprich in welchem Fall würde ich denn einen Device auf einen einzelnen Kanal definieren?
Stichwort Homematic Rauchmelder: ich habe bisher viel von Fehlalarmen gehört und jetzt von Dir auch, aber ich selbst hatte im letzten halben Jahr keinen einzigen (solange sind die Dinger im Einsatz). Gekauft habe ich noch die ältere Version: http://www.elv.de/homematic-vds-funk-rauchmelder-bidcos.html
Beim Pairing in der Homematic Zentrale habe ich jeden Rauchmelder einzeln angemeldet. Dabei hat jeder Rauchmelder auch automatisch seine eigene Gruppe angelegt, die sich nicht mehr löschen lässt - weiß jemand, warum?
Müsste ich nicht so weiter machen, dass ich in der Homematic Zentrale eine Gruppe anlege, in die ich alle Rauchmelder übernehme (so habe ich das bei dem HMLAN-Adapter machen müssen). Oder muss ich die Rauchmelder direkt miteinander peeren?
Bitte da mal um Info, damit ich nicht schon vor der Übernahme in FHEM Rauchmelder-Chaos anrichte :o
Und klar- ich teste gerne alles aus, was zu dem Thema hier empfohlen wird!
Nach etwas Suchen habe ich folgende Anleitung gefunden, die helfen mag: http://files.elv.de/Assets/Produkte/7/766/76676/Downloads/76676_vernetzung_um.pdf - mit dem abschließenden Test hat man die Gewissheit, sie ordentlich angelernt und vernetzt zu haben.
Anbei die Info aus
get HMCCU2 deviceinfo RauchmelderTeam
in der Anlage. Gibt ja nicht wirklich viel her ...
Und nun die Einbindung in HMCCU ... ::)
Wenn Deine Rauchmelder keine Fehlalarme verursachen ist ja alles in Ordnung. Meine sind auch schon 2 Jahre alt und hatten am Ende beinahe täglich einen Fehlalarm.
Bei den Datenpunkten der Rauchmeldergruppe ist wohl nur STATE sinnvoll. Ich vermute, das geht auf true, wenn einer der Melder in der Gruppe auslöst. Insofern empfehle ich Dir, noch je ein Device in FHEM für jeden einzelnen Melder zu definieren. Dann kannst Du auch erkennen, welcher Melder ausgelöst hat.
Laut EQ-3 Doku hat ein RM vom Typ HM-Sec-SD-2 im Kanal 1 folgende Datenpunkte:
ERROR_ALARM_TEST
ERROR_SMOKE_CHAMBER
STATE
LOWBAT
INSTALL_TEST
Da alle in einem Kanal liegen, bietet es sich an, dafür HMCCUCHN zu verwenden. Das hat einige Vorteile, da HMCCUCHN jetzt schon Readings unterstützt, die nur aus dem Datenpunktnamen bestehen. Außerdem unterstützt HMCCUCHN read only Devices, d.h. ohne Set Befehl (was in diesem Fall oder auch bei Fenstersensoren Sinn macht, da diese Geräte keine Schreibzugriffe zulassen).
z.B.
define myRM HMCCUCHN ccu-channel-name-or-address readonly
attr myRM ccureadingfilter (LOWBAT|STATE)
attr myRM substitute STATE!(true|0):alarm,(false|0):kein_alarm;LOWBAT!(true|1):yes,(false|0):no
attr myRM ccureadingformat datapoint
Aber Achtung! Für das Gruppendevice immer HMCCUDEV verwenden, da bis jetzt nur dieses die *Adresse unterstützt.
Grundsätzlich fügt die CCU2 bei jedem Device einen künstlichen Kanal 0 hinzu, in dem solche Datenpunkte wie UNREACH oder RSSI bereitgestellt werden. Wenn Dich die interessieren, musst Du natürlich immer HMCCUDEV verwenden.
Danke, das werde ich heute ausprobieren. Bleibt für mich noich eine Frage offen: wie kann ich den TeamMelder aktiv anstoßen - also Befehle wie TeamCall, alarmOn (brauche ich für die Alarmanlage) und alarmOff (muss ja auch wieder aussschalten).
Hast Du da eine Idee? Definiert hab ich den TeamMelder so:
define RauchmelderTeam HMCCUDEV *MEQ0258600 1
attr RauchmelderTeam IODev HMCCU2
attr RauchmelderTeam ccureadingfilter (STATE)
attr RauchmelderTeam devStateIcon off:general_aus smoke-Alarm.*:secur_alarm@red
attr RauchmelderTeam devStateStyle style="text-align:right;;"
attr RauchmelderTeam event-on-change-reading .*
attr RauchmelderTeam eventMap /teamCall:Teamruf/ /alarmOn:Alarm an/ /alarmOff:Alarm aus/
attr RauchmelderTeam group Rauchmelder
attr RauchmelderTeam icon secur_smoke_detector
attr RauchmelderTeam room Device,Zentral
attr RauchmelderTeam statechannel 1
attr RauchmelderTeam statevals alarmOn:true,alarmOff:false
attr RauchmelderTeam substitute STATE!true:alarmOn,false:alarmOff,1:alarmOn,0:alarmOff
Leider funktionieren die Befehle so nicht, die Rauchmelder reagieren nicht darauf (wobei die Einrichtung lt. Abschlußtest ok ist).
Zitat von: Yil am 24 Juni 2016, 09:07:24
Danke, das werde ich heute ausprobieren. Bleibt für mich noich eine Frage offen: wie kann ich den TeamMelder aktiv anstoßen - also Befehle wie TeamCall, alarmOn (brauche ich für die Alarmanlage) und alarmOff (muss ja auch wieder aussschalten).
Gar nicht. Das sehen sowohl die XML-RPC-Schnittstellen als auch die Logikschicht der CCU nicht vor.
Echt? Ich kann den Alarm der RM nicht selbst aktiv auslösen? Dann kann ich die RM ja gar nicht in die Signalisierung meiner Alarmanlage einbinden. Beim HMLAN-Adapter ging das.
@zap: könntest Du das Thema auch mit auf die Roadmap nehmen? Sonst müsste ich mir noch eine Alarmsirene besorgen.
Das kann zap nicht auf die Roadmap nehmen.
Vollständig lesen:
Zitat
Das sehen sowohl die XML-RPC-Schnittstellen als auch die Logikschicht der CCU nicht vor.
@Ralli: Hast Du auch eine Erklärung, warum es mit dem HMLAN-Adapter (HM-CFG-LAN) ging?
Weil da fhem mit dem Modul CUL_HM als Zentrale fungiert und unmittelbar auf unterster Ebene mit den Sensoren und Aktoren kommunizieren kann - also BidCoS spricht.
Das Modul HMCCU kann und macht das nicht, es ist dazu da, eine bestehende CCU mit den von ihr zur Verfügung gestellten Methoden "fernzubedienen".
Da solltest Du aber eigentlich selbst drauf kommen, wenn Du Dich mit den Modulen richtig auseinander gesetzt hast.
Workaround 1:
Nimm dies: http://www.elv.de/homematic-komplettbausatz-innensirene-als-mini-alarmanlage.html
Hat den Vorteil, dass es im Alarmfall weniger Funkverkehr gibt, da nicht alle RM wild durch die Gegend funken.
Workaround 2:
http://www.elv.de/homematic-schaltaktor-fuer-batteriebetrieb-komplettbausatz.html
Das Relais kannst Du an die Drahtanbindung eines RM anschließen. 2.5 Sekunden für Alarm ein- und 6.5 für Alarm ausschalten.
Als Ergänzung: hier eine kleine Bastelanleitung für das manuelle Auslösen eines Rauchmelders:
http://homematic-forum.de/forum/viewtopic.php?f=31&t=9263
Grundsätzlich sollte man mit solchen Basteleien an Rauchmeldern vorsichtig sein. Bei Fehlern besteht die Gefahr, dass der Melder im Ernstfall nicht mehr auslöst.
Meine Empfehlung wäre daher eine Sirene für die Alarmanlage zu verwenden.
Danke für Eure Rückmeldungen - die Idee mit der Sirene war mein Plan B ;)
Dimmer und Tablet UI:
Ich habe einen LED-Dimmer definiert und möchte diesen über Tablet UI mit einem Dimmer Widget steuern. Das scheitert aber momentan.
So ist der Dimmer in FHEM definiert:
define Keller_LED_Bar HMCCUDEV Keller-LED-Bar 1
attr Keller_LED_Bar IODev myHomematicCCU
attr Keller_LED_Bar controldatapoint 1.LEVEL
attr Keller_LED_Bar event-on-change-reading .*
attr Keller_LED_Bar group BeachBar
attr Keller_LED_Bar icon light_led_stripe
attr Keller_LED_Bar room 04_Keller
attr Keller_LED_Bar statechannel 1
attr Keller_LED_Bar statedatapoint 1.LEVEL
attr Keller_LED_Bar statevals on:1.0,off:0.0
attr Keller_LED_Bar stripnumber 1
attr Keller_LED_Bar substitute 1.0:on,0.0:off,1:on,0:off
attr Keller_LED_Bar webCmd control
attr Keller_LED_Bar widgetOverride control:slider,0,0.1,1,1
Und so das Widget in Tablet UI:
<div data-type="dimmer" data-device="Keller_LED_Bar"
data-set="control" data-min="0" data-max="1" data-off="0" data-on="1" class="cell"></div>
Da die Werte vom LED-Dimmer zwischen 0 und 1 liegen, kann ich mit dem Widget nicht "dimmen", da es keine Zwischenwerte gibt. data-step="0.1" wird vom widget nicht unterstützt. data-step kann nur ganzzahlige Werte. Die Werte von "control" sollten dann zwischen 0 und 100 liegen. Wie krieg ich das zusammen?
In der nächsten Version von HMCCU wird es ein Attribut zum Skalieren von Werten geben.
Einige TabletUI Widgets unterstützen steps < 1, aber eben nicht alle. Bei Widgets, die von knob abgeleitet sind geht es.
Momentan kannst Du das nur über ein anderes Widget lösen.
Die neue Version von HMCCU sollte Ende nächster Woche fertig sein. Wollte zwar noch ein paar Dinge einbauen und insbesondere die Integration in den FHEM Update Zweig machen, aber das kann ich auch verschieben.
Hallo zap,
ich habe gerade meine FHEM Installation aufgeräumt und dann alles neu installiert. Leider funktioniert HMCCU jetzt nicht mehr so wie es soll.
Im Log erscheint immer folgendes:
2016.07.22 20:08:00 1: HMCCU: 500 Can't connect to 192.168.178.101:8181
Das merkwürdige ist, wenn ich die ganzen HMCCU Definitionen manuell eingebe, läuft alles bis zum Neustart.
So sieht meine Definition aus:
define d_ccu HMCCU 192.168.178.101
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 rpcinterval 5
attr d_ccu rpcport 2001
attr d_ccu rpcserver on
Wie gesagt, nach einem Neustart des Raspi startet fhem gar nicht mehr und es erscheint die obige Log-Meldung.
Hast Du eine Idee, was da schief läuft? Die IP der CCU ist definitiv richtig.
Grüße
Dominic
ich muss mal ebend nachfragen:
-wenn ich mir eine ccu2 zulege, habe ich einbußen in der bezug auf fhem und hm?
- aktuell fahre ich ein fhem+ hmlan+ hm-cfg-usb+ maxcune im homematic-mode als i.O und alle ist an die vccu gebunden, devices unterinandere verunden um auch ohne fhem schalten zu können
werden meine erwatungen erfüllt werden können:
- alle devices an ccu2 binden und untereinander für direktes schalten
(bei der ccu 1 wäre noch der vorteil des batteriebetriebes den es bei der 2er nicht mehr gibt)
- die io's würde ich an die ccu2 binden (hmlan und hmusb)
- alle devices in fhem auslesbar, schaltbar und zeitnahe statusänderungen
- betrieb ohne fhem möglich (bis auf evtl. in fhem erzeugte operationen natürlich)
- vorteile da man andere nicht fhem entwicklungen parallel nutzen kann (ccu scripte, erweiterungen usw)
- untertsützung von devices die in fhem nicht gehen wie der rgbw controller
danke !
Hallo zap,
ich habe es die halbe nach langt probiert - ich bekomme es einfach nicht mehr hin :-(
Die Meldung
HMCCU: 500 Can't connect to 192.168.178.101:8181
kommt nach jedem Neustart und zwar immer beim define d_ccu HMCCU 192.168.178.101.
Wenn ich das Define Auskommentiere und danach in fhem per Hand in die Kommandozeile eintrage,
dann funktioniert es einwandfrei ...
Hast Du einen Tip für mich?
@Nico,Chris: kann eure Fragen leider erst Montag beantworten, da momentan unterwegs mit sporadischer Internet Verbindung
Vielleicht ist zum Start von fhem das Netzwerk noch nicht fertig.
In /etc/init.d/fhem
die Zeile
# Required-Start: $local_fs $remote_fs
zu
# Required-Start: $local_fs $remote_fs $network
verändern.
Hallo Ralli,
danke - das wars :-)
Vielen vielen Dank.
Zitat von: chris1284 am 22 Juli 2016, 20:38:47
ich muss mal ebend nachfragen:
-wenn ich mir eine ccu2 zulege, habe ich einbußen in der bezug auf fhem und hm?
- aktuell fahre ich ein fhem+ hmlan+ hm-cfg-usb+ maxcune im homematic-mode als i.O und alle ist an die vccu gebunden, devices unterinandere verunden um auch ohne fhem schalten zu können
Wenn Du beides haben möchtest, also CUL_HM und HMCCU: das wurde hier schon mal diskutiert. Ich glaube, Du musst dann sowohl in der CCU2 als auch in FHEM die gleiche HMID verwenden. Das ist aber Theorie. Ich selbst habe das nicht getestet, da ich kein CUL habe.
Zitat
werden meine erwatungen erfüllt werden können:
- alle devices an ccu2 binden und untereinander für direktes schalten
Ja, Geräte, die an der CCU2 angelernt sind, können (sofern sie das unterstützen) direkt miteinander gepairt werden. Dann können Sie auch ohne CCU interagieren.
Zitat
(bei der ccu 1 wäre noch der vorteil des batteriebetriebes den es bei der 2er nicht mehr gibt)
Ich würde die 2er nehmen. Dann hast Du auch gleich Unterstützung für Homematic IP.
Zitat
- die io's würde ich an die ccu2 binden (hmlan und hmusb)
Wie Du das machen willst, ist mir nicht klar. Es funktioniert so: HMCCU ist das IO Device, das die Kommunikation mit der CCU2 erledigt. hmlan und hmusb brauchst Du nicht mehr. Das Anlernen an die CCU2 sowie das Pairen der Geräte untereinander wird alles in der CCU2 erledigt.
Zitat
- alle devices in fhem auslesbar, schaltbar und zeitnahe statusänderungen
- betrieb ohne fhem möglich (bis auf evtl. in fhem erzeugte operationen natürlich)
- vorteile da man andere nicht fhem entwicklungen parallel nutzen kann (ccu scripte, erweiterungen usw)
- untertsützung von devices die in fhem nicht gehen wie der rgbw controller
Mit HMCCU uneingeschränkt ja.
Aber HMCCU ist NICHT kompatibel mit VCCU!!
bezüglich hmlan und hmusb: an die ccu1 konnte man diese als weitere io-devices anbinden um die ccu-reichweite zu erhöhen, ich denke das geht zu mindest mit dem hmlan auch bei der 2er. zur fhemseite hat man dann natürlich nur die ccu2 als io. vccu brauch ich dann net mehr und den cube als 2. hmlan auch nicht da diecu2 einen teil abdecken würde und der hmlan einen anderen. den hm-cfg-usb würd ich in fhem / zum spielen nutzen.
Danke dir!
Hallo zap,
jetzt muss ich doch noch einmal stören :-(
Ich habe im Log folgenden Eintrag wenn ich bei einem Fensterkontakt "get Arbeitszimmer_Fenster update" ausführen:
2016.07.25 20:27:03 1: HMCCUCHN: Arbeitszimmer_Fenster No readable datapoints found
Der Status ist dann "error".
Das merkwürdige ist, dass ein genauso definierter Fensterkontakt mir den korrekten Status liefert.
Ein get Arbeitszimmer_Fenster devstate bringt mir dann den aktuellen Status, aber keine Datenpunkte für LOWBAT und ERROR.
So ist der der TFK definiert:
define Arbeitszimmer_Fenster HMCCUCHN LEQ0501605:1 readonly
attr Arbeitszimmer_Fenster IODev d_ccu
attr Arbeitszimmer_Fenster ccureadingfilter (ERROR|LOWBAT|STATE)
attr Arbeitszimmer_Fenster devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
attr Arbeitszimmer_Fenster event-on-change-reading .*
Hast Du noch einen Tip für mich?
Gruß
Nic
Dass get devstate funktioniert, aber get update nicht ... möglich. Bei get devstate wird einfach dumpf der Datenpunkt STATE abgefragt. Bei get update prüft HMCCU, ob es lesbare Datenpunkte gibt (es gibt tatsächlich Datenpunkte, in die man nur schreiben kann oder die sogar nur Events produzieren).
Jedenfalls müsste get update die 3 Datenpunkte finden. Prüfen kannst Du das, indem Du folgenden Befehl ausführst
get d_ccu deviceinfo LEQ0501605
Das gibt Dir alle Kanäle und Datenpunkte aus inklusive der Flags (bei STATE, ERROR und LOWBAT sollten das [RE] für Read und Event sein.
So und jetzt wird es kompliziert. Schau Dir mal von Deinem Device das Internal ccutype an. Hier findest Du den Gerätetyp (z.B. HM-Sec-SCo). Nun führst Du den Befehl "list d_ccu" aus.
In der folgenden rechte langen Ausgabe suchst Du den oben gefundenen Gerätetyp, also z.B. HM-Sec-SCo. In meinem Fall sieht das wie unten aus. Wichtig ist, dass unter Ch: 1: bei Error, Lowbat und State hinter oper jeweils eine 5 steht.
Hm-sec-sco:
Ch:
0:
Aes_key:
oper 1
type 8
Config_pending:
oper 5
type 2
Device_in_bootloader:
oper 5
type 2
Lowbat:
oper 5
type 2
Rssi_device:
oper 5
type 8
Rssi_peer:
oper 5
type 8
Sticky_unreach:
oper 7
type 2
Unreach:
oper 5
type 2
Update_pending:
oper 5
type 2
1:
Error:
oper 5
type 16
Install_test:
oper 4
type 2
Lowbat:
oper 5
type 2
State:
oper 5
type 2
Falls Du das nicht findest, führe einmal den Befehl "get d_ccu devicelist" aus, um die Geräte neu aus der CCU abzufragen.
Hi,
get device info liefert alle drei Datenpunkte.
list d_ccu liefert:
Hm-sec-sc-2:
Ch:
0:
Aes_key:
oper 1
type 8
Config_pending:
oper 5
type 2
Lowbat:
oper 5
type 2
Rssi_device:
oper 5
type 8
Rssi_peer:
oper 5
type 8
Sticky_unreach:
oper 7
type 2
Unreach:
oper 5
type 2
1:
Error:
oper 5
type 16
Install_test:
oper 4
type 2
Lowbat:
oper 5
type 2
State:
oper 5
type 2
get Arbeitszimmer_Fenster update liefert leider immer noch "no readable datapoints found"
Hast Du mehrere Fensterkontakte und tritt das Problem bei allen auf ?
Hast Du mal ein "get d_ccu devicelist" ausgeführt und danach nochmal das "get xxxx update" versucht ?
Hi, ja habe 10 FensterKontakte 6 gehen, 4 nicht :-(
Get d_ccu devicelist hat zwar rund 280 Kanäle geladen, aber am Verhalten ändert sich leider nichts :-(
Gesendet von meinem GT-I9505 mit Tapatalk
Ok, poste mal bitte ein "list <devname>" von einem Device das geht und von einem das nicht geht. Ausserdem die Definition und die Attribute von einem das geht.
So sieht es bei einem aus, der nicht funktioniert :
Internals:
CHANGED
DEF LEQ1060645:1 readonly
IODev d_ccu
NAME Schlafzimmer_Fenster
NR 68
STATE Error
TYPE HMCCUCHN
ccuaddr LEQ1060645:1
ccudevstate Active
ccuif BidCos-RF
ccuname Fenster Schlafzimmer
ccutype HM-Sec-SC-2
channels 1
statevals readonly
Readings:
2016-07-25 21:01:53 Fenster_Schlafzimmer.STATE 0
2016-07-26 10:09:07 state Error
Attributes:
IODev d_ccu
ccureadingfilter (ERROR|LOWBAT|STATE)
devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
event-on-change-reading .*
substitute STATE!(0|false):0,(1|true):1;LOWBAT!(0|false):0,(1|true):1
Gesendet von meinem GT-I9505 mit Tapatalk
Und so sieht es bei einem aus der funktioniert :
nternals:
DEF LEQ0175072:1 readonly
IODev d_ccu
NAME Kueche_Fenster
NR 29
STATE 0
TYPE HMCCUCHN
ccuaddr LEQ0175072:1
ccudevstate Active
ccuif BidCos-RF
ccuname Fenster_Kueche
ccutype HM-Sec-SC-2
channels 1
statevals readonly
Readings:
2016-07-25 20:35:39 Fenster_Kueche.ERROR 0
2016-07-25 20:35:39 Fenster_Kueche.LOWBAT 0
2016-07-25 20:35:39 Fenster_Kueche.STATE 0
2016-07-25 20:35:39 state 0
Attributes:
IODev d_ccu
ccureadingfilter (ERROR|LOWBAT|STATE)
devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
event-on-change-reading .*
substitute STATE!(0|false):0,(1|true):1;LOWBAT!(0|false):0,(1|true):1
Gesendet von meinem GT-I9505 mit Tapatalk
Und hier noch die Definition des tfk, der funktioniert :
#Fenster
#Kueche
define Kueche_Fenster HMCCUCHN LEQ0175072:1 readonly
attr Kueche_Fenster IODev d_ccu
attr Kueche_Fenster ccureadingfilter (ERROR|LOWBAT|STATE)
attr Kueche_Fenster devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
attr Kueche_Fenster event-on-change-reading .*
attr Kueche_Fenster substitute STATE!(0|false):0,(1|true):1;;LOWBAT!(0|false):0,(1|true):1
Gesendet von meinem GT-I9505 mit Tapatalk
Kann es sein, dass alle TF-Kontakte, bei denen get update nicht funktioniert, ein Leerzeichen im CCU-Namen (Internal ccuname) enthalten ist?
Zumindest ist das der einzige relevante Unterschied, den ich in den 2 Beispielen erkennen kann.
Wenn dem so ist bitte erst mal nichts unternehmen (umbenennen oder so). Vielleicht kann ich das in HMCCU beheben.
Hi, leider nein.
Hier von einem der nicht funktioniert (trotz ohne Leerzeichen ):
Save config
Unsorted
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
Internals:
DEF MEQ0723287:1 readonly
IODev d_ccu
NAME Gaeste_WC_Fenster
NR 48
STATE Error
TYPE HMCCUCHN
ccuaddr MEQ0723287:1
ccudevstate Active
ccuif BidCos-RF
ccuname Fenster_Gaeste_WC
ccutype HM-Sec-SCo
channels 1
statevals readonly
Readings:
2016-07-25 20:47:54 Fenster_Gaeste_WC.ERROR 0
2016-07-25 20:47:54 Fenster_Gaeste_WC.LOWBAT 0
2016-07-25 20:47:54 Fenster_Gaeste_WC.STATE 0
2016-07-26 15:10:46 state Error
Attributes:
IODev d_ccu
ccureadingfilter (ERROR|LOWBAT|STATE)
devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
event-on-change-reading .*
substitute STATE!(0|false):0,(1|true):1;LOWBAT!(0|false):0,(1|true):
Gesendet von meinem GT-I9505 mit Tapatalk
Und hier mit Leerzeichen , wo das update funktioniert :
Internals:
CHANGED
DEF MEQ0723295:1 readonly
IODev d_ccu
NAME WZ_vorn_Fenster
NR 36
STATE 0
TYPE HMCCUCHN
ccuaddr MEQ0723295:1
ccudevstate Active
ccuif BidCos-RF
ccuname Fenster Wohnzimmer vorn
ccutype HM-Sec-SCo
channels 1
statevals readonly
Readings:
2016-07-26 15:14:24 Fenster_Wohnzimmer_vorn.ERROR 0
2016-07-26 15:14:24 Fenster_Wohnzimmer_vorn.LOWBAT 0
2016-07-26 15:14:24 Fenster_Wohnzimmer_vorn.STATE 0
2016-07-26 15:14:24 state 0
Attributes:
IODev d_ccu
ccureadingfilter (ERROR|LOWBAT|STATE)
devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
event-on-change-reading .*
substitute STATE!(0|false):0,(1|true):1;LOWBAT!(0|false):0,(1|true):1
Gesendet von meinem GT-I9505 mit Tapatalk
Versuch mal bitte folgendes:
attr d_ccu ccutrace LEQ0501605
Dann nochmal den Befehl
get Arbeitszimmer_Fenster update
ausführen (Verbose Level muss min. 2 sein).
Dann im FHEM Logfile nachschauen. Es sollte nun 3 Zeilen geben, die so anfangen:
HMCCU: Addr=
HMCCU: Script response =
HMCCU: Script =
Diese Ausgabe hätte ich gerne.
So sieht das dann aus:
2016.07.26 16:35:02 1: in ATTR
2016.07.26 16:35:41 2: HMCCU: Addr=LEQ0501605:1 Name=Fenster Arbeitszimmer
2016.07.26 16:35:41 2: HMCCU: Script response =
0
2016.07.26 16:35:41 2: HMCCU: Script =
string sDPId;
string sChnName = "Fenster Arbeitszimmer";
integer c = 0;
object oChannel = dom.GetObject (sChnName);
if (oChannel) {
foreach(sDPId, oChannel.DPs()) {
object oDP = dom.GetObject(sDPId);
if (oDP) {
if (OPERATION_READ & oDP.Operations()) {
WriteLine (sChnName # "=" # oDP.Name() # "=" # oDP.Value());
c = c+1;
}
}
}
WriteLine (c);
}
2016.07.26 16:35:41 1: HMCCUCHN: Arbeitszimmer_Fenster No readable datapoints found
Gesendet von meinem GT-I9505 mit Tapatalk
Ok, wenn Du in der CCU2 Oberfläche Dir unter Einstellungen->Geräte den Fensterkontakt anschaust, gibt es einmal den Namen des Geräts und einmal den Namen des 1. Kanals. Sind die bei Dir identisch, d.h. heißen beide "Fenster Arbeitszimmer" ?
Ich mach das immer so: das Gerät heißt z.B. Mein_Geraet, die Kanäle dann Mein_Geraet:1, Mein_Geraet:2 usw.
Die Namen müssen jedenfalls unterschiedlich sein (Gerät, Kanäle) sonst greift das Script bei get update auf das falsche Objekt zu. Falls das bei Dir nicht der Fall ist, musst Du entweder den Kanal oder das Gerät in der CCU umbenennen. Danach musst Du in FHEM ein "get d_ccu devicelist" ausführen. Wenn Du den Kanal umbenennst, solltest Du auch das Device neu definieren (per modify), damit die Internals passen.
Hallo zap,
danke - das wars!
In der CCU sollten Namen niemals doppelt vergeben werden, da aus Homematic Script Sicht alles, also auch Räume oder Gewerke, Objekte sind. Wenn dann auf ein Objekt per GetObject() zugegriffen wird, ist es mehr oder weniger Zufall, welches zurück gegeben wird.
ich teste gerade mit der ccu2 in fhem:
ccu
define CCU01 HMCCU 192.168.2.10
attr CCU01 room HMein HM-WDS30-T-O (sensor, nur 1 channel)
soweit so gut.
get deviceliste --> Read 55 devices/channels from CCU
warum wird hier nicht gleich eine funktion angeboten per autocreate alle diese channels /devices erstellen zu lassen (oder gibt es sie und ich habe sie nur nicht gefunden)?
nun gut ein chn selbst ertsellt
define wz_sen_t_aquarium HMCCUCHN wz_sen_t_aquarium:1 readonly
attr wz_sen_t_aquarium IODev CCU01
attr wz_sen_t_aquarium room HMnun die frage: wie sehe ich nun die temp des sensors?
device angesehen -->
get datapoint TEMPERATUREdanach taucht ein für fhem sehr unschön formatiertes reading auf
Zitatwz_sen_t_aquarium.1.TEMPERATURE 22.000000 2016-07-29 07:00:31
auf. Wäre hier nicht eine fhemkomformere formatierung besser
Zitattemprature 22.0 2016-07-29 07:00:31
in fhem sind readings in der regel a) kleingeschrieben und b) ohne devicenamen
ich stelle mir hier gerade die weiterverwendung vor
... notify wz_sen_t_aquarium:wz_sen_t_aquarium.1.TEMPERATURE <div data-type="label" data-device="wz_sen_t_aquarium" data-get="wz_sen_t_aquarium.1.TEMPERATURE" data-unit="%B0C%0A" class="cell big"></div>recht viel unnötiger, übersichtlicher text und nicht überlich wie gesagt.
Fragen:
warum wird das reading / die readings eines devices nach definition nicht selbst geholt?
warum wird bei readingsänderung in der ccu das fhemdevice nicht automatisch aktualisiert? (aktuel bei den hm-modulen bekomt fhem sofort die änderung mit wenn das device sie sendet!)
ich hoffe hier muss ich nicht mit at's arbeiten und mich selbst in fhem um die abholung der daten kümmern....
was ist in eine hmccudev der unterschied zwischen einem control datapoint und einen datapoint
warum wird temp nicht wie gewohnt mi 1 nachkommastelle geliefert? 22.000000 mach irgendwie keinen sinn oder da sich bei dem device (oder auch allen die temp / hum wiedergeben?) eh nur die erste nachkommastelle ändert.
EDIT: bitte nicht als negative kritik auffassen! das sind so sachen die mir auffallen weil ich vorher shcon lange die übliche fhem-hm knfig fahre (sprich die module von martin)
Zitat von: chris1284 am 29 Juli 2016, 07:09:37
warum wird hier nicht gleich eine funktion angeboten per autocreate alle diese channels /devices erstellen zu lassen (oder gibt es sie und ich habe sie nur nicht gefunden)?
Von autocreate habe ich bisher abgesehen, da
- ich beim Start der Modulentwicklung bereits >600 Kanäle in meiner CCU hatte und eine Device-Flut in FHEM vermeiden wollte
- es nicht klar ist, ob ein Benutzer nur einen Kanal eines CCU-Device in FHEM haben möchte (HMCCUCHN) oder mehrere (HMCCUDEV). Jedes Device hat mindestens 2 Kanäle, da die CCU einen Kanal 0 hinzufügt, der solche Datenpunkte wie UNREACH oder RSSI enthält
Für die Zukunft könnte ich mir eine Art gefiltertes Autocreate vorstellen (z.B. für eine bestimmte Devicename-Regexp).
Zitat
danach taucht ein für fhem sehr unschön formatiertes reading auf
Bei HMCCUCHN Devices kannst Du den Readingname auf den Datenpunktnamen beschränken, indem Du das Attribut ccureadingformat auf "datapoint" setzt.
Bei HMCCUDEV geht das (derzeit) nicht, da es Geräte gibt, in denen - in unterschiedlichen Kanälen - Datenpunkte doppelt vorkommen. Ich arbeite an einer Lösung, die in so einem Fall die Readings um die Kanalnummer ergänzt. Dann würde der Gerätename entfallen.
Zitat
warum wird das reading / die readings eines devices nach definition nicht selbst geholt?
warum wird bei readingsänderung in der ccu das fhemdevice nicht automatisch aktualisiert? (aktuel bei den hm-modulen bekomt fhem sofort die änderung mit wenn das device sie sendet!)
Ein wichtiger Teil von HMCCU ist der RPC-Server. Er sorgt dafür, dass bei Änderungen in der CCU diese sofort an FHEM weitergeleitet werden. Du kannst eine Aktualisierung aller lesbaren Datenpunkte mit dem Befehl "get update" erzwingen (im IO Device für alle in FHEM definierten CCU-Geräte oder speziell von einem Client-Device).
Den RPC-Server startest Du wie folgt:
attr <iodev> ccuflags intrpc # Als Vorgriff auf die neue Version, die heute oder morgen kommt und die per Default nicht mehr ccurpcd.pl verwendet.
attr <iodev> rpcserver on # RPC-Server automatisch beim FHEM Start starten
attr <iodev> rpcport 2001 # Liste von Interfaces (2001=BidCosRF, 2010=HM-IP, 9292=Group-Devices)
set iodev rpcserver on # RPC-Server starten
Je nachdem, wieviele Ports im Attribut rpcport angegeben sind, dauert der Start des RPC-Servers einige Sekunden. Irgendwann geht das Internal RPCState des IODevice auf "running" und RPCPID stehen die PIDs der RPC-Server-Prozesse (je Port/Interface einer).
Ach ja: Der RPC-Server (= fhem.pl Prozess) benötigt Schreibrechte in /tmp. Dort werden die Eventqueues angelegt. Mein /tmp auf meinem Raspberry liegt in einer RAM-Disk, um meine SD-Karte zu schonen.
Zitat
was ist in eine hmccudev der unterschied zwischen einem control datapoint und einen datapoint
Beantworte ich später. Muss einen alten Post raussuchen.
Zitat
warum wird temp nicht wie gewohnt mi 1 nachkommastelle geliefert? 22.000000 mach irgendwie keinen sinn oder da sich bei dem device (oder auch allen die temp / hum wiedergeben?) eh nur die erste nachkommastelle ändert.
Die CCU liefert alle Fließkommawerte mit x Nachkommastellen. Mit dem Attribut stripnumber=1 kannst Du das auf 1 Stelle begrenzen (0=keine, 2=alle, oder war es umgekehrt ...?)
Zitat
EDIT: bitte nicht als negative kritik auffassen! das sind so sachen die mir auffallen weil ich vorher shcon lange die übliche fhem-hm knfig fahre (sprich die module von martin)
habe kein Problem mit Kritik ;-)
Vielen Dank für die zusammen- und umfassende Rückmeldung. Hat mir sehr geholfen!
BTW noch 3 Hinweise für den Einstieg:
- Der Befehl get devceinfo (verfügbar in HMCCUDEV und HMCCU) liefert eine Übersicht aller Datenpunkte inkl. Datentyp und Flags für Lesen/Schreiben. Erspart in und wieder den Blick in die EQ3 Doku
- Bei einigen Geräten ist es sinnvoll, das Attribut ccureadingfilter zu setzen um unnötige Readings zu vermeiden (z.B. bei Thermostaten
- Ich empfehle, grundsätzlich event-on-change-reading auf .* zu setzen
wenn ich beim HMCCUCHN device statedatapoint TEMPERATURE setzte und ccureadingformat auf datapoint setze wwird zwar das reading auf TEMPERATURE umgestellt aber der STATE ändersich nicht mehr.
ohne ccureadingformat ändert er sich mit der TEMPERATURE änderung. Bug oder eigenheit des CHN devices?
... da nun alles selbt aktualisiert werde ich auch mal ein thermostat auf die ccu2 umziehen ;)
Könnte ein Bug sein. Schau ich mir an.
ein get deviceinfo auf einen HM-LC-Sw4-Ba-PCB zeigt
Zitat
CHN MEQ0165768:0 az_sw4:0
DPT {b} BidCos-RF.MEQ0165768:0.UNREACH = false [RE]
DPT {b} BidCos-RF.MEQ0165768:0.STICKY_UNREACH = false [RWE]
DPT {b} BidCos-RF.MEQ0165768:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.MEQ0165768:0.LOWBAT = false [RE]
DPT {b} BidCos-RF.MEQ0165768:0.DUTYCYCLE = false [RE]
DPT {8} BidCos-RF.MEQ0165768:0.RSSI_DEVICE = 1 [RE]
DPT {8} BidCos-RF.MEQ0165768:0.RSSI_PEER = 32 [RE]
DPT {b} BidCos-RF.MEQ0165768:0.DEVICE_IN_BOOTLOADER = false [RE]
DPT {b} BidCos-RF.MEQ0165768:0.UPDATE_PENDING = false [RE]
DPT {8} BidCos-RF.MEQ0165768:0.AES_KEY = 0 [R]
CHN MEQ0165768:1 az_sw4:1
DPT {b} BidCos-RF.MEQ0165768:1.STATE = true [RWE]
DPT {f} BidCos-RF.MEQ0165768:1.ON_TIME = [W]
DPT {b} BidCos-RF.MEQ0165768:1.INHIBIT = false [RWE]
DPT {b} BidCos-RF.MEQ0165768:1.INSTALL_TEST = [W]
DPT {b} BidCos-RF.MEQ0165768:1.WORKING = false [RE]
CHN MEQ0165768:2 az_sw4:2
DPT {b} BidCos-RF.MEQ0165768:2.STATE = true [RWE]
DPT {f} BidCos-RF.MEQ0165768:2.ON_TIME = [W]
DPT {b} BidCos-RF.MEQ0165768:2.INHIBIT = false [RWE]
DPT {b} BidCos-RF.MEQ0165768:2.INSTALL_TEST = [W]
DPT {b} BidCos-RF.MEQ0165768:2.WORKING = false [RE]
CHN MEQ0165768:3 az_sw4:3
DPT {b} BidCos-RF.MEQ0165768:3.STATE = false [RWE]
DPT {f} BidCos-RF.MEQ0165768:3.ON_TIME = [W]
DPT {b} BidCos-RF.MEQ0165768:3.INHIBIT = false [RWE]
DPT {b} BidCos-RF.MEQ0165768:3.INSTALL_TEST = [W]
DPT {b} BidCos-RF.MEQ0165768:3.WORKING = false [RE]
CHN MEQ0165768:4 az_sw4:4
DPT {b} BidCos-RF.MEQ0165768:4.STATE = false [RWE]
DPT {f} BidCos-RF.MEQ0165768:4.ON_TIME = [W]
DPT {b} BidCos-RF.MEQ0165768:4.INHIBIT = false [RWE]
DPT {b} BidCos-RF.MEQ0165768:4.INSTALL_TEST = [W]
DPT {b} BidCos-RF.MEQ0165768:4.WORKING = false [RE]
ON_TIME writeable ? in jedem channel. in der set-list habe ich im channel-device aber nur on/off/toogle. kann ich das beinflussen? mit dem cul_hm modulen geht on for timer
noch etwas: bei den ganzen switchen ist der state zwischen zustand a (zb off) und zustand b (zb on) immer kurz OK , kann man das unterdrücken?
Wenn in HMCCUCHN das Attribut ccureadingformat auf "datapoint" gesetzt wird, funktioniert die Aktualisierung von STATE nicht. Das ist ein Bug in der aktuellen Version, mittlerweile in 3.4 gefixt (kommt heute oder morgen).
Der Set-Befehl "toggle" schaltet zwischen den im Attribut statevals festgelegten Werten um. Das können auch mehr als 2 sein.
ON_TIME muss beschreibbar sein, da darüber die "Ein-Zeit" in Sekunden festgelegt wird. Das Einschalten besteht dann im Prinzip aus 2 aufeinanderfolgenden Set-Befehlen (hier soll ein Switch für 60 Sekunden eingeschaltet werden):
set hmccudev_dev datapoint n.ONTIME 60
set hmccudev_dev datapoint n.STATE true
HMCCUDEV untersucht, ob ein CCU-Device einen Datenpunkt ON_TIME enthält. Falls ja, wird der Befehl on-for-timer angezeigt.
Derzeit unterstützt nur HMCCUDEV on-for-timer, nicht HMCCUCHN. Das liegt daran, dass ich eigentlich nur HMCCUDEV verwende, da ich grundsätzlich am Kanal 0 wegen LOWBAT, UNREACH usw. interessiert bin.
In Version 3.4 wird neben der ON_TIME auch die RAMP_TIME unterstützt.
beim HM-PB-6-WM55 gibt es das problem das in den channels keine tastedruck events erscheinen (press_short / press_long)
EDIT: gelöscht , antwort kam ja schon
Das ist kein "Problem" aka Fehler im Modul. Das liegt daran, dass die RPC-Schnittstelle darüber keinen Event produziert, wenn ein Taster(-Kanal) nicht mit einem (virtuellen) Gerät gepeered ist.
Also: Peere jeden der Kanäle, den Du vom Taster in fhem über CCU auswerten willst, mit einem virtuellen Kanal der CCU und schon kommt auch ein PRESS_SHORT usw. aus der RPC-Schnittstelle. Ist bekannt und wurde hier bereits thematisiert!
danke für den hinweis. aber das ist wohl falsch!
wähle ich beim Verknüpfen erst den virtuellen Kanal, erscheint der Wandtaster nicht als möglicher Partner.
wähle ich beim Verknüpfen erst den Wandtaster, erschein dann kein virtueller Kanal als möglicher Partner.
das scheint mir auch ganz logisch weil es keinen sinn ergibt 2 sender zu peeren
Die Lösung ist ein Programm, danach kommt auch der 2016-07-31 09:37:31 HMCCUCHN whg_pb6_05 whg_pb6.5.PRESS_SHORT: 1 im eventmonitor!
anebi mal so ein Programm
Zitatname Bedingung Aktivität
whg_pb6:5 pressshort Kanalzustand: whg_pb6:5 bei Tastendruck kurz Kanalauswahl: whg_rcv:1 sofort Tastendruck kurz
Zitat von: Ralli am 31 Juli 2016, 07:49:35
Das ist kein "Problem" aka Fehler im Modul. Das liegt daran, dass die RPC-Schnittstelle darüber keinen Event produziert, wenn ein Taster(-Kanal) nicht mit einem (virtuellen) Gerät gepeered ist.
Hmm, bei dem neuen ePaper Display (das mir gerade den letzten Nerv raubt und der Grund ist, weshalb ich die 3.4 noch nicht eingecheckt habe) werden aber Tasten-Events geschickt, auch wenn es nicht gepeered ist.
@chris1284: die 3.4 unterstützt nun virtuelle CCU Kanäle. Grund für die Probleme in früheren Versionen ist, dass diese Kanäle ein anderes Adressierungsschema verwenden und HMCCU beim Check auf valide Adressen (mit Absicht) sehr penibel ist.
siehe mein post über dir, so ist aktuell meine lösung. das peeren eine virt. ccu button und einen sender geht bei mir zu mindest nicht!
Jetzt haben sich die Antworten überschnitten ....
Hat jemand erfahrung mit dem rauchmelder? wenn man ihn per cul_hm an fhempaired kann man ihn zu einem alarm bewegen. mit der hmccu habe ich da noch keinen weg gefunden.
das drückern des testbutton für 2 sek bringt auch kein event, auch nicht wenn ich ihn wiedermit einem programm verbinde.
das team dafür nutzen bringt leider auch nichts, der status wird leider nicht von ok auf gefahr gesetzt
Das Peeren geht nicht unmittelbar - da habe ich mich falsch ausgedrückt.
Du musst in der CCU ein Programm erstellen, welches auf den Taster-Kanal reagiert, im Endeffekt aber nichts tut. Das führt dazu, dass die CCU intern ein Peering mit einem virtuellen Device durchführt und sodann werden die Events auch ausgegeben.
Edit: Wer alles liest, ist klar im Vorteil, ich sehe, Du bist mittlerweile auch selbst drauf gekommen 8).
Ich habe gerade Version 3.3 im Contrib-Pfad eingecheckt (Link siehe 1. Beitrag). Geändert haben sich die Dateien 88_HMCCU.pm, 88_HMCCUCHN.pm und 88_HMCCUDEV.pm.
Da mit dem letzten CCU Firmware Update der Kanal 0 auch für HM-IP Geräte eingeführt wurde, sollte einmal ein get iodev devicelist ausgeführt werden, sofern HM-IP Geräte genutzt werden.
HMCCU startet ab sofort per Default den eingebauten RPC-Server und verwendet ccurpcd.pl nicht mehr (als Vorbereitung auf Version 3.4). Wer trotzdem weiterhin ccurpcd.pl nutzen möchte, muss die Datei in das FHEM Verzeichnis kopieren, die Execute Flags setzen und das Attribut ccuflags im IO-Device auf "extrpc" setzen.
Gefixte Bugs:
- Der State eines HMCCUCHN Devices wurde nicht aktualisiert.
Neue Funktionen:
1) Unterstützung für virtuelle Taster der CCU (50 Kanäle)
2) Skalierung von Werten beim Lesen, Schreiben und bei Events. Mit dem Attribut "ccuscaleval" kann je Datenpunkt ein Faktor festgelegt werden. Beispiel: Skalierung des Levels eines Dimmers auf 0-100 (in der CCU 0-1):
attr devname ccuscaleval LEVEL:0.01
Durch diese Angabe wird beim Lesen und bei Events der Wert durch 0.01 geteilt, bevor das Reading geschrieben wird. Beim Schreiben per Set-Befehl wird der angegebene Wert mit 0.01 multipliziert.
3) Unterstützung von RAMP_TIME bei Set-Befehlen (on-for-timer, nur bei HMCCUDEV Devices), sofern das Gerät das unterstützt.
4) Unterstützung des neuen ePaper Displays. Wenn das Display als HMCCUDEV Device definiert ist, kann des wie folgt angesprochen werden:
Setzen der Zeilen 1+2: set devname config 2 TEXTLINE_1=Text TEXTLINE_2=Text
Setzen der Zeilen 4+5: set devname config 1 TEXTLINE_1=Text TEXTLINE_2=Text
Es kann dabei auch jeweils nur eine der Zeilen angesprochen werden.
Setzen der Zeilen 2-4 sowie Ausgabe von Tönen und Blinken der LED:
set devname datapoint 3.SUBMIT CommandString
Der CommandString besteht aus 1-n Zuweisungen der Form Parameter=Wert, die durch Komma getrennt werden. Folgende Parameter sind zulässig:
text1-3=Text|#1-9 Mit Raute werden 9 vordefinierte Texte angesprochen.
icon1-3=ico_off|ico_on|ico_open|ico_closed|ico_error|ico_ok|ico_info|ico_newmsg|ico_svcmsg
sound=snd_off|snd_longlong|snd_longshort|snd_long2short|snd_short|snd_shortshort|snd_long
signal=sig_off|sig_red|sig_green|sig_orange
repeat=0-15 0=unendlich
pause=1-160 Sekunden
Beispiel: set devname datapoint 3.SUBMIT text1=Zeile1,text2=Zeile2,sound=snd_short
Folgende Funktionen kommen erst mit der Version 3.4, die dann per FHEM Update verteilt wird:
- Verkürzte Readingnames
- CCU Heartbeat Mechanismus
- Erweiterung HMCCUCHN um on-for-timer
Super! Klasse, dass es voran geht!
Zitat von: zap am 31 Juli 2016, 17:35:52
2) Skalierung von Werten beim Lesen, Schreiben und bei Events. Mit dem Attribut "ccuscaleval" kann je Datenpunkt ein Faktor festgelegt werden.
Das ist prima, bisher hatte ich mir ein Userreading dafür angelegt:
attr FL_Light userReadings pct:.*1.LEVEL.* { return int((ReadingsVal($name, $name."-".substr($trigger, 2, -2), "0") + 0.005) * 100); }
Allerdings brauche ich das Reading nach wie vor unter diesem Namen, damit ich den Fhem-Standard erhalte und mittels devspec ordentlich schalten kann. Wenn du auf der Agenda für V3.4 die verkürzten Readingnamen stehen hast, kannst du bitte auch bedenken, dass es eine Lösung geben muss, um auf die Fhem Standards Readings zu kommen, ggf. gleich inkl. entsprechendem Setter, so dass man sich eventMap sparen kann? Dann kann man endlich problemlos und ohne viel Aufwand mehrere Devices unterschiedlichen Typs mit Komma getrennt adressieren oder eine Structure verwenden.
Prima wäre deshalb, wenn man eine Mapping-Tabelle definieren könnte, die dann jeweils vorwärts und rückwärts verwendet wird, so dass man schließlich die Readings nur noch so erhält, wie man sie braucht.
Wie füge ich nun aber bei obigem Befehl noch eine Ramptime und einen Timer hinzu?
Ich habe bei mir z.B. bisher folgendes über HMLAN laufen gehabt und bekomme es mit der CCU2 per Fhem nun überhaupt nicht mehr gescheit ans laufen (Licht 5min an und keine Rampup-Zeit):
DOELSEIF
(
[FL_Motion:?motion] and
[?HouseMode:state] eq "evening"
)
(
set FL_Light:FILTER=pct=0 pct 15 600 0,
set FL_Light:FILTER=pct!=0 pct [FL_Light:pct] 600 0
)
Ich hatte das wie folgt angepasst, aber es funktioniert nicht ordentlich:
DOELSEIF
(
[FL_Motion:?motion] and
[?HouseMode:state] eq "evening"
)
(
set FL_Light datapoint 1.ON_TIME 600,
set FL_Light datapoint 1.RAMP_TIME 0,
set FL_Light:FILTER=pct=0 pct 15,
set FL_Light:FILTER=pct!=0 pct [FL_Light:pct]
)
Mit Hilfe des neuen Attributs ccuscaleval wirds jetzt etwas einfacher.
Also habe ich hier einmal die Definition einiger Geräte von mir, die gerne mit in den Standard ausgenommen werden können:
Zitat
HM-LC-Dim1T-FM (HomeMatic Funk-Abschnitts- dimmer)
ccureadingformat name ccuscaleval LEVEL:0.01
cmdIcon pct%200%200%202:general_aus
controldatapoint 1.LEVEL
devStateIcon .*set_.*:light_control@orange .*100.*:light_light_dim_100@orange:pct%200%200%202 on:light_light_dim_100@orange:pct%200%200%202 .*1[0-9].*:light_light_dim_10@orange:pct%200%200%202 .*2[0-9].*:light_light_dim_20@orange:pct%200%200%202 .*3[0-9].*:light_light_dim_30@orange:pct%200%200%202 .*4[0-9].*:light_light_dim_40@orange:pct%200%200%202 .*5[0-9].*:light_light_dim_50@orange:pct%200%200%202 .*6[0-9].*:light_light_dim_60@orange:pct%200%200%202 .*7[0-9].*:light_light_dim_70@orange:pct%200%200%202 .*8[0-9].*:light_light_dim_80@orange:pct%200%200%202 .*9[0-9].*:light_light_dim_90@orange:pct%200%200%202 .*[1-9].*:light_light_dim_00@orange:pct%200%200%202 .*0.*:light_light_dim_00:pct%20100%201800%201 off:light_light_dim_00:pct%20100%201800%201
event-on-change-reading pct,.*1.LEVEL.*
eventMap /control:pct/control 0:off/control 100:on/
stateFormat pct
statechannel 1
userReadings pct:.*1.LEVEL.* { return ReadingsVal($name, $name."-".substr($trigger, 2, -2), "0"); }
webCmd pct%200%200%202
widgetOverride pct:slider,0,1,100
vielen dank, läuft soweit ohne fehler
ein kleiner bug ist noch aufgefallen: nach dem fhem start zb der state eines devices true/false ist wird auch true / fals angezeigt statt den substitute werden. diese greifen dann erst wieder wenn man das gerät schaltet. ist mi bisher aber nur bei geräten aufgefallen die vor dem fhem-restart on waren (also korekt true ersetzt) und danach auch. false/off geräte habe fein die "ausgeschaltet glühlampe" als symbol und nicht false
FHEM Update --> einwandfrei!!!
- Verkürzte Readingnames --> fidne ich gut, machts übersichlicher und bringt weniger frickelei in der readingsgroup mit sich was regexp angeht!
- Erweiterung HMCCUCHN um on-for-timer --> das fehlt mir aktuell wirklich
Mir ist aufgefallen, dass ein und das selbe Reading mal die Werte 0/1 haben und dann mal false/true hat.
on-for-timer wird leider Fhem ausgeführt statt auf dem HM Gerät selbst. Hier müsste man das mit dem control/datapoint Kommando als weitere Parameter hinten mit angeben können, damit es im Gerät ausgeführt wird:
Parameter 1: Level
Parameter 2: Ontime
Parameter 3: Ramptime
die einfach schalter bausätze machen schon on-for-timer selbst. das rawding working steht in der zeit auf 1 und die aktor led blink in der zeit.
Zitat von: chris1284 am 31 Juli 2016, 21:59:52
die einfach schalter bausätze machen schon on-for-timer selbst. das rawding working steht in der zeit auf 1 und die aktor led blink in der zeit.
Das ist gut zu wissen, aber es funktioniert eben leider nicht in der Kombination Dimmwert+Dauer bei einem Dimmer.
Ich habe nun nach dem gestrigen Update einmal die Mehrzahl meiner Homematic Geräte versucht nach Fhem Standard vorzukonfigurieren.
Die dafür angepasste HMCCUConf.pm sowie einen Screenshot habe ich mal angehängt.
Neue Devices dabei:
HM-Sec-MDIR
HM-Sec-MDIR-2
HM-LC-Bl1-SM
HM-LC-Dim1T-FM
HM-LC-Dim1TPBU-FM
HM-LC-SW2-PB-FM
HM-OU-LED16
Bereits enthaltende Devices habe ich teils verbessert.
Insbesondere habe ich versucht die STATE Values von CUL_HM nachzuempfinden und außerdem die wichtigsten Readings nach Fhem Standard wie z.B. battery,level,pct,motor sowie dazu passende Setter (sofern sinnvoll) definiert. Außerdem habe ich bei den meisten Devices sinnvolle Vorbelegungen für die Bedienung mit FHEMWEB hinterlegt (devStateIcon,cmdIcon,icon,widgetOverride,webCmd).
Eigentlich scheint es mir damit jetzt recht gut nutzbar zu sein :)
Gruß
Julian
@Loredo und chris1284, Zu Euren Fragen und Anmerkungen:
ZitatAllerdings brauche ich das Reading nach wie vor unter diesem Namen, damit ich den Fhem-Standard erhalte und mittels devspec ordentlich schalten kann. Wenn du auf der Agenda für V3.4 die verkürzten Readingnamen stehen hast, kannst du bitte auch bedenken, dass es eine Lösung geben muss, um auf die Fhem Standards Readings zu kommen, ggf. gleich inkl. entsprechendem Setter, so dass man sich eventMap sparen kann?
Von einem FHEM Standard bei Readingnames ist mir nichts bekannt. Meinst Du Readingnames analog CUL_HM? Es war nie meine Absicht, CUL_HM nach zu bauen. Eine Lösung für individuelle Readingnames wäre vermutlich ein Attribut in der Art "attr ccumapnames Datenpunkt:Reading,Datenpunkt:Reading". Ich werde aber nicht fest Namen wie "pct" einbauen. HMCCU verfolgt einen generischen Ansatz. Das hat den Vorteil, dass neue Homematic Geräte sofort nutzbar sind. In CUL_HM muss immer erst der Entwickler aktiv werden und wenn ich mir den Quellcode von CUL_HM anschaue mit x Fallunterscheidungen sehe ich meine Entscheidung bestätigt.
ZitatWie füge ich nun aber bei obigem Befehl noch eine Ramptime und einen Timer hinzu?
Ich habe leider keinen Dimmer. Aber wenn Du einen in FHEM mit HMCCUDEV anlegst, kannst Du wie folgt vorgehen:
set mydimmer datapoint n.ON_TIME 600
set mydimmer datapoint n.RAMP_TIME 5 # Das ist optional
set mydimmer datapoint n.LEVEL 0.5
Den letzten Befehl kannst Du per Attribut ccuscaleval anpassen, damit er Werte von 0-100 akzeptiert.
Mit dem Set Befehl on-for-timer geht das auch kürzer. Dieser Befehl steht zur Verfügung, wenn ein Gerät einen Datenpunkt ON_TIME bereitstellt:
attr mydimmer statedatapoint n.LEVEL
attr mydimmer statevals on:1.0,off:0.0
set mydimmer on-for-timer On-Time [Ramp-Time]
Nachteil: Es kann nur ein Zielwert für LEVEL verwendet werden (was mir gerade aufgefallen ist, das geht sicher noch besser, demnächst)
Zitat
ein kleiner bug ist noch aufgefallen: nach dem fhem start zb der state eines devices true/false ist wird auch true / fals angezeigt statt den substitute werden
Das ist seltsam. Nach dem Start des RPC-Servers wird ein "get update" ausgeführt, das alle Geräte Readings aktualisiert. Dabei sollten auch die true/false Werte gemäß dem Attribut Substitute ersetzt werden. Es dauert nach dem Start von FHEM aber ggf. 1-2 Minuten, bis der RPC-Server läuft. Hast Du Fehler im Logfile, dass Readings oder Datenpunkte nicht aktualisiert werden konnten?
ZitatMir ist aufgefallen, dass ein und das selbe Reading mal die Werte 0/1 haben und dann mal false/true hat.
Die RPC-Schnittstelle der CCU schickt 0/1, Homematic Script hingegen false/true (EQ-3 Logik ;-). Daher sehen meine Substitutes immer so aus (z.B. für ein Fenster):
attr mydev substitute (1|true):open,(0|false):closed
Zitaton-for-timer wird leider Fhem ausgeführt statt auf dem HM Gerät selbst. Hier müsste man das mit dem control/datapoint Kommando als weitere Parameter hinten mit angeben können, damit es im Gerät ausgeführt wird:
Verstehe ich nicht. Kannst Du das näher erläutern? Ich sehe schon: ich brauche einen Dimmer.
Noch eine Anmerkung zum Thema Rauchmelder: Ein Rauchmelder lässt sich nicht per Homematic Script oder RPC auslösen. Daher geht das mit HMCCU nicht. CUL_HM ist hier einfach näher am Protokoll unterwegs. Daher funktioniert es dort.
Zitat von: Loredo am 01 August 2016, 20:28:12
Ich habe nun nach dem gestrigen Update einmal die Mehrzahl meiner Homematic Geräte versucht nach Fhem Standard vorzukonfigurieren.
Die dafür angepasste HMCCUConf.pm sowie einen Screenshot habe ich mal angehängt.
Vielen Dank!!!! Ich schaue es mir an und übernehme es in das nächste Release.
Die on-for-timer Geschichte ist wohl noch nicht so richtig durchdacht meinerseits. Das geht wirklich noch besser. Liegt halt daran, dass ich das nur mit einer normalen Steckdose getestet habe (ohne Dimmer Funktion).
eine frage zur HMCCUConf.pm. sollten die attribute die da stehen bei einem define eigenständig geladen werden?
von den ganzen attributen wurde zb bei noch nie eines autom. gesetzt (was auch ganz gut ist wenn ich sehe das da cmdIcons gesetzt werden, nur lowbat statt batterie_state geholt wird oder zb lowbat false in no statt ok substitiert wird)?! ;D
kann man in fhem irgendwie sagen das es die config / ein teil der config anziehen und auf device xyz anweden soll?
Zitat von: chris1284 am 02 August 2016, 06:50:13
eine frage zur HMCCUConf.pm. sollten die attribute die da stehen bei einem define eigenständig geladen werden?
von den ganzen attributen wurde zb bei noch nie eines autom. gesetzt (was auch ganz gut ist wenn ich sehe das da cmdIcons gesetzt werden, nur lowbat statt batterie_state geholt wird oder zb lowbat false in no statt ok substitiert wird)?! ;D
kann man in fhem irgendwie sagen das es die config / ein teil der config anziehen und auf device xyz anweden soll?
Das automatische Laden der Attribute aus HMCCUConf.pm wäre noch eine Idee ... Im Moment werden diese Attribute per "set xy defaults" gesetzt. Eine Filterung bzw. Unterscheidung UI relevanter Attribute (cmdIcon usw) und anderer Attribute würde auch Sinn machen.
Die Idee hinter set defaults war, erst mal so viele Attribute wie möglich zu setzen und danach diese manuell anzupassen oder die überflüssigen zu löschen. Ich wollte damit einfach ein wenig Komfort für die verwöhnten CUL_HM Nutzer bereitstellen ;-)
Zitat von: zap am 02 August 2016, 09:01:41
Das automatische Laden der Attribute aus HMCCUConf.pm wäre noch eine Idee ... Im Moment werden diese Attribute per "set xy defaults" gesetzt. Eine Filterung bzw. Unterscheidung UI relevanter Attribute (cmdIcon usw) und anderer Attribute würde auch Sinn machen.
Die Idee hinter set defaults war, erst mal so viele Attribute wie möglich zu setzen und danach diese manuell anzupassen oder die überflüssigen zu löschen. Ich wollte damit einfach ein wenig Komfort für die verwöhnten CUL_HM Nutzer bereitstellen ;-)
Ich sehe darin vor allem eine enorme Zeitersparnis. Meinetwegen kann auch zwischen UI und Funktion unterschieden werden, auch wenn ich nicht weiß was die Leute da immer mit Bevormundung meinen... entweder ich lade ein Template und passe die Settings hinterher meinen Vorstellungen an oder ich lasse es eben bleiben; es wird ja niemand gezwungen die Voreinstellungen beizubehalten.
Gleichwohl bin ich der Meinung, wenn man gute Voreinstellungen auch für die UI hat, dass viele Nutzer dabei gar noch etwas lernen, weil sie eben die ganzen Kniffe der verschiedenen Attribute und wie diese zusammenspielen schon gar nicht mehr überblicken können (da hilt reines lesen der CommandRef nämlich auch schon bald nicht mehr). devStateIcon beispielsweise wirklich korrekt auf alle möglichen STATE-Werte einzustellen und gleichzeitig noch für sinnvolles schalten zu verwenden, ist gar nicht so leicht.
Deshalb: Ich finde es klingt immer etwas arrogant anzunehmen, dass man es selbst besser kann als ein Template es einem vielleicht per Voreinstellung vorschlagen (nicht vorgeben!) würde. Die wenigsten User sind echte Gurus und diejenigen Gurus sollen dann doch, pardon - gefälligst, ihren Beitrag dazu leisten, dass die Templates mega gut werden. Ich persönlich kann mir einfach nicht vorstellen, dass jemand freiwillig gerne Stunden pro einzelnem Device verbringen möchte es zu konfigurieren, wenn andere das auch schon durchlebt haben. Bei 20 unterschiedlichen Devices braucht man da schonmal locker mehrere Arbeitstage. Und bei der Vielzahl an teils notwendigen Attributen und klitzekleinen Details, die direkt zu Fehlern führen können, ist auch ein Kopieren auf weitere Devices sehr mühsam. Die Templates sind deshalb nicht nur was für dumme, faule CUL_HM Menschen... ::)
So, genug gejammert, einen hab ich noch...
Der default-Setter sollte bitte eigentlich ein Getter sein. Wenn ich in FHEMWEB nämlich den Zugriff für normale Nutzer (=Nicht-Administratoren) beschränken möchte, dann begrenze ich in der Regel die FHEM-Befehle auf "set". Auch wenn die Oberfläche nicht alle Setter direkt anbietet, so kann ein Nutzer jedoch wissentlich die direkte URL aufrufen, um die Konfiguration eines vorhandenen Devices so zu überschreiben. Das sollte vermieden werden.
(die Bezeichnung des "get"-Befehls ist dabei IMHO nicht so wortwörtlich zu nehmen, aber auch mangels alternativem Admin-Only Befehl; dazu gab es in der Developer-Ecke schon viel Diskussion, jedoch ohne Outcome). Beim HMCCU Master Device muss diese Trennung nicht unbedingt sein; man kann dort den Zugriff auch auf Deviceebene sperren (konsequenter wäre es allerdings).
Was auch toll wäre, wäre ein neuer Getter unter dem HMCCU Master Device, welcher eine Auswahlliste aller in der CCU definierten Devices zeigt und für die sich dann passend ein HMCCUDEV oder HMCCUCHN Device anlegen lässt. Aktuell muss man immer zwischen Fhem und der CCU hin und her wechseln und sich mühselig die Namen und Seriennummern raussuchen. Das würde helfen, dass man die vorhandenen Devicenamen aus der CCU auch direkt in Fhem so anlegt.
Was mich noch zu einem Hinweis führt: Damit die userReadings in meinen Beispielen in der HMCCUConf.pm kürzer sind wird davon ausgegangen, dass die Devicenamen in der CCU und in Fhem gleich sind. Andernfalls lässt sich nicht so einfach auf die Readingsnamen schließen (solange das mit den Readingsnamen ansich nicht gelöst wurde zumindest). Damit die userReadings zwischen Devices einigermaßen portabel bleiben, wird dort über aus dem verwendeten Trigger der Readingsname gebildet. Ist zwar auch nur bedingt schön, weil man auch die substr() Anweisung bei der Änderung des Triggers peinlich genau anpassen muss. Aber es ist immerhin kürzer und portabler, als es für jedes einzelne Device individuell mit den Device-spezifischen Readingnamen reinzuschreiben. Ich denke dieses Beispiel zeigt ganz gut, dass man an dieser Stelle nochmals überlegen sollte, ob die Readingsnamen tatsächlich jemals diesen Präfix des Devicenamen brauchen oder ob man den nicht einfach weg lassen kann ;)
Übrigens noch etwas (sorry - wenn's sprudelt, dann sprudelt's ;D ): Die Readingnamen für Kanal 0 werden immer mit einem Punkt "." an den Devicenamen angeschlossen. Bei den höheren Kanälen (1,2,3 ...) ist es ein Bindestrich. Das ist inkonsequent und sollte vereinheitlicht werden. Auch hier zeigt sich bei Nutzung der userReadings wieder eine gemeine Stolperstelle, bei der man den substr() Befehl entsprechend angleichen muss. Besonders gemein ist das auch, weil LOWBAT z.B. mal im Kanal 0 liegt und mal im Kanal 1 und man diese Anweisungen nicht einfach so kopieren kann, sondern dann je nach Device-Typ bzw. Kanal-Struktur wieder richtig anpassen muss.
Solange diese Stoplersteine so sind, helfen die Templates nochmals in mehrfacher Weise diese zu vermeiden - besonders weil Fehler in userReadings oftmals aufwändig zu debuggen sind.
Zitat von: chris1284 am 02 August 2016, 06:50:13
[...] nur lowbat statt batterie_state geholt wird oder zb lowbat false in no statt ok substitiert wird)?!
Der durch CUL_HM eingeführte Standard für die Batterie ist nunmal "ok" und "low". Alle Beispiele, vorhandenen Scripts (auch hier im Forum) etc sind eben zumeist auf diese Values ausgelegt. Daher macht es Sinn diese eben auch so beizubehalten. Ziel sollte doch sein, dass man auch ohne vermeidbare Schmerzen von CUL_HM auf HMCCU umsteigen kann (und ggf. wieder zurück).
Zitat von: Loredo am 02 August 2016, 11:39:18
Deshalb: Ich finde es klingt immer etwas arrogant anzunehmen, dass man es selbst besser kann als ein Template es einem vielleicht per Voreinstellung vorschlagen (nicht vorgeben!) würde.
ich finde es da ehr arrogant zu meinen mein Template sei das beste und es deshalb per default zu verteilen / usern aufzwingen zu wollen (evtl kann der user es ja doch besser /will es garnicht so)
Die lösung das template optional einzubindne fände ich super (ich schaue da nur die teile ab die ich brauche für meine anforderungen da ich FHEMWEB nicht als UI zum schalten benutze, ich schaue sie auch nur selten an und brauche daher keine bunten buttons oder bildchen,sondern brauche nur reine funktionsbereitstellung für TUI).
noch besser: die optionen
- nutze default-template [defaul]
- nutze user-template
- nutze garkein template
dies schön per attribut in der ccu konfigurierbar machen. so macht man alle glücklich (anfänger/faule , faule individualisten und die "do it yourself leute")
wie zap schon sagte will er das modul so generisch wie möglich halten und das finde ich gut. alles kann nur weniges muss (und das sollte nur das sein was die funktionalität sichert und dazu brauchts nunmal keine buttons oder bildchen oder web-cmds)
ZitatDer durch CUL_HM eingeführte Standard für die Batterie ist nunmal "ok" und "low".
mag sein, interessiert mich aber nicht wirklich. und da man hier ja glücklicherweise mit hmccu nicht wirklich eingeschränkt wird finde ich es gut das template nicht nutzen zu müssen!
Zitat
Was auch toll wäre, wäre ein neuer Getter unter dem HMCCU Master Device, welcher eine Auswahlliste aller in der CCU definierten Devices zeigt und für die sich dann passend ein HMCCUDEV oder HMCCUCHN Device anlegen lässt. Aktuell muss man immer zwischen Fhem und der CCU hin und her wechseln und sich mühselig die Namen und Seriennummern raussuchen.
hier wäre ein autocreate (per attribut aktivier und deaktivierbar) evtl. besser. ich persönlich muss zum anlegen irgendiwe keine namen und seriennummern mühselig kopieren..... 8)
Zitat von: chris1284 am 02 August 2016, 12:25:10
ich finde es da ehr arrogant zu meinen mein Template sei das beste und es deshalb per default zu verteilen / usern aufzwingen zu wollen (evtl kann der user es ja doch besser /will es garnicht so)
Wer lesen kann... niemandem soll was aufgezwungen werden. Wir reden wohl auch leicht aneinander vorbei, obwohl wir im Kern nicht weit voneinander weg sind. Das Template muss niemand benutzen, darf/kann es aber. Das muss auch überhaupt nicht automatisch passieren, nachdem ich ein Device frisch definiert habe. Den Setter/Getter dazu aufzurufen wird jeder noch selbst schaffen...
Zitat von: chris1284 am 02 August 2016, 12:25:10
wie zap schon sagte will er das modul so generisch wie möglich halten und das finde ich gut. alles kann nur weniges muss (und das sollte nur das sein was die funktionalität sichert und dazu brauchts nunmal keine buttons oder bildchen oder web-cmds)
mag sein, interessiert mich aber nicht wirklich. und da man hier ja glücklicherweise mit hmccu nicht wirklich eingeschränkt wird finde ich es gut das template nicht nutzen zu müssen!
Von "müssen" hat niemand was geschrieben. Es war, ist und bleibt nach meinem Verständnis ein Zusatzangebot.
Gegen den generischen Ansatz des Moduls ansich spricht ja auch gar nichts, da verstehst du (oder versteht ihr) mich offenbar vollkommen falsch.
Ich spreche ja davon, dass sich die HMCCU Devices harmonisch in eine Fhem Installation einfinden können (nicht jeder hat nur HM Geräte, sondern auch jede Menge anderer Gerätetypen). Da gehört es zum generischen Ansatz dazu, dass eine Austauschbarkeit des Backends möglich wird und man auch HM-Geräte zusammen mit nicht-HM-Geräten handhaben kann. Das hat auch nichts mit der UI zu tun, sondern damit, dass man z.B. für die einfache Nutzung der :FILTER Funktion in eigenen Scripts und Automationen die selben Readingnamen benötigt. Dafür haben sich bei den anderen Modulen einfach gewisse Standards herausgebildet. Wenn sich HMCCU nicht daran angleichen lässt, wird es für die wirklichen Nerds einfach nicht nutzbar sein/werden, weil es einfach zu sehr eine Sonderlocke bleibt und ich einmal an anderer Stelle in Fhem gelerntes nicht für HMCCU wiederverwenden und anwenden kann.
Ich habe verstanden, dass genau diese Sonderlocke eben durch den generischen Ansatz vermieden werden soll. Das finde ich ja großartig und prima; alles was ich sage ist, dass das noch nicht weit genug zu Ende gedacht ist und es deshalb Möglichkeiten geben muss an die Fhem Standards heranzukommen. Wie meine HMCCUConf Beispiele zeigen geht das auch heute schon, ist aber eben sehr mühselig und für jemanden, der die Fhem Standards nicht kennt auch schwer umzusetzen. Da helfen dann die Templates schon sehr. Anfängern kann man deshalb nur raten die Templates dann auch zu nutzen, damit das HMCCU Setup auch später ohne großen Mehraufwand erweiterbar bleibt und man im Laufe der Zeit alle Funktionen (heutige und zukünftige) von Fhem nutzen kann. Diese bleiben einem halt verwehrt, wenn man die HMCCU-Devices nicht von Anfang an entsprechend anlegt. Jeder hat die Freiheit sich bewusst dagegen zu entscheiden. Einigen Leuten sollte man aber auch ehrlicherweise sagen, welche Einschränkungen sie sich damit für eine spätere Erweiterung und Komplexisierung der Fhem Automationen ins Haus holen. Wer dann - wie du, chris1284 - sich trotzdem für seinen eigenen Weg entscheidet, der kann das ja tun und wird um Gottes Willen nicht dafür verurteilt oder gebrandmarkt! Ich möchte eben nur anmerken, dass man einige User, die mit Fhem noch keine jahrelange Erfahrung mit komplexen Setups haben, auch die Möglichkeit geben muss sie vor einem Chaos zu bewahren und Fhem für sie sonst irgendwann eher eine Negativerfahrung wird. In der Doku zu den Templates sollte dann deshalb auch ganz klar darauf hingewiesen werden, warum sie da sind und insbesondere was die Ziele sind und weshalb es Sinn macht sich an Fhem Standards zu orientieren. Wenn man all das weiß und es doch anders macht kann man sagen "You've been warned, we made you aware of it!".
ist doch ehr die frage, wer gibt die fhem standards für die readingsbezeichnung vor(das ältere modul? rudi? )...
denn es gibt keinen festgelegten reading-bezeichnungsstandard in fhem (wenn ja, habe ich die doku noch nicht finden können). Nur weil ein großteil etwas auf eine bestimmte art und weise macht, macht es das nicht zum standard ;)
Ich finde das durchaus sinnvoll das ein readings für auswertungen gleich ist (battery, humditity, temprature, usw) aber wer sagt zb ob nun set_tempratue oder desired-temp, BATTERY_STATE oder batteryLevel für alle thermostate (max,hm,fs20, usw suw) einzusetzen ist? das ist denke ich ein grundlegendes problem aller module
Zitat von: chris1284 am 02 August 2016, 13:22:37
ist doch ehr die frage wer gibt die fhem standards vor...
Ist wie immer demokratisch in Fhem: Einer hat es mal vorgemacht, andere haben sich ggf. daran orientiert und nun haben es mehrere Module (wenn auch nicht unbedingt alle) eben so implementiert. Das sind dann quasi Defacto-Standards, für die es sich lohnt einmal darüber nachzudenken was denn dagegen spricht, sich denen ebenfalls anzuschließen. Im Zweifel setzt für mich auch das Modul den Standard, welches die größte Nutzerschaft hat (siehe Stats (http://fhem.de/stats/statistics.html)).
Nur weil es ein Problem ist, was einige andere Module auch haben, muss man doch nicht bei einem neuen Modul diese Fehler wiederholen oder ignorieren? Wir lernen doch alle dazu, oder nicht ;)
hier ist es halt zweischneidig da die handhabung in hmccu ja richtiger wäre als die von cul_hm (auch wenn es als erstes da war) weil es auf der offiziellen hm-doku aufbaut und man im script auf der ccu die selben readings (datenpunkte) wiederfindet....
Deshalb macht es hier für mich auch Sinn beides parallel zu haben. Die userReadings sind ja genau dafür da. u.U. kann man aber auch zusätzlich noch etwas generisches ins Modul einbauen, welches neben der direkten 1-zu-1 Übernahme der CCU Datenpunkte für diese zusätzlich noch Readings anlegt und pflegt, die dann die Kompatibilität gewährleisten. Sollte eigentlich mit Hilfe dieses eq-3 Dokuments (http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/hm_devices_Endkunden.pdf) ziemlich einfach zu bewerten sein (habe auch schon darin gespickt für das HMCCUConf.pm Update). Das würde den komplexen userReadings-Verhau und auch die redundante Pflege der Templates in der HMCCUConf.pm reduzieren/vermeiden. Gleichzeitig bleibt die Flexibiltät des generischen Ansatzes aber erhalten, dass man neue und bisher unbekannte Geräte ebenfalls auch sofort nutzen kann. Im Gegenteil, ich sehe hier noch den Vorteil, dass man zusätzlich neu auf den Markt gekommene HM Gerät, die bereits bekannte CCU Datenpunkte verwenden, dann können diese auch direkt so verarbeitet werden wie bei all den anderen Devices auch bereits.
Beispielsweise kann man wohl davon ausgehen, dass die LEVEL Datenpunkte aus der CCU für die Kompatibilität immer auch zusätzlich als pct und level Readings verfügbar sein sollten (inkl. entsprechender Setter). Das wäre genauso generisch und unabhängig vom eigentlichen Device-Typ machbar, da eq-3 soweit ich das sehen kann schon sehr darauf achtet, dass sie einen Datenpunkt nicht doppelt und anders belegen. Datenpunkte mit dem gleichen Namen können also auch allesamt gleich behandelt werden.
Das einzige, was wirklich Device(typ) spezifisch bleibt ist auf jeden Fall die Berechnung von STATE. Das bliebe dann tatsächlich noch neben UI Anpassungen im Template übrig.
Zitat von: chris1284 am 02 August 2016, 13:31:08
[...] da die handhabung in hmccu ja richtiger wäre als die von cul_hm [...]
PS: es gibt hier wohl auch kein richtig oder falsch. Es gibt nur "legacy" und "neu" und die damit verbundene Frage, wie man die Brücken richtig baut. CUL_HM wurde eben AFAIK ohne eine offizielle eq-3 Dokumentation erstellt und daher kann man Martin da auch nicht sagen "du bist jetzt Schuld, dass dort alles gegen den eq-3 Standard funktioniert". Das wäre falsch und unfair. Richtig hingegen wäre es nun zu schauen, wie man als Fhem Gemeinde und zap als Modul Autor damit umgeht.
Es ist nunmal so, dass man für HMCCU nicht Fhem komplett umbauen wird und es auch weiterhin sehr gute Gründe gibt (und immer geben wird), dass Leute CUL_HM verwenden und nicht HMCCU. Allein deshalb sollte HMCCU nicht (nur) sein eigenes Süppchen kochen, möge es noch so nah an der echten eq-3 Welt sein. Ich denke diese Suppe funktioniert wie gesagt schon ganz hervorragend. Nun ist es Zeit für den nächsten Schritt sich der Fhem Welt anzunähern, damit das Modul auch irgendwann mal aus Contrib raus verschoben werden kann.
Zitat von: Loredo am 02 August 2016, 14:08:19
Beispielsweise kann man wohl davon ausgehen, dass die LEVEL Datenpunkte aus der CCU für die Kompatibilität immer auch zusätzlich als pct und level Readings verfügbar sein sollten (inkl. entsprechender Setter). Das wäre genauso generisch und unabhängig vom eigentlichen Device-Typ machbar, da eq-3 soweit ich das sehen kann schon sehr darauf achtet, dass sie einen Datenpunkt nicht doppelt und anders belegen. Datenpunkte mit dem gleichen
Deine Worte in EQ-3's Ohr ;-)
Zumindest bei LEVEL werde ich das so implementieren, d.h. sobald ein Datenpunkt Level verfügbar ist, wird es einen "set pct" Befehl geben.
ZitatDie Readingnamen für Kanal 0 werden immer mit einem Punkt "." an den Devicenamen angeschlossen. Bei den höheren Kanälen (1,2,3 ...) ist es ein Bindestrich. Das ist inkonsequent und sollte vereinheitlicht werden
Das ist dann ein Bug. Der Aufbau der Readingnames ist immer (je nach Attribut ccureadingformat):
Kanalname.Datenpunkt
Kanaladresse.Datenpunkt
Datenpunkt (nur bei HMCCUCHN möglich)
Allerdings werden Zeichen im Kanalnamen, die nicht der FHEM Konvention für Readingnames entsprechen, nach folgenden Regeln ersetzt:
Aus : wird .
Aus allem, was nicht [^A-Za-z\d_\.-] ist, wird _
Wenn das bei Dir anders ist, zeig mal, wie die entsprechenden Kanalnamen in der CCU aussehen. Vielleicht gibt es hier noch einen Bug bei der Zeichenersetzung.
Zitat von: zap am 02 August 2016, 16:46:11
Zumindest bei LEVEL werde ich das so implementieren, d.h. sobald ein Datenpunkt Level verfügbar ist, wird es einen "set pct" Befehl geben.
Der Setter kann ruhig "level" heißen, pct wäre aber als Alias trotzdem noch gut. In CUL_HM ist das ebenfalls aus Kompatibilitätsgründen so eingebaut (wenn das als Argument zählt). Es geht halt darum, dass man eine Schnittmenge zwischen mehreren unterschiedlichen Fhem-Devices erreicht (einige haben nur level, andere haben nur pct), wenn man z.B. :FILTER benutzt. HMCCU sollte nicht notwendigerweise einer der Kandidaten sein, der da ein Showstopper ist bzw. bei dem man dann doch wieder mit eventMap rangehen muss... ::)
Zitat von: zap am 02 August 2016, 16:46:11
Das ist dann ein Bug. Der Aufbau der Readingnames ist immer (je nach Attribut ccureadingformat):
Kanalname.Datenpunkt
Kanaladresse.Datenpunkt
Datenpunkt (nur bei HMCCUCHN möglich)
Anbei ein Screenshot eines HMCCUDEV, taucht aber so überall durchweg auf.
Zitat von: chris1284 am 02 August 2016, 13:22:37
ist doch ehr die frage, wer gibt die fhem standards für die readingsbezeichnung vor(das ältere modul? rudi? )...
denn es gibt keinen festgelegten reading-bezeichnungsstandard in fhem (wenn ja, habe ich die doku noch nicht finden können). Nur weil ein großteil etwas auf eine bestimmte art und weise macht, macht es das nicht zum standard ;)
Es gibt eine Festlegung, welche Zeichen in einem Readingname zulässig sind (ich habe die Festlegung selbst "verbockt", weil ich im Rahmen der HMCCU Entwicklung mal danach gefragt habe). Nun wird jeder Readingname mit einem unzulässigen Zeichen beim Starten von FHEM mit einer Fehlermeldung "belohnt".
Für das Thema Template wird sich eine Lösung finden. Z.B. könnte man dem Nutzer die Angabe einer Textdatei erlauben, die seine persönlichen Templates enthält.
Dass HMCCU noch im Contrib Zweig ist, hat nichts mit irgendwelchen FHEM Namenskonventionen zu tun sondern damit, dass bisher der RPC-Server sowie das Handling der Filequeues als separate Dateiene implementiert waren und das Einchecken in den FHEM Zweig auf wenig Gegenliebe bei den FHEM-Wächtern gestossen ist ;-). (Was ich durchaus verstehen kann). Seit Version 3.2 sind diese Hindernisse ausgeräumt.
@Loredo: Zu dem Readingname Problem: Wie heißen diese Kanäle in der CCU??
Zitat von: zap am 02 August 2016, 16:54:45
Es gibt eine Festlegung, welche Zeichen in einem Readingname zulässig sind (ich habe die Festlegung selbst "verbockt", weil ich im Rahmen der HMCCU Entwicklung mal danach gefragt habe). Nun wird jeder Readingname mit einem unzulässigen Zeichen beim Starten von FHEM mit einer Fehlermeldung "belohnt".
Das war auch gut so ;-)
Zum Verständnis: Chris und ich haben uns über den Namen eines Readings ausgetauscht, nicht über den dafür zur Verfügung stehenden Zeichensatz.
Zitat von: zap am 02 August 2016, 16:54:45
@Loredo: Zu dem Readingname Problem: Wie heißen diese Kanäle in der CCU??
Soweit ich das jetzt gesehen habe, würde ich folgende Korrelationen sehen (im Format CCU -> FHEM):
LEVEL (range: 0-1, steps: 0.005) => level,pct (range: 0-100, steps: 0.5)
LOWBAT (boolean) => battery (0=ok,1=low)
MOTION (boolean) => motion (0=no,1=yes)
BRIGHTNESS (range: 0-255) => brightness (range: 0-255)
UNREACH (boolean) => Activity (0=active,1=dead)
All diese Datenpunkte kann man denke ich problemlos unabhängig vom Devicetyp übernehmen.
Setter brauchts nur bei LEVEL und dazu hast du dich ja schon geäußert.
Nicht ganz sicher bin ich, ob man DIRECTION auch problemlos generalisieren kann, da die Readingnamen in CUL_HM dann doch vom Einsatzzweck abhängen (bzw. glaube ich größtenteils in die Berechnung von STATE einfließt). Der Vollständigkeit halber aber trotzdem als Beispiel für einen Rollladenaktor:
DIRECTION (range: 0-3, steps: 1) => motor (0=none,1=up,2=down,3=undefined)
Missverständnis: Wie heißen die Kanäle in der CCU, die in FHEM mit dem Bindestrich dargestellt werden?
Ich glaube, ich weiß was Du meinst. Das Problem ist: Der Kanal 0 wird von der CCU eigenständig hinzugefügt für Datenpunkte wie LOWBAT, UNREACH usw. Das jeweilige Gerät selbst hat nur die Kanäle 1-n. Und auch nur die können in der CCU individuell benannt werden. Der Kanal 0 hat hingegen immer den Namen des Geräts selbst. Da kann ich leider nichts machen. Dürfte sich aber erledigt haben, sobald es möglich ist, in HMCCUDEV auch Readings ohne Kanalname zu verwenden. Die Readings werden dann den Datenpunkten entsprechen. Wenn ein Datenpunkt in mehreren Kanälen vorkommt, wird die Kanalnummer mit einem Punkt vorangestellt, also z.B. 0.LOWBAT
Ha ja na klar, ich habe die Kanäle in der CCU so benannt, natürlich. ;)
Frage zu ccuscalevalZitat
2) Skalierung von Werten beim Lesen, Schreiben und bei Events. Mit dem Attribut "ccuscaleval" kann je Datenpunkt ein Faktor festgelegt werden. Beispiel: Skalierung des Levels eines Dimmers auf 0-100 (in der CCU 0-1):
attr devname ccuscaleval LEVEL:0.01
Durch diese Angabe wird beim Lesen und bei Events der Wert durch 0.01 geteilt, bevor das Reading geschrieben wird. Beim Schreiben per Set-Befehl wird der angegebene Wert mit 0.01 multipliziert.
Ich habe die Version 3.3 geladen und für meinen Dimmer das neue Attribut "ccuscaleval" gesetzt. Leider kann ich keine Wirkung feststellen. Wo liegt mein Denkfehler?
Internals:
DEF Keller-LED-Bar 1
IODev myHomematicCCU
NAME Keller_LED_Bar
NR 1316
STATE 0.0
TYPE HMCCUDEV
ccuaddr MEQ0343850
ccudevstate Active
ccuif BidCos-RF
ccuname Keller-LED-Bar
ccutype HM-LC-Dim1PWM-CV
channels 4
statevals devstate|on|off
Readings:
2016-08-02 23:47:24 Keller-LED-Bar.0.AES_KEY off
2016-08-02 23:47:24 Keller-LED-Bar.0.CONFIG_PENDING false
2016-08-02 23:47:24 Keller-LED-Bar.0.DEVICE_IN_BOOTLOADER false
2016-08-02 23:47:24 Keller-LED-Bar.0.DUTYCYCLE false
2016-08-02 23:47:24 Keller-LED-Bar.0.RSSI_DEVICE on
2016-08-02 23:47:24 Keller-LED-Bar.0.RSSI_PEER 87
2016-08-02 23:47:24 Keller-LED-Bar.0.STICKY_UNREACH false
2016-08-02 23:47:24 Keller-LED-Bar.0.UNREACH false
2016-08-02 23:47:24 Keller-LED-Bar.0.UPDATE_PENDING false
2016-08-02 23:51:48 Keller-LED-Bar.1.DIRECTION off
2016-08-02 23:51:48 Keller-LED-Bar.1.ERROR_OVERHEAT off
2016-08-02 23:51:48 Keller-LED-Bar.1.ERROR_REDUCED off
2016-08-02 23:47:24 Keller-LED-Bar.1.INHIBIT false
2016-08-02 23:51:48 Keller-LED-Bar.1.LEVEL 0.0
2016-08-02 23:51:48 Keller-LED-Bar.1.LEVEL_REAL 0.0
2016-08-02 23:51:48 Keller-LED-Bar.1.WORKING off
2016-08-02 23:47:24 Keller-LED-Bar.2.DIRECTION off
2016-08-02 23:47:24 Keller-LED-Bar.2.ERROR_OVERHEAT false
2016-08-02 23:47:24 Keller-LED-Bar.2.ERROR_REDUCED false
2016-08-02 23:47:24 Keller-LED-Bar.2.INHIBIT false
2016-08-02 23:47:24 Keller-LED-Bar.2.LEVEL 1.0
2016-08-02 23:51:48 Keller-LED-Bar.2.LEVEL_REAL 0.0
2016-08-02 23:47:24 Keller-LED-Bar.2.WORKING false
2016-08-02 23:47:24 Keller-LED-Bar.3.DIRECTION off
2016-08-02 23:47:24 Keller-LED-Bar.3.ERROR_OVERHEAT false
2016-08-02 23:47:24 Keller-LED-Bar.3.ERROR_REDUCED false
2016-08-02 23:47:24 Keller-LED-Bar.3.INHIBIT false
2016-08-02 23:47:24 Keller-LED-Bar.3.LEVEL 1.0
2016-08-02 23:51:48 Keller-LED-Bar.3.LEVEL_REAL 0.0
2016-08-02 23:47:24 Keller-LED-Bar.3.WORKING false
2016-08-02 23:51:48 control 0.0
2016-08-02 23:51:48 state 0.0
Attributes:
IODev myHomematicCCU
ccuscaleval Keller-LED-Bar.1.LEVEL:0.01
controldatapoint 1.LEVEL
event-on-change-reading .*
group BeachBar
icon light_led_stripe
room 04_Keller
statechannel 1
statedatapoint 1.LEVEL
statevals on:1.0,off:0.0
stripnumber 1
substitute 1.0:on,0.0:off,1:on,0:off
webCmd control
widgetOverride control:slider,0,0.1,1,1
define Keller_LED_Bar HMCCUDEV Keller-LED-Bar 1
attr Keller_LED_Bar IODev myHomematicCCU
attr Keller_LED_Bar ccuscaleval Keller-LED-Bar.1.LEVEL:0.01
attr Keller_LED_Bar controldatapoint 1.LEVEL
attr Keller_LED_Bar event-on-change-reading .*
attr Keller_LED_Bar group BeachBar
attr Keller_LED_Bar icon light_led_stripe
attr Keller_LED_Bar room 04_Keller
attr Keller_LED_Bar statechannel 1
attr Keller_LED_Bar statedatapoint 1.LEVEL
attr Keller_LED_Bar statevals on:1.0,off:0.0
attr Keller_LED_Bar stripnumber 1
attr Keller_LED_Bar substitute 1.0:on,0.0:off,1:on,0:off
attr Keller_LED_Bar webCmd control
attr Keller_LED_Bar widgetOverride control:slider,0,0.1,1,1
es muss nur der Datenpunkt genannt werden, also nur LEVEL:0.01 statt Keller-LED-Bar.1.LEVEL:0.01
Gruß
Julian
Zitat von: zap am 02 August 2016, 17:37:40
Der Kanal 0 hat hingegen immer den Namen des Geräts selbst.
den kann man doch auch umbenennen / bzw das gerät in der ccu. ich habe nichts in der ccu mit originalem namen wwas devices angeht
Zitat von: zap am 02 August 2016, 17:37:40
Wenn ein Datenpunkt in mehreren Kanälen vorkommt, wird die Kanalnummer mit einem Punkt vorangestellt, also z.B. 0.LOWBAT
inkonsistent würde ich sagen wollen. entweder immer mit kanal vorweg oder halt keine HMCCUDEV mehr und nur noch HMCCUCHN. das wäre dann im übrigen genau so wie es CUL_HM macht, da gibts auch keine Devices somit auch nie das problem doppelter readings da ein fhem device (also ein hmccuchn) nur einmal in fhem existieren darf.
beispiel ein 4-fach aktor hat auf jeden fall doppelte readings und somit immer eine zahl davor. das mach den readingsnamen wieder unbrauchbar zu den "standards". wenn ich zb in einer readingsgroup alle state's anzeigen will würde ich das per .*:STATE machen. die 4-fach switsche würden als HMCCUDEV da völlig raus fallen, als HMCCUCHN jedoch nicht weil es pro chn nur 1 state gibt
thermostate habe ich zb nur mit HMCCUCHN eingebunden (chn4) als [raumkürzel]_hz_Clima. bei 1-fach switches nur chn1,bei sensroen nur chn1, bei 4-fach switches ch1-4
1-2 device habe ich als ccudev, davon ist aber keines genutzt, er zum mal anschauen
vorteil nur noch HMCCUCHN
-so holt man sich nur den chn in fhem rein welchen man braucht zum schalten / für readings
-das ist ein vorteil gegenüber CUL_HM der immer alle channels will und auch anlegt, egal ob man sie gebrauchen kann oder nicht (da man peering und config in der ccu macht braucht man viele mit HMCCU halt nicht )
-du must nicht 2 module pflegen
-keine doppelten readings
-esgibt keien grund für hmccudev
nachteil
-wüsste ich keinen außer das sich das auf bestehende installationen auswirken würde wo hmccudevs definiert sind
- man würde einfach das modulnicht weiter bearbeiten und nur noch hmccuchn, wer dann nach 3 monaten noch HMCCUDEV definiert hat hat halt was verpasst
Zitat von: chris1284 am 03 August 2016, 06:39:53
den kann man doch auch umbenennen / bzw das gerät in der ccu. ich habe nichts in der ccu mit originalem namen wwas devices angeht
Das Gerät kann man natürlich umbenennen. Ich meinte, dass der Kanal 0 in der CCU nicht separat aufgeführt wird und nicht wie die anderen Kanäle - unabhängig vom übergeordneten Gerät - umbenannt werden kann.
Zitat
inkonsistent würde ich sagen wollen. entweder immer mit kanal vorweg oder halt keine HMCCUDEV mehr und nur noch HMCCUCHN. das wäre dann im übrigen genau so wie es CUL_HM macht, da gibts auch keine Devices somit auch nie das problem doppelter readings da ein fhem device (also ein hmccuchn) nur einmal in fhem existieren darf.
Mit inkonsistent hast Du recht. Also immer mit Kanalnummer. Das macht die Umsetzung auch einfacher.
Ein Verzicht auf HMCCUDEV wäre natürlich aus Entwicklersicht eine große Vereinfachung, da es deutlich komplexer ist als HMCCUCHN. Allerdings möchte ich grundsätzlich den Kanal 0 dabei haben wegen LOWBAT und UNREACH. Es gibt einige Geräte (z.B. Tür-/Fensterkontakte), die auch im Kanal 1 LOWBAT bereitstellen. Aber leider eben nicht alle. D.h. ich müsste ein HMCCUCHN bauen, dass immer auch den Kanal 0 mitführt. Muss ich mal drüber hirnen ;-). Ein einziges Client-Modul hat schon einen gewissen Charme, zumal es mir Arbeit erspart (Informatiker sind ja von Natur aus faul und hassen sich wiederholende Tätigkeiten bzw. neigen zum KISS Prinzip ;) ).
Noch was anderes: Ich habe leider keinen Dimmer. In der EQ-3 Doku habe ich gesehen, dass es bei den Dimmern virtuelle Kanäle gibt, die die gleichen Datenpunkte wie Kanal 1 enthalten. Welche Funktion haben diese virtuellen Kanäle ?
ich fände die aufnahme von kanal 0 in hmccuchn, den wegfall von hmcudev und den wegfall der vorangestellten kanalnummer bei readings auch für die optiomalste lösung
wenn man quasi das device ohne angabe der kanalnummer definiert nimmt er nu chan 0
define <def> HMCCUCHN <ccudefname> legt den 0erchannel an , nat. mit readings ohne vorzeichen
define <def> HMCCUCHN <ccudefname>:<n> legt den n channel an , nat. mit readings ohne vorzeichen, gibt man 0 an legt er dannnatürlich auch nur den chn 0 an
Ich empfinde es schon als Vorteil, wenn man nicht wie bei CUL_HM zwingend für jeden Kanal ein eigenes Device benötigt.
Das ist z.B. bei einem LED-Display mit 16+1 Kanälen total nervig. Außerdem noch zu bedenken: Bisher war der Favorit HMCCUDEV eben genau wegen der LOWBAT und UNREACH Infos etc. Es macht bei einer großen Installation viel Arbeit dem Hü und Hott zu folgen (sprich: die >20 mühsam einzeln erstellten Kanäle müssen wieder komplett neu umgeschrieben werden -> Horror!).
Die Trennung zwischen HMCCUDEV und HMCCUCHN aufzuheben finde ich prinzipiell gut. Vielleicht lässt sich das Define für HMCCUCHN ja so anpassen, dass man auch mehrere Kanäle mit Komma getrennt angeben kann.
Die Readings sollten nur wenn unbedingt notwendig die Kanalnummer beinhalten, damit Fhem Scripts, Attribute etc. portabler und weniger von den Kanalnummern abhängig sind.
Zitat von: zap am 03 August 2016, 07:30:33
Noch was anderes: Ich habe leider keinen Dimmer. In der EQ-3 Doku habe ich gesehen, dass es bei den Dimmern virtuelle Kanäle gibt, die die gleichen Datenpunkte wie Kanal 1 enthalten. Welche Funktion haben diese virtuellen Kanäle ?
Soweit ich weiß liegt das daran, dass neuere Geräte noch einen Kanal pro Taster(richtung) bereitstellen. Es gibt ein internes Peering zwischen dem 1. Kanal und dem 2.+3., damit bei betätigen der Taste für Kanal 2/3 dann der Kanal 1 geschaltet wird. Dieses Peering kann man wohl auch aufheben und den Taster damit anders konfigurieren oder komplett anders verwenden. Zumindest habe ich das bei CUL_HM so verstanden. Ob sich das auch mit der CCU so nutzen/verwenden lässt, habe ich nicht ausprobiert.
immer noch ccuscalevalZitat
2) Skalierung von Werten beim Lesen, Schreiben und bei Events. Mit dem Attribut "ccuscaleval" kann je Datenpunkt ein Faktor festgelegt werden. Beispiel: Skalierung des Levels eines Dimmers auf 0-100 (in der CCU 0-1):
attr devname ccuscaleval LEVEL:0.01
Durch diese Angabe wird beim Lesen und bei Events der Wert durch 0.01 geteilt, bevor das Reading geschrieben wird. Beim Schreiben per Set-Befehl wird der angegebene Wert mit 0.01 multipliziert.
und
Zitates muss nur der Datenpunkt genannt werden, also nur LEVEL:0.01 statt Keller-LED-Bar.1.LEVEL:0.01
Ich habe jetzt alles mögliche probiert und werde nicht schlauer....
mein aktuelles define sieht so aus:
1.LEVEL:0.01, da das Reading LEVEL in allen Kanälen des HM-Dimmers vorkommt. Ich möchte lediglich den LEVEL des Kanals 1 "skalieren". Leider scheint das keine Wirkung zu haben.
Ein
set datapoint 1.LEVEL 30 bewirkt z.B. dass 1.LEVEL auf den Wert 1.0 gesetzt wird. Wo ist mein Denkfehler....
Zitat von: Achiim am 03 August 2016, 10:57:55
immer noch ccuscaleval
und
Ich habe jetzt alles mögliche probiert und werde nicht schlauer....
mein aktuelles define sieht so aus: 1.LEVEL:0.01, da das Reading LEVEL in allen Kanälen des HM-Dimmers vorkommt. Ich möchte lediglich den LEVEL des Kanals 1 "skalieren". Leider scheint das keine Wirkung zu haben.
Ein set datapoint 1.LEVEL 30 bewirkt z.B. dass 1.LEVEL auf den Wert 1.0 gesetzt wird. Wo ist mein Denkfehler....
Es muss, wie schon mehrfach gesagt, nur der Datenpunkt ohne Kanal angegeben werden. Eine unterschiedliche Skalierung des gleichen Datenpunktes bei unterschiedlichen Kanälen ist wohl nicht vorgesehen, macht aber IMHO auch keinen Sinn, da es sich um das gleiche Datenformat handelt. Wenn du diese Unterscheidung möchtest, musst du wohl mehrere HMCCUCHN Devices anlegen anstatt ein einzelnes HMCCUDEV.
Zitat von: Achiim am 03 August 2016, 10:57:55
mein aktuelles define sieht so aus: 1.LEVEL:0.01, da das Reading LEVEL in allen Kanälen des HM-Dimmers vorkommt. Ich möchte lediglich den LEVEL des Kanals 1 "skalieren". Leider scheint das keine Wirkung zu haben.
Ein set datapoint 1.LEVEL 30 bewirkt z.B. dass 1.LEVEL auf den Wert 1.0 gesetzt wird. Wo ist mein Denkfehler....
Da mit Deiner Definition die Skalierung nicht greift, wird der Wert 30 an den Datenpunkt durchgereicht. Das veranlasst die CCU, den Datenpunkt auf den Maximalwert 1 zu setzen.
Eine Skalierung auf einzelne Kanäle bei mehrfach vorhandenen Datenpunkten ist nicht möglich (macht m.E. auch nicht wirklich sinn, da gleich benannte Datenpunkte normalerweise auch die gleiche Funktion haben). Was funktionieren sollte:
attr devname ccuscaleval LEVEL:0.01 # Damit werden alle LEVELS aller Kanäle des Dimmers skaliert
set devname datapoint 1.LEVEL 30
Also im Prinzip einfach die Kanalangabe beim Attribut ccuscaleval weg lassen.
Wenn sich das Ganze nur auf den Kanal 1 beziehen soll, nimm HMCCUCHN statt HMCCUDEV. Dann beim set Befehl den Kanal weglassen.
BTW: Da ich keinen Dimmer habe, habe ich die Skalierung nur beim Get getestet. Sollte aber tun.
@zap: Protipp - vorher Antworten checken, spart Arbeit ;)
Zitat von: Loredo am 03 August 2016, 11:58:08
@zap: Protipp - vorher Antworten checken, spart Arbeit ;)
Jepp, die Finger waren schneller als das Auge (oder so ähnlich)
Sorry für meine Begriffsstutzigkeit. Nun funktioniert's. Danke.
Anbei meine Defines für die Nachwelt:
define Lagerfeuer HMCCUDEV Keller-Bar 1
attr Lagerfeuer IODev myHomematicCCU
attr Lagerfeuer ccuscaleval LEVEL:0.01
attr Lagerfeuer controldatapoint 1.LEVEL
attr Lagerfeuer group BeachBar
attr Lagerfeuer icon light_led_stripe
attr Lagerfeuer room 04_Keller
attr Lagerfeuer statechannel 1
attr Lagerfeuer statedatapoint 1.LEVEL
attr Lagerfeuer statevals on:100,off:0
attr Lagerfeuer stripnumber 1
attr Lagerfeuer substitute 100.0:on,0.0:off,100:on,0:off
attr Lagerfeuer webCmd control
attr Lagerfeuer widgetOverride control:slider,0,1,100,100
Und das Define für tabletUI:
<div data-type="dimmer" data-device="Lagerfeuer" data-set="control" data-min="0" data-max="100" data-off="0" data-on="100" class="cell"></div>
<div data-type="label" class="cell">Lagerfeuer</div>
Danke für Eure Unterstützung.
Es wäre übrigens sehr wünschenswert, wenn Geräte nach einem Fhem Neustart nicht den State "Initialized" bekämen, sondern die Readings einfach nicht angefasst würden bis die Daten von der CCU geladen und dann aktualisiert werden. Ein "Initialized" ist ok für frisch definierte Geräte, bei denen man noch kein Update gemacht oder ein Event bekommen hat. Ansonsten sollte die Aktualisierung der Readings ausschließlich Event getrieben sein.
Zitat von: Loredo am 03 August 2016, 10:43:58
Bisher war der Favorit HMCCUDEV eben genau wegen der LOWBAT und UNREACH Infos etc. Es macht bei einer großen Installation viel Arbeit dem Hü und Hott zu folgen (sprich: die >20 mühsam einzeln erstellten Kanäle müssen wieder komplett neu umgeschrieben werden -> Horror!).
musst du eh... wenn die readings umbenannt werden musst du ja zwangsläufig auch viele attribute an den devices anpassen. da kann man auch gleich auf HMCCUCHN wechseln ;-)
ich denke mal es wäre dann auch nur EIN finales Hott statt hüs und hotts
Noch ein weiterer Hinweis:
Ein Reading mit dem Namen "STATE" (groß geschrieben) macht wohl bei HMCCUCHN ein paar Probleme, wenn "attr ccureadingformat datapoint" gesetzt ist (so wie der ja nun wohl angedachte spätere Standard). So wird bei einer Definition eines HM-Sec-SC z.B. das Reading "state" (klein geschrieben) nicht aktualisiert und somit muss noch ein "attr stateFormat STATE" hinzugefügt werden, damit das Internal STATE dann korrekt den Wert des Reading STATE (statt dem Fhem Default "state") enthält. Dabei hilft es auch nicht, "attr statedatapoint STATE" zu setzen.
Diese Überschneidung zwischen Fhem und der CCU bedarf also wohl noch einer Sonderbehandlung.
Das Reading "STATE", welches aus der CCU übernommen wird, sollte also für den definierten Kanal einfach in "state" umbenannt werden. Wenn mehrere Kanäle definiert sein sollten und HMCCUCHN das dann unterstützt, müssen die Readings ja dann eh unterschieden werden. Da gibt es dann keinen Konflikt und statedatapoint kann ganz normal greifen.
Edit:
Außerdem führt das auch dazu, dass nach einem Neustart der Initialized-Wert nicht überschrieben wird, wenn man nur event-on-change-reading gesetzt hat und nicht zusätzlich noch even-on-update-reading für .*STATE.* definiert hat. Das spricht auch dafür den Initialized Status nach dem Neustart nochmals zu überdenken, schließlich will man event-on-update-reading nur in Ausnahmefällen und nicht immer setzen müssen.
Ich dachte eigentlich, dass ich den STATE Bug (keine Aktualisierung) mit der V3.3 behoben hatte. Da muss ich nochmal drüber schauen.
In der 3.4, die ich gerade in der Mache habe, gibt es ein Attribut ccuackstate. Wenn das auf 0 gesetzt wird, lässt HMCCU die Finger vom Internal STATE und dem Reading state, d.h. kein "initialized" oder "ok". Lediglich im Fehlerfall wird ein "error" gesetzt.
Um es dem Anwender einfach zu machen, ist der Default = 0, d.h. die States werden nicht mehr mit (positiven) Statusmeldungen überschrieben.
Das "OK" finde ich durchaus als Quittungsmeldung sinnvoll (Error ebenso). Allerdings habe ich auch schon beobachtet, dass das OK stehen bleibt, wenn man z.B. einen Dimmer oder Rollladen Befehl schickt und das Gerät bereits im angefragten Status ist (also z.B. schon komplett geöffnet ist). Die CCU schickt wohl nur bei einer Änderung eine Antwort, wohl aber nicht auf den Befehl ansich... von daher macht das für einige Geräte Sinn es komplett abzuschalten.
Hallo,
ich habe mal ein ganze blöde Anwenderfrage:
Ich würde gerne von meinem Jalousieaktor die Werte vertauschen, damit ich sie in Smartvisu visualisieren kann.
Aktuell steht level bei 1 wenn die Jalousie oben ist und bei 0 wenn die Jalousie unten ist. Smartvisu, bzw. icon.shutter erwartet es aber genau andersrum.
Kann ich das irgendwie einfach mit HMCCU ändern?
Grüße
Dominic
Zitat von: Loredo am 03 August 2016, 18:53:36
Das "OK" finde ich durchaus als Quittungsmeldung sinnvoll (Error ebenso). Allerdings habe ich auch schon beobachtet, dass das OK stehen bleibt, wenn man z.B. einen Dimmer oder Rollladen Befehl schickt und das Gerät bereits im angefragten Status ist (also z.B. schon komplett geöffnet ist). Die CCU schickt wohl nur bei einer Änderung eine Antwort, wohl aber nicht auf den Befehl ansich... von daher macht das für einige Geräte Sinn es komplett abzuschalten.
ok, die fehlende Aktualisierung von STATE / state kann ich bestätigen. Werde ich beheben.
Wenn die CCU nicht zeitnah nach einem Set einen Event schickt und damit die Werte aktualisiert werden, hilft es ggf., das Attribut "ccuverify" auf 1 zu setzen. Das funktioniert nur, wenn der Datenpunkt auch lesbar ist.
Mit ccuverify = 2 wird der Wert direkt nach dem setzten einfach in das Reading geschrieben (d.h. ohne Rückfrage bei der CCU). Das Risiko dabei ist, dass ein falscher Status im Reading landet, wenn das Set fehlschlägt.
Zitat von: Nic0205 am 03 August 2016, 18:55:52
Hallo,
ich habe mal ein ganze blöde Anwenderfrage:
Ich würde gerne von meinem Jalousieaktor die Werte vertauschen, damit ich sie in Smartvisu visualisieren kann.
Aktuell steht level bei 1 wenn die Jalousie oben ist und bei 0 wenn die Jalousie unten ist. Smartvisu, bzw. icon.shutter erwartet es aber genau andersrum.
Kann ich das irgendwie einfach mit HMCCU ändern?
Nur bei der Statusmeldung oder auch beim Setzen?
Wenn es nur um die Statusmeldung geht, per Attribut substitue (dann nur für die Endpositionen), also
attr devname substitute LEVEL!1.0:0.0,0.0:1.0
Müsste funktionieren. Um das 100% zu unterstützen (get und set), müsste es neben dem Attribut ccuscaleval noch sowas wie ein ccureverseval geben. Kann ich mal drüber nachdenken ...
P.S. Die Liste der Wünsche wird länger. Freut mich, da es mir zeigt, dass das Modul genutzt wird. Ich hoffe aber Ihr habt Verständnis, dass ich das nur nach und nach realisieren kann. Habe nebenher noch einen zwar interessanten, aber stressigen Job und jede Menge Hobbies :D
Hallo zap,
das mit substitute ist ein guter Ansatz - werde ich heute abend mal probieren.
Ein CCUreverseval wäre dann natürlich die Krönung, damit könnte man dann auch die zwisxhenposition seht schön ansteuern. ;-) hast du schon eine Roadmap für die 3.4? :-)
Gesendet von meinem GT-I9505 mit Tapatalk
Zitat von: Nic0205 am 04 August 2016, 06:34:53
Ein CCUreverseval wäre dann natürlich die Krönung, damit könnte man dann auch die zwisxhenposition seht schön ansteuern. ;-) hast du schon eine Roadmap für die 3.4? :-)
Noch nicht. Prio 1 hat aber die Verlagerung aus contrib nach FHEM, damit endlich das Update einfacher wird. Die Grundlagen dafür gibt es seit 3.2 (interner RPC Server), da die FHEM Macher nicht so begeistert von der Idee waren, sowas wie ccurpcd.pl im Hauptzweig zu haben. Finde ich zwar schade, da der interne Server wg. dem Forken des FHEM-Prozesses nun ca. das 10 fache an Ressourcen benötigt wie das schlanke ccurpcd.pl. Aber wie sagt mein Lieblingsrestaurant-Besitzer immer: "was ka ma mache?" ;)
Neben ein paar Bug Fixes werden es folgende Funktionen definitiv in die 3.4 schaffen:
- Set-Befehle on-for-timer und pct, sofern ein Gerät über die entsprechenden Datenpunkte verfügt
- Verkürzte Readingnames in HMCCUDEV Devices (ohne Gerätenamen)
Ein ccureverseval wäre jetzt nicht so schwer umzusetzen, allerdings möchte ich auch die Attribut-Flut nicht zu groß werden lassen.
Das verstehe ich natürlich.
Das Problem mit den CCUreverseval müsste aber doch eigentlich jeder haben, der smartvisu und homematic mit hmccu einsetzt , oder ? Vielleicht gibt es ja auch noch eine andere Lösung
Gesendet von meinem GT-I9505 mit Tapatalk
weiss einer wie ich den thermostaten (rt-dn) auf manu setzen kann und er die aktuelle / letzte manu-temp setzt?
beispiel
-er ist im manu mit temp x
-dann schalte ich auto und er nimmt nat. die für die zeit definierte autotemp
-dann will ich manu setzen und er soll wieder temp x fahren
manuel wechsel würde ich rt nur den modus wechseln ohne was am rad zu drehen. unter cul_hm würde ich nur set manu sagen ohne eine temp anzugeben. in der ccu nur den mode manu button drücken ohne eine temp anzugeben. hmccudev verlangt nach 4.MODE_MANU aber einen {value} so das ich immer was angeben muss (gibt man blödsin ein wie true oder 1 geht der rt auf OFF).
aus der scriptdocu entnehme ich nur das der value float sein muss. gibts da nen trick oder wie macht die ccu/der rt das intern?
Hallo zap,
ich habe leider mal wieder ein Problem mit dem RPC.
Mein Log sieht aktuell so aus:
2016.08.03 05:17:14 1: Including fhem.cfg
2016.08.03 05:17:14 3: telnetPort: port 7072 opened
2016.08.03 05:17:15 3: WEB: port 8083 opened
2016.08.03 05:17:15 3: WEBphone: port 8084 opened
2016.08.03 05:17:15 3: WEBtablet: port 8085 opened
2016.08.03 05:17:15 2: eventTypes: loaded 204 events from ./log/eventTypes.txt
2016.08.03 05:17:16 2: meinfronthem: ipc listener opened at port 16384
"my" variable $dpt masks earlier declaration in same scope at ./FHEM/88_HMCCU.pm line 1291, <DATA> line 1.
2016.08.03 05:55:27 1: Including ./log/fhem.save
2016.08.03 05:55:27 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.08.03 05:55:27 1: in INITIALIZED
2016.08.03 05:55:27 1: usb create starting
2016.08.03 05:55:27 3: Probing CUL device /dev/ttyAMA0
2016.08.03 05:55:27 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.08.03 05:55:27 1: usb create end
2016.08.03 05:55:27 1: in INITIALIZED
2016.08.03 05:55:27 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.08.03 05:55:27 0: Featurelevel: 5.7
2016.08.03 05:55:27 0: Server started with 31 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 643)
2016.08.03 05:55:27 3: ipc meinfronthem:127.0.0.1:38444 (ws): ws alive with pid 652
2016.08.03 05:55:39 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2016.08.03 05:55:39 0: HMCCU: Child process for server CB2001 started with PID 662
2016.08.03 05:55:39 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001
2016.08.03 05:55:39 0: RPC server(s) starting
2016.08.03 05:55:39 0: CCURPC: Initializing RPC server CB2001
2016.08.03 05:55:39 0: CCURPC: Callback server created listening on port 7401
2016.08.03 05:55:39 1: CCURPC: CB2001 Adding callback for events
2016.08.03 05:55:39 1: CCURPC: CB2001 Adding callback for new devices
2016.08.03 05:55:39 1: CCURPC: CB2001 Adding callback for deleted devices
2016.08.03 05:55:39 1: CCURPC: CB2001 Adding callback for modified devices
2016.08.03 05:55:39 1: CCURPC: CB2001 Adding callback for replaced devices
2016.08.03 05:55:39 1: CCURPC: CB2001 Adding callback for readded devices
2016.08.03 05:55:39 1: CCURPC: CB2001 Adding callback for list devices
2016.08.03 05:55:39 0: CCURPC: CB2001 Entering server loop
2016.08.03 05:55:44 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2016.08.03 05:55:51 1: HMCCU: Registering callback http://192.168.178.52:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.08.03 05:55:51 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2016.08.03 05:55:51 1: HMCCU: RPC callback with URL http://192.168.178.52:7401/fh2001 initialized
2016.08.03 05:55:53 2: CCURPC: CB2001 NewDevice received 226 device specifications
2016.08.03 05:55:56 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.08.03 05:55:57 2: HMCCU: Addr=LEQ0501605:1 Name=Fenster Arbeitszimmer:1
2016.08.03 05:55:57 2: HMCCU: Script response =
Fenster Arbeitszimmer:1=BidCos-RF.LEQ0501605:1.STATE=true
Fenster Arbeitszimmer:1=BidCos-RF.LEQ0501605:1.ERROR=0
Fenster Arbeitszimmer:1=BidCos-RF.LEQ0501605:1.LOWBAT=false
3
2016.08.03 05:55:57 2: HMCCU: Script =
string sDPId;
string sChnName = "Fenster Arbeitszimmer:1";
integer c = 0;
object oChannel = dom.GetObject (sChnName);
if (oChannel) {
foreach(sDPId, oChannel.DPs()) {
object oDP = dom.GetObject(sDPId);
if (oDP) {
if (OPERATION_READ & oDP.Operations()) {
WriteLine (sChnName # "=" # oDP.Name() # "=" # oDP.Value());
c = c+1;
}
}
}
WriteLine (c);
}
2016.08.03 05:55:57 2: HMCCU: Updated devices. Success=18 Failed=0
2016.08.03 05:55:57 1: HMCCU: All RPC servers running
2016.08.03 06:03:59 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 06:12:26 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 06:20:36 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 06:28:57 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 06:37:30 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 06:46:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 06:55:47 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 07:04:19 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 07:14:00 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 07:22:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 07:31:44 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 07:40:35 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 07:50:03 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 08:00:12 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 08:04:03 2: HMCCU: Received unknown event from CCU: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x45 0x56
2016.08.03 08:09:22 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 08:18:46 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 08:28:09 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 08:36:26 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 08:45:47 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 08:55:21 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 09:04:36 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 09:13:42 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 09:22:22 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 09:31:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 09:41:13 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 09:50:14 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 09:59:48 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 10:09:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 10:18:25 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 10:27:00 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 10:36:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 10:45:43 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 10:55:01 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 11:04:09 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 11:13:13 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 11:22:55 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 11:33:02 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 11:42:01 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 11:50:54 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 12:00:16 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 12:09:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 12:17:44 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 12:27:32 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 12:36:35 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 12:46:07 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 12:55:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 13:04:03 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 13:13:44 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 13:22:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 13:31:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 13:40:41 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 13:50:33 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 13:59:59 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 14:09:33 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 14:18:44 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 14:28:00 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 14:37:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 14:46:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 14:55:19 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 15:04:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 15:13:46 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 15:23:00 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 15:32:09 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 15:41:43 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 15:50:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 16:00:31 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 16:08:50 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 16:17:34 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 16:26:34 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 16:35:55 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 16:45:11 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 16:54:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 17:03:44 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 17:13:03 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 17:22:25 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 17:31:42 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 17:40:58 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 17:50:11 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 17:59:32 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 18:08:02 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 18:16:36 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 18:26:28 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 18:36:11 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 18:43:59 1: in ATTR
2016.08.03 18:43:59 1: in ATTR
2016.08.03 18:45:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 18:54:26 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 19:02:53 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 19:12:02 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 19:22:19 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 19:31:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 19:39:19 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 19:47:35 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 19:56:25 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 20:04:33 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 20:13:33 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 20:22:25 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 20:31:53 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 20:40:23 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 20:49:40 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 20:57:48 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 21:07:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 21:17:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 21:25:26 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 21:34:32 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 21:43:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 21:52:25 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 22:02:14 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 22:12:01 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 22:21:33 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 22:30:40 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 22:39:12 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 22:48:28 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 22:58:00 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 23:08:34 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 23:18:12 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 23:27:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 23:36:28 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 23:45:47 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.03 23:54:31 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 00:04:27 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 00:14:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 00:23:54 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 00:32:02 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 00:42:19 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 00:51:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 01:00:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 01:10:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 01:19:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 01:28:05 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 01:37:36 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 01:46:48 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 01:56:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 02:05:44 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 02:15:19 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 02:24:08 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 02:33:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 02:42:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 02:51:46 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 03:00:57 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 03:10:42 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 03:19:02 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 03:28:43 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 03:38:22 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 03:47:14 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 03:56:49 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 04:06:49 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 04:12:02 2: HMCCU: Received unknown event from CCU: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x45 0x56
2016.08.04 04:15:55 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 04:24:54 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 04:34:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 04:42:48 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 04:52:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 05:01:40 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 05:10:44 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 05:20:21 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 05:29:08 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 05:38:30 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 05:47:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 05:56:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 06:05:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 06:06:57 2: HMCCU: Received unknown event from CCU: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x45 0x56
2016.08.04 06:13:36 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 06:21:36 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 06:30:27 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 06:39:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 06:48:31 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 06:56:56 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 07:06:32 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 07:14:58 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 07:24:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 07:33:54 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 07:42:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 07:52:21 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 08:00:42 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 08:10:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 08:19:12 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 08:28:23 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 08:37:31 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 08:46:09 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 08:56:01 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 09:05:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 09:14:02 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 09:23:42 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 09:33:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 09:42:25 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 09:51:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 10:01:13 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 10:11:30 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 10:20:25 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 10:29:15 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 10:38:02 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 10:47:06 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 10:56:57 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 11:05:36 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 11:15:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 11:24:48 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 11:34:15 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 11:43:14 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 11:52:41 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 12:01:26 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 12:10:45 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 12:20:07 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 12:30:02 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 12:38:41 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 12:42:04 2: HMCCU: Received unknown event from CCU: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x45 0x56
2016.08.04 12:48:12 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 12:57:15 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 13:06:25 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 13:15:55 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 13:24:45 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 13:34:13 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 13:43:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 13:52:28 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 14:02:31 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 14:11:15 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 14:20:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 14:30:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 14:39:48 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 14:49:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 14:57:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 15:07:31 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 15:16:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 15:26:14 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 15:35:21 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 15:45:16 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 15:54:42 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 16:03:46 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 16:13:22 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 16:22:23 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 16:32:06 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 16:41:21 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 16:50:43 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 16:59:50 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 17:08:56 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 17:17:41 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 17:27:21 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 17:36:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 17:46:47 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 17:56:58 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 18:05:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 18:15:02 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 18:24:31 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 18:33:47 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 18:42:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 18:52:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 19:01:08 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 19:10:30 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 19:18:23 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 19:27:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 19:36:07 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 19:44:45 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 19:53:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 20:02:09 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 20:11:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 20:20:34 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 20:28:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 20:38:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 20:48:13 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 20:56:53 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 21:05:45 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 21:15:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 21:24:41 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 21:34:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 21:38:41 1: in ATTR
2016.08.04 21:38:41 1: in ATTR
2016.08.04 21:43:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 21:52:44 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 22:01:40 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 22:11:50 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 22:21:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 22:30:27 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 22:40:09 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 22:49:31 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 22:58:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 23:07:23 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 23:17:58 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 23:27:37 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 23:36:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 23:45:44 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.04 23:55:36 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 00:04:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 00:13:35 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 00:23:54 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 00:33:08 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 00:42:11 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 00:51:48 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 01:01:34 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 01:10:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 01:20:45 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 01:29:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 01:32:25 2: HMCCU: Received unknown event from CCU: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x45 0x56
2016.08.05 01:39:25 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 01:48:36 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 01:57:32 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 02:07:36 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 02:17:14 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 02:26:05 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 02:35:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 02:44:44 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 02:53:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 03:03:58 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 03:13:44 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 03:22:40 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 03:30:58 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 03:40:50 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 03:49:50 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 03:59:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 04:08:16 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 04:18:23 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 04:27:08 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 04:36:41 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 04:45:13 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 04:54:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 05:03:50 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 05:12:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 05:21:12 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 05:30:44 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 05:40:35 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 05:50:08 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 05:58:05 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 06:03:05 1: in ATTR
2016.08.05 06:03:05 1: in ATTR
2016.08.05 06:07:05 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 06:16:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 06:25:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 06:34:07 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 06:43:06 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 06:51:46 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 07:01:34 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 07:10:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 07:19:35 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 07:28:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 07:37:50 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 07:46:48 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 07:55:58 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 08:04:58 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 08:14:16 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 08:23:06 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 08:32:32 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 08:41:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 08:50:08 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 08:59:26 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 09:09:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 09:18:00 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 09:27:31 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 09:36:55 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 09:46:02 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 09:55:33 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 10:04:30 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 10:13:22 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 10:22:50 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 10:31:44 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 10:41:12 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 10:50:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 11:00:44 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 11:09:26 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 11:19:16 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 11:28:34 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 11:37:13 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 11:46:13 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 11:56:02 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 12:05:35 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 12:14:40 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 12:22:59 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 12:32:45 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 12:42:09 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 12:51:48 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 13:00:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 13:09:25 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 13:18:28 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 13:28:28 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 13:37:41 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 13:47:45 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 13:55:56 2: HMCCU: Received unknown event from CCU: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x45 0x56
2016.08.05 13:56:23 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 14:05:58 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 14:15:19 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 14:24:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 14:33:47 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 14:43:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 14:51:57 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 15:00:59 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 15:10:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 15:19:19 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 15:28:57 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 15:37:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 15:47:25 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 15:56:35 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 16:05:12 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 16:14:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 16:22:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 16:31:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 16:40:54 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 16:50:12 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 17:00:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 17:08:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 17:18:01 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 17:27:09 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 17:36:13 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 17:44:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 17:53:41 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 18:03:41 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 18:12:37 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 18:22:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 18:31:28 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 18:40:49 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 18:49:14 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 18:58:35 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 19:07:27 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 19:16:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 19:25:49 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 19:34:27 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 19:43:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 19:53:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 20:02:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 20:12:55 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 20:21:23 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 20:30:45 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 20:40:01 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 20:48:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 20:58:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 21:07:53 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 21:17:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 21:25:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 21:33:14 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 21:42:57 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 21:51:45 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 22:00:47 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 22:09:53 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 22:19:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.05 22:33:21 2: HMCCU: Received no events from CCU since 300 seconds
2016.08.06 08:45:43 1: in SAVE
2016.08.06 08:45:43 1: in SAVE
2016.08.06 08:46:04 1: in ATTR
2016.08.06 08:46:04 1: in ATTR
2016.08.06 08:47:32 1: in ATTR
2016.08.06 08:47:32 1: in ATTR
2016.08.06 08:48:50 1: in SAVE
2016.08.06 08:48:50 1: in SAVE
2016.08.06 08:49:30 1: in SAVE
2016.08.06 08:49:30 1: in SAVE
2016.08.06 08:54:07 1: in SHUTDOWN
2016.08.06 08:54:07 1: in SHUTDOWN
2016.08.06 08:54:07 0: Server shutdown
2016.08.06 08:54:07 1: HMCCU: Deregistering RPC server http://192.168.178.52:7401/fh2001 at http://192.168.178.101:2001/
2016.08.06 08:54:07 0: HMCCU: Stopping RPC server CB2001 with PID 662
2016.08.06 08:54:07 0: CCURPC: CB2001 Server loop terminated
2016.08.06 08:54:07 2: CCURPC: Eventcount DD = 0
2016.08.06 08:54:07 2: CCURPC: Eventcount EV = 210485
2016.08.06 08:54:07 2: CCURPC: Eventcount EX = 1
2016.08.06 08:54:07 2: CCURPC: Eventcount IN = 1
2016.08.06 08:54:07 2: CCURPC: Eventcount ND = 226
2016.08.06 08:54:07 2: CCURPC: Eventcount RA = 0
2016.08.06 08:54:07 2: CCURPC: Eventcount RD = 0
2016.08.06 08:54:07 2: CCURPC: Eventcount SL = 1
2016.08.06 08:54:07 2: CCURPC: Eventcount ST = 420
2016.08.06 08:54:07 2: CCURPC: Eventcount UD = 0
2016.08.06 08:54:07 2: CCURPC: Eventcount total = 211134
2016.08.06 08:54:07 2: CCURPC: Eventcount writeerror = 0
2016.08.06 08:54:21 1: Including fhem.cfg
2016.08.06 08:54:21 3: telnetPort: port 7072 opened
2016.08.06 08:54:22 3: WEB: port 8083 opened
2016.08.06 08:54:22 3: WEBphone: port 8084 opened
2016.08.06 08:54:22 3: WEBtablet: port 8085 opened
2016.08.06 08:54:22 2: eventTypes: loaded 238 events from ./log/eventTypes.txt
2016.08.06 08:54:23 2: meinfronthem: ipc listener opened at port 16384
"my" variable $dpt masks earlier declaration in same scope at ./FHEM/88_HMCCU.pm line 1291, <DATA> line 1.
2016.08.06 08:54:43 1: Including ./log/fhem.save
2016.08.06 08:54:43 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.08.06 08:54:43 1: in INITIALIZED
2016.08.06 08:54:43 1: usb create starting
2016.08.06 08:54:44 3: Probing CUL device /dev/ttyAMA0
2016.08.06 08:54:44 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.08.06 08:54:44 1: usb create end
2016.08.06 08:54:44 1: in INITIALIZED
2016.08.06 08:54:44 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.08.06 08:54:44 0: Featurelevel: 5.7
2016.08.06 08:54:44 0: Server started with 31 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 645)
2016.08.06 08:54:44 3: ipc meinfronthem:127.0.0.1:41568 (ws): ws alive with pid 654
2016.08.06 08:54:55 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2016.08.06 08:54:55 0: HMCCU: Child process for server CB2001 started with PID 659
2016.08.06 08:54:55 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001
2016.08.06 08:54:55 0: CCURPC: Initializing RPC server CB2001
2016.08.06 08:54:55 0: RPC server(s) starting
2016.08.06 08:54:56 0: CCURPC: Callback server created listening on port 7401
2016.08.06 08:54:56 1: CCURPC: CB2001 Adding callback for events
2016.08.06 08:54:56 1: CCURPC: CB2001 Adding callback for new devices
2016.08.06 08:54:56 1: CCURPC: CB2001 Adding callback for deleted devices
2016.08.06 08:54:56 1: CCURPC: CB2001 Adding callback for modified devices
2016.08.06 08:54:56 1: CCURPC: CB2001 Adding callback for replaced devices
2016.08.06 08:54:56 1: CCURPC: CB2001 Adding callback for readded devices
2016.08.06 08:54:56 1: CCURPC: CB2001 Adding callback for list devices
2016.08.06 08:54:56 0: CCURPC: CB2001 Entering server loop
2016.08.06 08:55:00 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2016.08.06 08:55:07 1: HMCCU: Registering callback http://192.168.178.52:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.08.06 08:55:08 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2016.08.06 08:55:08 1: HMCCU: RPC callback with URL http://192.168.178.52:7401/fh2001 initialized
2016.08.06 08:55:10 2: CCURPC: CB2001 NewDevice received 226 device specifications
2016.08.06 08:55:13 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.08.06 08:55:13 2: HMCCU: Addr=LEQ0501605:1 Name=Fenster Arbeitszimmer:1
2016.08.06 08:55:13 2: HMCCU: Script response =
Fenster Arbeitszimmer:1=BidCos-RF.LEQ0501605:1.STATE=false
Fenster Arbeitszimmer:1=BidCos-RF.LEQ0501605:1.ERROR=0
Fenster Arbeitszimmer:1=BidCos-RF.LEQ0501605:1.LOWBAT=false
3
2016.08.06 08:55:13 2: HMCCU: Script =
string sDPId;
string sChnName = "Fenster Arbeitszimmer:1";
integer c = 0;
object oChannel = dom.GetObject (sChnName);
if (oChannel) {
foreach(sDPId, oChannel.DPs()) {
object oDP = dom.GetObject(sDPId);
if (oDP) {
if (OPERATION_READ & oDP.Operations()) {
WriteLine (sChnName # "=" # oDP.Name() # "=" # oDP.Value());
c = c+1;
}
}
}
WriteLine (c);
}
2016.08.06 08:55:14 2: HMCCU: Updated devices. Success=18 Failed=0
2016.08.06 08:55:14 1: HMCCU: All RPC servers running
2016.08.06 09:04:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 09:13:07 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 09:22:15 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 09:31:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 09:41:11 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 09:49:36 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 09:57:42 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 10:07:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 10:15:58 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 10:25:15 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 10:33:43 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 10:43:16 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 10:51:27 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 11:01:06 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 11:10:25 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 11:18:40 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 11:28:43 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 11:37:11 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 11:46:55 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 11:55:50 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 12:04:37 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 12:14:45 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 12:22:42 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 12:31:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 12:39:31 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 12:49:01 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 12:57:28 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 13:06:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 13:15:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 13:24:47 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 13:33:12 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 13:17:14 1: Including fhem.cfg
2016.08.06 13:17:14 3: telnetPort: port 7072 opened
2016.08.06 13:17:15 3: WEB: port 8083 opened
2016.08.06 13:17:15 3: WEBphone: port 8084 opened
2016.08.06 13:17:15 3: WEBtablet: port 8085 opened
2016.08.06 13:17:15 2: eventTypes: loaded 238 events from ./log/eventTypes.txt
2016.08.06 13:17:16 2: meinfronthem: ipc listener opened at port 16384
"my" variable $dpt masks earlier declaration in same scope at ./FHEM/88_HMCCU.pm line 1291, <DATA> line 1.
2016.08.06 13:40:54 1: Including ./log/fhem.save
2016.08.06 13:40:54 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.08.06 13:40:54 1: in INITIALIZED
2016.08.06 13:40:54 1: usb create starting
2016.08.06 13:40:55 3: Probing CUL device /dev/ttyAMA0
2016.08.06 13:40:55 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.08.06 13:40:55 1: usb create end
2016.08.06 13:40:55 1: in INITIALIZED
2016.08.06 13:40:55 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.08.06 13:40:55 0: Featurelevel: 5.7
2016.08.06 13:40:55 0: Server started with 31 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 645)
2016.08.06 13:40:55 3: ipc meinfronthem:127.0.0.1:54696 (ws): ws alive with pid 654
2016.08.06 13:41:06 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2016.08.06 13:41:06 0: HMCCU: Child process for server CB2001 started with PID 658
2016.08.06 13:41:06 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001
2016.08.06 13:41:06 0: CCURPC: Initializing RPC server CB2001
2016.08.06 13:41:06 0: RPC server(s) starting
2016.08.06 13:41:07 0: CCURPC: Callback server created listening on port 7401
2016.08.06 13:41:07 1: CCURPC: CB2001 Adding callback for events
2016.08.06 13:41:07 1: CCURPC: CB2001 Adding callback for new devices
2016.08.06 13:41:07 1: CCURPC: CB2001 Adding callback for deleted devices
2016.08.06 13:41:07 1: CCURPC: CB2001 Adding callback for modified devices
2016.08.06 13:41:07 1: CCURPC: CB2001 Adding callback for replaced devices
2016.08.06 13:41:07 1: CCURPC: CB2001 Adding callback for readded devices
2016.08.06 13:41:07 1: CCURPC: CB2001 Adding callback for list devices
2016.08.06 13:41:07 0: CCURPC: CB2001 Entering server loop
2016.08.06 13:41:11 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2016.08.06 13:41:18 1: HMCCU: Registering callback http://192.168.178.52:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.08.06 13:41:19 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2016.08.06 13:41:19 1: HMCCU: RPC callback with URL http://192.168.178.52:7401/fh2001 initialized
2016.08.06 13:41:21 2: CCURPC: CB2001 NewDevice received 226 device specifications
2016.08.06 13:41:24 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.08.06 13:41:25 2: HMCCU: Addr=LEQ0501605:1 Name=Fenster Arbeitszimmer:1
2016.08.06 13:41:25 2: HMCCU: Script response =
Fenster Arbeitszimmer:1=BidCos-RF.LEQ0501605:1.STATE=true
Fenster Arbeitszimmer:1=BidCos-RF.LEQ0501605:1.ERROR=0
Fenster Arbeitszimmer:1=BidCos-RF.LEQ0501605:1.LOWBAT=false
3
2016.08.06 13:41:25 2: HMCCU: Script =
string sDPId;
string sChnName = "Fenster Arbeitszimmer:1";
integer c = 0;
object oChannel = dom.GetObject (sChnName);
if (oChannel) {
foreach(sDPId, oChannel.DPs()) {
object oDP = dom.GetObject(sDPId);
if (oDP) {
if (OPERATION_READ & oDP.Operations()) {
WriteLine (sChnName # "=" # oDP.Name() # "=" # oDP.Value());
c = c+1;
}
}
}
WriteLine (c);
}
2016.08.06 13:41:25 2: HMCCU: Updated devices. Success=18 Failed=0
2016.08.06 13:41:25 1: HMCCU: All RPC servers running
2016.08.06 13:50:35 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 13:58:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 14:01:02 2: HMCCU: Received unknown event from CCU: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x45 0x56
2016.08.06 14:06:47 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 14:16:05 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 14:24:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 14:34:30 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 14:42:42 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 14:50:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 14:59:31 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 15:07:41 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 15:16:53 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 15:25:36 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 15:33:58 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 15:42:50 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 15:51:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 16:00:53 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 16:09:54 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 16:18:14 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 16:27:43 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 16:35:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 16:44:22 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 16:53:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 17:02:06 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 17:10:43 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 17:19:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 17:28:23 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 17:36:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 17:46:05 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 17:54:16 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 18:03:43 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 18:12:12 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 18:21:22 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 18:30:25 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 18:39:30 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 18:47:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 18:56:37 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 19:05:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 19:14:43 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 19:22:53 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 19:32:22 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 19:42:07 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 19:50:56 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 19:59:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 20:07:55 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 20:16:40 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 20:25:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 20:35:11 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 20:42:55 2: HMCCU: Received unknown event from CCU: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x45 0x56
2016.08.06 20:44:14 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 20:53:22 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 21:00:55 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 21:09:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 21:18:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 21:26:37 3: CCURPC: CB2001 Received 500 events from CCU since last check
2016.08.06 21:33:16 2: HMCCU: Received no events from CCU since 300 seconds
Die Aktualisierung der Reading erfolgt eher "sporadisch". Aktuell z.B. gar nicht mehr.
Hast Du eine Idee für mich?
So sieht das Log auf der CCU aus:
Aug 6 19:23:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 19:24:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25809 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:25:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25817 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:26:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25825 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:27:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25838 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:28:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25846 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:28:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 19:29:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25854 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:30:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25864 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:31:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25872 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:32:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25880 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:33:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25888 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:33:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 19:34:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25896 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:35:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25904 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:36:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25912 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:37:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25920 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:38:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25928 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:38:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 19:39:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25936 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:40:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25949 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:41:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25959 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:42:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25967 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:43:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25975 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:43:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 19:44:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25983 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:45:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25991 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:45:02 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","LEQ0002140:1","TEMPERATURE",24.600000}],[methodName:"event",params:{"CB2001","LEQ0002140:1","HUMIDITY",55}]}) on http://192.168.178.52:7401/fh2001:
Aug 6 19:45:02 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 19:45:22 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","KEQ0011779:2","ADJUSTING_COMMAND",0}],[methodName:"event",params:{"CB2001","KEQ0011779:2","ADJUSTING_DATA",0}],[methodName:"event",params:{"CB2001","KEQ001409
Aug 6 19:45:22 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 19:46:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 25999 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:47:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26007 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:48:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26015 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:48:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 19:49:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26023 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:50:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26031 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:51:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26039 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:52:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26047 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:52:22 homematic-ccu2 daemon.info cuxd[322]: rename '/tmp/devlog.txt' -> '/tmp/devlog.txt.0'
Aug 6 19:52:23 homematic-ccu2 daemon.info cuxd[26055]: move '/tmp/devlog.txt.0' -> '/tmp/sd/cuxd/devlog/devlog.txt.20160806-1952'
Aug 6 19:53:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26056 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:53:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 19:54:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26064 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:55:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26073 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:56:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26081 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:57:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26093 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:58:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26103 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:58:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 19:59:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26111 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:00:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26119 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:01:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26127 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:02:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26135 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:03:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26143 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:03:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 20:04:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26151 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:05:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26164 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:06:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26172 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:07:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26182 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:08:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26190 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:08:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 20:09:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26198 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:10:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26206 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:11:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26214 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:12:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26222 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:13:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26230 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:13:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 20:14:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26238 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:15:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26247 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:16:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26255 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:17:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26263 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:18:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26271 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:18:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 20:19:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26279 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:20:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26288 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:21:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26300 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:22:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26310 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:23:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26318 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:23:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 20:23:48 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","JEQ0268572:1","TEMPERATURE",17.400000}]}) on http://192.168.178.52:7401/fh2001:
Aug 6 20:23:48 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 20:24:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26326 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:25:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26334 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:25:37 homematic-ccu2 daemon.info cuxd[322]: rename '/tmp/devlog.txt' -> '/tmp/devlog.txt.0'
Aug 6 20:25:39 homematic-ccu2 daemon.info cuxd[26342]: move '/tmp/devlog.txt.0' -> '/tmp/sd/cuxd/devlog/devlog.txt.20160806-2025'
Aug 6 20:26:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26343 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:27:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26351 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:28:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26359 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:28:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 20:29:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26367 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:30:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26376 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:31:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26390 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:31:15 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","HEQ0508540:2","ADJUSTING_COMMAND",0}],[methodName:"event",params:{"CB2001","HEQ0508540:2","ADJUSTING_DATA",0}]}) on http://192.168.178.52:7401/fh2001:
Aug 6 20:31:15 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 20:32:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26398 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:33:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26406 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:33:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 20:34:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26414 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:35:02 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26422 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:36:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26430 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:37:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26438 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:38:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26446 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:38:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 20:39:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26454 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:40:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26462 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:41:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26470 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:42:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26485 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:43:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26493 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:43:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 20:44:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26501 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:45:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26509 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:46:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26517 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:47:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26525 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:48:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26533 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:48:17 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","KEQ0519697:4","CONTROL_MODE",1}],[methodName:"event",params:{"CB2001","KEQ0519697:4","FAULT_REPORTING",0}],[methodName:"event",params:{"CB2001","KEQ0519697:4"
Aug 6 20:48:17 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 20:48:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 20:49:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26541 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:50:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26549 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:51:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26557 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:52:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26565 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:53:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26574 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:53:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 20:54:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26586 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:55:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26596 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:56:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26604 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:57:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26612 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:58:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26620 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:58:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 20:59:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26628 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 20:59:08 homematic-ccu2 daemon.info cuxd[322]: rename '/tmp/devlog.txt' -> '/tmp/devlog.txt.0'
Aug 6 20:59:10 homematic-ccu2 daemon.info cuxd[26636]: move '/tmp/devlog.txt.0' -> '/tmp/sd/cuxd/devlog/devlog.txt.20160806-2059'
Aug 6 21:00:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26637 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:01:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26645 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:02:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26653 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:03:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26666 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:03:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 21:04:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26676 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:05:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26684 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:06:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26692 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:07:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26700 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:08:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26709 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:08:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 21:09:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26717 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:10:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26725 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:11:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26733 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:12:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26741 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:13:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26749 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:13:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 21:14:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26759 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:15:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26770 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:16:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26783 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:17:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26793 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:18:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26801 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:18:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 21:19:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26810 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:20:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26818 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:21:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26826 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:22:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26834 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:23:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26842 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:23:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 21:24:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26850 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:25:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26858 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:26:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26866 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:27:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26874 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:28:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26882 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:28:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 21:28:43 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","LEQ0002140:1","TEMPERATURE",24.000000}]}) on http://192.168.178.52:7401/fh2001:
Aug 6 21:28:43 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 21:29:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26895 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:29:03 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","LEQ0002140:1","HUMIDITY",54}],[methodName:"event",params:{"CB2001","IEQ0171822:2","ADJUSTING_COMMAND",0}],[methodName:"event",params:{"CB2001","IEQ0171822:2",
Aug 6 21:29:03 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 21:29:23 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","LEQ0081955:2","ACTUAL_TEMPERATURE",19.400000}],[methodName:"event",params:{"CB2001","LEQ0081955:2","ACTUAL_HUMIDITY",67.000000}],[methodName:"event",params:{"
Aug 6 21:29:23 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 21:29:44 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","LEQ0081955:1","TEMPERATURE",19.400000}],[methodName:"event",params:{"CB2001","LEQ0081955:1","HUMIDITY",68}],[methodName:"event",params:{"CB2001","HEQ0508540:2
Aug 6 21:29:44 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 21:30:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26903 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:30:02 homematic-ccu2 user.err rfd: HSSParameter::SetValue() 1.000000 Put failed
Aug 6 21:30:02 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::CallXmlrpcMethod: execute result isFault; method =setValue Params = {"LEQ0276309:1","LEVEL",1.000000} result= [faultCode:-1,faultString:"Failure"] [../Platform/DOM/iseXmlRpc.cpp (2627)]
Aug 6 21:30:02 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::CallSetValue: CallXmlrpcMethod failed [../Platform/DOM/iseXmlRpc.cpp (1517)]
Aug 6 21:30:02 homematic-ccu2 local0.err ReGaHss: Error: IseHssDP::WriteValue: CallSetValue failed; address = LEQ0276309:1 [../Platform/DOM/iseDOMdpHSS.cpp (77)]
Aug 6 21:30:04 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","JEQ0268572:1","TEMPERATURE",16.400000}],[methodName:"event",params:{"CB2001","JEQ0268572:1","HUMIDITY",83}],[methodName:"event",params:{"CB2001","KEQ0729410:4
Aug 6 21:30:04 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 21:30:24 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","HEQ0510129:1","TEMPERATURE",21.800000}],[methodName:"event",params:{"CB2001","HEQ0510129:1","HUMIDITY",65}],[methodName:"event",params:{"CB2001","LEQ0276309:0
Aug 6 21:30:24 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 21:30:44 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","LEQ0276309:0","UNREACH",false}],[methodName:"event",params:{"CB2001","LEQ0276309:1","LEVEL",1.000000}],[methodName:"event",params:{"CB2001","LEQ0276309:1","WO
Aug 6 21:30:44 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 21:31:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26912 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:31:04 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","MEQ0723323:1","STATE",false}],[methodName:"event",params:{"CB2001","MEQ0723323:1","LOWBAT",false}],[methodName:"event",params:{"CB2001","MEQ0723323:1","LOWBAT
Aug 6 21:31:04 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 21:31:24 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","KEQ0519697:4","CONTROL_MODE",1}],[methodName:"event",params:{"CB2001","KEQ0519697:4","FAULT_REPORTING",0}],[methodName:"event",params:{"CB2001","KEQ0519697:4"
Aug 6 21:31:24 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 21:31:44 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","IEQ0171822:1","TEMPERATURE",22.100000}],[methodName:"event",params:{"CB2001","IEQ0171822:1","HUMIDITY",63}],[methodName:"event",params:{"CB2001","KEQ0733480:4
Aug 6 21:31:44 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 21:32:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26920 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:32:04 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","IEQ0171822:2","ADJUSTING_COMMAND",0}],[methodName:"event",params:{"CB2001","IEQ0171822:2","ADJUSTING_DATA",0}],[methodName:"event",params:{"CB2001","JEQ022172
Aug 6 21:32:04 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 6 21:32:04 homematic-ccu2 daemon.info cuxd[322]: rename '/tmp/devlog.txt' -> '/tmp/devlog.txt.0'
Aug 6 21:32:06 homematic-ccu2 daemon.info cuxd[26928]: move '/tmp/devlog.txt.0' -> '/tmp/sd/cuxd/devlog/devlog.txt.20160806-2132'
Aug 6 21:32:16 homematic-ccu2 daemon.warn openvpn[426]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Aug 6 21:33:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26929 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:33:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 21:34:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26942 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:35:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26950 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:36:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26958 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:37:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26966 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:38:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26974 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:38:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 21:39:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26982 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:40:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26990 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:41:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 26998 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:42:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27013 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:43:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27021 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:43:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 21:44:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27029 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:45:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27037 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:46:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27045 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:47:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27053 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:48:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27078 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:48:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 21:49:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27099 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:49:20 homematic-ccu2 auth.info sshd[27107]: Accepted password for root from 192.168.178.95 port 49481 ssh2
Aug 6 21:50:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27125 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:50:18 homematic-ccu2 auth.info sshd[27138]: Accepted password for root from 192.168.178.95 port 49498 ssh2
Aug 6 19:50:18 homematic-ccu2 auth.info sshd[27138]: subsystem request for sftp by user root
Aug 6 21:51:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27158 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:52:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27182 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:53:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27201 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:53:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 6 19:53:45 homematic-ccu2 auth.info sshd[27107]: Received disconnect from 192.168.178.95: 11: disconnected by user
Aug 6 21:54:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27209 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:55:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27218 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:56:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27226 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:57:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27241 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 21:58:01 homematic-ccu2 cron.info crond[94]: crond: USER root pid 27249 cmd /bin/sh /usr/local/etc/config/addons/mh/cloudmaticcheck.sh >> /dev/null
Aug 6 19:58:09 homematic-ccu2 auth.info sshd[27257]: Accepted password for root from 192.168.178.95 port 49673 ssh2
Aug 6 21:58:26 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A000035229933B70 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Zitat von: chris1284 am 06 August 2016, 19:56:44
weiss einer wie ich den thermostaten (rt-dn) auf manu setzen kann und er die aktuelle / letzte manu-temp setzt?
beispiel
-er ist im manu mit temp x
-dann schalte ich auto und er nimmt nat. die für die zeit definierte autotemp
-dann will ich manu setzen und er soll wieder temp x fahren
manuel wechsel würde ich rt nur den modus wechseln ohne was am rad zu drehen. unter cul_hm würde ich nur set manu sagen ohne eine temp anzugeben. in der ccu nur den mode manu button drücken ohne eine temp anzugeben. hmccudev verlangt nach 4.MODE_MANU aber einen {value} so das ich immer was angeben muss (gibt man blödsin ein wie true oder 1 geht der rt auf OFF).
aus der scriptdocu entnehme ich nur das der value float sein muss. gibts da nen trick oder wie macht die ccu/der rt das intern?
Ich kann nur vermuten, dass sich die CCU den zuletzt eingestellten Wert merkt. Wie Du schon erkannt hast, muss man beim Datenpunkt MANU_MODE immer eine Temperatur angeben. Dabei ist ein Wert < 5 Grad = Off und ein Wert > 30 Grad = On. Daher wird das Thermostat bei true/1 auf off gesetzt. Bist Du sicher, dass bei CUL_HM temp x und nicht temp y bei Reaktivierung des manuellen Modus gesetzt wird?
definitiv ein
set controlMode manual
im climachannel brachte den rt auf manu mit der letzten temp des manumode
mit
set controlManu 15.0
konnte man manu + ttemp einstellen
Zitat von: chris1284 am 07 August 2016, 13:20:36
set controlManu 15.0
konnte man manu + ttemp einstellen
Du kannst in HMCCU mit eventMap einiges simulieren (Kanalnummern anpassen, die unten sind für ein Gruppendevice):
attr xy eventMap /datapoint 1.MANU_MODE 20.0:Manu/datapoint 1.AUTO_MODE 1:Auto/datapoint 1.BOOST_MODE 1:Boost/datapoint 1.MANU_MODE 4.5:off/datapoint 1.MANU_MODE 30.5:on/
Ich habe mir den Code von CUL_HM mal angeschaut. Bei controlMode manu wird einfach der Wert des Readings "desired-temp" gesetzt. Auch das lässt sich per eventMap realisieren, sofern das Perl-Code unterstützt (dann einfach ein {ReadingsVal()} für das SET_TEMPERATURE Reading einfügen.
Hallo zap,
Ich habe jetzt die ccu nochmal neu gestartet, leider "muckt" der RPC immer noch :-(
Gesendet von meinem GT-I9505 mit Tapatalk
Ist Dein FHEM-Rechner per WLAN angebunden oder per Kabel? So auf die Schnelle sieht mir das nach Kommunikationsproblemen aus.
Per Kabel . Kann man die Kommunikation irgendwie prüfen?
Gesendet von meinem GT-I9505 mit Tapatalk
Verwendest Du den internen RPC Server oder ccurpcd.pl? Wenn Du die aktuelle Version von HMCCU verwendest, einfach das Attribut ccuflags im IODevice löschen. Falls Du eine ältere verwendest, das Attribut ccuflags auf intrpc setzen.
Dann den RPC Server stoppen, prüfen dass kein ccurpcd.pl mehr läuft und wieder starten. Dann wird für jeden Eintrag in rpcport ein neuer FHEM Prozess gestartet (der RPC Server).
Wie bekomme ich denn raus welchen RPC Server ich nutze. Habe einfach alles aus dem download nach /FHEM kopiert. ...
Gesendet von meinem GT-I9505 mit Tapatalk
Hallo zap,
so ganz werde ich noch nicht schlau.
Ich habe die aktuellste Version - also gehe ich mal vom internen RPC Server aus.
Das Attribut ccuflags ist bei mir nicht gesetzt. Soll ich hier mal irgendeinen Wert erfassen?
Ich habe es mal mit pi@linado_home:~ $ ps aux | grep ccurpcd.pl
pi 5877 0.0 0.1 4612 1848 pts/0 S+ 20:49 0:00 grep --color=auto ccurpcd.pl
und dann
pi@linado_home:~ $ sudo kill 5877
probiert.
Da wird dann aber imm sofort eine neue Instanz erstellt:
pi@linado_home:~ $ ps aux | grep ccurpcd.pl
pi 5891 0.0 0.1 4612 1844 pts/0 S+ 20:51 0:00 grep --color=auto ccurpcd.pl
pi@linado_home:~ $ ps aux | grep ccurpcd.pl
pi 5893 0.0 0.1 4612 1844 pts/0 S+ 20:52 0:00 grep --color=auto ccurpcd.pl
pi@linado_home:~ $ ps aux | grep ccurpcd.pl
pi 5895 0.0 0.1 4612 1744 pts/0 S+ 20:52 0:00 grep --color=auto ccurpcd.pl
pi@linado_home:~ $ ps aux | grep ccurpcd.pl
pi 5897 0.0 0.1 4612 1824 pts/0 S+ 20:52 0:00 grep --color=auto ccurpcd.pl
p
Du verwendest den internen. Das was Du bei ps siehst ist der grep Befehl selbst. Siehe auch
ps aux | grep ccurpcd | grep -v grep
Dann gibt es keine Ausgabe.
Aber ein "ps aux | grep fhem" sollte mindestens 2 fhem.pl Prozesse liefern. Einmal der normale und einmal der geforkte RPC Prozess. Wenn Du im Attribut rpcport mehrere Ports angegeben hast, entsprechend mehr fhem Prozesse.
Ich muss mir Deine Logs morgen mal in Ruhe anschauen. Auf den ersten Blick sieht alles ok aus. Bei mir läuft der RPC Server (3 Prozesse) wochenlang ohne Probleme.
Hallo zap,
folgendes bringt ps aux:
pi@linado_home:~ $ ps aux | grep fhem
fhem 5969 0.2 3.7 40920 35964 ? S Aug07 1:07 /usr/bin/perl fhem.pl fhem.cfg
fhem 5970 0.0 1.5 19320 14828 ? Ss Aug07 0:01 /usr/bin/perl fhem.pl fhem.cfg
fhem 5974 0.6 3.8 41896 36116 ? S Aug07 3:11 /usr/bin/perl fhem.pl fhem.cfg
pi 7396 0.0 0.1 4612 1844 pts/0 S+ 06:02 0:00 grep --color=auto fhem
also drei Prozesse.
Wenn bei Dir im FHEM Log die Meldung kommt:
2016.08.06 21:33:16 2: HMCCU: Received no events from CCU since 300 seconds
dann häufen sich in Deiner CCU die Meldungen:
Aug 6 21:29:03 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","LEQ0002140:1","HUMIDITY",54}],[methodName:"event",params:{"CB2001","IEQ0171822:2","ADJUSTING_COMMAND",0}],[methodName:"event",params:{"CB2001","IEQ0171822:2",
Aug 6 21:29:03 homematic-ccu2 user.err rfd: XmlRpc transport error
Das heißt: Die CCU möchte ein Update für einen Datenpunkt an FHEM schicken. Das klappt aber nicht ("transport error"). Bleibt noch die Frage nach der Ursache ...
Fragen:
Welche Firmware Version hat Deine CCU?
Gibt es im Systemlog /var/log/messages zur gleichen Zeit irgendwelche Fehlermeldungen?
In Deinem /tmp Verzeichnis ist genug Platz?
Firmware: 2.19.9
Speicher in /tmp auf der CCU:
# df /tmp
Filesystem Size Used Available Use% Mounted on
tmpfs 124.7M 180.0K 124.5M 0% /tmp
#
Das Log von /var/log/messages habe ich ja schon geposted.
/tmp auf dem fhem server:pi@linado_home:~ $ sudo df /tmp
Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/root 30337356 1858436 27216812 7% /
pi@linado_home:~ $
Hilft Dir das weiter?
Die Firmware ist ziemlich alt, 2.21.10 ist aktuell. Wird aber vermutlich nicht helfen, da es mit Deiner Version bei mir auch schon gelaufen ist.
Ich meinte nicht das messages File der CCU sondern das das FHEM Servers.
Aber wenn da keine Fehlermeldungen drinnstehen, bringt das nichts. Wäre eh nur ein Strohhalm gewesen.
Läuft auf dem FHEM Server noch irgendwas anderes neben FHEM, evtl eine andere Software, die sich an die CCU andockt?
auf dem FHEM Server läuft nur FHEM, Smartvisu und Fronthem.
Kann man irgendwie überprüfen, ob es Kommunikationsprobleme gibt?
Zitat von: Nic0205 am 08 August 2016, 20:44:09
auf dem FHEM Server läuft nur FHEM, Smartvisu und Fronthem.
Kann man irgendwie überprüfen, ob es Kommunikationsprobleme gibt?
Naja, "xmlrpc transport error" sind definitiv Kommunikationsprobleme. Die Frage ist: was ist die Ursache? Und warum funktioniert es eine Zeit lang und dann plötzlich nicht mehr.
Der RPC Server nimmt anscheinend keine Requests mehr entgegen. Was Du noch prüfen könntest: Wenn mal wieder dieser Effekt auftritt (viele Transport Errors in /var/log/messages auf der CCU und die Meldung, dass seit 300 Sekunden keine Events mehr kamen im fhem.log): Läuft der RPC Server überhaupt noch? D.h. "ps aux | grep fhem". Die ProzessIDs mit dem abgleichen, was in FHEM im IO Device im Internal RPCPID angezeigt wird.
Ich habe es nun endlich geschafft, dass define <name> HMCCU <hostname_or_IP> nicht mit irgendeiner Fehlermeldung quittiert wird und der DeviceOverview geladen wird. (es lag an fehlerhaft heruntergeladenen Dateien)
Aber was mache ich jetzt? Aus der Anleitung im .txt werde ich nicht schlau. Gibt es irgendwo eine Anleitung für noobs wie mich? Ich habe keine Ahnung, was ich nun als nächstes machen muss.
Gruß
Daniel
Zitat von: xxxONURISxxx am 08 August 2016, 22:47:00
Aber was mache ich jetzt? Aus der Anleitung im .txt werde ich nicht schlau. Gibt es irgendwo eine Anleitung für noobs wie mich? Ich habe keine Ahnung, was ich nun als nächstes machen muss.
Als nächstes musst Du für die CCU Geräte und Kanäle, die Du in FHEM haben möchtest, mit Hilfe von HMCCUDEV und HMCCUCHN Client Devices in FHEM anlegen. Einige Beispiele findest Du hier:
https://forum.fhem.de/index.php/topic,51339.0.html
Danach wäre es ratsam, den RPC-Server zu starten (set rpcserver on), damit die neu angelegten Client Devices mit Daten aus der CCU versorgt werden. Vorher solltest Du noch das Attribut rpcport auf die Liste der Schnittstellen setzen, die Deine CCU verwendet (also BidCos, HM-IP oder Wired).
Wenn ich mal die Zeit finde, werde ich den ein oder anderen Wiki Artikel schreiben. Momentan bin ich aber mit der neuen Version beschäftigt.
Habe ein Update von 88_HMCCU.pm im Contrib Zweig eingecheckt. Gab leider einen Bug beim Update von Readings in bestimmten Konstellationen.
Eine Warnung bzgl. der aktuellen CCU2 Firmware 2.21.10: Mit dieser Version wird für Homematic IP Komponenten der Kanal 0 hinzugefügt. Das hat zumindest bei mir dazu geführt, dass einige der anderen Kanäle von HM-IP Schaltsteckdosen auf ihren Default Namen zurück gesetzt wurden. Dadurch konnte ich in HMCCU nicht mehr darauf zugreifen. Nach Korrektur der Namen auf den alten Stand vor dem Update hat wieder alles funktioniert.
Update auf Homematic CCU-Version 2.21.10 scheitert
Leider konnte mir die ELV-Hotline bisher nicht weiterhelfen, daher mal hier die Frage, ob dieses Problem bei euch bekannt ist.... Im Logfile der CCU2 finde ich jede Menge Einträge.... Sagt das Euch was?
Aug 15 12:09:39 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::GetObjectByHSSAddress: no exists device object with address= 3014F711A0000353C9952FD2 [../Platform/DOM/iseXmlRpc.cpp (2166)]
Aug 15 12:13:24 homematic-ccu2 user.warn kernel: [1866655.750000] tclsh invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.760000] Backtrace:
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.760000] [<c000bc20>] (dump_backtrace+0x0/0x110) from [<c02a783c>] (dump_stack+0x18/0x1c)
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.770000] r6:cf9ee300 r5:00000000 r4:c2572000 r3:00000002
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.770000] [<c02a7824>] (dump_stack+0x0/0x1c) from [<c02a86f4>] (dump_header.isra.14+0x8c/0x1a4)
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.780000] [<c02a8668>] (dump_header.isra.14+0x0/0x1a4) from [<c0083814>] (oom_kill_process+0x80/0x2b4)
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.790000] [<c0083794>] (oom_kill_process+0x0/0x2b4) from [<c0083e84>] (out_of_memory+0x160/0x210)
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.800000] [<c0083d24>] (out_of_memory+0x0/0x210) from [<c0086fd8>] (__alloc_pages_nodemask+0x598/0x6ec)
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.810000] [<c0086a40>] (__alloc_pages_nodemask+0x0/0x6ec) from [<c00827f4>] (filemap_fault+0x2dc/0x400)
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.820000] [<c0082518>] (filemap_fault+0x0/0x400) from [<c0098964>] (__do_fault+0xc4/0x4b8)
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.830000] [<c00988a0>] (__do_fault+0x0/0x4b8) from [<c009b12c>] (handle_pte_fault+0x2a4/0xc8c)
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.840000] [<c009ae88>] (handle_pte_fault+0x0/0xc8c) from [<c009bbdc>] (handle_mm_fault+0xc8/0xdc)
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.850000] [<c009bb14>] (handle_mm_fault+0x0/0xdc) from [<c02aefc8>] (do_page_fault+0x184/0x3c0)
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.860000] [<c02aee44>] (do_page_fault+0x0/0x3c0) from [<c0008608>] (do_DataAbort+0x3c/0xa0)
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.870000] [<c00085cc>] (do_DataAbort+0x0/0xa0) from [<c02ad880>] (__dabt_usr+0x40/0x60)
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.880000] Exception stack(0xc2573fb0 to 0xc2573ff8)
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.880000] 3fa0: 006fe0d1 00000072 b6f17524 00000002
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.890000] 3fc0: 006f6640 00000004 b6f1751c 00000000 ffffffff b6f05f24 006fe0d0 b6f171e4
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.900000] 3fe0: b6f14a58 beb1c548 00000069 b6ed6940 a0000010 ffffffff
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.900000] r7:00000000 r6:ffffffff r5:a0000010 r4:b6ed6940
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.910000] Mem-info:
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.910000] Normal per-cpu:
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.920000] CPU 0: hi: 90, btch: 15 usd: 68
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.920000] active_anon:20856 inactive_anon:39427 isolated_anon:0
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.920000] active_file:14 inactive_file:21 isolated_file:0
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.920000] unevictable:0 dirty:0 writeback:0 unstable:0
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.920000] free:712 slab_reclaimable:427 slab_unreclaimable:1055
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.920000] mapped:31 shmem:42768 pagetables:274 bounce:0
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.950000] Normal free:2848kB min:2036kB low:2544kB high:3052kB active_anon:83424kB inactive_anon:157708kB active_file:56kB inactive_file:84kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:260096kB mlocked
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.990000] lowmem_reserve[]: 0 0
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866655.990000] Normal: 148*4kB 34*8kB 24*16kB 14*32kB 6*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 2848kB
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866656.010000] 42803 total pagecache pages
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866656.020000] 65536 pages of RAM
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866656.030000] 1070 free pages
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866656.030000] 1688 reserved pages
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866656.030000] 1125 slab pages
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866656.040000] 129 pages shared
Aug 15 12:13:25 homematic-ccu2 user.warn kernel: [1866656.040000] 0 pages swap cached
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.040000] [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.050000] [ 94] 0 94 616 26 0 0 0 crond
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.060000] [ 98] 0 98 595 14 0 0 0 syslogd
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.070000] [ 100] 0 100 595 17 0 0 0 klogd
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.070000] [ 103] 0 103 722 96 0 -17 -1000 udevd
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.080000] [ 139] 0 139 693 67 0 -17 -1000 udevd
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.090000] [ 140] 0 140 693 70 0 -17 -1000 udevd
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.100000] [ 141] 0 141 562 13 0 0 0 watchdog
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.100000] [ 150] 0 150 595 16 0 0 0 udhcpd
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.110000] [ 268] 0 268 595 16 0 0 0 udhcpc
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.120000] [ 274] 0 274 494 22 0 0 0 ifplugd
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.130000] [ 302] 0 302 934 31 0 0 0 eq3configd
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.140000] [ 303] 0 303 928 30 0 0 0 ssdpd
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.140000] [ 313] 0 313 956 38 0 0 0 ntpclient
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.150000] [ 319] 0 319 1348 313 0 0 0 lighttpd
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.160000] [ 324] 0 324 1072 62 0 -17 -1000 sshd
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.170000] [ 362] 0 362 1353 52 0 0 0 multimacd
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.180000] [ 378] 0 378 4546 2126 0 0 0 rfd
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.180000] [ 384] 0 384 51154 11604 0 0 0 java
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.190000] [ 468] 0 468 4365 1744 0 0 0 ReGaHss
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.200000] [ 470] 0 470 992 35 0 0 0 hss_led
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.210000] [ 490] 0 490 596 15 0 0 0 getty
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.220000] [ 491] 0 491 596 15 0 0 0 getty
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.220000] [25507] 0 25507 1245 239 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.230000] [25508] 0 25508 1011 48 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.240000] [25509] 0 25509 780 47 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.250000] [25510] 0 25510 780 48 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.250000] [25511] 0 25511 1011 48 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.260000] [25512] 0 25512 1011 51 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.270000] [25513] 0 25513 780 47 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.280000] [25514] 0 25514 780 48 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.280000] [25515] 0 25515 780 47 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.290000] [25516] 0 25516 780 48 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.300000] [25517] 0 25517 780 47 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.310000] [25518] 0 25518 780 47 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.320000] [25519] 0 25519 780 46 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.320000] [25520] 0 25520 780 34 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.330000] [25521] 0 25521 780 47 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.340000] [25522] 0 25522 780 46 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.350000] [25523] 0 25523 780 47 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.350000] [25524] 0 25524 780 47 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.360000] [25525] 0 25525 780 47 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.370000] [25526] 0 25526 780 47 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.380000] [25527] 0 25527 1011 48 0 0 0 tclsh
Aug 15 12:13:25 homematic-ccu2 user.err kernel: [1866656.390000] Out of memory: Kill process 384 (java) score 152 or sacrifice child
Aug 15 12:13:25 homematic-ccu2 user.err kernel: [1866656.390000] Killed process 384 (java) total-vm:204616kB, anon-rss:46344kB, file-rss:72kB
Aug 15 12:13:25 homematic-ccu2 user.info kernel: [1866656.560000] eq3loop: eq3loop_close_slave() ttyS0
Aug 15 12:13:26 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF_java","MEQ0690196:1","FILLING_LEVEL",32}]}) on http://127.0.0.1:9292/bidcos:
Aug 15 12:13:26 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 15 12:13:26 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF_java","NEQ0322390:1","LUX",9757.770000}]}) on http://127.0.0.1:9292/bidcos:
Aug 15 12:13:26 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 15 12:14:36 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF_java","LEQ0532520:2","BOOT",true}]}) on http://127.0.0.1:9292/bidcos:
Aug 15 12:14:36 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 15 12:14:36 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF_java","LEQ0532520:2","ENERGY_COUNTER",1988.600000}]}) on http://127.0.0.1:9292/bidcos:
Aug 15 12:14:36 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 15 12:14:36 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF_java","LEQ0532520:2","POWER",0.000000}],[methodName:"event",params:{"BidCos-RF_java","LEQ0532520:2","CURRENT",0.000000}],[methodName:"event",params:{"BidCos-
Aug 15 12:14:36 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 15 12:14:51 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF_java","LEQ0533049:2","BOOT",true}],[methodName:"event",params:{"BidCos-RF_java","LEQ0533049:2","ENERGY_COUNTER",0.800000}],[methodName:"event",params:{"BidCo
Aug 15 12:14:51 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 15 12:15:51 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF_java","NEQ0322390:1","LUX",1856.140000}]}) on http://127.0.0.1:9292/bidcos:
Aug 15 12:15:51 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 15 12:16:53 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF_java","LEQ0532520:2","BOOT",true}],[methodName:"event",params:{"BidCos-RF_java","LEQ0532520:2","ENERGY_COUNTER",1988.600000}],[methodName:"event",params:{"Bi
Aug 15 12:16:53 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 15 12:16:53 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF_java","LEQ0532520:2","VOLTAGE",239.200000}]}) on http://127.0.0.1:9292/bidcos:
Aug 15 12:16:53 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 15 12:16:53 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF_java","LEQ0532520:2","FREQUENCY",49.990000}]}) on http://127.0.0.1:9292/bidcos:
Aug 15 12:16:53 homematic-ccu2 user.err rfd: XmlRpc transport error
Aug 15 15:01:47 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 97 0x61 [1] 0 0x00 [2] 99 0x63 [3] 0 0x00 [4] 100 0x64 [../Platform/DOM/iseESPexec.cpp (11622)]
im notfall würde ich ein backup machen, ccu reset, updatem, backup wieder einspielen
was hats du den bereits mit dem elv support probiert? so sachen wie reboot denke ich schon oder?
Also bei mir hat dieses Update auch gezickt. Musste 2x Booten, erst dann hat alles funktioniert. Trotzdem habe ich gelegentlich Fehlermeldungen im messages File. Scheint wieder mal ein Gurken-Release von EQ-3 zu sein. Habe es nur drauf gelassen wg. Support des neuen Lichtsensors und wegen dem Statuskanal bei Homematic IP.
Spiel doch die alte Version ein und warte, bis ein Update kommt. Hast Du schon mal im Homematic Forum gefragt?
Hier gibts 30 Seiten Lesestoff:
http://homematic-forum.de/forum/viewtopic.php?f=26&t=31892
Hallo Jungs,
danke für die Tipps. Ich habe die Variante von chris1284 ausprobiert und war erfolgreich. Die Hotline hatte mir das so nicht empfohlen, sondern den Cache des Browsers leeren lassen, das Anti-Virenprogramm abschalten lassen.... Alles leider ohne Erfolg.
Nach dem Reset der CCU war der Firmwarestand schon aktuell auf der Version 2.21.10 und ich habe den Backup eingespielt, um meine individuellen Definitionen wieder herzustellen.
Bzgl. nächste Version von HMCCU hätte ich mal eine Frage an die Nutzer: Aktuell ist HMCCU so aufgebaut:
- IO-Device: HMCCU
- Client-Devices: HMCCUCHN, HMCCUDEV
Leider war ich bei der Entwicklung etwas inkonsequent. Daher gibt es im IO-Device ebenfalls Client-Device Funktionen wie z.B. Set Datapoint, Get Datapoint usw. Diese Funktionen würde ich gerne aus dem IO-Device entfernen. Hätte den Nachteil, dass man für die Interaktion mit Homematic Geräten immer Client-Devices anlegen muss (wie das bei CUL_HM auch ist).
Wenn jetzt nicht der große Aufschrei kommt, würde ich diese Funktionen aus 88_HMCCU.pm entfernen. Setzen/Lesen von CCU Systemvariablen und das Ausführen von CCU-Programmen würde aber im IO-Device drin bleiben.
Finde ich nur konsequent 8)
Ich nutze nur den "get CCU2 devicelist" Getter in einem DOIF und lese damit alle 4 Stunden halt nochmals die CCU aus (weiß grad aber nicht mehr wieso... :o )
dito, nutze nur get devcelist
Finde ich auch gut
Zitat von: Loredo am 16 August 2016, 09:09:52
Finde ich nur konsequent 8)
Ich nutze nur den "get CCU2 devicelist" Getter in einem DOIF und lese damit alle 4 Stunden halt nochmals die CCU aus (weiß grad aber nicht mehr wieso... :o )
get devicelist sollte man immer ausführen, wenn sich in der Gerätekonfiguration der CCU etwas ändert, insbesondere wenn neue Geräte angelernt werden, sich Geräte- oder Kanalnamen ändern oder Geräte entfernt werden.
HMCCU generiert ein Event in FHEM wenn Geräte in der CCU gelöscht oder angelernt werden. Auf dieses Event kann man per Nofity reagieren und ein get devicelist auslösen. Die Events sehen so aus:
nn devices added in CCU
nn devices deleted in CCU
Hallo zusammen,
ich bin echt verzweifelt gerade. Nachdem ich in den letzten Wochen mit mäßigem Erfolg versucht habe, mehrere HMLAN's in einer VCCU zum Laufen zu bringen, dachte ich, dass das HMCCU die Lösung ist.
Also CCU2 gekauft, Devices neu angelernt und mich an die Installation der Programme gemacht.
Dann kam das Problem. Beim Versuch des Einbindens ins Fhem komme ich über den ersten Schritt nicht hinaus :(.
Ich erhalte die Fehelermeldung:
2016.08.21 22:35:36 1: reload: Error:Modul 88_HMCCU deactivated:
Glob not terminated at FHEM/HMCCUConf.pm line 28, <DATA> line 1.
Compilation failed in require at ./FHEM/88_HMCCU.pm line 85, <DATA> line 1.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 85, <DATA> line 1.
Hat jemand einen Tipp für mich, wie ich das beseitigen kann?
Viele Grüße
Markus
Ich vermute, Du hast die Dateien falsch herunter geladen. Du musst jede Datei anklicken (Quelltext Anzeige) und dann auf "download this file" klicken.
Bald hat die Qual ein Ende und HMCCU kann über FHEM update installiert werden.
Hallo,
danke, das war es. Hab bei einem File nicht lange genug gewartet, daher war es nicht komplett ???
Jetzt läuft es.
Viele Grüße
Markus
Ich habe ein Problem mit den Slidern der Thermostate. Das setzen der Temperatur funktioniert. Allerdings springt der im Slider angezeigte Wert immer wieder auf 10 zurück. Geht das nicht anders oder womit kann ich die aktuell eingestellte Temperatur im Slider anzeigen lassen?
Gruß
er sollte nur kurzzeitig zurückspringen weil es eine weile braucht ehe die temp per ccu an das device gesendet und dieses den erfolg + neue temp an die ccu (und diese dann an fhem).
Zitat von: chris1284 am 26 August 2016, 15:39:09
er sollte nur kurzzeitig zurückspringen weil es eine weile braucht ehe die temp per ccu an das device gesendet und dieses den erfolg + neue temp an die ccu (und diese dann an fhem).
Komischerweise stehen immer alle Regler auf 10 Grad. Kann es sein, dass etwas mit der Konfiguration der CCU nicht stimmt?
Gesendet von iPhone mit Tapatalk
Zitat von: xxxONURISxxx am 26 August 2016, 16:33:27
Komischerweise stehen immer alle Regler auf 10 Grad. Kann es sein, dass etwas mit der Konfiguration der CCU nicht stimmt?
Gesendet von iPhone mit Tapatalk
Ok. Jetzt geht es. Ein Neustart des rpc-Server hat geholfen.
Gesendet von iPhone mit Tapatalk
Hallo zap,
ich komme mit dem Attribut stripnumber nicht weiter. Im readme schreibst Du dazu folgendes:
0 = Floating point numbers are stored as read from CCU (i.e. with trailing zeros).
1 = Trailing zeros are stripped from floating point numbers except one digit.
2 = All trailing zeros are stripped from floating point numbers.
"0" ist auch der Standard und klar. Aber was genau machen die anderen beiden:
Schneiden die wirklich nur angehängte Nullen ab? Oder sollen die Nachkommastellen abschneiden?
Ich würde gerne als Beispiel statt 0.420000 nur 0 angezeigt bekommen.
Aber mit "2" bekomme ich dann 0.42 und mit "1" 0.4 angezeigt.
Viele Grüße
Christian
Zitat von: cho am 30 August 2016, 13:13:23
Hallo zap,
ich komme mit dem Attribut stripnumber nicht weiter. Im readme schreibst Du dazu folgendes:
0 = Floating point numbers are stored as read from CCU (i.e. with trailing zeros).
1 = Trailing zeros are stripped from floating point numbers except one digit.
2 = All trailing zeros are stripped from floating point numbers.
"0" ist auch der Standard und klar. Aber was genau machen die anderen beiden:
Schneiden die wirklich nur angehängte Nullen ab? Oder sollen die Nachkommastellen abschneiden?
Ich würde gerne als Beispiel statt 0.420000 nur 0 angezeigt bekommen.
Aber mit "2" bekomme ich dann 0.42 und mit "1" 0.4 angezeigt.
Viele Grüße
Christian
Ich vermute mal, eine Rundungsfunktion wäre das richtige für Dich. Geht momentan nur mit userreading Gebastel. Das Attribut stripnumber schneidet einfach nur Nullen oder Stellen ab.
Mal sehen was mir dazu einfällt ... Rundung könnte ich auch gebrauchen.
Ab der nächsten Version wird ein negativer Wert bei stripnumber auf die entsprechende Anzahl Stellen runden. Dabei wird stripnumber = -0 auf den Ganzzahl Anteil runden.
Gibt es irgendwo ein Beispiel, wo die Readings eines Devices (nur bestimmte nicht alle) in ein Logfile geschrieben werden, damit ich daraus einen Plot machen kann ?
kommt drauf an was bei dir als log definiert ist ...
was hast du den unter Everything so als FileLogs definiert oder setzt du gar (was ich bezweifle ) auf dblog?
Nee, dbLog verwende ich nicht. Das mache ich (wie früher auch) über Filelog.
Die entsprechende zeile sieht so aus:
define filelog_Temp_Feuchte_Aussen FileLog ./log/filelog_Temp_Feuchte_Aussen-%d.log Temp_Feuchte_Aussen.*:Temp_Feuchte_Aussen.*|rgTestName:d_TEST.Temp_Feuchte_Aussen.*
na dann weisst du doch wo deine readings sind filelog_Temp_Feuchte_Aussen
du musst nur im webinteface das logdevice anklicken, dann hast du obern den punkt "create SVG ...."
Ja, okay, damit ist die Definition wohl richtig.
Nur leider habe ich das Problem, dass das Logfile zwar angelegt wurde aber es wird nichts eingetragen und ist somit praktisch leer ! :o
Nochmal so als Info zu meinem Aufbau:
Ich mache alles nur über den rpcserver und habe keine CUL angelegt, was ich, so meine ich, auch nicht brauche. Ich möchte ja "nur" die Funktionalität der CCU2 erweitern. Weiss nciht ob diese Info wichtig ist.
dann ist dein regexp zum filelog wohl falsch. logge doch testhalber mal mit
define filelog_Temp_Feuchte_Aussen FileLog ./log/filelog_Temp_Feuchte_Aussen-%d.log <gerätename>:.*
So Logs werden beschrieben:
2016-09-01_10:58:21 rgTestName d_TEST.Temp_Feuchte_Aussen.1.TEMPERATURE: 24.4 °C
2016-09-01_11:01:03 rgTestName d_TEST.Temp_Feuchte_Aussen.1.TEMPERATURE: 24.6 °C
2016-09-01_11:01:03 rgTestName d_TEST.Temp_Feuchte_Aussen.1.HUMIDITY: 61 %
2016-09-01_11:03:30 rgTestName d_TEST.Temp_Feuchte_Aussen.1.TEMPERATURE: 24.8 °C
2016-09-01_11:03:30 rgTestName d_TEST.Temp_Feuchte_Aussen.1.HUMIDITY: 59 %
2016-09-01_11:08:44 rgTestName d_TEST.Temp_Feuchte_Aussen.1.TEMPERATURE: 24.9 °C
2016-09-01_11:14:04 rgTestName d_TEST.Temp_Feuchte_Aussen.1.TEMPERATURE: 25.1 °C
2016-09-01_11:16:24 rgTestName d_TEST.Temp_Feuchte_Aussen.1.TEMPERATURE: 25.2 °C
2016-09-01_11:18:28 rgTestName d_TEST.Temp_Feuchte_Aussen.1.TEMPERATURE: 25.3 °C
2016-09-01_11:21:22 rgTestName d_TEST.Temp_Feuchte_Aussen.1.TEMPERATURE: 25.4 °C
2016-09-01_11:21:22 rgTestName d_TEST.Temp_Feuchte_Aussen.1.HUMIDITY: 58 %
2016-09-01_11:24:01 rgTestName d_TEST.Temp_Feuchte_Aussen.1.TEMPERATURE: 25.6 °C
2016-09-01_11:24:01 rgTestName d_TEST.Temp_Feuchte_Aussen.1.HUMIDITY: 57 %
Allerdings kein SVG Plot angezeigt :-(
su must schon auf den punk create svg ... klicken und dann den svg sagen was er plotten soll und auf write plot klicken.
Man man man .... manchmal sieht man den Wald vor lauter Bäumen nicht :o :o :o
Läuft und Danke !
Neues aus der EQ-3 Murks-Fabrik:
Ein Dimmer (Steckdose) hat einen Datenpunkt LEVEL. Laut Doku hat dieser Datenpunkt einen Wertebereich zwischen 0 und 1.
Eine Abfrage des LEVELs per Homematic Script liefert auch Werte in diesem Bereich.
ABER: Angenommen, man schaltet einen Dimmer auf 100% mit LEVEL=1 meldet die RPC-Schnittstelle der CCU2 als neuen Wert LEVEL=100 zurück. Super! 2 Wertebereiche, je nachdem, über welche Schnittstelle die Abfrage erfolgt.
Bei einem Rolladenaktor ist das übrigens konsistent. Hier ist der Wertebereich von LEVEL immer 0-1.
Nur zur Info, falls sich jemand wundert.
Zitat von: zap am 01 September 2016, 19:02:57
Nur zur Info, falls sich jemand wundert.
Ich meine in dem anderen Thread "HMCCU Beispiel Geräte-Definitionen" hatte member Yil doch das Problem. Vielleicht liest er es ja bzw. hat es selber schon erkannt / gelöst.
Neue Frage:
Ich habe von den meisten HM-Komponenten den RSSI übertragen bekommen. Den habe ich mir auch schön anzeigen lassen mit Farbwechsel usw.
Der wird eines gerätes wird mir dabei mit 207 angegeben.
Aus Spaß habe ich mal das Java Programm HMCompanion V0.22 herausgekramt, wo ebenso die RSSI Werte angegeben werden. Da bin ich völlig erstaunt, dass nun ein Wert von -51dBm mir angegeben wird. --> Mhhhh ist da noch eine Umrechnung drin oder wie habe ich nun die unterschiedlichen Werte zu interpretieren ?
Gibt's etwas Neues zur geplanten Verteilung des Moduls HMCCU über den FHEM update?
@tuppertasse: ja, ist mir auch schon aufgefallen. Die Werte müssen wohl umgerechnet werden. Ich schau mir das mal an.
@Achiim: wollte es eigentlich gestern einchecken. Habe dann aber noch einen Fehler gefunden. Dauert nicht mehr lange.
Ich habe heute die Version 3.4 von HMCCU in den
Hauptzweig von FHEM eingecheckt. Damit ist HMCCU über den normalen FHEM Update Mechanismus verfügbar. Das Modul 88_HMCCU bringt einen eingebauten RPC-Server mit. Sollte jemand weiterhin den externen RPC-Server nutzen wollen, muss die Datei ccurpcd.pl aus dem bekannten contrib Verzeichnis manuell herunter geladen und installiert werden. Außerdem muss das Attribut ccuflags auf 'extrpc' gesetzt werden Ich rate jedoch davon ab, da ich ccurpcd.pl nicht mehr weiter entwickle.
Änderungen / Neuerungen gegenüber Version 3.3:
- HMCCU: Folgende Set-/Get-Befehle stehen nicht mehr zur Verfügung: config, datapoint, channel.
- HMCCU: Folgende Attribute stehen nicht mehr zur Verfügung: updatemode
- HMCCUCHN, HMCCUDEV: Neue Set-Befehle on-for-timer, on-till und pct für die Steuerung von Geräten mit Datenpunkten ON_TIME, RAMP_TIME und LEVEL (Dimmer, Jalousien, Schalter, ...)
- HMCCUCHN, HMCCUDEV: Der Befehl get channel steht nicht mehr zur Verfügung, da weitgehend identisch mit get update
- HMCCUCHN, HMCCUDEV: Neuer Befehl set clear zum selektiven Löschen von Readings.
- Attribut ccureadingformat: Beim Format 'datapoint' setzt sich der Readingname nun so zusammen: channel-number.datapoint. Dieses Format ist nun auch für HMCCUDEV verfügbar und erlaubt Readingnames ohne den Gerätenamen.
- Das Attribut ccuackstate legt fest, ob nach Ausführung eines Befehls STATE mit dem Ergebnis der Ausführung (z.B. OK) überschrieben wird. Die Voreinstellung ist 0 = nicht überschreiben.
- Das Attribut ccuscaleval wurde erweitert. Es erlaubt nun die Skalierung, Verschiebung und Umkehrung von Werten beim Schreiben und Lesen (Beispiele s.u.)
- Das Attribut ccureadingname erlaubt die Umbenennung von Readingnamen. Beispiel: attr xyz ccureadingname 0.LOWBAT:battery,1:LEVEL:pct
- Das Attribut ccureadingformat wurde um die Werte 'namelc', 'addresslc' und 'datapointlc' erweitert. Der Zusatz 'lc' bewirkt, dass Readingnames in Kleinbuchstaben angelegt werden.
- HMCCUCHN: Neben dem Datenkanal werden auch immer die Datenpunkte/Readings des Statuskanals (0) aktualisiert. Dies kann durch das Attribut ccuflags = 'nochn0' deaktiviert werden.
- Das Attribut stripnumber akzeptiert nun auch negative Werte. Damit werden nummerische Werte auf die entsprechende Anzahl Stellen gerunden (-0 = runden auf ganze Zahlen)
- Das Attribut ccuflags erlaubt mit der Option 'trace' ein erweitertes Logging bestimmter Aktionen für das entsprechende Device. Bitte dieses Device bezogene Attribut verwenden. Das globale Attribut ccutrace im Modul HMCCU wird in der nächsten Version verschwinden.
- Bei read only Devices stehen nun einige Set-Befehle zur Verfügung
- HMCCUDEV: Bei der Definition von Devices kann die Option 'defaults' angegeben werden, um empfohlene Attribute zu setzen, sofern für den betreffenden Gerätetyp Vorgaben existieren.
Beispiele für Attrubt ccuscaleval:
attr name ccuscaleval LEVEL:0.01 => Einfache Skalierung
attr name ccuscaleval LEVEL:0:1:0:100 => Skalierung vom Bereich 0-1 in 0-100
attr name ccuscaleval LEVEL:0:1:0:200 => Skalierung vom Bereich 0-1 in 0-200
attr name ccuscaleval LEVEL:0:1:50:100 => Skalierung vom Bereich 0-1 in 50-100
attr name ccuscaleval !LEVEL:0:1:0:100 => Skalierung vom Bereich 0-1 in 0-100 und Umkehrung der Werte
Ich empfehle, insbesondere bei Dimmern die einfache Syntax (z.B. LEVEL:0.01) nicht zu verwenden, da die CCU in manchen Fällen bereits skalierte Werte liefert. Bei Angabe eines Wertebereiches erkennt HMCCU das und vermeidet eine doppelte Skalierung.
Hi,
ich habe gerade den Thread gefunden und würde heute Abend dann auch mal versuchen meine CCU zu integrieren, habe allerdings noch eine Frage bzgl des XML::Simple Moduls.
Muss das jetzt nach dem gestrigen Update noch installiert werden?
Bin leider nicht ganz so fit was diese Dinge angeht, deshalb meine (vll sehr laienhafte) Frage ::)
Ansonsten tut aber bestimmt auch das Lob eines Laiens gut ;) Dieses Modul hört sich wirklich sehr vielversprechend an und nachdem ich nach dem Umstieg auf HomeMatic schon fast komplett auf FHEM verzichtet hätte, kann ich dir nur danken
Folgende Module werden benötigt:
IO::File (dürfte vorhanden sein)
RPC::XML::Client
RPC::XML::Server
Du kannst die Module entweder über CPAN installieren oder als Linux Paket. Wenn Du dich nicht so gut auskennst, nimm CPAN.
Wenn ich es richtig "im Kopf habe":
apt-get install librpc-xml-perl
Danke euch beiden - hat wunderbar funktioniert
Zitat von: Wernieman am 14 September 2016, 20:47:12
Wenn ich es richtig "im Kopf habe":
apt-get install librpc-xml-perl
Ja, das passt für Debian bzw Raspian. Die aktuelleren Versionen gibt's allerdings über cpan. Aber wenn es läuft alles gut.
Zitat von: zap am 13 September 2016, 16:36:25
Das Modul 88_HMCCU bringt einen eingebauten RPC-Server mit. Sollte jemand weiterhin den externen RPC-Server nutzen wollen, muss die Datei ccurpcd.pl aus dem bekannten contrib Verzeichnis manuell herunter geladen und installiert werden.
Moin!
Das ist ja schon mal super.
Aber wie erkenne ich jetzt ob ich den richtigen rpcserver laufen habe?
Habe jetzt ein update gemacht und die 88er wurden auch reingeladen. Muss ich jetzt noch etwas umkonfigurieren um den eingebauten Server zu nutzen ?
@zap:
Du hast mit der Aktuallität recht. Aber apt (oder sonstige Packetmanager) hat den Vorteil, das bei einem Systemupdate auch alle anderen Perl-Packete upgedatet werden, bei CPAN eben nicht. Für "Normale" User würde ich deshalb immer die Distri-Packete nehmen und nicht CPAN ... es sei denn, es gibt besondere gründe
Zitat von: tuppertasse am 15 September 2016, 08:12:36
Moin!
Das ist ja schon mal super.
Aber wie erkenne ich jetzt ob ich den richtigen rpcserver laufen habe?
Habe jetzt ein update gemacht und die 88er wurden auch reingeladen. Muss ich jetzt noch etwas umkonfigurieren um den eingebauten Server zu nutzen ?
Das wird über das Attribut 'ccuflags' im I/O Device gesteuert. Wenn dort nicht 'extrpc' explizit gesetzt ist, startet immer der interne RPC-Server. Auf Linux Ebene ist das wir folgt erkennbar:
ps -ef | grep ccurpcd | grep -v grep
Sollte keinen Prozess anzeigen. Die internen RPC-Server sind einfach Klone des FHEM Prozesses, d.h. wenn Du im Attribut rpcport 2 RPC Ports angegeben hast, wirst Du 2 zusätzliche FHEM Prozesse sehen bei:
ps -ef | grep fhem | grep -v grep
Die IDs dieser Prozesse finden sich dann auch im Internal RPCPID im I/O Device. Und im Zweifel löschst Du einfach die alte ccurpcd.pl aus dem FHEM Modulverzeichnis und löschst das Attribut ccuflags aus dem I/O Device.
Ich habe gerade das neueste HMCCU Release über das FHEM-Update bezogen. Das hat wunderbar geklappt.
Wie empfohlen, habe ich noch alle meine Dimmer neu "skaliert" mit:
attr name ccuscaleval LEVEL:0:1:0:100 => Skalierung vom Bereich 0-1 in 0-100Läuft gut. Kompliment.
Für die Wuschliste:
Zitat von: Achiim am 15 September 2016, 17:43:39
Für die Wuschliste:
Unterstützung von toggle
Das geht eigentlich schon länger. Du musst das Attribut 'statevals' mit mindestens 2 Werten definieren. z.B.
attr myswitch statevals on:true,off:false
Dann steht automatisch ein 'set toggle' zur Verfügung, mit dem zwischen den statevals umgeschaltet wird (im Beispiel on/off). In statevals sind auch >2 Werte möglich, zwischen denen dann mit toggle geschaltet werden kann:
attr mydimmer statevals off:0,dim:50,on:100
attr mydimmer statedatapoint 1.LEVEL
set mydimmer toggle
BTW: Bevor Ihr Euch zu viel Arbeit macht mit der Definition von zig CCU Devices und Channels in FHEM: autocreate ist in Arbeit. Muss es noch testen. Kommt aber (hoffentlich) am Wochenende.
Hallo Zap,
Dein Modul ist wirklich der Hammer und es hat mir sehr geholfen. Endlich kann ich beide Welten wunderbar miteinander verheiraten.
Aber ich habe natürlich auch eine Frage... und die ist mal völlig anderer Natur ;)
Hast Du eine Amazon Wunschliste ? Einen Paypal Account oder ähnliches ? Oder eine Adresse für eine Kiste Bier :)
Ich finde irgendetwas in diese Richtung hast Du verdient.
Gruß
Carsten
Das klingt ja gut, Zap. Vielen Dank!
Macht es Sinn, dass ich mir nochmals die Mühe mache die Templates daraufhin zu aktualisieren oder bin da nur ich dran interessiert?
Zitat von: Loredo am 16 September 2016, 23:41:56
Das klingt ja gut, Zap. Vielen Dank!
Macht es Sinn, dass ich mir nochmals die Mühe mache die Templates daraufhin zu aktualisieren oder bin da nur ich dran interessiert?
Du sprichst von den Templates für Attribute, die in HMCCUConf.pm definiert sind? Ich nutze sie selbst gelegentlich und die Autocreate Funktion wird sie unterstützen. Keine Ahnung, wieviele sie sonst nutzen. Fragen gibt es kaum dazu.
kann man die servicemeldungen / den service meldungscounter eigentlich auch abfragen ?
Ja, über RPC mit der Methode getServiceMessages. Aber leider nur wirklich abfragen, es gibt nichts oder eine Liste mit den Meldungen zurück. Die XML-RPC-Schnittstelle generiert aber keinen Event, sobald eine Servicemeldung auf der CCU aufpoppt.
Zitat von: chris1284 am 17 September 2016, 14:11:21
kann man die servicemeldungen / den service meldungscounter eigentlich auch abfragen ?
Ich hatte das (ganz) am Anfang mal eingebaut. Geht prinzipiell auch ohne RPC Request. Der Mehrwert ist aber gering, da man die Meldungen immer aktiv abfragen muss.
Im Grunde basieren die Meldungen ja auf Zuständen im jeweiligen Statuskanal 0 der CCU Geräte. Die Datenpunkte dieses Kanals werden per RPC-Server aktualisiert. Du musst also eigentlich in FHEM nur darauf achten, ob einer der Datenpunkte LOWBAT, UNREACH oder STICKY_UNREACH auf true bzw. 1 geht.
Wäre es hilfreich, wenn HMCCU in diesem Fall ein Event in FHEM triggert?
Hallo zap,
ich bin mal wieder bei meinen Eltern und habe gerade FHEM-Update ausgeführt und gesehen, dass du dein Modul mittlerweile im Update-Prozess integriert hast. :)
Aber leider bekomme ich nach dem Update und Neustart von FHEM dein Modul nicht mehr zum laufen.
RPCState bleibt im Status "starting" hängen. Auch nach mehreren Minuten tut sich nichts.
#HMCCU
define CCU2 HMCCU 192.168.178.42
attr CCU2 ccureadingformat name
attr CCU2 ccureadings 0
attr CCU2 devStateIcon (OK|Initialized):10px-kreis-gruen Error:10px-kreis-rot
attr CCU2 event-on-change-reading .*
attr CCU2 icon rc_HOME
attr CCU2 rpcinterval 5
attr CCU2 rpcport 2001,2010
attr CCU2 rpcserver off
attr CCU2 stateFormat { $defs{$name}{RPCState} }
attr CCU2 statevals on:true,off:false
attr CCU2 stripchar :
attr CCU2 stripnumber 1
attr CCU2 updatemode client
attr CCU2 verbose 2
attr CCU2 ccuflags intrpc
Viele Grüße, Thomas
Hallo Zap,
ich versuche gerade meine HM Geräte via Deinem Modul und dem Homebridge Modul in Apple Home einzubinden.
Die Steuerung von einfachen Dummy Geräten funktioniert gut. Aber ich bekomme die HM Geräte dadrüber nicht zum Laufen. Hast Du schon mit Homebridge Erfahrungen gesammelt und weißt, wie die Attribute für HM Geräte am Besten zu setzen sind?
Viele Grüße
Christian
Hallo Zap,
ich versuche gerade meine HM Geräte via Deinem Modul und dem Homebridge Modul in Apple Home einzubinden.
Die Steuerung von einfachen Dummy Geräten funktioniert gut. Aber ich bekomme die HM Geräte dadrüber nicht zum Laufen. Hast Du schon mit Homebridge Erfahrungen gesammelt und weißt, wie die Attribute für HM Geräte am Besten zu setzen sind?
Viele Grüße
Christian
Zitat von: ToM_ToM am 17 September 2016, 18:50:41
Hallo zap,
ich bin mal wieder bei meinen Eltern und habe gerade FHEM-Update ausgeführt und gesehen, dass du dein Modul mittlerweile im Update-Prozess integriert hast. :)
Aber leider bekomme ich nach dem Update und Neustart von FHEM dein Modul nicht mehr zum laufen.
RPCState bleibt im Status "starting" hängen. Auch nach mehreren Minuten tut sich nichts.
attr CCU2 updatemode client
attr CCU2 ccuflags intrpc
Viele Grüße, Thomas
Gibt es irgendwelche Meldungen im Logfile?
Halt mal fhem an. Prüfe, dass kein fhem oder ccurpcd Prozess mehr läuft und starte dann fhem. Danach den Rpc Server erst mal manuell starte mit set rpcserver on.
Die beiden Attribute oben im Zitat kannst Du löschen. Updatemode wird nicht mehr verwendet und der Default für ccuflags ist intrpc.
Hallo zap,
ich habe meine Config entsprechend angepasst und die Sachen überprüft. Habe auch nochmal den Pi neu gestartet und alles so gemacht wie du gesagt hast.
Auszug aus dem Log:
2016.09.18 11:40:18 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2016.09.18 11:40:18 0: HMCCU: Child process for server CB2001 started with PID 1483
2016.09.18 11:40:18 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001
2016.09.18 11:40:18 0: CCURPC: Initializing RPC server CB2001
2016.09.18 11:40:18 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2016.09.18 11:40:18 0: HMCCU: Child process for server CB2010 started with PID 1484
2016.09.18 11:40:18 0: CCURPC: CB2010 Creating file queue /tmp/ccuqueue_2010
2016.09.18 11:40:18 0: CCURPC: Initializing RPC server CB2010
2016.09.18 11:40:18 0: RPC server(s) starting
2016.09.18 11:40:18 0: CCURPC: Callback server created listening on port 7410
2016.09.18 11:40:18 0: CCURPC: Callback server created listening on port 7401
2016.09.18 11:40:18 1: CCURPC: CB2010 Adding callback for events
2016.09.18 11:40:18 1: CCURPC: CB2001 Adding callback for events
2016.09.18 11:40:18 1: CCURPC: CB2010 Adding callback for new devices
2016.09.18 11:40:18 1: CCURPC: CB2001 Adding callback for new devices
2016.09.18 11:40:18 1: CCURPC: CB2010 Adding callback for deleted devices
2016.09.18 11:40:18 1: CCURPC: CB2001 Adding callback for deleted devices
2016.09.18 11:40:18 1: CCURPC: CB2001 Adding callback for modified devices
2016.09.18 11:40:18 1: CCURPC: CB2010 Adding callback for modified devices
2016.09.18 11:40:18 1: CCURPC: CB2001 Adding callback for replaced devices
2016.09.18 11:40:18 1: CCURPC: CB2010 Adding callback for replaced devices
2016.09.18 11:40:18 1: CCURPC: CB2010 Adding callback for readded devices
2016.09.18 11:40:18 1: CCURPC: CB2001 Adding callback for readded devices
2016.09.18 11:40:18 1: CCURPC: CB2001 Adding callback for list devices
2016.09.18 11:40:18 0: CCURPC: CB2001 Entering server loop
2016.09.18 11:40:18 1: CCURPC: CB2010 Adding callback for list devices
2016.09.18 11:40:18 0: CCURPC: CB2010 Entering server loop
2016.09.18 11:40:23 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2016.09.18 11:40:30 1: HMCCU: Registering callback http://192.168.178.58:7401/fh2001 with ID CB2001 at http://192.168.178.42:2001/
2016.09.18 11:40:30 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2016.09.18 11:40:30 1: HMCCU: RPC callback with URL http://192.168.178.58:7401/fh2001 initialized
2016.09.18 11:40:31 2: CCURPC: CB2001 NewDevice received 154 device specifications
2016.09.18 11:40:35 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.09.18 11:40:35 0: HMCCU: Received SL event. RPC server CB2010 enters server loop
Mhhhh,
ich hatte mal ein Phänomen, dass ich einfach F5 drücken musste. Hat einfach immer starting angezeigt anstatt running. Hab dann komplett Cache geleert usw. Seitdem ging es bzw. leere den Cache automatisch wenn ich den Browser schliesse.
Ansonsten seh ich keinen Fehler. Prüf mal die beiden Befehle auf der Konsole aus dem Thread #726.
Kriegste denn Werte ?
Hit Tuppertasse,
aktualisiert habe ich immer. Also ein Anzeigefehler ist es nicht. Was meinst du mit Thread #726? Wie komme ich dort hin? :D
VG, Thomas
:-)
hier hin (https://forum.fhem.de/index.php/topic,40189.msg491232.html#msg491232)
Wenn Dein Logfile dort endet, scheint der RPCServer für HMIP nicht richtig initialisiert zu werden. Ich vermute, dass auf der CCU etwas schief läuft. Im Zweifel die mal neu starten oder vorher in /var/log/messages auf der CCU nachschauen, ob da irgendwelche Fehler stehen.
Hey, habe jetzt mal die CCU neu durchgebootet und die Datei gelöscht wie im Thread 726 beschrieben. Jetzt läuft alles perfekt. :)
Danke euch 2.
Immer noch toggle:ZitatDas geht eigentlich schon länger. Du musst das Attribut 'statevals' mit mindestens 2 Werten definieren. z.B.
Ich verwende toggle in Kombination mit "substiture". Sollte das auch gehen? Bei mir geht's leider nicht.
define Arbeitszimmer_Deckenlicht HMCCUDEV AZ-Deckenlicht 1
attr Arbeitszimmer_Deckenlicht IODev myHomematicCCU
attr Arbeitszimmer_Deckenlicht ccuscaleval LEVEL:0:1:0:100
attr Arbeitszimmer_Deckenlicht controldatapoint 1.LEVEL
attr Arbeitszimmer_Deckenlicht event-on-change-reading .*
attr Arbeitszimmer_Deckenlicht group Arbeitszimmer_Licht
attr Arbeitszimmer_Deckenlicht icon light_ceiling
attr Arbeitszimmer_Deckenlicht room 02_Oben
attr Arbeitszimmer_Deckenlicht statechannel 1
attr Arbeitszimmer_Deckenlicht statedatapoint 1.LEVEL
attr Arbeitszimmer_Deckenlicht statevals on:100,off:0
attr Arbeitszimmer_Deckenlicht stripnumber 1
attr Arbeitszimmer_Deckenlicht substitute 100:on,0:off
attr Arbeitszimmer_Deckenlicht webCmd control
attr Arbeitszimmer_Deckenlicht widgetOverride control:slider,0,1,100,100Ein
set Arbeitszimmer_Deckenlicht toggle bewirkt bei mir seltsamerweise das Setzen von Level auf Kanal 2???? Siehe screenshot.
Nochmal Rauchmelder
Ich habe das in de CCU2 definierte Rauchmederteam auch in FHEM als HMCCUDEV angelegt. Wie kann ich die Teammitglieder in FEHM abfragen? In der CCU2 sehe ich das Team -> screenshot.
define HM_Rauchmelderteam HMCCUDEV Rauchmelderteam 1
attr HM_Rauchmelderteam IODev myHomematicCCU
attr HM_Rauchmelderteam devStateIcon false:10px-kreis-gruen true:10px-kreis-rot ok:10px-kreis-gelb
attr HM_Rauchmelderteam group Global
attr HM_Rauchmelderteam room 00_Haus
attr HM_Rauchmelderteam statechannel 1
Zitat von: Achiim am 18 September 2016, 16:46:34
Immer noch toggle:
Ich verwende toggle in Kombination mit "substiture". Sollte das auch gehen? Bei mir geht's leider nicht.
Ein set Arbeitszimmer_Deckenlicht toggle bewirkt bei mir seltsamerweise das Setzen von Level auf Kanal 2???? Siehe screenshot.
Kann ich bei mir nachvollziehen. Da stimmt etwas nicht im Modul. Ein einfaches "set on" oder "set off" funktioniert. Das substitute ist korrekt. Ohne das funktioniert Toggle nicht.
Update: Fehler in Toggle gefunden. Wird behoben.
Zum Rauchmelder: Du möchtest wissen, welche Einzelgeräte zu einem Team gehören? Oder möchtest Du die Einzeldevices in FEHM haben => Einfach definieren.
ich würde zum rauchmelder gerne wissen welches event bei einem alarm generiert wird. der testalarm den man auslösen kann bringt in fhem kein event
ZitatZum Rauchmelder: Du möchtest wissen, welche Einzelgeräte zu einem Team gehören?
Korrekt.
Automatisch ermitteln kann HMCCU das derzeit nicht. Wenn Du die Rauchmelder manuell zusammenfassen willst:
define RM_Gruppe HMCCUDEV virtual group=AZ-Rauchmelder:1,WK-Rauchmelder:1,...
Zitat von: cho am 17 September 2016, 22:30:31
Hallo Zap,
ich versuche gerade meine HM Geräte via Deinem Modul und dem Homebridge Modul in Apple Home einzubinden.
Die Steuerung von einfachen Dummy Geräten funktioniert gut. Aber ich bekomme die HM Geräte dadrüber nicht zum Laufen. Hast Du schon mit Homebridge Erfahrungen gesammelt und weißt, wie die Attribute für HM Geräte am Besten zu setzen sind?
Viele Grüße
Christian
Hallo zusammen,
hat schon irgendjemand von Euch Erfahrung mit Zaps Modul und Homebridge gesammelt? Wie habt Ihr Eure HM Thermostate und Fensterkontakte für Homebridge konfiguriert?
Viele Grüße
Christian
Hey, hat jemand von euch schon eine Wetterstation eingebunden?
Die Wetterstation an sich ist kein Problem, aber die Daten wie "Rain today" werden nicht im Device, bzw. Kanal gespeichert, sondern als System-Variable.
Systemvariablen kann ich ja mitget CCU2 vars .* abfragen und bekomme dann die Daten ${sysVarRainToday}=0.000000 zurück.
In der Wetterstation gibt es ein Reading welches ob es aktuell regnet oder nicht, daher wollte ich irgendwie den Weg über das notify gehen. Wenn es regnet, dann starte einen Watchdog der alle 30 Sekunden die Systemvariable einliest um die CCU nur mit der Abfrage zu belasten wenn es regnet.
Idee war so etwas in der Art:
define RefreshTodayRainVolume notify HM_GN_Wetterstation.1.RAINING.yes {...hier dann die Abfrage mit get CCU2 vars ${sysVarRainToday} und das Schreiben der Daten in ein Reading...}
Aber ich glaube, das funtkioniert so nicht... oder (unabhängig davon dass ich das $ und die { } noch maskieren müsste)?
VG, Thomas
Die Systemvariable in der CCU heißt wirklich ${sysVarRainToday}? Wer denkt sich denn sowas aus?
Wenn ich mich recht erinnere, holt sich HMCCU bei einem "get vars" sowieso immer alle Variablen. Der Parameter legt nur fest, welche Variablen tatsächlich in einem Reading landen. Da das ein regulärer Ausdruck ist, sollte folgendes funktionieren:
get CCU2 vars sysVarRainToday
Kannst es ja mal manuell probieren.
Statt in FHEM ein Notify zu verwenden, könntest Du auch aus der CCU2 heraus ein Reading bzw. ein Dummy Device in FHEM auf den Wert setzen. Wie das geht, hatte ich schon mal irgendwo beschrieben. Du brauchst auf der CCU2 das Programm "nc" (NetCat) sowie am besten noch CuXD. Dann erstellst Du in der CCU2 ein Programm, das bei Änderung einer Variablen ausgeführt wird und entsprechende Werte an FHEM schickt.
Update: Hier ist der Beitrag:
https://forum.fhem.de/index.php?topic=42089.0
Hallo zap,
habe mir das durchgelesen, aber ich möchte ungern irgendwas auf die CCU draufspielen.
Habe mir die Lösung jetzt so gebaut:
define RefreshTodayRainVolume notify HM_GN_Wetterstation.HM-WDS100-C6-O-2_NEQXXXXXXX.1.RAINING.yes { my $rainVolume = fhem("get CCU2 vars sysVarRainToday");; fhem("trigger RefreshTodayRainVolumeWatchdog .");; }
define RefreshTodayRainVolumeWatchdog watchdog HM_GN_Wetterstation.HM-WDS100-C6-O-2_NEQXXXXXXX.1.RAINING:yes.* 00:00:10 SAME { my $rainVolume = fhem("get CCU2 vars sysVarRainToday") =~ s/\$\{sysVarRainToday\}=//r ;; fhem("setreading HM_GN_Wetterstation RainToday $rainVolume");; fhem("trigger RefreshTodayRainVolumeWatchdog .");; }
Ich denke, der Ansatz ist ganz gut.
Aber irgendwie triggert der Watchdog nur einmal und läuft nicht alle 10 Sekunden wie ich es eigentlich wollte.
VG, Thomas
Ich habe gerade ein Update für 88_HMCCU.pm eingecheckt. Das dürfte allerdings erst morgen per Update verteilt werden (kenne den Aktualisierungszyklus von FHEM SVN nicht).
In dieser Version sollte der Bug im Attribut stripnumber behoben sein (wenn stripnumber = 2).
Der Befehl "get devicelist" des I/O Device wurde um eine Autocreate Funktion erweitert. Die alte Syntax geht natürlich auch noch. Die neue sieht so aus:
get name devicelist create <devexp> [p=<prefix>] [s=<suffix>] [f=<format>] [<attr>=<value> [...]]
Der Parameter devexp legt einen regulären Ausdruck für CCU Geräte- oder Kanalnamen fest. Für alle Namen, die auf diesen Ausdruck passen, werden Geräte in FHEM angelegt. Ich rate dringend davon ab, hier .* zu verwenden.
Wenn ein Präfix oder ein Suffix angegeben wird, werden die FHEM Gerätenamen entsprechend ergänzt. Format legt einen generellen Formatstring für den Gerätenamen fest. In allen drei Parametern können folgende Platzhalter verwendet werden:
%n = Geräte- oder Kanalname in der CCU
%d = Gerätename in der CCU (auch bei Kanälen)
%a = Adresse in der CCU
Die Regel ist also: FHEM-Gerätename = Präfix + Format + Suffix. Wobei der Default für Format %n ist. Default für Präfix und Suffix ist ein Leerstring.
Beispiel:
get myccu devicelist create ^KLIMA-WOHNEN.* p=HMKL_ f=%n_dev room=Homematic icon=rc_Home
Hi,
heute habe ich auf die offizielle HMCCU per fhem Update upgedated.
Seitdem funktioniert meine CUxD "Christbaum"-Steckdose nicht mehr.
Fehler:
HMCCUCHN Christbaum Invalid Datapoint
Defnition wie vorher:
define Christbaum HMCCUCHN Christbaum
attr Christbaum userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr Christbaum IODev ccu2
attr Christbaum ccureadingfilter (STATE|ON_TIME)
attr Christbaum ccureadings 1
attr Christbaum devStateIcon on:li_wht_on off:li_wht_off Initialized:10px-kreis-gelb
attr Christbaum event-on-change-reading .*
attr Christbaum group Lichter
attr Christbaum room Homekit,Wohnzimmer
attr Christbaum statevals on:true,off:false
attr Christbaum substitute STATE!true:on,false:off,1:on,0:off
Was ist da jetzt anders?
Wieso geht das nicht mehr?
VG alex
Zitat von: aski71 am 19 September 2016, 20:38:58
Hi,
heute habe ich auf die offizielle HMCCU per fhem Update upgedated.
Seitdem funktioniert meine CUxD "Christbaum"-Steckdose nicht mehr.
Fehler:
HMCCUCHN Christbaum Invalid Datapoint
Defnition wie vorher:
define Christbaum HMCCUCHN Christbaum
attr Christbaum userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr Christbaum IODev ccu2
attr Christbaum ccureadingfilter (STATE|ON_TIME)
attr Christbaum ccureadings 1
attr Christbaum devStateIcon on:li_wht_on off:li_wht_off Initialized:10px-kreis-gelb
attr Christbaum event-on-change-reading .*
attr Christbaum group Lichter
attr Christbaum room Homekit,Wohnzimmer
attr Christbaum statevals on:true,off:false
attr Christbaum substitute STATE!true:on,false:off,1:on,0:off
Was ist da jetzt anders?
Wieso geht das nicht mehr?
VG alex
Ergänzung: KEINE meiner CUxD Steckdosen geht mehr! Überall der gleiches Problem.
Umdefinition mittels HMCCUDEV: Gleiches Problem.
Danke für Hilfe....
Du musst vermutlich das Attribut statedatapoint setzen. Da ist HMCCU nun etwas sensibler geworden. Mach mal bitte ein get deviceinfo auf eines der Geräte und poste die Ausgabe.
Zitat von: zap am 20 September 2016, 07:26:58
Du musst vermutlich das Attribut statedatapoint setzen. Da ist HMCCU nun etwas sensibler geworden. Mach mal bitte ein get deviceinfo auf eines der Geräte und poste die Ausgabe.
statedatapoint habe ich auch schon versucht.
Keine Änderung, egal ob ich: state, STATE, oder Christbaum.STATE verwende.
Auch CUxD.CUX2801005:2.STATE, CUX2801005:2.STATE führt zu nichts.
Deviceinfo sieht so aus:
CHN CUX2801005:0 FritzDECT:0
DPT {b} CUxD.CUX2801005:0.LOWBAT = false [RE]
DPT {b} CUxD.CUX2801005:0.UNREACH = false [RE]
DPT {b} CUxD.CUX2801005:0.STICKY_UNREACH = true [RWE]
CHN CUX2801005:1 Harmony
DPT {f} CUxD.CUX2801005:1.LEVEL = 0.010000 [RWE]
DPT {b} CUxD.CUX2801005:1.OLD_LEVEL = [W]
DPT {b} CUxD.CUX2801005:1.STOP = [WE]
DPT {b} CUxD.CUX2801005:1.STATE = false [RWE]
DPT {b} CUxD.CUX2801005:1.PRESS_SHORT = [WE]
DPT {b} CUxD.CUX2801005:1.PRESS_LONG = [WE]
DPT {b} CUxD.CUX2801005:1.CMD_RUNS = [W]
DPT {b} CUxD.CUX2801005:1.CMD_RUNL = [W]
DPT {s} CUxD.CUX2801005:1.CMD_KILL = [W]
DPT {s} CUxD.CUX2801005:1.CMD_EXEC = [W]
DPT {s} CUxD.CUX2801005:1.LOGIT = [W]
DPT {s} CUxD.CUX2801005:1.SYSLOG = [W]
DPT {s} CUxD.CUX2801005:1.CMD_SETS = $_P1$ switch $_C1$ 0 [RWE]
DPT {s} CUxD.CUX2801005:1.CMD_SETL = $_P1$ switch $_C1$ 1 [RWE]
DPT {s} CUxD.CUX2801005:1.CMD_RETS = 0 [RE]
DPT {s} CUxD.CUX2801005:1.CMD_RETL = [RE]
DPT {b} CUxD.CUX2801005:1.CMD_QUERY_RET = [W]
DPT {b} CUxD.CUX2801005:1.WORKING = false [RE]
DPT {i} CUxD.CUX2801005:1.CONTROL = 1 [R]
DPT {f} CUxD.CUX2801005:1.SET_STATE = [W]
DPT {s} CUxD.CUX2801005:1.RAND = 54260 [RW]
DPT {b} CUxD.CUX2801005:1.INHIBIT = false [RW]
CHN CUX2801005:2 Christbaum
DPT {f} CUxD.CUX2801005:2.LEVEL = 0.010000 [RWE]
DPT {b} CUxD.CUX2801005:2.OLD_LEVEL = [W]
DPT {b} CUxD.CUX2801005:2.STOP = [WE]
DPT {b} CUxD.CUX2801005:2.STATE = false [RWE]
DPT {b} CUxD.CUX2801005:2.PRESS_SHORT = [WE]
DPT {b} CUxD.CUX2801005:2.PRESS_LONG = [WE]
DPT {b} CUxD.CUX2801005:2.CMD_RUNS = [W]
DPT {b} CUxD.CUX2801005:2.CMD_RUNL = [W]
DPT {s} CUxD.CUX2801005:2.CMD_KILL = [W]
DPT {s} CUxD.CUX2801005:2.CMD_EXEC = [W]
DPT {s} CUxD.CUX2801005:2.LOGIT = [W]
DPT {s} CUxD.CUX2801005:2.SYSLOG = [W]
DPT {s} CUxD.CUX2801005:2.CMD_SETS = $_P1$ switch $_C1$ 0 [RWE]
DPT {s} CUxD.CUX2801005:2.CMD_SETL = $_P1$ switch $_C1$ 1 [RWE]
DPT {s} CUxD.CUX2801005:2.CMD_RETS = 0 [RE]
DPT {s} CUxD.CUX2801005:2.CMD_RETL = 0 [RE]
DPT {b} CUxD.CUX2801005:2.CMD_QUERY_RET = [W]
DPT {b} CUxD.CUX2801005:2.WORKING = false [RE]
DPT {i} CUxD.CUX2801005:2.CONTROL = 1 [R]
DPT {f} CUxD.CUX2801005:2.SET_STATE = [W]
DPT {s} CUxD.CUX2801005:2.RAND = 12157 [RW]
DPT {b} CUxD.CUX2801005:2.INHIBIT = false [RW]
CHN CUX2801005:3 Balkonlicht
DPT {f} CUxD.CUX2801005:3.LEVEL = 0.000000 [RWE]
DPT {b} CUxD.CUX2801005:3.OLD_LEVEL = [W]
DPT {b} CUxD.CUX2801005:3.STOP = [WE]
DPT {b} CUxD.CUX2801005:3.STATE = false [RWE]
DPT {b} CUxD.CUX2801005:3.PRESS_SHORT = [WE]
DPT {b} CUxD.CUX2801005:3.PRESS_LONG = [WE]
DPT {b} CUxD.CUX2801005:3.CMD_RUNS = [W]
DPT {b} CUxD.CUX2801005:3.CMD_RUNL = [W]
DPT {s} CUxD.CUX2801005:3.CMD_KILL = [W]
DPT {s} CUxD.CUX2801005:3.CMD_EXEC = [W]
DPT {s} CUxD.CUX2801005:3.LOGIT = [W]
DPT {s} CUxD.CUX2801005:3.SYSLOG = [W]
DPT {s} CUxD.CUX2801005:3.CMD_SETS = $_P1$ switch $_C1$ 0 [RWE]
DPT {s} CUxD.CUX2801005:3.CMD_SETL = $_P1$ switch $_C1$ 1 [RWE]
DPT {s} CUxD.CUX2801005:3.CMD_RETS = [RE]
DPT {s} CUxD.CUX2801005:3.CMD_RETL = [RE]
DPT {b} CUxD.CUX2801005:3.CMD_QUERY_RET = [W]
DPT {b} CUxD.CUX2801005:3.WORKING = false [RE]
DPT {i} CUxD.CUX2801005:3.CONTROL = 1 [R]
DPT {f} CUxD.CUX2801005:3.SET_STATE = [W]
DPT {s} CUxD.CUX2801005:3.RAND = 50659 [RW]
DPT {b} CUxD.CUX2801005:3.INHIBIT = false [RW]
Ist das ein Dimmer (wegen dem Datenpunkt LEVEL)? Wenn es über STATE geschaltet wird, muss bei HMCCUDEV statedatapoint=1.STATE sein, bei HMCCUCHN hingegen nur STATE und das HMCCUCHN Device muss sich auf Kanal 1 beziehen.
Ansonsten setze mal ccuflags auf trace, führe dann ein Set datapoint aus und schau, was im FHEM.log dazu protokolliert wird.
Zitat von: zap am 20 September 2016, 11:49:45
Ist das ein Dimmer (wegen dem Datenpunkt LEVEL)? Wenn es über STATE geschaltet wird, muss bei HMCCUDEV statedatapoint=1.STATE sein, bei HMCCUCHN hingegen nur STATE und das HMCCUCHN Device muss sich auf Kanal 1 beziehen.
Ansonsten setze mal ccuflags auf trace, führe dann ein Set datapoint aus und schau, was im FHEM.log dazu protokolliert wird.
Nein. Das ist kein Dimmer. CUxD legt nur allerlei Allerlei an. Im Prinzip wird bei Veränderung des STATE von CUxD ein Shellscript mit dem richtigen Parameter aufgerufen. Das funktioniert auch nach wie vor hervorragend in der CCU Oberfläche, in der HC App (die direkt mit der CCU verbunden ist). Nur aus fhem seit dem Update gestern nicht mehr.
Hab ccuflags auf trace gesetzt und dann diverser set datapoint Kommandos ausprobiert.
Ergebnis im Log ist immer:
2016.09.20 13:14:50 1: HMCCUCHN: Christbaum Invalid datapoint
Bitte aktualisiere im iO Device nochmal die Deviceliste mit get Deviceliste
Danach nochmal das Set datapoint versuchen
Zitat von: zap am 20 September 2016, 14:38:35
Bitte aktualisiere im iO Device nochmal die Deviceliste mit get Deviceliste
Danach nochmal das Set datapoint versuchen
Auch schon mal gemacht.
Immer der gleiche Fehler.
set Christbaum datapoint STATE on
set Christbaum datapoint state on
set Christbaum datapoint Christbaum.STATE on
get Christbaum devstate
get Christbaum datapoint state
get Christbaum datapoint STATEDas einzige, was zu gehen scheint, ist folgendes:
Wenn ich direkt mit der CCU-Oberfläche schalte und dann
get updatemache, dann wird der Ein-/Aus-Zustand ausgelesen und richtig dargestellt.
Die Readings Christbaum.STATE und state werden aktualisiert.
Habe die Ursache gefunden. Die CUxD Devices werden in der CCU mit einem bestimmten Typ angelegt (einem original Homematic Typ). Leider unterscheiden sich die Datenpunkte des CUxD Devices von denen des original Homematic Typen.
In Deinem Fall hat also die CUxD Steckdose andere Datenpunkte als eine Homematic Steckdose, wird aber als solche von der Zentrale verwaltet. Wenn HMCCU nun mit get devicelist alle Geräte der CCU abfragt, merkt es sich die verfügbaren Datenpunkte je Gerätetyp. Da hier 2 Devices sich als gleicher Gerätetyp ausgeben aber unterschiedliche Datenpunkte liefern, überschreiben sie sich gegenseitig. Das ist echt übel. Da muss ich erst mal drüber nachdenken, wie man das umgehen kann. Jedenfalls nicht ohne Update.
Zitat von: zap am 20 September 2016, 16:50:14
Habe die Ursache gefunden. Die CUxD Devices werden in der CCU mit einem bestimmten Typ angelegt (einem original Homematic Typ). Leider unterscheiden sich die Datenpunkte des CUxD Devices von denen des original Homematic Typen.
In Deinem Fall hat also die CUxD Steckdose andere Datenpunkte als eine Homematic Steckdose, wird aber als solche von der Zentrale verwaltet. Wenn HMCCU nun mit get devicelist alle Geräte der CCU abfragt, merkt es sich die verfügbaren Datenpunkte je Gerätetyp. Da hier 2 Devices sich als gleicher Gerätetyp ausgeben aber unterschiedliche Datenpunkte liefern, überschreiben sie sich gegenseitig. Das ist echt übel. Da muss ich erst mal drüber nachdenken, wie man das umgehen kann. Jedenfalls nicht ohne Update.
Oha. :-\
Und wieso ging das dann vorher?
Zitat von: aski71 am 20 September 2016, 18:03:46
Oha. :-\
Und wieso ging das dann vorher?
Weil HMCCU bisher nicht geprüft hat, ob ein Datenpunkt gültig ist. Der Befehl wurde einfach an die CCU geschickt. Leider hat das in einigen Fällen die CCU ins Straucheln gebracht. Daher habe ich die Prüfung eingebaut.
Bitte gedulde Dich bis morgen. Ich checke heute noch ein Update ein. Habe zwar etwas Bedenken wegen eventueller Seiteneffekte, läuft aber bei mir momentan stabil.
Oder Du ziehst Dir die alte Version aus dem bisherigen Contrib-Pfad.
Zitat von: zap am 20 September 2016, 19:04:31
Weil HMCCU bisher nicht geprüft hat, ob ein Datenpunkt gültig ist. Der Befehl wurde einfach an die CCU geschickt. Leider hat das in einigen Fällen die CCU ins Straucheln gebracht. Daher habe ich die Prüfung eingebaut.
Bitte gedulde Dich bis morgen. Ich checke heute noch ein Update ein. Habe zwar etwas Bedenken wegen eventueller Seiteneffekte, läuft aber bei mir momentan stabil.
Oder Du ziehst Dir die alte Version aus dem bisherigen Contrib-Pfad.
Ah, verstehe. :) Das macht natürlich Sinn.
Ich warte auf die neue Version.
Die Version mit den Anpassungen für CUxD Datenpunkte sollte jetzt im Update sein. Bitte beachten: nach dem Neustart von FHEM bzw nach einem get Devicelist muss sich das Internal ccutype der FHEM Devices in "CUX-..." ändern. Falls das nicht passiert, müssen die Devices per Click auf DEF neu angelegt werden. Hat bei mir aber automatisch funktioniert.
Hallo Miteinander,
habe heute Devices per AutoCreate angelegt. Hat auch soweit gut funktioniert.
Wäre es denn aber nicht sinniger wenn die Templates in HMCCUConf.pm automatisch gegriffen werden ?
Das hat bei mir nicht funktioniert (wenn es denn so gewünscht ist).
Ich musste mit einem get / set Default die Templates laden, natürlich für die jeweiligen Devices.
Ich hab auch noch eine Erweiterung für die Templates nämlich die alten Homematic Steckdosen.
"HM-LC-Sw1-Pl-DN-R1" => { # Steckdose
ccureadingfilter => "(STATE|UNREACH)",
controldatapoint => "1.STATE",
statechannel => 1,
statevals => "on:true,off:false",
substitute => "STATE!(1|true):on,(0|false):off;(true|1):yes,(false|0):no",
webCmd => "control",
widgetOverride => "control:uzsuToggle,off,on"
},
Ich hab das bei mir eingetragen, funktioniert genauso wie die neuen Steckdosen. Könnte man ja generell übernehmen ?
Gruß
Carsten
Zitat von: zap am 21 September 2016, 07:23:09
Die Version mit den Anpassungen für CUxD Datenpunkte sollte jetzt im Update sein. Bitte beachten: nach dem Neustart von FHEM bzw nach einem get Devicelist muss sich das Internal ccutype der FHEM Devices in "CUX-..." ändern. Falls das nicht passiert, müssen die Devices per Click auf DEF neu angelegt werden. Hat bei mir aber automatisch funktioniert.
Topp! Funktioniert wieder!
Vielen Dank für die schnelle Behebung! :D
Zitat von: Hellspawn am 21 September 2016, 12:27:46
Hallo Miteinander,
habe heute Devices per AutoCreate angelegt. Hat auch soweit gut funktioniert.
Wäre es denn aber nicht sinniger wenn die Templates in HMCCUConf.pm automatisch gegriffen werden ?
Ja wäre hilfreich. Habe ich schlicht vergessen. Werde es einbauen.
Dein Konfigurationsbeispiel nehme ich gerne auf.
Hey Super, Dankeschön
Hi,
ich steh auf dem Schlauch.
Ich würde gerne von meinem Thermostat das Reading CONTROL_MODE aus fhem ändern und Richtung CCU zurück schicken.
Geht das irgendwie?
Ich hätte vermutet, dass es mit "set Thermostat datapoint 1.CONTROL_MODE <wert>" vielleicht geht?
Tut es aber nicht. Egal, wie ich den datapoint formuliere, taucht die mir so beliebte Meldung "Invalid datapoint" auf.
Danke für Hilfe.
VG Alex
Wenn Du get deviceinfo für das Thermostat Device aufrufst, wirst Du feststellen, dass bei CONTROL_MODE [RE] steht. Das steht für Read und Event. Der Datenpunkt ist also nicht beschreibbar.
Du musst den Mode über die beschreibbaren Datenpunkte MANU_MODE, AUTO_MODE usw. einstellen. Beachte auch den Datentyp des Datenpunktes (steht bei get deviceinfo am Anfang, b=bool, f=float, i=integer).
Bei AUTO_MODE schreibst Du true oder false, das ist vom Typ bool.
Bei MANU_MODE gibst Du die Temperatur mit (5-30 Grad). Wenn Du hier 4.5 angibst, geht der Thermostat auf OFF. Bei 30.5 geht er auf ON.
All diese Infos findest Du bei Google unter dem Begriff "Homematic Datenpunkte". Einer der Treffer ist ein PDF von EQ-3, in dem alle Geräte mit allen Datenpunkten, den Typen und Wertebereichen beschrieben sind.
List eines meiner Wandthermostate:
Internals:
CHANGED
DEF KL-SZ-TH
IODev d_ccu
NAME HM_KL_SZ_TH
NR 76
STATE T: 21.1° H: 58% D: 21.0° P: 12.5°
TYPE HMCCUDEV
ccuaddr LEQ0000647
ccudevstate Active
ccuif BidCos-RF
ccuname KL-SZ-TH
ccutype HM-TC-IT-WM-W-EU
channels 6
statevals devstate
Readings:
2016-09-21 20:53:01 DEWPOINT 12.5
2016-09-20 19:00:28 KL-SZ-TH.0.STICKY_UNREACH false
2016-09-20 19:00:28 KL-SZ-TH.0.UNREACH false
2016-09-21 20:53:01 KL-SZ-TH.1.HUMIDITY 58
2016-09-21 20:53:01 KL-SZ-TH.1.TEMPERATURE 21.1
2016-09-21 17:01:01 KL-SZ-TH.2.CONTROL_MODE AUTO
2016-09-21 20:52:40 KL-SZ-TH.2.SET_TEMPERATURE 21.0
2016-09-21 20:52:40 control 21.0
2016-09-21 20:52:40 state 21.0
Attributes:
IODev d_ccu
ccureadingfilter (UNREACH|^HUMIDITY|^TEMPERATURE|^SET_TEMPERATURE|^LOWBAT1^WINDOW_OPEN|^CONTROL)
cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
comment Wand-Thermostat Schlafzimmer
controldatapoint 2.SET_TEMPERATURE
devStateIcon OK:10px-kreis-gruen Error:10px-kreis-rot Initialized:10px-kreis-gelb
event-on-change-reading .*
eventMap /datapoint 2.MANU_MODE 20.0:Manu/datapoint 2.AUTO_MODE 1:Auto/datapoint 2.BOOST_MODE 1:Boost/datapoint 2.MANU_MODE 4.5:off/datapoint 2.MANU_MODE 30.5:on/
group Klima
icon rc_HOME
room Homematic
stateFormat T: KL-SZ-TH.1.TEMPERATURE° H: KL-SZ-TH.1.HUMIDITY% D: KL-SZ-TH.2.SET_TEMPERATURE° P: DEWPOINT°
statedatapoint 2.SET_TEMPERATURE
stripnumber 1
substitute LOWBAT!(0|false):no,(1|true):yes;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed
userReadings DEWPOINT {HMCCU_Dewpoint($name,"KL-SZ-TH.1.TEMPERATURE", "KL-SZ-TH.1.HUMIDITY","n/a")}
webCmd control:Auto:Manu:Boost:on:off
widgetOverride control:slider,10,1,25
Super! Danke für die Infos.
Das mit dem Read-only hatte ich auch inzwischen rausgefunden. :)
Hallo Zusammen,
ich bin neu hier und bin seit einiger Zeit dabei mein Haus mit fhem "zu vernetzen". Ich habe mittlerweile den Raspberry3 am Laufen mit Anbindung an Fritzbox und Steuerung der Sonos.
Allerdings bin ich seit Längerem an einer Sache am rätseln und benötige Hilfe (das Forum habe ich "rauf und runter" gelesen ;) - Vielen Dank für die vielen nützlichen Infos hier!)
Meine CCU2 ist verbunden und der RPCState läuft. Ich kann auch Steckdosen per fhem schalten und sehe im Eventmonitor die Events vom Schalter / Taster.
Mein Problem ist nun, daß meine notify nicht auf die Events der Taster oder Bewegungsmelder reagieren?! Im Log wird auch nichts eingetragen - obwohl im Eventmonitor alles angezeigt wird.
Beispiel eines Tasters:
Readings:
Bei HM-PB-2-WM55-2_MEQ1767068.1.PRESS_SHORT on wird brav das Event mit Uhrzeit angezeigt, wenn ich den Taster drücke.
Wenn ich ein notify definiere mit
s_schalter1:HM-PB.PRESS_SHORT:.* set sd_Dose1 on
oder
s_schalter1:HM-PB.PRESS_SHORT:.on set sd_Dose1 on
reagiert er nicht. Das "HM-PB." habe ich schon weggelassen - geht auch nicht.
Mir ist nun nicht klar, was ich hier falsch mache? Der Schalter1 steht zusätzlich noch auf "Initialized"?!
Kann mir evtl. jemand einen Tipp geben, wo ich ansetzen kann?
Vielen lieben Dank und Gruß,
Torlan
Was bei dem notify schief geht weiß ich leider nicht. Wenn Du das Attribut statedatapoint auf 1.PRESS_SHORT setzt (bei Verwendung von HMCCUDEV) oder auf PRESS_SHORT (bei HMCCUCHN) wird auch state bzw. STATE aktualisiert und das "initialized" verschwindet.
Du kannst auch das Attribut ccureadingformat auf 'datapoint' setzen. Dann werden die Readingnames kürzer.
Hier mal ein Beispiel, das bei mir funktioniert:
define no_test notify HM_FB_BA_1:pressed set d_test $EVENT
Einen Readingnamen gebe ich hier gar nicht an. Könnte daran liegen, dass bei mir STATE aktualisiert wird.
"HM_FB_BA_1" ist das FHEM Device des Schalters, "pressed" das Event. Als Reaktion wird ein Dummy Device (d_test) auf das Event gesetzt. Das Attribut substitute steht auf PRESS_SHORT!(1|true):pressed
Klasse! Nun geht es!!! Vielen Dank - nachdem ich Deine Anweisungen probiert habe, geht es nun. Ob es das statedatapoint oder das ccureading war, kann ich leider nicht sagen.
Aber Du hast mir den Abend gerettet :)
Gruß,
Torlan
Hinweis: Unterschiedliche Skalierung von Werten bei "get update/datapoint" und RPC-Events.
Ich habe jetzt bei 2 meiner Geräte (Dimmer und Stromzählersensor) festgestellt, dass sich die Skalierung der Werte / Datenpunkte unterscheidet zwischen einer CCU Abfrage mit get update oder get datapoint und von der CCU per RPC-Server gesendeten Werte.
Beim Dimmer Datenpunkt LEVEL:
Get Wertebereich: 0-1
Event Wertebereich: 0-100
Beim Stromzählersensor, Datenpunkte ENERGY_COUNTER und POWER:
Get Einheiten: Watt bzw. Wattstunden
Event Einheiten: Kilowatt bzw. Kilowattstunden
Beim Dimmer lässt sich das durch das Attribut ccuscaleval relativ leicht abfangen (0:1:0:100). Beim Stromzählersensor kann man das ebenfalls durch ccuscaleval umrechnen lassen. Allerdings muss man sich hier auf eine Übertragungs-/Abfragemethode festlegen.
Leider ist dieses Verhalten wieder mal nicht einheitlich über alle Gerätetypen. EQ3/ELV Murks eben.
Hallo, habe ein Problem mit dem RPC Server (totaler Anfänger) - sorry, falls die Lösung hier irgendwo steht, 52 Seiten sind recht unübersichtlich, wenn man ein bestimmtes Thema sucht :)
Sieht so aus, als würde der RPC Server nicht laufen...
Log sagt:
2016.09.25 11:28:28 0: CCURPC: CB2010 Creating file queue /tmp_2010
2016.09.25 11:28:28 0: CCURPC: CB2010 Can't create queue
2016.09.25 11:28:28 2: CCURPC: Eventcount DD = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount EV = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount EX = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount IN = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount ND = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount RA = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount RD = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount SL = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount UD = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount total = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount writeerror = 0
2016.09.25 11:28:28 0: RPC server(s) starting
2016.09.25 11:28:35 1: HMCCU: Can't open file queue /tmp_2001
2016.09.25 11:28:35 1: HMCCU: Can't open file queue /tmp_2010
2016.09.25 11:28:35 0: HMCCU: Periodical check found no RPC Servers
2016.09.25 11:28:35 0: HMCCU: All RPC servers stopped
Rechte Problem? Linux ist nicht so meine Stärke... wie bekomme ich das hin?
Hallo zap,
ich bekomme im Logging sowas:
2016.09.25 11:27:58 1: PERL WARNING: Use of uninitialized value $ct in string ne at ./FHEM/88_HMCCU.pm line 1352.
Kannst Du das mal prüfen?
Zitat von: SaschaHL am 25 September 2016, 12:10:55
Hallo, habe ein Problem mit dem RPC Server (totaler Anfänger) - sorry, falls die Lösung hier irgendwo steht, 52 Seiten sind recht unübersichtlich, wenn man ein bestimmtes Thema sucht :)
Sieht so aus, als würde der RPC Server nicht laufen...
Log sagt:
2016.09.25 11:28:28 0: CCURPC: CB2010 Creating file queue /tmp_2010
2016.09.25 11:28:28 0: CCURPC: CB2010 Can't create queue
2016.09.25 11:28:28 2: CCURPC: Eventcount DD = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount EV = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount EX = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount IN = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount ND = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount RA = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount RD = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount SL = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount UD = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount total = 0
2016.09.25 11:28:28 2: CCURPC: Eventcount writeerror = 0
2016.09.25 11:28:28 0: RPC server(s) starting
2016.09.25 11:28:35 1: HMCCU: Can't open file queue /tmp_2001
2016.09.25 11:28:35 1: HMCCU: Can't open file queue /tmp_2010
2016.09.25 11:28:35 0: HMCCU: Periodical check found no RPC Servers
2016.09.25 11:28:35 0: HMCCU: All RPC servers stopped
Rechte Problem? Linux ist nicht so meine Stärke... wie bekomme ich das hin?
Hab es wohl hin.... hab ein Verzeichnis /opt/fhem/tmp angelegt, als Besitzer fhem zugewiesen und das Attribut entsprechend des neuen Ordners geändert.... sieht gut aus...
Traue mich mal hier mit einer Zwischenfrage, weil ja hier die meisten Leute mit zap's Modul zu finden sein dürften:
Verwendet Ihr alle eine eigene CCU2-Hardware oder hat schon mal jemand die CCU2-Software parallel zu FHEM auf dem gleichen Gerät installiert oder weiß davon? Frage mich schon länger, ob mein Raspi 2 das wuppen würde. Ein HomeMartic-Aufsteckmodul würde dann der CCU2 zugeordnet werden und nicht FHEM.
Ich such mir irgendwie gerade den Wolf nach solchen Beiträgen, mir fehlt der Überblick. Ein "geht nicht" oder "lasses lieber weil" wäre ja auch eine Antwort.
ich hatte lxccu neben her mal auf fhem laufen mit dem hm-cfg-lan. man merkt nicht , bezogen auf die fhem performance, dass die mit läuft. warum auch, die ccu2 hat gerademal 454MHz und 256mb ram.
Hallo,
ich habe einen Smartzähler welchen ich über Fhem auslesen und an die CCU2 sende. Dies funktioniert auch wunderbar. Jetzt habe ich einen dummy mit dem Wert z.bsp: 3 diesen möchte ich ebenfalls übergeben. Es klappt aber einfach nicht. Hier ist mein Script:
define biotonne dummy
define biotonne_setvar notify MuellterminDummy:BioTonne:.* set CCU2 var test $EVTPART1
Der Wert 3 ist im Dummy enthalten wird aber nicht an die CCU 2 gesendet. Die Variable ist richtig angelegt, da sie mit dem Reading vom Stromzähler funktioniert. Könnt ihr mir helffen. Danke
Hi zap,
heute habe ich meine CCU rebootet.
Danach haben die Tür- und Fenstersensoren in fhem nicht mehr funktioniert.
Alle meine Fenster wurden als geschlossen angezeigt.
Dann schoss und öffnete ich ein Fenster: Siehe da, war wieder richtig.
Bei einem anderen Fenster machte ich zweimal einen "update". Dann war's auch wieder richtig.
Die anderen ließen sich aber auch über "update" oder "devstate" nicht davon überzeugen, dass sie offen sind.
Erst, als ich alle Fenster einmal öffnete und schloss, war der Statusupdate in Fhem wieder erfolgreich.
Bitte mal prüfen, woran das liegen kann.
Mit den anderen Geräten schien es keine Probleme zu geben.
Viele Grüße
Alex
Das ist kein Problem des Moduls sondern der CCU. Nach einem Reboot sind für sie alle Fensterkontakte grundsätzlich geschlossen. Auch ein "Update-Request" bringt nichts, da das passive Sensoren sind, deren Status nicht aktiv abgefragt werden kann.
Und, übrigens, ich würde VOR dem Schießen ein Fenster öffnen, nicht danach ;-) SCNR.
Zitat von: Ralli am 27 September 2016, 18:22:22
Und, übrigens, ich würde VOR dem Schießen ein Fenster öffnen, nicht danach ;-) SCNR.
Das erklärt auch die hässlichen Löcher. Danke. 8) ;D
Ich bin mir nicht ganz sicher, ob das hier der richtige Thread ist, aber ich habe keinen besseren gefunden.
Bisher hatte ich an FHEM zwei CULs am laufen und eine HM-LAN-CFG per Ethernet, die dann zu einer VCCU zusammengefasst waren.
Jetzt wollte ich noch besseren Empfang im Keller haben, und da es den HM-LAN-CFG nicht mehr gibt, und die CCU2 als Bausatz dasselbe kostet wie HM-LGW-O-TW-W-EU, habe ich mir eine CCU2 gekauft.
Nun habe ich folgende Fragen:
- kann eine CCU2 die über das HMCCU-Modul eingerichtet ist, vernünftig als Bestandteil einer VCCU arbeiten?
- wie stelle ich in der CCU2 die Homematic-ID ein, da ich nicht alle meine Devices umkonfigurieren möchte. (evtl. in /var/ids ?)
- gibt es noch etwas zu beachten beim VCCU-Betrieb des CCU2?
Danke schonmal für alle Hinweise,
Thomas
Nee. Eine per HMCCU angebundene CCU2 ersetzt kein LAN-Gateway, wie es die in FHEM integrierten Homematic-Funktionen benötigen, sondern stellt eine komplett alternative Methode zur Zustandserfassung und Steuerung von Homematic-Komponenten dar. Vereinfacht gesprochen sind die Komponenten dann keine "CUL_HM"-Geräte mehr, sondern "HMCCUDEV"-Geräte. Administration des HM-Zoos wie Verschlüsselung, Firmwareupdates, Direktverknüpfungen komplett in der CCU. Die per HMCCUDEV angelegten Geräte in FHEM sind dann quasi Spiegel der Geräte dort, mit beidseitiger Kommunikation und Statusupdates.
Guck mal auch hier: https://forum.fhem.de/index.php/topic,40189.msg475633/topicseen.html#msg475633 (https://forum.fhem.de/index.php/topic,40189.msg475633/topicseen.html#msg475633), letzter Satz!
Der CCU eine Homematic-ID vorzugeben ist problemlos möglich, genaues müsste ich selbst erst wieder suchen.
Parallelbetrieb von HMLAN(D) via FHEM und CCU2 mit gleicher HM-ID ist nicht vernünftig möglich, die Geräte erkennen das jeweils andere als Störer im Funkverkehr (vereinfacht gesagt).
ich meine das thema vccu und ccu2 kannst du gleich knicken da die ccu kein iodev für die vccu ist wie etwa hmlan,hmusb oder cul.
entweder stellst du auf ccu2 um oder bleibst bei hm-modulen von martin (inkl vccu).
wie du die hmid in der cuu2 setzt steh im wiki meine ich iund im marktplatz wurde es erwähnt in dem einen thema wo jemand die ccu2 verkauft hat
hi,
ich bräuchte mal hilfe beim rgbw contoller da ich mit den ganzen attributen um die hmccu devices userfreundlich nutzbat zu machen auf kriegsfuß stehe.
er ist mit 3 channels als je hmccuchn eingeunden. ziel ist in userfreundlich schaltbar zu machen.
chn1 - helligkeit - az_rgbw_01_dim soll in fhemweb on/off/dimslider können
chn2 - color - az_rgbw_01_color soll im fhemweb wie wiflight rgb, colorpicker können
chn3 - auto - az_rgbw_01_auto da weiss ich noch nicht was er können soll. die programme 0-6 starten (stop und 1-6 die 5 standardprogramme)
ZitatInternals:
CFGFN
DEF az_rgbw_01:1
IODev CCU01
NAME az_rgbw_01_dim
NR 5109
STATE 1.000000
TYPE HMCCUCHN
ccuaddr NEQ0183567:1
ccudevstate Active
ccuif BidCos-RF
ccuname az_rgbw_01:1
ccutype HM-LC-RGBW-WM
channels 1
statevals devstate|on|off
Helper:
Dblog:
State:
Mydblog:
TIME 1475085112.42466
VALUE Initialized
Readings:
2016-09-28 19:52:03 R-az_rgbw_01.1.AES_ACTIVE 0
2016-09-28 21:11:46 az_rgbw_01.1.DIRECTION 0
2016-09-28 19:52:34 az_rgbw_01.1.INHIBIT false
2016-09-28 21:11:46 az_rgbw_01.1.LEVEL 1.000000
2016-09-28 21:11:46 az_rgbw_01.1.WORKING 0
2016-09-28 21:11:46 state 1.000000
Attributes:
DbLogExclude .*
IODev CCU01
room HM
statedatapoint 1.LEVEL
statevals on:1.000000,off:0.000000
ZitatInternals:
CFGFN
DEF az_rgbw_01:2
IODev CCU01
NAME az_rgbw_01_color
NR 5125
STATE 33
TYPE HMCCUCHN
ccuaddr NEQ0183567:2
ccudevstate Active
ccuif BidCos-RF
ccuname az_rgbw_01:2
ccutype HM-LC-RGBW-WM
channels 1
statevals devstate
Helper:
Dblog:
State:
Mydblog:
TIME 1475085246.18367
VALUE Initialized
Readings:
2016-09-28 19:54:16 R-az_rgbw_01.2.AES_ACTIVE 0
2016-09-28 19:54:16 R-az_rgbw_01.2.WHITE_ADJUSTMENT_VALUE_BLUE 100
2016-09-28 19:54:16 R-az_rgbw_01.2.WHITE_ADJUSTMENT_VALUE_GREEN 100
2016-09-28 19:54:16 R-az_rgbw_01.2.WHITE_ADJUSTMENT_VALUE_RED 100
2016-09-28 21:41:08 az_rgbw_01.2.COLOR 33
2016-09-28 19:56:27 az_rgbw_01.2.INHIBIT false
2016-09-28 21:41:08 state 33
Attributes:
DbLogExclude .*
IODev CCU01
room HM
statedatapoint 2.COLOR
ZitatInternals:
CFGFN
DEF az_rgbw_01:3
IODev CCU01
NAME az_rgbw_01_auto
NR 5158
STATE Initialized
TYPE HMCCUCHN
ccuaddr NEQ0183567:3
ccudevstate Active
ccuif BidCos-RF
ccuname az_rgbw_01:3
ccutype HM-LC-RGBW-WM
channels 1
statevals devstate
Helper:
Dblog:
State:
Mydblog:
TIME 1475085455.07025
VALUE Initialized
Readings:
2016-09-28 19:57:45 R-az_rgbw_01.3.AES_ACTIVE 0
2016-09-28 19:57:45 R-az_rgbw_01.3.COLOR_CHANGE_SPEED 10
2016-09-28 19:57:46 az_rgbw_01.3.ACT_BRIGHTNESS 0
2016-09-28 19:57:46 az_rgbw_01.3.ACT_MAX_BOARDER 0
2016-09-28 19:57:46 az_rgbw_01.3.ACT_MIN_BOARDER 0
2016-09-28 19:57:46 az_rgbw_01.3.INHIBIT false
2016-09-28 19:57:46 az_rgbw_01.3.ON_TIME 0.000000
2016-09-28 21:51:19 az_rgbw_01.3.PROGRAM 7
2016-09-28 19:57:46 az_rgbw_01.3.RAMP_TIME 0.500000
2016-09-28 19:57:40 state Initialized
Attributes:
DbLogExclude .*
IODev CCU01
room HM
statedatapoint 2.COLOR
vielen dank schon mal
chris
den dimmerchanenl konnte ich schon dazu bewegen on/off zu zeigen, jedoch nur bei 100 oder 0. kann ich bei substitute auch sagen alle was größer 0 ist, ist on? wie kann ich befehle wie dimup / dimdown einbinden (oder den dimmer slider)?
ZitatIODev CCU01
ccuscaleval LEVEL:0:1:0:100
room HM
statedatapoint 1.LEVEL
statevals on:100,off:0
substitute LEVEL!100:on,0:off
webCmd on:off
Zitat von: Pfriemler am 28 September 2016, 17:00:32
Nee. Eine per HMCCU angebundene CCU2 ersetzt kein LAN-Gateway, wie es die in FHEM integrierten Homematic-Funktionen benötigen, sondern stellt eine komplett alternative Methode zur Zustandserfassung und Steuerung von Homematic-Komponenten dar. Vereinfacht gesprochen sind die Komponenten dann keine "CUL_HM"-Geräte mehr, sondern "HMCCUDEV"-Geräte. Administration des HM-Zoos wie Verschlüsselung, Firmwareupdates, Direktverknüpfungen komplett in der CCU. Die per HMCCUDEV angelegten Geräte in FHEM sind dann quasi Spiegel der Geräte dort, mit beidseitiger Kommunikation und Statusupdates.
Guck mal auch hier: https://forum.fhem.de/index.php/topic,40189.msg475633/topicseen.html#msg475633 (https://forum.fhem.de/index.php/topic,40189.msg475633/topicseen.html#msg475633), letzter Satz!
Der CCU eine Homematic-ID vorzugeben ist problemlos möglich, genaues müsste ich selbst erst wieder suchen.
Parallelbetrieb von HMLAN(D) via FHEM und CCU2 mit gleicher HM-ID ist nicht vernünftig möglich, die Geräte erkennen das jeweils andere als Störer im Funkverkehr (vereinfacht gesagt).
Vielen Dank für diese exzellente Zusammenfassung... Einiges davon hatte ich schon vermutet, aber nirgends wirklich so niedergeschrieben gefunden. Ich werde mir jetzt überlegen, ob ich die CCU2 als Master betreibe und den HM-CFG-LAN als Slave an die CCU2 anbinde. Dann würde ich den CUL für FS20-Spielereien nehmen.
Gibt es irgendwelche Nachteile, wenn man FHEM an eine CCU2 anbindet, statt FHEM als Homematic-Master zu nutzen? Oder sind die Verknüpfungen und Events einfach nur "anders", und im Endeffekt lässt sich über FHEM trotzdem alles steuern und realisieren.
Zitat von: tobox am 29 September 2016, 14:04:41
Gibt es irgendwelche Nachteile, wenn man FHEM an eine CCU2 anbindet,
man könnte als nachteil sehen das du nach dem define der HMMCUDEv oder HMCCUCHN noch vieles in fhem an attributen setzen musst um das device userfreundlich schaltbar zu machen. die cul_hm devices sind quasie nach dem autocreate fertig.
Zitat
sind die Verknüpfungen und Events einfach nur "anders", und im Endeffekt lässt sich über FHEM trotzdem alles steuern und realisieren.
die selben, nur das du sie nicht umständlich über ellenlange fhembefehle und register erstellen musst sondern einfach nur in der ccu zusammen klickst. in fhem hast du mit dem peeren dann ncihts mehr zu tun
Da sag ich Danke für diese Zusammenfassung :-)
Zitat von: chris1284 am 29 September 2016, 14:59:56
man könnte als nachteil sehen das du nach dem define der HMMCUDEv oder HMCCUCHN noch vieles in fhem an attributen setzen musst um das device userfreundlich schaltbar zu machen. die cul_hm devices sind quasie nach dem autocreate fertig.
Also ich habe auch noch eine Menge Handarbeit üblicherweise, insbesondere sind die Namen nicht immer benutzerfreundlich. Homematic-Martin gibt sich aber unglaubliche Mühe, alles so einfach wie möglich zu gestalten, aber jedes neue Gerät ist eine neue Herausforderung (die er bisher immer bewundernswert gemeistert hat). Das wird aber in der CCU2 meist recht komfortabel integriert, siehe RGBW-Modul oder die Innensirene. Vor allem etwas seltsame Geräte sind in der CCU quasi ab Werk integriert.
Zitatdie selben, nur das du sie nicht umständlich über ellenlange fhembefehle und register erstellen musst sondern einfach nur in der ccu zusammen klickst. in fhem hast du mit dem peeren dann ncihts mehr zu tun
Wenn man die Syntax einmal verinnerlicht hat, geht es eigentlich auch in FHEM einfach, aber die Einstiegschwelle ist deutlich höher. Zudem hat Martin die "templates" entwickelt, mit der sich ganze Registersätze auf einmal setzen lassen. Aber in der CCU gibt es für viele einfache Aufgaben wie einen Treppenlichtautomaten einen eigenen Eintrag in einer Klickdown-Liste. Was der CCU m.W. fehlt, sind Backup und Restores. Einen defekten Aktor durch einen anderen zu ersetzen, indem man seine Registerprogrammierung komplett in den Ersatz überträgt, das hat schon was...
Ich hatte wegen der Klick-und-fertig-Oberfläche auch einmal eine CCU2, aber da war das HMCCU noch nicht so ausgereift wie jetzt. Jetzt bin ich sogar am Überlegen, meinen ganzen Zoo von gut 30 Geräten wieder auf eine CCU umzuziehen. Aber zwei Geräte, zwei (völlig unterschiedliche) Oberflächen ...
Letztlich muss jeder selbst wissen, was er für sich besser findet.
warum ist setlist als attribut eigentlich nicht verfügbar? würde hier weiterhelfen weil ich dann den slider einbauen könnte für level und color
Zitat von: chris1284 am 28 September 2016, 21:52:32
hi,
ich bräuchte mal hilfe beim rgbw contoller da ich mit den ganzen attributen um die hmccu devices userfreundlich nutzbat zu machen auf kriegsfuß stehe.
er ist mit 3 channels als je hmccuchn eingeunden. ziel ist in userfreundlich schaltbar zu machen.
chn1 - helligkeit - az_rgbw_01_dim soll in fhemweb on/off/dimslider können
chn2 - color - az_rgbw_01_color soll im fhemweb wie wiflight rgb, colorpicker können
chn3 - auto - az_rgbw_01_auto da weiss ich noch nicht was er können soll. die programme 0-6 starten (stop und 1-6 die 5 standardprogramme)
vielen dank schon mal
chris
Hallo zusammen,
leider scheitere ich derzeit auf sämtlichen Wegen der Homeatic-Integration in FHEM (Fritzbox, Hue, Intertechno-Funksteckdosen laufen alle).
Nun dachte ich, ich hätte hier die Eierlegende Wollmilchsau gefunden, scheitere aber an anderer Front: Beim installieren von RPC::XML::Server in perl. Ist hier durch Zufall noch jemand mit FHEM auf einer Synology unterwegs und hat das Modul installieren können? Nutze die Perl Distribution aus dem Paket-Zentrum, die per ipkg macht nur einen segfault beim aufrufen, ist also auch keine Alternative.
für alle Zuschriften Dankbar!
Gruß
Eddie8
40€ in die hand nehmen und eine pi kaufen wäre die lösung. warum sich selbst und fhem zwangskastrieren? diese günstigen home nas sind nur halbwegs als nas zu gebrauchen, mehr aber auch nicht
(unur meine meinung). evtl hilft das weiter, das ist definitiv ehr was für den nas-bereich https://forum.fhem.de/index.php/topic,9649.msg53769.html#msg53769 . martin wäre also ein guter ansprechpartner
hallo zap, warum kennen channel kein control? so kannman diese nicht mit controls belegen was sehr schade ist
die beschreibung aus der chmdref zu hmccuchn ist somit verkehrt meine ich
Zitatcontroldatapoint <datapoint>
Set datapoint for device control. Can be use to realize user defined control elements for setting control datapoint. For example if datapoint of thermostat control is SET_TEMPERATURE one can define a slider for setting the destination temperature with following attributes:
attr mydev controldatapoint SET_TEMPERATURE attr mydev webCmd control attr mydev widgetOverride control:slider,10,1,25
das geht irgendwie nur bei devices. und controldatapoint müsste dann, wenn es nur für devices geht, mehrere werte annehmen können so das man zb für alle 3 chn je ein slider bauen kann
@chris1284:
Es scheiterte weniger an den 40€ (eine PI3 hab ich) als am Starrsinn, das auch so hinzubekommen, schließlich ist die Performance von dem NAS mehr als ausreichend. Schade, dass es an sowas banalem wie der Perl-Distribution scheitert.
Bin jetzt aber auf den PI3 umgezogen, 3 Abende basteln vs. 2 Stunden PI einrichten und alles drin. Insofern danke für den Hinweis! Ja, das hat seine Vorzüge, wenn es auch ein Workaround und keine Lösung des Problems ist. ;)
das proble ist halt neben perl auch der treibersupport. hättest du diese eine perl modul zum laufen bekommen wärest du evtl beim nächsten modul mit einem anderen perl modul wieder gescheitert.
Hallo,
hab eine Frage zu Systemvariablen. In fhem im Bild "DeviceOverview" werden die Eigenschaften von HMCCU dargestellt. Unter Readings sieht man alle Systemvariablen der CCU-2. Allerdings nicht aktualisiert. Erst mit dem Start des scripts HMTEST.SCR aktualisieren sich die Werte.
In der Homatic sind Temperaturen, die ich über den wiffi-pump in die CCU schreibe, dort aber nicht als Kurve darstellen kann. In fhem wäre das wesentlich einfacher.
Wie kann ich in fhem die Variablen auslesen und z.B. zur Anzeige bringen und für ein LogFile nutzen?
Danke.
Urlaub muss auch mal sein. Daher sorry, wenn ich die letzten 2 Wochen etwas schweigsam war. Ich werde versuchen, die Fragen in den nächsten Tagen zu beantworten. Stay tuned ...
So, hier mal einige Antworten:
@SaschaHL: Du hast vermutlich im IO-Device das Attribut rpcqueue falsch gesetzt. Dieses Attribut legt den vollen Prefix der Queue-Files inkl. Verzeichnis fest. Wenn das Attribut nicht gesetzt ist, ist der Default /tmp/ccuqueue. Wenn Du das Attribut nicht setzt, benötigt fhem Schreibrechte im Verzeichnis /tmp. In Deinem Fall kannst Du das Attribut auf /opt/fhem/tmp/ccuqueue setzen, wenn Du Dein angelegtes Verzeichnis nutzen willst. Ansonsten lösche das Attribut. FHEM sollte eigentlich Schreibrechte in /tmp haben.
@aski71: Die Fehlermeldung "use of uninitialized value $ct" kommt daher, dass eines der Module, die Du verwendest, das Internal "TYPE" nicht gesetzt hat. Sehr seltsam, da das FHEM Standard ist. Ist unschön, sollte aber für HMCCU keine Auswirkungen haben.
Nach dem Reboot der CCU muss der RPC-Server neu gestartet werden, da die CCU beim Reboot die registrierten RPC-Abnehmer (hier FHEM) vergisst.
@bumbumb: Ich nehme an, Dein notify ist falsch. Schreibe doch mal als Reaktion auf Dein notify EVTPART1 in ein anderes Dummy. Dann siehst Du, ob es grundsätzlich funktioniert.
@chris1284: Zu Deiner Frage bzgl. Webdarstellung später. Muss ich mir im Detail anschauen. Bei HMCCUCHN ist aufgrund eines Bugs in der FHEM Oberfläche der Befehl "set control" nicht vorhanden. Per Kommandozeile sollte er aber funktionieren. Wird korrigiert.
@vorhand: Die CCU Systemvariablen werden von der CCU leider nicht über die RPC-Schnittstelle aktualisiert. Daher bekommt FHEM Änderungen nicht mit. Ich empfehle Dir, in FHEM ein AT Device einzurichten, mit dem regelmäßig der Befehl "get xy vars .*" ausgeführt wird. Das Intervall würde ich nicht zu klein wählen (versuche mal 5 oder 10 Sekunden) um die CCU nicht zu sehr zu belasten.
Danke - soll ein AT-Device einrichten!?
Könntest du ein paar Zeilen Code als Beispiel schreiben?
Die Ansprache der Systemvariablen in fhem gelingt mir nicht.
Grüße
Zitat von: Vorhand am 06 Oktober 2016, 12:49:43
Danke - soll ein AT-Device einrichten!?
Könntest du ein paar Zeilen Code als Beispiel schreiben?
Die Ansprache der Systemvariablen in fhem gelingt mir nicht.
Grüße
Ungefähr so: Wenn Dein IO-Device CCU2 heißt, aktualisiert das folgende AT-Device die Variablen Readings in FHEM jede Minute:
define updatevars at +*00:01:00 get CCU2 vars .*
Bei CCU2 das Attribut ccureadings auf 1 setzen. Um eine Variable in der CCU zu setzen, muss diese zunächst in der CCU angelegt werden. Dann kannst Du in FHEM z.B. folgendes machen:
set CCU2 var Test Wert
Hallo zap, das Setzen der Variablen geht super.
Wie kann ich sie in fhem auslesen und weiterverarbeiten?
Mein Versuch des FileLog:
define FileLog_d_ccu FileLog ./log/d_ccu-%Y-%m.log d_ccu:.*
geht leider nicht!
Was mache ich falsch?
Dein Log-Statement sieht soweit gut aus. Es bewirkt, dass alle Trigger-Meldungen vom Device d_ccu und Änderungen von Readings in das Logfile geschrieben werden. Wenn Dein IO-Device d_ccu heißt, musst Du zunächst dafür sorgen, dass die Readings überhaupt geschrieben werden:
attr d_ccu ccureadings 1
attr d_ccu event-on-change-reading .*
Ggf. event-on-change-reading durch event-on-update-reading ersetzen, wenn bei jeder Aktualisierung ein Logfle Eintrag geschrieben werden soll.
Nun einmal manuell eine Variable aus der CCU abfragen. Angenommen, die Variable heißt "TEST", dann lautet der Befehl:
get d_ccu vars TEST
Nun muss zunächst ein Reading TEST im FHEM-Device d_ccu erscheinen und außerdem ein Eintrag im Logfile geschrieben werden. Gleiches Spiel für alle Variablen:
get d_ccu vars .*
Um das zu automatisieren, das oben beschriebene AT verwenden, um den get Befehl regelmäßig auszuführen.
Ja, jetzt füllt sich das File.
Hatte das attr d_ccu event-on-change-reading auf 1 gesetzt
geht nicht!
attr d_ccu event-on-change-reading .*
geht!
Alle Systemvariablen bekommt man mit
attr d_ccu event-on-update-reading .*
Danke
Zitat von: zap am 06 Oktober 2016, 11:19:42
@aski71: Die Fehlermeldung "use of uninitialized value $ct" kommt daher, dass eines der Module, die Du verwendest, das Internal "TYPE" nicht gesetzt hat. Sehr seltsam, da das FHEM Standard ist. Ist unschön, sollte aber für HMCCU keine Auswirkungen haben.
Nach dem Reboot der CCU muss der RPC-Server neu gestartet werden, da die CCU beim Reboot die registrierten RPC-Abnehmer (hier FHEM) vergisst.
Danke.
Das mit dem Reboot und RPC-Server ist klar.
Um das andere Thema muss ich mir also keine weiteren Sorgen machen? Es ist seitdem auch nicht mehr aufgetreten.
VG Alex
@vorhand: die "event-on-..." Attribute gehören zu FHEM und haben mit HMCCU nichts zu tun. Bei change wird nur ein Event ausgelöst, wenn sich der Wert eines Readings ändert. Bei update auch dann, wenn ein Reading aktualisiert wird (also auch wenn der neue Wert identisch ist).
@askiz1: habe den Code an der genannten Stelle überprüft. Ist in Ordnung. Hier werden alle FHEM Devices überprüft, ob sie vom Typ HMCCUCHN oder HMCCUDEV sind. Bei einem deiner FHEM Devices konnte der Typ nicht ermittelt werden. Warum ist mir unklar. Könnte ich abfangen, wäre aber aufwändig und macht nicht wirklich sinn, da es kein HMCCU Thema ist.
Hallo zap,
Homatic 8-Kanal-Funk-Empfangsmodul HM-MOD-Re-8
Wenn ich dieses Teil aus fhem mit "set HM_S85_01 on-for-timer 5" ansteuere, blinkt das Teil 5 mal. Auch on-til 09:50 führt zu blinken - also Ein/Aus im SekundenRhythmus, bis die Zeit erreicht ist. Normales on ist stabil.
Hast du eine Idee?
Danke
das blinken bei on-for-timer ist normal würde ich behaupten, das macht zb der 2 / 4 kanal aktorbausatz auch. er blinkt bis zum ablauf der zeit und ist dabei dauer on (und nicht ein/aus/ein/aus)
Entschuldigung - hatte noch keine Last dran.
Mit Relais hab ich es sofort gesehen, dass das Blinken nur einen Zeitablauf signalisiert.
Danke für die schnelle Antwort chris1284.
Hallo!
Es gab ja in der Mitte des Threads schon einmal das Thema des automatischen Reconnects, wenn die Verbindung zur CCU abreißt bzw. diese neu startet. Damals am die Meldung dazu:
HMCCU: Received no events from CCU since 300 seconds
Gibt es irgendeine Möglichkeit, auf dieses Event zu "triggern" und den RPC-Server neu zu starten?
Danke und Grüße
Phil
Neben dem genannten Logfile Eintrag gibt es auch ein Event:
"No events from CCU since nnn seconds"
Wobei nnn dem Attribut rpctimeout entspricht, das per Default auf 300 Sekunden steht. Das Event kannst Du mit einem Notify abfangen und als Reaktion den RPC-Server neu starten. Du solltest rpctimeout mit Bedacht wählen. Wenn Du nur wenige Geräte hast, könnten 300 Sekunden zu wenig sein und der RPC-Server würde ohne Not neu starten.
Wenn ich mal Zeit habe, werde ich einen aktiven CCU Keepalive Check einbauen. Aber auch so ein Check kann natürlich (je nach Prüfintervall) einen Neustart der CCU "übersehen". Dann wäre der o.g. Event doch wieder die Lösung.
P.S. Oh, ich sehe gerade, das war mein Iron Maiden Beitrag: 666 ;-)
Hallo!
Danke für die Antwort. Mir ist leider nicht klar, wie so ein notify aussehen müsste. Ich finde dazu auch keine Beispiele.
Kannst du mir einen Tipp zur Syntax geben?
Vielen Dank!!
Zitat von: zap am 15 Oktober 2016, 17:49:21
P.S. Oh, ich sehe gerade, das war mein Iron Maiden Beitrag: 666 ;-)
\m/ \m/ \m/ \m/ \m/ \m/ \m/ \m/ \m/ \m/ \m/ \m/ \m/ \m/ \m/ \m/
I'm not a number, I'm a free FHEMler!!! ;)
(Sorry für Off-Topic, aber das MUSSTE sein)
Hallo!
Ich muss noch eine Frage nachschieben:
Wie sieht es mit den Einschränkungen von HMCCU gegenüber einer "direkten" HM-Ansteuerung aus? Ich habe bisher zum Test an einer CCU2 einen HM-TC-IT-WM-W-EU Wandthermostat angelernt. Scheinbar gibt es im Gegensatz zur Direktansteuerung über einen HMLAN nicht die Möglichkeit, das Zeitmodell zu ändern über FHEM.
Habe ich hier etwas übersehen, oder gibt es hier einfach Parameter, die nicht über FHEM angepasst werden können?
Danke und Grüße
Die Zeitmodelle werden nicht über Datenpunkte eingestellt sondern über Config-Parameter. Du musst also einen "Set Config" Befehl verwenden. Die verfügbaren Parameter kann man sich bei den meisten Geräten per "get configdesc" anzeigen lassen.
Hallo!
Bei 'get configdesc' bekomme ich leider:
HMCCUDEV: HMTHERMO No response from CCU
Mache ich etwas falsch?
Grüße
Versuch mal, eine Kanalnummer anzugeben. Am besten schaust Du Dir die Geräteeinstellungen in der CCU an. Dort siehst Du, für welche Kanäle überhaupt Einstellungen möglich sind.
Wenn HMTHERMO Dein Device ist, probier mal:
get HMTHERMO configdesc 1
get HMTHERMO configdesc 2
Übrigens kann man Config-Parameter auch auslesen und als Reading speichern lassen (fangen dann mit "R-" an).
get HMTHERMO config 1
Hallo!
get HMTHERMO configdesc 1
get HMTHERMO configdesc 2
--> liefert leider auch HMCCUDEV: HMTHERMO No response from CCU
get HMTHERMO config 1
--> hat prima funktioniert und ich sehe alle Profile.
Kannst Du mir noch einen Tipp geben, wie ich diese dann ändere?
set config HMTHERMO R-HMTHERMO.P1_TEMPERATURE_FRIDAY_1 21
set config HMTHERMO R-HMTHERMO.P1_TEMPERATURE_FRIDAY_1=21
set config HMTHERMO P1_TEMPERATURE_FRIDAY_1=21
set config HMTHERMO P1_TEMPERATURE_FRIDAY_1 21
...hat leider nicht funktioniert.
Grüße und Danke!
Phil
Die CCU stellt leider nicht für alle Gerätetypen Beschreibungen zur Verfügung. Welchen Typ Thermostat hast Du denn?
Um die Parameter für ein HMCCUDEV Device zu setzen, musst Du den Kanal mit angeben und außerdem "config" und "HMTHERMO" vertauschen:
set HMTHERMO config 1 P1_TEMPERATURE_FRIDAY_1=21
Der Befehl akzeptiert auch mehrere Parameter=Wert Paare.
Kurz zum Hintergrund: Homematic kennt Konfigurationsparameter für Geräte und Kanäle, wobei nicht jeder Gerätetyp beides anbietet. Wenn Du einen Geräteparameter setzen oder auslesen willst, musst Du die Kanalnummer weglassen. Wenn Du hingegen einen Kanalparameter setzen oder auslesen möchtest, musst Du die Kanalnummer mit angeben (so wie im Beispiel oben).
Hallo!
Der Thermostat ist ein HM-TC-IT-WM-W-EU, der mich wohl irgendwie nicht mag.
set HMTHERMO config 1 P1_TEMPERATURE_FRIDAY_1=21
hat leider nichts geändert, obwohl das Device ja auch passen sollte... Es kommt kein Fehler, aber danach ist die Config gleich.
Ich weiß gerade nicht, wo der Fehler liegt.
Hast Du noch eine Idee?
Grüße
Phil
Ich habe das Wandthermostat auch. Werde mal testen, heute aber nicht mehr.
Ahoi,
kann mir mal jemand eine Config für ein HM-LC-Sw2-FM geben?
Ich steh gerade auf dem Schlauch wie ich das einrichten kann.
Bisher hab ich:
Internals:
DEF MEQ1711385 1
IODev d_ccu
NAME Gabionen_Licht
NR 38
STATE Initialized
TYPE HMCCUDEV
ccuaddr MEQ1711385
ccudevstate Active
ccuif BidCos-RF
ccuname Gabionenlicht
ccutype HM-LC-Sw2-FM
channels 3
statevals devstate
Readings:
2016-10-19 12:44:11 state Initialized
Attributes:
IODev d_ccu
statechannel 1
statevals on:true,off:false
substitute STATE!true:on,false:off,1:on,0:off Aber bei nem get devstate bekomme ich
ZitatHMCCUDEV: Gabionen_Licht Invalid datapoint
MfG
Manuel
Eigentlich sieht die Device Definition gut aus, bis auf das Internal statevals. Da müsste wegen dem Attribut statevals eigentlich "devstate|on|off" drin stehen statt nur "devstate". Das hat aber nichts mit der von Dir beschriebenen Fehlermeldung zu tun. Setz einfach mal das Attribut statevals nochmal.
Für den Fehler versuche mal
get Gabionen_Licht datapoint 1.STATE
Falls das auch auf Fehler läuft, führe mal folgendes aus und poste das Ergebnis:
get Gabionen_Licht deviceinfo
Zitat von: Stril am 17 Oktober 2016, 17:52:58
get HMTHERMO config 1
--> hat prima funktioniert und ich sehe alle Profile.
Da es sich bei den Profilen um Geräteparameter und nicht um Kanalparameter handelt, müsste eigentlich folgendes funktionieren
get HMTHERMO config
Zitat
Kannst Du mir noch einen Tipp geben, wie ich diese dann ändere?
set config HMTHERMO R-HMTHERMO.P1_TEMPERATURE_FRIDAY_1 21
set config HMTHERMO R-HMTHERMO.P1_TEMPERATURE_FRIDAY_1=21
set config HMTHERMO P1_TEMPERATURE_FRIDAY_1=21
set config HMTHERMO P1_TEMPERATURE_FRIDAY_1 21
...hat leider nicht funktioniert.
Versuche mal folgendes:
set HMTHERMO config P1_TEMPERATURE_FRIDAY_1=21.0
Die RPC-Schnittstelle der CCU ist hier etwas eigen. Sie hätte die Temperatur gerne mit Dezimalpunkt. Funktioniert so bei mir.
Bei den Config-Parametern ist es hilfreich, sich die Einstellungsseite für das jeweilige Gerät in der CCU anzuschauen, gerade wenn get configdesc nicht unterstützt wird. Dazu in der CCU Oberfläche Einstellungen->Geräte aufrufen und beim Gerät hinten den Button "Einstellungen" drücken. Dann sieht man die Einstellungen gruppiert nach Geräteparametern und Kanalparametern. Dadurch weiß man zumindest, ob man eine Kanalnummer angeben muss.
Ich werde noch eine Möglichkeit einbauen, die verfügbaren Parameter auch dann auszulesen, wenn get configdesc nicht funktioniert. Sonst ist das ein ziemlicher Blindflug.
Hallo!
Vielen Dank!!!
set HMTHERMO config P1_TEMPERATURE_FRIDAY_1=21.0
--> hat funktioniert.
Grüße
Ahoi
get Gabionen_Licht datapoint 1.STATE
liefert:
HMCCUDEV: Gabionen_Licht Invalid datapoint
und
get Gabionen_Licht deviceinfo
liefert:
HMCCUDEV: Gabionen_Licht Execution of CCU script or command failed
Kann das evtl damit zu tun haben, dass in der CCU2 die einzelnen Channels nen anderen Namen haben?
Also das Device heißt da Gabionenlicht und der erste Aktor darunter heißt Gabionenlicht_hinten. Testweises Umbennenen hat leider auch nichts gebracht.
MfG
Manuel
Zitat von: Chaos am 19 Oktober 2016, 20:05:29
Kann das evtl damit zu tun haben, dass in der CCU2 die einzelnen Channels nen anderen Namen haben?
Also das Device heißt da Gabionenlicht und der erste Aktor darunter heißt Gabionenlicht_hinten. Testweises Umbennenen hat leider auch nichts gebracht.
Mit den Kanalnamen hat das nichts zu tun. Mach mal bitte folgendes:
get d_ccu devicelist
Damit liest FHEM die Namen der Geräte in der CCU neu ein. Das ist immer notwendig, wenn in der CCU ein Geräte- oder Kanalname geändert oder ein neues Gerät definiert wurde.
Danach bitte nochmal ein
get Gabionen_Licht deviceinfo
Hallo zap,
ich habe einen HM-PBI-4-FM in meiner CCU2, den ich schnellstmöglich über HMCCU aktualisieren möchte um ein Licht zu schalten. Eine Direktverknüpfung ist nicht möglich da der Schaltaktor eine Siemens LOGO ist. Das rpcserver Intervall habe ich derzeit auf 0,5s gesetzt - jedoch ist mir die Reaktionszeit von ca 1 - 1,5s noch etwas zu lang (das geht über CUL schneller).
ZitatStatt in FHEM ein Notify zu verwenden, könntest Du auch aus der CCU2 heraus ein Reading bzw. ein Dummy Device in FHEM auf den Wert setzen. Wie das geht, hatte ich schon mal irgendwo beschrieben. Du brauchst auf der CCU2 das Programm "nc" (NetCat) sowie am besten noch CuXD. Dann erstellst Du in der CCU2 ein Programm, das bei Änderung einer Variablen ausgeführt wird und entsprechende Werte an FHEM schickt.
Update: Hier ist der Beitrag:
https://forum.fhem.de/index.php?topic=42089.0
Das brachte mich auf die Idee dass bei einem Event auf der CCU ein Reading in FHEM auslöst und den rpcserver aktualisiert. Das Intervall könnte man dann wieder hochsetzen und das System wird weniger belastet. Ich habe mir das schon mal angesehen, jedoch scheitere ich derzeit schon am Passwort vom SPC und vermutlich mangelndem Wissen von Linux.
Macht es Sinn diesen Ansatz weiter zu verfolgen oder mache ich da einen Denkfehler und wird keine Verbesserung bringen?
Gruß
Spielmann
Zitat von: Spielmann am 21 Oktober 2016, 00:29:10
Hallo zap,
ich habe einen HM-PBI-4-FM in meiner CCU2, den ich schnellstmöglich über HMCCU aktualisieren möchte um ein Licht zu schalten. Eine Direktverknüpfung ist nicht möglich da der Schaltaktor eine Siemens LOGO ist. Das rpcserver Intervall habe ich derzeit auf 0,5s gesetzt - jedoch ist mir die Reaktionszeit von ca 1 - 1,5s noch etwas zu lang (das geht über CUL schneller).
So ganz verstehe ich das Problem nicht. Ein Schaltbefehl an den HM-PBI-4-FM über HMCCU ausgelöst wird ja sofort an die CCU bzw. das Device geschickt. Da greift kein Intervall. Lediglich der Rückweg, also die Signalisierung des geänderten Zustands des HM-PBI-4-FM erfolgt über den RPC-Server und ist damit um max. 'rpcinterval' Sekunden verzögert. Oder möchtest Du als Reaktion auf die Meldung (z.B. Licht eingeschaltet) eine weitere Aktion ausführen, bei der die 1-1,5s zu viel sind?
Zitat
Das brachte mich auf die Idee dass bei einem Event auf der CCU ein Reading in FHEM auslöst und den rpcserver aktualisiert. Das Intervall könnte man dann wieder hochsetzen und das System wird weniger belastet. Ich habe mir das schon mal angesehen, jedoch scheitere ich derzeit schon am Passwort vom SPC und vermutlich mangelndem Wissen von Linux.
Macht es Sinn diesen Ansatz weiter zu verfolgen oder mache ich da einen Denkfehler und wird keine Verbesserung bringen?
Was ist "SPC"? Grundsätzlich ist es über den von mir in dem anderen Thread beschriebenen Weg möglich, von der CCU aus beliebige Befehle in FHEM auszuführen. Damit könntest Du z.B. auch ein "get datapoint" oder "get devstate" für Dein HM-PBI-4-FM Device triggern, das dann das entsprechende Reading aktualisiert.
Hallo!
Kurze Info:
Der HMIP-WTH-2 (Wandthermostat für Fußbodenheizung) funktioniert mit HMCCU fast vollständig:
Möglich ist:
- Umschaltung Auto/Manuell
- Manuelle Temperatur vorgeben
- Temperatur, Luftfeuchte auslesen
- Partyzeiten setzen
- Boostmode
- Status (Batterie, etc.)
Bisher nicht möglich:
- Zeitprofile über FHEM setzen (hierzu gibt es keine Readings)
Hast Du noch eine Idee, wie die Zeitprofile reinkommen könnten?
Grüße
Phil
Zitat von: Stril am 21 Oktober 2016, 10:31:48
Bisher nicht möglich:
- Zeitprofile über FHEM setzen (hierzu gibt es keine Readings)
Hast Du noch eine Idee, wie die Zeitprofile reinkommen könnten?
Doch das geht. Für Zeitprofile gibt es ebenfalls Config-Parameter. Ich kann die heute abend mal hier nachliefern. Allerdings sind die etwas "tricky" zu setzen, da man immer einen Tag komplett definieren muss. Die Zeitangabe erfolgt in Minuten seit 0 Uhr, d.h. 6:30 Uhr morgens wäre dann 6*60+30=390.
Zitat von: zap am 21 Oktober 2016, 11:16:36
Doch das geht. Für Zeitprofile gibt es ebenfalls Config-Parameter. Ich kann die heute abend mal hier nachliefern. Allerdings sind die etwas "tricky" zu setzen, da man immer einen Tag komplett definieren muss. Die Zeitangabe erfolgt in Minuten seit 0 Uhr, d.h. 6:30 Uhr morgens wäre dann 6*60+30=390.
Hallo!
Kannst Du mir da einen Tipp geben? Ich finde keinen "datapoint", der diese Zeiten irgendwie enthält. Bei der HM-Variante (ohne IP) finde ich die Readings, aber beim HmIP-Wandthermostat gibt auch "get d_ccu deviceinfo HMIPTHERMO" nichts Passendes aus.
Danke und Grüße
Hallo zap,
anders herum. Ich habe den HM-PBI-4-FM mit der CCU gepairt und möchte über HMCCU das Devive in fhem ansprechen. Somit greift das Intervall. Anstatt jetzt das Intervall bis auf ein Minimum zu reduzieren, dachte ich man könnte doch bei einem Event in der CCU aktiv über Netcat fhem antriggern und die Werte im RPCserver auf fhem aktualisieren. Somit könnten auch zeitkritische Geschichten umgesetzt werden.
Ich bin noch in der Testphase vom HM-LAN auf HMCCU zu wechseln. Abgesehen von den unkonfortablen Nachteilen gegenüber der direkten HMCUL hat mich folgendes überzeugt eine Umstellung zu testen:
- durch die nicht mehr Verfügbarkeit des HM-LAN bin ich mit der CCU auf der sicheren Seite auch weiter unterstützte Geräte von eq3 zu erhalten (wenn nicht alles eingestellt wird oder eq3 Pleite geht)
- durch die rpc-Schnittstelle kann ich selbst auch als "Programmierlaie" eine Schnittstelle über die datapoints finden.
- eine komfortable Reichweitenvergrößerung ist in der CCU enthalten.
Ist jetzt etwas off Topic:
Noch etwas zum HM-PBI-4-FM (der etwas eigenartig reagiert): Ist der Taster nur mit der CCU gepairt erzeugt der Tasten beim Drücken nur das Event INSTALL-TEST. Ich habe dann ein Dummy Programm in der CCU angelegt, dass nur die 4 Tasten abfragt. Nach einem Druck auf die Install-Taste am HM-PBI-4-FM spricht er dann auch (LONG, SHORT,RELEASE). Damit kann ich jedoch leben (man muss nur darauf kommen).
Ansonsten ein großes Lob an HMCCU. Ohne dem autocreate hätte ich vermutlich das Thema nicht angegangen.
Gruß
Spielmann
update noch vergessen:
ZitatWas ist "SPC"? Grundsätzlich ist es über den von mir in dem anderen Thread beschriebenen Weg möglich, von der CCU aus beliebige Befehle in FHEM auszuführen. Damit könntest Du z.B. auch ein "get datapoint" oder "get devstate" für Dein HM-PBI-4-FM Device triggern, das dann das entsprechende Reading aktualisiert.
Damit meine ich natürlich WINSCP um NetCat auf die CCU zu bekommen.
Gruß
Spielmann
Zitat von: Stril am 21 Oktober 2016, 11:28:05
Hallo!
Kannst Du mir da einen Tipp geben? Ich finde keinen "datapoint", der diese Zeiten irgendwie enthält. Bei der HM-Variante (ohne IP) finde ich die Readings, aber beim HmIP-Wandthermostat gibt auch "get d_ccu deviceinfo HMIPTHERMO" nichts Passendes aus.
Danke und Grüße
Homematic unterscheidet zwischen Datenpunkten (Datapoints) und Config-Parametern. Das was Du in der CCU Weboberfläche unter dem Menü "Status und Bedienung" findest, bezieht sich auf die Datenpunkte. Das sind auch die Dinge, die Du bei HMCCU per get/set datapoint bzw. get/set devstate oder auch get update ansprechen kannst.
Die Config-Parameter findest Du in der CCU unter dem Menü "Einstellungen -> Geräte". Wenn Du in dieser Geräteliste hinter einem Gerät auf den Button "Einstellung" drückst, siehst Du diese Parameter getrennt nach allgemeinen Geräteparametern und Kanalparametern. Diese Parameter werden in HMCCU über die Befehle get/set config bzw. configdesc angesprochen.
Wenn Du nun letztere Aktion für Dein HMIP Thermostat ausführst, müsstest Du bei den Config-Parametern fündig werden, wenn es um Zeitprofile geht. Schau nach, ob die Zeiten für das Gerät oder für einen Kanal (wenn ja Nummer merken) eingestellt werden.
Definiere dann in FHEM ein HMCCUDEV Device für das HMIP-Thermostat und führe einen der folgenden Befehle aus (je nachdem, ob die Zeiten für das Gerät oder einen Kanal eingestellt werden):
get mydev config
get mydev config Kanalnummer
Dann müssten eigentlich die Readings angezeigt werden. Aus den Readingnamen lassen sich dann die Namen der Parameter ableiten, die Du für einen set config Befehl brauchst.
Die Parameter sehen bei einem BidCos Device z.B. so aus:
P1_ENDTIME_FRIDAY_2 = 540
P1_ENDTIME_FRIDAY_3 = 1020
P1_ENDTIME_FRIDAY_4 = 1320
P1_ENDTIME_FRIDAY_5 = 1440
Hi
Zitat von: zap am 20 Oktober 2016, 07:46:34
get d_ccu devicelist
get Gabionen_Licht deviceinfo
letzteres gibt leider
HMCCUDEV: Gabionen_Licht Execution of CCU script or command failedKann ich irgendwo sehen was aus der CCU gelesen wird?
Ich seh nur dass er 80 Channel liest, aber leider nicht welche.
MfG
Manuel
Zitat von: Chaos am 21 Oktober 2016, 15:37:29
Hi
letzteres gibt leider
HMCCUDEV: Gabionen_Licht Execution of CCU script or command failed
Kann ich irgendwo sehen was aus der CCU gelesen wird?
Ich seh nur dass er 80 Channel liest, aber leider nicht welche.
Mach mal bitte folgendes:
attr Gabionen_Licht ccuflags trace
get Gabionen_Licht deviceinfo
Dann schau im fhem-Logfile nach. Da müssten HMCCU oder HMCCUDEV Meldungen drinstehen. Die wären interessant ...
Zitat von: Spielmann am 21 Oktober 2016, 12:30:47
Hallo zap,
anders herum. Ich habe den HM-PBI-4-FM mit der CCU gepairt und möchte über HMCCU das Devive in fhem ansprechen. Somit greift das Intervall. Anstatt jetzt das Intervall bis auf ein Minimum zu reduzieren, dachte ich man könnte doch bei einem Event in der CCU aktiv über Netcat fhem antriggern und die Werte im RPCserver auf fhem aktualisieren. Somit könnten auch zeitkritische Geschichten umgesetzt werden.
Du kannst das so über netcat realisieren. Allerdings triggerst Du nicht den RPC-Server an, sondern führst einfach den Befehl "get update" für das FHEM-Device aus, das Deinem HM-PBI-4-FM entspricht. Damit werden alle Readings aktualisiert (alternativ ein get datapoint, um einen einzelnen Datenpunkt zu aktualisieren).
Zitat
Ist jetzt etwas off Topic:
Noch etwas zum HM-PBI-4-FM (der etwas eigenartig reagiert): Ist der Taster nur mit der CCU gepairt erzeugt der Tasten beim Drücken nur das Event INSTALL-TEST. Ich habe dann ein Dummy Programm in der CCU angelegt, dass nur die 4 Tasten abfragt. Nach einem Druck auf die Install-Taste am HM-PBI-4-FM spricht er dann auch (LONG, SHORT,RELEASE). Damit kann ich jedoch leben (man muss nur darauf kommen).
Das Verhalten ist leider normal bzw. bekannt. Liegt an der CCU. Erst wenn eine Taste mit einem Programm oder einem Gerät verbunden ist, werden die PRESS- und RELEASE-Events generiert. Ich verbinde die immer mit einem Dummy-Programm, das nichts macht oder einfach irgendeine Variable setzt. Du kannst auch alle Taster mit dem gleichen Programm verbinden, indem Du sie einfach per ODER verknüpft abfragst.
Hallo zap,
jetzt habe ich auf der CCU unter /usr/local/addons nc entpackt. CuxD ist installiert.
Im Script auf https://forum.fhem.de/index.php/topic,42089.0.html (https://forum.fhem.de/index.php/topic,42089.0.html) wird vermutlich myfhemserver durch die IP des fhem-Servers ersetzt. Dann hört es bei mir schon auf.
Unter welchem Namen soll ich das Script abspeichern? Vielleicht /usr/local/addons/fhemcomand.sh ?
Muss ich jetz unter CuxD ein Gerät anlegen ? Aber Welches und wo gebe ich den Pfad für das script an?
Wo gebe ich im angelegten Device den Befehl (z.B. get update) ein?
Gruß
Spielmann
Zitat von: Spielmann am 22 Oktober 2016, 01:24:23
Hallo zap,
jetzt habe ich auf der CCU unter /usr/local/addons nc entpackt. CuxD ist installiert.
Im Script auf https://forum.fhem.de/index.php/topic,42089.0.html (https://forum.fhem.de/index.php/topic,42089.0.html) wird vermutlich myfhemserver durch die IP des fhem-Servers ersetzt. Dann hört es bei mir schon auf.
Unter welchem Namen soll ich das Script abspeichern? Vielleicht /usr/local/addons/fhemcomand.sh ?
Muss ich jetz unter CuxD ein Gerät anlegen ? Aber Welches und wo gebe ich den Pfad für das script an?
Wo gebe ich im angelegten Device den Befehl (z.B. get update) ein?
Gruß
Spielmann
Ich habe die Anleitung im Link oben (siehe Zitat) ergänzt.
Ich weiß, es ist hier im FHEM Forum so üblich, Fragen zu bestimmten Modulen in einem einzigen Thread zu diskutieren. Trotzdem überlege ich, den Thread hier auf read only zu setzen, da er doch langsam etwas unübersichtlich wird. Was meint Ihr?
Man könnte ja vor jede HMCCU Frage einfach ein "HMCCU:" voranstellen, damit sich diese Fragen von den CUL_HM Fragen klar abgrenzen. Ist natürlich die Disziplin der Fragesteller etwas gefordert.
wäre io aber für hmccu -module würde ich ehr einen neuen fred öffnen den nur du barbeitest, im homematic bereich anpinnen und dann von dir immer mit den updates / neuerungen gefüttert wird
Hallo,
jo ich wäre auch dafür. Aber wo sollen dann die fragen der Member hin ? Separater Forenbereich oder Posten mit HMCCU voranstellen ?
Hallo,
ich persönlich fände einen separaten Forenbereich für Diskussionen am übersichtlichsten. Dazu sollte es dann einen read-only Thread für die aktuellen Änderungen am Modul und einen für die Beispiele geben.
Viele Grüße
Christian
Ich muss mich mal schlau machen: als normaler User kann ich nur einen eigenen Beitrag schließen. Ich kann werder etwas anpinnen noch ein Unterforum anlegen.
Wenn es so bleibt wie es ist, gibt es schon eine große Verwechslungsgefahr mit Cul_hm. Auch blöd.
Hi
Zitat von: zap am 21 Oktober 2016, 16:07:55
Mach mal bitte folgendes:
attr Gabionen_Licht ccuflags trace
get Gabionen_Licht deviceinfo
Dann schau im fhem-Logfile nach. Da müssten HMCCU oder HMCCUDEV Meldungen drinstehen. Die wären interessant ...
sorry für die späte Rückmeldung.
Bekomme leider nichts anderes als
2016.10.24 10:05:19 1: HMCCUDEV: Gabionen_Licht Execution of CCU script or command failedFalls gewünscht kann ich das gerne in eine eigenes Thema packen.
Edit: Hab den Verbose vom d_ccu mal auf 5 gestellt und seh jetzt im Log (nach shutdown restart):
Device MEQ1711385 has no readable datapointsDanke
Manuel
Ist mir echt ein Rätsel. Kannst Du mal ein list vom IO Device schicken?
Der STATE Datenpunkt muss auf jeden Fall lesbar sein.
Hi
Zitat von: zap am 24 Oktober 2016, 19:38:19
Ist mir echt ein Rätsel. Kannst Du mal ein list vom IO Device schicken?
Der STATE Datenpunkt muss auf jeden Fall lesbar sein.
mir auch :-D
Internals:
Clients :HMCCUDEV:HMCCUCHN:
DEF 192.168.0.111
DelDevices 0
DevCount 80
NAME d_ccu
NR 21
NTFY_ORDER 50-d_ccu
NewDevices 0
RPCPID 23907,23908
RPCPRC internal
RPCState running
STATE OK
TYPE HMCCU
ccutype CCU2
host 192.168.0.111
version 3.4
Readings:
2016-10-24 10:27:46 rpcstate running
2016-10-24 11:22:59 state OK
Hmccu:
evtime 1477297666
evtimeout 1
localaddr 192.168.0.50
rpccount 2
rpcinit 2
updatetime 1477300979
Dp:
Hm-lc-bl1pbu-fm:
Ch:
0:
Aes_key:
oper 1
type 8
Config_pending:
oper 5
type 2
Device_in_bootloader:
oper 5
type 2
Dutycycle:
oper 5
type 2
Rssi_device:
oper 5
type 8
Rssi_peer:
oper 5
type 8
Sticky_unreach:
oper 7
type 2
Unreach:
oper 5
type 2
Update_pending:
oper 5
type 2
1:
Direction:
oper 5
type 16
Inhibit:
oper 7
type 2
Install_test:
oper 2
type 2
Level:
oper 7
type 4
Stop:
oper 2
type 2
Working:
oper 5
type 2
Cnt:
AES_KEY 1
CONFIG_PENDING 1
DEVICE_IN_BOOTLOADER 1
DIRECTION 1
DUTYCYCLE 1
INHIBIT 1
INSTALL_TEST 1
LEVEL 1
RSSI_DEVICE 1
RSSI_PEER 1
STICKY_UNREACH 1
STOP 1
UNREACH 1
UPDATE_PENDING 1
WORKING 1
Spc:
level 1.LEVEL
Hm-lc-sw2-fm:
Ch:
1:
Hm-sec-key-s:
Ch:
0:
Aes_key:
oper 1
type 8
Config_pending:
oper 5
type 2
Dutycycle:
oper 5
type 2
Lowbat:
oper 5
type 2
Rssi_device:
oper 5
type 8
Rssi_peer:
oper 5
type 8
Sticky_unreach:
oper 7
type 2
Unreach:
oper 5
type 2
1:
Direction:
oper 5
type 16
Error:
oper 5
type 16
Inhibit:
oper 7
type 2
Install_test:
oper 2
type 2
Open:
oper 2
type 2
Relock_delay:
oper 2
type 4
State:
oper 7
type 2
State_uncertain:
oper 5
type 2
Cnt:
AES_KEY 1
CONFIG_PENDING 1
DIRECTION 1
DUTYCYCLE 1
ERROR 1
INHIBIT 1
INSTALL_TEST 1
LOWBAT 1
OPEN 1
RELOCK_DELAY 1
RSSI_DEVICE 1
RSSI_PEER 1
STATE 1
STATE_UNCERTAIN 1
STICKY_UNREACH 1
UNREACH 1
Ev:
DD 0
EV 0
EX 0
IN 2
ND 80
RA 0
RD 0
SL 2
ST 0
UD 0
total 84
Rpc:
Cb2001:
cbport 7401
cburl http://192.168.0.50:7401/fh2001
clurl http://192.168.0.111:2001/
loop 2
pid 23907
port 2001
queue /tmp/ccuqueue_2001
state running
Cb2010:
cbport 7410
cburl http://192.168.0.50:7410/fh2010
clurl http://192.168.0.111:2010/
loop 2
pid 23908
port 2010
queue /tmp/ccuqueue_2010
state running
Attributes:
rpcport 2001,2010
rpcserver on
verbose 5 Sieht ein bisschen leer beim Hm-lc-sw2-fm aus...
Danke
Manuel
Ich erlaube mir folgende Frage zu stellen:
Ich beabsichtige einen Temperatur/Feuchte Sensor via HMCCUDEV zu integrieren;
habe aber dabei Probleme!
Vielleich besteht die Möglichkeit dass ein "Experte" mir bitte feedback gibt.
###############################
## Temperatur_Feuchtigkeit: HM-WDS40-TH-I-2
###############################
define Temp_Feuchte_DG HMCCUDEV Temp_Feuchte_DG
attr Temp_Feuchte_DG IODev d_ccu2
attr Temp_Feuchte_DG ccureadingfilter (ERROR|LOWBAT|STATE)
attr Temp_Feuchte_DG event-on-change-reading .*
attr Temp_Feuchte_DG room System
attr Temp_Feuchte_DG statechannel 1
# Werte der CCU2 in den Readings ersetzen
attr Temp_Feuchte_DG substitute LOWBAT!(0|false):no,(1|true):yes
define rg_Temp_Feuchte readingsGroup TYPE=HMCCUDEV:Temp_Feuchte_DG.1.TEMPERATURE,Temp_Feuchte_DG.1.HUMIDITY
attr rg_Temp_Feuchte valueFormat { Temp_Feuchte_DG.1 => "%.1f °C"}
attr rg_Temp_Feuchte alias Temperatur / Feuchtigkeit
attr rg_Temp_Feuchte room Dachgeschoss
Ausgabe:
Temp_Feuchte_DG 12.500000 70
Ich hätte gerne 12.5 °C 70% hier stehen!
Fragen: 1) Wie liest man ein HM-WDS40-TH-I-2 korrekt via HMCCUDEV aus,
sodass mann alle Werte welche in der CCU2 angezeigt werden auch
in den Readings von FHEM sieht
2) Wie formatiert man die Readingwerte 12.500000 70 zu 12.5 °C
und 70%
attr rg_Temp_Feuchte valueFormat { Temp_Feuchte_DG.1 => "%.1f °C"}
hat leider nichts bewirkt
Vielen dank im voraus für Eure Bemühngen
Zitat von: okuegerl am 24 Oktober 2016, 21:13:28
define Temp_Feuchte_DG HMCCUDEV Temp_Feuchte_DG
Muss nicht bei der DEF die Seriennummer des Gerätes hin ? Ich meine das habe ich so bei mir.
Schau auch mal hier, da sind eineige nützliche Beispiele zu Definitionen --> Beispiele (https://forum.fhem.de/index.php/topic,51339.msg464966.html#msg464966)
Zitat von: Chaos am 24 Oktober 2016, 20:14:18
Sieht ein bisschen leer beim Hm-lc-sw2-fm aus...
Danke
Manuel
Ja, das ist der Grund für das Problem. Funktioniert das Teil denn an der CCU korrekt? Ich würde folgendes vorschlagen:
1. FHEM: RPC-Server stoppen
2. CCU: Neu starten
3. FHEM:
3.1 IO-Device: get devicelist ausführen
3.2 IO-Device(!): get deviceinfo CCU-Name, wobei CCU-Name der Name des Aktors in der CCU ist.
3.3 Wenn 3.2 ok, RPC-Server wieder starten
Wenn bei 3.2 wieder ein Fehler kommt, das Gerät in der CCU ablernen und (unter dem gleichen Namen) neu anlernen. Dann die Schritte 3.1 und 3.2 von oben wiederholen.
Zitat von: tuppertasse am 25 Oktober 2016, 08:10:24
Muss nicht bei der DEF die Seriennummer des Gerätes hin ? Ich meine das habe ich so bei mir.
Nein, da kann man sowohl den Namen des Geräts in der CCU als auch seine Adresse bzw. Seriennummer angeben. Beides wird akzeptiert.
Zitat von: zap am 25 Oktober 2016, 08:17:28
Nein, da kann man sowohl den Namen des Geräts in der CCU als auch seine Adresse bzw. Seriennummer angeben. Beides wird akzeptiert.
Ich lerne immer mehr dazu :-) Danke zap
Zitat von: okuegerl am 24 Oktober 2016, 21:13:28
Fragen: 1) Wie liest man ein HM-WDS40-TH-I-2 korrekt via HMCCUDEV aus,
sodass mann alle Werte welche in der CCU2 angezeigt werden auch
in den Readings von FHEM sieht
Du kannst alle Datenpunkte bzw. Readings explizit mit "get update" auslesen. Besser ist aber, den RPC-Server von HMCCU zu starten, dann geht das automatisch.
Zitat
2) Wie formatiert man die Readingwerte 12.500000 70 zu 12.5 °C
und 70%
attr rg_Temp_Feuchte valueFormat { Temp_Feuchte_DG.1 => "%.1f °C"}
hat leider nichts bewirkt
Für state geht das über das FHEM Standard Attribut stateformat. Da kannst Du einfach einen Formatstring angeben. Mit valueFormat habe ich mich noch nicht beschäftigt. Muss ich mir mal anschauen.
Zitat von: tuppertasse am 25 Oktober 2016, 08:25:09
Ich lerne immer mehr dazu :-) Danke zap
Ich hatte einfach keinen Bock, mir die blöden Zahlen zu merken. Ist also meiner Bequemlichkeit geschuldet ;-)
Kann man mit diesem Modul eine CCU2 als "Ersatz" für einen HMLAN-CFG betreiben? Preiswert ist das vielleicht nicht, aber so hätte man mit der CCU2 ein Gerät, um seine HM-Komponenten weiter zu pflegen, nachdem die HMLAN-Software auch nicht mehr weiterentwickelt wird.
Falls das schon irgendwo hier stehen sollte: Bitte nicht lynchen, weil ich jetzt nicht die ganzen 58 Seiten gelesen habe.
Hi,
hat jemand schon mal eine Konfig für den WinMatic Fensterantrieb gemacht und kann diese teilen?
Danke und viele Grüße
Alex
Zitat von: topfi am 25 Oktober 2016, 13:38:09
Kann man mit diesem Modul eine CCU2 als "Ersatz" für einen HMLAN-CFG betreiben?
Weiß nicht ob ich es richtig verstanden habe aber ich habe nur eine CCU2 laufen und konfiguriere darüber alles. Ansosnten lasse ich alles über den rpcserver mir in fhem oder TabletUI reinschieben.
Ich möchte die CCU2 im Normalfall nur als "dummes" IO-Gerät für die Homematic-Komponenten verwenden. Also: die Komponenten, Schlüssel usw. sind alle in FHEM definiert und die CCU fungiert nur als Sender.
Zitat von: topfi am 25 Oktober 2016, 15:25:04
Ich möchte die CCU2 im Normalfall nur als "dummes" IO-Gerät für die Homematic-Komponenten verwenden. Also: die Komponenten, Schlüssel usw. sind alle in FHEM definiert und die CCU fungiert nur als Sender.
Also gerät ganz normal und ordnungsgemäß anlernen an der CCU2 und den rest in Fhem via rpcserver sollte kein Problem sein. Warum nicht einen Raspberry Pi inkl. HM-Funkmodul ? Ist deutlich günstiger.
Dann hätte ich gleich noch ein Gerät zur Pflege meines HM-Komponenten-Zoos. Das geht ja für neue Geräte mit dem HMLAN auch nicht mehr. Außerdem sieht es schöner aus und irgendwie traue ich dem Bastelteil nicht so eine gute Funkreichweite zu wie einem HMLAN.
Aber an der CCU2 möchte ich eigentlich nichts anlernen, sondern an FHEM. Dafür scheint die CCU wohl wirklich das verkehrte Gerät zu sein.
die ccu2 hat ne bessere funkabdeckung bei gezeigt als der hmlan
was verstehst du unter bastelteil??? da du nicht löten musst und das modul quasi sauber von eq3 verbaut wurde , was soll schief gehen?
ich muss die ccu2 nur zum anlernen pflegen und habe den vorteil das auch alles gut ohne fhem läuft und ich auch alle vorteile der ccu erweiterung nutzen könnte.
wenn du mit fhem only arbeiten willst kauf dir keine ccu2, dafür ist sie nicht geeignet. da kannst du das gleich schicke neu elangateway mit gleicherm preis und weniger funktionen nehmen (du verstehts die ironie?!). oder halt hm-usb -cfg restbestände oder das pi modul. ich fürchte aber fast das in zukunft kein cul mehr genutzt werden wird. ich liebäugle zb mit hm-ip komponenten. kann cul_hm nicht und wird es wohl auch nicht. mir mit meiner cuu2 egal. ich bediene wired, bidcos und ip über ccu2 und fhem ;-)
Hi
Zitat von: zap am 25 Oktober 2016, 08:15:04
Ja, das ist der Grund für das Problem. Funktioniert das Teil denn an der CCU korrekt? Ich würde folgendes vorschlagen:
1. FHEM: RPC-Server stoppen
2. CCU: Neu starten
3. FHEM:
3.1 IO-Device: get devicelist ausführen
3.2 IO-Device(!): get deviceinfo CCU-Name, wobei CCU-Name der Name des Aktors in der CCU ist.
3.3 Wenn 3.2 ok, RPC-Server wieder starten
Wenn bei 3.2 wieder ein Fehler kommt, das Gerät in der CCU ablernen und (unter dem gleichen Namen) neu anlernen. Dann die Schritte 3.1 und 3.2 von oben wiederholen.
Das Umbenennen des Devices in der CCU hat es gebracht (nicht die Channels).
Jetzt klappt alles wie gewünscht.
Es kann sein, dass es schon mal ein Device mit gleichem Namen gab und deshalb die Probleme bestanden haben.
Vielen Dank
Manuel
Ich frage anders: Kann ich eine CCU2 unter fhem als IO-Gerät in eine vccu einbinden?
nö
Zitat von: topfi am 26 Oktober 2016, 13:44:42
Ich frage anders: Kann ich eine CCU2 unter fhem als IO-Gerät in eine vccu einbinden?
Die CUL_HM/VCCU- und die HMCCU-Welt sind 2 verschiedene, nicht miteinander kompatible Dinge. Du musst Dich entscheiden ...
Hallo,
hätte gerne gewusst, wie ich die hmip-ps als device definieren muss um sie zu schalten.
Habe das hier nicht gefunden.
Danke
Hallo!
Steht eigentlich schon mehrfach im Thread:
HmIP ist genauso zu definieren und zu bedienen, wie HM:
define DEVICENAME HMCCU DEVICENAMECCU
Grüße
Phil
Zitat von: Stril am 27 Oktober 2016, 13:20:02
Hallo!
Steht eigentlich schon mehrfach im Thread:
HmIP ist genauso zu definieren und zu bedienen, wie HM:
define DEVICENAME HMCCU DEVICENAMECCU
Ersetze "HMCCU" durch "HMCCUDEV" oder "HMCCUCHN", dann passt es.
Grüße
Phil
...ups...
Diese Vertipper :-)
Ich kann übrigens jeden Tag das Modul mehr empfehlen. Gestern habe ich alle restlichen Devices von meinem HMLAN auf die CCU2 migriert und bin mehr als zufrieden.
Grüße
Phil
Wie aufwendig ist das denn? In dem anderen Thread mit den Beispielen verstehe ich nur Bahnhof... :o
Hallo!
Das ist wie bei allem mit FHEM:
Einfach, sobald man die Logik verstehen hat. Vorher fies
Zitat von: topfi am 29 Oktober 2016, 23:03:19
Wie aufwendig ist das denn? In dem anderen Thread mit den Beispielen verstehe ich nur Bahnhof... :o
Moin moin !
Definiere mal was du unter "aufwändig" verstehst ?
Wie überall, MUSS man sich in die Dinge einlesen, egal ob man einen super modernen Fernseher, Dolby 7.1 Verstärker oder sonst was. Genauso ist es hier. Und dabei helfen die Beispiele aus dem Thread enorm !
Am Anfang wird man wahrscheinlich alles verfluchen aber sobald man die "Logik" des Aufbaus verstanden hat umso einfacher wird es, genauso wie es Member Stril geschrieben hat !
Ich mag das Modul auch jeden Tag immer mehr ! Warum ? Weil ich jeden Tag immer ein wenig mehr verstehe und davon begeistert bin :-)
Naja das erste Erfolgserlebnis mit einer brauchbaren Konfig, um einen Ersatz für CUL_HM zu erhalten, ist schon seeehr mühselig.
Meine Templates haben bisher ja leider keinen Weg in den Mainstream gefunden.
naja komm so schlimm ist es nicht! die beispieldefinitionen braucht man ehr selten wenn man ein bissl mit fhem erfahrung hat. aber defaoult attribute für die devices wären schon hilfreich
Die neue Version (läuft bei mir gerade im Test) wird deutlich mehr Default Attribute enthalten, nun auch für HMCCUCHN Devices.
Das lässt hoffen. Es ist wirklich sehr aufwändig eine bestehende Installation mit fast 100 Devices komplett neu definieren zu müssen und dabei auch nur annähern das selbe Verhalten, Readings, Icons etc. nachzubauen.
Vom Workflow her wäre es natürlich toll, wenn man einfach für jedes von der CCU2 ausgelesene Gerät am Anfang ein HMCCU Gerät oder Channel (was je nach Gerät eben mehr Sinn macht) automatisch anlegen könnte, inkl. aller Attribute und Iconsets, damit man die Geräte dann nur noch umbenennen muss und sie direkt für die vorigen CUL_HM Geräte als Ersatz dienen können. Ich habe gerade bei meinen Eltern mit der Umstellung der Heizungssteuerung begonnen und was soll ich sagen: Nach Tagen Arbeit ist es noch nichtmals im Ansatz so, wie es mal war, leider...
Autocreate geht ja schon (mit get devicelist). In der neuen Version auch gleich mit Attributen, sofern in HMCCUConf.pm vorhanden. Eine Kompatibilität mit CUL_HM Attributen wird es allerdings nicht geben. Dazu sind die Ansätze zu unterschiedlich.
Ich werde auch nicht alle Attribute aus Deiner Template-Datei übernehmen. Gerade die event-maps und die devicons sind doch sehr umfangreich und passen sicher nicht jedem Nutzer ins Konzept. Ich tendiere eher dazu, eigene Templates zu zu lassen, die jeder Nutzer in einer Textdatei pflegen kann. Vorgabe wären dann die Attribute aus HMCCUConf.pm, die dann mit eigenen Attributen aus der Textdatei überschrieben werden, sofern vorhanden.
Noch zwei Hinweise, die die Anwendung von HMCCU vielleicht etwas vereinfachen:
1. Im Attribut substitute kann man ja Datenpunkt bezogen Ersetzungsregeln für Werte definieren. Das Attribut akzeptiert auch Listen von Datenpunkten. Um z.B. die Werte der Datenpunkte UNREACH und LOWBAT durch "yes" und "no" zu ersetzen, kann man folgendes Attribut setzen:
attr mydev substitute UNREACH,LOWBAT!(0|false):no,(1|true):yes
2. Wem die Readingnamen nicht gefallen, kann sie mit dem Attribut ccureadingname umbenennen:
attr mydev ccureadingname LOWBAT:battery,LEVEL:pct
Das erspart exzessive Userreadings (und ist im übrigen performanter als userreadings, die intern per Notify-Call abgearbeitet werden)
Der erste Teil vor dem Doppelpunkt ist ein regulärer Ausdruck. Es können also auch nur Teile der Readingnames ersetzt werden.
Ich habe gerade die Version 3.5 eingecheckt. Änderungen:
88_HMCCU
- Neuer Befehl 'get defaults' listet die Gerätetypen auf, für die Default-Attribute verfügbar sind (inklusive vom Benutzer definierte Attribute)
- Neuer Befehl 'get exportdefaults' erzeugt aus den Default-Attributen in HMCCUConf.pm eine Textdatei, die als Grundlage für eine eigene Default-Attribut Datei verwendet werden kann
- Neuer Befehl 'set importdefaults' importiert aus einer angegebenen Textdatei benutzerdefinierte Default-Attribute. Diese haben Vorrang gegenüber der Datei HMCCUConf.pm. Für eine persistente Einbindung der Attribut-Datei wird das Attribut 'ccudefaults' auf den Pfadnamen der Datei mit den benutzerdefinierten Default-Attributen
- Neuer Befehl 'set cleardefaults' löscht benutzerdefinierte Default-Attribute
- Default-Attribute werden nun auch für Devices vom Typ HMCCUCHN unterstützt
- Autocreate im Befehl 'get devicelist' unterstützt nun die Option 'defattr' zum automatischen Setzen von Default-Attributen bei der Erzeugung von Devices
88_HMCCUDEV, 88_HMCCUCHN
- Neues Attribut 'substexcl' schließt einzelne Readings von der Werteersetzung mit 'substitute' aus. Sinnvoll in Zusammenhang mit der Ersetzung von Nummernbereichen (s.u.)
- Attribut 'substitute' unterstützt nun Nummernbereiche. Hilfreich für Dimmer, Rolläden und Thermostate. Beispiel s.u. Ein Nummernbereich beginnt immer mit einer # gefolgt vom Bereich im Format Min-Max. Bei Einzelwerten ist Min=Max (z.B. '#3-3')
- Attribut 'substitute' unterstützt nun die Einschränkung auf Datenpunkte bestimmter Kanäle. Beispiel: 1.STATE!0:off,1:on. Hilfreich, wenn mehrere Kanäle den gleichen Datenpunkt haben
Bugfixes
- Bei HMCCUCHN Devices ist nun der Befehl 'set control' verfügbar
- Reihenfolge der Bearbeitung von Readingvalues geändert: 1. Skalierung, 2. Formatierung, 3. Substitute
Beispiel für Werteersetzung bei Wandthermostaten:
attr mytherm controldatapoint 2.SET_TEMPERATURE
attr mytherm substexcl control
attr mytherm substitute SET_TEMPERATURE!#0-4.5:off,30.5-40:on
attr mytherm widgetOverride control:slider,4.5,0.5,30.5,1
Mit diesem Code wird die Zieltemperatur 4.5 als off und 30.5 als on dargestellt. Alle anderen Temperaturen werden mit ihrem Wert dargestellt.
moin,
ich schlage mich gerade durch eine fhem Konfiguration mit hmcc durch. An sich scheint alles zu laufen, zumindest bekomme ich die Readings und Config Values aller Heizungsthermostate und auch der Fensterkontake.
Allerdings kommen regelmässig im Log die folgende Meldung:
2016.11.10 22:19:19.860 3: CCURPC: CB2001 Received 500 events from CCU since last check
Ist diese ein Anzeichen für ein Problem oder nur eine Statusmeldung?
Reine Statusmeldung die zeigt, dass Events von der CCU ankommen. Mit Loglevel < 3 kommt die Meldung nicht.
ok, Danke :)
Hallo!
Irgendwie habe ich ein Problem nach dem letzten Update. HMCCU bleibt stehen auf "rpcstate starting"
Das Log ist wenig aufschlussreich für mich:
2016.11.11 22:44:19 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.11.11 22:44:31 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2016.11.11 22:44:31 0: HMCCU: Child process for server CB2001 started with PID 1343
2016.11.11 22:44:31 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2016.11.11 22:44:31 0: HMCCU: Child process for server CB2010 started with PID 1344
2016.11.11 22:44:38 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2016.11.11 22:44:45 1: HMCCU: Registering callback http://10.10.9.11:7401/fh2001 with ID CB2001 at http://10.10.9.32:2001/
2016.11.11 22:44:45 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2016.11.11 22:44:45 1: HMCCU: RPC callback with URL http://10.10.9.11:7401/fh2001 initialized
2016.11.11 22:44:47 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.11.11 22:44:47 0: HMCCU: Received SL event. RPC server CB2010 enters server loop
2016.11.11 22:44:54 1: HMCCU: Registering callback http://10.10.9.11:7410/fh2010 with ID CB2010 at http://10.10.9.32:2010/
2016.11.11 22:44:54 1: HMCCU: RPC callback with URL http://10.10.9.11:7410/fh2010 initialized
Habt ihr dazu eine Idee?
EDIT: Nach einem Neustart der CCU2 läuft alles wieder - mit HMCCU 3.5
Gruß
Phil
Das sind die normalen Meldungen beim Start des RPC Servers. Hast du vor dem Update den RPC Server gestoppt? Sollte man machen.
Die Meldungen deuten jedenfalls nicht auf einen Fehler hin.
Hallo!
Ich hatte fhem sogar ganz neu gestartet, aber auch nach 10 min stand das Modul auf busy.
Nach dem ccu2 Neustart sieht aber alles fit aus.
moin,
ich habe ein komisches Phänomen bei der Darstellung der Thermostate States. Nach dem ändern des StateFormat sieht alles normal aus. Sobald ein Update auf dem Device kommt ändert sich die Schriftart und die Darstellung wird auf mehr als die gewünschten 2 Zeilen verteilt. Wenn ich dann ein Reload der Seite mache, dann sieht alles wieder normal aus. Ich habe mir mal den HTML Quellcode angeschaut, der Unterschied ist das es einmal mir <pre> </pre> formatiert wird undbei einem Device Update das <pre> verloren geht.
Zitat
nach Reload (mit pre):
======================
<td informid="wz_Thermostat"><pre> <div id="wz_Thermostat" title="T: <b style=color:orange>25.2</b>°C
M: AUTO
<br />
V: <b style=color:red>0</b>
B: OK" class="col2"><a style="cursor: pointer;">T: <b style="color:orange">25.2</b>°C
M: AUTO
<br>
V: <b style="color:red">0</b>
B: OK</a></div></pre> </td>
nach Device Update (ohne pre):
========================
<td informid="wz_Thermostat"><div id="wz_Thermostat" title="T: <b style=color:orange>25.2</b>°C
M: AUTO
<br />
V: <b style=color:red>0</b>
B: OK" class="col2"><a style="cursor: pointer;">T: <b style="color:orange">25.2</b>°C
M: AUTO
<br>
V: <b style="color:red">0</b>
B: OK</a></div></td>
Ich habe es auch mit einem einfache StateFormat getest. Auch das ist der gleiche Effekt sichtbar. Kann dieses an einer Einstellung liegen oder ist dieses ein Bug? Ich kann gerne auch weitere Informationen zu den Devices liefern.
Du solltest die Frage im FHEMWEB Unterforum des Frontend Forums stellen. Dort ist die Wahrscheinlichkeit für eine Antwort höher
Hi ZAP,
ich kämpfe seit der Umstellung auf Dein Modul mit den langen Reading-Namen, die mir nach dem define und auslesen der Datenpunkte so verpasst werden. Bsp.:
define EZ.Heizung HMCCUDEV NEQ0071936
ergibt u.a. folgendes Reading:
HM-TC-IT-WM-W-EU_NEQ0071936.2.SET_TEMPERATURE
Ich meine mich zu erinnern, dass Du mal was gesagt hast, es sollte hier eine Vereinfachung geben... ;)
VG Yil
mit:
Zitat
ccureadingformat {address[lc] | name[lc] | datapoint[lc]}[
/quote]
Wenn Du
attr DEVICEt ccureadingformat datapoint
setzt dann sieht das Reading so aus:
R-TEMPERATURE_WEDNESDAY_1
Dieses Umstellung hat es mir auch sehr erleichtert.
Super genial - was mich das schon die ganze Zeit gestört hat ... ;D
Allerdings muss ich jetzt jede Routine überprüfen und - wenn ich schon mal dabei bin - haufenweise geschwätzige Readings löschen.
Danke!!
Gerade aufgetaucht im Log:
PERL WARNING: Use of uninitialized value $ct in string ne at ./FHEM/88_HMCCU.pm line 1682.
Was kann das sein?
Zitat von: Yil am 15 November 2016, 21:01:52
Super genial - was mich das schon die ganze Zeit gestört hat ... ;D
Allerdings muss ich jetzt jede Routine überprüfen und - wenn ich schon mal dabei bin - haufenweise geschwätzige Readings löschen.
Danke!!
Einfach für jedes HMCCU* Device den Befehl "set clear" ausführen. Beim Readingformat 'datapoint' werden jedoch noch die Kanalnummern davor gestellt. Das muss zu sein, da Datenpunkte in mehreren Kanälen vorkommen können (zB bei Schaltern mit mehreren Kanälen gibt es STATE mehrfach).
Komplett umbenennen lassen sich Readings mit dem Attribut ccureadingname.
Den Log Fehler schau ich mir an.
"set clear" ist definitiv kürzer als deletereading xxx .* ;)
Ja ich weiß, hab's eingebaut weil es den Befehl in CUL_HM auch gibt und außerdem sicher gestellt ist, dass man aus Versehen nicht Readings anderer Devices löscht.
Nachdem ich nun Ventiltriebe und Wandthermostate angelernt und in fhem eingebunden habe, hat jemand Beispiele für Heizungssteuerung der folgenden Art:
- Boost starten
- Temperatur ändern (so dass sie über das Control ebenfalls korrekt angezeigt wird)
Es bleibt ja dabei, dass im Gruppenverbund Ventiltrieb und Wandthermostat die Regelung ausschließlich über das Wandthermostat vorgenommen wird - richtig?
Zitat von: Yil am 16 November 2016, 13:48:57
Nachdem ich nun Ventiltriebe und Wandthermostate angelernt und in fhem eingebunden habe, hat jemand Beispiele für Heizungssteuerung der folgenden Art:
- Boost starten
- Temperatur ändern (so dass sie über das Control ebenfalls korrekt angezeigt wird)
Es bleibt ja dabei, dass im Gruppenverbund Ventiltrieb und Wandthermostat die Regelung ausschließlich über das Wandthermostat vorgenommen wird - richtig?
Definiere mal mit HMCCUDEV ein Device für Dein Wandthermostat in FHEM und führe dann "set defaults" dafür aus (in der Hoffnung, dass der Typ Deines Thermostaten in HMCCUConf.pm hinterlegt ist.
Und ja, das Wandthermostat ist der Master, wenn Wand- und Heizkörperthermostat verknüpft sind. Grundsätzlich würde ich Dir aber zu einer Gerätegruppe in der CCU2 raten, wobei die allerdings in FHEM etwas anders definiert wird als ein normales Gerät. Mal als Beispiel:Gruppe in CCU2 = G-AZ-HZ, bestehend aus den CCU2 Thermostaten (Wand, Heizkörper) KL-AZ-TH und KL-AZ-HZ. Die Gruppe enthält in der CCU2 zwar noch 2 Fenstersensoren, auf die kann jedoch hier verzichtet werden, da das Wandthermostat den Fensterstatus mitliefert (aufgrund der Verknüpfung).
define HM_G_AZ_HZ HMCCUDEV G-AZ-HZ group=KL-AZ-HZ,KL-AZ-TH
attr HM_G_AZ_HZ ccureadingfilter (^SET_TEMPERATURE|^TEMPERATURE|^HUMIDITY|LOWBAT$|^VALVE|^CONTROL|^WINDOW_OPEN)
attr HM_G_AZ_HZ cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
attr HM_G_AZ_HZ controldatapoint 1.SET_TEMPERATURE
attr HM_G_AZ_HZ event-on-change-reading .*
attr HM_G_AZ_HZ eventMap /datapoint 1.MANU_MODE 20.0:Manu/datapoint 1.AUTO_MODE 1:Auto/datapoint 1.BOOST_MODE 1:Boost/datapoint 1.MANU_MODE 4.5:off/datapoint 1.MANU_MODE 30.5:on/
attr HM_G_AZ_HZ statedatapoint 1.SET_TEMPERATURE
attr HM_G_AZ_HZ stripnumber 1
attr HM_G_AZ_HZ substexcl control
attr HM_G_AZ_HZ substitute LOWBAT!(0|false):no,(1|true):yes;;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed;;SET_TEMPERATURE!#0-4.5:off,#30.5-40:on
attr HM_G_AZ_HZ webCmd control:Auto:Manu:Boost:on:off
attr HM_G_AZ_HZ widgetOverride control:slider,4.5,0.5,30.5,1
Die Attribute können auch weitgehend für einen Wandthermostaten übernommen werden, sofern Du keine Gruppe verwenden möchtest. Bei Gruppen muss rpcport um 9292 ergänzt werden.
ZitatDefiniere mal mit HMCCUDEV ein Device für Dein Wandthermostat in FHEM und führe dann "set defaults" dafür aus (in der Hoffnung, dass der Typ Deines Thermostaten in HMCCUConf.pm hinterlegt ist.
Das ist ja prima - die eventMap wurde zusätzlich definiert und einiges ergänzt. Trotzdem ist für mich der fhem-Befehl noch nicht klar.
Wenn das meine Einrichtung ist:
Internals:
CFGFN
CHANGED
DEF MEQ0235698
IODev HMCCU2
NAME Bad.Wandthermostat
NR 1423
STATE T: 19.9° H: 48% T: 19.0° D: 8.6°
TYPE HMCCUDEV
ccuaddr MEQ0235698
ccudevstate Active
ccuif BidCos-RF
ccuname Bad.Wandthermostat
ccutype HM-TC-IT-WM-W-EU
channels 6
statevals devstate
Readings:
2016-11-16 16:31:53 1.HUMIDITY 48
2016-11-16 16:31:53 1.TEMPERATURE 19.9
2016-11-16 16:31:32 2.SET_TEMPERATURE 19.0
2016-11-16 16:21:44 2.WINDOW_OPEN_REPORTING closed
2016-11-16 16:31:53 DEWPOINT 8.6
2016-11-16 16:31:32 control 19.0
2016-11-16 16:31:32 state 19.0
Attributes:
IODev HMCCU2
alias Bad Wandthermostat
ccureadingfilter (^UNREACH|^HUMIDITY|^TEMPERATURE|^SET_TEMPERATURE|^LOWBAT$|^WINDOW_OPEN)
ccureadingformat datapoint
cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
controldatapoint 2.SET_TEMPERATURE
devStateIcon OK:10px-kreis-gruen Error:10px-kreis-rot Initialized:10px-kreis-gelb
event-on-change-reading .*
eventMap /datapoint 2.MANU_MODE 20.0:Manu/datapoint 2.AUTO_MODE 1:Auto/datapoint 2.BOOST_MODE 1:Boost/datapoint 2.MANU_MODE 4.5:off/datapoint 2.MANU_MODE 30.5:on/
group Heizung & Thermostate
icon hm-tc-it-wm-w-eu
room Bad,Device
stateFormat T: 1.TEMPERATURE° H: 1.HUMIDITY% T: 2.SET_TEMPERATURE° D: DEWPOINT°
statechannel 2
statedatapoint 2.SET_TEMPERATURE
stripnumber 1
substexcl control
substitute LOWBAT,UNREACH!(0|false):no,(1|true):yes;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed;SET_TEMPERATURE!#0-3.5:off,#30.5-40:on
userReadings DEWPOINT {HMCCU_Dewpoint($name,"1.TEMPERATURE", "1.HUMIDITY","n/a")}
webCmd control:Auto:Manu:Boost:on:off
widgetOverride control:slider,4.5,0.5,30.5,1 Wie muss dann der fhem-Befehl für das Einschalten des Boosts lauten sowie der Befehl für das Setzen der Temperatur (mal ganz unabhängig von Gruppen).
Und auch wenn ich nerve - wozu braucht es die Gruppendefinition? Was bringt das?
Mit der eventmap Definition wird der Boost-Mode so eingeschaltet:
set Bad.Wandthermostat Boost
Ohne eventmap:
set Bad.Wandthermostat datapoint 2.BOOST_MODE 1
Die Zieltemperatur stellt man so ein:
set Bad.Wandthermostat datapoint 2.SET_TEMPERATURE 20
Aber aufpassen: Der Datenpunkt SET_TEMPERATURE liegt je nach Gerätetyp in unterschiedlichen Kanälen:
Wandthermostat: 2.SET_TEMPERATURE
Heizkörperthermostat: 4.SET_TEMPERATURE
Gruppe: 1.SET_TEMPERATURE
Wenn Heizkörper- und Wandthermostat verknüpft sind, wird jegliche Änderung am Heizkörperthermostat sofort vom Wandthermostat wieder überschrieben.
Vorteile von Gruppendevices:
- In der CCU2 müssen die Komponenten nicht manuell verknüpft werden.
- In FHEM spart man sich das Anlegen von einzelnen Devices für Heizkörper-/Wandthermostat und ggf. Fenster. Ich habe z.B. in einem großen Raum 1 Wandthermostat, 2 Heizkörperthermostate und 3 Fenstersensoren alle in einer Gruppe und mit einem einzigen Gruppendevice abgefrühstückt. Natürlich kommst Du theoretisch in FHEM mit einem Device für das Wandthermostat aus. Allerdings hast Du dann z.B. keine Info über die Ventilöffnung am Heizkörper oder den Fensterstatus, der ja z.B. zum Schließen des Ventils führt.
Klasse und danke für die schlüssige und ausführliche Erklärung. ;D
Hallo Zusammen,
ich hätte mal ein Frage zum Wandtaster und long press event.
Bei mir daheim nutze ich FHEM auf einem Pi mit der HM-LAN-Box und kann auf das press_long Event so lange reagieren bis die Taste losgelassen wird.
Dadurch wird mit folgendem Code durch drücken der Taste, die Lautstärke permanent verringert bis ich wieder loslasse.
#Wandtaster 3 (6fach)-Sonos Steuerung - Lautstärke runter
define Wandtaster3_Btn3_long DOIF ([vccu_Btn7:virtActTrigType] eq "long") (set Sonos_Wohnzimmer Volume -1)
attr Wandtaster3_Btn3_long DbLogExclude .*
attr Wandtaster3_Btn3_long do always
attr Wandtaster3_Btn3_long group Wohnzimmer
attr Wandtaster3_Btn3_long room Sonos
Nun möchte ich bei meinen Eltern das Gleiche installieren. Allerdings wird hier eine CCU verwendet.
Und da bekomme ich das Event erst nach dem Loslassen. Gibt es hier eine Möglichkeit, das auch direkt permanent zu erhalten?
# Wandtaster 6 fach #
#####################
define Wandtaster6Fach HMCCUDEV MEQ0XXXXXX
attr Wandtaster6Fach IODev CCU2
attr Wandtaster6Fach group Wandtaster6Fach
# Wandtaster 6 fach - Kanal 3 #
###############################
define Wandtaster6Fach_03 HMCCUCHN MEQ0XXXXXX:3
attr Wandtaster6Fach_03 IODev CCU2
attr Wandtaster6Fach_03 ccureadings 1
attr Wandtaster6Fach_03 group Wandtaster6Fach
attr Wandtaster6Fach_03 statevals on:true,off:false
attr Wandtaster6Fach_03 substitute STATE!1:on,0:off
# Wandtaster 6 fach - Sonos Steuerung - Lautstärke runter -5
define Wandtaster6Fach_03_Long DOIF (["Wandtaster6Fach_03:HM-PB-6-WM55_MEQ0XXXXXX.3.PRESS_LONG"] eq "1") (set Sonos_Bad_oben Volume -1)
attr Wandtaster6Fach_03_Long do always
attr Wandtaster6Fach_03_Long group Wandtaster6Fach
attr Wandtaster6Fach_03_Long room Sonos
Vielen Dank :)
Hast Du einen Reading Filter gesetzt? Eigentlich müsstest Du Readings PRESS_CONT bekommen. Nach der Doku kommen die, wenn man eine Taste gedrückt hält. Kann das leider nicht nachvollziehen, da ich so ein Teil nicht habe.
Außerdem würde ich event-on-update-reading auf .* setzen.
Problematisch könnte das Attribut rpcinterval im IO Device werden. Wenn das z.B. auf 5 Sekunden steht, bekommst Du auch nur alle 5 Sekunden ein Event. Dann musst Du ziemlich lange die Taste gedrückt halten.
Aber schau erst mal, ob ein REading PRESS_CONT gesetzt wird.
Hallo zap,
nein, ich habe keinen Filter gesetzt. Ist genau so definiert wie du oben den Code siehst.
Den PRESS_CONT gibt's leider nicht.
Anbei nochmal ein Foto vom Kanal.
Viele Grüße
Thomas
Echt blöd. Habe mal Google bemüht. Andere User berichten auch davon, dass PRESS_CONT nicht gesendet wird.
Scheint ein Problem der Firmware des Schalters zu sein. Frag mich nicht, warum das bei Deiner anderen Installation funktioniert.
Hast Du auch event-on-update-reading gesetzt?
Hallo zap,
ja, ich habe rpcinterval jetzt auf 1 gesetzt und den Kanälen das attr Wandtaster6Fach_03_Long event-on-update-reading .* hinzugefügt.
Aber hilft leider auch nicht.
Viele Grüße
Thomas
Hallo zap,
ich habe jetzt herausgefunden dass beim gedrückt halten der Taste, sich der Timestamp des folgenden readings ändert.
HM-PB-6-WM55_MXXXXXXX74.4.INSTALL_TEST
Es gibt ja neben "TEST" unter anderem auch noch das Reading "LONG" und "LONG_RELEASE", aber die aktualisieren sich leider beide erst nach dem loslassen der Taste.
Also Workaround könnte ich theoretisch auf den "TEST" gehen, allerdings wird dieser auch beim kurz drücken aktualisiert.
Der DP INSTALL_TEST ist zwar in der eq3 Doku aufgeführt, allerdings ohne Kommentar. Schwierig ...
Hallo,
ich kämpfe noch ein wenig mit den neuen Homematic-IP-Devices und der Definition in HMCCU.
Mein Heizkörperthermostat: HMIP-eTRV (ich will das ohne Wandthermostat betreiben, da dies nur einen Handtuchwärmer ansteuert)
Die Readings
CHN 000393C994D014:0 HMIP-eTRV_000393C994D014:0
DPT {b} HmIP-RF.000393C994D014:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.000393C994D014:0.DUTY_CYCLE = false [RE]
DPT {b} HmIP-RF.000393C994D014:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.000393C994D014:0.OPERATING_VOLTAGE = 3.000000 [RE]
DPT {n} HmIP-RF.000393C994D014:0.RSSI_DEVICE = 191 [RE]
DPT {n} HmIP-RF.000393C994D014:0.RSSI_PEER = 188 [RE]
DPT {b} HmIP-RF.000393C994D014:0.UNREACH = false [RE]
DPT {b} HmIP-RF.000393C994D014:0.UPDATE_PENDING = false [RE]
CHN 000393C994D014:1 HMIP-eTRV_000393C994D014:1
DPT {i} HmIP-RF.000393C994D014:1.ACTIVE_PROFILE = 1 [WE]
DPT {f} HmIP-RF.000393C994D014:1.ACTUAL_TEMPERATURE = 22.000000 [RE]
DPT {b} HmIP-RF.000393C994D014:1.BOOST_MODE = false [WE]
DPT {f} HmIP-RF.000393C994D014:1.CONTROL_DIFFERENTIAL_TEMP = [WE]
DPT {i} HmIP-RF.000393C994D014:1.CONTROL_MODE = [WE]
DPT {i} HmIP-RF.000393C994D014:1.DURATION_UNIT = [W]
DPT {i} HmIP-RF.000393C994D014:1.DURATION_VALUE = [W]
DPT {b} HmIP-RF.000393C994D014:1.FROST_PROTECTION = false [RE]
DPT {f} HmIP-RF.000393C994D014:1.LEVEL = 0.050000 [RWE]
DPT {b} HmIP-RF.000393C994D014:1.PARTY_MODE = false [RE]
DPT {f} HmIP-RF.000393C994D014:1.PARTY_SET_POINT_TEMPERATU = 0.000000 [RE]
DPT {s} HmIP-RF.000393C994D014:1.PARTY_TIME_END = [RWE]
DPT {s} HmIP-RF.000393C994D014:1.PARTY_TIME_START = [RWE]
DPT {i} HmIP-RF.000393C994D014:1.SET_POINT_MODE = 0 [RWE]
DPT {f} HmIP-RF.000393C994D014:1.SET_POINT_TEMPERATURE = 20.000000 [RWE]
DPT {b} HmIP-RF.000393C994D014:1.SWITCH_POINT_OCCURED = false [RE]
DPT {b} HmIP-RF.000393C994D014:1.VALVE_ADAPTION = [WE]
DPT {i} HmIP-RF.000393C994D014:1.VALVE_STATE = 4 [RE]
DPT {i} HmIP-RF.000393C994D014:1.WINDOW_STATE = 0 [WE]
Ich habe versucht die Atrribute entsprechend der Beispiele von anderen Thermostaten abzuleiten, verzweifel aber so langsam.
controldatapoint 1.SET_POINT_TEMPERATURE
event-on-change-reading .*
genericDeviceType thermostat
homebridgeMapping TargetTemperature=HMIP-eTRV_000393C994D014.1.SET_POINT_TEMPERATURE,minValue=10,maxValue=25,minStep=0.5
CurrentTemperature=HMIP-eTRV_000393C994D014.1.ACTUAL_TEMPERATURE
icon hc_wht_regler
stateFormat T: HMIP-eTRV_000393C994D014.1.ACTUAL_TEMPERATURE° D: HMIP-eTRV_000393C994D014.1.SET_POINT_TEMPERATURE° V: HMIP-eTRV_000393C994D014.1.VALVE_STATE%
statechannel 1
statedatapoint 1.SET_POINT_TEMPERATURE
stripnumber 1
substitute LOW_BAT!(0|false):ok,(1|true):low;;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;WINDOW_STATE!(true|1):open,(false|0):closed
webCmd control
widgetOverride control:slider,10,1,25
Meine Fragen/Probleme:
Den Modus einstellen per SET ... klappt nicht.
Ist- und Zieltemperatur in FHEM ändern klappt.
Das Mapping in Homebridge klappt leider nur halb.
Ist-Temperatur klappt.
Soll-Temperatur wird nicht verändert.
Wie kommt man sinnvoll an eine Erklärung der Readings (hier zB LEVEL)?
Könnt ihr mir beim Endspurt helfen?
Besten Dank vorab!
Viele Grüße
Christian
Kann Dir erst heute Abend helfen. Nur soviel: homeBridgeMapping und genericDeviceType sind keine HMCCU Attribute. Die dürften hier also nichts bewirken.
Zitat von: Chris8888 am 18 November 2016, 18:34:17
CHN 000393C994D014:1 HMIP-eTRV_000393C994D014:1
DPT {i} HmIP-RF.000393C994D014:1.ACTIVE_PROFILE = 1 [WE]
DPT {f} HmIP-RF.000393C994D014:1.ACTUAL_TEMPERATURE = 22.000000 [RE]
DPT {b} HmIP-RF.000393C994D014:1.BOOST_MODE = false [WE]
DPT {f} HmIP-RF.000393C994D014:1.CONTROL_DIFFERENTIAL_TEMP = [WE]
DPT {i} HmIP-RF.000393C994D014:1.CONTROL_MODE = [WE]
DPT {i} HmIP-RF.000393C994D014:1.DURATION_UNIT = [W]
DPT {i} HmIP-RF.000393C994D014:1.DURATION_VALUE = [W]
DPT {b} HmIP-RF.000393C994D014:1.FROST_PROTECTION = false [RE]
DPT {f} HmIP-RF.000393C994D014:1.LEVEL = 0.050000 [RWE]
DPT {b} HmIP-RF.000393C994D014:1.PARTY_MODE = false [RE]
DPT {f} HmIP-RF.000393C994D014:1.PARTY_SET_POINT_TEMPERATU = 0.000000 [RE]
DPT {s} HmIP-RF.000393C994D014:1.PARTY_TIME_END = [RWE]
DPT {s} HmIP-RF.000393C994D014:1.PARTY_TIME_START = [RWE]
DPT {i} HmIP-RF.000393C994D014:1.SET_POINT_MODE = 0 [RWE]
DPT {f} HmIP-RF.000393C994D014:1.SET_POINT_TEMPERATURE = 20.000000 [RWE]
DPT {b} HmIP-RF.000393C994D014:1.SWITCH_POINT_OCCURED = false [RE]
DPT {b} HmIP-RF.000393C994D014:1.VALVE_ADAPTION = [WE]
DPT {i} HmIP-RF.000393C994D014:1.VALVE_STATE = 4 [RE]
DPT {i} HmIP-RF.000393C994D014:1.WINDOW_STATE = 0 [WE]
ccureadingformat datapoint
ccuscaleval LEVEL:0:1:0:100
controldatapoint 1.SET_POINT_TEMPERATURE
event-on-change-reading .*
eventmap /datapoint 1.CONTROL_MODE 1:Manu/datapoint 1.CONTROL_MODE 0:Auto/datapoint 1.CONTROL_MODE 2:Party/datapoint 1.CONTROL_MODE 3:Boost/datapoint 1.SET_POINT_TEMPERATURE 4.5:off/datapoint 1.SET_POINT_TEMPERATURE 30.5/on/
statedatapoint 1.SET_POINT_TEMPERATURE
stateFormat T: 1.ACTUAL_TEMPERATURE° D: 1.SET_POINT_TEMPERATURE° V: 1.LEVEL%
stripnumber 1
substexcl control
substitute LOW_BAT!(0|false):ok,(1|true):low;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;WINDOW_STATE!(true|1):open,(false|0):closed;SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on
webCmd control
widgetOverride control:slider,4.5,0.5,30.5,1
Durch das eventMap Attribut werden neue Set Befehle zur Verfügung gestellt (Auto, Boost, usw). Grundsätzlich sollte aber auch "set datapoint 1.CONTROL_MODE Wert" funktionieren. Möglicherweise muss man auch den DP SET_POINT_MODE verwenden, um den Controlmode zu setzen. Dann im eventMap Attribute entsprechend ersetzen. Würde es aber erst mal so testen.
Ach ja: Wird bei Dir das Reading CONTROL_MODE aktualisiert? Ich frage, weil jemand mal Probleme damit hatte.
Hallo Zap,
danke für die Hilfe!
Leider klappt es noch nicht.
Ein Umschalten auf Auto und Manuell funktioniert, Boost und Party funktionieren nicht. Auch nicht mit SET_POINT_MODE.
Ein Reading 1.CONTROL.MODE wird nicht angezeigt, das Reding 1.SET_POINT_MODE verändert sich nie.
Bekommt man nicht für jeden Datenpunkt des Devices ein Reading?
LEVEL ist also der Öffnungsgrad des Ventiles..:-) Wieder was gelernt.
Seltsamerweise habe ich kurz nach der Attr-Anlage "neue" Readings bekommen.
Mehr oder minder die gleichen, nur ohne "HMIP-eTRV_000393C994D014.".
Die neuen werden auch aktuallisiert (außer SET_POINT_MODE), die alten nicht.
So richtig verstehen tue ich es noch nicht....
Hast du noch eine Idee?
VG
Christian
Zitat von: Chris8888 am 20 November 2016, 13:49:39
Ein Umschalten auf Auto und Manuell funktioniert, Boost und Party funktionieren nicht. Auch nicht mit SET_POINT_MODE.
Ein Reading 1.CONTROL.MODE wird nicht angezeigt, das Reding 1.SET_POINT_MODE verändert sich nie.
OK, das IP-Thermostat scheint sich hier anders zu verhalten. Versuche mal folgendes für Boos und Party:
set xyz datapoint 1.BOOST_MODE true
set xyz datapoint 1.PARTY_MODE true
Wenn "true" nicht funktioniert, versuche "1". Wenn Du damit Boost und Party einschalten kannst, musst Du das eventMap Attribut anpassen (wobei das nice to have ist, grundsätzlich geht das immer auch mit "set datapoint"):
eventmap /datapoint 1.CONTROL_MODE 1:Manu/datapoint 1.CONTROL_MODE 0:Auto/datapoint 1.PARTY_MODE 1:Party/datapoint 1.BOOST_MODE 1:Boost/datapoint 1.SET_POINT_TEMPERATURE 4.5:off/datapoint 1.SET_POINT_TEMPERATURE 30.5/on/
Zitat
Bekommt man nicht für jeden Datenpunkt des Devices ein Reading?
Nein. Wenn Du mit "get deviceinfo" die Datenpunkte abfragst, stehen hinter jedem Datenpunkt die Buchstaben R, W und E in eckigen Klammern. W steht für "Write", d.h. der Datenpunkt kann mit "set" geschrieben werden. Bei "R" für "Read" ist ein Auslesen des Datenpunktes mit "get" möglich. "E" steht für "Event", d.h. der Datenpunkt wird automatisch aktualisiert. Sowohl bei "R" als auch bei "E" wird ein Reading in FHEM aktualisiert. Allerdings scheint aufgrund eines Software Fehlers in der CCU bzw. dem Thermostaten CONTROL_MODE trotz "E" Kennzeichnung nicht aktualisiert zu werden. Gerade wurde ja ein neues Firmware Update für die CCU verteilt. Hast Du das installiert? Vielleicht wird damit der Fehler behoben.
Zitat
LEVEL ist also der Öffnungsgrad des Ventiles..:-) Wieder was gelernt.
Ja ich auch. Zumal es bei den alten Thermostaten VALVE_STATE war.
Zitat
Seltsamerweise habe ich kurz nach der Attr-Anlage "neue" Readings bekommen.
Mehr oder minder die gleichen, nur ohne "HMIP-eTRV_000393C994D014.".
Die neuen werden auch aktuallisiert (außer SET_POINT_MODE), die alten nicht.
Das liegt am Attribut "ccureadingformat". Wenn Du das auf "datapoint" setzt, werden kürzere Readingnamen verwendet.
Zitat von: zap am 20 November 2016, 19:02:56
OK, das IP-Thermostat scheint sich hier anders zu verhalten. Versuche mal folgendes für Boos und Party:
set xyz datapoint 1.BOOST_MODE true
set xyz datapoint 1.PARTY_MODE true
Wenn "true" nicht funktioniert, versuche "1". Wenn Du damit Boost und Party einschalten kannst, musst Du das eventMap Attribut anpassen (wobei das nice to have ist, grundsätzlich geht das immer auch mit "set datapoint"):
eventmap /datapoint 1.CONTROL_MODE 1:Manu/datapoint 1.CONTROL_MODE 0:Auto/datapoint 1.PARTY_MODE 1:Party/datapoint 1.BOOST_MODE 1:Boost/datapoint 1.SET_POINT_TEMPERATURE 4.5:off/datapoint 1.SET_POINT_TEMPERATURE 30.5/on/
1.BOOST_MODE true funktioniert (false = ausschalten auch)
1.PARTY_MODE true funktioniert nicht (invalid datapoint...skuril)...mit "1" funktioniert es auch nicht, gleiche Meldung
eventmap ist jetzt:
/datapoint 1.CONTROL_MODE 1:Manu/datapoint 1.CONTROL_MODE 0:Auto/datapoint 1.PARTY_MODE true:Party/datapoint 1.BOOST_MODE true:Boost/datapoint 1.SET_POINT_TEMPERATURE 4.5:off/datapoint 1.SET_POINT_TEMPERATURE 30.5/on/
Da ich nur den Boost benötige ist das für mich so okay, Party nutze ich nicht.
Oder kann ich das "false" (=Ausschalten des Boostmodus) nicht auch im Eventmap hinterlegen?
Die Firmware der CCU2 ist aktuell 2.25.14.
Hinter dem 1.CONTROL_MODE steht ein [WE].
Wie kann ich denn die "alten" Readings löschen?
Danke vorab für den spitzen Service!
VG
Christian
Ich kann bei den IP-Thermostaten mit: set <device> datapoint 1.CONTROL_MODE 0|1|2 zwischen auto, manual und holiday umschalten.
Das reading für den aktuellen Modus bekomme ich aber nur über 1.SET_POINT_MODE ausgelesen.
Zitat
Ich kann bei den IP-Thermostaten mit:
set <device> datapoint 1.CONTROL_MODE 0|1|2
zwischen auto, manual und holiday umschalten.
Das reading für den aktuellen Modus bekomme ich aber nur über 1.SET_POINT_MODE ausgelese
Danke für den Hinweis! Wird SET_POINT_MODE bei Dir automatisch aktualisiert? Werden in SET_POINT_MODE nur die Modi 0-2 zurück gegeben oder weitere (>2)?
Zitat
1.PARTY_MODE true funktioniert nicht (invalid datapoint...skuril)...mit "1" funktioniert es auch nicht, gleiche Meldung
Kann nicht funktionieren, da PARTY_MODE kein "W" Flag hat, d.h. read only ist. Das war bei den alten Thermostaten so schön konsistent gelöst und jetzt so ein Murks bei den IP Geräten. EQ3 eben. Versuche mal, mit
set datapoint 1.PARTY_SET_POINT_TEMPERATU 20
eine Party-Zieltemp zu setzen (und nein, die fehlenden "RE" am Ende des Datenpunkts scheinen kein Schreibfehler zu sein). Prüfe dann, ob der Thermostat automatisch den Party-Mode einschaltet.
Zitat
Oder kann ich das "false" (=Ausschalten des Boostmodus) nicht auch im Eventmap hinterlegen?
Du könntest es so machen (eventMap ist ein Standard FHEM Attribut, sehr mächtig, siehe Online Hilfe):
attr eventMap /datapoint 1.CONTROL_MODE 1:Manu/datapoint 1.CONTROL_MODE 0:Auto/datapoint 1.CONTROL_MODE 2:Holiday/datapoint 1.PARTY_SET_POINT_TEMPERATU 20:Party/datapoint 1.BOOST_MODE true:BoostOn/datapoint 1.BOOST_MODE false:BoostOff/datapoint 1.SET_POINT_TEMPERATURE 4.5:off/datapoint 1.SET_POINT_TEMPERATURE 30.5/on/
Bitte achte mal darauf, ob das Reading SET_POINT_MODE automatisch aktualisiert wird.
Zitat
Wie kann ich denn die "alten" Readings löschen?
Entweder mit dem FHEM Befehl deletereading oder mit "set clear" im HMCCUDEV/CHN Device (löscht alle Readings außer State, aber die kommen ja wieder).
Bei mir wird SET_POINT_MODE automatisch aktualisiert.
Bisher habe ich nur die Werte 0-2 gesehen.
2 setzt sowohl den Urlaubsmodus in der CCU2-WebUI als auch das PARTY_MODE reading.
Es wird also zwischen Party und Urlaub nicht unterschieden.
Ah ich sehe schon da hat jemand bei eq3 mitgedacht. Szenario: Eltern in Urlaub, Kinder wollen Party machen. Da macht es natürlich Sinn die beiden Modi zu verknüpfen ;-)
bin ein wenig am verzweifeln und hoffe ihr könnt mir helfen...
Ich bekomme den rpcserver nicht ans Laufen.
2016.11.21 16:21:42 0: HMCCU: Child process for server CB9292 started with PID 1047
2016.11.21 16:21:42 0: CCURPC: CB9292 Creating file queue /tmp_9292
2016.11.21 16:21:42 0: CCURPC: CB9292 Can't create queue
2016.11.21 16:21:42 2: CCURPC: Eventcount DD = 0
2016.11.21 16:21:42 2: CCURPC: Eventcount EV = 0
2016.11.21 16:21:42 2: CCURPC: Eventcount EX = 0
2016.11.21 16:21:42 2: CCURPC: Eventcount IN = 0
2016.11.21 16:21:42 2: CCURPC: Eventcount ND = 0
2016.11.21 16:21:42 2: CCURPC: Eventcount RA = 0
2016.11.21 16:21:42 2: CCURPC: Eventcount RD = 0
2016.11.21 16:21:42 2: CCURPC: Eventcount SL = 0
2016.11.21 16:21:42 2: CCURPC: Eventcount UD = 0
2016.11.21 16:21:42 2: CCURPC: Eventcount total = 0
2016.11.21 16:21:42 2: CCURPC: Eventcount writeerror = 0
2016.11.21 16:21:42 0: RPC server(s) starting
2016.11.21 16:21:54 1: HMCCU: Can't open file queue /tmp_2001
2016.11.21 16:21:54 1: HMCCU: Can't open file queue /tmp_2010
2016.11.21 16:21:54 1: HMCCU: Can't open file queue /tmp_9292
2016.11.21 16:21:54 0: HMCCU: Periodical check found no RPC Servers
2016.11.21 16:21:54 0: HMCCU: All RPC servers stopped
Sieht so aus, als wenn die queue Dateien nicht generiert werden können, der tmp Ordner ist leer.
Der Server steht auf busy und die ganze Zeit auf stopped.
Habt ihr eine Idee woran es liegen kann?
Den tmp Ordner musste ich händisch anlegen. Sollte der automatisch installiert werden?
Hast Du das Attribut rpcqueue gesetzt? Wenn ja lösche es oder setze es auf /tmp/ccuqueue.
Was für ein System verwendest Du eigentlich? Ich frage, weil es kein /tmp gibt. Das ist ungewöhnlich. Wenn Du /tmp manuell angelegt hast, achte darauf, dass der User fhem Schreibrechte hat.
Zitat von: zap am 21 November 2016, 18:44:17
Hast Du das Attribut rpcqueue gesetzt? Wenn ja lösche es oder setze es auf /tmp/ccuqueue.
Ja, das habe ich gesetzt. Allerdings nur wie im FHEM Wiki mit :
attr d_ccu rpcqueue /tmpZitat von: zap am 21 November 2016, 18:44:17
Was für ein System verwendest Du eigentlich? Ich frage, weil es kein /tmp gibt. Das ist ungewöhnlich. Wenn Du /tmp manuell angelegt hast, achte darauf, dass der User fhem Schreibrechte hat.
Ich hab Raspbian Jessie auf einem RPi 3 installiert. Den Ordner habe selbst unter fhem erstellt.
Zitat von: zap am 21 November 2016, 08:54:10
Danke für den Hinweis! Wird SET_POINT_MODE bei Dir automatisch aktualisiert? Werden in SET_POINT_MODE nur die Modi 0-2 zurück gegeben oder weitere (>2)?
Bei mir werden bei 1.CONTROL_MODE nur 0 und 1 akzeptiert. Bei 2 passiert nichts. SET_POINT_MODE wird bei 0 und 1 automatisch aktuallisiert/angezeigt.
Zitat von: zap am 21 November 2016, 08:54:10
Kann nicht funktionieren, da PARTY_MODE kein "W" Flag hat, d.h. read only ist. Das war bei den alten Thermostaten so schön konsistent gelöst und jetzt so ein Murks bei den IP Geräten. EQ3 eben. Versuche mal, mit
set datapoint 1.PARTY_SET_POINT_TEMPERATU 20
eine Party-Zieltemp zu setzen (und nein, die fehlenden "RE" am Ende des Datenpunkts scheinen kein Schreibfehler zu sein). Prüfe dann, ob der Thermostat automatisch den Party-Mode einschaltet.
Fehlermeldung: Invalid Datapoint. ???
Zitat von: zap am 21 November 2016, 08:54:10
Du könntest es so machen (eventMap ist ein Standard FHEM Attribut, sehr mächtig, siehe Online Hilfe):
attr eventMap /datapoint 1.CONTROL_MODE 1:Manu/datapoint 1.CONTROL_MODE 0:Auto/datapoint 1.CONTROL_MODE 2:Holiday/datapoint 1.PARTY_SET_POINT_TEMPERATU 20:Party/datapoint 1.BOOST_MODE true:BoostOn/datapoint 1.BOOST_MODE false:BoostOff/datapoint 1.SET_POINT_TEMPERATURE 4.5:off/datapoint 1.SET_POINT_TEMPERATURE 30.5/on/
Bitte achte mal darauf, ob das Reading SET_POINT_MODE automatisch aktualisiert wird.
Super! Danke.
Zitat von: zap am 21 November 2016, 08:54:10
Entweder mit dem FHEM Befehl deletereading oder mit "set clear" im HMCCUDEV/CHN Device (löscht alle Readings außer State, aber die kommen ja wieder).
Das habe ich gesucht. Danke!
Zitat von: theotherhalf am 21 November 2016, 20:14:39
Ja, das habe ich gesetzt. Allerdings nur wie im FHEM Wiki mit : attr d_ccu rpcqueue /tmp
Ich hab Raspbian Jessie auf einem RPi 3 installiert. Den Ordner habe selbst unter fhem erstellt.
Ok, mein Fehler. Die Angabe im Wiki ist falsch. Also entweder das Attribut weglassen oder auf /tmp/ccuqueue setzen. Das Verzeichnis alleine genügt nicht. Das Präfix für die Queue Dateien (hier ccuqueue) muss mit angegeben werden.
Was meinst du mit "unter fhem erstellt"? Unter dem User fhem ? Dann müsste alles passen (Rechte).
Gibt es im Forum keine "In Thread Suche"? Na ja, dann muss ich halt Fragen (nachdem ich 5 Seiten durch habe ;-)
Kann ich über das HMCCU Modul auch AES Verschlüsselte Aktoren/Sensoren steuern/einlesen? Ist gerade für eine Kaufentscheidung wichtig (CCU2 oder doch nur FHEM).
ZitatKann ich über das HMCCU Modul auch AES Verschlüsselte Aktoren/Sensoren steuern/einlesen?
Warum nicht? "AES" steht für die "Verschlüsselung" (isses ja genaugenommen nicht) auf der Funkstrecke, die Kommunikation zwischen FHEM und der CCU2 mittels des Moduls HMCCU hat damit doch nicht die Bohne zu tun, oder liege ich da falsch?
ZitatIst gerade für eine Kaufentscheidung wichtig (CCU2 oder doch nur FHEM)
AES können beide, so what?
Zitat von: zap am 22 November 2016, 07:10:46
Ok, mein Fehler. Die Angabe im Wiki ist falsch. Also entweder das Attribut weglassen oder auf /tmp/ccuqueue setzen. Das Verzeichnis alleine genügt nicht. Das Präfix für die Queue Dateien (hier ccuqueue) muss mit angegeben werden.
Was meinst du mit "unter fhem erstellt"? Unter dem User fhem ? Dann müsste alles passen (Rechte).
Ah, OK.
Habe es jetzt geändert und es läuft.:-)
Ich dachte, dass das /tmp Verzeichnis unter fhem erstellt werden muss, aber es ist ja im Hauptverzeichnis zu finden.
Werde mich dann jetzt mal weiter durch den Rest arbeiten bis ich die gewünschten Werte im Floorplan sehe.
Danke vorerst!
Zitat von: mbuzina am 24 November 2016, 10:40:11
Gibt es im Forum keine "In Thread Suche"? Na ja, dann muss ich halt Fragen (nachdem ich 5 Seiten durch habe ;-)
Kann ich über das HMCCU Modul auch AES Verschlüsselte Aktoren/Sensoren steuern/einlesen? Ist gerade für eine Kaufentscheidung wichtig (CCU2 oder doch nur FHEM).
HMCCU steuert keine Aktoren/Sensoren sondern nutzt die CCU für diese Aufgabe. Die mehr oder weniger verschlüsselte Kommunikation passiert zwischen der CCU und den Aktoren/Sensoren. HMCCU dockt sich lediglich an die CCU an.
Die Kommunikation zwischen HMCCU und der CCU ist nicht verschlüsselt. Muss sie auch nicht, da sie im lokalen Netz stattfindet. Wenn Du auch diese Verbindung verschlüsseln möchtest, könntest Du Dir mit einem SSH Tunnel behelfen. Aber hey, was für ein Aufwand!
Hallo zusammen,
nachdem ich das Modul nun schon einen kleinen Moment im Einsatz habe bin ich extrem davon begeistert und habe nun auch endlich meine YAHM CCU produktiv im Einsatz. Es ist wirklich beeindruckend wie schnell es hier vorwärts geht, meinen Respekt dafür.
Ich habe aber leider zwei kleine Probleme mit dem Modul und hoffe mir kann hier jemand weiterhelfen. Wie schon erwähnt habe ich eine YAHM Installation auf dem selben PI wie FHEM am laufen. Wenn ich den PI neu starte scheint die CCU nicht ganz so schnell hochgefahren zu sein, weshalb ich anschließend in FHEM nur Fehler bekomme und keins meiner HMCCU Devices angezeigt wird. Starte ich FHEM dann neu läuft alles wieder normal und das gleiche Problem habe ich auch wenn ich nur die CCU neu starte.
Das andere Problem betrifft den toggle Befehl, diesen bekomme ich einfach nicht zum Laufen. Ich bekomme immer die Fehlermeldung "Current device state doesn't match statevals" obwohl die statevals gesetzt sind. Muss ich hier noch irgendetwas beachten? In den Beispiel Definitionen habe ich nichts besonderes gesehen was von meinen Definitionen abweicht.
Nun habe ich alle Thermostate eingerichtet und es sieht soweit gut aus.
Leider werden aber alle Werte der Devices nur nach einem Neustart des Raspi einmal eingelesen.
Danach nicht mehr. Der RPC Server läuft und steht auf Ok und running, der Intervall steht auf 10s. Das Datum hinter dem RPC Server ist allerdings das des Neustarts.
Hab ich was übersehen?
Zitat von: ph4 am 25 November 2016, 23:05:04
Hallo zusammen,
nachdem ich das Modul nun schon einen kleinen Moment im Einsatz habe bin ich extrem davon begeistert und habe nun auch endlich meine YAHM CCU produktiv im Einsatz. Es ist wirklich beeindruckend wie schnell es hier vorwärts geht, meinen Respekt dafür.
Ich habe aber leider zwei kleine Probleme mit dem Modul und hoffe mir kann hier jemand weiterhelfen. Wie schon erwähnt habe ich eine YAHM Installation auf dem selben PI wie FHEM am laufen. Wenn ich den PI neu starte scheint die CCU nicht ganz so schnell hochgefahren zu sein, weshalb ich anschließend in FHEM nur Fehler bekomme und keins meiner HMCCU Devices angezeigt wird. Starte ich FHEM dann neu läuft alles wieder normal und das gleiche Problem habe ich auch wenn ich nur die CCU neu starte.
Die CCU Software muss vor FHEM gestartet werden. Ich kenne zwar YAHM nicht, aber grundsätzlich kannst Du unter Linux die Startreihenfolge der Prozesse über /etc/init.d bzw. die /etc/rcx.d Logik beeinflussen. Wenn die CCU Software neu gestartet wird, muss auch der RPC-Server in FHEM neu gestartet werden, da die CCU Software in diesem Fall alle registrierten Abnehmer von Infos "vergisst".
BTW: Mittlerweile gibt es von EQ3 fertige Images für den Raspi.
Zitat
Das andere Problem betrifft den toggle Befehl, diesen bekomme ich einfach nicht zum Laufen. Ich bekomme immer die Fehlermeldung "Current device state doesn't match statevals" obwohl die statevals gesetzt sind. Muss ich hier noch irgendetwas beachten? In den Beispiel Definitionen habe ich nichts besonderes gesehen was von meinen Definitionen abweicht.
Ich benötige die Definition und Attribute des FHEM-Device, bei dem Toggle Probleme mach. Am besten ein "list".
Zitat von: theotherhalf am 26 November 2016, 11:39:01
Nun habe ich alle Thermostate eingerichtet und es sieht soweit gut aus.
Leider werden aber alle Werte der Devices nur nach einem Neustart des Raspi einmal eingelesen.
Danach nicht mehr. Der RPC Server läuft und steht auf Ok und running, der Intervall steht auf 10s. Das Datum hinter dem RPC Server ist allerdings das des Neustarts.
Hab ich was übersehen?
Irgendwie scheint der RPC-Server nicht richtig zu laufen (vermute ich). Das erste Update der Werte nach dem Start erfolgt nicht durch den RPC-Server sondern durch eine Abfrage der Stati aller Geräte von der CCU.
Gib mir mal ein "list" eines der Thermostat Devices. Außerdem schaue Dir das FHEM Logfile an und poste mal alle HMCCU Meldungen, die beim Start des RPC-Servers geloggt werden.
Hallo,
ich bin ein Fan von HMCCU (geworden) und stelle sukzessive alles um.
NUn habe ich eine Frage zum Thermostat:
derzeit benutze ich das Abbild des Automatikbetriebs in templist.cfg (Schaltzeitpunkte und Solltemperaturen). Das nutze ich für eine vorausschauende Darstellung des Tages-Heizungs-Profils.
KOMME ICH ÜBER HMCCU AUCH AN DIE TEMERATURPROFILE HERAN? (Ähnlich wie Impport in templist.cfg)
Danke für Tips
Zitat von: zap am 26 November 2016, 18:54:09
Irgendwie scheint der RPC-Server nicht richtig zu laufen (vermute ich). Das erste Update der Werte nach dem Start erfolgt nicht durch den RPC-Server sondern durch eine Abfrage der Stati aller Geräte von der CCU.
Gib mir mal ein "list" eines der Thermostat Devices. Außerdem schaue Dir das FHEM Logfile an und poste mal alle HMCCU Meldungen, die beim Start des RPC-Servers geloggt werden.
Mein Rapsi hängt derzeit noch über WLAN am Netz.
Könnte es ebenso sein, dass nach der Nachtabschaltung des WLAN (ca.6std.) der RPC Server nicht wieder richtig ans Laufen kommt?
Habe das noch nicht nachgestellt, aber vllt. Hängt es damit zusammen?
Zitat von: wolfgang99 am 27 November 2016, 11:37:43
derzeit benutze ich das Abbild des Automatikbetriebs in templist.cfg (Schaltzeitpunkte und Solltemperaturen). Das nutze ich für eine vorausschauende Darstellung des Tages-Heizungs-Profils.
KOMME ICH ÜBER HMCCU AUCH AN DIE TEMERATURPROFILE HERAN? (Ähnlich wie Impport in templist.cfg)
Ist templist.cfg was CUL_HM spezifisches? Wie auch immer: In HMCCUDEV bzw. HMCCUCHN Devices gibt es die Befehle "get config" und "set config". Damit werden in der CCU Konfigurationsparameter gesetzt bzw. ausgelesen. Die von Dir benötigten Temperaturprofile werden in der CCU als Konfigurationsparameter gespeichert (in der CCU das Menü "Einstellungen - Geräte" und dann beim Thermostaten auf "Eigenschaften"). In dieser Eigenschaften-Seite stecken wichtige Infos, u.a. die Angabe der Kanalnummern, in denen die entsprechenden Parameter verwaltet werden.
Mal ein Beispiel für einen Thermostaten vom Typ HM-CC-RT-DN:
Zunächst mal die Beschreibung der Parameter auslesen:
get mydev config
Liefert reichlich Readings, die alle mit "R-" beginnen:
Readings:
2016-11-27 18:05:13 R-KL-AZ-HZ.ADAPTIVE_REGULATION 2
2016-11-27 18:05:13 R-KL-AZ-HZ.BACKLIGHT_ON_TIME 10
2016-11-27 18:05:13 R-KL-AZ-HZ.BOOST_AFTER_WINDOW_OPEN 0
2016-11-27 18:05:13 R-KL-AZ-HZ.BOOST_POSITION 80
2016-11-27 18:05:13 R-KL-AZ-HZ.BOOST_TIME_PERIOD 1
2016-11-27 18:05:13 R-KL-AZ-HZ.BURST_RX 1
2016-11-27 18:05:13 R-KL-AZ-HZ.BUTTON_LOCK 0
2016-11-27 18:05:13 R-KL-AZ-HZ.BUTTON_RESPONSE_WITHOUT_BACKLIGHT 0
2016-11-27 18:05:13 R-KL-AZ-HZ.CYCLIC_INFO_MSG 1
2016-11-27 18:05:13 R-KL-AZ-HZ.CYCLIC_INFO_MSG_DIS 0
2016-11-27 18:05:13 R-KL-AZ-HZ.DAYLIGHT_SAVING_TIME 1
2016-11-27 18:05:13 R-KL-AZ-HZ.DECALCIFICATION_TIME 660
2016-11-27 18:05:13 R-KL-AZ-HZ.DECALCIFICATION_WEEKDAY 0
2016-11-27 18:05:13 R-KL-AZ-HZ.DISPLAY_INFORMATION 0
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_FRIDAY_1 360
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_FRIDAY_10 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_FRIDAY_11 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_FRIDAY_12 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_FRIDAY_13 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_FRIDAY_2 1320
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_FRIDAY_3 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_FRIDAY_4 1320
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_FRIDAY_5 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_FRIDAY_6 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_FRIDAY_7 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_FRIDAY_8 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_FRIDAY_9 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_MONDAY_1 360
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_MONDAY_10 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_MONDAY_11 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_MONDAY_12 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_MONDAY_13 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_MONDAY_2 1320
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_MONDAY_3 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_MONDAY_4 1320
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_MONDAY_5 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_MONDAY_6 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_MONDAY_7 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_MONDAY_8 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_MONDAY_9 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SATURDAY_1 300
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SATURDAY_10 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SATURDAY_11 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SATURDAY_12 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SATURDAY_13 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SATURDAY_2 1260
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SATURDAY_3 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SATURDAY_4 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SATURDAY_5 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SATURDAY_6 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SATURDAY_7 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SATURDAY_8 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SATURDAY_9 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SUNDAY_1 360
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SUNDAY_10 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SUNDAY_11 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SUNDAY_12 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SUNDAY_13 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SUNDAY_2 1320
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SUNDAY_3 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SUNDAY_4 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SUNDAY_5 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SUNDAY_6 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SUNDAY_7 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SUNDAY_8 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_SUNDAY_9 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_THURSDAY_1 360
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_THURSDAY_10 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_THURSDAY_11 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_THURSDAY_12 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_THURSDAY_13 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_THURSDAY_2 1320
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_THURSDAY_3 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_THURSDAY_4 1320
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_THURSDAY_5 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_THURSDAY_6 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_THURSDAY_7 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_THURSDAY_8 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_THURSDAY_9 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_TUESDAY_1 360
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_TUESDAY_10 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_TUESDAY_11 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_TUESDAY_12 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_TUESDAY_13 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_TUESDAY_2 1320
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_TUESDAY_3 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_TUESDAY_4 1320
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_TUESDAY_5 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_TUESDAY_6 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_TUESDAY_7 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_TUESDAY_8 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_TUESDAY_9 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_WEDNESDAY_1 360
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_WEDNESDAY_10 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_WEDNESDAY_11 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_WEDNESDAY_12 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_WEDNESDAY_13 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_WEDNESDAY_2 1320
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_WEDNESDAY_3 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_WEDNESDAY_4 1320
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_WEDNESDAY_5 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_WEDNESDAY_6 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_WEDNESDAY_7 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_WEDNESDAY_8 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.ENDTIME_WEDNESDAY_9 1440
2016-11-27 18:05:13 R-KL-AZ-HZ.GLOBAL_BUTTON_LOCK 0
2016-11-27 18:05:13 R-KL-AZ-HZ.I_VALUE_EXTERN 15
2016-11-27 18:05:13 R-KL-AZ-HZ.I_VALUE_INTERN 15
2016-11-27 18:05:13 R-KL-AZ-HZ.LOCAL_RESET_DISABLE 0
2016-11-27 18:05:13 R-KL-AZ-HZ.LOW_BAT_LIMIT 2.1
2016-11-27 18:05:13 R-KL-AZ-HZ.MANU_MODE_PRIORITIZATION 1
2016-11-27 18:05:13 R-KL-AZ-HZ.MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE 0
2016-11-27 18:05:13 R-KL-AZ-HZ.MODUS_BUTTON_LOCK 0
2016-11-27 18:05:13 R-KL-AZ-HZ.PARTY_MODE_PRIORITIZATION 1
2016-11-27 18:05:13 R-KL-AZ-HZ.P_START_VALUE_EXTERN 30
2016-11-27 18:05:13 R-KL-AZ-HZ.P_START_VALUE_INTERN 30
2016-11-27 18:05:13 R-KL-AZ-HZ.P_VALUE_EXTERN 30
2016-11-27 18:05:13 R-KL-AZ-HZ.P_VALUE_INTERN 30
2016-11-27 18:05:13 R-KL-AZ-HZ.SHOW_WEEKDAY 0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATUREFALL_MODUS 0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATUREFALL_VALUE 1.4
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATUREFALL_WINDOW_OPEN 12.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATUREFALL_WINDOW_OPEN_TIME_PERIOD 15
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_COMFORT 21.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_FRIDAY_1 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_FRIDAY_10 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_FRIDAY_11 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_FRIDAY_12 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_FRIDAY_13 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_FRIDAY_2 17.5
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_FRIDAY_3 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_FRIDAY_4 21.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_FRIDAY_5 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_FRIDAY_6 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_FRIDAY_7 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_FRIDAY_8 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_FRIDAY_9 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_LOWERING 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MAXIMUM 30.5
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MINIMUM 4.5
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MONDAY_1 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MONDAY_10 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MONDAY_11 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MONDAY_12 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MONDAY_13 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MONDAY_2 17.5
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MONDAY_3 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MONDAY_4 21.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MONDAY_5 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MONDAY_6 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MONDAY_7 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MONDAY_8 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_MONDAY_9 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_OFFSET 7
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SATURDAY_1 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SATURDAY_10 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SATURDAY_11 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SATURDAY_12 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SATURDAY_13 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SATURDAY_2 17.5
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SATURDAY_3 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SATURDAY_4 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SATURDAY_5 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SATURDAY_6 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SATURDAY_7 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SATURDAY_8 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SATURDAY_9 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SUNDAY_1 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SUNDAY_10 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SUNDAY_11 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SUNDAY_12 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SUNDAY_13 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SUNDAY_2 17.5
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SUNDAY_3 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SUNDAY_4 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SUNDAY_5 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SUNDAY_6 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SUNDAY_7 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SUNDAY_8 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_SUNDAY_9 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_THURSDAY_1 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_THURSDAY_10 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_THURSDAY_11 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_THURSDAY_12 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_THURSDAY_13 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_THURSDAY_2 17.5
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_THURSDAY_3 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_THURSDAY_4 21.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_THURSDAY_5 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_THURSDAY_6 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_THURSDAY_7 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_THURSDAY_8 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_THURSDAY_9 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_TUESDAY_1 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_TUESDAY_10 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_TUESDAY_11 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_TUESDAY_12 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_TUESDAY_13 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_TUESDAY_2 17.5
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_TUESDAY_3 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_TUESDAY_4 21.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_TUESDAY_5 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_TUESDAY_6 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_TUESDAY_7 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_TUESDAY_8 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_TUESDAY_9 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_WEDNESDAY_1 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_WEDNESDAY_10 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_WEDNESDAY_11 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_WEDNESDAY_12 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_WEDNESDAY_13 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_WEDNESDAY_2 17.5
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_WEDNESDAY_3 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_WEDNESDAY_4 21.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_WEDNESDAY_5 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_WEDNESDAY_6 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_WEDNESDAY_7 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_WEDNESDAY_8 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.TEMPERATURE_WEDNESDAY_9 17.0
2016-11-27 18:05:13 R-KL-AZ-HZ.VALVE_ERROR_RUN_POSITION 15
2016-11-27 18:05:13 R-KL-AZ-HZ.VALVE_MAXIMUM_POSITION 100
2016-11-27 18:05:13 R-KL-AZ-HZ.VALVE_OFFSET 0
Setzen kann man die Parameter entsprechend mit set config.
Leider werden diese Parameter nicht automatisch aktualisiert sondern müssen mit get config abgefragt werden. Beim Setzen der Parameter (speziell bei den Zeiten für Heizung) muss man einiges beachten. Die Angaben für einen Tag müssen komplett in einem Befehl übermittelt werden. Die Zeitangaben sind in Minuten seit Mitternacht.
set mydev config ENDTIME_MONDAY_1=360 ENDTIME_MONDAY_2=1440
Zitat von: zap am 26 November 2016, 18:48:49
Die CCU Software muss vor FHEM gestartet werden. Ich kenne zwar YAHM nicht, aber grundsätzlich kannst Du unter Linux die Startreihenfolge der Prozesse über /etc/init.d bzw. die /etc/rcx.d Logik beeinflussen. Wenn die CCU Software neu gestartet wird, muss auch der RPC-Server in FHEM neu gestartet werden, da die CCU Software in diesem Fall alle registrierten Abnehmer von Infos "vergisst".
BTW: Mittlerweile gibt es von EQ3 fertige Images für den Raspi.
Habe im depend.start einmal fhem hinzugefügt und den lxc Dienst als Voraussetzung hinzugefügt. Da hier aber die CCU virtuell läuft und dann erst gestartet wird wenn der lxc Dienst läuft, bringt das nicht wirklich viel. Habe nun quick und dirty ein sleep 30 in das fhem Start Skript gepackt ... So funktioniert es schon einmal.
Bzgl. der fertigen Images für den Raspi ... das Projekt von eq3 ist prinzipiell tot und aktuell ist Yahm die einzige vernünftige Lösung die CCU zu virtualisieren. Ist bei mir auch nur aus der Not entstanden da ich den HM LAN zuvor direkt in fhem laufen hatte und unbedingt eine CCU und dein Modul testen wollte. Nun bin ich halt dabei geblieben :)
Zitat von: zap am 26 November 2016, 18:48:49
Ich benötige die Definition und Attribute des FHEM-Device, bei dem Toggle Probleme mach. Am besten ein "list".
Hier das Beispiel der Küche aber betrifft alle Lampen.
Internals:
DEF HM-LC-DIM-Kueche
IODev HMCCU
NAME HM_LC_DIM_Kueche
NR 305
STATE off
TYPE HMCCUDEV
ccuaddr NEQ0256982
ccudevstate Active
ccuif BidCos-RF
ccuname HM-LC-DIM-Kueche
ccutype HM-LC-Dim1TPBU-FM
channels 4
statevals devstate|on|off
Readings:
2016-11-27 19:07:41 HM-LC-DIM-Kueche.0.AES_KEY 1
2016-11-27 19:07:41 HM-LC-DIM-Kueche.0.CONFIG_PENDING false
2016-11-27 19:07:41 HM-LC-DIM-Kueche.0.DEVICE_IN_BOOTLOADER false
2016-11-27 19:07:41 HM-LC-DIM-Kueche.0.DUTYCYCLE false
2016-11-27 19:07:41 HM-LC-DIM-Kueche.0.RSSI_DEVICE 1
2016-11-27 19:07:41 HM-LC-DIM-Kueche.0.RSSI_PEER 188
2016-11-27 19:07:41 HM-LC-DIM-Kueche.0.STICKY_UNREACH false
2016-11-27 19:07:41 HM-LC-DIM-Kueche.0.UNREACH false
2016-11-27 19:07:41 HM-LC-DIM-Kueche.0.UPDATE_PENDING false
2016-11-27 19:07:52 HM-LC-DIM-Kueche.1.DIRECTION off
2016-11-27 19:07:52 HM-LC-DIM-Kueche.1.ERROR_OVERHEAT off
2016-11-27 19:07:52 HM-LC-DIM-Kueche.1.ERROR_OVERLOAD off
2016-11-27 19:07:52 HM-LC-DIM-Kueche.1.ERROR_REDUCED off
2016-11-27 19:07:41 HM-LC-DIM-Kueche.1.INHIBIT false
2016-11-27 19:07:52 HM-LC-DIM-Kueche.1.LEVEL off
2016-11-27 19:07:41 HM-LC-DIM-Kueche.1.LEVEL_REAL 0.000000
2016-11-27 19:07:52 HM-LC-DIM-Kueche.1.WORKING off
2016-11-27 19:07:52 HM-LC-Dim1TPBU-FM_NEQ0256982.2.DIRECTION off
2016-11-27 19:07:52 HM-LC-Dim1TPBU-FM_NEQ0256982.2.ERROR_OVERHEAT off
2016-11-27 19:07:52 HM-LC-Dim1TPBU-FM_NEQ0256982.2.ERROR_OVERLOAD off
2016-11-27 19:07:52 HM-LC-Dim1TPBU-FM_NEQ0256982.2.ERROR_REDUCED off
2016-11-27 19:07:41 HM-LC-Dim1TPBU-FM_NEQ0256982.2.INHIBIT false
2016-11-27 19:07:52 HM-LC-Dim1TPBU-FM_NEQ0256982.2.LEVEL off
2016-11-27 19:07:41 HM-LC-Dim1TPBU-FM_NEQ0256982.2.LEVEL_REAL 0.000000
2016-11-27 19:07:52 HM-LC-Dim1TPBU-FM_NEQ0256982.2.WORKING off
2016-11-27 19:07:53 HM-LC-Dim1TPBU-FM_NEQ0256982.3.DIRECTION off
2016-11-27 19:07:53 HM-LC-Dim1TPBU-FM_NEQ0256982.3.ERROR_OVERHEAT off
2016-11-27 19:07:53 HM-LC-Dim1TPBU-FM_NEQ0256982.3.ERROR_OVERLOAD off
2016-11-27 19:07:53 HM-LC-Dim1TPBU-FM_NEQ0256982.3.ERROR_REDUCED off
2016-11-27 19:07:41 HM-LC-Dim1TPBU-FM_NEQ0256982.3.INHIBIT false
2016-11-27 19:07:52 HM-LC-Dim1TPBU-FM_NEQ0256982.3.LEVEL off
2016-11-27 19:07:41 HM-LC-Dim1TPBU-FM_NEQ0256982.3.LEVEL_REAL 0.000000
2016-11-27 19:07:53 HM-LC-Dim1TPBU-FM_NEQ0256982.3.WORKING off
2016-11-27 19:07:52 control off
2016-11-27 19:07:52 state off
Attributes:
IODev HMCCU
alias Licht Küche
ccureadings 1
ccuscaleval LEVEL:0:1:0:100
cmdIcon dimup:dimup on:on off:off dimdown:dimdown
controldatapoint LEVEL
devStateIcon {Color::devStateIcon($name,"dimmer",undef,"state")}
event-on-change-reading .*
group Licht
icon light_light
room HMCCU
statechannel 1
statedatapoint LEVEL
statevals on:100,off:0
substitute 100:on,0:off
Zitat von: theotherhalf am 27 November 2016, 14:26:05
Mein Rapsi hängt derzeit noch über WLAN am Netz.
Könnte es ebenso sein, dass nach der Nachtabschaltung des WLAN (ca.6std.) der RPC Server nicht wieder richtig ans Laufen kommt?
Habe das noch nicht nachgestellt, aber vllt. Hängt es damit zusammen?
Das Abschalten der Netzverbindung ist eine ganz schlechte Idee. Während der Abschaltung versucht die CCU ja weiterhin, Updates der Gerätezustände an FHEM bzw. den RPC-Server zu schicken. Ich nehme an, das versucht sie einige Male und gibt dann irgendwann auf.
Wenn Du das unbedingt abschalten musst, würde ich vor dem Abschalten den RPC-Server stoppen und nach dem Einschalten wieder starten.
Zitat von: ph4 am 27 November 2016, 19:15:45
Hier das Beispiel der Küche aber betrifft alle Lampen.
Kann das bei mir nachvollziehen, ist ein Bug. Wird in der neuen Version (kommt noch diese Woche) behoben.
Zitat
Attributes:
IODev HMCCU
alias Licht Küche
ccureadings 1
ccuscaleval LEVEL:0:1:0:100
cmdIcon dimup:dimup on:on off:off dimdown:dimdown
controldatapoint LEVEL
devStateIcon {Color::devStateIcon($name,"dimmer",undef,"state")}
event-on-change-reading .*
group Licht
icon light_light
room HMCCU
statechannel 1
statedatapoint LEVEL
statevals on:100,off:0
substitute 100:on,0:off
Bei den Attributen lässt sich noch das eine oder andere optimieren, speziell wenn Du Slider für das Dimmen verwenden möchtest. Das Attribut statechannel ist veraltet und bei controldatapoint fehlt die Kanalnummer (hat aber beides nichts mit dem Toggle Problem zu tun). Vorschlag:
controldatapoint 1.LEVEL
statedatapoint 1.LEVEL
substitute LEVEL!#0-0:off,#1-100:on
# Datenpunkte filtern (je nach Wunsch). Ersetze xyz durch den Namen von Kanal 1 in der CCU oder lasse xyz! komplett weg.
ccureadingfilter xyz!(^LEVEL$|ERROR)
# Schlankere Readingnames
ccureadingformat datapoint
# Fuer den Slider
substexcl control
webCmd control:on:off
widgetOverride control:slider,0,10,100
Hallo,
ich benutze FHEM jetzt schon seit einigen Jahren in meiner Wohnung ohne eine CCU. Für die Anbindung einer örtlich getrennten Lokation habe ich mich entschlossen an der "Außenstelle" eine CCU2 einzusetzen. Die grundsätzliche Konfiguration von HMCCU scheint soweit in Ordnung zu sein ("get wrkst_ccu devicelist" bzw. "get wrkst_ccu vars .*" liefern richtige Werte an FHEM zurück), ich bin jetzt aber auf folgendes Problem gestoßen:
Sobald ich mittels "set wrkst_ccu rpcserver on" manuell (bzw. auch bei Verwendung von "attr wrkst_ccu rpcserver on" in der .cfg) den RPC Server starten will, stürzt FHEM ab.
Hier der relevante Teil aus dem Log:
2016.11.28 20:58:13 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2016.11.28 20:58:14 0: HMCCU: Child process for server CB2001 started with PID -1604
2016.11.28 20:58:14 0: RPC server(s) starting
2016.11.28 20:58:14 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001
2016.11.28 20:58:14 0: CCURPC: Initializing RPC server CB2001
2016.11.28 20:58:15 2: SubProcess: onRun returned error: Attempt to reload XML/Parser.pm aborted.
Compilation failed in require at C:/HomeServer/fhem-5.7/perl/site/lib/RPC/XML/Procedure.pm line 530.
2016.11.28 20:58:15 2: CCURPC: Eventcount DD = 0
2016.11.28 20:58:15 2: CCURPC: Eventcount EV = 0
2016.11.28 20:58:15 2: CCURPC: Eventcount EX = 0
2016.11.28 20:58:15 2: CCURPC: Eventcount IN = 0
2016.11.28 20:58:15 2: CCURPC: Eventcount ND = 0
2016.11.28 20:58:15 2: CCURPC: Eventcount RA = 0
2016.11.28 20:58:15 2: CCURPC: Eventcount RD = 0
2016.11.28 20:58:15 2: CCURPC: Eventcount SL = 0
2016.11.28 20:58:15 2: CCURPC: Eventcount UD = 0
2016.11.28 20:58:15 2: CCURPC: Eventcount total = 0
2016.11.28 20:58:15 2: CCURPC: Eventcount writeerror = 0
Das im "XML/Procedure.pm" angeführte "require XML::Parser;" Perl Modul ist vorhanden.
perl\site\bin\cpanm XML::Parser -> XML::Parser is up to date. (2.44)
Ich bin kein Perl Spezialist und in Bezug auf FHEM auch nur Anwender, daher meine Frage an euch ob ihr mir da weiterhelfen könnt?
Zu meiner Installation:
-> FHEM 5.7 mit letztem Update von heute
-> Perl: strawberry-perl-5.24.0.1-32bit-portable
-> auf Windows 10 Pro
Schon mal herzlichen Dank vorab
LG
autLaW
Das dürfte mit der Perl Implementierung unter Windows zusammenhängen. Das habe ich nie getestet. Sowohl HMCCU als auch Subprocess.pm (Teil von FHEM) nutzen Unix bzw. Linux spezifische Mechanismen um Subprozesse zu starten und zu steuern. Ich kenne niemanden, der das so unter Windows am Laufen hat.
Du kannst nochmal prüfen, ob die Parser.pm im gleichen Verzeichnis wie die Procedure.pm vorhanden ist. Ansonsten sehe ich 3 Möglichkeiten für Dich:
1. Du steigst auf Linux um (mit Raspi) bzw einem zusätzlichen FHEM
2. Du nutzt den RPC-Server nicht sondern führst per AT-Device in FHEM alle paar Sekunden den HMCCU Befehl "get update" aus. Der Aktualisiert alle Readings manuell, braucht aber deutlich mehr Ressourcen als der RPC-Server
3. Du nutzt keine CCU sondern Deine bisherige Lösung.
Ich nehme an, die aktuellen Versionen der Perl Module RPC::XML::Server und RPC::XML::Client sind installiert?
Hallo zap,
danke das du dich gemeldet hast und auch herzlichen dank an dich für deinen persönlichen Aufwand den du mit diesem Modul betreibst!
So, zur Vollständigkeit:
-> "Parser.pm im gleichen Verzeichnis wie die Procedure.pm" ... ja, bei mir beide unter "C:\HomeServer\fhem-5.7\perl\site\lib\RPC\XML"
-> "aktuellen Versionen der Perl Module RPC::XML::Server und RPC::XML::Client sind installiert?" ... ja, folgenden Output habe ich bei der HMCCU Installation mitgeschrieben:
perl\site\bin\cpanm RPC::XML::Client -> Successfully installed RPC-XML-0.80
perl\site\bin\cpanm RPC::XML::Server -> RPC::XML::Server is up to date. (1.73)
Update zu meinem Problem:
Inzwischen bin ich schon einen Schritt weiter. Mir ist eingefallen das ich bei der Installation von FHEM und HMCCU in der Konsole (CMD) zuerst den Pfad ergänzt habe (so wie es in der FHEM Win Installation beschrieben ist):
PATH=C:\HomeServer\fhem-5.7\c\bin;C:\HomeServer\fhem-5.7\perl\bin;%PATH%
Also habe ich testweise FHEM in einer Konsole gestartet. Zuerst ohne die Pfad Modifikation (-> selber Fehler) und dann mit der Pfad Modifikation und plötzlich läßt sich der RPC Server starten ::)
Naja, das hätte mir eigentlich nicht passieren dürfen. ;D
Hier der dazu passende Log-Auszug:
2016.11.29 08:36:01 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2016.11.29 08:36:02 0: HMCCU: Child process for server CB2001 started with PID -1620
2016.11.29 08:36:02 0: RPC server(s) starting
2016.11.29 08:36:02 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001
2016.11.29 08:36:02 0: CCURPC: Initializing RPC server CB2001
2016.11.29 08:36:04 0: CCURPC: Callback server created listening on port 7401
2016.11.29 08:36:04 1: CCURPC: CB2001 Adding callback for events
2016.11.29 08:36:04 1: CCURPC: CB2001 Adding callback for new devices
2016.11.29 08:36:04 1: CCURPC: CB2001 Adding callback for deleted devices
2016.11.29 08:36:04 1: CCURPC: CB2001 Adding callback for modified devices
2016.11.29 08:36:04 1: CCURPC: CB2001 Adding callback for replaced devices
2016.11.29 08:36:04 1: CCURPC: CB2001 Adding callback for readded devices
2016.11.29 08:36:04 1: CCURPC: CB2001 Adding callback for list devices
2016.11.29 08:36:04 0: CCURPC: CB2001 Entering server loop
2016.11.29 08:36:09 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2016.11.29 08:36:16 1: HMCCU: Registering callback http://192.168.1.13:7401/fh2001 with ID CB2001 at http://my.Remote.Location.xyz:2001/
D.h. der RPC Server funktioniert grundsätzlich auch unter Windows.
Nun aber zum nächsten Problem:
Wie man oben sehen kann wird der RPC Callback mit der lokalen IP Adresse (192.168...) bei der entfernten CCU registriert (DNS Name). Da mein FHEM und die CCU in unterschiedlichen Netzwerken sind und ich die Verbindung über das Internet aufbaue passiert natürlich folgendes:
2016.11.29 08:38:23 1: HMCCU: RPC callback with URL http://192.168.1.13:7401/fh2001 initialized
2016.11.29 08:38:28 0: HMCCU: Periodical check found no RPC Servers
2016.11.29 08:38:28 1: HMCCU: Deregistering RPC server http://192.168.1.13:7401/fh2001 at http://my.Remote.Location.xyz:2001/
2016.11.29 08:38:43 0: HMCCU: All RPC servers stopped
@zap, ich denke ich brauche hier speziell deine Hilfe: wo kann ich im HMCCU Modul für meine lokale FHEM Installation einen DNS Namen hinterlegen der dann für die Callback Registrierung verwendet wird (anstatt der lokalen IP Adresse)? Bzw. ist der Callback Port immer 7401, oder kann man den einstellen?
Danke!
Zitat von: autLaW am 29 November 2016, 09:23:08
Hallo zap,
danke das du dich gemeldet hast und auch herzlichen dank an dich für deinen persönlichen Aufwand den du mit diesem Modul betreibst!
Purer Eigennutz ;-)
Zitat
D.h. der RPC Server funktioniert grundsätzlich auch unter Windows.
Erstaunlich finde ich, dass er die Queue-Files (/tmp/ccuqueue_xxx) anlegen kann. Wo landen die denn unter Windows?
Zitat
Wie man oben sehen kann wird der RPC Callback mit der lokalen IP Adresse (192.168...) bei der entfernten CCU registriert (DNS Name). Da mein FHEM und die CCU in unterschiedlichen Netzwerken sind und ich die Verbindung über das Internet aufbaue passiert natürlich folgendes:
2016.11.29 08:38:23 1: HMCCU: RPC callback with URL http://192.168.1.13:7401/fh2001 initialized
2016.11.29 08:38:28 0: HMCCU: Periodical check found no RPC Servers
2016.11.29 08:38:28 1: HMCCU: Deregistering RPC server http://192.168.1.13:7401/fh2001 at http://my.Remote.Location.xyz:2001/
2016.11.29 08:38:43 0: HMCCU: All RPC servers stopped
D.h. Dein Router registriert seine Internet IP vermutlich bei einem Dyn-DNS Dienst. Für die Verbindung der externen CCU richtest Du entsprechend eine Port-Weiterleitung ein, korrekt?
Schwierig. Beim Starten des RPC-Servers ermittelt HMCCU die eigene IP und regisitriert diese bei der CCU. Ich müsste eine Möglichkeit (zusätzliches Attribut) einbauen, damit man diese IP bei Bedarf durch einen Namen überschreiben kann (keine große Sache). Auch der Port ist momentan nicht frei konfigurierbar (auch das könnte ich lösen). Kommt dann in einer der nächsten Versionen. Hast Du mal darüber nachgedacht, einen VPN Tunnel aufzubauen? Spart die potenziell unsichere Freigabe von Ports auf dem Router.
Was mich wundert ist die Meldung "Periodical check found no RPC Servers". HMCCU prüft alle paar Sekunden, ob der RPC-Server Prozess noch läuft. Diese Prüfung scheint unter Windows fehl zu schlagen. D.h. der RPC-Server Prozess läuft vermutlich noch, HMCCU erkennt das aber falsch. Kannst Du diese Vermutung bitte verifizieren, d.h. prüfen, ob im Taskmanager der Prozess noch da ist (PID steht im Log)?
ZitatErstaunlich finde ich, dass er die Queue-Files (/tmp/ccuqueue_xxx) anlegen kann. Wo landen die denn unter Windows?
Nachdem ich auf meinem Homeserver nur eine Partition habe (c:) und wohl c:\tmp auch unter Windows standard ist ergab sich das Problem wohl nicht. Auf jeden Fall finde ich unter c:\tmp zwei Dateien ("ccuqueue_2001.dat" und "ccuqueue_2001.idx") die wohl vom Zeitstempel her neue angelegt werden wenn der RPC Server gestartet wird.
ZitatD.h. Dein Router registriert seine Internet IP vermutlich bei einem Dyn-DNS Dienst. Für die Verbindung der externen CCU richtest Du entsprechend eine Port-Weiterleitung ein, korrekt?
Ja genau. Beide Router haben eine dynamische DNS Registrierung und Anfragen können entsprechend über Port Forwards an die CCU bzw. FHEM geleitet werden.
Wenn du wie beschrieben den lokalen DNS-Namen + Port (FHEM seitige) einstellbar machen könntest wäre das toll.
Zitat
Hast Du mal darüber nachgedacht, einen VPN Tunnel aufzubauen? Spart die potenziell unsichere Freigabe von Ports auf dem Router.
Ja, natürlich mache ich mir darüber Gedanken und ist wohl auch in Zukunft anzustreben. Derzeit scheitert es an den unterschiedlichen Routern und der begrenzten Zeit die ich investieren kann. :-\
Zitat
Kannst Du diese Vermutung bitte verifizieren, d.h. prüfen, ob im Taskmanager der Prozess noch da ist (PID steht im Log)?
Nein, die Prozess-ID (wie im Log geschrieben) kann ich im Taskmanager nicht mehr finden. Es ist sogar so das kurz nach dem Starten wenn die PID ins Log geschrieben wird der Prozess auch nicht im Taskmanger sichtbar ist (bzw. ist vermutlich der Update der Anzeige so träge das ich es nicht sehe bevor der Prozess wieder weg ist).
Zitat von: autLaW am 29 November 2016, 11:51:44
Nein, die Prozess-ID (wie im Log geschrieben) kann ich im Taskmanager nicht mehr finden. Es ist sogar so das kurz nach dem Starten wenn die PID ins Log geschrieben wird der Prozess auch nicht im Taskmanger sichtbar ist (bzw. ist vermutlich der Update der Anzeige so träge das ich es nicht sehe bevor der Prozess wieder weg ist).
Gut, möglicherweise startet der Perl fork() unter Windows auch nur einen neuen Thread, der in der Standardansicht des Taskmanagers nicht angezeigt wird. Bin leider aus der Windows Welt schon einige Jahre raus und nutze nur noch MacOS und Linux. Möglicherweise hilft der Befehl tasklist als Admin auf Konsolenebene ausgeführt. Es wäre nur gut zu wissen, ob der RPC-Server wirklich nicht mehr läuft. Gibt es noch andere Meldungen im Log als die, die Du schon gepostet hast?
Das eigentliche Problem ist jedoch die Art und Weise, wir HMCCU prüft, ob der RPC-Server läuft. Dazu wird nämlich per kill() ein Signal an den Prozess geschickt und das Ergebnis ausgewertet. Das dürfte unter Windows (vielleicht) nicht funktionieren.
Zitat von: zap am 29 November 2016, 13:14:48
der in der Standardansicht des Taskmanagers nicht angezeigt wird
hier bieten sich auch tools wie der prozessexplorer anhttps://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx
Zitatmöglicherweise startet der Perl fork() unter Windows auch nur einen neuen Thread, der in der Standardansicht des Taskmanagers nicht angezeigt wird
Ja, das kann ich jetzt auch bestätigen. Mittels Prozessexplorer (Danke an chris1284!) habe ich die im Log angeführte "PID" als Thread unter dem allgemeinen FHEM-Perl-Prozess gefunden. D.h. der RPC Server läuft tatsächlich weiter.
Anmerkung: wenn ich den "set wrkst_ccu rpcserver on" Befehl wiederholt ausführe dann werden jedes mal neue Threads erzeugt (wobei alle alten bestehen bleiben).
ZitatGibt es noch andere Meldungen im Log als die, die Du schon gepostet hast?
Es gibt keine anderen Meldungen die auf das HMCCU Modul zurückzuführen sind, jedoch hatte ich aus dem vorhergehenden Auszug einige Meldungen gelöscht die nicht vom HMCCU Modul kommen.
Jedoch bei genauerem Hinsehen, fällt mir auf das diese Meldungen immer mit den HMCCU Meldungen gemeinsam auftreten (Anmerkung: der "Unknown Code" ist jedoch immer anders).
Das Betroffene Device ist mein HM-LAN Adapter ("HMLAN1") den ich in FHEM verwende um die lokalen HM Geräte zu integrieren.
Sehr interessant ist die Tatsache das diese Meldungen immer "vermeintlich" Zeitgleich innerhalb von einer Sekunde auftreten.
D.h. kann es hier eine Abhängigkeit zwischen HMCCU und HMLAN geben?
2016.11.29 18:07:33 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2016.11.29 18:07:40 1: HMCCU: Registering callback http://192.168.1.13:7401/fh2001 with ID CB2001 at http://my.Remote.Location.xyz:2001/
2016.11.29 18:09:47 1: HMCCU: RPC callback with URL http://192.168.1.13:7401/fh2001 initialized
2016.11.29 18:09:47 1: 192.168.1.14:1000 disconnected, waiting to reappear (HMLAN1)
2016.11.29 18:09:47 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.11.29 18:09:47 1: HMLAN_Parse: HMLAN1 new condition init
2016.11.29 18:09:47 1: 192.168.1.14:1000 reappeared (HMLAN1)
2016.11.29 18:09:47 3: HMLAN1: Unknown code A0C5xxxxxxxxxxxxxxxxxxxxx32::-47:HMLAN1, help me!
2016.11.29 18:09:47 1: HMLAN_Parse: HMLAN1 new condition ok
2016.11.29 18:09:52 0: HMCCU: Periodical check found no RPC Servers
2016.11.29 18:09:52 1: HMCCU: Deregistering RPC server http://192.168.1.13:7401/fh2001 at http://my.Remote.Location.xyz:2001/
2016.11.29 18:10:07 0: HMCCU: All RPC servers stopped
Anmerkung: diese "HMLAN1: Unknown code A0C5xxxxxxxxxxxxxxxxxxxxx32::-47:HMLAN1, help me!" Log-Einträge habe ich schon lange.
Diese treten immer wieder am Tag auf. Ich hab sie bisher immer ignoriert.
Ich habe es dann mal geschafft die CCU2 einzubinden und auch meine drei Thermostate einzubinden... allerdings frage ich mich jetzt wie ich das ganze schöner machen kann.
Wenn ich zb die Temperatur ändern will muss ich als befehl "set HM_HeizungBad datapoint 4.PARTY_TEMPERATURE <wert>" eingeben was ich eher umständlich finde.
Gibt es eine möglichkeit das schöner zu gestallten ? zb einen regler in fhem anlegen oder so etwas ? und sry wenn das schon geklärt oder gefragt worden ist aber in einzelnen threads suchen ist ja leider nicht möglich :/
Zitat von: zap am 28 November 2016, 09:56:51
Kann das bei mir nachvollziehen, ist ein Bug. Wird in der neuen Version (kommt noch diese Woche) behoben.
Bei den Attributen lässt sich noch das eine oder andere optimieren, speziell wenn Du Slider für das Dimmen verwenden möchtest. Das Attribut statechannel ist veraltet und bei controldatapoint fehlt die Kanalnummer (hat aber beides nichts mit dem Toggle Problem zu tun). Vorschlag:
controldatapoint 1.LEVEL
statedatapoint 1.LEVEL
substitute LEVEL!#0-0:off,#1-100:on
# Datenpunkte filtern (je nach Wunsch). Ersetze xyz durch den Namen von Kanal 1 in der CCU oder lasse xyz! komplett weg.
ccureadingfilter xyz!(^LEVEL$|ERROR)
# Schlankere Readingnames
ccureadingformat datapoint
# Fuer den Slider
substexcl control
webCmd control:on:off
widgetOverride control:slider,0,10,100
Vielen Dank für die Info, habe ich gleich mal so umgesetzt. Ist wirklich nun deutlich übersichtlicher.
Ich habe in Sachen Dimmer mal die Darstellung des halbrunden Kreises (bei den Gerätedefinitionen, arbeitet im Bereich 0-1) auf die von Dir empfohlene Darstellung umgestellt, weil ich sie auch schöner zu bedienen finde und ich mehrere solcher Schieberegler habe:
Internals:
DEF MEQ0395724 1
IODev HMCCU2
NAME WZ.Deckenbeleuchtung
NR 1134
STATE 0
TYPE HMCCUDEV
ccuaddr MEQ0395724
ccudevstate Active
ccuif BidCos-RF
ccuname WZ.Deckenbeleuchtung
ccutype HM-LC-Dim1TPBU-FM
channels 4
statevals devstate
Readings:
2016-12-02 12:14:02 1.LEVEL off
2016-12-02 12:14:02 1.LEVEL_REAL 0
2016-12-02 05:31:23 2.LEVEL 1
2016-12-02 12:14:02 2.LEVEL_REAL 0
2016-12-02 05:31:23 3.LEVEL 1
2016-12-02 12:14:02 3.LEVEL_REAL 0
2016-12-02 12:14:02 control 0
2016-12-02 12:14:02 state off
Attributes:
IODev HMCCU2
alias Wohnzimmer Deckenlampe
ccureadingfilter (LEVEL)
ccureadingformat datapoint
ccureadings 1
ccuverify 2
controldatapoint 1.LEVEL
devStateIcon {Color::devStateIcon($name,"dimmer",undef,"state")}
devStateStyle style="text-align:right;"
event-on-change-reading .*
group Licht
icon light_ceiling
room Device,Wohnzimmer
stateFormat {sprintf("%d",ReadingsVal($name,"1.LEVEL",0)*100)}
statedatapoint 1.LEVEL
stripnumber 2
substexcl control
substitute LEVEL!#0-0:off,#1-100:on
webCmd control:on:off
widgetOverride control:slider,0,10,100
Leider bekomme ich einen Fehler, wenn ich auf on oder off schalte (Unknown argument ...). Bei Werten auf dem Slider < 50 springt der Slider auf 0, das Licht wird nicht geschaltet, bei Werten > 50 springt er im 1.LEVEL auf 1, das Licht wird voll aufgedimmt. Irgendwas habe ich übersehen, oder?
Da scheint das Attribut ccuscaleval zu fehlen:
ccuscaleval LEVEL:0:1:0:100
Dann sieht Dein stateformat auch etwas einfacher aus, nämlich nur LEVEL. Die Multiplikation mit 100 sowie das Teilen durch 100 beim setzen der Werte übernimmt HMCCU.
Das war's :D
Thx
ich habe einmal eine HMCCU eingerichtet - parallel zu meiner FHEM Installation.
das automatische einbinden ist schief gegangen da der default-name in der CCU ein Leerzeichen beinhaltet. Ich muss also erst alles umbenennen? Macht sicher sinn, muss man nur wissen. Wäre cool wenn zu fehlermendungen kommt bei Leerzeichen.
dann habe ich die Kanäle umbenannt - jeden einzeln ( schönes FHEM :) ). Hierbei kann ein Kanal den gleichen Namen haben wie das Device. Dann klappt es nicht wirklich meine ich. Das Device fehlte am Ende.
Weiter habe ich dann neue Namen vergeben. Die alten Devices haben weiter existiert.
=> wie kann ich einen sauberen Abgleich machen: Alle Devices eintragen, Fehler erkennen, Umbenannte löschen oder umbenennen? Ohne Sync der Gerätenamen sehe ich Probleme.
Es scheint mir so, dass hierbei noch mehr Entities angelegt werden als in FHEM. Ein Device ist a) das Device und b) Device mit Channel 0.
Es scheint demnach nicht die Absicht der des Moduls zu sein, ein umfassendes Abbild in FHEM zu erstellen - korrekt?
Die CCU macht immer ein Leerzeichen in den Namen des Device oder des oder der Channel beim Anlernen. Da ich diese in der CCU aber nicht umbenennen möchte, wie kann ich diese in FHEM per
get CCU2 devicelist create ...
importieren? Jedes Device oder Channel in der CCU umzubenennen ist sehr umständlich.
Zitat von: martinp876 am 04 Dezember 2016, 20:17:15
ich habe einmal eine HMCCU eingerichtet - parallel zu meiner FHEM Installation.
das automatische einbinden ist schief gegangen da der default-name in der CCU ein Leerzeichen beinhaltet. Ich muss also erst alles umbenennen? Macht sicher sinn, muss man nur wissen. Wäre cool wenn zu fehlermendungen kommt bei Leerzeichen.
Was meinst Du mit automatischem Einbinden? Hast Du versucht, ein einzelnes Device oder einen einzelnen Channel in FHEM zu definieren oder wolltest Du per "get devicelist create" alles auf einmal anlegen?
Grundsätzlich unterstützen HMCCU,HMCCUDEV und HMCCUCHN CCU Geräte und Kanäle mit Leerzeichen im Namen, da die Kommunikation immer über die Seriennummer/Adresse erfolgt.
Das Problem ist das Define in FHEM. Bisher benutzen die Module nicht die neue Commandline Parserfunktion. Daher wird ein CCU Name mit Leerzeichen beim Define wie 2 Argumente behandelt. Man kann sich bei einem einzelnen Define aber behelfen, indem man statt des Namens die Seriennummer/Adresse angibt. Leider funktioniert das bei "get devicelist create" nicht (meine Schuld, wird korrigiert).
Zitat
dann habe ich die Kanäle umbenannt - jeden einzeln ( schönes FHEM :) ). Hierbei kann ein Kanal den gleichen Namen haben wie das Device. Dann klappt es nicht wirklich meine ich. Das Device fehlte am Ende.
Ja, das liegt daran, dass HMCCU beim Ansprechen der CCU Geräte und Kanäle einen generischen "GetObject" Aufruf durchführt. CCU seitig ist alles ein Objekt, ob jetzt Kanal, Gerät, Systemvariable, Raum, usw. Daher darf ein Name in der CCU nicht doppelt verwendet werden. Sonst müsste HMCCU jedes mal den kompletten Objektbaum der CCU durchforsten und den Objekttyp überprüfen. Das wäre aufwändig und langsam.
Grundsätzlich würde ich eh dazu raten, sich für CCU Geräte und Kanäle ein eingängiges Namenskonzept zu überlegen. Das macht das Leben (nach der Umbenennung) leichter.
Zitat
Weiter habe ich dann neue Namen vergeben. Die alten Devices haben weiter existiert.
Also die alten Devices in FHEM(?). Bei jeglicher Änderung an Geräten oder Kanälen in der CCU generiert HMCCU einen FHEM Event (es sei denn, ich habe da noch einen Bug drin). Sonderfall: Wenn man einen Namen in der CCU ändert, wird das Internal "ccuname" im FHEM Device automatisch angepasst. Ist aber nur Kosmetik, da die Kommunikation wie gesagt über Seriennummer/Adresse erfolgt.
Zitat
=> wie kann ich einen sauberen Abgleich machen: Alle Devices eintragen, Fehler erkennen, Umbenannte löschen oder umbenennen? Ohne Sync der Gerätenamen sehe ich Probleme.
Grundsätzlich sollte der Befehl "get devicelist" das leisten. Ich habe jedoch bisher davon abgesehen, vorhandene FHEM Devices einfach zu löschen. Stattdessesn wird ein Device z.B. als "deleted" gekennzeichnet.
Zitat
Es scheint mir so, dass hierbei noch mehr Entities angelegt werden als in FHEM. Ein Device ist a) das Device und b) Device mit Channel 0.
Es scheint demnach nicht die Absicht der des Moduls zu sein, ein umfassendes Abbild in FHEM zu erstellen - korrekt?
Es bleibt Dir überlassen, wie viele Entitiies Du in FHEM anlegst. Wenn Du ein Device mit HMCCUDEV anlegst, hast Du darin das Device selbst plus alle seine Kanäle an einer Stelle. Mit HMCCUCHN legst Du in FHEM ein Device für einen einzelnen Kanal an. Wenn Du nun "get devicelist create" mit einem ".*" verwendest, ist das nicht im Sinne des Erfinders, da dann sehr viele redundante Devices angelegt werden. In der nächsten Version kann man das automatische Anlegen von FHEM Devices auf CCU Geräte einschränken und Kanäle ignorieren.
Der Kanal 0 ist ein Sonderfall. Homematic Geräte haben keinen Kanal 0. Den fügt die CCU hinzu um dort Datenpunkte wie RSSI, LOWBAT oder UNREACH zu verwalten. Damit man diese Infos auch bei Devices vom Typ HMCCUCHN zur Verfügung hat, ist der Kanal 0 auch bei diesen Devices mit dabei.
@DerTom: Wie oben geschrieben: "get devicelist create" kann bald auch mit Leerzeichen in Namen umgehen. Ich empfehle trotzdem, sich ein Namenskonzept zu überlegen und das auch in der CCU umzusetzen.
Nun, mein Anspruch mag nicht der Mai stream sein, ist eben nur meine Sicht und wie ich es realisieren würde, welche Funktionalität ich mir wünsche.
Zum ersten ist es ein sauberer und kompletter Abgleich der devices. der support mit Leerzeichen kommt habe ich verstanden. Gut.
Wenn ich ein devicelist mache werden alle devices gelesen, leider kann ich sie nicht sehen. Sie stehen in helper, also unsichtbar. Warum werden sie nicht ausgegeben wenn ich ein get absetze?
Leerzeichen halte ich für kritisch. Nun, ccu nutzt es. Ich würde diese strikt durch ein _ ersetzen. Aus die Maus. Das wird immer zu Problemen führen.
Der Kanal 0 existiert im device. Das ist schon korrekt, nur kann man diesen gut handeln, muss man den User nicht mit belasten. CUL_HM geht damit entsprechend um.
Ich werde weiter spielen. Ich vergleiche natürlich culhm mit hmccu.
Aktuell schneidet (kein Wunder, ich habe meine Vorstellung realisiert) culhm nicht schlecht ab. Was fehlt ist ein komfortables Frontend fuer Register und templates. Und das unschlagbaren timing der ccu beim msg senden, da werde ich nicht ran kommen.
Aber, kein falscher Eindruck: gute Arbeit!! Ich werde weiter meine Ideen vorbringen, was immer du damit machst.
Zitat von: martinp876 am 06 Dezember 2016, 06:40:33
Wenn ich ein devicelist mache werden alle devices gelesen, leider kann ich sie nicht sehen. Sie stehen in helper, also unsichtbar. Warum werden sie nicht ausgegeben wenn ich ein get absetze?
"get devicelist dump" gibt eine Liste der Geräte und Kanäle aus. Leider nicht sehr sprechend. Habe die Ausgabe gerade für die nächste Version etwas aufgehübscht.
Zitat
Leerzeichen halte ich für kritisch. Nun, ccu nutzt es. Ich würde diese strikt durch ein _ ersetzen. Aus die Maus. Das wird immer zu Problemen führen.
Das passiert bei "get devicelist create" jetzt schon. Bringt nur leider nix, weil ich da einen grundsätzlichen Fehler drin habe (verwendet Name statt Adresse beim Define).
Zitat
Der Kanal 0 existiert im device. Das ist schon korrekt, nur kann man diesen gut handeln, muss man den User nicht mit belasten. CUL_HM geht damit entsprechend um.
Was meinst Du damit? Wäre es besser, die Datenpunkte von Kanal 0 anders darzustellen?
Zitat
Aber, kein falscher Eindruck: gute Arbeit!! Ich werde weiter meine Ideen vorbringen, was immer du damit machst.
Jede Anregung ist willkommen!
Wie kann ich ein Wochenprogramm erstellen für thermostate ?
Ich würde am liebsten drei verschiedene Programme haben. Eins für dei früh eins für die Spät und eins für freie wochen.
für jedes programm sollte eine woche abgedeckt sein für die verschiedenen wochentage von wann bis wann welche temperatur sein soll.
am besten so das es am ende der woche automatisch das programm wechselt (früh und spätschicht im wechsel) bzw manuell deaktivieren das dritte programm laufen lassen wenn ich ne woche frei habe. habe nach langem suchen nichts gefundne wie ich daas umsetzten kann.
bin für jede antwort dankbar :)
ich fürchte ccu script. einmalig kann man sie in der ccu setzen, um sie dynamisch zu wechseln kenn ich aktuell nichts. würde mich aber auch interessieren
Zitat von: wuast94 am 07 Dezember 2016, 14:56:34
Wie kann ich ein Wochenprogramm erstellen für thermostate ?
Ich würde am liebsten drei verschiedene Programme haben. Eins für dei früh eins für die Spät und eins für freie wochen.
für jedes programm sollte eine woche abgedeckt sein für die verschiedenen wochentage von wann bis wann welche temperatur sein soll.
am besten so das es am ende der woche automatisch das programm wechselt (früh und spätschicht im wechsel) bzw manuell deaktivieren das dritte programm laufen lassen wenn ich ne woche frei habe. habe nach langem suchen nichts gefundne wie ich daas umsetzten kann.
Grundsätzlich gibt es 2 Ebenen der CCU Gerätesteuerung: Über Datenpunkte (set/get datapoint) und über Konfig-Parameter (set/get config). Mit letzterer Methode erreicht man die Parameter, die man in der CCU unter "Einstellungen/Geräte" und dann Button "Einstellungen" findet.
Da die Definition von Zeitprogrammen über HMCCU sehr aufwändig und umständlich ist, würde ich Dir raten, das in der CCU zu definieren. Mit dem "set config" Befehl kannst Du in FHEM dann zwischen den Programmen wechseln.
Für ein Wandthermostat sieht der Befehl so aus:
set mytherm config WEEK_PROGRAM_POINTER=Programm
Wobei "Programm" 0,1,2 sein kann (für das zu aktivierende Programm).
Das Problem: Bei dem Heizkörperthermostat scheint es nur ein Wochenprogramm zu geben (oder kannst Du bei Dir in der CCU unter Einstellungen - Geräte und dann über den Button "Einstellen" hinter dem Thermostaten zwischen 3 Programmen wählen?).
Bei mir wird jedenfalls nur ein Programm angezeigt. Ich habe jedoch die Heizkörperthermostate mit Wandthermostaten verknüpft. Dann erfolgt die Steuerung über das Wandthermostat.
Apropos Performance - ich hab da mal ne Frage:
ich habe mir heute einen HM Funk-Taster (HM-PB-2-WM55 namens EG.LichtSchalter) kommen lassen und steuere über den einen dummy (EZ.Licht). Die Schaltzeit zum dummy beträgt dabei gut 3 Sekunden.
define LichttasterEGEin notify EG.LichtSchalter.1.PRESS_SHORT:.*|EG.LichtSchalter.1.PRESS_LONG:.* set EZ.Licht on
Woran liegt die Verzögerung? Gibt es Möglichkeiten, das zu beschleunigen?
Zitat von: Yil am 07 Dezember 2016, 19:51:48
ch habe mir heute einen HM Funk-Taster (HM-PB-2-WM55 namens EG.LichtSchalter) kommen lassen und steuere über den einen dummy (EZ.Licht). Die Schaltzeit zum dummy beträgt dabei gut 3 Sekunden.
define LichttasterEGEin notify EG.LichtSchalter.1.PRESS_SHORT:.*|EG.LichtSchalter.1.PRESS_LONG:.* set EZ.Licht on
Woran liegt die Verzögerung? Gibt es Möglichkeiten, das zu beschleunigen?
Die Kommunikation läuft so:
1. Du drückst die Taste
2. CCU schickt dem RPC-Server von HMCCU ein Event, dass die Taste gedrückt wurde.
3. RPC-Server schreibt das Event in die File-Queue
4. HMCCU liest die Filequeue alle x Sekunden und verteilt die Events an die zuständigen FHEM Devices.
Bedeutet: Die Verzögerung zwischen Tastendruck und Notification ist maximal x Sekunden. Der Wert x wird über das HMCCU Attribut rpcinterval eingestellt. Default ist 5 Sekunden. Auf meinem Raspi habe ich das auf 3 Sekunden gesetzt, wobei 2 auch noch performant läuft. Musst Du ausprobieren.
Ich hatte auch mal eine direkte Notification ohne Queues getestet. Scheitert daran, dass FHEM die Daten nicht schnell genug verarbeiten kann. Dann gehen Events verloren.
Ok, verstanden. rpcinterval 3 hab ich ausprobiert - subjektiv habe ich den Eindruck, dass nicht immer alle Schaltbefehle ausgeführt werden, insbesondere wenn man den Schalter zu oft betätigt (wobei ich immer eine Pause von 5 sec. hatte wg. des Herunterdimmens der Leuchten).
rpcinterval 2 gibt es nicht, wird im Auswahlmenü nicht angeboten.
Zitat von: Yil am 07 Dezember 2016, 21:08:34
Ok, verstanden. rpcinterval 3 hab ich ausprobiert - subjektiv habe ich den Eindruck, dass nicht immer alle Schaltbefehle ausgeführt werden, insbesondere wenn man den Schalter zu oft betätigt (wobei ich immer eine Pause von 5 sec. hatte wg. des Herunterdimmens der Leuchten).
rpcinterval 2 gibt es nicht, wird im Auswahlmenü nicht angeboten.
Kannst Du einfach per Kommandozeile einstellen:
attr xy rpcinterval 2
Events sollten eigentlich nicht verloren gehen. Bei Tastern würde ich auf jeden Fall event-on-update-reading auf .* setzen und auf event-on-change-reading verzichten.
Ok, vielen Dank - hab ich mal so eingestellt und werde es morgen testen :)
Die Version 3.6 ist nun per FHEM Update verfügbar. Folgende Änderungen gibt es:
- Modul HMCCU: Der Befehl get devicelist create für das automatische Erstellen von CCU Devices in FHEM wurde um den Parameter "t={dev|chn}" erweitert. Die Angabe t=dev (Default) legt nur Devices für Homematic Geräte an (mit HMCCUDEV), während t=chn nur Devices für Homematic Kanäle anlegt. Außerdem wurde ein Bug behoben, der das Anlegen von Devices verhindert hat, die in der CCU ein Leerzeichen im Namen haben.
- Modul HMCCU: Das neue Attribut rpcserveraddr ermöglicht die Angabe einer IP-Adresse oder eines DNS-Namens, an den die CCU Events schicken soll. Dadurch ist es möglich, eine CCU über eine Internetverbindung mit FHEM zu verbinden. In diesem Fall würde man bei rpcserveraddr die öffentliche IP bzw. den DynDNS-Eintrag des Routers angeben, über das FHEM aus dem Internet erreichbar ist. Zusätzlich muss auf dem Router ein Portforwarding eingerichtet werden (s.u. Attribut rpcserverport).
- Modul HMCCU: Das neue Attribut rpcserverport ermöglicht die Änderung der Ports, auf die die CCU Events an den RPC-Server schickt. Der hier angegebene Port ist lediglich ein Basisport, aus dem die tatsächlich genutzten Ports berechnet werden. Dazu wird folgende Formel verwendet: Port = rpcserverport + rpcport + (ccunumber * 10). Dabei entspricht rpcport dem Inhalt des Attributs rpcport, also 2000, 2001, 2010 oder 9292. Der Wert ccunumber ist bei einer CCU immer 0 (Vorbereitung für die nächste Version, die mehrere CCUs unterstützen wird). Beispiel: Bei einer Installation mit BidCos-RF und HM-IP (rpcport=2001,2010) und mit rpcserverport=5400 ergeben sich somit folgende tatsächlich genutzten Ports: 5400+2001+(0*10)=7401, 5400+2010+(0*10)=7410. Bei einer Verbindung CCU - FHEM über das Internet müsste entsprechend für diese beiden Ports auf dem Router ein Portforwarding eingerichtet werden.
- Modul HMCCU: Einführung einer CCU-Nummer als Vorbereitung für die Unterstützung mehrerer CCUs in der nächsten Version. Dateinamen der Queue-Files des RPC-Servers enhalten nun auch die CCU-Nummer. Die erste CCU hat die Nummer 0.
- Modul HMCCU: Einführung von Aggregationsregeln, Attribut ccuaggregate und Befehl get aggregation. Mit diesen Regeln können Fragen beantwortet werden wie z.B. "Sind gerade Fenster geöffnet und wenn ja, welche?", "Wieviele und welche Devices haben ein Batterieproblem?". Weitere Erläuterungen siehe Online-Hilfe oder im FHEM Wiki (https://wiki.fhem.de/wiki/HMCCU#Aggregation_von_Ger.C3.A4tezust.C3.A4nden_.28ab_3.6.29)
Habe gerade ein Update gemacht.
Meine CCUNum wurde auf 1 gesetzt. Habe auch nur eine CCU.
Im Beitrag oberhalb steht aber bei einer CCU CCUnum 0.
Was mir jedoch aufgefallen ist.
Bei einem "Shutdown restart", ist die CCU bisher immer recht flott selbstständig auf OK gegangen. Sprich der RPC wurde automatisch gestartet.
Jetzt nach dem Update bleibt "RPCState-stopped" und "STATE auf Initialized".
Auch wenn ich mehrere Minuten warte.
Muss händisch den RPC wieder starten dann geht wieder alles.
Vielen Dank für den Hinweis! Habe das korrigiert und 88_HMCCU.pm neu eingecheckt.
Hallo zusammen
ich bekomme nach dem heutigen Update die CCU2 nicht "zum Laufen" nach dem Versuch den RPC Server zu starten, kam die Meldung
HMCCU: CCU2 Start of RPC server failed ,
auch sind die Clients "weg" (Update gegen 17 Uhr)
die log "sagte" auch nur RPC server nicht gestartet
Nach der Rücksetzung auf die gestrige version funktioniert alles wieder ?
FHEM ist auf dem neuesten Stand
Cubieboard wird auch 1 mal in der Woche geupdatet
was habe ich beim update übersehen?
Gruss tagedieb
Hi zap,
ich habe gerade auf Version 3.6 aktualisiert, da ich die Aggregationsregeln gut gebrauchen kann.
Vier Sachen sind mir aufgefallen:
Zum einen funktioniert der automatische Start nach dem Fhem reboot bei mir auch nicht. Aber dafür hast Du ja schon ein weiteres Update für morgen eingestellt.
Dann komme ich mit dem Namen und dem Prefix nicht klar. Bei mir verwendet er immer nur den Namen als Prefix, aber nicht den Wert, den ich als Prefix definiere?
Die Aktualisierung der neuen Attribute funktioniert bei mir nicht automatisch. Aktualisiert wird nur, wenn ich manuell get ... aggregation ... auslöse.
Und als letztes eine praktisch Frage zu den Fensterkontakten. Ich habe sowohl die optischen (offen, geschlossen) als auch die mechanischen an den Griffen (offen, gekippt, geschlossen) im Einsatz. Wenn ich es richtig verstanden habe, kann das if aber nur einen Wert abfragen, z.B. offen. Ich würde aber auch gerne im if offen und gekippt gleichzeitig abfragen. Geht das irgendwie?
Viele Grüße
Christian
Zitat von: tagedieb am 12 Dezember 2016, 18:15:27
Hallo zusammen
ich bekomme nach dem heutigen Update die CCU2 nicht "zum Laufen" nach dem Versuch den RPC Server zu starten, kam die Meldung
HMCCU: CCU2 Start of RPC server failed ,
auch sind die Clients "weg" (Update gegen 17 Uhr)
die log "sagte" auch nur RPC server nicht gestartet
Nach der Rücksetzung auf die gestrige version funktioniert alles wieder ?
Mm, dazu 3 Fragen:
1. gibt es noch weitere Meldungen im Log?
2. Steht im Internal CCUNum eine 0 oder 1?
3. Hast Du das Attribut rpcport gesetzt?
Zitat von: cho am 12 Dezember 2016, 19:04:42
Zum einen funktioniert der automatische Start nach dem Fhem reboot bei mir auch nicht. Aber dafür hast Du ja schon ein weiteres Update für morgen eingestellt.
Könnte auch ein anderes Problem sein. Versuche das gerade einzugrenzen, da es bei mir funktioniert. Welchen Wert hat bei Dir das. internal CCUNum und hast Du rpcport gesetzt?
Zitat
Dann komme ich mit dem Namen und dem Prefix nicht klar. Bei mir verwendet er immer nur den Namen als Prefix, aber nicht den Wert, den ich als Prefix definiere?
Ist vermutlich ein Bug den ich nicht bemerkt habe, weil ich immer den Namen als Präfix nutze.
Zitat
Die Aktualisierung der neuen Attribute funktioniert bei mir nicht automatisch. Aktualisiert wird nur, wenn ich manuell get ... aggregation ... auslöse.
Sollte aber, da das normale FHEM interne Notify genutzt wird. Setzt aber ein Event voraus. Je nach Gerätetyp musst du event-on-change-reading oder event-on-update-reading auf .* setzen bzw im Eventmonitor beobachten, ob Events beim Update der entsprechenden Aggregationsreadings auftauchen.
Zitat
Und als letztes eine praktisch Frage zu den Fensterkontakten. Ich habe sowohl die optischen (offen, geschlossen) als auch die mechanischen an den Griffen (offen, gekippt, geschlossen) im Einsatz. Wenn ich es richtig verstanden habe, kann das if aber nur einen Wert abfragen, z.B. offen. Ich würde aber auch gerne im if offen und gekippt gleichzeitig abfragen. Geht das irgendwie?
Muss ich mir anschauen. Sollte möglich sein, wenn if einen regulären Ausdruck akzeptiert.
Ich hab ein ganz merkwürdiges Phänomen seit einigen Tagen: einige Sensoren melden ihre Werte nicht mehr an die CCU (resp. die CCU nimmt die Werte nicht auf). Es handelt sich bei mir um einen Heligkeitswert (aus einem externen Bewegungsmelder) und Klimawerte von Thermostaten.
Erst der Start der CCU2 und dann anschließend des entsprechenden FHEM-Moduls liefern die Sensoren Werte. Blöd ist, dass meine ganze Lichtsteuerung an der zu erlässigen Lieferung eines Helligkeitswertes hängt, und die ist nun komplett aus dem Trit gekommen.
Nach dem Neustart der CCU und dem Neustart des rpc-Servers funktioniert wirder alles - zumindest kurzzeitig. Danach steigt der Bewegungsmesser als erstes und später dann die Themperatursensoren wieder aus. Ich hatte zentral rpcinterval auf 2 gesetzt. Kann das eine Ursache sein. Ich glaube ja nicht, dass alle 3 Sensoren glichzeitig kaput gehen. Ob es die CCU selbst sein könnte oder ein Bug im HMCCU-Modul?
An rpcinterval liegt es sicher nicht. Das beeinflusst nur, wie häufig FHEM die Events der CCU aus den Queue-Files (ebenfalls FHEM Seite) liest. Das bremst höchstens FHEM aus.
Wenn die Helligkeitswerte nicht mal an der CCU2 direkt ankommen, hast Du ein reines Homematic Problem. Hat sich sonst irgendwas an Deiner Installation geändert? Wurde eine potenzielle Störquelle installiert?
Ich habe ebenfalls einen Lichtsensor. Der "frisst" Batterien und steigt dann irgendwann aus. Aber das scheint bei Dir ja nicht der Fall zu sein.
An alle, die beim Starten des RPC-Servers mit Version 3.6 Probleme haben, hier mal ein Log-Auszug von meiner Installation. Gestartet werden 3 RPC-Server für die Ports (rpcport) 2001, 2010, 9292. Keinerlei Probleme. Dazu muss ich allerdings erwähnen, dass ich nach einem FHEM Update niemals "shutdown restart" verwende sondern von Linux aus mit "/etc/init.d/fhem stop" bzw. start.
Diejenigen, die Probleme mit dem Start haben, können ja mal die Logs mit ihren vergleichen.
2016.12.12 13:30:50 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2016.12.12 13:30:50 0: HMCCU: Child process for server CB2001 started with PID 13081
2016.12.12 13:30:50 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001_0
2016.12.12 13:30:50 0: CCURPC: Initializing RPC server CB2001
2016.12.12 13:30:50 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2016.12.12 13:30:50 0: HMCCU: Child process for server CB2010 started with PID 13082
2016.12.12 13:30:50 0: CCURPC: CB2010 Creating file queue /tmp/ccuqueue_2010_0
2016.12.12 13:30:50 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2016.12.12 13:30:50 0: CCURPC: Initializing RPC server CB2010
2016.12.12 13:30:50 0: HMCCU: Child process for server CB9292 started with PID 13083
2016.12.12 13:30:50 0: CCURPC: CB9292 Creating file queue /tmp/ccuqueue_9292_0
2016.12.12 13:30:50 0: CCURPC: Initializing RPC server CB9292
2016.12.12 13:30:50 0: RPC server(s) starting
2016.12.12 13:30:51 0: CCURPC: Callback server created listening on port 7401
2016.12.12 13:30:51 1: CCURPC: CB2001 Adding callback for events
2016.12.12 13:30:51 1: CCURPC: CB2001 Adding callback for new devices
2016.12.12 13:30:51 1: CCURPC: CB2001 Adding callback for deleted devices
2016.12.12 13:30:51 1: CCURPC: CB2001 Adding callback for modified devices
2016.12.12 13:30:51 1: CCURPC: CB2001 Adding callback for replaced devices
2016.12.12 13:30:51 1: CCURPC: CB2001 Adding callback for readded devices
2016.12.12 13:30:51 1: CCURPC: CB2001 Adding callback for list devices
2016.12.12 13:30:51 1: CCURPC: CB2001 Adding callback for event query
2016.12.12 13:30:51 0: CCURPC: CB2001 Entering server loop
2016.12.12 13:30:51 0: CCURPC: Callback server created listening on port 7410
2016.12.12 13:30:51 1: CCURPC: CB2010 Adding callback for events
2016.12.12 13:30:51 1: CCURPC: CB2010 Adding callback for new devices
2016.12.12 13:30:51 1: CCURPC: CB2010 Adding callback for deleted devices
2016.12.12 13:30:51 1: CCURPC: CB2010 Adding callback for modified devices
2016.12.12 13:30:51 1: CCURPC: CB2010 Adding callback for replaced devices
2016.12.12 13:30:51 1: CCURPC: CB2010 Adding callback for readded devices
2016.12.12 13:30:51 1: CCURPC: CB2010 Adding callback for list devices
2016.12.12 13:30:51 1: CCURPC: CB2010 Adding callback for event query
2016.12.12 13:30:51 0: CCURPC: CB2010 Entering server loop
2016.12.12 13:30:51 0: CCURPC: Callback server created listening on port 14692
2016.12.12 13:30:51 1: CCURPC: CB9292 Adding callback for events
2016.12.12 13:30:51 1: CCURPC: CB9292 Adding callback for new devices
2016.12.12 13:30:51 1: CCURPC: CB9292 Adding callback for deleted devices
2016.12.12 13:30:51 1: CCURPC: CB9292 Adding callback for modified devices
2016.12.12 13:30:51 1: CCURPC: CB9292 Adding callback for replaced devices
2016.12.12 13:30:51 1: CCURPC: CB9292 Adding callback for readded devices
2016.12.12 13:30:51 1: CCURPC: CB9292 Adding callback for list devices
2016.12.12 13:30:51 1: CCURPC: CB9292 Adding callback for event query
2016.12.12 13:30:51 0: CCURPC: CB9292 Entering server loop
2016.12.12 13:30:53 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2016.12.12 13:31:00 1: HMCCU: Registering callback http://192.168.1.12:7401/fh2001 with ID CB2001 at http://homematic:2001/
2016.12.12 13:31:01 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2016.12.12 13:31:01 1: HMCCU: RPC callback with URL http://192.168.1.12:7401/fh2001 initialized
2016.12.12 13:31:04 2: CCURPC: CB2001 NewDevice received 250 device specifications
2016.12.12 13:31:04 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.12.12 13:31:04 0: HMCCU: Received SL event. RPC server CB2010 enters server loop
2016.12.12 13:31:11 1: HMCCU: Registering callback http://192.168.1.12:7410/fh2010 with ID CB2010 at http://homematic:2010/
2016.12.12 13:31:11 1: HMCCU: RPC callback with URL http://192.168.1.12:7410/fh2010 initialized
2016.12.12 13:31:12 1: CCURPC: CB2010 ListDevices. Sending init to HMCCU
2016.12.12 13:31:12 2: CCURPC: CB2010 NewDevice received 16 device specifications
2016.12.12 13:31:15 0: HMCCU: Received IN event. RPC server CB2010 initialized.
2016.12.12 13:31:15 0: HMCCU: Received SL event. RPC server CB9292 enters server loop
2016.12.12 13:31:22 1: HMCCU: Registering callback http://192.168.1.12:14692/fh9292 with ID CB9292 at http://homematic:9292/groups
2016.12.12 13:31:22 1: CCURPC: CB9292 ListDevices. Sending init to HMCCU
2016.12.12 13:31:22 2: CCURPC: CB9292 NewDevice received 12 device specifications
2016.12.12 13:31:32 1: HMCCU: RPC callback with URL http://192.168.1.12:14692/fh9292 initialized
2016.12.12 13:31:35 0: HMCCU: Received IN event. RPC server CB9292 initialized.
2016.12.12 13:31:40 2: HMCCU: Updated devices. Success=46 Failed=3
2016.12.12 13:31:40 1: HMCCU: All RPC servers running
Zitat von: zap am 13 Dezember 2016, 07:04:11
An rpcinterval liegt es sicher nicht. Das beeinflusst nur, wie häufig FHEM die Events der CCU aus den Queue-Files (ebenfalls FHEM Seite) liest. Das bremst höchstens FHEM aus.
Dachte ich mir eigentlich auch schon. Aktuell experimentiere ich mit rpcinterval = 1 ;)
Zitat von: zap am 13 Dezember 2016, 07:04:11
Wenn die Helligkeitswerte nicht mal an der CCU2 direkt ankommen, hast Du ein reines Homematic Problem. Hat sich sonst irgendwas an Deiner Installation geändert? Wurde eine potenzielle Störquelle installiert?
Stimmt, es muss ja innerhalb Homeatic sein. Ich habe einen Dimmer installiert und in der CCU2 aufgenommen, diesen aber wieder vom Strom genommen, da ich erst einige bauliche Veränderungen vornehmen muss. Seitdem produziert der in der WebGui der CCU2 eine Servicemeldung. Aber das kann es ja nicht sein, oder?
Der Device, um den es geht, steht an der Grundstücksgrenze und ist damit potenziell näher an anderen Häuser als an meinem eigenen. Ggf. kommen Störungen von außerhalb meines Systems. Ich habe mich bisher noch nicht mit der Abschirmung meines Systems ggü. Dritten beschäftigt. Bevor ich eine CCU2 hatte, habe ich einen HMLAN-Adapter betrieben und hatte (auch um andere Systeme auszuschließen) eine virtuelle CCU eingerichtet (vccu). Das Konzept gibt es ja nicht bei Dir. Daher nun die Frage: wie schirmt man einen HMCCU vernünftig ggü. anderen Systemen ab, so dass die nicht reinfunken oder einen sonstigen Unsinn anstellen?
Zitat von: zap am 13 Dezember 2016, 07:04:11
Ich habe ebenfalls einen Lichtsensor. Der "frisst" Batterien und steigt dann irgendwann aus. Aber das scheint bei Dir ja nicht der Fall zu sein.
Ich habe die Batterien nachgemessen. Von den 1,5 V sind noch je 1,476 V übrig - das kann es also auch nicht sein.
Diejenigen, die Probleme mit dem Start haben, können ja mal die Logs mit ihren vergleichen.
im log steht genau nüscht bis ich den rpc von hand starte. somit wird vermutlich nach initialisieren garnicht versucht den rpc zu starten
Hi zap,
bei mir ist es das gleiche. Nach dem Fhem reboot finde ich im Log nur eine einzige Zeile von Deinem Modul:
2: After sleep: 57 client devices successfully updated. Update for 0 client devices failed
Wenn ich den rpcserver dann manuell starte, füllt sich mein Log identisch zu Deinem.
CCUNum steht bei mir übrigens auf 0. Und rpcport habe ich auf 2001,9292 gesetzt.
Viele Grüße
Christian
Zitat von: Yil am 13 Dezember 2016, 09:18:11
Stimmt, es muss ja innerhalb Homeatic sein. Ich habe einen Dimmer installiert und in der CCU2 aufgenommen, diesen aber wieder vom Strom genommen, da ich erst einige bauliche Veränderungen vornehmen muss. Seitdem produziert der in der WebGui der CCU2 eine Servicemeldung. Aber das kann es ja nicht sein, oder?
Gibt es in der CCU2 WebGUI Servicemeldungen? Im Zweifel schau Dir mal auf der CCU2 die Datei /var/log/messages an.
Wenn Du Geräte anlernst musst Du sie auch wieder richtig ablernen. Du kannst ja versuchen, den Dimmer nochmal reinzunehmen und wieder raus.
Zitat von: chris1284 am 13 Dezember 2016, 10:06:15
Diejenigen, die Probleme mit dem Start haben, können ja mal die Logs mit ihren vergleichen.
im log steht genau nüscht bis ich den rpc von hand starte. somit wird vermutlich nach initialisieren garnicht versucht den rpc zu starten
Der RPC-Server Start wird durch den FHEM Global Event "Initialiazation complete" oder so ähnlich getriggert.
Das Problem liegt also anscheinend beim Autostart, während der manuelle Start funktioniert. Muss ich heute Abend mal genauer analysieren.
Fehler für Autostart RPC Server gefunden. Update gibt es heute abend
Habe gerade ein Update für 88_HMCCU.pm eingecheckt. Damit wird der Fehler beim Autostart des RPC-Servers behoben.
@cho: Der "if" Parameter bei Aggregationsregeln akzeptiert nun bei "all" und "any" reguläre Ausdrücke. Für Deine Fenster könnte das "if" so aussehen:
if:any=(offen|gekippt)
Sollte funktionieren. Natürlich musst Du offen und gekippt durch die tatsächlichen Reading Werte ersetzen.
Hallo zap
komme leider erst heute dazu deine Hilfe zu befolgen
Internals:
CCUNum 0
Clients :HMCCUDEV:HMCCUCHN:
DEF 192.168.1.92
DelDevices 0
DevCount -1
NAME CCU2
NR 2256
NTFY_ORDER 50-CCU2
NewDevices 0
RPCState stopped
STATE Initialized
TYPE HMCCU
ccutype CCU2
host 192.168.1.92
version 3.6
Readings:
2016-12-13 19:48:38 rpcstate stopped
2016-12-13 19:48:38 state Initialized
Hmccu:
evtime 0
evtimeout 0
rpccount 0
updatetime 0
Attributes:
room Flur_oben
rpcinterval 5
rpcport 2001,9292
rpcqueue /tmp/ccuqueue
rpcserver on
stateFormat rpcstate/state
anbei ein "list CCU2" vor dem "set CCU2 rpserver on"
danach erscheint in den readings
rpcstate stopped + Datum und zeit
state Error + Datum und zeit
vielleicht hilft das weiter, denn ich habe auch nach dem heutigen update wieder diese fehlermeldung und keine Idee, wo ich ansetzten soll
gruss tagedieb
Du hast sonst keinerlei Meldungen im FHEM Log?
Falls nicht, setze mal das Attribut verbose auf 2.
Hallo zap
dankeschön für deine Hilfe
im log steht nur2016.12.13 20:42:03 1: HMCCU: Can't connect to CCU port2001
2016.12.13 20:42:03 1: HMCCU: CCU2 Start of RPC server failed
viele Grüsse tagedieb
Also Deine CCU hat die IP-Adresse 192.168.1.92, korrekt? Wenn Du vom FHEM Server aus ein ping auf diese Adresse absetzt, funktioniert das? Das müsste so ähnlich aussehen:
macbook:~ zap$ ping 192.168.1.11
PING 192.168.1.11 (192.168.1.11): 56 data bytes
64 bytes from 192.168.1.11: icmp_seq=0 ttl=64 time=4.049 ms
64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=2.454 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=3.779 ms
Jetzt geht es ans eingemachte. Falls Du mit den folgenden Schritten nichts anfangen kannst, starte einfach mal die CCU neu und versuche nochmal, den RPC-Server zu starten.
1. Per SSH auf der CCU anmelden
2. Befehl eingeben: fuser 2001/tcp
3. Befehl in 2. sollte eine Zahl ausgeben, wenn nicht => CCU neu starten
4. Befehl eingeben: ps -ef | grep Zahl_aus_Punkt2
5. Befehl in 4. sollte eine Zeile ausgeben, die "rfd" enthält.
Beispiel (bei mir):
# fuser 2001/tcp
355
# ps -ef | grep 355
355 root /bin/rfd -f /etc/config/rfd.conf -l 5
2879 root grep 355
#
Die Fehlermeldung "Can't connect to ..." deutet darauf hin, dass der rfd Prozess auf der CCU nicht mehr läuft.
Hallo zap
danke für deine Hilfehinweise
ZitatAlso Deine CCU hat die IP-Adresse 192.168.1.92, korrekt? Wenn Du vom FHEM Server aus ein ping auf diese Adresse absetzt, funktioniert das? Das müsste so ähnlich aussehen:
korrekt
und nach einem Neustart der CCu funktioniert auch der Start des rpc servers wieder :)
Dankeschön
gruss tagedieb
Habe heute ein Update gemacht.
Nach einem Shutdown restart, hat sich der RPC auch nicht von selbst gestartet. Das funktionierte vor einigen Tagen vor den letzten zwei Upates noch.
Deine Anleitung im Thread 989 mit den Abfragen auf der CCU sehen aus wie bei dir.
Meine CCUNum ist 0.
CCU selbst wurde auch neu gestartet.
list der CCU:
Internals:
Internals:
CCUNum 0
Clients :HMCCUDEV:HMCCUCHN:
DEF 10.0.0.82
DelDevices 0
DevCount 149
NAME CCU2
NR 857
NTFY_ORDER 50-CCU2
NewDevices 0
RPCState stopped
STATE Initialized
TYPE HMCCU
ccutype CCU2
host 10.0.0.82
version 3.6
Readings:
2016-11-21 16:31:04 Anwesenheit true
2016-12-14 07:47:45 rpcstate stopped
2016-12-14 07:47:45 state Initialized
Hmccu:
evtime 0
evtimeout 0
rpccount 0
updatetime 0
Adr:
Bz-og-fk:
address LEQ0566054
addtype dev
valid 1
Attributes:
ccureadings 0
devStateIcon (running/OK):10px-kreis-gruen Error:10px-kreis-rot
event-on-change-reading .*
icon hm_ccu
room HM_CCU2
rpcinterval 2
rpcport 2001,2010,9292
rpcserver on
stateFormat rpcstate/state
So ging's mir heut früh nach dem Update auch - der RPC-Server stand. Ich habe ihn dann manuell gestartet, das ging.
Hallo zap,
bei mir funktioniert der automatische Start nach dem Update von heute wieder.
Viele Grüße
Christian
Zitat von: cho am 14 Dezember 2016, 10:59:19
Hallo zap,
bei mir funktioniert der automatische Start nach dem Update von heute wieder.
Viele Grüße
Christian
Probiere mal die Aggregationsregeln mit dem erweiterten if aus, ob das mit der RegEx funktioniert.
@all: der Grund für den ausbleibenden RPc Server Start war simpel. Ich hatte beim Attribut rpcserver on und off vertauscht. Wenn es trotzdem nicht geht, hat das andere Gründe. Bitte Log beachten und Fehlermeldungen hier posten.
Hi zap,
zur Info:
gleiches Problem hier: nach Neustart bleibt HMCCU stehen.
Gestern Abend habe ich noch ein Update auf die neue Version gemacht, leider hat das nichts geändert. Ein manuelles Starten funktioniert. Fehlermeldungen im Log kann ich nicht erkennen.
Tom
Habe jetzt gerade wieder einen Update Check gemacht und auf einmal war die 88_HMCCU.pm wieder da als Update.
Nach dem jetzigen Update funktioniert der Autostart auch wieder.
Um welche Uhrzeit werden den die neuen Updates im (Update check) geändert?
Möglich das ich mir um 7:30 noch die alten Dateien gezogen haben?
LG Thomas
Ah, seltsam/tatsächlich: 88_HMCCU.pm ist wieder da als Update da, Autostart geht!
Dauert wohl immer etwas bis die Updates zur Verfügung stehen.
WICHTIG! Habe gerade ein neues Update für 88_HMCCU.pm eingecheckt. Bitte unbedingt installieren, sobald in FHEM Update verfügbar. Behebt ein Memory Leak im RPC-Server. Führt dazu, dass die RPC-Server Prozesse immer mehr Speicher allokieren.
Hallo!
Ich möchte eine HM-OU-LED16 Funk-Statusanzeige einbinden.
Im Thread ist zwar eine Definition von Loredo drin mit der ich die LED Stati übertragen kann,
ich kann aber leider damit keine LEDs von fhem per HMCCUDEV aus schalten.
Hat jemand dieses Problem schon gelöst?
Gruß
Sven
Poste mal bitte die Ausgabe von "get deviceinfo" sowie ein list des Devices.
Hallo!
Hier die Daten,
Gruss
Sven
Listing:
Internals
CHANGED
DEF HM-OU-LED16_Flur
IODev hm_ccu
NAME HM_OU_LED16_Flur
NR 671
STATE Initialized
TYPE HMCCUDEV
ccuaddr JEQ0699082
ccudevstate Active
ccuif BidCos-RF
ccuname HM-OU-LED16_Flur
ccutype HM-OU-LED16
channels 17
statevals devstate
Readings
HM-OU-LED16_Flur.0.UNREACH false 2016-12-14 23:31:14
HM-OU-LED16_Flur.1.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.10.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.11.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.12.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.13.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.14.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.15.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.16.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.2.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.3.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.4.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.5.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.6.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.7.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.8.LED_STATUS off 2016-12-14 23:31:14
HM-OU-LED16_Flur.9.LED_STATUS off 2016-12-14 23:31:14
state Initialized 2016-12-14 22:58:46
Attributes
IODev hm_ccu
ccureadingfilter (LED_STATUS|^UNREACH)
event-on-change-reading state
eventMap /datapoint LED_STATUS:led1/datapoint 2.LED_STATUS:led2/datapoint 3.LED_STATUS:led3/datapoint 4.LED_STATUS:led4/datapoint 5.LED_STATUS:led5/datapoint 6.LED_STATUS:led6/datapoint 7.LED_STATUS:led7/datapoint 8.LED_STATUS:led8/datapoint 9.LED_STATUS:led9/datapoint 10.LED_STATUS:led10/datapoint 11.LED_STATUS:led11/datapoint 12.LED_STATUS:led12/datapoint 13.LED_STATUS:led13/datapoint 14.LED_STATUS:led14/datapoint 15.LED_STATUS:led15/datapoint 16.LED_STATUS:led16/
room Homematic
substitute LED_STATUS!(0|false):off,(1|true):red,2:green,3:orange
get deviceinfo
CHN JEQ0699082:0 HM-OU-LED16_Flur:0
DPT {b} BidCos-RF.JEQ0699082:0.UNREACH = false [RE]
DPT {b} BidCos-RF.JEQ0699082:0.STICKY_UNREACH = false [RWE]
DPT {b} BidCos-RF.JEQ0699082:0.CONFIG_PENDING = false [RE]
DPT {n} BidCos-RF.JEQ0699082:0.RSSI_DEVICE = 1 [RE]
DPT {n} BidCos-RF.JEQ0699082:0.RSSI_PEER = 226 [RE]
DPT {n} BidCos-RF.JEQ0699082:0.LED_STATUS = [W]
DPT {b} BidCos-RF.JEQ0699082:0.DEVICE_IN_BOOTLOADER = false [RE]
DPT {b} BidCos-RF.JEQ0699082:0.UPDATE_PENDING = false [RE]
DPT {n} BidCos-RF.JEQ0699082:0.AES_KEY = 1 [R]
CHN JEQ0699082:1 HM-OU-LED16_Flur:1
DPT {b} BidCos-RF.JEQ0699082:1.PRESS_SHORT = false [WE]
DPT {i} BidCos-RF.JEQ0699082:1.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:1.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:1.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:1.INSTALL_TEST = [WE]
CHN JEQ0699082:2 HM-OU-LED16_Flur:2
DPT {b} BidCos-RF.JEQ0699082:2.PRESS_SHORT = false [WE]
DPT {i} BidCos-RF.JEQ0699082:2.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:2.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:2.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:2.INSTALL_TEST = [WE]
CHN JEQ0699082:3 HM-OU-LED16_Flur:3
DPT {b} BidCos-RF.JEQ0699082:3.PRESS_SHORT = [WE]
DPT {i} BidCos-RF.JEQ0699082:3.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:3.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:3.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:3.INSTALL_TEST = [WE]
CHN JEQ0699082:4 HM-OU-LED16_Flur:4
DPT {b} BidCos-RF.JEQ0699082:4.PRESS_SHORT = [WE]
DPT {i} BidCos-RF.JEQ0699082:4.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:4.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:4.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:4.INSTALL_TEST = [WE]
CHN JEQ0699082:5 HM-OU-LED16_Flur:5
DPT {b} BidCos-RF.JEQ0699082:5.PRESS_SHORT = [WE]
DPT {i} BidCos-RF.JEQ0699082:5.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:5.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:5.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:5.INSTALL_TEST = [WE]
CHN JEQ0699082:6 HM-OU-LED16_Flur:6
DPT {b} BidCos-RF.JEQ0699082:6.PRESS_SHORT = [WE]
DPT {i} BidCos-RF.JEQ0699082:6.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:6.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:6.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:6.INSTALL_TEST = [WE]
CHN JEQ0699082:7 HM-OU-LED16_Flur:7
DPT {b} BidCos-RF.JEQ0699082:7.PRESS_SHORT = [WE]
DPT {i} BidCos-RF.JEQ0699082:7.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:7.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:7.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:7.INSTALL_TEST = [WE]
CHN JEQ0699082:8 HM-OU-LED16_Flur:8
DPT {b} BidCos-RF.JEQ0699082:8.PRESS_SHORT = [WE]
DPT {i} BidCos-RF.JEQ0699082:8.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:8.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:8.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:8.INSTALL_TEST = [WE]
CHN JEQ0699082:9 HM-OU-LED16_Flur:9
DPT {b} BidCos-RF.JEQ0699082:9.PRESS_SHORT = [WE]
DPT {i} BidCos-RF.JEQ0699082:9.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:9.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:9.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:9.INSTALL_TEST = [WE]
CHN JEQ0699082:10 HM-OU-LED16_Flur:10
DPT {b} BidCos-RF.JEQ0699082:10.PRESS_SHORT = [WE]
DPT {i} BidCos-RF.JEQ0699082:10.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:10.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:10.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:10.INSTALL_TEST = [WE]
CHN JEQ0699082:11 HM-OU-LED16_Flur:11
DPT {b} BidCos-RF.JEQ0699082:11.PRESS_SHORT = [WE]
DPT {i} BidCos-RF.JEQ0699082:11.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:11.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:11.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:11.INSTALL_TEST = [WE]
CHN JEQ0699082:12 HM-OU-LED16_Flur:12
DPT {b} BidCos-RF.JEQ0699082:12.PRESS_SHORT = [WE]
DPT {i} BidCos-RF.JEQ0699082:12.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:12.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:12.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:12.INSTALL_TEST = [WE]
CHN JEQ0699082:13 HM-OU-LED16_Flur:13
DPT {b} BidCos-RF.JEQ0699082:13.PRESS_SHORT = [WE]
DPT {i} BidCos-RF.JEQ0699082:13.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:13.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:13.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:13.INSTALL_TEST = [WE]
CHN JEQ0699082:14 HM-OU-LED16_Flur:14
DPT {b} BidCos-RF.JEQ0699082:14.PRESS_SHORT = [WE]
DPT {i} BidCos-RF.JEQ0699082:14.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:14.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:14.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:14.INSTALL_TEST = [WE]
CHN JEQ0699082:15 HM-OU-LED16_Flur:15
DPT {b} BidCos-RF.JEQ0699082:15.PRESS_SHORT = [WE]
DPT {i} BidCos-RF.JEQ0699082:15.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:15.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:15.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:15.INSTALL_TEST = [WE]
CHN JEQ0699082:16 HM-OU-LED16_Flur:16
DPT {b} BidCos-RF.JEQ0699082:16.PRESS_SHORT = false [WE]
DPT {i} BidCos-RF.JEQ0699082:16.LED_STATUS = 0 [RWE]
DPT {s} BidCos-RF.JEQ0699082:16.ALL_LEDS = [W]
DPT {i} BidCos-RF.JEQ0699082:16.LED_SLEEP_MODE = [W]
DPT {b} BidCos-RF.JEQ0699082:16.INSTALL_TEST = [WE]
Hallo und guten morgen
ich habe zwar schon sehr viel über HMCCU und ccu2 hier im Forum gefunden, doch für eine Frage habe ich keine Antwort gefunden und würde mich über Hilfe freuen
Ich habe FHEM mit Homematic aktoren über HMLAN integriert, und mittlerweile auch eine CCu2 im System - hier sind jedoch nur die IP Homematic aktoren verbunden und werden so auch über FHEM nutzbar, Danke hier an alle, für die tollen Module und Erklärungen
ich habe gelesen, das ich mit der ccu2 auch über FHEM Firmwareupdates durchführen kann, wenn alles HMLAN`s deaktiviert sind - jetzt meine Frage - muss ich dann alle zu updatende Homematicaktoren zum update mit der ccu pairen ?
Über eine helfende Antwort würde ich mich freuen
ich wünsche allen einen schönen Tag
gruss tagedieb
Zitat von: tagedieb am 16 Dezember 2016, 06:35:10
ich habe gelesen, das ich mit der ccu2 auch über FHEM Firmwareupdates durchführen kann, wenn alles HMLAN`s deaktiviert sind - jetzt meine Frage - muss ich dann alle zu updatende Homematicaktoren zum update mit der ccu pairen ?
Über eine helfende Antwort würde ich mich freuen
HMCCU unterstützt keine Firmware Updates. Die CCU selbst kann nur Firmware Updates für Geräte durchführen, die sie kennt, d.h. die angelernt sind.
Zitat von: zentis666 am 15 Dezember 2016, 12:45:08
eventMap /datapoint LED_STATUS:led1/datapoint 2.LED_STATUS:led2/datapoint 3.LED_STATUS:led3/datapoint 4.LED_STATUS:led4/datapoint 5.LED_STATUS:led5/datapoint 6.LED_STATUS:led6/datapoint 7.LED_STATUS:led7/datapoint 8.LED_STATUS:led8/datapoint 9.LED_STATUS:led9/datapoint 10.LED_STATUS:led10/datapoint 11.LED_STATUS:led11/datapoint 12.LED_STATUS:led12/datapoint 13.LED_STATUS:led13/datapoint 14.LED_STATUS:led14/datapoint 15.LED_STATUS:led15/datapoint 16.LED_STATUS:led16/
room Homematic
substitute LED_STATUS!(0|false):off,(1|true):red,2:green,3:orange
Im ersten eventMap Eintrag fehlt die "1." vor dem LED_STATUS. Prüfe mal, ob Du mit einem der folgenden Befehle einer der LEDs einschalten kannst.
set HM-OU-LED16_Flur datapoint 1.LED_STATUS true
set HM-OU-LED16_Flur datapoint 1.LED_STATUS 1
set HM-OU-LED16_Flur datapoint 2.LED_STATUS true
set HM-OU-LED16_Flur datapoint 2.LED_STATUS 1
Hallo,
ich experimentiere gerade bei HMCCU mit dem Exportieren und Importieren der Attribute, da ich diese bei mir anders standardisieren möchte (Ich habe smartVisu und damit andere Widgets und möchte auch den Sabotagekontakt am HM-SEC-SCo noch einbeziehen).
Ich habe die Defaultliste exportiert, mit file edit auf der FHEM Weboberfläche bearbeitet, wieder importiert und funktioniert soweit. Das File habe ich unter dem Verzeichnis /FHEM abgelegt und mit der Dateiendung .layout versehen, dass ich es komfortabel auf der Weboberfläche mit file edit bearbeiten kann.
Meine "custom Defaults" werden allerdings nur übernommen, wenn ich das Device lösche und neu createn lasse. Ist das so angedacht um die vergebenen Attribute vor versehentlichen überschreiben zu schützen? Es wäre praktisch wenn man nachträglich die Attribute per Default ändern könnte (z.B. wenn man grundsätzlich eine andere Darstellung haben möchte).
Ansonsten bin ich von diesem System begeistert da ich es für das beste bezüglich HM-Komponenten Verfügbarkeit halte (immer kompatibel zu FHEM da CCU als Schnittstelle, die von eq3 unterstützt wird)
Gruß
Spielmann
Hallo zap
danke für die Rückinfo
Gruss tagedieb
Zitat von: Spielmann am 16 Dezember 2016, 10:11:13
Meine "custom Defaults" werden allerdings nur übernommen, wenn ich das Device lösche und neu createn lasse. Ist das so angedacht um die vergebenen Attribute vor versehentlichen überschreiben zu schützen? Es wäre praktisch wenn man nachträglich die Attribute per Default ändern könnte (z.B. wenn man grundsätzlich eine andere Darstellung haben möchte).
Beim Import der Custom Defaults werden nicht automatisch die Attribute der vorhandenen Devices neu gesetzt bzw. überschrieben. Dazu musst Du für jedes Device den Befehl "set xyz defaults" ausführen.
Glücklicherweise ermöglicht FHEM ja die Ausführung eines set Befehls für mehrere Devices "in einem Rutsch". Ich könnte dem Import Befehl aber auch noch eine Option verpassen, mit der für alle vorhandenen Geräte die Attribute überschrieben werden.
Hallo zap,
dass die Attribute ganz automatisch unkontrolliert überschrieben werden, sobald die Liste importiert wird würde ich auch nicht wollen. Ich habe nur mit den Befehlen in der set / get drop-down-Liste gespielt und da hat der "defaults" nichts aus der custom Liste geholt. Mir würde es schon reichen wenn ich im Device per Auswahlliste die Attribute aktualisieren könnte. Den Befehl in die Eingabezeile eingeben geht natürlich auch. Wenn ich das jetzt richtig verstehe, dann holt der Befehl set <Name> defaults in der Auswahlliste im Device die ursprünglichen defaults und in der Eingabezeile die "custom defaults". Ich werde das heute Abend mal testen.
Gruß
Spielmann
Nein, zumindest ist das so nicht gewollt. Set defaults soll immer erst in der Custom Liste nachschauen. Erst wenn da kein passender Eintrag existiert, soll Default verwendet werden. Muss ich mir anschauen, möglicherweise ein Bug.
Hi zap,
vielen Dank, funktioniert!
Zitat von: zap am 16 Dezember 2016, 10:08:23
Prüfe mal, ob Du mit einem der folgenden Befehle einer der LEDs einschalten kannst.
set HM-OU-LED16_Flur datapoint 1.LED_STATUS 1
--> 1. LED rot
set HM_OU_LED16_Flur datapoint 1.LED_STATUS 2
--> 1. LED grün
set HM_OU_LED16_Flur datapoint 1.LED_STATUS 3
--> 1. LED gelb
set HM-OU-LED16_Flur datapoint 2.LED_STATUS 1
--> 2. LED rot
Muss ich nur noch die 3 Stati auf die Farben mappen.
Gruß
Sven
Hallo zap,
inzwischen habe ich etwas herausgefunden. Ich habe die Devices HM-Sec-SC und HM-Sec-SCo getrennt in der Liste aufgeführt, da ich nur die HM-Sec-SCo besitze und den magnetischen Fensterkontakt nicht kenne.
Wenn ich:
device:HM-Sec-SC
_description=Tuer/Fensterkontakt magnetisch
ccureadingfilter=(^UNREACH|LOWBAT|LOW_BAT|STATE)
statedatapoint=1.STATE
substitute=STATE!(0|false):closed,(1|true):open;UNREACH,LOWBAT,LOW_BAT!(0|false):no,(1|true):yes
device:HM-Sec-SCo
_description=Tuer/Fensterkontakt optisch
ccureadingfilter=(^UNREACH|LOWBAT|ERROR|STATE)
statedatapoint=1.STATE
substitute=STATE!(0|false):closed,(1|true):open;UNREACH,LOWBAT!(0|false):no,(1|true):yes;ERROR!(7):sabotage,(0|false):ok
in die Liste eintrage, werden für meinem HM-Sec-SCo die defaults von HM-Sec-SC übernommen. Nachdem ich den HM-Sec-SCo in der Liste vorangestellt habe
device:HM-Sec-SCo
_description=Tuer/Fensterkontakt optisch
ccureadingfilter=(^UNREACH|LOWBAT|ERROR|STATE)
statedatapoint=1.STATE
substitute=STATE!(0|false):closed,(1|true):open;UNREACH,LOWBAT!(0|false):no,(1|true):yes;ERROR!(7):sabotage,(0|false):ok
device:HM-Sec-SC
_description=Tuer/Fensterkontakt magnetisch
ccureadingfilter=(^UNREACH|LOWBAT|LOW_BAT|STATE)
statedatapoint=1.STATE
substitute=STATE!(0|false):closed,(1|true):open;UNREACH,LOWBAT,LOW_BAT!(0|false):no,(1|true):yes
klappts. Anscheinend stimmt etwas mit dem Devicenamen nicht. Wie sich das mit den Channels verhält habe ich nicht getestet, da ich HMCCUCHN wegen der Übersichtlichkeit nicht nutze .
Gruß
Spielmann
Danke, Du hast den Bug gefunden! Der Devicetype ist ein regulärer Ausdruck. Da in Deinem Fall der eine Typ im anderen enthalten ist, matched der kürzere zuerst.
Zitat von: Spielmann am 17 Dezember 2016, 00:08:28
in die Liste eintrage, werden für meinem HM-Sec-SCo die defaults von HM-Sec-SC übernommen. Nachdem ich den HM-Sec-SCo in der Liste vorangestellt habe
device:HM-Sec-SCo
_description=Tuer/Fensterkontakt optisch
ccureadingfilter=(^UNREACH|LOWBAT|ERROR|STATE)
statedatapoint=1.STATE
substitute=STATE!(0|false):closed,(1|true):open;UNREACH,LOWBAT!(0|false):no,(1|true):yes;ERROR!(7):sabotage,(0|false):ok
device:HM-Sec-SC
_description=Tuer/Fensterkontakt magnetisch
ccureadingfilter=(^UNREACH|LOWBAT|LOW_BAT|STATE)
statedatapoint=1.STATE
substitute=STATE!(0|false):closed,(1|true):open;UNREACH,LOWBAT,LOW_BAT!(0|false):no,(1|true):yes
klappts. Anscheinend stimmt etwas mit dem Devicenamen nicht. Wie sich das mit den Channels verhält habe ich nicht getestet, da ich HMCCUCHN wegen der Übersichtlichkeit nicht nutze .
Gruß
Spielmann
Ich muss mich korrigieren. Es ist kein Bug sondern so gewollt. Die Angaben hinter "device" und "channel" sind reguläre Ausdrücke. Du hast mehrere Möglichkeiten:
1. Du lässt den nicht benötigten Gerätetyp weg
2. Du drehst die Reihenfolge um, wie Du es schon gemacht hast
3. Du belässt es bei HM-Sec-SCo|HM-Sec-SC
Leider wollen nun meine 3 wired IO-Module überhaupt nicht mehr (Ich hatte eine längere Zeit kein FHEM-Update). Zum Ergründen hab ich mir nen extra-Raspi gegönnt. und das Fhem neu aufgesetzt und nur die HMCCU angedockt. (alle Updates auf Stand heute)
defmod HMCCU2 HMCCU 192.168.yyy.xxx
attr HMCCU2 room HM,Unsorted
attr HMCCU2 rpcport 2000,2001
attr HMCCU2 rpcserver on
attr HMCCU2 stateFormat rpcstate/state
setstate HMCCU2 running/OK
setstate HMCCU2 2016-12-18 15:56:43 rpcstate running
setstate HMCCU2 2016-12-18 19:08:12 state OK
Dann einen der HMW-IO-12-Sw7-DR erkennen lassen
get HMCCU2 devicelist create 7-2
ergibt folgendes defmod 7_2 HMCCUDEV MEQ02789xx
attr 7_2 IODev HMCCU2
Danach versucht mir die get 7_2 deviceinfo anzeigen zu lassen, das liefert:
HMCCUDEV: 7_2 Execution of CCU script or command failed
Andere Versuche, die "früher" gingen, liefern "Invalid datapoint"
Ein Versuch mit nem HM-Funkschalter HM-ES-PMSw1-Pl funktioniert problemlos!
Also das Device heißt in der CCU 7-2? Das ist wirklich das Device und kein Kanal?
Versuche mal ein
get HMCCU2 deviceinfo 7-2
Hier musst Du den Namen in der CCU angeben. Ich habe hier angenommen, dass der 7-2 ist.
Zitatzap:
Ich muss mich korrigieren. Es ist kein Bug sondern so gewollt. Die Angaben hinter "device" und "channel" sind reguläre Ausdrücke. Du hast mehrere Möglichkeiten:
1. Du lässt den nicht benötigten Gerätetyp weg
2. Du drehst die Reihenfolge um, wie Du es schon gemacht hast
3. Du belässt es bei HM-Sec-SCo|HM-Sec-SC
Ich lasse das einfach mal so stehen. Ich weis ja inzwischen wo ich bei solchen Fällen suchen muss und kann jetzt die Zusammenhänge besser verstehen (und vielleicht auch andere). Danke.
Gruß
Spielmann
Hallo zap,
jo heist so
Name: 7-2
Typenbezeichnung: HMW-IO-12-Sw7-DR
Seriennummer: MEQ0278xxx
auf "get HMCCU2 deviceinfo 7-2" antwortet "HMCCU: HMCCU2 Execution of CCU script or command failed"
Ich habs mal auf IO7-2 umgetauft, FHEM neugestartet und es kommt ein brauchbares Ergebnis vom DeviceInfo!
Also sollten die CCU Dev Namen mit nem Buchstaben beginnen - OK.
Danke! & Harzliche Grüße Rainer
Könnte daran liegen, dass HMCCU sowohl Namen als auch Adressen akzeptiert. Ich vermute, dass die Prüfroutine bei 7-2 fälschlicherweise von einer Adresse ausgeht. Ich nehme es mal in die "zu prüfen" Liste auf.
Hab mir grad ne Fernbedienung Typ HM-RC-Dis-H-x-EU gegönnt. Hat die jemand schonmal jemand mit diesem neuen Modul hier angebunden?
Lerne das Gerät an die CCU an. Mach dann in FHEM im HMCCU IO Device:
get devicelist
get deviceinfo Devname_in_CCU
Schau Dir die Ausgabe an. Bei der Fernbedienung gibt es vermutlich sowas wie PRESSED, PRESSED_LONG usw.
Definiere ein HMCCUDEV Device. Setze event-on-update-reading auf .*. Teste, ob Readings beim Tastedrücken angelegt werden.
get deviceinfo (kann keinen Namen dazu angeben):
CHN NEQ0271726:0 Fernbedienung:0
DPT {b} BidCos-RF.NEQ0271726:0.UNREACH = false [RE]
DPT {b} BidCos-RF.NEQ0271726:0.STICKY_UNREACH = false [RWE]
DPT {b} BidCos-RF.NEQ0271726:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.NEQ0271726:0.LOWBAT = false [RE]
DPT {n} BidCos-RF.NEQ0271726:0.RSSI_DEVICE = 1 [RE]
DPT {n} BidCos-RF.NEQ0271726:0.RSSI_PEER = 1 [RE]
DPT {b} BidCos-RF.NEQ0271726:0.DEVICE_IN_BOOTLOADER = false [RE]
DPT {b} BidCos-RF.NEQ0271726:0.UPDATE_PENDING = false [RE]
DPT {n} BidCos-RF.NEQ0271726:0.AES_KEY = 2 [R]
CHN NEQ0271726:1 Fernbedienung1
DPT {b} BidCos-RF.NEQ0271726:1.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:1.PRESS_LONG = false [WE]
DPT {b} BidCos-RF.NEQ0271726:1.INSTALL_TEST = false [E]
DPT {b} BidCos-RF.NEQ0271726:1.PRESS_CONT = false [E]
DPT {b} BidCos-RF.NEQ0271726:1.PRESS_LONG_RELEASE = false [E]
CHN NEQ0271726:2 Fernbedienung2
DPT {b} BidCos-RF.NEQ0271726:2.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:2.PRESS_LONG = false [WE]
DPT {b} BidCos-RF.NEQ0271726:2.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:2.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:2.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:3 Fernbedienung3
DPT {b} BidCos-RF.NEQ0271726:3.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:3.PRESS_LONG = false [WE]
DPT {b} BidCos-RF.NEQ0271726:3.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:3.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:3.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:4 Fernbedienung4
DPT {b} BidCos-RF.NEQ0271726:4.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:4.PRESS_LONG = false [WE]
DPT {b} BidCos-RF.NEQ0271726:4.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:4.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:4.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:5 Fernbedienung5
DPT {b} BidCos-RF.NEQ0271726:5.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:5.PRESS_LONG = false [WE]
DPT {b} BidCos-RF.NEQ0271726:5.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:5.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:5.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:6 Fernbedienung6
DPT {b} BidCos-RF.NEQ0271726:6.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:6.PRESS_LONG = false [WE]
DPT {b} BidCos-RF.NEQ0271726:6.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:6.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:6.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:7 Fernbedienung7
DPT {b} BidCos-RF.NEQ0271726:7.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:7.PRESS_LONG = [WE]
DPT {b} BidCos-RF.NEQ0271726:7.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:7.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:7.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:8 Fernbedienung8
DPT {b} BidCos-RF.NEQ0271726:8.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:8.PRESS_LONG = [WE]
DPT {b} BidCos-RF.NEQ0271726:8.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:8.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:8.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:9 Fernbedienung9
DPT {b} BidCos-RF.NEQ0271726:9.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:9.PRESS_LONG = [WE]
DPT {b} BidCos-RF.NEQ0271726:9.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:9.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:9.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:10 Fernbedienung10
DPT {b} BidCos-RF.NEQ0271726:10.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:10.PRESS_LONG = [WE]
DPT {b} BidCos-RF.NEQ0271726:10.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:10.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:10.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:11 Fernbedienung11
DPT {b} BidCos-RF.NEQ0271726:11.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:11.PRESS_LONG = [WE]
DPT {b} BidCos-RF.NEQ0271726:11.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:11.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:11.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:12 Fernbedienung12
DPT {b} BidCos-RF.NEQ0271726:12.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:12.PRESS_LONG = [WE]
DPT {b} BidCos-RF.NEQ0271726:12.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:12.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:12.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:13 Fernbedienung13
DPT {b} BidCos-RF.NEQ0271726:13.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:13.PRESS_LONG = [WE]
DPT {b} BidCos-RF.NEQ0271726:13.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:13.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:13.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:14 Fernbedienung14
DPT {b} BidCos-RF.NEQ0271726:14.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:14.PRESS_LONG = [WE]
DPT {b} BidCos-RF.NEQ0271726:14.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:14.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:14.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:15 Fernbedienung15
DPT {b} BidCos-RF.NEQ0271726:15.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:15.PRESS_LONG = [WE]
DPT {b} BidCos-RF.NEQ0271726:15.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:15.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:15.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:16 Fernbedienung16
DPT {b} BidCos-RF.NEQ0271726:16.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:16.PRESS_LONG = [WE]
DPT {b} BidCos-RF.NEQ0271726:16.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:16.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:16.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:17 Fernbedienung17
DPT {b} BidCos-RF.NEQ0271726:17.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:17.PRESS_LONG = [WE]
DPT {b} BidCos-RF.NEQ0271726:17.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:17.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:17.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:18 Fernbedienung18
DPT {b} BidCos-RF.NEQ0271726:18.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:18.PRESS_LONG = [WE]
DPT {b} BidCos-RF.NEQ0271726:18.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:18.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:18.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:19 Fernbedienung19
DPT {b} BidCos-RF.NEQ0271726:19.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:19.PRESS_LONG = [WE]
DPT {b} BidCos-RF.NEQ0271726:19.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:19.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:19.PRESS_LONG_RELEASE = [E]
CHN NEQ0271726:20 Fernbedienung20
DPT {b} BidCos-RF.NEQ0271726:20.PRESS_SHORT = false [WE]
DPT {b} BidCos-RF.NEQ0271726:20.PRESS_LONG = [WE]
DPT {b} BidCos-RF.NEQ0271726:20.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0271726:20.PRESS_CONT = [E]
DPT {b} BidCos-RF.NEQ0271726:20.PRESS_LONG_RELEASE = [E]
get devicelist gibt es nicht.
Den Device habe ich definiert. Readings werden wie bei Schaltern anlegt, nachdem ich in der Homematic WebUI alle Schalter manuell einmal betätigt habe.
Internals:
DEF NEQ0271726 1
IODev HMCCU2
NAME HM.FB
NR 1246
STATE Initialized
TYPE HMCCUDEV
ccuaddr NEQ0271726
ccudevstate Active
ccuif BidCos-RF
ccuname Fernbedienung
ccutype HM-RC-Dis-H-x-EU
channels 21
statevals devstate
Readings:
2016-12-20 23:04:56 0.AES_KEY 2
2016-12-20 23:04:56 0.CONFIG_PENDING false
2016-12-20 23:04:56 0.DEVICE_IN_BOOTLOADER false
2016-12-20 23:04:56 0.LOWBAT false
2016-12-20 23:04:56 0.RSSI_DEVICE 1
2016-12-20 23:04:56 0.RSSI_PEER 1
2016-12-20 23:04:56 0.STICKY_UNREACH false
2016-12-20 23:04:56 0.UNREACH false
2016-12-20 23:04:56 0.UPDATE_PENDING false
2016-12-20 20:18:00 1.PRESS_CONT on
2016-12-20 22:59:09 1.PRESS_SHORT on
2016-12-20 20:06:32 10.PRESS_SHORT on
2016-12-20 20:06:34 11.PRESS_SHORT on
2016-12-20 20:06:34 12.PRESS_SHORT on
2016-12-20 20:06:35 13.PRESS_SHORT on
2016-12-20 20:06:35 14.PRESS_SHORT on
2016-12-20 20:06:38 15.PRESS_SHORT on
2016-12-20 20:06:40 16.PRESS_SHORT on
2016-12-20 20:06:40 17.PRESS_SHORT on
2016-12-20 20:06:40 18.PRESS_SHORT on
2016-12-20 20:06:43 19.PRESS_SHORT on
2016-12-20 20:06:20 2.PRESS_SHORT on
2016-12-20 20:06:43 20.PRESS_SHORT on
2016-12-20 20:06:21 3.PRESS_SHORT on
2016-12-20 20:06:24 4.PRESS_SHORT on
2016-12-20 20:06:26 5.PRESS_SHORT on
2016-12-20 20:06:26 6.PRESS_SHORT on
2016-12-20 20:06:29 7.PRESS_SHORT on
2016-12-20 20:06:30 8.PRESS_SHORT on
2016-12-20 20:06:31 9.PRESS_SHORT on
2016-12-20 23:06:23 Fernbedienung.0.AES_KEY 2
2016-12-20 23:06:23 Fernbedienung.0.CONFIG_PENDING false
2016-12-20 23:06:23 Fernbedienung.0.DEVICE_IN_BOOTLOADER false
2016-12-20 23:06:23 Fernbedienung.0.LOWBAT false
2016-12-20 23:06:23 Fernbedienung.0.RSSI_DEVICE 1
2016-12-20 23:06:23 Fernbedienung.0.RSSI_PEER 1
2016-12-20 23:06:23 Fernbedienung.0.STICKY_UNREACH false
2016-12-20 23:06:23 Fernbedienung.0.UNREACH false
2016-12-20 23:06:23 Fernbedienung.0.UPDATE_PENDING false
2016-12-20 16:30:55 state Initialized
Allerdings zeigt die Fernbedienung beharrlich:
------------------
Kein Gerät
angelernt
------------------
Ich würde gerne über FHEM direkt die Zuorndung steuern sowie die Beschriftung der Textzeilen je Kanal.
Allerdings ist mir nicht klar, wie. Readings zu den Textzeilen werden nicht angegeben, die sind lediglich in der Homematic WebUI verfügbar.
Kein Gerät angelernt... ist ja auch richtig, du hast ja nur die zentrale angelernt. du müsstest jetzt noch jeden channel mit einem gerät vernüpfen welches du per fb bedienen willst.
ZitatIch würde gerne über FHEM direkt die Zuorndung steuern
was heisst das für dich, "zuordnung" zu anderen geräten? das machst du in der ccu und nennt sich verknüpfen/peeren. das per hmccu in fhem geht meine ich nicht. das ist ja gerade das schöne, das man fhem für diese aufgabe nicht benötigt sondern peeren bequem und vor allem einfach per ccu macht und in fhem nur steuert. der weg über fhem peeren geht mit cul_hm.
wenn du nicht verknüpfte geräte (oder nicht hm-geräte ) steuern willst musst du den tastendruck per fhem abfangen (notify auf zb HMCCUDEV Fernbedienung.7.PRESS_SHORT:) und dann das gewünschte command abgeben
Ergänzend: Wenn man die "Verknüpfung" (die eigentlich keine ist) in FHEM machen möchte, kann man die Fernbedienungstasten in der CCU auch mit einem Dummy Programm verknüpfen, das gar nichts macht oder z.B. eine Systemvariable setzt. Dann sollte auch diese Meldung aus der Anzeige verschwinden. Die PRESSED-Events werden trotzdem an FHEM geschickt.
Aber ganz ehrlich: Ganz schön umständlich. Macht m.E. nur Sinn, wenn man mit der FB Nicht-Homematic Geräte in FHEM steuern möchte. Ansonsten ist die Verknüpfung direkt in der CCU vorzuziehen.
Zitat von: zap am 21 Dezember 2016, 09:20:50
die "Verknüpfung" (die eigentlich keine ist) .
magst du das näher erleutern?
Zitat von: chris1284 am 21 Dezember 2016, 09:41:09
magst du das näher erleutern?
Ich meine damit: Wenn ich in FHEM eine FB-Taste per Notify mit einer Aktion in einem anderen FHEM Device verknüpfe, ist das nicht dasselbe wie eine direkte (in der CCU) konfigurierte Verknüpfung zwischen der FB-Taste und einem Homematic Aktor. Letzteres läuft eben komplett an FHEM vorbei bzw. man bekommt nur die Statiwechsel von der CCU geliefert.
danke, hatte das auf die ccu verknüpfung bezogen verstanden (das diese eigentlich keine echte verknüpfung sei). Missverständnis erfolgreich aufgelöst ;D
Ok, soweit verstanden.
Ich steuer in FHEM aber recht viel über dummys. Die kann ich natürlich nicht in der CCU verknüpfen. Aber ich probiere das mal aus, wenn ich die Events in FHEM abfange, die Beschriftungs-Texte jedoch in der CCU setze.
Diese Texte kann ich demnach nicht via FHEM setzen? Gleiches analog zu dem Homematic-Bausatz: Funk-Statusanzeige mit E-Paper-Display.
Zitat von: Yil am 21 Dezember 2016, 12:02:35
Diese Texte kann ich demnach nicht via FHEM setzen? Gleiches analog zu dem Homematic-Bausatz: Funk-Statusanzeige mit E-Paper-Display.
Doch kannst Du. Bei Homematic gibt es bei allem was ein Display hat unterschiedliche Verfahren, die Texte zu ändern. Bei manchen Geräten geht es über die Datenpunkte, bei manchen über die Config-Parameter (analog CCU2 Einstellungen > Geräte, Button Einstellen). In besonders "schikanösen" Fällen muss man sogar beides nutzen (beim ePaper Display).
Die Datenpunkte sind dokumentiert (suche mal "Homematic Datenpunkte" bei Google, ist ein PDF). Bei den Config-Parametern würde ich erst mal in der CCU2 unter Einstellungen > Geräte nachschauen, in welchem Kanal die Texte gesetzt werden. Dann definierst Du in FHEM ein Device für Deine Fernbedienung oder Dein Display und führst mal folgenden Befehl aus:
Für das Gerät: get xyz configlist
Für einen Kanal dieses Geräts: get xyz configlist n, wpbei n=Kanalnummer.
Dann bekommst Du eine Liste der Parameter. Ein Parameter kann mit set config param=wert param=wert ... geändert werden.
HMCCU hat spezielle Routinen für das ePaper Display eingebaut, da hier ein speziell formatierter String an das Gerät geschickt werden muss. Das ist in der Online Doku zum Set-Befehl von HMCCUDEV beschrieben.
Danke für Deine ausführliche Antwort. Das Dokument über die Datenpunkte ist ja wirklich sehr aufschlußreich.
Stand aktuell: ich habe die HM-RC-Dis-H-x-EU in FHEM eingebunden, in der HM WebUI die Texte geändert, ein Dummy-Programm je Taste hinterlegt (setzt wie oben vorgeschlagen eine neu erschaffene Systemevariable) und in FHEM notifys definiert, die den Tastendruck abfangen. Funktioniert sehr gut, auch und natürlich mit dem Setzen von dummys - so war's gewollt. ;D
Deine Anleitung, über FHEM die Texte zu ändern, habe ich noch nicht komplett umsetzen können. Wenn ich mit
set config param=wert param=wert ...
arbeite, wie gebe ich dann die jeweilige Kanalnummer mit, um die es geht - die Bezeichner für den Text sind ja in jedem Kanal gleich?
Ausgehend von Deinem Screenshot:
set HM.FB config 1 TEXT1=Test TEXT2=xyz
Wenn ich mich recht erinnere, solltest Du für Leerzeichen \_ angeben können:
set HM.FB config 1 TEXT1=Hallo\_Welt TEXT2=xyz
Prima und danke. Dachte ich mir fast schon, dass man die Kanalnummer als ersten Parameter mitgibt. Die Fernbedienung zeigt diese Werte allerdings erst an, wenn man dort den Konfigurationsmodus einmal laufen lässt - das ist natürlich nicht so nett. Gibt es da einen workaround?
Möglicherweise gibt es noch andere Parameter. Versuche mal ein
get HM.FB configlist
ohne Kanalnummer.
Ich richte gerade wieder eine komplett neue CCU2 in FHEM ein.
Es ist leider noch immer ein enormer Schmerz sich jetzt Tage mit der richtigen Definition in HMCCU Style für mehrere Duzend Geräte beschäftigen zu müssen.
FHEM Standards werden noch immer ignoriert (keine Readings mit dem Namen pct, level, desired-temp und so weiter...), man braucht für alles Sonderfälle und userReadings, um es richtig hinzubiegen. Das braucht Ewigkeiten und ist umständlich. Templates für die einfachsten Geräte sind noch immer nicht enthalten, obwohl ich diese schon einmal Copy&Paste fähig bereitgestellt hatte.
Ich bin frustriert. Mal wieder. Narf.
Als ich hier zuletzt las hieß es, es würde an alles gedacht. Es wurde wohl auch viel geändert, aber ich erkenne keinen Fortschritt in irgendeiner Richtung.
Offenbar noch mehr teils eher nutzlose Attribute, deren Namen nichts sagend oder inkonsistent sind. Flexibilität hin oder her, ist ja alles schön und gut. Aber soll man das auch benutzen können?
da es auch bei dutzenden geräten nicht so viele unterschiedliche typen gibt kann ich mir ganricht vorstellen "sich jetzt Tage mit der richtigen Definition in HMCCU Style für mehrere Duzend Geräte beschäftigen zu müssen". zumal ja laut deiner aussage alles vorhanden ist da du die definitionen "schon einmal Copy&Paste fähig bereitgestellt" hattest.
ZitatFHEM Standards werden noch immer ignoriert
das wird meine ich auch nicht kommen
jammern auf hohrm niveau.... ::)
Zitat von: Loredo am 25 Dezember 2016, 23:13:44
FHEM Standards werden noch immer ignoriert (keine Readings mit dem Namen pct, level, desired-temp und so weiter...), man braucht für alles Sonderfälle und userReadings, um es richtig hinzubiegen.
Es gibt keine FHEM Standards. Vielleicht CUL_HM "Standards". Um diese in HMCCU umzusetzen, müsste ich den generischen Ansatz komplett über Bord werfen und wie in CUL_HM in einer schier endlosen IF-THEN Orgie alle Gerätetypen als Einzelfälle betrachten. Das wird nicht passieren. Dann musst Du eben CUL_HM benutzen. Mit dem Attribut ccureadingname gibt es die Möglichkeit, einzelne Readings umzubenennen (z.B. 1.LEVEL:pct,0.LOWBAT:battery).
Zitat
Das braucht Ewigkeiten und ist umständlich.
Was bitte schön ist einfach bei FHEM. FHEM ist mächtig und flexibel, aber sicher nicht "einfach" bzw. benutzerfreundlich.
Zitat
Templates für die einfachsten Geräte sind noch immer nicht enthalten, obwohl ich diese schon einmal Copy&Paste fähig bereitgestellt hatte.
Deine sehr komplexen und umfangreichen Attribut-Templates konnte ich nicht 1:1 übernehmen, da sie sicher nicht den Geschmack jedes Nutzers getroffen hätten. Einige Attribute habe ich jedoch übernommen. Seit einiger Zeit gibt es die Möglichkeit, eigene Attribut-Templates in einer Config-Datei anzugeben. Darüber könntest Du Deine eigenen Templates relativ einfach definieren.
Zitat
Offenbar noch mehr teils eher nutzlose Attribute, deren Namen nichts sagend oder inkonsistent sind. Flexibilität hin oder her, ist ja alles schön und gut. Aber soll man das auch benutzen können?
Im Vergleich zu anderen Modulen liegt HMCCU was die Anzahl der Attribute angeht eher im unteren Mittelfeld. Da gibt es viel "schlimmere".
Zitat von: zap am 26 Dezember 2016, 12:09:06
Es gibt keine FHEM Standards. Vielleicht CUL_HM "Standards".
Das kannst du so lange wiederholen, wie du möchtest, aber: Es gibt sie.
CUL_HM mag diese einmal initial forciert haben, dennoch setzen eine ganze Menge an Modulen und Funktionen darauf, dass bestimmte Readings die Namen "pct" oder "level" tragen. Da wären beispielsweise außerdem homebridge-fhem, HUEBridge/HUEDevice, Alarm, PHTV, HP1000, Wunderground. Viele Frontends setzen darauf, dass die Readings so heißen. Aktuell muss man peinlich genau darauf achten, welchen Gerätetyp man gerade vor sich hat um das richtige Reading zu verwenden. Bei dem einen heißt es so, bei dem anderen wieder anders... Für die Verwendung in einer structure muss man erstmal umständlich Mappings definieren, damit man HMCCU Geräte mit anderen Geräten wie z.B. CUL_HM und HUE mixen kann. Martin und André haben hier beide eine große Nutzerschaft bei den Modulen und setzen somit einfach einen Standard - Punkt.
Zitat von: zap am 26 Dezember 2016, 12:09:06
Um diese in HMCCU umzusetzen, müsste ich den generischen Ansatz komplett über Bord werfen
Das ist schlichtweg nicht wahr und das habe ich auch nicht gefordert. Es lässt sich prima beides miteinander vereinen. Es geht mir darum, dass mir das Modul dabei hilft bessere Qualität in weniger Zeit bei der Definition der HMCCU Devices zu erhalten. Die Möglichkeiten sind ja wie gesagt da, aber man muss sich für jedes neue Gerät wieder und wieder durch einen Berg von Attributen und deren komplexen Möglichkeiten wühlen. Es ist toll, dass man das machen kann - wer das braucht soll es auch tun können.
Ich habe schon erklärt, dass man die LEVEL Werte in HMCCU IMHO _immer_ als pct und level interpretieren kann. Du hast nun zwar halbherzig/halbfertig Setter dafür eingebaut, das ist aber eben nur die halbe Miete und für sich allein genommen nutzlos bzw. erspart es nicht wieder und wieder für jedes einzelne HMCCU Gerät die gleichen userReadings anlegen zu müssen.
Zitat von: zap am 26 Dezember 2016, 12:09:06
Mit dem Attribut ccureadingname gibt es die Möglichkeit, einzelne Readings umzubenennen (z.B. 1.LEVEL:pct,0.LOWBAT:battery)
Prima. Warum wird das Attribut nicht bei den Defaults direkt so für alle in Frage kommenden Readings gesetzt, dass diese FHEM Standard Readings entsprechend so benannt werden? Ich finde es auch nicht verwerflich die Readings doppelt zu führen, man kann die Events ja entsprechend einschränken. Es braucht nicht ein "entweder/oder", sondern ein "sowohl als auch".
Zitat von: zap am 26 Dezember 2016, 12:09:06
Was bitte schön ist einfach bei FHEM. FHEM ist mächtig und flexibel, aber sicher nicht "einfach" bzw. benutzerfreundlich.
Das ist jedoch kein Grund, dass jedes Modul sein eigenes Ökosystem baut und sich nicht rechts und links umschaut, um sich möglichst einfach in FHEM einzufügen.
Ich will sicherlich HMCCU vollumfänglich beeinflussen _können_, wenn ich weiß warum ich das will. Dazu gehört aber nicht, dass ich das Modul erstmal so richtig hinbiegen _muss_, dass es sich an de facto Standards hält. Zumal ich das für jedes einzelne Device machen muss und bei Änderungen darf ich dann wieder duzende Geräte von Hand anfassen. Das ist langwierig und fehlerträchtig. Ein Computer ist dafür da mir solche Arbeit abzunehmen und Fehler zu ersparen.
IMHO ist FHEM dafür da unterschiedliche Hersteller und Technologien zusammenzuführen und schließlich gemeinsam in ähnlicher Art und Weise zu handhaben. Dazu gehört selbstverständlich, dass man versucht die gleichen Werte von unterschiedlichen Geräten verschiedener Hersteller vergleichbar zu machen. Eine Mapping Tabelle zu führen ala "bei dem Modul heißt der Wert so, bei dem anderen wieder so", wobei beide Werte eigentlich das selbe aussagen, ist nunmal aufwändig und macht alles nur noch komplexer. Im Grunde läuft es hier auch auf die Unit/RType Diskussion heraus. Ein gutes Beispiel ist aber ebenfalls, dass sich AV Module auf einen gewissen gemeinsamen Reading-Standard geeinigt haben und ich kann darin nur Vorteile erkennen.
Wir haben sehr viele Module, die sich NICHT an Standards halten, das finde ich schlimm genug. Nun kann man bei HMCCU aber nicht von einem Modul sprechen, welches lediglich eine kleine Gruppe adressiert (oder adressieren möchte). Im Gegenteil, es hat sicherlich das Potential genauso viele Nutzer anzusprechen wie CUL_HM es tut. Es hat aber den großen Nachteil, dass die Integration in FHEM viel aufwändiger ist, da es mit anderen Modulen nicht gut zusammenarbeitet und es sehr schwer und unübersichtlich wird, wenn man mit HMCCU Automationen in FHEM definieren möchte. Da ich davon ausgehe, dass dies der Hauptgrund ist, weshalb Menschen FHEM verwenden, sollte HMCCU darauf entsprechend eingehen.
Außerdem muss man sich auch die Frage stellen: Wer verwendet eine CCU2 statt einen CUL Stick o.ä.? Sicherlich doch auch eher die Nutzerschaft, die es sich leicht und einfach machen will, indem sie auf das setzen, was der Hersteller eq3 sich gedacht hat. Du betitelst HMCCU mit "best of both worlds". Das kann ich aber eben nicht erkennen und so nicht unterschreiben, denn jemand, der auf HMCCU mit einer CCU2 setzt, hat es deutlich schwieriger aus FHEM das beste rauszuholen als jemand, der CUL_HM verwendet (und dadurch dann andererseits die Sicherheit des Herstellerstandards aufgeben muss). Dein Versuch mit HMCCU beide Welten ideal zu verbinden verfehlst du deshalb meiner Ansicht nach momentan aufgrund der hohen Komplexität bei Wartbarkeit, Verlässlichkeit und der extrem hohen Einstiegshürde.
Hinzu kommt dann noch, dass sich Dinge auf unterschiedliche Arten lösen kann und ich nie so richtig weiß, ob ich mich jetzt darauf verlassen kann die bestmögliche Definition zu verwenden (Performance, Wartbarkeit, Zukunftssicherheit etc).
Zitat von: zap am 26 Dezember 2016, 12:09:06
Deine sehr komplexen und umfangreichen Attribut-Templates konnte ich nicht 1:1 übernehmen, da sie sicher nicht den Geschmack jedes Nutzers getroffen hätten.
Die Komplexität rührt daher, dass HMCCU eben "zu" flexibel ist und eine extreme Menge an Attributen erfordert. Du hast selbst erklärt, weshalb du das so haben möchtest. Die Folge daraus sind selbstverständlich viele und auch sehr komplexe Attribute. Was hast du erwartet?
Die Attribute stellen den Versuch dar dein Modul einigermaßen in das FHEM Ökosystem und seine anderen Module zu integrieren. Ich möchte stark davon ausgehen, dass die überwiegende Mehrzahl der FHEM Benutzer dieses Interesse verfolgt. Ebenfalls bleibt die Freiheit erhalten Attribute danach abzuändern oder zu löschen. Wir sprechen hier ja auch nicht nur über die reinen FHEMWEB relevanten Attribute zur reinen Anzeige, die vielleicht einige anders haben wollen würden. Du hattest ja beschrieben du würdest solche Attribute ggf. als optional mit aufnehmen. Das hätte ich einen guten Kompromiss gefunden, auch wenn ich noch immer finde, dass es niemandem weh tut, wenn man initial und einmalig einige Attribute so setzt, dass man ein Gerät direkt und sinnvoll aus FHEMWEB heraus steuern kann. Es wird ja niemandem vorgeschrieben diese Einstellungen so zu belassen - es ist ein Template und per Definition ist eine solche Vorlage eben nach ihrer Anwendung beliebig änderbar und stellt nur einen gewissen Standard als Ausgangsbasis dar.
Zitat von: zap am 26 Dezember 2016, 12:09:06
Im Vergleich zu anderen Modulen liegt HMCCU was die Anzahl der Attribute angeht eher im unteren Mittelfeld. Da gibt es viel "schlimmere".
Es ist weniger die reine Anzahl, sondern eher die Mischung aus deren Syntax, Bezeichnung und Kombination untereinander. Andere bezeichnen das als "sehr mächtig". Ich verwende diese Worte aber eben nur, wenn ich nicht dazu gezwungen werde mich dieser "Macht" ständig und wiederholt in einem Umfang zu stellen, der Pflege/Wartung und Setup neuer Systeme signifikant verkompliziert. Vor allem, wenn das eigentlich gar nicht so sein müsste und man niemandem etwas wegnähme, wenn diese Flexibilität optional und für einen sinnvollen Einsatz eben nicht zwingend erforderlich wäre.
Zitat von: zap am 13 Dezember 2016, 21:48:32
Also Deine CCU hat die IP-Adresse 192.168.1.92, korrekt? Wenn Du vom FHEM Server aus ein ping auf diese Adresse absetzt, funktioniert das? Das müsste so ähnlich aussehen:
macbook:~ zap$ ping 192.168.1.11
PING 192.168.1.11 (192.168.1.11): 56 data bytes
64 bytes from 192.168.1.11: icmp_seq=0 ttl=64 time=4.049 ms
64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=2.454 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=3.779 ms
Jetzt geht es ans eingemachte. Falls Du mit den folgenden Schritten nichts anfangen kannst, starte einfach mal die CCU neu und versuche nochmal, den RPC-Server zu starten.
1. Per SSH auf der CCU anmelden
2. Befehl eingeben: fuser 2001/tcp
3. Befehl in 2. sollte eine Zahl ausgeben, wenn nicht => CCU neu starten
4. Befehl eingeben: ps -ef | grep Zahl_aus_Punkt2
5. Befehl in 4. sollte eine Zeile ausgeben, die "rfd" enthält.
Beispiel (bei mir):
# fuser 2001/tcp
355
# ps -ef | grep 355
355 root /bin/rfd -f /etc/config/rfd.conf -l 5
2879 root grep 355
#
Die Fehlermeldung "Can't connect to ..." deutet darauf hin, dass der rfd Prozess auf der CCU nicht mehr läuft.
Hallo Zap,
unglücklicherweise habe ich seit gestern das gleiche Problem, leider als ich mit der HMCCU "rum" spielte. Hab den Raspberry jetzt zum dritten mal neu aufgesetzt.... :-\
Habe die CCU2 neu gestartet, leider kann der RPC Server nicht gestartet werden
Im Logfile kommt folgende Fehlermeldung
2016.12.27 20:09:07 1: HMCCU: Can't connect to CCU port2000
2016.12.27 20:09:07 1: HMCCU: CCU2 Start of RPC server failed
2016.12.27 20:24:46 1: HMCCU: Can't connect to CCU port2000
2016.12.27 20:24:46 1: HMCCU: CCU2 Start of RPC server failed
2016.12.27 20:25:36 1: HMCCU: Can't connect to CCU port2000
2016.12.27 20:25:36 1: HMCCU: CCU2 Start of RPC server failed
2016.12.27 20:46:45 1: HMCCU: Can't connect to CCU port2000
2016.12.27 20:46:45 1: HMCCU: CCU2 Start of RPC server failed
Bei der CCU2 wird keine Zahl angezeigt beim Kommando fuser 2000/TCP
Kannst du weiter helfen?
Bevor der Server abschmierte klappte die Kopplung zwischen FHEM auf Raspberry2 bzw. jetzt 3 und der CCU2
Besten Dank
weihnachtliche Grüße
Ich vermute, du hast das Attribut rpcport auf 2000 gesetzt. Benutzt Du Bidcos-RF (Funk) oder Homematic wired? Die richtigen Werte für rpcport sind (mehrere möglich):
2000 = wired
2001 = bidcos-rf (Funk)
2010 = homematic ip
9292 = virtuelle Gruppengeräte
Mal eine Grundsatzfrage:
Die ccu2 kann und sollte in der Weboberfläche per User/Passwort geschützt werden. Verstehe ich es richtig, das dieses per Netzt, z.B: mit diesem Modul, nicht nötig ist?
Zitat von: Wernieman am 28 Dezember 2016, 12:29:26
Mal eine Grundsatzfrage:
Die ccu2 kann und sollte in der Weboberfläche per User/Passwort geschützt werden. Verstehe ich es richtig, das dieses per Netzt, z.B: mit diesem Modul, nicht nötig ist?
Doch, du solltest weiterhin User/Passwort in der CCU setzen. Allerdings ist die RPC Schnittstelle, die HMCCU verwendet, nicht darüber geschützt, weshalb du bei der Konfiguration von HMCCU auch keine Logindaten eingeben musst, sondern nur die IP Adresse.
Der Zugriff auf die RPC Schnittstelle lässt sich aber immerhin auf bestimmte IP Adressen beschränken. Da macht es Sinn nur die IP des Servers anzugeben, auf dem FHEM läuft.
Die Festlegung einer zulässigen IP Adresse für die RPC Schnittstelle hilft aber nur dafür. Die Homematic Script Schnittstelle (tclrega) bleibt trotzdem offen. Die lässt sich m.W. auch nicht blockieren.
Deshalb sollte man eine CCU auch niemals per Port Forwarding aus dem Internet erreichbar machen sondern besser einen VPN Zugang verwenden.
Ich hatte schonmal darüber nachgedacht, auf die JSON Schnittstelle der CCU2 umzusteigen. Leider funktioniert da die Eventbenachrichtigung nicht. Bei der JSON Schnittstelle kommt ein Authorisierungstoken mit UserID und Passwort zum Einsatz.
Update: Ich sehe gerade bei Loredos Screenshot doch den Punkt Homematic Script. Also möglicherweise lässt sich das doch auf einzelne IPs beschränken. Muss ich mal testen.
Danke für die Info!
Hallo!
Könnte mir bitte jemand mit der Definition meiner Keymatic helfen?
Ich hab leider noch nichts fertiges finden können.
Das Gerät sieht folgendermaßen aus
DEF MEQxxxxxxx
IODev hm_ccu
NAME HM_Sec_Key_S
NR 689
STATE true
TYPE HMCCUDEV
ccuaddr MEQxxxxxxx
ccudevstate Active
ccuif BidCos-RF
ccuname HM-Sec-Key-S
ccutype HM-Sec-Key-S
channels 2
statevals devstate
Readings HM-Sec-Key-S.0.AES_KEY 1
HM-Sec-Key-S.0.CONFIG_PENDING false
HM-Sec-Key-S.0.DUTYCYCLE false
HM-Sec-Key-S.0.LOWBAT false
HM-Sec-Key-S.0.RSSI_DEVICE 186
HM-Sec-Key-S.0.RSSI_PEER 196
HM-Sec-Key-S.0.STICKY_UNREACH false
HM-Sec-Key-S.0.UNREACH false
HM-Sec-Key-S.1.DIRECTION 0
HM-Sec-Key-S.1.ERROR 0
HM-Sec-Key-S.1.INHIBIT false
HM-Sec-Key-S.1.STATE 0
HM-Sec-Key-S.1.STATE_UNCERTAIN 0
state 0
Attributes
IODev hm_ccu
event-on-change-reading .*
room Homematic
Wenn ich abschliesse ist
HM-Sec-Key-S.1.STATE 0
und
state 0
aufgeschlossen ist
HM-Sec-Key-S.1.STATE 1
und
state 1
Danke schonmal und Gruß
Sven
Bei der Keymatic würde ich es mal mit folgenden Attributen versuchen:
ccureadingformat datapoint
statedatapoint 1.STATE
statevals lock:false,unlock:true
substitute STATE!(0|false):locked,(1|true):unlocked,2:open;LOWBAT,UNREACH!(0|false):no,(1|true):yes;STATE_UNCERTAIN!(1|true):manual;DIRECTION!0:none,1:up,2:down,3:undefined;ERROR!0:no,1:clutch_failure,2:motor_aborted
event-on-change-reading .*
eventMap /datapoint 1.OPEN true:open/
Abgeleitet aus der Doku (ich habe keine Keymatic):
http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/hm_devices_Endkunden.pdf
Das sollte Dir folgende neue Set Befehle bereitstellen: lock, unlock, open
Wenn das so funktioniert, teile das bitte mit. Dann übernehme ich die Einstellungen in die Default Templates.
Hallo zap,
vielen Dank für Deine Hilfe, funktioniert wie beschrieben!
Kannst Du so ins default template übernehmen.
Gruß
Sven
Hallo zap,
eine Funktionalität der KeyMatic fehlt mir noch:
man kann das Schloss "sperren" im Falle einer Sabotage zum Beispiel.
Ich hab einen Fingerabdruck Sensor dran der das auslöst falls jemand das Gehäuse öffnet.
get deviceinfo gibt zurück
CHN MEQXXXXXXX:0 HM-Sec-Key-S:0
DPT {b} BidCos-RF.MEQXXXXXXX:0.UNREACH = false [RE]
DPT {b} BidCos-RF.MEQXXXXXXX:0.STICKY_UNREACH = false [RWE]
DPT {b} BidCos-RF.MEQXXXXXXX:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.MEQXXXXXXX:0.LOWBAT = false [RE]
DPT {b} BidCos-RF.MEQXXXXXXX:0.DUTYCYCLE = false [RE]
DPT {n} BidCos-RF.MEQXXXXXXX:0.RSSI_DEVICE = 186 [RE]
DPT {n} BidCos-RF.MEQXXXXXXX:0.RSSI_PEER = 196 [RE]
DPT {n} BidCos-RF.MEQXXXXXXX:0.AES_KEY = 1 [R]
CHN MEQXXXXXXX:1 HM-Sec-Key-S:1
DPT {b} BidCos-RF.MEQXXXXXXX:1.STATE = true [RWE]
DPT {b} BidCos-RF.MEQXXXXXXX:1.OPEN = [W]
DPT {f} BidCos-RF.MEQXXXXXXX:1.RELOCK_DELAY = [W]
DPT {b} BidCos-RF.MEQXXXXXXX:1.STATE_UNCERTAIN = false [RE]
DPT {b} BidCos-RF.MEQXXXXXXX:1.INHIBIT = false [RWE]
DPT {i} BidCos-RF.MEQXXXXXXX:1.ERROR = 0 [RE]
DPT {i} BidCos-RF.MEQXXXXXXX:1.DIRECTION = 0 [RE]
DPT {b} BidCos-RF.MEQXXXXXXX:1.INSTALL_TEST = [W]
Müsste sein:
DPT {b} BidCos-RF.MEQXXXXXXX:1.INHIBIT = false
das hätte ich gerne in ein eigenes reading was ich ein und ausschalten kann.
Geht das mit HMCCU?
Gruß
Sven
Ich habe jetzt einmal mit ccureadingname und substitute versucht die Readings so zu verbiegen, dass ich keine userReadings mehr benötigte.
Ich komme jedoch weder bei HMCCUCHN noch bei HMCCUDEV soweit, dass die Kanalnummer nicht mehr als Präfix mit enthalten ist. Daher erscheinen mir diese Attribute derzeit wenig nutzbar für die Angleichung an FHEM Standard-Readingnamen.
Bei HMCCUDEV wurde glaube ich gesagt, dass man nicht auf den Kanal-Präfix verzichten könne, weil Überlappungen bei den Readingnamen nicht auszuschließen wären. Nach Studium der eq-3 Doku zu den Datenpunkten (http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/hm_devices_Endkunden.pdf) würde ich aber sagen, dass es keine zu erwartenden Überlappungen gibt. Vielleicht habe ich aber auch etwas übersehen.
Ich erinnere mich, dass für HMCCUCHN einmal im Raum stand den Kanal 0 zusätzlich mit aufzuführen, um dort Zugriff auf Dinge wie LOWBAT, UNREACH etc zu bekommen. Diese Funktion konnte ich nicht finden, sofern sie schon eingebaut ist. Wäre sie da, dann würde ich vermutlich ausschließlich nur noch HMCCUCHN Geräte definieren und HMCCUDEV wäre komplett obsolete, sofern die Kanalpräfixe dort zwingend erhalten blieben. Ich verstehe wohl noch immer nicht, warum man den Unterschied zwischen HMCCUCHN und HMCCUDEV (noch) machen muss.
Grundsätzlich kannst Du mit dem Befehl set datapoint jeden Datenpunkt ansprechen, der bei deviceinfo das "W" gesetzt hat.
Also z.B.
set HM_Sec_Key_S datapoint 1.INHIBIT true
Das lässt sich natürlich auch mittels eventMap als Befehl abbilden:
eventMap eventMap /datapoint 1.OPEN true:open/datapoint 1.INHIBIT true:inhibiton/datapoint 1.INHIBIT false:inhibitoff/
Nur als Hinweis: Manche Homematic Geräte werden auch über die Geräteeinstellungen bzw. Config-Parameter gesperrt. Die erreicht man im CCU WebUI über Einstellungen -> Geräte und dann beim jeweiligen Gerät den Button "Einstellen". Diese Art Parameter werden nicht über Datenpunkte abgebildet. Man erreicht sie nur mit dem Befehl set config.
Zitat von: Loredo am 29 Dezember 2016, 13:34:47
Ich habe jetzt einmal mit ccureadingname und substitute versucht die Readings so zu verbiegen, dass ich keine userReadings mehr benötigte.
Ich komme jedoch weder bei HMCCUCHN noch bei HMCCUDEV soweit, dass die Kanalnummer nicht mehr als Präfix mit enthalten ist. Daher erscheinen mir diese Attribute derzeit wenig nutzbar für die Angleichung an FHEM Standard-Readingnamen.
m.E. sollte das ohne Kanalnummer funktionieren. Du musst berücksichtigen, dass der zu ersetzende Readingname ein regulärer Ausdruck ist und lediglich der Teil des Readingnames ersetzt wird, der dem regulären Ausdruck entspricht. Beispiel
Readingname = 0.LOWBAT
Ersetzungsregel = LOWBAT:battery
Ergebnis: 0.battery
ABER:
Readingname = 0.LOWBAT
Ersetzungsregel = ^.*LOWBAT$:battery
Ergebnis: battery
Ok, die Doku ist an dieser Stelle ausbaufähig ;-)
Zitat
Bei HMCCUDEV wurde glaube ich gesagt, dass man nicht auf den Kanal-Präfix verzichten könne, weil Überlappungen bei den Readingnamen nicht auszuschließen wären. Nach Studium der eq-3 Doku zu den Datenpunkten (http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/hm_devices_Endkunden.pdf) würde ich aber sagen, dass es keine zu erwartenden Überlappungen gibt. Vielleicht habe ich aber auch etwas übersehen.
Ja, die Mehrfach-Schalter hast Du z.B. übersehen. Da hat jeder Kanal seinen eigenen STATE Datenpunkt. In der Doku steht da immer Kanal 1-n.
Zitat
Ich erinnere mich, dass für HMCCUCHN einmal im Raum stand den Kanal 0 zusätzlich mit aufzuführen, um dort Zugriff auf Dinge wie LOWBAT, UNREACH etc zu bekommen. Diese Funktion konnte ich nicht finden, sofern sie schon eingebaut ist. Wäre sie da, dann würde ich vermutlich ausschließlich nur noch HMCCUCHN Geräte definieren und HMCCUDEV wäre komplett obsolete, sofern die Kanalpräfixe dort zwingend erhalten blieben. Ich verstehe wohl noch immer nicht, warum man den Unterschied zwischen HMCCUCHN und HMCCUDEV (noch) machen muss.
Das ist eingebaut, es sei denn, Du setzt für ein HMCCUCHN Device das Attribut ccuflags auf nochn0.
Zitat von: zap am 29 Dezember 2016, 13:52:25
Das ist eingebaut, es sei denn, Du setzt für ein HMCCUCHN Device das Attribut ccuflags auf nochn0.
sollte das bedeuten wenn das attribut nicht gesetzt ist sollte egal welchen cahnnel ich per hmccuchn anlege zusätzlich noch die 0.* readings haben?
Ja.
... aber:
in der aktuellen Version nur, wenn sie die CCU schickt. Bei einem "get update" werden sie nicht aktualisiert. Das wird erst mit 3.7 so sein.
Man kann es testen indem man z.B. die Batterien bei einem Gerät entfernt. Mit geeignetem ccureadingfilter sollte dann ein 0.UNREACH kommen.
Zitat von: zap am 29 Dezember 2016, 13:52:25
m.E. sollte das ohne Kanalnummer funktionieren. Du musst berücksichtigen, dass der zu ersetzende Readingname ein regulärer Ausdruck ist und lediglich der Teil des Readingnames ersetzt wird, der dem regulären Ausdruck entspricht
Passt, danke!
Zitat von: zap am 29 Dezember 2016, 13:52:25
Das ist eingebaut, es sei denn, Du setzt für ein HMCCUCHN Device das Attribut ccuflags auf nochn0.
Hm, also bei einem "get update" werden diese Readings nicht erzeugt.
defmod LR_SunBlind HMCCUCHN HEQ0402430:1
attr LR_SunBlind DbLogExclude .*
attr LR_SunBlind IODev CCU2
attr LR_SunBlind alias Markise
attr LR_SunBlind ccureadingformat datapoint
attr LR_SunBlind ccureadingname ^.*ACTUAL_TEMPERATURE$:measured-temp,^.*BRIGHTNESS$:brightness,^.*CONTROL_MODE$:controlMode,^.*DIRECTION$:direction,^.*HUMIDITY$:humidity,^.*INHIBIT$:lock,^.*LEVEL$:level,^.*LOW[_]?BAT$:battery,^.*MOTION$:motion,^.*SET_TEMPERATURE$:desired-temp,^.*TEMPERATURE$:temperature,^.*UNREACH$:Activity,^.*WORKING$:working
attr LR_SunBlind ccuscaleval LEVEL:0.01
attr LR_SunBlind cmdIcon close:control_arrow_leftward stop:time_manual_mode open:control_arrow_rightward
attr LR_SunBlind devStateIcon 100|on:fts_sunblind_100@red:level 0|off:fts_sunblind_0@green:level%2055 1[0-9].*:fts_sunblind_10@orange:level 2[0-9].*:fts_sunblind_20@orange:level 3[0-9].*:fts_sunblind_30@orange:level 4[0-9].*:fts_sunblind_40@orange:level 5[0-9].*:fts_sunblind_50@orange:level 6[0-9].*:fts_sunblind_60@red:level 7[0-9].*:fts_sunblind_70@red:level 8[0-9].*:fts_sunblind_80@red:level 9[0-9].*:fts_sunblind_90@red:level [0-9].*:fts_sunblind_0@orange:level out|up|opening:control_arrow_rightward@orange:stop in|down|closing:control_arrow_leftward@orange:stop OK:general_ok@green:stop unreachable:light_question Error:light_exclamation
attr LR_SunBlind event-on-change-reading .*
attr LR_SunBlind eventMap /datapoint STOP 1:stop/datapoint LEVEL:level/datapoint LEVEL:pct/datapoint LEVEL 55:on/datapoint LEVEL 55:out/datapoint LEVEL 55:open/datapoint LEVEL 55:down/datapoint LEVEL 0:off/datapoint LEVEL 0:in/datapoint LEVEL 0:close/datapoint LEVEL 0:up/
attr LR_SunBlind genericDeviceType blind
attr LR_SunBlind group Fenster & Türen
attr LR_SunBlind icon awning
attr LR_SunBlind room HMCCU,Homekit,Umwelt,Wohnzimmer
attr LR_SunBlind siriName Sunblind
attr LR_SunBlind sortby 1
attr LR_SunBlind stateFormat stateHM
attr LR_SunBlind substitute DIRECTION!(none|0):none,(up|1):up,(down|2):down,.*:undefined;;INHIBIT!(false|0):unlocked,(true|1):locked;;LOWBAT!(false|0):ok,(true|1):low;;LOW_BAT!(false|0):ok,(true|1):low;;MOTION!(false|0):noMotion,(true|1):motion;;UNREACH!(false|0):alive,(true|1):dead
attr LR_SunBlind userReadings stateHM:.* { my $m = ReadingsVal($name, 'direction', 'error');; my $l = ReadingsVal($name, 'level', 'error');; my $r = ReadingsVal($name, 'Activity', 'error');; if ($r eq 'dead') { return 'unreachable' } elsif ($m eq 'none') { if ($l eq '0') { return 'off' } elsif ($l eq '100') { return 'on' } else { return $l } } else { return $m } }
attr LR_SunBlind webCmd close:stop:open
attr LR_SunBlind widgetOverride level:slider,0,1,100
setstate LR_SunBlind 10000
setstate LR_SunBlind 2016-12-29 14:33:22 direction none
setstate LR_SunBlind 2016-12-29 14:33:22 level 10000
setstate LR_SunBlind 2016-12-29 14:25:50 lock unlocked
setstate LR_SunBlind 2016-12-29 14:25:51 pct 0
setstate LR_SunBlind 2016-12-29 14:33:22 stateHM 10000
setstate LR_SunBlind 2016-12-29 14:33:22 working 0
s. mein Posting eins weiter oben. Das ist u.a. auch der Grund, weshalb die Readings bei HMCCUCHN Devices den Kanal vorangestellt haben. Bei Fensterkontakten (z.B.) Datenpunkt LOWBAT sowohl in 0 als auch in 1.
Zu Deiner Markise: bei LEVEL würde ich Dir empfehlen, bei ccuscaleval immer folgende Syntax zu verwenden:
LEVEL:0:1:0:100
Grund: bei manchen Geräten liefert LEVEL Werte von 0-100, teilweise abhängig von der Geräte-Revision bzw. der Firmware. Bei o.g. Syntax prüft ccuscaleval vor der Skalierung, in welchem Bereich der Wert liegt. Bei Deiner Variante wird gnandelos skaliert.
Außerdem sollte der Befehl "set pct" automatisch verfügbar sein, wenn ein LEVEL vorhanden ist. Spart den eventMap Eintrag.
Ok, merci!
Kannst du noch sagen, weshalb ich in obigem Beispiel plötzlich eine falsche Berechnung von level habe?
Eigentlich ist der Wert aktuell 0
Zitat von: Loredo am 29 Dezember 2016, 14:38:01
Ok, merci!
Kannst du noch sagen, weshalb ich in obigem Beispiel plötzlich eine falsche Berechnung von level habe?
Eigentlich ist der Wert aktuell 0
mit LEVEL:0.01 oder mit LEVEL:0:1:0:100 ?
Eigentlich mit LEVEL:0.01.
Ich denke aber ich weiß woran es liegt: Ich habe für den Test ein vorhandenes HMCCUCHN Gerät dupliziert. Diese scheinen sich gegenseitig zu stören und nicht unabhängig voneinander zu sein. Das sieht man daran, dass ich bei dem einen Gerät LEVEL:0:1:0:100 ausprobiert habe und bei dem anderen LEVEL:0.01 gesetzt ist. Die beiden Geräte scheinen sich die Attribute irgendwie zu teilen bzw. sie scheinen sich gar noch irgendwie zu addieren, weil ich hier teils um den Faktor 100 zu hohe Werte bekomme (also 8950 statt 89.50).
Interessanter Effekt, der so nicht gewollt ist. Versuche ich mal nachzuvollziehen.
Zitat von: Loredo am 29 Dezember 2016, 14:50:29
Eigentlich mit LEVEL:0.01.
Ich denke aber ich weiß woran es liegt: Ich habe für den Test ein vorhandenes HMCCUCHN Gerät dupliziert. Diese scheinen sich gegenseitig zu stören und nicht unabhängig voneinander zu sein. Das sieht man daran, dass ich bei dem einen Gerät LEVEL:0:1:0:100 ausprobiert habe und bei dem anderen LEVEL:0.01 gesetzt ist. Die beiden Geräte scheinen sich die Attribute irgendwie zu teilen bzw. sie scheinen sich gar noch irgendwie zu addieren, weil ich hier teils um den Faktor 100 zu hohe Werte bekomme (also 8950 statt 89.50).
Ist ein Bug. Tritt nur auf, wenn es >1 FHEM-Devices mit gleicher Adresse gibt.
Hat jemand schon mal Sirenen (HM-Sec-Sir-WM) mit diesem Modul angebunden und gesteuert?
heute hat ein set upate eine hmccudev fhem gekilled. letzte meldung im log war dann
Zitat
2017.01.03 18:20:15 0: HMCCU: Received IN event. RPC server CB9292 initialized.
2017.01.03 18:20:15 3: HMCCU: Device LEQ0636100:6 has no readable datapoints
Unmatched ) in regex; marked by <-- HERE in m/0|false) <-- HERE / at ./FHEM/88_HMCCU.pm line 1751.
... und beim start danach direkt wieder
2017.01.03 18:42:38 0: HMCCU: Received IN event. RPC server CB9292 initialized.
Unmatched ) in regex; marked by <-- HERE in m/0|false) <-- HERE / at ./FHEM/88_HMCCU.pm line 1751.als letztes hatte ich einem device einen (wohl unverträglichen) substitute gegeben! dass sollte man unbedingt abfangen im modul!!!!
zusatz der fehler liegt offenbar nicht mit dem substitute zusammen. auch nach cfg änderung startet die ka... immer noch nicht
Zitat
2017.01.03 18:53:01 0: HMCCU: Received IN event. RPC server CB9292 initialized.
2017.01.03 18:53:01 3: HMCCU: Device LEQ0636100:5 has no readable datapoints
2017.01.03 18:53:01 3: HMCCU: Device MEQ0600596:1 has no readable datapoints
Unmatched ) in regex; marked by <-- HERE in m/0|false) <-- HERE / at ./FHEM/88_HMCCU.pm line 1751.
an keinen der beiden geräten würde was geändert !
EDIT: - ein neustart der ccu + neustart fhemserver und es lief kurz... bis ich ein get update bei folgendem device gemacht habe:
define az_hz HMCCUDEV az_hz
attr az_hz IODev CCU01
attr az_hz ccureadingformat datapoint
attr az_hz controldatapoint 4.SET_TEMPERATURE
attr az_hz eventMap /datapoint 4.AUTO_MODE 1:Auto/datapoint 4.BOOST_MODE 1:Boost
attr az_hz group Heizung
attr az_hz room HM
attr az_hz stateFormat T: 4.ACTUAL_TEMPERATURE dT: 4.SET_TEMPERATURE V: 4.VALVE_STATE B: 0.LOWBAT
attr az_hz stripnumber 1
attr az_hz substitute LOWBAT!(0|false):ok,(1|true):low;;UNREACH!0|false):ok,(1|true):unreach;;
attr az_hz webCmd control:Auto:Boost
attr az_hz widgetOverride control:slider,5,1,25
umgestellt wurde
ccureadingformat auf datapoint
eventMap /datapoint 4.AUTO_MODE 1:Auto/datapoint 4.BOOST_MODE 1:Boost
az_hz stateFormat T: 4.ACTUAL_TEMPERATURE dT: 4.SET_TEMPERATURE V: 4.VALVE_STATE B: 0.LOWBAT
substitute LOWBAT!(0|false):ok,(1|true):low;UNREACH!0|false):ok,(1|true):unreach;EDIT2:
habe alle änderungen aus der cfg genommen, server reboot, device wieder so konfiguriert bis auf "UNREACH!0|false):ok,(1|true):unreach;" kann es sein das er mit der substitution nicht klar kam weil UNREACH und unreach???
Hallo,
zunächst einmal möchte ich zap für das tolle Modul danken.
Trotz lesen der 71 Seiten und des WIKIs brauche ich aber noch etwas Unterstützung:
Ich habe ein Homematic Thermostat HM-CC-RT-DN als HMCCUDEV eingebunden, hier tauchen die beiden nachfolgenden Probleme bei mir auf:
1. ccureadingname 4.BATTERY_STATE:Batterygreift bei mir nicht. Das Reading 4.BATTERY_STATE wird nicht ersetzt. Leider weiß ich nicht, was ich falsch mache.
2. ccureadingfilter (^UNREACH|LOWBAT|TEMPERATURE|VALVE_STATE|CONTROL)trotz dieses defaults Attributs werden Readings wie z.B. R-ENDTIME_FRIDAY ausgegeben. Auch hier die gleiche Frage, wieso wird dies mit ausgegeben bzw. was mache ich falsch?
Und zum Schluss (evtl. Offtopic). Bei meiner CCU2 blinkt die Internet-LED nach jedem Neustart. Der Fehler wird u.a. hier http://homematic-forum.de/forum/viewtopic.php?f=31&t=31917 (http://homematic-forum.de/forum/viewtopic.php?f=31&t=31917) beschrieben und gelöst. Leider kann ich die Datei /etc/network/if-up.d/eQ3StartNetwork nicht editieren. Diese Datei ist read-only >:(. Daher löse ich das Problem indem ich
touch /var/status/hasInternet auf der CCU2 ausführe. Und nun meine Fragen. Kann ich den vorgenannten Befehl auch über das HMCCU-Modul absetzen. Oder wisst ihr, wie ich die Datei eQ3StartNetwork so editieren kann, dass ich die überprüfte IP-Adresse ersetzen kann (hier gegen die IP-Adresse meines Routers).
Gruß
Mundus
warum stört dich die led? sobald die ccu2 dann nach start erkennt das sie internet zugang hat geht sie aus. das problem ist aber ehr in deinem netzwerk zu suchen als an der ccu denke ich
Zitat von: chris1284 am 03 Januar 2017, 18:57:38
attr az_hz substitute LOWBAT!(0|false):ok,(1|true):low;;UNREACH!0|false):ok,(1|true):unreach;;
Nach UNREACH! fehlt eine "(".
Mal sehen, ob ich per eval eine Prüfung des Regexp einbauen kann, bevor sie ausgeführt wird.
Zitat von: Mundus am 05 Januar 2017, 00:03:18
Ich habe ein Homematic Thermostat HM-CC-RT-DN als HMCCUDEV eingebunden, hier tauchen die beiden nachfolgenden Probleme bei mir auf:
1. ccureadingname 4.BATTERY_STATE:Batterygreift bei mir nicht. Das Reading 4.BATTERY_STATE wird nicht ersetzt. Leider weiß ich nicht, was ich falsch mache.
Der Datenpunkt BATTERY_STATE muss auch im Attribut ccureadingfilter drin sein. Nach Deinen Angaben unten ist er das nicht..
Zitat
2. ccureadingfilter (^UNREACH|LOWBAT|TEMPERATURE|VALVE_STATE|CONTROL)trotz dieses defaults Attributs werden Readings wie z.B. R-ENDTIME_FRIDAY ausgegeben. Auch hier die gleiche Frage, wieso wird dies mit ausgegeben bzw. was mache ich falsch?
Der ccureadingfilter bezieht sich nur auf die Datenpunkte. Alle Readings, die mit "R-" beginnen, sind aber Config-Parameter, die mit dem Befehl "get config" ausgelesen wurden. Bei diesem Befehl kann man einen regulären Ausdruck angeben, der die gelesenen Parameter (und damit die "R-" Readings) einschränkt.
Zitat
Daher löse ich das Problem indem ich
touch /var/status/hasInternet auf der CCU2 ausführe. Und nun meine Fragen. Kann ich den vorgenannten Befehl auch über das HMCCU-Modul absetzen. Oder wisst ihr, wie ich die Datei eQ3StartNetwork so editieren kann, dass ich die überprüfte IP-Adresse ersetzen kann (hier gegen die IP-Adresse meines Routers).
Die Ausführung von Linux Befehlen auf der CCU wird von HMCCU nicht unterstützt. Du kannst es Dir aber selbst bauen, z.B. per SSH:
- Key ohne Passphrase generieren
- Key auf der CCU für den User root hinterlegen
- Auf FHEM Seite eine Shell-Script erzeugen, dass per SSH unter Verwendung des o.g. Keys auf der CCU den gewünschten Befehl ausführt.
Um das Shellscript aus FHEM anzustoßen, gibt es viele Möglichkeiten unter FHEM.
Oder Du versuchst, die eigentliche Fehlerursache zu eliminieren. Bei mir geht die LED aus, sobald die Inet-Verbindung steht.
hi zap, hast du evtl hierfür schon was in planung oder einen workaround?
https://forum.fhem.de/index.php/topic,64064.0.html
Hallo,
Zitat von: zap am 05 Januar 2017, 12:33:42
Der Datenpunkt BATTERY_STATE muss auch im Attribut ccureadingfilter drin sein. Nach Deinen Angaben unten ist er das nicht.
Das war der Ansatzpunkt der mir fehlte. Nachdem ich
deleteReading KuecheThermostat .*ausgeführt habe, sind alle (wie auch immer von mir zugefügten Readings) verschwunden. Anschließend wurden noch die Readings angezeigt, die im ccureadingfilter genannt waren. Dort habe ich BATTERY angefügt und prompt griff meine Ersetzung im ccureadingname. Gibt es eigentlich eine schönere Variante als deleteReading um die Readings von HMCCUDEV's zurückzusetzen?
Außerdem wird hier eine Doku zu HMCCU erwähnt, die ich leider nicht finde. Existiert neben den WIKI Einträgen und der COMMANDREF noch eine weitere Dokumentation?
Das Problem bzw. der Fehler mit der CCU2 ist bei mir kein Fehler, da meine CCU2 nicht ins Internet soll (Diesen Zustand möchte ich auch gerne beibehalten). Daher habe ich ein Workaround gesucht, wie ich die blinkende LED (das nervt ziemlich) dauerhaft anschalte. Ich werde mir also den Hinweis
Zitat von: zap am 05 Januar 2017, 12:33:42
Die Ausführung von Linux Befehlen auf der CCU wird von HMCCU nicht unterstützt. Du kannst es Dir aber selbst bauen, z.B. per SSH:
- Key ohne Passphrase generieren
- Key auf der CCU für den User root hinterlegen
- Auf FHEM Seite eine Shell-Script erzeugen, dass per SSH unter Verwendung des o.g. Keys auf der CCU den gewünschten Befehl ausführt.
Um das Shellscript aus FHEM anzustoßen, gibt es viele Möglichkeiten unter FHEM.
mal genauer ansehen bzw. mich einlesen.
Abschließend vielen Dank für eure Hilfe
Mit dem Befehl "Set clear" kann man Readings löschen. Der Unterschied zu deleterding ist allerdings marginal.
Als Doku gibt es "nur" die Commandref und die Wiki Artikel. Was fehlt Dir denn?
Zitat von: zap am 06 Januar 2017, 07:15:21
Als Doku gibt es "nur" die Commandref und die Wiki Artikel. Was fehlt Dir denn?
Mir fehlt nichts, ich wollte nur wissen, ob es weitere Beschreibungen gibt, die ich übersehen habe.
Hallo!
Ich habe ein Problem mit dem HMCCU Modul und einem CCU Gruppendevice.
Ich hab mich an die Config in https://forum.fhem.de/index.php/topic,51339.msg499371.html#msg499371 (https://forum.fhem.de/index.php/topic,51339.msg499371.html#msg499371) angelehnt.
Wenn ich die Temperatur per Slider setze friert fhem komplett ein, per Weboberfläche und per telnet nicht mehr erreichbar.
Auch ein service fhem restart führt nicht zum Erfolg.
Ich muss meinen NUC neu booten damit ich überhaupt wieder auf fhem komme.
Im Log steht nach dem Einfrieren:
Undefined subroutine &main::usleep called at ./FHEM/88_HMCCU.pm line 3833.
Definition des Device:
IODev hm_ccu
ccureadingfilter (^SET_TEMPERATURE|^TEMPERATURE|^HUMIDITY|LOWBAT|^VALVE|^CONTROL|^WINDOW_OPEN)
ccureadingformat name
ccuverify 1
cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
controldatapoint 1.SET_TEMPERATURE
event-on-change-reading .*
eventMap /datapoint 1.MANU_MODE 20.0:Manu/datapoint 1.AUTO_MODE 1:Auto/datapoint 1.BOOST_MODE 1:Boost/datapoint 1.MANU_MODE 4.5:off/datapoint 1.MANU_MODE 30.5:on/
room 2.10:Arbeitszimmer,Homematic
stateFormat
T: HM-TC-IT-2OG_AZ.1.TEMPERATURE° H: HM-TC-IT-2OG_AZ.1.HUMIDITY% D: HM-TC-IT-2OG_AZ.2.SET_TEMPERATURE° P: DEWPOINT° V: HM-CC-RT-2OG_AZ.4.VALVE_STATE% HM-TC-IT-2OG_AZ.2.CONTROL_MODE
statechannel 1
statedatapoint 1.SET_TEMPERATURE
stripnumber 1
substitute LOWBAT!(0|false):no,(1|true):yes;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed
userReadings DEWPOINT {HMCCU_Dewpoint($name,"HM-TC-IT-2OG_AZ.1.TEMPERATURE", "HM-TC-IT-2OG_AZ.1.HUMIDITY","n/a")}, LOWBAT_STATE:(HM-TC-IT-2OG_AZ.0.LOWBAT|HM-CC-RT-2OG_AZ.0.LOWBAT) {HMCCU_AggReadings($name, "HM-CC.*LOWBAT","and","no","yes")}, LOWBAT_COUNT:(HM-TC-IT-2OG_AZ.0.LOWBAT|HM-CC-RT-2OG_AZ.0.LOWBAT) {HMCCU_AggReadings($name, "HM-CC.*LOWBAT","cnt","yes","")}
webCmd control:Auto:Manu:Boost:on:off
widgetOverride control:slider,10,1,25
Readings:
DEWPOINT 7.3
G_HZ_2OG_AZ.0.LOWBAT no
G_HZ_2OG_AZ_INT0000001.1.CONTROL_MODE AUTO
G_HZ_2OG_AZ_INT0000001.1.SET_TEMPERATURE 21.0
HM-CC-RT-2OG_AZ.0.LOWBAT no
HM-CC-RT-2OG_AZ.4.CONTROL_MODE AUTO
HM-CC-RT-2OG_AZ.4.SET_TEMPERATURE 21.0
HM-CC-RT-2OG_AZ.4.VALVE_STATE 6
HM-TC-IT-2OG_AZ.0.LOWBAT no
HM-TC-IT-2OG_AZ.1.HUMIDITY 41
HM-TC-IT-2OG_AZ.1.TEMPERATURE 21.1
HM-TC-IT-2OG_AZ.2.CONTROL_MODE AUTO
HM-TC-IT-2OG_AZ.2.LOWBAT_REPORTING false
HM-TC-IT-2OG_AZ.2.SET_TEMPERATURE 21.0
HM-TC-IT-2OG_AZ.2.WINDOW_OPEN_REPORTING closed
control 21.0
state 21.0
Fehler im Modul oder bei mir?
Gruß
Sven
In Deiner Perl Installation fehlt usleep() aus dem Modul Timer::Hires. Bei vielen Installationen ist das dabei.
Abhilfe ist einfach: Lösche das Attribut "ccuverify". Dann wird usleep() nicht mehr aufgerufen. Alternativ kannst Du Timer::HiRes per CPAN oder als Paket installieren. ccuverify ist aber in den wenigsten Fällen notwendig.
Hi zap,
danke für die Erklärung, funktioniert bei mir leider noch nicht wie beschrieben
Zitat von: zap am 08 Januar 2017, 10:32:40
In Deiner Perl Installation fehlt usleep() aus dem Modul Timer::Hires. Bei vielen Installationen ist das dabei.
Abhilfe ist einfach: Lösche das Attribut "ccuverify". Dann wird usleep() nicht mehr aufgerufen. Alternativ kannst Du Timer::HiRes per CPAN oder als Paket installieren. ccuverify ist aber in den wenigsten Fällen notwendig.
Ich hab HiRes per CPAN installiert:
cpan
cpan> install Bundle::CPAN
cpan> reload cpan
cpan> install Time::HiRes
cpan> exitHabe dann sicherheitshalber fhem mal neu gestartet.
Der Fehler ist immer noch da.
Das Paket libdatetime-perl war übrigens vorher schon installiert.
Mein System ist ein NUC mit Debian (8.6).
Ich hab ccuverify erstmal abgeschaltet was das Problem ja erstmal nur umgeht.
Was kann ich tun um das Perl Problem zu lösen?
Danke und Gruß
Sven
Komischerweise ist aus dem Modul 88_HMCCU.pm das Statement verschwunden, mit dem Timer::HiRes eingebunden wird. Deine Installation hat daher keinen Effekt. Ich habe das vermutlich irgendwann mal entfernt, warum auch immer.
In der nächsten Version ist es wieder drin und Du kannst dann das Attribut wieder benutzen.
Die 3.7 ist gerade im Test bei mir. Wenn keine größeren Bugs mehr auftreten, werde ich es in den nächsten Tagen einchecken.
Ok dann liegt es nicht an meiner Installation.
Danke fürs nachschauen dann freu ich mich aufs Update :)
Gruß
Sven
Zitat von: Yil am 31 Dezember 2016, 02:32:17
Hat jemand schon mal Sirenen (HM-Sec-Sir-WM) mit diesem Modul angebunden und gesteuert?
Hier mal einige Attribute, die hilfreich sein könnten. Da ich keine Sirene habe, kann ich das alles nicht testen.
ccureadingfilter = (STATE|ERROR)
ccureadingname = 1.STATE:STATE_SENSOR1,2.STATE:STATE_SENSOR2,3.STATE:STATE_PANIC
eventMap = /datapoint 3.STATE true:panic/
statedatapoint = 4.ARMSTATE
statevals = disarmed:0,extsens-armed:1,allsens-armed:2,alarm-blocked:3
substitute = ERROR_SABOTAGE!(0|false):no,(1|true):yes;ARMSTATE!0:disarmed,1:extsens_armed,2:allsens_armed,3:alarm_blocked
Damit bekommst Du zusätzliche Set-Befehle:
set panic
set disarmed
set extsens-armed
set allsend-armed
set alarm-blocked
Wenn Du on-for-timer oder on-till nutzen möchtest, solltest Du statevals wie folgt setzen:
statevals = off:0,extsens-armed:1,on:2,alarm-blocked:3
Hintergrund: die Timerbefehle funktionieren nur, wenn "on" existiert.
@ZAP
Ich hab ne Frage zu den Thermostaten (HM-CC-RT-DN, HM-TC-IT-WM-W-EU).
Gibt es eine Möglichkeit über Fhem die Modis btnLock, globalBtnLock und modusBtnLock über HMCCU zu senden ?
Ich hab da so zwei Stinker, nennen wir sie mal Kinder :D und die drehen gerne mal Nachts zur Schlafenszeit die Temperatur hoch.
Das will ich verhindern und ihnen Nachts das Thermostat sperren. Momentan klappt das über HMLAN, jedoch will ich irgendwann komplett auf HMCCU umsteigen.
Gruß
Rubinho
in der konfig gibts zumindest MODUS_BUTTON_LOCK=0 , in der deviceinfo taucht aber kein writeable datapoint auf.
per cul_hm gehts
EDIT: Antowrt aus HM -Forum
Zitat
das geht mit dem setParam.tcl-Script, min. BUTTON_LOCK boolean 0 MODUS_BUTTON_LOCK boolean 0 kann man damit setzen und aufheben...
@chris1284
Ja, das der datapoint fehlt ist mir auch aufgefallen (deswegen die Frage) vielleicht wurde das auf Modulseite (HMCCU) nur nicht implementiert.
Blöd wäre es, wenn das rpc die Modis einfach nicht hat.
So ich hab mittlerweile herausgefunden, dass man zumindest mit dem Befehl get <device> config GLOBAL_BUTTON_LOCK den Wert angezeigt bekommt.
Eigendlich bin ich davon ausgegangen, dass mit dem Befehl set <device> config GLOBAL_BUTTON_LOCK=1 den Modus auch auf dem Gerät setzen kann, doch dass will nicht gehen.
Der Befehl wird zwar ohne murren abgesetzt, jedoch wird das HM Device nicht geändert :/
Hat noch jemand eine Idee ?
Zitat von: rubinho am 12 Januar 2017, 13:41:37
vielleicht wurde das auf Modulseite (HMCCU) nur nicht implementiert.
nö, er ist auch nicht in den datapoint-dokus von eq3 beschrieben somit sicher nicht vorhanden.
per ccu scripts gehts aber und die kannst du per HMCCU auch aus fhem starten
Du mmust über einen anderen Datapoint gehen .. kann es nur nicht gerade prüfen ..
Der von Dir genannte ist doch "readonly"?
ich habe keinen datapoint der auch nur ansatzweise was mit den buttons zu tun hat und es ist in der doku auch keiner beschrieben! http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/hm_devices_Endkunden.pdf seite 28
anbeimal die deviceinfo eines rt
Zitat
CHN NEQ1408452:0 wz_hz:0
DPT {b} BidCos-RF.NEQ1408452:0.UNREACH = false [RE]
DPT {b} BidCos-RF.NEQ1408452:0.STICKY_UNREACH = false [RWE]
DPT {b} BidCos-RF.NEQ1408452:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.NEQ1408452:0.LOWBAT = false [RE]
DPT {n} BidCos-RF.NEQ1408452:0.RSSI_DEVICE = 1 [RE]
DPT {n} BidCos-RF.NEQ1408452:0.RSSI_PEER = 212 [RE]
DPT {b} BidCos-RF.NEQ1408452:0.INHIBIT = false [RWE]
DPT {b} BidCos-RF.NEQ1408452:0.DEVICE_IN_BOOTLOADER = false [RE]
DPT {b} BidCos-RF.NEQ1408452:0.UPDATE_PENDING = false [RE]
DPT {n} BidCos-RF.NEQ1408452:0.AES_KEY = 0 [R]
CHN NEQ1408452:4 wz_hz:4
DPT {i} BidCos-RF.NEQ1408452:4.CONTROL_MODE = 0 [RE]
DPT {i} BidCos-RF.NEQ1408452:4.FAULT_REPORTING = 0 [RE]
DPT {f} BidCos-RF.NEQ1408452:4.BATTERY_STATE = 2.900000 [RE]
DPT {i} BidCos-RF.NEQ1408452:4.VALVE_STATE = 0 [RE]
DPT {i} BidCos-RF.NEQ1408452:4.BOOST_STATE = 0 [RE]
DPT {f} BidCos-RF.NEQ1408452:4.ACTUAL_TEMPERATURE = 16.900000 [RE]
DPT {f} BidCos-RF.NEQ1408452:4.SET_TEMPERATURE = 16.000000 [RWE]
DPT {b} BidCos-RF.NEQ1408452:4.AUTO_MODE = [W]
DPT {f} BidCos-RF.NEQ1408452:4.MANU_MODE = [W]
DPT {b} BidCos-RF.NEQ1408452:4.BOOST_MODE = [W]
DPT {b} BidCos-RF.NEQ1408452:4.COMFORT_MODE = [W]
DPT {b} BidCos-RF.NEQ1408452:4.LOWERING_MODE = [W]
DPT {s} BidCos-RF.NEQ1408452:4.PARTY_MODE_SUBMIT = [W]
DPT {f} BidCos-RF.NEQ1408452:4.PARTY_TEMPERATURE = 5.000000 [RW]
DPT {i} BidCos-RF.NEQ1408452:4.PARTY_START_TIME = 0 [RW]
DPT {i} BidCos-RF.NEQ1408452:4.PARTY_START_DAY = 1 [RW]
DPT {i} BidCos-RF.NEQ1408452:4.PARTY_START_MONTH = 1 [RW]
DPT {i} BidCos-RF.NEQ1408452:4.PARTY_START_YEAR = 0 [RW]
DPT {i} BidCos-RF.NEQ1408452:4.PARTY_STOP_TIME = 0 [RW]
DPT {i} BidCos-RF.NEQ1408452:4.PARTY_STOP_DAY = 1 [RW]
DPT {i} BidCos-RF.NEQ1408452:4.PARTY_STOP_MONTH = 1 [RW]
DPT {i} BidCos-RF.NEQ1408452:4.PARTY_STOP_YEAR = 0 [RW]
Ich glaube Wernieman meinte den Konfigpoint (Ich nenne es jetzt mal so)
R-HM-TC-IT-WM-W-EU.BUTTON_LOCK
Diesen kann man auslesen, theoretisch auch schreiben, wenn er denn nicht readonly ist.
das ist ja das was man auch in get configlist sieht
Zitat von: chris1284 am 12 Januar 2017, 13:31:48
EDIT: Antowrt aus HM -Forum
Zitatdas geht mit dem setParam.tcl-Script, min. BUTTON_LOCK boolean 0 MODUS_BUTTON_LOCK boolean 0 kann man damit setzen und aufheben...
Da ich mit der Homatic CCU2 absolut keine Erfahrung habe, kann ich mir der Info nicht wirklich viel anfangen, sorry.
Ich wollte auch so wenig wie möglich auf der CCU2 rumfummeln und überwiegend in Fhem arbeiten, nur dass was Fhem in Verbindung mit HMLAN nicht kann (z.B. FW-Updates, HM-IP) soll die CCU2 übernehmen.
Von daher würde ich für etwas Hilfe dankbar sein.
Einzig der Pfad des Scripts "setparam.tcl" (/usr/local/) ist mir bekannt. Das war es auch schon.
Gruß
Rubinho
Der Datapoint, um die Bedienung zu locken, lautet INHIBIT.
Zitat von: Loredo am 12 Januar 2017, 16:53:31
Der Datapoint, um die Bedienung zu locken, lautet INHERIT.
Ich muss Dich korrigieren: INHIBIT (Kanal 0).
Um also ein mit HMCCUDEV definiertes Thermostat zu sperren, kann man das machen:
set xyz datapoint 0.INHIBIT 1
oder:
attribute xyz eventMap /datapoint 0.INHIBIT 1:lock/datapoint 0.INHIBIT 0:unlock/
set xyz lock
set xyz unlock
Grundsätzlich müsste es über die Config-Parameter auch gehen. Allerdings ist GLOBAL_BUTTON_LOCK möglicherweise readonly. Leider sind die Config-Parameter nicht dokumentiert. Einige Devices implementieren eine Methode, mit der man eine Kurzbeschreibung auslesen kann. Das entspricht in HMCCUDEV dem Befehl get configdesc. Leider ist dies bei Thermostaten nicht implementiert.
Eine gute Infoquelle sind die Geräteeinstellungen in der CCU. Dort kann man Haken bei 3 verschiedenen Locks setzten. Insofern müsste
set xyz config GLOBAL_BUTTON_LOCK=1
funktionieren. Kann es aber momentan nicht testen, da ich dabei gerade in der neuen Version hier einen echt üblen Bug gefunden habe ;-)
Zitat von: zap am 12 Januar 2017, 18:31:17
Eine gute Infoquelle sind die Geräteeinstellungen in der CCU. Dort kann man Haken bei 3 verschiedenen Locks setzten. Insofern müsste
set xyz config GLOBAL_BUTTON_LOCK=1
funktionieren. Kann es aber momentan nicht testen, da ich dabei gerade in der neuen Version hier einen echt üblen Bug gefunden habe ;-)
@ZAP
Jep den Befehl hab ich schon getestet. Der wird von Fhem sogar akzeptiert, jedoch wird nix in die CCU2 geschrieben und bei einem
get xyz config GLOBAL_BUTTON_LOCK kommt auch wieder direkt eine 0.
Das müsste doch gehen, ich werd verrückt. :o
Hast Du den Tipp weiter oben probiert?
set datapoint 0.INHIBIT 1
Zitat von: zap am 12 Januar 2017, 20:31:16
set datapoint 0.INHIBIT 1
bringt nichts, das reading ändet sich aber mehr nicht. weder beim rt noch beim wandthermostat. aktiviert man den lock am rt ändert sich das reading auch nicht.
es gibt insgesamt auch 3 modi des btnlock
btnLock = BUTTON_LOCK
globalBtnLock = GLOBAL_BUTTON_LOCK
modusBtnLock = MODUS_BUTTON_LOCK
edit:
wäre das ein script für die ccu2 , wenn ka wo/wie ausführen?
string addr = dom.GetObject("az_hz").Address();
system.Exec("tclsh /usr/local/setparam.tcl "#addr#" BUTTON_LOCK boolean 1");
AFAIK lassen sich die Button Locks am Gerät selbst aktivieren und deaktivieren, das findet auch der Nachwuchs raus. INHIBIT geht nur über die Station. Die Übertragung kann aber etwas dauern
Sent from my iPad using Tapatalk
Zitat von: Loredo am 12 Januar 2017, 22:24:26
AFAIK lassen sich die Button Locks am Gerät selbst aktivieren und deaktivieren, das findet auch der Nachwuchs raus. INHIBIT geht nur über die Station. Die Übertragung kann aber etwas dauern
Sent from my iPad using Tapatalk
Den Modus den du beschreibst ist der Global_Button_Lock, dieser lässt sich nur über die Software (Fhem oder CCu2) freischalten.
INHIBIT hat bei mir ausser das Ändern des Readings keine Auswirkung. Es wird nichts gesperrt.
dazu finde ich hier die aussage ganz gut http://homematic-forum.de/forum/viewtopic.php?t=28125&p=250060
diese parameter sind wohl nicht über die channel verfügbar (set <> datapoint 0.xxx 4.xxx sollte somit garnicht gehen)
ich setzte erfolgreich den buttonlock via programm auf der ccu2 das ich über die hmccu starte
Zitatset ccu execute btn_lock
das script im programm ist folgendes (az_hz ist durch euren gerätenamen zu ersetzen)
var stdout;
var stderr;
string addr = dom.GetObject("az_hz").Address();
system.Exec("tclsh /usr/local/setParam.tcl "#addr#" BUTTON_LOCK boolean 1",&stdout,&stderr);
WriteLine(stdout);
WriteLine(stderr);
die setParam.tcl muss unter /usr/local/ auf der ccu abgelegt werden (per winscp / shh zB). (quelle http://homematic-forum.de/forum/viewtopic.php?t=5621)
#
# Aufruf für ein putParamset (z.B. via system.Exec)
# =================================================
# von Oliver Wagner <owagner@vapor.com>
#
# tclsh setparam <addresse> <item> <datentyp> <wert>
# z.B.
# tclsh setparam GEQ004711:2 MODE_TEMPERATUR_REGULATOR int 1
#
# Diese Version ist fuer Funk. Fuer Wired muss unten der Port von 2001 auf 2000 geaendert werden.
#
load tclrpc.so
set item [lindex $argv 1]
set datatype [lindex $argv 2]
set val [lindex $argv 3]
set cmd "{$item {$datatype $val}}"
xmlrpc http://127.0.0.1:2001/ putParamset [list string [lindex $argv 0]] [list string "MASTER"] [list struct $cmd]
wenn jemand weiss wie man einem ccu scritp parameter übergibt wäre ich dankbar, so könnte man dem script einfach den namen des gerätes mitgeben statt diesen fest im script zu haben (um nicht für jeden rt ein script bauen zu müssen)
es müsste auch ohne gehen denn ist xmlrpc nicht die ccu2 rpc-schnittstelle die hmccu eh verwendet???
Das xmlrpc gibt es auch für jeden Linux-Rechner, z.B. durch installieren von apt install libxmlrpc-core-c3-dev
Entsprechend könntest Du mal probieren, ob die Zeile auch von Deinem PC aus funktioniert:
xmlrpc http://127.0.0.1:2001/ putParamset [list string [lindex $argv 0]] [list string "MASTER"] [list struct $cmd]
Kann es nur aktuell nicht Probieren .. und wegen Oberleitungssturmschaden bei der Bahn (in Leipzig) weiß ich nicht, wann ich heute "zu Hause" bin
In diesem Fall ist xmlrpc ein TCL Befehl. Witzigerweise macht ein set config in HMCCU nichts anderes.
Aufrufparameter für hmscript werde ich noch einbauen.
Sobald meine eigene Installation wieder läuft, teste ich mal ausgiebig
Also: Man kann die Config-Parameter setzen. Man muss aber den richtigen Datentyp verwenden:
set config BUTTON_LOCK=true
set config BUTTON_LOCK=false
Gleiches für GLOBAL_BUTTON_LOCK.
Leider spiegelt sich die Änderung nicht in den Einstellungen im CCU WebUI wieder. Bei Abfrage mit get configlist wird jedoch der geänderte Wert angezeigt (witzigerweise als 0/1). Könnte daran liegen, dass die CCU Änderungen an Config-Parametern mitunter zeitversetzt an das Gerät überträgt.
Zitat von: zap am 13 Januar 2017, 13:17:39
Könnte daran liegen, dass die CCU Änderungen an Config-Parametern mitunter zeitversetzt an das Gerät überträgt.
die konfig über ccu gesetzt ist sofort am rt aktiv. an der ccu ist auch sofort der haken gesetzt (per set ccu execute btn_lock)
Habe den Parameter beim Wandthermostat gesetzt aber beim Heizkörper überprüft. Blöd.
Also: Sowohl beim Heizkörper als auch beim Wandthermostat kann man wie folgt die Bedienung sperren oder freigeben. Reaktion erfolgt praktisch sofort:
set config BUTTON_LOCK=true/false
set config GLOBAL_BUTTON_LOCK=true/false
die erste Variante kann man am Gerät rückgängig machen, die zweite nur per HMCCU oder CCU Webfrontend.
Einfach Mist, dass EQ-3 den Kram nicht dokumentiert.
Wofür ist denn dann INHIBIT? Verstehe ich nicht.
Zitat von: Loredo am 13 Januar 2017, 16:41:24
Wofür ist denn dann INHIBIT? Verstehe ich nicht.
Ja das wüsste ich auch gern. Ich konnte jedenfalls keine Änderung auf dem HM Device feststellen.
@zap
Erstmal ein großes Dankeschön, auf true/false muss man erstmal kommen, vorallem da in der Konfig 0/1 steht :o
Und ich geb dir recht, EQ3 könnte da mehr dokumentieren. Das ist ja wie im drüben zu fischen.... :-\
Zitat von: zap am 13 Januar 2017, 13:17:39
Leider spiegelt sich die Änderung nicht in den Einstellungen im CCU WebUI wieder. Bei Abfrage mit get configlist wird jedoch der geänderte Wert angezeigt (witzigerweise als 0/1). Könnte daran liegen, dass die CCU Änderungen an Config-Parametern mitunter zeitversetzt an das Gerät überträgt.
Also bei mir wird der geänderte Wert im Webui angezeigt, nur halt nicht in Echtzeit. Man muss die Seite (Geräteeinstellung) neu laden und die Änderung wird sichtbar.
Ich habe gerade HMCCU Version 3.7 eingecheckt.
Neues/Änderungen
- HMCCU unterstützt jetzt (theoretisch) mehrere CCUs. Wenn jemand mehrere CCUs hat, kann er das ja mal testen. Was nicht geht: Mehrere IO Devices für die gleiche CCU definieren.
- Neuer Kommandozeilenparameter für Define Befehle in HMCCUCHN und HMCCUDEV: Mit iodev=<name> wird der Name des zuständigen IO-Device explizit festgelegt. Falls mehrere CCUs verwendet werden und dieser Parameter nicht angegeben wird, sucht HMCCU selbstständig nach dem IO-Device der CCU, an der das Device angelernt wurde, das definiert werden soll.
- Alle Get-, Set- und Define-Befehle nutzen nun ParseParams(), d.h. es können Parameter mit Leerzeichen übergeben werden, indem man die Parameter in doppelte Hochkomma einschließt.
- Mit dem neuen Attribut "substdefaults" im IO Device können Default-Regeln für die Ersetzung von Reading-/Datenpunkt-Werten festgelegt werden. Das erspart das Festlegen von Ersetzungsregeln für häufig genutzte Datenpunkte wie z.B. LOWBAT in den einzelnen Devices. Die Syntax entspricht der des Attributes "substitute". Wenn "substdefaults" nicht gesetzt wird, ist die Vorgabe "LOWBAT,UNREACH!(0|false):no,(1|true):yes".
- Das Attribut "ccureadingname" in HMCCUDEV und HMCCUCHN wurde erweitert. Wenn der neue Readingname mit einem "+" beginnt, wird dieses Reading zusätzlich erzeugt, d.h. das alte wird beibehalten. Beispiel: Mit "LOWBAT:+battery" erhält man zwei Readings.
- Für jedes Device wird ab sofort ein Reading "hmstate" erzeugt. Wenn einer der Datenpunkte UNREACH, ERROR*, FAULT* oder LOWBAT eines Devices einen Wert > 0 hat, wird dieser Wert in "hmstate" übernommen. Die Priorisierung erfolgt nach o.g. Reihenfolge. Das Attribut "hmstatevals" legt fest, wie die Werte > 0 ersetzt werden. Die Syntax entspricht dem Attribut "substitute", jedoch ohne den Wert 0. Beispiel: "LOWBAT!1:battery_low;UNREACH!1:unreachable". Wenn keiner der o.g. Datenpunkte > 0 ist, wird der Wert von "state" in "hmstate" übernommen.
- Die Datenpunkte LOWBAT/LOW_BAT und UNREACH werden immer als Readings gespeichert. Ein Angabe im Attribut "ccureadingfilter" ist nicht mehr erforderlich.
- In HMCCUConf.pm wurden neue Attribut-Templates für weitere Gerätetypen ergänzt. Eine Übersicht erhält man mit dem Befehl "get defaults" im IO Device.
- HMCCU unterstützt nun Geräte des CCU2 Homegear-Addons. Die Unterstützung ist noch experimentell. Die Homegear Module PING und SONOS habe ich getestet. Bei letzterem gibt es noch Bugs auf Homegear Seite, die die Nutzbarkeit stark einschränken. Die Innen- und Außenkameras konnte ich noch nicht testen. Für eine automatische Aktualisierung der Datenpunkte muss das Attribut "rpcport" im IO-Device um den Wert 2003 ergänzt werden.
Behobene Fehler
- Attribut-Templates mit mehr als einem Gerätetyp wurden nicht gefunden.
- Syntax Fehler im Attribut substitute führten u.U. zum Absturz von FHEM.
- Bei HMCCUCHN Devices wurden bei "get update" die Datenpunkte von Kanal 0 nicht aktualisiert.
- Wenn für ein CCU Gerät zwei FHEM Geräte angelegt wurden, konnte es zu fehlerhaften Berechnungen beim Skalieren von Reading-Werten kommen.
- Der Aufruf der Funktion usleep() wurde entfernt. Damit entfällt die Notwendigkeit für das Modul Timer::HiRes.
Zitat von: zap am 13 Januar 2017, 13:17:39
set config BUTTON_LOCK=true
set config BUTTON_LOCK=false
Gleiches für GLOBAL_BUTTON_LOCK.
Gleiches für MODUS_BUTTON_LOCK (sperrt den wechsel des modus)
und nochmal ein Update für 88_HMCCU.pm hinterher ...
Kleiner Bug in "substexcl" gefixt.
ZitatWenn "substdefaults" nicht gesetzt wird, ist die Vorgabe "LOWBAT,UNREACH!(0|false):no,(1|true):yes".
ähm kann man dieses default auch abstellen oder muss ich den default im device/channel überschreiben?
Zitat von: chris1284 am 13 Januar 2017, 19:18:27
ähm kann man dieses default auch abstellen oder muss ich den default im device/channel überschreiben?
d.h. Du möchtest die Rohwerte haben (0/1, false/true) ?
In dem Fall setze substdefaults im IO Device auf irgendwas sinnloses wie z.B. ZAPSBLOEDESDEFAULT!1:doof ;-)
ui, hier wäre doch ein attribut wie "usesubstdefaults 0/1" besser oder nicht weil deine "defaults" sind nun mal keine defaults sondern schon user-anpassungen
zu den templates habe ich noch eine frage
set <name> defaults würde die attribute aus HMCCUConf.pm in alle devices schreiben, habe ich das richtig verstanden?
ich habe eine HMCCUConf_personal.pm, wie kann ich die anbinden?
EDIT:"substdefaults im IO Device" erst als HMCCUDEV verstande, sry
Achtung! Die vor 19:45 Uhr eingecheckten Versionen von 88_HMCCUDEV und 88_HMCCUCHN sind verwanzt gewesen. Gerade nochmal neu eingecheckt.
@chris1284: Später mehr zu Deiner defaults Frage. Habe Hunger ;-)
kein problem iss dich satt, ruh dich aus ;D
was ich noch gut fände für das hmccuconf_template:
neben der chn und dev sektion eine global sektion wo man zb attribute definiert die alle bekommen sollen (bei mir zb verbose 1, room hm, usw usw)
was du in dem template noch auf nehmen kannst (habe die aktuelle version noch nicht, info basiert auf der alten)
HM-Sec-SC-2 in der sektion "HM-Sec-SCo|HM-Sec-SC"
für hmccudev (musst du noch anpassen da ich kein unreach nutze sowie batlow auf low setze und keine readingsfilter nutze)
Zitat
"HM-LC-Sw1-Ba-PCB" => {
_description => "1 Kanal Funk Schaltaktor für Batteriebetrieb",
ccureadingformat => "datapoint",
room => "HM",
statedatapoint => "1.STATE",
substitute => "STATE!1:on,0:off,false:off,true:on;LOWBAT!(0|false):ok,(1|true):low;",
verbose => 1
},
ZitatReadingname mit einem "+" beginnt, wird dieses Reading zusätzlich erzeugt
top, danke somit fliegen diverse userreadings raus
Kurze Noobfrage,
ich versuche gerade meine Heizungsgruppe in Fhem anzulegen, Diese besteht aus einem HM_CC_RT_DN und HM-TC-IT-WM-W-EU.
Die Namen sind wie folgt in der CCU angelegt worden ... TC_IT_WM_W_EU_Office, CC_RT_DN_Office. Der Gruppenname (INT0000001) hat in der CCU die Bezeichnung Office und das virtuelle Gerät heißt Group_HLK_Office1.
Wenn ich jetzt versuche die Gruppe mit folgenden Befehl händisch anzulegen.
define HM_Group_HLK_Office1 HMCCUDEV INT0000001 group=TC_IT_WM_W_EU_Office,CC_RT_DN_Office
Bekomme ich die Meldung
Invalid device or channel TC_IT_WM_W_EU_Office
Drehe ich die Geräte, steht dann, dass CC_RT_DN_Office in der Fehlermeldung.
Ich hab auch schon statt INT0000001 die Bezeichnung Group_HLK_Office1 genutzt. Das Ergebnis war das gleiche.
Jetzt zur Frage... :D
Was hab ich falsch gemacht.
Versuch erst mal, für eines der Geräte ein normales Device anzulegen, zB
define testtherm HMCCUDEV TC_IT....
Wenn das die gleiche Meldung kommt, mach mit dem IO Dev mal ein "get devicelist" und versuche es nochmal
Zitat von: chris1284 am 13 Januar 2017, 19:31:49
set <name> defaults würde die attribute aus HMCCUConf.pm in alle devices schreiben, habe ich das richtig verstanden?
ich habe eine HMCCUConf_personal.pm, wie kann ich die anbinden?
set name defaults setzt nur die Attribute für "name". FHEM unterstützt aber Wildcards für set Befehle. Damit kann man dann mehrere Devices in einem Rutsch mit Defaults versorgen.
HMCCU unterstützt benutzerdefinierte Template Files. Du erstellst zunächst mit set exportdefaults eine solche Textdatei, passt sie nach Deinen Vorstellungen an und importierst sie wieder mit set importdefaults.
Damit die Datei beim Start von FHEM geladen wird, setzt Du das Attribut ccudefaults auf den Namen der Datei. Beim Setzen der Attribute mit set defaults schaut HMCCU zunächst Deine selbst definierten Attribute durch. Nur wenn da nichts passt, sucht es in HMCCuConf.pm.
Damit du deine Arbeit nicht nochmal machen musst, kannst Du versuchen, die HMCCUConf.pm durch Deine Datei zu ersetzen und danach mit set exportdefaults eine Textdatei zu erzeugen. Dann kopierst Du die Orginal .pm wieder an ihren Platz und kannst die erstellte Textdatei mit attr ccudefaults einbinden
Die Einzelgeräte sind ja schon angelegt. (Via Autocreate)
Ich hab sie aber nochmal gelöscht und auch erfolgreich händisch angelegt.
Daran liegts also nicht.
Ach Verdammt, ich hab den Namen von Fhem genommen und Fhem mag doch keine Bindestriche.
Da die CCU-Beschriftung Bindestriche hat und mir es nicht aufgefallen ist, kannte er das Gerät natürlich nicht.
Fhem-Name TC_IT_WM_W_EU_Office
CCU-Name TC-IT-WM-W-EU_Office
Es geht jetzt :-[
Sry, Jungs
Zitat von: zap am 13 Januar 2017, 21:22:19
Damit du deine Arbeit nicht nochmal machen musst, kannst Du versuchen, die HMCCUConf.pm durch Deine Datei zu ersetzen und danach mit set exportdefaults eine Textdatei zu erzeugen.
das geht, man muss nur fhem neustarten damit die manipulierte HMCCUConf.pm eingelesen wird.
man sollte in der datei allerdings keine userreadings mit perlfunktionen haben...
Zitat2017.01.14 08:58:45 1: reload: Error:Modul 88_HMCCU deactivated:
syntax error at FHEM/HMCCUConf.pm line 114, near ""color { ReadingsVal(""az_rgbw_01""
Compilation failed in require at ./FHEM/88_HMCCU.pm line 91, <DATA> line 1.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 91, <DATA> line 1.
2017.01.14 08:58:45 0: syntax error at FHEM/HMCCUConf.pm line 114, near ""color { ReadingsVal(""az_rgbw_01""
Compilation failed in require at ./FHEM/88_HMCCU.pm line 91, <DATA> line 1.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 91, <DATA> line 1.
Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 134, <$fh> line 67.
das habe ich entfertn, danach lief der export mit meinen werten sauber. das textfile habe ich dann per attr ccudefaults /opt/fhem/HMCCU_templ/myHMCCUdefaults eingebunden.
leider hat er keine attribute hinzugefügt nach dem ich neugestartet hatte.
danach einen importdefaults an einem device, das funktioniert, meine defaults werden geladen
ist es evtl gewollt das die default nicht beim star tgeladen werden und auf alle devices gebügelt?
schade ist auch das bei set defaults nicht andere , in der vorgabe nicht defininierte, hmccu-atrribute gelöscht werden.
zb wenn ein device attr ccureadings 1 hat, dieses in dern defaults nicht gelistet ist, dann sollte es gelöscht werden. hilfreich um in bestehenden systemen die attribute aufzuräumen und zu vereinheitlichen
beim export kann man aktuell keinen pfad angeben?! ich habe es relativ zum fhem-root und absolut probiert (cant open file meldung jeweils)
Zum Thema benutzerdefinierte Templates empfehle ich folgende Vorgehensweise (im Beispiel heißt das IO Device "ccu"):
- Export der Default Templates in eine Datei mit dem Befehl "get ccu exportdefaults /opt/fhem/FHEM/hmccutemp.cfg". Verzeichnis und Dateiname können frei gewählt werden. Allerdings muss der Unix-User fhem Schreibrechte haben. Ich empfehle das FHEM Verzeichnis (s.o.), da man dann die erstellte Datei über die FHEM Oberfläche editieren kann.
- Anhand der exportierten Datei sieht man die Syntax, die sich stark an das Format in HMCCUConf.pm anlehnt, allerdings nicht identisch ist (es ist eben eine Textdatei, kein Perl-Modul)
- Anpassen der exportierten Datei an die eigenen Bedürfnisse
- Laden der geänderten Datei in das IO Device mit dem Befehl "attr ccu ccudefaults /opt/fhem/FHEM/hmccutemp.cfg". Für einen einmaligen Import (z.B. für Tests) kann man auch den Befehl "set ccu importdefaults /opt/fhem/FHEM/hmccutemp.cfg" verwenden. Die so importierten Templates "vergisst" HMCCU aber beim nächsten Neustart wieder.
- Prüfen, ob das IO Device die neuen Templates kennt mit dem Befehl "get ccu defaults". Die benutzerdefinierten Attribute werden am Ende aufgelistet.
Für diejenigen, die sich ein eigenes Perl Modul durch Anpassung von HMCCUConf.pm erstellt haben, schlage ich folgende Vorgehensweise vor:
- Export der Templates wie oben beschrieben.
- Einbinden der Exportdatei wie oben beschrieben mit attr ccudefaults
- FHEM Update um die Standard HMCCU-Module wieder zu laden
Templates mit Perl-Code:In einer benutzerdefinierten Template-Datei sollte Perl-Code keine Probleme machen. Wenn man hingegen HMCCUConf.pm anpasst, muss man Perl-Sonderzeichen wie "$" oder "{" usw. mit einem "\" escapen. Aber davon sollte man absehen und die o.g. Methode der benutzerdefinierten Templates verwenden.
@chris1284: Das Löschen von Attributen, die nicht Bestandteil des Templates sind, dürfte nicht bei jedem Nutzer gut ankommen. Man könnte es aber per Option im Befehl "set defaults" erlauben. Dann kann jeder selbst entscheiden. Ich setze es auf die Liste für die nächste Version.
irendwas stimmt mit hmmcu nicht. ich lösche bei einer handvoll devices attribute, speichere, starte neu und die attribute sind wieder da!
es betrifft attr DbLogExclude * und nur hmccu geräte die bereits im bestand sind. heute habe ich einen wt angelernt, dieser zeigt das verhalten nicht.
wo cached hmccu die einstellungen? cleardefaults hat nichts gebracht
Structure? Structexclude ist dein Freund :)
Gruß
Julian
Danke, tatsache. die structure gelöscht, alle attribute dazu in devices gelöscht -> reboot alles gut.
wo ist den dieses verhalten näher beschrieben? den sinn / hintergrund verstehe ich noch nicht
cmd-ref
Zitatstructexclude
Bei gesetztem Attribut wird set, attr/deleteattr ignoriert.
das war aber nicht gesetzt, deswegen irritiert es mich ein wenig
Kurzum: structure konsolidiert nicht nur buttom-up den Status von Devices, sondern ermöglicht gleichzeitig auch top-down deren gemeinsame Konfiguration. Alle(?) Attribute, die an der Structure definiert sind, werden auch nach unten weitergereicht. Das kann verwirrend sein, wenn man während des Betriebs die Attribute an den untergeordneten Devices selbst anpasst, nicht aber in der Structure. Die Structure vererbt ihre Attribute nur wenn man diese dort neu setzt glaube ich, auf jeden Fall aber immer, wenn die Structure bei einem Neustart initialisiert wird.
Man kann das verschieden beeinflussen:
1. man nutzt Attribute nur an den untergeordneten Devices und hat diese nicht in der Structure definiert -> Attribute bleiben wie sie sind
2. man nutzt Attribute in der Structure -> werden vererbt
3. man nutzt Attribute in der Structure und möchte die gleichen Attribute bei den untergeordneten Devices anders und/oder unterschiedlich belegen -> Attribut in structexclude der jeweiligen untergeordneten Devices aufnehmen. Wenn diese sich nicht unterscheiden sollen, kann man structexclude auch in der Structure selbst setzen und nach unten vererben. Auch structexclude wird dann vererbt. Wenn man das nicht will, muss man auch structexclude selbst mit in das structexclude Value schreiben.
Structures mit HMCCU sind u.U. deutlich komplexer, wenn man dort nicht nur HMCCU Geräte zusammenfassen will, da man die Readingnamen zunächst auf einen einheitlichen (FHEM)Standard bringen muss. Entweder über die Attribute clientstate_priority und <struct_type>_map, die structure verwaltet, oder über die vielen Möglichkeiten von HMCCU selbst.
Das ist einer der Gründe, weshalb ich hier seit langem predige, dass HMCCU eine Möglichkeit braucht es Menschen einfacher zu machen seine komplexen Attribute anständig zu benutzen, ohne zuvor eine Doktorarbeit darüber zu schreiben. Auf mich hört ja keiner ::)
Ich werde bald nochmal einen letzten Versuch starten aus meiner Sicht vernünftige Default-Settings hier zu posten, die allgemein gültig sein sollten. Ob die dann jeder einfach benutzen können soll oder ob jeder weiterhin dann Stunden und Tage damit verbringen muss FHEM, HMCCU (und eq-3 mit seinen Datapoints) richtig zu verstehen, bleibt dann unserem Modulautor überlassen.
Zitat von: Loredo am 15 Januar 2017, 11:01:51
Das ist einer der Gründe, weshalb ich hier seit langem predige, dass HMCCU eine Möglichkeit braucht es Menschen einfacher zu machen seine komplexen Attribute anständig zu benutzen, ohne zuvor eine Doktorarbeit darüber zu schreiben. Auf mich hört ja keiner ::)
Ich finde schon, dass ich bei der aktuellen Version auf dich gehört habe ;-)
Zitat
Ich werde bald nochmal einen letzten Versuch starten aus meiner Sicht vernünftige Default-Settings hier zu posten, die allgemein gültig sein sollten. Ob die dann jeder einfach benutzen können soll oder ob jeder weiterhin dann Stunden und Tage damit verbringen muss FHEM, HMCCU (und eq-3 mit seinen Datapoints) richtig zu verstehen, bleibt dann unserem Modulautor überlassen.
Du kannst Dir das Leben schon mal erleichtern, indem Du im IO Device das Attribut substdefaults nach Deinen Wünschen setzt. Damit hast Du schon mal einheitliche Readingwerte. Das greift bei allen Client Devices.
Einen globalen Default Setter für Readingnames werde ich auch noch bereitstellen (hatte ich nicht mehr in der 3.7 geschafft). Mit diesen beiden Attributen, die du nur einmal setzen musst, kannst Du alle Readings nach deinen Wünschen beeinflussen.
Bzgl. der Datenpunkte wird dir aber auch zukünftig ein Blick in die EQ-3 Doku nicht erspart bleiben, wenn die Verwendung unklar ist, kein Template existiert oder die Templates nicht deinen Wünschen entsprechen.
Zitat von: zap am 15 Januar 2017, 11:20:46
Ich finde schon, dass ich bei der aktuellen Version auf dich gehört habe ;-)
A bisserl, ja ;)
*thumbsUp*Zitat von: zap am 15 Januar 2017, 11:20:46
Du kannst Dir das Leben schon mal erleichtern, indem Du im IO Device das Attribut substdefaults nach Deinen Wünschen setzt.
Danke, das ist ein guter Hinweis. Ich habe eine Zeitlang nicht mitgelesen hier (hier ist einfach zu viel los und die Themen sind leider viel zu divers; solch wichtige Dinge gehen hier schnell unter). Allerdings sehe ich das etwas Zwiegespalten, denn wollte man die Templates in der HMCCUConf.pm verbessern (und das ist ja das, wovon ich die ganze Zeit rede), dann müsste man dort eigentlich pro Device das substitude Attribut mitgeben, weil man sonst voraussetzte, dass substdefaults schon entsprechend richtig gesetzt sein muss. Gleichwohl finde ich es gut die Dopplungen zu vermeiden und diese allgemeinen Mappings zentral zu definieren.
Ich habe substdefaults jetzt mal gesetzt und mixe es für STATE mit einer zusätzlichen substitute Definition in den Devices.
Zitat von: zap am 15 Januar 2017, 11:20:46
Einen globalen Default Setter für Readingnames werde ich auch noch bereitstellen (hatte ich nicht mehr in der 3.7 geschafft).
Das ist super! Genau das fehlt eben noch, bevor es anfängt nützlich zu werden.
Danach fehlen IMHO noch 2 Dinge:
1. Die Auswertung der Readings, um daraus ein FHEM-kompatibles Status Reading zu generieren. Ich hatte dazu ja bereits per PM Vorschläge für ein Reading "stateHM" gemacht und darum gebeten eine Funktion in HMCCU direkt einzubauen, weil die Informationen da effizienter bereitstehen statt über eine Custom-Funktion in Verbindung mit userReadings.
sub myHMCCUstate($;$) {
# based on: HomeMatic-Script Dokumentation, Teil 4: Datenpunkte V1.0
my ( $name, $reverseOnOff ) = @_;
my $p = myHMCCUreadingsToHash($name);
my $stateHM;
# eval error parameters
if ( defined( $p->{UNREACH} ) && $p->{UNREACH} =~ /^(1|true|dead)$/i ) {
$stateHM = "unreachable";
}
elsif ( defined( $p->{FAULT_REPORTING} )
&& $p->{FAULT_REPORTING} !~ /^(0|NO_FAULT|4|COMMUNICATION_ERROR|6|LOWBAT)$/i )
{
$stateHM = "err_f_" . $p->{FAULT_REPORTING};
}
elsif ( defined( $p->{ERROR_OVERHEAT} )
&& $p->{ERROR_OVERHEAT} =~ /^(1|true)$/i )
{
$stateHM = "err_overheated";
}
elsif ( defined( $p->{ERROR_OVERLOAD} )
&& $p->{ERROR_OVERLOAD} =~ /^(1|true)$/i )
{
$stateHM = "err_overloaded";
}
elsif ( defined( $p->{ERROR_REDUCED} )
&& $p->{ERROR_REDUCED} =~ /^(1|true)$/i )
{
$stateHM = "err_reduced";
}
elsif ( defined( $p->{ERROR} ) && $p->{ERROR} !~ /^(0|NO_ERROR)$/i ) {
$stateHM = "err_" . $p->{ERROR};
}
# eval operational parameters
elsif ( defined( $p->{INHIBIT} )
&& $p->{INHIBIT} =~ /^(1|true|locked)$/i )
{
$stateHM = "locked";
}
elsif ( defined( $p->{DIRECTION} )
&& $p->{DIRECTION} !~ /^(0|NONE|stop)$/i )
{
$stateHM = "undefined";
if ( $p->{DIRECTION} =~ /^(1|UP)$/i ) {
$stateHM = "up";
}
elsif ( $p->{DIRECTION} =~ /^(2|DOWN)$/i ) {
$stateHM = "down";
}
}
elsif ( defined( $p->{WORKING} )
&& $p->{WORKING} !~ /^(0|false)$/i )
{
$stateHM = "working";
}
# eval state parameters
elsif ( defined( $p->{MOTION} ) ) {
$stateHM = "noMotion";
$stateHM = "motion" if ( $p->{MOTION} =~ /^(1|true|motion)$/i );
}
elsif ( defined( $p->{LEVEL} ) ) {
$stateHM = $p->{LEVEL};
if ($reverseOnOff) {
$stateHM = "off"
if ( $stateHM eq "100" );
$stateHM = "on"
if ( $stateHM eq "0" );
}
else {
$stateHM = "off"
if ( $stateHM eq "0" );
$stateHM = "on"
if ( $stateHM eq "100" );
}
$stateHM = $p->{stateHM}
if ( defined( $p->{stateHM} ) && $p->{LEVEL} > 100 );
}
elsif ( defined( $p->{STATE} ) ) {
# cannot reliably be translated into text value
# -> custom rewrite via FHEM device attributes required
$stateHM = $p->{STATE};
}
elsif ( defined( $p->{VALVE_STATE} ) ) {
$stateHM = $p->{VALVE_STATE};
}
elsif ( defined( $p->{ACTUAL_TEMPERATURE} ) ) {
$stateHM = $p->{ACTUAL_TEMPERATURE};
}
elsif ( defined( $p->{CONTROL_MODE} ) ) {
$stateHM = $p->{CONTROL_MODE};
}
elsif ( defined( $p->{TEMPERATURE} ) || defined( $p->{HUMIDITY} ) ) {
$stateHM .= "T: " . $p->{TEMPERATURE} . " "
if ( defined( $p->{TEMPERATURE} ) );
$stateHM .= "H: " . $p->{HUMIDITY} . " "
if ( defined( $p->{HUMIDITY} ) );
$stateHM .= "W: " . $p->{WIND_SPEED} . " "
if ( defined( $p->{WIND_SPEED} ) );
$stateHM .= "R: " . $p->{RAIN_COUNTER} . " "
if ( defined( $p->{RAIN_COUNTER} ) );
$stateHM .= "IR: " . $p->{RAINING} . " "
if ( defined( $p->{RAINING} ) );
$stateHM .= "WD: " . $p->{WIND_DIRECTION} . " "
if ( defined( $p->{WIND_DIRECTION} ) );
$stateHM .= "WDR: " . $p->{WIND_DIRECTION_RANGE} . " "
if ( defined( $p->{WIND_DIRECTION_RANGE} ) );
$stateHM .= "S: " . $p->{SUNSHINEDURATION} . " "
if ( defined( $p->{SUNSHINEDURATION} ) );
$stateHM .= "B: " . $p->{BRIGHTNESS} . " "
if ( defined( $p->{BRIGHTNESS} ) );
}
# eval warning parameters
elsif ( defined( $p->{FAULT_REPORTING} )
&& $p->{FAULT_REPORTING} =~ /^(6|LOW_?BAT)$/i )
{
$stateHM = "warn_battery";
}
elsif ( defined( $p->{LOW_BAT} )
&& $p->{LOW_BAT} =~ /^(1|true|low)$/i )
{
$stateHM = "warn_battery";
}
elsif ( defined( $p->{LOWBAT} )
&& $p->{LOWBAT} =~ /^(1|true|low)$/i )
{
$stateHM = "warn_battery";
}
# default value
elsif ( defined( $p->{UNREACH} ) && $p->{UNREACH} !~ /^(1|true|dead)$/i ) {
$stateHM = "ok";
}
else {
$stateHM = "Initialized";
}
return $stateHM;
}
sub myHMCCUreadingsToHash ($) {
my ($name) = @_;
my $d = $defs{$name};
my $r;
my $rmap = {
Activity => 'UNREACH',
controlMode => 'CONTROL_MODE',
direction => 'DIRECTION',
humidity => 'HUMIDITY',
level => 'LEVEL',
locked => 'INHIBIT',
'measured-temp' => 'ACTUAL_TEMPERATURE',
motion => 'MOTION',
motor => 'DIRECTION',
pct => 'LEVEL',
temperature => 'TEMPERATURE',
valve => 'VALVE_STATE',
};
if ( defined($d) && defined( $d->{READINGS} ) ) {
foreach ( keys %{ $d->{READINGS} } ) {
my $n = $_;
$n = $rmap->{$_} if ( $rmap->{$_} );
$r->{$n} = $d->{READINGS}{$_}{VAL}
if ( defined( $d->{READINGS}{$_}{VAL} ) );
}
}
return $r;
}2. Für Datenpunkte, bei denen der Zweck eindeutig global über die eq-3 Doku zu ermitteln ist, sollte HMCCU die Attribute entsprechend sinnvoll vorbelegen. Derzeit kann man z.B. gefahrlos bei jedem HMCCUDEV/HMCCUCHN Device diese Settings setzen und erhält damit endlich die FHEM Kompatibilität:
ccureadingformat datapoint
ccureadingname ^.*ACTUAL_TEMPERATURE$:measured-temp,^.*AES_KEY$:sign,^.*BRIGHTNESS$:brightness,^.*CONTROL_MODE$:controlMode,^.*DIRECTION$:direction,^.*ENERGY_COUNTER$:energy,^.*FREQUENCY$:frequency,^.*HUMIDITY$:humidity,^.*INHIBIT$:lock,^.*LEVEL$:pct,^.*LOW[_]?BAT$:battery,^.*MOTION$:motion,^.*POWER$:power,^.*SET_TEMPERATURE$:desired-temp,^.*TEMPERATURE$:temperature,^((.*\.)?\d\.+)?UNREACH$:Activity,^.*VALVE_STATE$:valve,^.*VOLTAGE$:voltage,^.*WORKING$:working,^\d\.+:,
substitude AES_KEY!(1|true):on,(0|false):off;DIRECTION!(none|0):none,(up|1):up,(down|2):down,.*:undefined;INHIBIT!(false|0):unlocked,(true|1):locked;LOWBAT,LOW_BAT!(false|0):ok,(true|1):low;MOTION!(false|0):noMotion,(true|1):motion;UNREACH!(false|0):alive,(true|1):dead;WORKING!(false|0):false,(true|1):true
stateFormat stateHM
userReadings stateHM:^(?!stateHM).* { return myHMCCUstate($name); }
(Ich taste mich da aktuell aber selbst gerade noch - eben mühsam - vor die FHEM Standards teils zu ermitteln und mit der eq-3 Datenpunkt-Doku in Einklang zu bringen)
Aber warum sich jeder HMCCU Nutzer diese Erkenntnisse erst selbst mühsam durch lesen und verstehen(!) der CommandRef sowie der eq-3 Datenpunkt-Doku erarbeiten muss, erschließt sich mir eben gar nicht. Die sollte man nur zur Hilfe nehmen müssen, wenn es wirklich was ganz neues gibt oder man eben weiß was man tut und warum man dann etwas anders konfigurieren will.
Zitat von: zap am 15 Januar 2017, 11:20:46
Bzgl. der Datenpunkte wird dir aber auch zukünftig ein Blick in die EQ-3 Doku nicht erspart bleiben, wenn die Verwendung unklar ist, kein Template existiert oder die Templates nicht deinen Wünschen entsprechen.
Absolut richtig, das darf ja auch so sein ;)
Zitat von: zap am 13 Januar 2017, 17:59:41Ich habe gerade HMCCU Version 3.7 eingecheckt.
Grad erst gesehen... mea culpa.
Zitat von: zap am 13 Januar 2017, 17:59:41
- Das Attribut "ccureadingname" in HMCCUDEV und HMCCUCHN wurde erweitert. Wenn der neue Readingname mit einem "+" beginnt, wird dieses Reading zusätzlich erzeugt, d.h. das alte wird beibehalten. Beispiel: Mit "LOWBAT:+battery" erhält man zwei Readings.
Sollte das auf eines meiner Feedbacks zurückzuführen sein wäre mir hier nicht ganz klar, wie ich jetzt das Reading umbenennen kann und gleichzeitig unter zwei anderen Namen erzeugen lasse..
(Beispiel: LEVEL -> pct+level)
Zitat von: zap am 13 Januar 2017, 17:59:41
- Für jedes Device wird ab sofort ein Reading "hmstate" erzeugt. Wenn einer der Datenpunkte UNREACH, ERROR*, FAULT* oder LOWBAT eines Devices einen Wert > 0 hat, wird dieser Wert in "hmstate" übernommen. Die Priorisierung erfolgt nach o.g. Reihenfolge. Das Attribut "hmstatevals" legt fest, wie die Werte > 0 ersetzt werden. Die Syntax entspricht dem Attribut "substitute", jedoch ohne den Wert 0. Beispiel: "LOWBAT!1:battery_low;UNREACH!1:unreachable". Wenn keiner der o.g. Datenpunkte > 0 ist, wird der Wert von "state" in "hmstate" übernommen.
Ähnlich hier: Wenn das auf mein PM Feedback zurückgehen sollte, ist der Sinn verfehlt, da sich die in meinem vorigen Post genannten Custom-Funktionen für stateHM nicht dadurch ersetzen lassen.
Nur die Errors zusammenzuführen (und die Zahlenwerte zu deuten) ist IMHO so gut wie sinnfrei, zumal du Fehler mit Warnungen vermischst (LOWBAT ist kein Fehler).
Ich hätte mich darüber gefreut, wenn du lieber nochmal bei mir nachgefragt hättest, ob du es richtig verstanden hast oder weshalb du meinst etwas weglassen zu müssen. Darüber hätte ich dann gerne diskutiert.
So entsteht jetzt das "friss oder stirb" Gefühl und meine Dankbarkeit hält sich eher in Grenzen.
Zitat von: zap am 13 Januar 2017, 17:59:41
- Die Datenpunkte LOWBAT/LOW_BAT und UNREACH werden immer als Readings gespeichert. Ein Angabe im Attribut "ccureadingfilter" ist nicht mehr erforderlich.
Verstehe ich nicht. Was ist daran neu? Wenn ich ccureadingfilter gar nicht gesetzt habe oder die Datenpunkte dort mit aufgenommen habe, dann wurden sie auch gespeichert. Werden sie jetzt also gespeichert, egal ob sie in ccureadingfilter aufgeführt sind? Da wird's jetzt aber inkonsistent, wenn du jetzt plötzlich von deiner Absicht abweichtest alles vollkommen flexibel und bloß ohne Bevormundung umzusetzen.
Versteh mich richtig, ich finde auch, dass diese Angaben essentiell für jedes Device sind. Aber es entspräche eben nicht mehr deiner eigens definierten Philosophie.
Zitat von: Loredo am 15 Januar 2017, 17:07:51
Sollte das auf eines meiner Feedbacks zurückzuführen sein wäre mir hier nicht ganz klar, wie ich jetzt das Reading umbenennen kann und gleichzeitig unter zwei anderen Namen erzeugen lasse..
(Beispiel: LEVEL -> pct+level)
ccureadingname LEVEL:+pct,LEVEL:+level => Ergibt 3 Readings LEVEL, pct und level
ccureadingname LEVEL:+pct,LEVEL:level => Ergibt 2 Readings pct und level
Im Fall von LEVEL => level hilft auch "ccureadingformat datapointlc" (lc für lower case)
Zitat
Ähnlich hier: Wenn das auf mein PM Feedback zurückgehen sollte, ist der Sinn verfehlt, da sich die in meinem vorigen Post genannten Custom-Funktionen für stateHM nicht dadurch ersetzen lassen.
Nur die Errors zusammenzuführen (und die Zahlenwerte zu deuten) ist IMHO so gut wie sinnfrei, zumal du Fehler mit Warnungen vermischst (LOWBAT ist kein Fehler).
Mit dem Reading hmstate in Kombination mit dem Attribut hmstatevals läßt sich m.E. Deine stateHM Funktion 1:1 abbilden. Dabei bleibt alles weitgehend frei konfgiurierbar, ohne eine Funktion mit endlosen if/elsif Konstrukten bauen zu müssen, die vielleicht beim nächsten EQ-3 Gerät oder Firmware Update nicht mehr funktioniert. Es gibt bei der Brechnung von hmstate eine Prioliste. LOWBAT als Warning steht ganz hinten in dieser Liste.
Zitat
So entsteht jetzt das "friss oder stirb" Gefühl und meine Dankbarkeit hält sich eher in Grenzen.
Vom Anspruch, es jedem recht zu machen und alle Anforderungen umzusetzen, habe ich mit schon vor vielen Berufsjahren verabschiedet ;-)
Zitat
Werden sie jetzt also gespeichert, egal ob sie in ccureadingfilter aufgeführt sind? Da wird's jetzt aber inkonsistent, wenn du jetzt plötzlich von deiner Absicht abweichtest alles vollkommen flexibel und bloß ohne Bevormundung umzusetzen.
Versteh mich richtig, ich finde auch, dass diese Angaben essentiell für jedes Device sind. Aber es entspräche eben nicht mehr deiner eigens definierten Philosophie.
Das Statement im HMCCU Code sieht so aus:
return 1 if ($cf !~ /nohmstate/ && $dpt =~ /(^UNREACH|^LOWBAT|^LOW_BAT|^ERROR|^FAULT)/);
Soll heißen, all diese Datenpunkte im Statement werden als Reading gespeichert. Sie werden benötigt, um hmstate zu ermitteln. Mit dem Attribut ccuflags = nohmstate kann man dieses Speichern verhindern, dann gibt es aber auch kein hmstate Reading.
Die Flexibilität bleibt also insofern gewahrt, als man über ccuflags das bisherige Verhalten wiederherstellen kann.
Hi,
ich habe irgendwie Ärger mit dem RPC Server - er scheint zwar zu laufen, aber er updatet nicht die Readings automatisch.
defmod d_ccu HMCCU homematic-ccu2
attr d_ccu alias HomeMatic CCU2
attr d_ccu room Schnittstellen
attr d_ccu rpcport 2001,2010
attr d_ccu rpcserver on
attr d_ccu stateFormat rpcstate/state
setstate d_ccu running/OK
setstate d_ccu 2017-01-17 19:15:07 rpcstate running
setstate d_ccu 2017-01-18 08:24:16 state OK
get rpcstate sagt "RPC Process not running"
RPCPID hat die Werte 4824,4825 und ps -ef sagt
root@fhem:~# ps -ef | grep 482
fhem 4824 4813 0 Jan17 ? 00:00:52 /usr/bin/perl fhem.pl fhem.cfg
fhem 4825 4813 0 Jan17 ? 00:00:50 /usr/bin/perl fhem.pl fhem.cfg
RPCState running
STATE running/OK
Ein ps -ef | grep ccurpcd ergibt auch, das kein entsprechender Process läuft
Ein set rpcserver on ergibt
2017.01.18 10:13:27 0: HMCCU: RPC server(s) already running with PIDs 4825,4824
ein set rpcserver restart ergibt
2017.01.18 10:14:07 1: HMCCU: Deregistering RPC server http://192.168.1.166:7420/fh2010 at http://homematic-ccu2:2010/
2017.01.18 10:14:07 1: HMCCU: Deregistering RPC server http://192.168.1.166:7411/fh2001 at http://homematic-ccu2:2001/
2017.01.18 10:14:07 0: HMCCU: Stopping RPC server CB2010 with PID 4825
2017.01.18 10:14:07 0: HMCCU: Stopping RPC server CB2001 with PID 4824
2017.01.18 10:14:07 0: CCURPC: CB2010 Server loop terminated
2017.01.18 10:14:07 0: CCURPC: CB2001 Server loop terminated
2017.01.18 10:14:07 2: CCURPC: Eventcount DD = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount DD = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount EV = 39
2017.01.18 10:14:07 2: CCURPC: Eventcount EV = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount EX = 1
2017.01.18 10:14:07 2: CCURPC: Eventcount EX = 1
2017.01.18 10:14:07 2: CCURPC: Eventcount IN = 1
2017.01.18 10:14:07 2: CCURPC: Eventcount IN = 1
2017.01.18 10:14:07 2: CCURPC: Eventcount ND = 73
2017.01.18 10:14:07 2: CCURPC: Eventcount ND = 9
2017.01.18 10:14:07 2: CCURPC: Eventcount RA = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount RA = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount RD = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount RD = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount SL = 1
2017.01.18 10:14:07 2: CCURPC: Eventcount SL = 1
2017.01.18 10:14:07 2: CCURPC: Eventcount UD = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount UD = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount total = 115
2017.01.18 10:14:07 2: CCURPC: Eventcount total = 12
2017.01.18 10:14:07 2: CCURPC: Eventcount writeerror = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount writeerror = 0
2017.01.18 10:14:11 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2017.01.18 10:14:11 0: HMCCU: Received EX event. RPC server CB2010 terminated.
2017.01.18 10:14:11 0: HMCCU: RPC server(s) with PID(s) 4824,4825 shut down. f=2
2017.01.18 10:14:11 2: HMCCU: Eventcount DD = 0
2017.01.18 10:14:11 2: HMCCU: Eventcount EV = 39
2017.01.18 10:14:11 2: HMCCU: Eventcount EX = 2
2017.01.18 10:14:11 2: HMCCU: Eventcount IN = 2
2017.01.18 10:14:11 2: HMCCU: Eventcount ND = 82
2017.01.18 10:14:11 2: HMCCU: Eventcount RA = 0
2017.01.18 10:14:11 2: HMCCU: Eventcount RD = 0
2017.01.18 10:14:11 2: HMCCU: Eventcount SL = 2
2017.01.18 10:14:11 2: HMCCU: Eventcount ST = 0
2017.01.18 10:14:11 2: HMCCU: Eventcount UD = 0
2017.01.18 10:14:11 2: HMCCU: Eventcount total = 127
2017.01.18 10:14:11 0: HMCCU: RPC server CB2001 started with pid 17404
2017.01.18 10:14:11 0: HMCCU: RPC server CB2010 started with pid 17405
2017.01.18 10:14:18 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2017.01.18 10:14:25 1: HMCCU: Registering callback http://192.168.1.166:7411/fh2001 with ID CB2001 at http://homematic-ccu2:2001/
2017.01.18 10:14:25 1: HMCCU: RPC callback with URL http://192.168.1.166:7411/fh2001 initialized
2017.01.18 10:14:30 0: HMCCU: Received SL event. RPC server CB2010 enters server loop
2017.01.18 10:14:37 1: HMCCU: Registering callback http://192.168.1.166:7411/fh2010 with ID CB2010 at http://homematic-ccu2:2010/
2017.01.18 10:14:37 1: HMCCU: RPC callback with URL http://192.168.1.166:7411/fh2010 initialized
jetzt sehe ich auch die beiden RPC Prozesse
fhem 17404 4813 3 10:14 ? 00:00:04 /usr/bin/perl ./FHEM/ccurpcd.pl homematic-ccu2 2001 /tmp/ccuqueue_2001_1 ./log/ccurpcd_2001_1.log 3
fhem 17405 4813 3 10:14 ? 00:00:03 /usr/bin/perl ./FHEM/ccurpcd.pl homematic-ccu2 2010 /tmp/ccuqueue_2010_1 ./log/ccurpcd_2010_1.log 3
Die Readings aktualisieren sich trotzdem nicht
Ich habe auch mal eine Frage zu der IP-Adresse 192.168.1.166 für den RPC-Server. Woher kommt diese IP? Die wurde nicht per DHCP vergeben und die feste IP des Fhem Servers ist eine andere (192.168.1.30)
Auszug aus der ccurpcd Log Datei
root@fhem:/opt/fhem# cat ./log/ccurpcd_2010_1.log
16.01.2017 17:53:54 Creating file queue
16.01.2017 17:53:54 Initializing RPC server
16.01.2017 17:53:54 Callback server created listening on port 7410
16.01.2017 17:53:54 Adding callback for events
16.01.2017 17:53:54 Adding callback for new devices
16.01.2017 17:53:54 Adding callback for deleted devices
16.01.2017 17:53:54 Adding callback for modified devices
16.01.2017 17:53:54 Adding callback for replaced devices
16.01.2017 17:53:54 Adding callback for readded devices
16.01.2017 17:53:54 Entering server loop. Use kill -SIGINT 24528 to terminate program
16.01.2017 17:55:29 RPC server terminated
18.01.2017 10:14:14 Creating file queue
18.01.2017 10:14:14 Initializing RPC server
18.01.2017 10:14:15 Callback server created listening on port 7410
18.01.2017 10:14:15 Adding callback for events
18.01.2017 10:14:15 Adding callback for new devices
18.01.2017 10:14:15 Adding callback for deleted devices
18.01.2017 10:14:15 Adding callback for modified devices
18.01.2017 10:14:15 Adding callback for replaced devices
18.01.2017 10:14:15 Adding callback for readded devices
18.01.2017 10:14:15 Entering server loop. Use kill -SIGINT 17405 to terminate program
root@fhem:/opt/fhem# cat ./log/ccurpcd_2010_1.log
16.01.2017 17:53:54 Creating file queue
16.01.2017 17:53:54 Initializing RPC server
16.01.2017 17:53:54 Callback server created listening on port 7410
16.01.2017 17:53:54 Adding callback for events
16.01.2017 17:53:54 Adding callback for new devices
16.01.2017 17:53:54 Adding callback for deleted devices
16.01.2017 17:53:54 Adding callback for modified devices
16.01.2017 17:53:54 Adding callback for replaced devices
16.01.2017 17:53:54 Adding callback for readded devices
16.01.2017 17:53:54 Entering server loop. Use kill -SIGINT 24528 to terminate program
16.01.2017 17:55:29 RPC server terminated
18.01.2017 10:14:14 Creating file queue
18.01.2017 10:14:14 Initializing RPC server
18.01.2017 10:14:15 Callback server created listening on port 7410
18.01.2017 10:14:15 Adding callback for events
18.01.2017 10:14:15 Adding callback for new devices
18.01.2017 10:14:15 Adding callback for deleted devices
18.01.2017 10:14:15 Adding callback for modified devices
18.01.2017 10:14:15 Adding callback for replaced devices
18.01.2017 10:14:15 Adding callback for readded devices
18.01.2017 10:14:15 Entering server loop. Use kill -SIGINT 17405 to terminate program
Die beiden Dat Dateien ccuqueue_2010_1.dat und ccuqueue_2001_1.dat in /tmp haben jeweils 0 Byte
Das HMCCU Device steht in Fhem jetzt seit 10 Minuten auf starting/busy
Hmm, was kann ich noch tun um das Problem einzukreisen?
hMCCU registriert sich mit der falschen IP bei der CCU. Deshalb gehen die Aktualisierungen von der CCU ins Nirvana.
Mach mal bitte ein
Ifconfig -a
Hi,
hatte ich natürlich auch gemacht, bevor ich schrieb, woher die IP-Adresse kommt, weil die ipadresse nur per DHCP kommen könnte (die Fritzbox kennt das Lease aber nicht) und ich das Interface auf dem Fhem-Server (Raspberry mit Jessi) selber eingerichtet hatte:
eth0 Link encap:Ethernet Hardware Adresse b8:27:eb:6e:e0:12
inet6-Adresse: fe80::c3c6:aeac:eb7f:c0fc/64 Gültigkeitsbereich:Verbindung
UP BROADCAST MULTICAST MTU:1500 Metrik:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:65536 Metrik:1
RX packets:2076083 errors:0 dropped:0 overruns:0 frame:0
TX packets:2076083 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:328796063 (313.5 MiB) TX bytes:328796063 (313.5 MiB)
wlan0 Link encap:Ethernet Hardware Adresse 74:da:38:33:8f:6f
inet Adresse:192.168.1.30 Bcast:192.168.1.255 Maske:255.255.255.0
inet6-Adresse: fe80::76da:38ff:fe33:8f6f/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:498940 errors:0 dropped:2896 overruns:0 frame:0
TX packets:392065 errors:0 dropped:1 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:245764912 (234.3 MiB) TX bytes:143054697 (136.4 MiB)
und Interface-Definition
root@fhem:/tmp# cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
iface eth0 inet dhcp
auto wlan0
allow-hotplug wlan0
iface wlan0 inet static
address 192.168.1.30
netmask 255.255.255.0
network 192.168.1.0
gateway 192.168.1.1
wpa-ap-scan 1
wpa-scan-ssid 1
wpa-ssid "$MEINESSID$"
wpa-psk "$MEINPSK$"
Sehr merkwürdig - einen anderen DHCP Server habe ich auch nicht laufen und ifconfig zeigt auch keine anderen Interfaces. Auch mit grep 192.168.1.66 über /etc/networks/* bekomme ich keine Übereinstimmung.
Muss ich mich wohl mal auf die Suche machen
Fehler gefunden (aber noch nicht behoben) :o Die Fritzbox macht da echt quatsch - trotz static ip adresse, weißt er dem Fhem Server noch eine weitere IP Adresse im DNS zu, die natürlich bei einer Hostabfrage fröhlich zwischen den IP-Adressen springt. Das ist mal echt kacke, zumal ich über die Fritzbox Gui nicht so einfach den Eintrag löschen kann.
Hi Zap,
sorry - aber Kommando zurück. Zwar habe ich jetzt nur eine IP-Adresse
2017.01.18 15:08:06 1: HMCCU: Registering callback http://192.168.1.30:7411/fh2001 with ID CB2001 at http://homematic-ccu2:2001/
2017.01.18 15:08:06 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.01.18 15:08:06 1: HMCCU: RPC callback with URL http://192.168.1.30:7411/fh2001 initialized
aber das ursprüngliche Problem gibt es leider trotzdem noch
Sehe das jetzt erst: Die Restart-Funktion des RPC-Servers scheint fehlerhaft zu sein. Er dürfte keinen ccurpcd.pl starten. Das ist der alte RPC-Server. Muss ich mir mal anschauen.
Meine Empfehlung:
- Stoppe FHEM
- Prüfe danach, ob noch irgendwelche ccurpcd.pl oder fhem.pl Prozesse laufen. Wenn ja, kille sie.
- Starte FHEM
- NAch dem Start (wenn rpcserver = on) müssten die beiden RPC-Server Prozesse laufen (als fhem.pl, nicht als ccurpcd.pl).
- Wichtig! Im Log muss eine Meldung stehen "All RPC Servers running". Dann ist alles in Ordnung.
Habe ich gemacht.
Als Meldung kommt dann final
2017.01.18 17:19:15 1: HMCCU: All RPC servers running
und dann halt alle 300 sekunden
HMCCU: Received no events from CCU since 300 seconds
Leider updaten aber nicht die Readings
Und im Log steht vorher
HMCCU: Registering callback http://192.168.1.30 ...
d.h. mit der korrekten IP?
Wenn ja, stoppe den RPC-Server, starte die CCU neu, starte den RPC-Server wieder.
Zitat von: zap am 18 Januar 2017, 18:18:51
Und im Log steht vorher
HMCCU: Registering callback http://192.168.1.30 ...
d.h. mit der korrekten IP?
Jap. Die IP steht jetzt richtig im Log
Zitat von: zap am 18 Januar 2017, 18:18:51
Wenn ja, stoppe den RPC-Server, starte die CCU neu, starte den RPC-Server wieder.
Habe ich gemacht - dann ging es ne Weile, aber irgendwann scheint er dann sich nicht mehr zu aktualisieren. Die aktuellsten Timestamps sind von 19:05
Edit:
Der letzte HMCCU: Received no events from CCU since 300 seconds Eintrag ist von 19:13:02
hi zap,
zwei HM-LC-Sw1PBU-FM (Unterputz Schaltaktoren) melden mir seit kurzem im reading 0.LOWBAT den Wert 1, den ich üblicherweise (bei Batterie betriebenen Homematic Komponenten) mit on interpretiere. Müsste ich das hier anders auslesen/intrepretieren (per subsitutue), oder kannst Du das beheben?
VG Yil
Zitat von: Kai-Alfonso am 19 Januar 2017, 08:01:51
Jap. Die IP steht jetzt richtig im Log
Habe ich gemacht - dann ging es ne Weile, aber irgendwann scheint er dann sich nicht mehr zu aktualisieren. Die aktuellsten Timestamps sind von 19:05
Edit:
Der letzte HMCCU: Received no events from CCU since 300 seconds Eintrag ist von 19:13:02
Du nutzt WLAN, richtig? Kannst Du den Raspi auch direkt per Kabel anschließen? Möglicherweise hat die WLAN Verbindung sporadisch Aussetzer. Das würde dazu führen, dass die CCU irgendwann aufhört, Events zu schicken.
Ja, ich nutze einen Edimax USB Dongle und habe eigentlich auch die Energieverwaltung abgestellt - was natürlich nix heißen muss. Da ich den Raspi eh ans LAN bringen wollte, teste ich das mal heute abend und gebe dann wieder Bescheid. :o
Danke für deine Hilfe und Geduld - muss man ja auch mal sagen 8)
moin,
entspricht eigentlich bei den Thermostaten "HM-CC-RT-DN" das READING R-TEMPERATURE_OFFSET dem Wert "Temperatur-Offset" in der CCU Oberfläche und wenn ja, wie ist die Umrechnung?
Das ist wirklich seltsam: das Temperatur Offset on meiner CCU steht auf 0. Der Parameter TEMPERATURE_OFFSET hingegen steht auf 7.
Das passt zu meinen Werte:
T CCU FHEM
AZ -1,5° 4
WZ 0° 7
SZ 0° 7
BD -0,5° 6
Wenn ich raten müsste, dann ist 7=0° und +-1 sind dann +-0,5°
Zitat von: zap am 19 Januar 2017, 11:55:30
Du nutzt WLAN, richtig? Kannst Du den Raspi auch direkt per Kabel anschließen? Möglicherweise hat die WLAN Verbindung sporadisch Aussetzer. Das würde dazu führen, dass die CCU irgendwann aufhört, Events zu schicken.
So, konnte das gestern abend mal testen - aber an der NIC (egal ob eth0 oder wlan0) kann es nicht liegen, weil nach 600 Sekunden es wieder nicht ging
2017.01.20 22:21:06 2: CCURPC: CB2001 NewDevice received 73 device specifications
2017.01.20 22:21:11 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2017.01.20 22:21:11 0: HMCCU: Received SL event. RPC server CB2010 enters server loop
2017.01.20 22:21:18 1: HMCCU: Registering callback http://192.168.1.30:7420/fh2010 with ID CB2010 at http://homematic-ccu2:2010/
2017.01.20 22:21:18 1: HMCCU: RPC callback with URL http://192.168.1.30:7420/fh2010 initialized
2017.01.20 22:21:18 1: CCURPC: CB2010 ListDevices. Sending init to HMCCU
2017.01.20 22:21:19 2: CCURPC: CB2010 NewDevice received 9 device specifications
2017.01.20 22:21:24 0: HMCCU: Received IN event. RPC server CB2010 initialized.
2017.01.20 22:21:25 2: HMCCU: Updated devices. Success=6 Failed=0
2017.01.20 22:21:25 1: HMCCU: All RPC servers running
2017.01.20 22:28:49 2: HMCCU: Received no events from CCU since 300 seconds
2017.01.20 22:36:31 2: HMCCU: Received no events from CCU since 300 seconds
Das war der letzte HMCCU Eintrag
Ich habe gerade die Version 3.8 eingecheckt.
Es gibt einige wichtige Änderungen, die u.U. dazu führen, dass einige Attribute nicht mehr korrekt funktionieren:
- HMCCUDEV,HMCCUCHN: In den Attributen ccureadingfilter und ccureadingname wurde bisher ',' für die Trennung mehrerer Filter bzw. Regeln verwendet. Statt ',' muss nun ';' verwendet werden.
- HMCCU: Das Attribut substdefaults wurde durch ccudef-substitute ersetzt.
Neu in Version 3.8:Default-Attribute im I/O Device:
Einführung von Default-Attributen für Reading-/Datapoint-Filter, Readingnames, Ersetzungen (Substitute) und Readingname-Formate im jeweiligen I/O Device. Die Default-Werte werden an eventuell in den Einzel-Devices definierte Attribute
angehängt (außer ccudef-readingformat)!
- ccudef-readingfilter : legt den Default Filter für alle HMCCUDEV/HMCCUCHN Devices fest.
- ccudef-readingname : legt Ersetzungsregeln für Readingnames für alle HMCCUDEV/HMCCUCHN Devices fest.
- ccudef-substitute: legt Ersetzungsregeln für Datenpunkt-Werte für alle HMCCUDEV/HMCCUCHN Devices fest.
- ccudef-readingformat : legt das Format der Readingnamen für alle HMCCUDEV/HMCCUCHN Devices fest (z.B. name oder datapoint). Dieser Default-Wert gilt nicht für virtuelle Gruppen Devices (z.B. Heizungsgruppen). Hier wird immer 'name' verwendet, da sich Datenpunkte überschneiden können.
Entsprechend wurde HMCCUConf.pm um Templates für eine CCU2 erweitert. Dort sind nun Vorgaben für die o.g. 3 Attribute definiert, die mit dem Befehl "set defaults" im I/O Device aktiviert werden können.
Durch diese Templates werden Readings generiert, die (weitgehend) mit CUL_HM kompatibel sind.
Unterstützung OSRAM Lightify Addon der CCU2 (experimentell):HMCCU unterstützt nun das Adressierungsschema von OSRAM Lampen ("OL-"), die in der CCU2 über das OSRAM Lightify Addon eingebunden sind. Bitte mal testen, ob alles funktioniert, insbesondere die automatische Aktualisierung von Readings.
HMScript mit Parametern:Bei dem Befehl "set hmscript" im I/O Device können nun Parameter an das auszuführende Homematic Script übergeben werden. Im folgenden Beispiel gibt das Script die Datenpunkte eines Kanals aus. Der Kanalname wird als Parameter übergeben:
string sDPId;
object oChannel = dom.GetObject ("$CCUDEV");
foreach(sDPId, oChannel.DPs().EnumUsedIDs())
{
object oDP = dom.GetObject(sDPId);
WriteLine (oDP.Name());
}
Ausführung, wenn das Script als /opt/fhem/partest.scr gespeichert ist:
set myccu hmscript /opt/fhem/partest.scr dump CCUDEV=MyDevChannel
Der optionale Parameter 'dump' sorgt für die Ausgabe im FHEM WebGUI.
Sonstiges:
- HMCCUCHN Devices unterstützen nun ebenfalls den Befehl "get deviceinfo"
- HMCCU ermittelt den Typ von Kanälen und speichert ihn im Internal chntype (nur bei HMCCUCHN Devices)
- Ein Fehler beim Befehl "set rpcserver restart" wurde behoben
Für Interessierte zum Schluss noch die neuen Default-Attribute:
"CCU2" => {
_description => "HomeMatic CCU2",
"ccudef-readingfilter" => '^(LOW_?BAT|UNREACH)$',
"ccudef-readingformat" => 'datapoint',
"ccudef-readingname" => '^(.+\.)?AES_KEY$:sign;^(.+\.)?LOW_?BAT$:battery;^(.+\.)?UNREACH$:Activity;^(.+\.)?TEMPERATURE$:+measured-temp;^(.+\.)?SET_TEMPERATURE$:+desired-temp;^(.+\.)?HUMIDITY$:+humidity;^(.+\.)?LEVEL$:+pct;^(.+\.)?CONTROL_MODE$:+controlMode',
"ccudef-substitute" => 'AES_KEY!(0|false):off,(1|true):on;LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;UNREACH!(0|false):alive,(1|true):dead;MOTION!(0|false):noMotion,(1|true):motion;DIRECTION!0:stop,1:up,2:down,3:undefined;WORKING!0:false,1:true;INHIBIT!(0|false):unlocked,(1|true):locked'
}
Einige der Vorschläge für die CUL_HM Kompatibilität konnte ich nicht umsetzen, da EQ-3 hier insbesondere bei der gemischten Verwendung von Nicht-IP mit HMIP Inkonsistenzen eingebaut hat. Insofern bleibt es jedem selbst überlassen, die Default-Attribute nach eigenen Wünschen anzupassen.
Hi zap,
die default-Werte an der HMCCU sind definitiv eine gute Entwicklung und machen das Arbeiten mit dem Modul an vielen Stellen leichter! Danke dafür.
eine Frage zum Attribut ccureadingfilter: hier habe ich keine Kommas als Trenner, sondern '|' -> also z.B.: (LOWBAT|STATE). Was ändert sich hier?
VG Yil
Zitat von: Yil am 21 Januar 2017, 14:13:07
die default-Werte an der HMCCU sind definitiv eine gute Entwicklung und machen das Arbeiten mit dem Modul an vielen Stellen leichter! Danke dafür.
eine Frage zum Attribut ccureadingfilter: hier habe ich keine Kommas als Trenner, sondern '|' -> also z.B.: (LOWBAT|STATE). Was ändert sich hier?
Mit der Einführung der Default-Attribute habe ich konsequenterweise auch aus den Templates die Datenpunkte LOWBAT, UNREACH usw entfernt.
Bei ccureadingfilter musst Du in Deinem Fall nichts ändern, denn '|' ist kein Trenner sondern Teil eines regulären Ausdrucks. Hier ein Beispiel, bei dem etwas geändert werden müsste:
Alt (Liste von 2 Filtern durch Komma getrennt): ccureadingfilter LEVEL,^PRESS.*
Neu (Komma durch Semikolon ersetzt): ccureadingfilter LEVEL;^PRESS.*
Hi,
ich stehe heute vor einem seltsamen Problem - vielleicht habe ich aber auch nur irgendwo auf den vielen Seiten zu dem Thema etwas überlesen.
Und zwar versuche ich eine HmIP-SMI in FHEM hinzuzufügen. In der CCU2 ist bereits angelernt und funktioniert wie gewünscht.
Dementsprechend habe ich ein
get d_ccu devicelist
gemacht.
Anschließend versuche ich ein
get d_ccu deviceinfo HmIP-SMI
Bekomme nun aber ein Popup mit
HMCCU: d_ccu Invalid name or address
und danach steht der RPC Server auf Error.
Stoppen, Neustart und erneuter Versuch bringt das gleiche Resultat.
So sieht das im Logfile aus:
2017.01.21 17:51:06 0: RPC server(s) starting
2017.01.21 17:51:06 0: CCURPC: Callback server created listening on port 7420
2017.01.21 17:51:06 1: CCURPC: CB2010 Adding callback for events
2017.01.21 17:51:06 1: CCURPC: CB2010 Adding callback for new devices
2017.01.21 17:51:06 1: CCURPC: CB2010 Adding callback for deleted devices
2017.01.21 17:51:06 1: CCURPC: CB2010 Adding callback for modified devices
2017.01.21 17:51:06 1: CCURPC: CB2010 Adding callback for replaced devices
2017.01.21 17:51:06 1: CCURPC: CB2010 Adding callback for readded devices
2017.01.21 17:51:06 1: CCURPC: CB2010 Adding callback for list devices
2017.01.21 17:51:06 0: CCURPC: Callback server created listening on port 14702
2017.01.21 17:51:06 1: CCURPC: CB9292 Adding callback for events
2017.01.21 17:51:06 1: CCURPC: CB9292 Adding callback for new devices
2017.01.21 17:51:06 1: CCURPC: CB9292 Adding callback for deleted devices
2017.01.21 17:51:06 1: CCURPC: CB2010 Adding callback for event query
2017.01.21 17:51:06 0: CCURPC: CB2010 Entering server loop
2017.01.21 17:51:06 1: CCURPC: CB9292 Adding callback for modified devices
2017.01.21 17:51:06 1: CCURPC: CB9292 Adding callback for replaced devices
2017.01.21 17:51:06 1: CCURPC: CB9292 Adding callback for readded devices
2017.01.21 17:51:06 1: CCURPC: CB9292 Adding callback for list devices
2017.01.21 17:51:06 1: CCURPC: CB9292 Adding callback for event query
2017.01.21 17:51:06 0: CCURPC: CB9292 Entering server loop
2017.01.21 17:51:11 0: HMCCU: Received SL event. RPC server CB2010 enters server loop
2017.01.21 17:51:18 1: HMCCU: Registering callback http://192.168.178.35:7420/fh2010 with ID CB2010 at http://192.168.178.47:2010/
2017.01.21 17:51:18 1: HMCCU: RPC callback with URL http://192.168.178.35:7420/fh2010 initialized
2017.01.21 17:51:19 1: CCURPC: CB2010 ListDevices. Sending init to HMCCU
2017.01.21 17:51:19 2: CCURPC: CB2010 NewDevice received 6 device specifications
2017.01.21 17:51:23 0: HMCCU: Received IN event. RPC server CB2010 initialized.
2017.01.21 17:51:23 0: HMCCU: Received SL event. RPC server CB9292 enters server loop
2017.01.21 17:51:30 1: HMCCU: Registering callback http://192.168.178.35:14702/fh9292 with ID CB9292 at http://192.168.178.47:9292/groups
2017.01.21 17:51:31 1: CCURPC: CB9292 ListDevices. Sending init to HMCCU
2017.01.21 17:51:40 1: HMCCU: RPC callback with URL http://192.168.178.35:14702/fh9292 initialized
2017.01.21 17:51:45 0: HMCCU: Received IN event. RPC server CB9292 initialized.
2017.01.21 17:51:46 2: HMCCU: Updated devices. Success=1 Failed=0
2017.01.21 17:51:46 1: HMCCU: All RPC servers running
2017.01.21 17:53:06 1: HMCCU: d_ccu Invalid name or address
Und hier noch das List vom Device
Internals:
CCUNum 1
Clients :HMCCUDEV:HMCCUCHN:
DEF 192.168.178.47
DelDevices 0
DevCount 58
NAME d_ccu
NR 187
NTFY_ORDER 50-d_ccu
NewDevices 0
RPCPID 1431,1432
RPCPRC internal
RPCState running
STATE running/Error
TYPE HMCCU
ccutype CCU2
host 192.168.178.47
version 3.7
Readings:
2016-12-25 16:23:41 batterycount 1
2016-12-25 16:23:41 batterylist no match
2016-12-25 16:23:41 batterymatch 0
2016-12-25 16:23:41 batterystate no
2017-01-21 17:51:45 rpcstate running
2017-01-21 17:53:05 state Error
Hmccu:
evtime 1485017954
evtimeout 0
localaddr 192.168.178.35
rpccount 2
rpcinit 2
updatetime 0
Adr:
Hm-fk_sz_1:
address 0000D569A1ABC7
addtype dev
valid 1
Hm-fk_sz_1:0:
address 0000D569A1ABC7:0
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:
address BidCoS-RF
addtype dev
valid 1
Hm-rcv-50 bidcos-rf:0:
address BidCoS-RF:0
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:1:
address BidCoS-RF:1
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:10:
address BidCoS-RF:10
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:11:
address BidCoS-RF:11
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:12:
address BidCoS-RF:12
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:13:
address BidCoS-RF:13
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:14:
address BidCoS-RF:14
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:15:
address BidCoS-RF:15
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:16:
address BidCoS-RF:16
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:17:
address BidCoS-RF:17
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:18:
address BidCoS-RF:18
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:19:
address BidCoS-RF:19
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:2:
address BidCoS-RF:2
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:20:
address BidCoS-RF:20
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:21:
address BidCoS-RF:21
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:22:
address BidCoS-RF:22
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:23:
address BidCoS-RF:23
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:24:
address BidCoS-RF:24
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:25:
address BidCoS-RF:25
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:26:
address BidCoS-RF:26
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:27:
address BidCoS-RF:27
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:28:
address BidCoS-RF:28
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:29:
address BidCoS-RF:29
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:3:
address BidCoS-RF:3
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:30:
address BidCoS-RF:30
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:31:
address BidCoS-RF:31
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:32:
address BidCoS-RF:32
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:33:
address BidCoS-RF:33
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:34:
address BidCoS-RF:34
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:35:
address BidCoS-RF:35
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:36:
address BidCoS-RF:36
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:37:
address BidCoS-RF:37
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:38:
address BidCoS-RF:38
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:39:
address BidCoS-RF:39
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:4:
address BidCoS-RF:4
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:40:
address BidCoS-RF:40
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:41:
address BidCoS-RF:41
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:42:
address BidCoS-RF:42
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:43:
address BidCoS-RF:43
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:44:
address BidCoS-RF:44
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:45:
address BidCoS-RF:45
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:46:
address BidCoS-RF:46
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:47:
address BidCoS-RF:47
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:48:
address BidCoS-RF:48
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:49:
address BidCoS-RF:49
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:5:
address BidCoS-RF:5
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:50:
address BidCoS-RF:50
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:6:
address BidCoS-RF:6
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:7:
address BidCoS-RF:7
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:8:
address BidCoS-RF:8
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:9:
address BidCoS-RF:9
addtype chn
valid 1
Hmip-swdo 0000d569a1abc7:1:
address 0000D569A1ABC7:1
addtype chn
valid 1
Hmip-smi 0009156993c0bb:
address 0009156993C0BB
addtype dev
valid 1
Hmip-smi 0009156993c0bb:0:
address 0009156993C0BB:0
addtype chn
valid 1
Hmip-smi 0009156993c0bb:1:
address 0009156993C0BB:1
addtype chn
valid 1
Agg:
Battery:
fcoll alias
fcond any
fdflt no match
felse no
fexcl
fexpr Homematic
fpref battery
fread (LOWBAT|LOW_BAT)
ftrue yes
ftype room
Dev:
0000d569a1abc7:
addtype dev
channels 2
interface HmIP-RF
name HM-FK_SZ_1
type HMIP-SWDO
valid 1
0000d569a1abc7:0:
addtype chn
channels 1
name HM-FK_SZ_1:0
valid 1
0000d569a1abc7:1:
addtype chn
channels 1
name HMIP-SWDO 0000D569A1ABC7:1
valid 1
0009156993c0bb:
addtype dev
channels 2
interface HmIP-RF
name HmIP-SMI 0009156993C0BB
type HmIP-SMI
valid 1
0009156993c0bb:0:
addtype chn
channels 1
name HmIP-SMI 0009156993C0BB:0
valid 1
0009156993c0bb:1:
addtype chn
channels 1
name HmIP-SMI 0009156993C0BB:1
valid 1
Bidcos-rf:
addtype dev
channels 51
interface BidCos-RF
name HM-RCV-50 BidCoS-RF
type HM-RCV-50
valid 1
Bidcos-rf:0:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:0
valid 1
Bidcos-rf:1:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:1
valid 1
Bidcos-rf:10:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:10
valid 1
Bidcos-rf:11:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:11
valid 1
Bidcos-rf:12:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:12
valid 1
Bidcos-rf:13:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:13
valid 1
Bidcos-rf:14:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:14
valid 1
Bidcos-rf:15:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:15
valid 1
Bidcos-rf:16:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:16
valid 1
Bidcos-rf:17:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:17
valid 1
Bidcos-rf:18:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:18
valid 1
Bidcos-rf:19:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:19
valid 1
Bidcos-rf:2:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:2
valid 1
Bidcos-rf:20:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:20
valid 1
Bidcos-rf:21:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:21
valid 1
Bidcos-rf:22:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:22
valid 1
Bidcos-rf:23:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:23
valid 1
Bidcos-rf:24:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:24
valid 1
Bidcos-rf:25:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:25
valid 1
Bidcos-rf:26:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:26
valid 1
Bidcos-rf:27:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:27
valid 1
Bidcos-rf:28:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:28
valid 1
Bidcos-rf:29:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:29
valid 1
Bidcos-rf:3:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:3
valid 1
Bidcos-rf:30:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:30
valid 1
Bidcos-rf:31:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:31
valid 1
Bidcos-rf:32:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:32
valid 1
Bidcos-rf:33:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:33
valid 1
Bidcos-rf:34:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:34
valid 1
Bidcos-rf:35:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:35
valid 1
Bidcos-rf:36:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:36
valid 1
Bidcos-rf:37:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:37
valid 1
Bidcos-rf:38:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:38
valid 1
Bidcos-rf:39:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:39
valid 1
Bidcos-rf:4:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:4
valid 1
Bidcos-rf:40:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:40
valid 1
Bidcos-rf:41:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:41
valid 1
Bidcos-rf:42:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:42
valid 1
Bidcos-rf:43:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:43
valid 1
Bidcos-rf:44:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:44
valid 1
Bidcos-rf:45:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:45
valid 1
Bidcos-rf:46:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:46
valid 1
Bidcos-rf:47:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:47
valid 1
Bidcos-rf:48:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:48
valid 1
Bidcos-rf:49:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:49
valid 1
Bidcos-rf:5:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:5
valid 1
Bidcos-rf:50:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:50
valid 1
Bidcos-rf:6:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:6
valid 1
Bidcos-rf:7:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:7
valid 1
Bidcos-rf:8:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:8
valid 1
Bidcos-rf:9:
addtype chn
channels 1
name HM-RCV-50 BidCoS-RF:9
valid 1
Dp:
Hm-rcv-50:
Ch:
0:
Install_mode:
oper 3
type 2
1:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
10:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
11:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
12:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
13:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
14:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
15:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
16:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
17:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
18:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
19:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
2:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
20:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
21:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
22:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
23:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
24:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
25:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
26:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
27:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
28:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
29:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
3:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
30:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
31:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
32:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
33:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
34:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
35:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
36:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
37:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
38:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
39:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
4:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
40:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
41:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
42:
Level:
oper 2
type 6
Press_long:
oper 6
type 2
Press_short:
oper 6
type 2
Mach mal bitte noch den Code-Tag am Ende zu, damit Dein Beitrag etwas übersichtlicher wird.
Du musst beim Befehl "get deviceinfo" den Namen des HmIP-SMI Geräts in der CCU angeben, nicht den Typ.
Wenn ich das richtig interpretiere, heißt das Gerät in der CCU "HmIP-SMI 0009156993C0BB" (Du solltest Dir sprechendere Namen überlegen, möglichst ohne Leerzeichen). Dann lautet der korrekte Befehl
get d_ccu deviceinfo "HmIP-SMI 0009156993C0BB"
Der "error" im State von d_ccu kommt nicht vom RPC-Server sondern ist das Ergebnis des falschen Parameters bei get deviceinfo.
Zitat von: zap am 21 Januar 2017, 19:06:37
Wenn ich das richtig interpretiere, heißt das Gerät in der CCU "HmIP-SMI 0009156993C0BB" (Du solltest Dir sprechendere Namen überlegen, möglichst ohne Leerzeichen).
Tatsache, die Kombi hinter dem Leerzeichen habe ich durch den Umbruch in der WebUI echt übersehen.
Danke fürs Augen öffnen!
Hallo zap,
Zitat von: zap am 21 Januar 2017, 10:53:44
Unterstützung OSRAM Lightify Addon der CCU2 (experimentell):
HMCCU unterstützt nun das Adressierungsschema von OSRAM Lampen ("OL-"), die in der CCU2 über das OSRAM Lightify Addon eingebunden sind. Bitte mal testen, ob alles funktioniert, insbesondere die automatische Aktualisierung von Readings.
Meines Wissens werden die Datenpunkte von Lightify-Produkten nicht in der CCU aktualisiert - es erfolgt keine Rückgabe vom Gateway und kein periodisches Abfragen. Insofern ist das Vorbereiten des Moduls auf diese Devices zwar einerseits sinnvoll in Erwartung von Verbesserungen seitens eq3, andererseits ist es, glaube ich, zur Zeit zielführender, Lightify-Geräte unmittelbar in fhem einzubinden.
Ich habe das OSRAM Addon nur eingebunden, weil ein Nutzer (Yil?) danach gefragt hatte.
Beschränkt sich momentan auch auf die Unterstützung des etwas seltsamen Adressierungsschemas.
Hi zap,
ich habe gerade mal nach langer Zeit wieder ein Update gefahren und nun funktionieren meine Wandtaster nicht mehr. Es kommt in FHEM gar kein EVENT mehr an.
Vorher hatte ich mich die ganze Zeit auf folgendes EVENT gestürzt.
HM-PB-6-WM55_MEQXXXXXXX.1.PRESS_SHORT
Nun sehe ich beim Tastendruck meiner Wandtaster im EVENT-Monitor nur noch:
2017-01-22 11:38:29 HMCCUCHN Wandtaster6Fach_01 hmstate: Initialized
2017-01-22 11:38:29 HMCCUDEV Wandtaster6Fach hmstate: Initialized
2017-01-22 11:38:49 HMCCUCHN Wandtaster6Fach_05 hmstate: Initialized
2017-01-22 11:38:49 HMCCUDEV Wandtaster6Fach hmstate: Initialized
2017-01-22 11:39:16 HMCCUCHN Wandtaster4FachWohnzimmer_02 hmstate: Initialized
2017-01-22 11:39:16 HMCCUDEV Wandtaster4FachWohnzimmer hmstate: Initialized
2017-01-22 11:39:16 HMCCUCHN Wandtaster4FachWohnzimmer_02 hmstate: Initialized
2017-01-22 11:39:16 HMCCUDEV Wandtaster4FachWohnzimmer hmstate: Initialized
Viele Grüße
Thomas
wenn ich ccu
ccudef-readingname 4.SET_TEMPERATURE:+desired-temp,4.ACTUAL_TEMPERATURE:+measured-temp,4.VALVE_STATE:+actuator,0.LOWBAT:+battery,4.BATTERY_STATE:+batteryLevel
ccudef-substitute LOWBAT!(0|false):ok,(1|true):low
ccudef-readingformat datapoint
setz und die attribute bei einem hmccudev lösche wird nichts mehr angezeigt, ich würde meinen es sollte dann aber readings im datapoint format erzeugt werden da in der ccu definiert richtig?
des weiteren fehlt bei ccudef-readingformat das auswahldropdown wie bei ccureadingsformat
es werden auch keine werte mehr aus der ccu geholt seit dem das update eingespielt ist. der rpc läuft aber ohne fehlermeldungen
ich setze nun wieder auf hmccu 3.7. die 3.8 ist bei mir nicht i.O. da keine updates von der ccu geholt werden. die kommunikation scheint zu gehen (get devicelist holt zb 200er nochwas geräte aber readings werdne zb bei get update nicht aktualisiert. wenn das funktionieren würde, wären sicher meine fragen von eben gelöst
Zitat von: ToM_ToM am 22 Januar 2017, 11:45:21
Hi zap,
ich habe gerade mal nach langer Zeit wieder ein Update gefahren und nun funktionieren meine Wandtaster nicht mehr. Es kommt in FHEM gar kein EVENT mehr an.
Vorher hatte ich mich die ganze Zeit auf folgendes EVENT gestürzt.
HM-PB-6-WM55_MEQXXXXXXX.1.PRESS_SHORT
Setze mal im I/O Device das Attribut ccudef-readingformat auf name. Das hat sich auf 'datapoint' geändert. Der Event müsste bei 'datapoint' "1.PRESS_SHORT" heißen, ohne HM... davor.
Außerdem bitte ein list des Wandtasters in FHEM.
Zitat von: chris1284 am 22 Januar 2017, 11:54:47
wenn ich ccu
ccudef-readingname 4.SET_TEMPERATURE:+desired-temp,4.ACTUAL_TEMPERATURE:+measured-temp,4.VALVE_STATE:+actuator,0.LOWBAT:+battery,4.BATTERY_STATE:+batteryLevel
ccudef-substitute LOWBAT!(0|false):ok,(1|true):low
ccudef-readingformat datapoint
setz und die attribute bei einem hmccudev lösche wird nichts mehr angezeigt, ich würde meinen es sollte dann aber readings im datapoint format erzeugt werden da in der ccu definiert richtig?
des weiteren fehlt bei ccudef-readingformat das auswahldropdown wie bei ccureadingsformat
es werden auch keine werte mehr aus der ccu geholt seit dem das update eingespielt ist. der rpc läuft aber ohne fehlermeldungen
Zeige mal ein list eines betroffenen Devices. Hast Du ccudef-readingfilter im I/O Device gesetzt?
Wichtig! Wenn in der neuen Version 3.8 keine Readings aktualisiert werden, liegt das vermutlich daran, dass weder im IO Device das Attribut ccudef-readingfilter noch im betroffenen Client Device das Attribut ccureadingfilter gesetzt ist.
Abhilfe: im IO Device ccudef-readingfilter auf .* setzen!
Edit: ccudef-readingsfilter auf .* hilft, sollte aber Default sein.
Ich probiere mal aus, wie weit man jetzt kommt. Zum hmstate Reading muss ich nochmals meine Gedanken sammeln, derzeit eignet es sich nach wie vor nicht durch die Vermischung von Warnungen und echten Fehlern.
Mir ist außerdem aufgefallen:
list i:chntype=.+ i:chntype
BA_Window VIR-LG-WHITE-DIM-CH
BR_Light VIR-LG-WHITE-DIM-CH
BR_Shutter VIR-LG-WHITE-DIM-CH
BR_WindowCmpl VIR-LG-WHITE-DIM-CH
BR_WindowTilt VIR-LG-WHITE-DIM-CH
FL_FrontDoor VIR-LG-WHITE-DIM-CH
FL_Light VIR-LG-WHITE-DIM-CH
KT_Light VIR-LG-WHITE-DIM-CH
KT_LightCounter VIR-LG-WHITE-DIM-CH
KT_Window VIR-LG-WHITE-DIM-CH
LR_BalconyDoorCmpl VIR-LG-WHITE-DIM-CH
LR_BalconyDoorTilt VIR-LG-WHITE-DIM-CH
LR_ShutterSouth VIR-LG-WHITE-DIM-CH
LR_ShutterWest VIR-LG-WHITE-DIM-CH
LR_SunBlind VIR-LG-WHITE-DIM-CH
LR_WindowSouth VIR-LG-WHITE-DIM-CH
LR_WindowWest VIR-LG-WHITE-DIM-CH
Zitat von: zap am 22 Januar 2017, 13:16:55
Hast Du ccudef-readingfilter im I/O Device gesetzt?
weder im dev noch im io weil ich keine readings filtern will
ZitatAbhilfe: im IO Device ccudef-readingfilter auf .* setzen!
bedeutet das es nun ein pflichtattribut ist damit überhaupt readings ankommen? dann sollte das per default auch ohne zutun des users gesetzt werdne wenn nicht schon anderst durhc den user konifguriert.
ich werds testen
ccu-readingsfilter .* hilft wirklich! aber das olltest du vorraussetzen wenn das attribut nicht gestezt ist
in ccudef-readingname würde ich in den defaults batterie ehr so definieren
Zitat..;^(.+\.)?LOW_?BAT$:+battery;
dann fehlt noch
Zitat..;^(.+\.)?BATTERY_STATE:+batteryLevel;
würde ich meinen
Hallo zap,
zuerst einmal finde ich es cool, dass Du die Module ständig aktualisierst und erweiterst! Vielen Dank dafür!
Aber mit dem Wechsel von 3.7 auf 3.8 scheint sich jetzt ja einiges grundlegend zu ändern, was - soweit ich das verstehe - auch sinnvoll zu sein scheint. Eine gute Sache für alle, die gerade am Einrichten sind.
Aber was bedeutet das für Nutzer wie mich, die eine "fertige", funktionierende Konfiguration laufen haben?
- in ccureadingfilter und ccureadingname muss ich "," durch ";" ersetzen: ok
- statt substdefaults muss ich ccudef-substitute verwenden: kann, falls vorhanden, der alte Wert 1:1 übernommen werden oder gibt es irgendwas zu beachten?
- ccudef-readingfilter, ccudef-readingname und ccudef-readingformat sind neu hinzugekommen und können durch Vorgaben aus den Templates befüllt werden: welche Werte muss ich setzten, wenn ich nicht mit den Templates arbeiten möchte und eigentlich nur das gleiche Verhalten des Modules wie vorher benötige?
P.S. Noch läuft bei mir 3.7
Viele Grüße
Christian
Zitat^(.+\.)?TEMPERATURE$:+measured-temp;
das kannst du so auch nicht in den defaults lassen das zb bei tempsensoren dann auch measured-temp steht. wenn du dich an cul_Hm orientierst müsste da temperature stehen.
dafür könntest du folgendes aufnehmen
Zitat^(.+\.)?ACTUAL_HUMIDITY:+humidity;^(.+\.)?ACTUAL_TEMPERATURE:+temperature
Zitat von: Loredo am 22 Januar 2017, 13:25:28
Edit: ccudef-readingsfilter auf .* hilft, sollte aber Default sein.
Ja ich weiß. Ein Bug. Ich versuche, noch heute ein Update zu liefern.
@chris1284: Danke für die Hinweise zu den Defaults. Ändere ich.
@cho: Ich liefere die Einstellungen nach (damit alles so funktioniert wie vorher). Die Idee war eigentlich, dass das der Fall ist, wenn man keines der ccudef- Atribute setzt. Ist aber nicht so. Sorry.
Bei ccudef-substitute kannst Du die Einstellungen von substdefault einfach übernehmen. Da wurde sowieso schon ; als Trenner verwendet.
@loredo: evtl. hilft es, wenn ich noch ein ccudef-hmstate ergänze, mit dem man festlegen kann, welche Readings in hmstate einfließen (?)
eins habe ich noch ;D
ein
Zitatccudef-substexcl
attribut wäre toll. somit kann ich das (weil überall wenn gesetzt gleich) auch aus den eigenen geräte defaults nehmen und in die ccudefaults packen
Hi zap,
habe die Änderungen vorgenommen und jetzt läufts.
Danke :)
VG, Thomas
Zitat von: chris1284 am 22 Januar 2017, 13:47:03
in ccudef-readingname würde ich in den defaults batterie ehr so definieren
..;^(.+\.)?LOW_?BAT$:+battery;
Wozu ist "..;" am Anfang gut?
das sollte nur bedeuten das davor noch was ist wie "...<einigedefinitionen >...;"
Wenn Du in einem Client Device das Attribut 'ccureadingname' setzt und auch im I/O Device 'ccudef-readingname' gesetzt ist, werden beide Angaben einfach aneinander gehängt:
ccureadingname;ccudef-readingname
Da die Regeln von links nach rechts abgearbeitet werden, kann man die Angaben aus 'ccudef-readingname auch überschreiben. Ein Beispiel:
ccudef-readingname = LOWBAT:+battery
ccureadingname = LOWBAT:saft
Man beachte das fehlende '+' bei ccureadingname. Das ergibt die Regel:
LOWBAT:saft;LOWBAT:+battery
Da bereits im ersten Schritt LOWBAT durch 'saft' ersetzt wird, greift die folgende Regel nicht mehr, da LOWBAT umbenannt wurde. Ein ccureadingname = LOWBAT:+saft hingegen würde zu 3 Readings führen: LOWBAT, saft und battery
So, die Änderungen sind eingecheckt. Dürften dann morgen verteilt werden. Die wichtigste Änderung: Default für ccudef-readingfilter ist '.*', d.h. alle Readings werden aktualisiert.
Um das Verhalten der Version 3.7 bei der Aktualisierung von Readings zu erreichen, sind im I/O Device folgende Attribute zu setzen:
ccudef-readingfilter = .* (muss nicht sein, da nun Vorgabe)
ccudef-readingformat = name
Die Attribute ccudef-substitute und ccudef-readingname sollten in diesem Fall nicht gesetzt werden.
Ggf. werde ich morgen noch 2 weitere Default-Attribute nachreichen. Muss ich aber erst noch drüber nachdenken ...
Ich habe die 3.8v2 jetzt getestet und muss sagen: Die Grundlagen sind jetzt beinahe geschaffen,
großes Lob! :)
Dass man nach wie vor bei einem komplett neu angelegten HMCCU Gateway Device ein "set defaults" machen muss, um den sinnvollen Ausgangspunkt zu erhalten, finde ich nicht optimal, aber ich kann damit leben. Für Neulinge bedeutet das noch immer genaues lesen und verstehen statt "Hands on", was eigentlich schade ist. rpcserver=on gehört eigentlich auch noch in die Defaults rein würde ich sagen.
Chris hatte ja schon bemerkt, dass wir wohl noch etwas an vollständigen/sinnvollen Default-Werten für ccudef-readingname und ccudef-substitude feilen sollten. Das sind aber Details und hilft dann vor allem den Neuein- und Umsteigern. Da wohl keiner alle HM und HMIP Geräte auf dem Markt hat, müssen wir hier gemeinsam herausfinden, welche Datenpunkte man mit guter Sicherheit umschreiben kann (und wie). Der Temperaturbereich ist wohl einer der Bereiche und Chris hat schon beschrieben, dass das Verständnis über CUL_HM und andere FHEM-Module etwas anders ist (oder sein sollte), als die momentane Vorbelegung es nahelegt. Im Grunde ist es einfach: Die gemessene Temperatur bei reinen Sensoren heißt immer 'temperature' (z.B. Wetterstation draußen; HM Kanaltyp WEATHER.*), wenn es ein Sensor als Teil einer Klimaregelung ist heißt das Reading 'measured-temp' (z.B. Raumthermostat; HM Kanaltyp CLIMATECONTROL.*). Das lässt sich auch gut daraus ablesen, dass eq-3 diesen Unterschied ebenso macht: Bei der Wetterstation heißt der Datenpunkt TEMPERATURE, bei den Reglern ACTUAL_TEMPERATURE und es gibt bei letzterem deshalb konsequenter Weise zusätzlich SET_TEMPERATURE, was desired-temp entspricht. Das ist alles absolut logisch aufgebaut, wenn man mal genau liest ;-)
Ich habe also aktuell folgendes für ccudef-readingname:
^(.+\.)?ACTUAL_HUMIDITY$:humidity;
^(.+\.)?ACTUAL_TEMPERATURE$:measured-temp;
^(.+\.)?AES_KEY$:sign;
^(.+\.)?BATTERY_STATE$:batteryLevel;
^(.+\.)?BRIGHTNESS$:brightness;
^(.+\.)?CONTROL_MODE$:controlMode;
^(.+\.)?DIRECTION$:direction;
^(.+\.)?ENERGY_COUNTER$:energy;
^(.+\.)?FREQUENCY$:frequency;
^(.+\.)?HUMIDITY$:humidity;
^(.+\.)?INHIBIT$:lock;
^(.+\.)?LEVEL$:+pct;
^(.+\.)?LEVEL$:level;
^(.+\.)?LOW_?BAT$:battery;
^(.+\.)?MOTION$:motion;
^(.+\.)?PARTY_START_TIME$:partyStart;
^(.+\.)?PARTY_STOP_TIME$:partyEnd;
^(.+\.)?PARTY_TEMPERATURE$:partyTemp;
^(.+\.)?POWER$:consumption;
^(.+\.)?SET_TEMPERATURE$:desired-temp;
^(.+\.)?TEMPERATURE$:temperature;
^(.+\.)?UNREACH$:Activity;
^(.+\.)?VALVE_STATE$:valve;
^(.+\.)?VOLTAGE$:voltage;
^(.+\.)?WORKING$:working;
^(.+\.)?STATE$:STATE;
Für ccudef-substitude habe ich:
AES_KEY!(0|false):off,(1|true):on;
CONTROL_MODE!0:auto,1:manual,2:party,3:boost;
DIRECTION!0:stop,1:up,2:down,3:undefined;
INHIBIT!(0|false):unlocked,(1|true):locked;
LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;
MOTION!(0|false):noMotion,(1|true):motion;
UNREACH!(0|false):alive,(1|true):dead;
WORKING!(0|false):false,(1|true):true;
Was mir dabei nicht klar ist, auf welcher Grundlage ihr meint die umgeschriebenen Readings zusätzlich zu den Ausgangsreadings erzeugen zu müssen (also mit der '+' Notation). Mir fällt da (außer für LEVEL) kein Grund ein, warum das so sein muss, habt ihr einen? Mir ist nicht klar, weshalb man bei ccuref-readingname Regex verwenden kann und bei ccudef-substitude nicht (sieht man schön am Beispiel LOW_BAT/LOWBAT), ggf. ließe sich das angleichen.
Der Eintrag für STATE (bzw. müsste es eigentlich sogar ^\d+\.:; lauten) bei mir in ccudef-readingname ist eher dem geschuldet, dass ich es nach wie vor für die eigene Berechnung von stateHM ohne den Channel-Prefix benötige, was mich zu deiner Frage führt, @zap:
Zitat von: zap am 22 Januar 2017, 14:02:30
@loredo: evtl. hilft es, wenn ich noch ein ccudef-hmstate ergänze, mit dem man festlegen kann, welche Readings in hmstate einfließen (?)
So wie du hmstate aktuell gemeint hast (lt. Commandref), hilft es für die Steuerung von Geräten nicht, sondern ist nur eine bessere Zusammenfassung von Warn- und Fehlerstatus. Damit lässt sich nichts steuern. Sagen zu können welche Datenpunkte/Readings mit in die Berechnung einfließen und mit welcher Priorität wäre essentiell, ja. Zentral in ccudef-hmstate zu konfigurieren wäre auch wünschenswert. Man müsste aber auch einen anderen Statuswert angeben können statt dem, der im Reading aktuell ist. Es macht beispielsweise keinen Sinn den Wert von Activity in hmstate direkt zu übernehmen, es müsste bei Activity=dead nämlich stattdessen "unreachable" rauskommen. Die Logik lässt sich dabei prima aus meinem 99_myutils Schnipsel weiter vorne im Thread (https://forum.fhem.de/index.php/topic,40189.msg561772.html#msg561772) herauslesen. Die Grundlogik bei der Reihenfolge ist:
1. Zuerst echte Fehler anzeigen, die eine Bedienung des Geräte unmöglich machen. Ein entsprechender Prefix err_ o.ä. ist hier essentiell notwendig (in meinem Beispiel mit dem Kommentar versehen: eval error parameters)
2. Dann die Bediensperre, sofern INHIBIT=1|locked; Gerät lässt sich ebenfalls nicht bedienen (in meinem Beispiel mit dem Kommentar versehen: eval operational parameters)
3. Den Geräte-Arbeitsstatus, wenn es gerade aktiv ist: erst DIRECTION, wenn vorhanden und ungleich stop|0, dann WORKING wenn ungleich 0 (in meinem Beispiel mit dem Kommentar versehen: eval operational parameters)
4. Dann den Datenpunkt als Status, den das jeweilige Gerät für den Gerätestatus anbietet/verwendet; Reihenfolge MOTION, LEVEL, STATE, VALVE_STATE, ACTUAL_TEMPERATURE, CONTROL_MODE (in meinem Beispiel mit dem Kommentar versehen: eval state parameters). Für LEVEL muss berücksichtigt werden, dass Änderungen >100 laut eq3 Doku ein Spezialstatus bedeuten und der vorherige LEVEL-Wert deshalb für eine korrekte Statusanzeige erhalten bleiben muss. Außerdem braucht es die Möglichkeit die Top-Werte 100 und 0 in on bzw. off umzubenennen. Zudem ist es notwendig dies auch umdrehen zu können (100=off,0=on), weil Schalter auch (absichtlich) verkehrt herum eingebaut sein können. Das wiederum muss sich pro Gerät einzeln als Abweichung zur Norm ändern lassen.
4a. Bei vorhandenem Datenpunkt TEMPERATURE oder HUMIDITY wird die Notation für einen WEATHER Datentyp angenommen. Das bedeutet sowas wie "T: 10 °C H: 40 %". Wenn weitere Datenpunkte für WIND.*, RAIN.*, SUNSHINEDURATION, BRIGHTNESS vorhanden sind, handelt es sich um eine Wetterstation und diese Werte müssen entsprechend hinzugefügt werden. Ich wollte es an dieser Stelle bisher nicht noch komplizierter machen und habe die Unterstützung von Unit.pm für die korrekte Zuweisung von Readings-Datentypen bisher nicht berücksichtigt (gleichwohl machte es dann die makeSTATE() Funktion aus Unit.pm leichter dieses Statusfeld zu erzeugen). Die Verheiratung von Unit.pm, 98_powerMap etc. mit HMCCU ist dann nochmal ein ganz eigenes Kapitel...
5. Optional könnte an dieser Stelle jetzt tatsächlich noch LOWBAT und all die anderen Warning-Only Datenpunkte angezeigt werden, sofern das Gerät eben keinen normalen Status-Datenpunkt hat. Ein entsprechender Prefix warn_ o.ä. ist hier analog zu err_ auch nötig.
6. Default Wert 'ok' sofern keiner der Status Datenpunkte vorhanden ist und UNREACH nicht 1 ist. Wenn UNREACH nicht vorhanden ist, dann ist der Default Wert "Initialized".
Warnungen wie LOWBAT sollen für hmstate keine Rolle spielen, da sie für die Bedienung des Gerätes unerheblich sind. Dafür haben wir ja gesonderte Readings und können separat reagieren. hmstate soll sich also hauptsächlich auf die Bedienfunktion konzentrieren.
Wenn sich hmstate über hmstatevals so, wie gerade beschrieben, definieren ließe (und dann noch global als ccudef-hmstatevals), dann ließe sich das Reading sinnvoll für eine Steuerung verwenden.
Außerdem ist das Reading dann dafür geeignet den Stromverbrauch mittels powerMap in akkurater Weise zu errechnen.
Nachtrag:
Ich habe jetzt nochmals versucht hmstatevals zu erraten:
UNREACH!1:unreachable;
FAULT_REPORTING!1:err_VALVE_TIGHT;
FAULT_REPORTING!2:err_ADJUSTING_RANGE_TOO_LARGE;
FAULT_REPORTING!3:err_ADJUSTING_RANGE_TOO_SMALL;
FAULT_REPORTING!5:err_UNSPECIFIED;
FAULT_REPORTING!7:err_VALVE_ERROR_POSITION;
ERROR_OVERHEAT!1:err_overheated;
ERROR_OVERLOAD!1:err_overloaded;
ERROR_REDUCED!1:err_reduced;
ERROR!1:err_1;
ERROR!2:err_2;
ERROR!3:err_3;
INHIBIT!1:locked;
DIRECTION!1:up;
DIRECTION!2:down;
DIRECTION!3:undefined;
WORKING!1:working;
MOTION!0:noMotion;
MOTION!1:motion;
LEVEL!0:off;
LEVEL!(1-99):??;
LEVEL!100:on;
STATE!.*:??;
VALVE_STATE!.*:??;
ACTUAL_TEMPERATURE!.*:??;
CONTROL_MODE!.*:??;
TEMPERATURE!.*:+T: ??;
HUMIDITY!.*:+H: ??;
WIND_SPEED!.*:+W: ??;
RAIN_COUNTER!.*:+R: ??;
RAINING!.*:+IR: ??;
WIND_DIRECTION!.*:+WD: ??;
WIND_DIRECTION_RANGE!.*:+WDR: ??;
SUNSHINEDURATION!.*:+S: ??;
BRIGHTNESS!.*:+B: ??;
FAULT_REPORTING!6:warn_battery;
LOW_BAT,LOWBAT!1:warn_battery;
ERROR!4:warn_battery;
UNREACH!0:ok;
Wie man dabei sieht, fehlt es an der Möglichkeit das bereits per ccudef-substitude umgewandeltes Value hier 1-zu-1 durchzureichen, wenn der Datenpunkt existiert (Beispiele LEVEL, STATE, VALVE_STATE, ACTUAL_TEMPERATURE, CONTROL_MODE). Deshalb die ?? in dem Beispiel.
Außerdem fehlt es für die ganzen WEATHER Datenpunkte daran diesen einen Präfix voranzustellen und sie hintereinander zu ergänzen. Die Notation dazu habe ich jetzt einfach mal erraten.
LEVEL>100 müsste auch noch so abgefangen werden, dass sich der Status dann gar nicht ändert und der vorherige LEVEL Wert erhalten bleibt.
Disclaimer: Das obige Beispiel funktioniert (derzeit) gar nicht, also z.B. auch nichtmal für Bewegungsmelder mit dem Datenpunkt MOTION.
Gruß
Julian
ZitatWas mir dabei nicht klar ist, auf welcher Grundlage ihr meint die umgeschriebenen Readings zusätzlich zu den Ausgangsreadings erzeugen zu müssen (also mit der '+' Notation).
die grundlage für die (korekten) readings sind die datenpunkte wie sie eq3 beschreibt (das ist ein definierter, dokumentierter standard bezogen auf homematic produkte).
die möchte ich schon gerne haben/sehen. die umgeschriebenen readings erzeuge ich nur um readings an gepflogenheiten in fhem anzupassen (mach einer bezeichnet diese fälschlicherweise als"standards" ;) ) , da dies das arbeiten mit einigen anderen modulen (wie dewpoint zb) erleichtert bzw eine einheitliche namensgebung geräteübergreifend erfmöglicht (ich könnte auch einfach die anderen readings per userreadings an die datenpunkte anpassen da diese in der minderzahl sind aber per hmccu gehts das nun deutlich einfacher). und die doppelten readings (sind ja eh nicht alle) fressen kein heu
Zitat von: chris1284 am 23 Januar 2017, 13:21:30
die grundlage für die (korekten) readings sind die datenpunkte wie sie eq3 beschreibt (das ist ein definierter, dokumentierter standard bezogen auf homematic produkte).
Ich weiß, dieses Dokument habe IMHO ich ins Spiel gebracht; darauf beziehe ich mich seit Anbeginn ;)
Zitat von: chris1284 am 23 Januar 2017, 13:21:30
die möchte ich schon gerne haben/sehen. die umgeschriebenen readings erzeuge ich nur um readings an gepflogenheiten in fhem anzupassen (mach einer bezeichnet diese fälschlicherweise als"standards" ;) ) , da dies das arbeiten mit einigen anderen modulen (wie dewpoint zb) erleichtert bzw eine einheitliche namensgebung geräteübergreifend erfmöglicht
Mir ist schon klar, warum man das macht (auch wenn es IMHO keine FHEM Gepflogenheiten sind, sondern zum übermäßigen Teil sinnvolle Änderungen in Richtung "Human readability"). Was mit nicht klar ist, wie man sich entscheiden soll, ein Reading doppelt zu führen und ein anderes nicht. Für mich ergibt sich daraus kein Mehrwert, wenn ich habe den Wert ja nach wie vor als umbenanntes Reading und was ich nicht umbenenne bleibt im eq-3 Original. Kann sicher jeder machen, wie sie/er möchte. Ich wollte nur verstehen wie man da logisch drüber entscheidet wann mit und wann ohne +.
ZitatIch wollte nur verstehen wie man da logisch drüber entscheidet wann mit und wann ohne +.
bei mir richtet sich das allein nach schnittmengen mit anderen devices und modulen (zb dewpoint übergreifende für hmccu, hms, weather usw).
des weiteren habe ich seit hmcuu eine tui instanz die ich, bei verzicht auf die eq3 readings, erstmal komplett überarbeiten müsste. wenn ich lust und zeit hab das zu tun werde ich sicher auch das ein oder ander "+" entfernen. die config readings R-<Channel>.Datapoint müsste man ja auch noch "übersetzen" um sich cul_hm anzugleichen
Zitat von: chris1284 am 23 Januar 2017, 13:40:25
des weiteren habe ich seit hmcuu eine tui instanz die ich, bei verzicht auf die eq3 readings, erstmal komplett überarbeiten müsste.
Ok. Wir diskutieren hier aber doch IMHO, was wir als Standardvorgabe mit ins Template aufnehmen können. Eigene Bequemlichkeiten zählen da nicht dazu ;)
Bisher habe ich nicht gehört, warum man ins Default-Template etwas mit + aufnehmen müsste (außer wegen dem pct/level Kompatibilitätseintrag für LEVEL).
Zitat von: chris1284 am 23 Januar 2017, 13:40:25
die config readings R-<Channel>.Datapoint müsste man ja auch noch "übersetzen" um sich cul_hm anzugleichen
Das ist sicherlich eher die Kür, weil es für die Bedienung der Geräte nicht notwendig ist und man die Programmierung ja eher in der CCU vornimmt (das verstehe zumindest ich unter "Best of both worlds"). Wenn du dich aber daran wagen möchtest, nur zu :D
Zitat von: Loredo am 23 Januar 2017, 13:45:04
Eigene Bequemlichkeiten zählen da nicht dazu ;)
ähm das hat nichts mit bequemlichkeit zu tun. diese readingsnamen (die hmccu seit anbeginn der module pflegte und pflegt)
waren und sind der standard der module. alles was darauf aufgebaut wurde sollte man nicht unter bequemlichkeit abtun und einfach abschneiden und sagen wer das noch will sei zu bequem alles wieder umzubauen.
jetzt eine Standardvorgabe ins template zu setzen die alles komplett umwirft was es bisher in hmccu gab wäre falsch, der parallele weg (+) der kompatibelste und beste.
das wäre so als würde man nun in cul_hm einfach von heute auf morgen datapoints als readings einsetzen und alle bisherigen readings entfernen-> großer mist
die readings im cul_hm-format sind wie ich finde immernoch als nettes feature zu sehen (für evtl bequeme leute die mal cul_hm einsetzten) und nicht als default-template (außer als 2. reading halt, denn die stören bestandsinstallationen nicht sollte man templates per default aktivieren ).
Hallo,
ich habe HMCCU eingerichtet und HMCCUDEV für meine Wetterstation.
In HMCCUDEV habe ich datapoint mit 1.TEMPERATURE angelegt.
leider ändert sich der Wert der Temperatur nicht
1.TEMPERATURE -0.800000 2017-01-23 15:21:55
hmstate Initialized 2017-01-23 15:40:01
state Initialized 2017-01-23 15:21:15
Muss ich noch was setzen?
Ciao Fini
Zitat von: Loredo am 23 Januar 2017, 13:20:34
Nachtrag:
Ich habe jetzt nochmals versucht hmstatevals zu erraten:
Das hat eigentlich nichts mit Erraten zu tun. Ich versuche mal, die Logik hinter hmstate zu beschreiben:
- Bei jeder Datenpunkt Änderung eines Geräts berechnet HMCCU hmstate neu.
- Die Neuberechnung ermittelt zunächst den aktuellen Wert aller Datenpunkte, die zum Muster "^(UNREACH|LOWBAT|LOW_BAT|ERROR.*|FAULT_REPORTING|SABOTAGE)$" passen.
- Im Anschluss werden die Datenpunkte "normalisiert", d.h. alle ERROR_xxx werden zu ERROR, alle FAULT_xxx werden zu FAULT, LOW_BAT zu LOWBAT. Außerdem werden die Werte true/false durch 1/0 ersetzt.
- Nun wird geprüft, ob einer der normalisierten Datenpunkte >0 ist, d.h. einen Fehler anzeigt. Dabei wird nach folgender Reihenfolge vorgegangen: 'UNREACH', 'ERROR', 'FAULT', 'SABOTAGE', 'LOWBAT'.
- Der erste Wert, der die Bedingung >0 erfüllt, ergibt das neue hmstate. Durch die Priorisierung ist gewährleistet, dass hmstate immer den kritischsten Wert beinhaltet. Da die Bedeutung der Fehlercodes (Werte > 0) je nach Gerätetyp unterschiedlich sein kann, holt sich HMCCU die entsprechenden Ersetzungen aus dem Attribut 'hmstatevals'. Für viele Gerätetypen habe ich in HMCCUConf.pm hmstatevals definiert. Man kann die Fehler darüber natürlich auch anders benennen, z.B. "err_xxx"
- Wenn keiner der Werte die Bedingung > 0 erfüllt, also kein Fehler vorliegt, wird hmstate = state gesetzt. Dabei werden natürlich die Standard Wertemappings aus substitute übernommen.
Ein globales Attribut ccudef-hmstatevals macht keinen Sinn, da wie gesagt die Bedeutung der Codes je nach Gerätetyp unterschiedlich ist. Ich könnte allerdings substitute berücksichtigen. Das würde hmstatevals obsolet machen (mal sehen).
Zum Thema Ausgestaltung des Attributs ccudef-readingname: Ich möchte nicht in den Defaults die Originaldatenpunkte ersetzen. Sonst werden Nutzer, die aus der CCU2 Umgebung kommen, noch mehr verwirrt. Insofern ist die Duplizierung von Readings m.E. ein guter Kompromiss. Es steht ja jedem frei, das Attribut an die eigenen Bedürfnisse anzupassen.
Zitat von: fini am 23 Januar 2017, 15:43:48
Hallo,
ich habe HMCCU eingerichtet und HMCCUDEV für meine Wetterstation.
In HMCCUDEV habe ich datapoint mit 1.TEMPERATURE angelegt.
leider ändert sich der Wert der Temperatur nicht
1.TEMPERATURE -0.800000 2017-01-23 15:21:55
hmstate Initialized 2017-01-23 15:40:01
state Initialized 2017-01-23 15:21:15
Muss ich noch was setzen?
Ciao Fini
Verm. läuft der RPC-Server nicht. Wenn Dein HMCCU-Device "myccu" heißt, musst Du noch folgendes machen:
attr myccu rpcserver on
attr myccu rpcport 2001
set myccu rpcserver on
Falls Du Homematic IP verwendest, ergänze setze rpcport auf 2001,2010
Zitat von: chris1284 am 23 Januar 2017, 15:26:53
ähm das hat nichts mit bequemlichkeit zu tun. diese readingsnamen (die hmccu seit anbeginn der module pflegte und pflegt) waren und sind der standard der module.
Die neuen Attribute ccudef-readingsname und ccudef-substitude gehören aber nicht dazu. Warum soll jemand, der neu startet es unbequemer haben als jemand, der schon länger HMCCU benutzt? Ein Neuling versteht nicht, weshalb ein und derselbe Wert doppelt unter zwei Namen auftaucht und dass nun er derjenige sein soll, der sich das aus dem Standard-Attribut raus konfigurieren muss (und erstmal gar nicht weiß wie das geht).
Wenn du eine
neue Funktion
zusätzlich verwenden willst, musst du damit rechnen, dass
du zusätzlichen Aufwand hast. Folglich ist es nur fair, dass du dir die + Zeichen an die richtigen Stellen schreiben musst, weil auch nur du weißt, wo du das haben willst und warum du es brauchst.
Es besteht ja überhaupt keine Gefahr, du musst ja bei einem bestehenden Setup explizit ccudef-readingsname und ccudef-substitude setzen. Da hast du dich vorher eh informiert, wozu du das willst, nicht?
Zitat von: chris1284 am 23 Januar 2017, 15:26:53
die readings im cul_hm-format sind wie ich finde immernoch als nettes feature zu sehen (für evtl bequeme leute die mal cul_hm einsetzten) und nicht als default-template (außer als 2. reading halt denn die stören bestandsinstallationen nicht)
Das sehe ich anders.
In der Tat hat es nämlich
hier ganz sicher nichts mit Bequemlichkeit zu tun, sondern zum Beispiel
a) mit der Notwendigkeit Values verständlich darzustellen, um besser erkennen zu können, was sie bedeuten (ein Wert 0-3 sagt nicht viel aus). Es macht keinen Sinn, dass jeder sich selbst in die eq-3 Dokumentation einlesen muss, nur um die selbe Information daraus zu extrahieren, wie alle anderen.
b) damit Homematic Geräte mit anderen Geräten kombinierbar zu machen, ohne dass sich jeder den Aufwand dafür wieder allein im stillen Kämmerlein machen muss, obwohl 100erte andere die selbe Aufgabe lösen oder schon gelöst haben. Da fallen mir sofort meine aktuellen Projekte powerMap und Unit zu ein... ohne
hmstatus stateHM sinnlos. Andere Modulautoren geben sich auch immens Mühe damit, dass sie sich in das FHEM Ökosystem möglichst gut eingliedern. Ich will einfach nicht begreifen, warum das hier so schwer zu verstehen ist...
c) um vorhandene Codeschnipsel aus der Community übernehmen zu können, ohne sie ins kleinste Detail verstehen zu müssen.
d) schnelle Erfolgserlebnisse zu haben, damit FHEM Spaß macht und man sich langsam vortasten kann (ich weiß, ist selbst Rudi egal).
Ist ja schön, dass es euch Spaß macht beim Zusammenfassen aller Lichter aus Homematic, HUE und FS20 in einer Structure die HMCCU Geräte einzeln und jedes für sich so mit eventmap und co umzubiegen, dass der Gruppenstatus richtig erzeugt wird. Sowas ist doch unnötige, sich noch potenzierende Arbeit.
Zitat von: zap am 23 Januar 2017, 15:54:56
- Die Neuberechnung ermittelt zunächst den aktuellen Wert aller Datenpunkte, die zum Muster "^(UNREACH|LOWBAT|LOW_BAT|ERROR.*|FAULT_REPORTING|SABOTAGE)$" passen.
Kann man das flexibel machen, damit mein theoretisches Beispiel (https://forum.fhem.de/index.php/topic,40189.msg567596.html#msg567596) damit funktioniert? Ich möchte den
Gerätestatus abgebildet haben, nicht den
Fehlerstatus. Außerdem ist nicht generell alles was >1 ein echter Fehler, sondern ggf. nur eine Warnung und die möchte ich nicht bei jedem Gerät priorisiert angezeigt haben.
Sabotage z.B. will man auch unberücksichtigt lassen können, wenn man einen Bewegungsmelder hat, der nirgends montiert ist.
Zitat von: zap am 23 Januar 2017, 15:54:56
- Im Anschluss werden die Datenpunkte "normalisiert", d.h. alle ERROR_xxx werden zu ERROR, alle FAULT_xxx werden zu FAULT, LOW_BAT zu LOWBAT. Außerdem werden die Werte true/false durch 1/0 ersetzt.
Das ist eher schlecht, weil der nummerische Wert der Datenpunkte jeweils unterschiedliche Bedeutung haben kann. Siehe mein hypothetisches Beispiel (https://forum.fhem.de/index.php/topic,40189.msg567596.html#msg567596) wie hmstatevals in etwa aussehen müsste.
Zitat von: zap am 23 Januar 2017, 15:54:56
- Nun wird geprüft, ob einer der normalisierten Datenpunkte >0 ist, d.h. einen Fehler anzeigt. Dabei wird nach folgender Reihenfolge vorgegangen: 'UNREACH', 'ERROR', 'FAULT', 'SABOTAGE', 'LOWBAT'.
Das ist zu unflexibel bzw. zu generell. Bei FAULT_REPORTING sind auch Warnungen enthalten und nicht nur Fehler. 6/LOWBAT ist nur eine Warnung und ist weniger wichtig als der Gerätestatus insgesamt, 4/COMMUNICATION_ERROR kann immer mal vorkommen, hindert u.U. aber nicht daran das Gerät generell noch zu bedienen und ist deshalb ebenfalls nicht entscheidend für den Gerätestatus.
Zitat von: zap am 23 Januar 2017, 15:54:56
- Der erste Wert, der die Bedingung >0 erfüllt, ergibt das neue hmstate. Durch die Priorisierung ist gewährleistet, dass hmstate immer den kritischsten Wert beinhaltet. Da die Bedeutung der Fehlercodes (Werte > 0) je nach Gerätetyp unterschiedlich sein kann, holt sich HMCCU die entsprechenden Ersetzungen aus dem Attribut 'hmstatevals'. Für viele Gerätetypen habe ich in HMCCUConf.pm hmstatevals definiert. Man kann die Fehler darüber natürlich auch anders benennen, z.B. "err_xxx"
Nach dieser Beschreibung müsste dein Reading hmerrorstate benannt werden. Das ist nicht das, wovon ich die ganze Zeit spreche.
Ich kann damit nicht mein myHMCCUstate() in 99_myUtils ersetzen, obwohl du der Meinung bist, dass das zu 100% möglich wäre. Ich kann mir das nur so erklären, dass du es dir gar nicht näher angeschaut hast. Ich hoffe daher, dass mein Beispiel für hmstatevals weiter vorne (https://forum.fhem.de/index.php/topic,40189.msg567596.html#msg567596) ein besseres Beispiel darüber gibt, was passieren soll.
Zitat von: zap am 23 Januar 2017, 15:54:56
- Wenn keiner der Werte die Bedingung > 0 erfüllt, also kein Fehler vorliegt, wird hmstate = state gesetzt. Dabei werden natürlich die Standard Wertemappings aus substitute übernommen.
Das ist irgendwie nichts halbes und nichts ganzes, denn den Gerätestatus erst an dieser Stelle zu erfahren ist für die Geräte
steuerung nichts mehr wert. Du könntest genauso gut "no error" reinschreiben.
Zitat von: zap am 23 Januar 2017, 15:54:56
Das hat eigentlich nichts mit Erraten zu tun.
Doch. Denn wie du erkennen kannst, hast du mit deiner Aussage "du kannst damit komplett deine Funktion in 99_myUtils ersetzen" ganz andere Erwartungen ausgelöst. Die Dokumentation des Attributs hmstatevals gab das aber nicht her. Nach deiner ausführlichen Beschreibung weiß ich nun auch weshalb aber leider auch, weshalb es mir eher sinnfrei erscheint (möge mir gerne jemand sagen, was er mit hmstate jetzt wirklich besser machen kann, als die eq-3 Originalreadings entsprechend auszuwerten).
Zitat von: zap am 23 Januar 2017, 16:01:19
Verm. läuft der RPC-Server nicht. Wenn Dein HMCCU-Device "myccu" heißt, musst Du noch folgendes machen:
attr myccu rpcserver on
attr myccu rpcport 2001
set myccu rpcserver on
Falls Du Homematic IP verwendest, ergänze setze rpcport auf 2001,2010
habe jetzt alles noch mal neu eingerichtet
der Wert der Temperatur ändert sich nicht
ist immer -0.700000
müsste aber -0.800000 sein
Ganz ehrlich: Ich verstehe das unten überhaupt nicht. Ist das der Inhalt eines ccudef-substitute? Wenn ja: Du möchtest also überhaupt keine separaten substitutes mehr in einzelnen Devices definieren, sondern alles über ein globales ccudef-substitute abhandeln? All diese Datenpunkte werden ja niemals in einem Gerät gleichzeitig vorkommen.
Oder meinst Du ein globales hmstatevals, in dem Du festlegen kannst, dass in einem Reading hmstate z.B. drin stehen kann "die Aussentemperatur ist gerade xy Grad"?
Eine globale Festlegung wird nicht möglich sein. Der Wert ERROR=1 kann bei Gerätetyp A eine andere Bedeutung haben als bei Typ B. Bei Wertemengen von identischen Datenpunkten gibt es Unterschiede zwischen HM-IP und klassischem HomeMatic. Deshalb können ccudef-readingname und ccudef-substitute nur Datenpunkte und Werte enthalten, die für alle Typen gelten.
Zitat von: Loredo am 23 Januar 2017, 13:20:34
Nachtrag:
Ich habe jetzt nochmals versucht hmstatevals zu erraten:
UNREACH!1:unreachable;
FAULT_REPORTING!1:err_VALVE_TIGHT;
FAULT_REPORTING!2:err_ADJUSTING_RANGE_TOO_LARGE;
FAULT_REPORTING!3:err_ADJUSTING_RANGE_TOO_SMALL;
FAULT_REPORTING!5:err_UNSPECIFIED;
FAULT_REPORTING!7:err_VALVE_ERROR_POSITION;
ERROR_OVERHEAT!1:err_overheated;
ERROR_OVERLOAD!1:err_overloaded;
ERROR_REDUCED!1:err_reduced;
ERROR!1:err_1;
ERROR!2:err_2;
ERROR!3:err_3;
INHIBIT!1:locked;
DIRECTION!1:up;
DIRECTION!2:down;
DIRECTION!3:undefined;
WORKING!1:working;
MOTION!0:noMotion;
MOTION!1:motion;
LEVEL!0:off;
LEVEL!(1-99):??;
LEVEL!100:on;
STATE!.*:??;
VALVE_STATE!.*:??;
ACTUAL_TEMPERATURE!.*:??;
CONTROL_MODE!.*:??;
TEMPERATURE!.*:+T: ??;
HUMIDITY!.*:+H: ??;
WIND_SPEED!.*:+W: ??;
RAIN_COUNTER!.*:+R: ??;
RAINING!.*:+IR: ??;
WIND_DIRECTION!.*:+WD: ??;
WIND_DIRECTION_RANGE!.*:+WDR: ??;
SUNSHINEDURATION!.*:+S: ??;
BRIGHTNESS!.*:+B: ??;
FAULT_REPORTING!6:warn_battery;
LOW_BAT,LOWBAT!1:warn_battery;
ERROR!4:warn_battery;
UNREACH!0:ok;
Wie man dabei sieht, fehlt es an der Möglichkeit das bereits per ccudef-substitude umgewandeltes Value hier 1-zu-1 durchzureichen, wenn der Datenpunkt existiert (Beispiele LEVEL, STATE, VALVE_STATE, ACTUAL_TEMPERATURE, CONTROL_MODE). Deshalb die ?? in dem Beispiel.
Außerdem fehlt es für die ganzen WEATHER Datenpunkte daran diesen einen Präfix voranzustellen und sie hintereinander zu ergänzen. Die Notation dazu habe ich jetzt einfach mal erraten.
LEVEL>100 müsste auch noch so abgefangen werden, dass sich der Status dann gar nicht ändert und der vorherige LEVEL Wert erhalten bleibt.
Disclaimer: Das obige Beispiel funktioniert (derzeit) gar nicht, also z.B. auch nichtmal für Bewegungsmelder mit dem Datenpunkt MOTION.
Gruß
Julian
Zitat von: zap am 23 Januar 2017, 17:33:50
Ganz ehrlich: Ich verstehe das unten überhaupt nicht. Ist das der Inhalt eines ccudef-substitute? Wenn ja: Du möchtest also überhaupt keine separaten substitutes mehr in einzelnen Devices definieren, sondern alles über ein globales ccudef-substitute abhandeln? All diese Datenpunkte werden ja niemals in einem Gerät gleichzeitig vorkommen.
Oder meinst Du ein globales hmstatevals, in dem Du festlegen kannst, dass in einem Reading hmstate z.B. drin stehen kann "die Aussentemperatur ist gerade xy Grad"?
Eine globale Festlegung wird nicht möglich sein. Der Wert ERROR=1 kann bei Gerätetyp A eine andere Bedeutung haben als bei Typ B. Bei Wertemengen von identischen Datenpunkten gibt es Unterschiede zwischen HM-IP und klassischem HomeMatic. Deshalb können ccudef-readingname und ccudef-substitute nur Datenpunkte und Werte enthalten, die für alle Typen gelten.
ich möchte einfach nur die Aktuelle Aussentemperatur ???
Egel wie ... dachte nur es geht so wie in den beiden Bildern.
Wenn es anders geht?
Wind, Sonne u.s.w. sollen auch noch kommen.
Die Werte möchte ich dann in die Tablet UI einbinden.
Zitat von: zap am 23 Januar 2017, 17:33:50
Ganz ehrlich: Ich verstehe das unten überhaupt nicht. Ist das der Inhalt eines ccudef-substitute?
Nein, aber schön, dass sich die ganzen Attribute und Varianten inzwischen auch verwirren :P
Zitat von: zap am 23 Januar 2017, 17:33:50
Ist das der Inhalt eines ccudef-substitute?
Nein, ich rede hier nicht von ccudef-substitude, sondern vom Attribut hmstatevals.
Es handelt sich um meinen Versuch dir in deiner Sprache bzw.
fiktiver HMCCU-Notation zu erklären, wie mein Custom Script myHMCCUstate() (https://forum.fhem.de/index.php/topic,40189.msg561772.html#msg561772) zur Erzeugung eines Reading namens "stateHM" funktioniert und wie HMCCU's hmstate funktionieren und was es können sollte. Was du in dem Beitrag siehst, den du gerade zitiert hast (https://forum.fhem.de/index.php/topic,40189.msg567596.html#msg567596), ist der Inhalt des Attributs hmstatevals, sofern es so funktionieren würde, wie ich es nach deiner "geht doch alles damit" Aussage erwartet habe.
Ich habe eigentlich alles verlinkt, aber die muss man natürlich auch anklicken. ???
Dieser Versuch der Erklärung war also wohl leider vergeblich :(
Zitat von: zap am 23 Januar 2017, 17:33:50
Wenn ja: Du möchtest also überhaupt keine separaten substitutes mehr in einzelnen Devices definieren
Doch, aber selbstverständlich! Das muss immer möglich sein für Ausnahmen.
Zitat von: zap am 23 Januar 2017, 17:33:50
sondern alles über ein globales ccudef-substitute abhandeln? All diese Datenpunkte werden ja niemals in einem Gerät gleichzeitig vorkommen.
Ich möchte selbstverständlich alles möglichst an einer einzigen Stelle konfigurieren und nur die Ausnahmen an den Geräten selbst.
Das mache ich ja jetzt auch schon so und es funktioniert auch prima über ccudef-substitude (wobei ich noch nicht probiert habe substitute jetzt mit einer Ausnahme an einem Gerät zu definieren).
Dass nicht alle Datenpunkte gleichzeitig bei einem einzelnen Gerät vorkommen können ist ja gerade das tolle: Ist es vorhanden greifen die Einstellungen, ist es nicht vorhanden macht es auch nichts das zentral mit drin zu haben, damit es für andere Geräte greifen kann.
Ich wundere mich gerade etwas darüber, dass es an dieser Stelle nun gerade so zu funktionieren scheint, wie ich es erwartet habe, es aber offenbar gar keine Absicht ist. Das macht mir etwas Sorgen...
Zitat von: zap am 23 Januar 2017, 17:33:50
Oder meinst Du ein globales hmstatevals, in dem Du festlegen kannst, dass in einem Reading hmstate z.B. drin stehen kann "die Aussentemperatur ist gerade xy Grad"?
Ein Attribut ccudef-hmstatevals wäre sehr wünschenswert, um nicht den selben Text bei jedem HMCCU.+ Device im Attribut hmstate stehen zu haben.
Ich will aber da keinen Langtext rein schreiben, ist aber sicher schön, wenn man es könnte.
Die von mir beschriebene Logik lässt sich eigentlich extrem einfach in myHMCCUstate() (https://forum.fhem.de/index.php/topic,40189.msg561772.html#msg561772) nachvollziehen. Die fiktive hmstatevals Notation habe ich nur deshalb geschrieben, weil ich annahm, dass es für dich leichter wäre nachzuvollziehen. Ich habe ja auch extra noch hier (https://forum.fhem.de/index.php/topic,40189.msg567517.html#msg567517) beschrieben, was von der Logik-Reihenfolge passieren soll (die Punkte beschriftet mit 1., 2., 3., 4., 4a., 5., 6.). Hast du das wenigstens gelesen und verstanden?
Ich weiß auch nicht was ich noch machen soll, um es dir zu erklären. :-[ Nachdenken und nachvollziehen müsstest du es schon selbst.
Zitat von: zap am 23 Januar 2017, 17:33:50
Eine globale Festlegung wird nicht möglich sein. Der Wert ERROR=1 kann bei Gerätetyp A eine andere Bedeutung haben als bei Typ B. Bei Wertemengen von identischen Datenpunkten gibt es Unterschiede zwischen HM-IP und klassischem HomeMatic.
Wir reden über ccudef-hmstatevals, ja? Gut.
Der ERROR Wert hat sicherlich unterschiedliche Bedeutung. Das heißt aber nicht, dass ich nicht global zumindest festlegen könnte, dass dort einfach nur ein Text wie err_1, err_2 und so weiter stehen kann. Wenn ich es dabei genauer haben wollen würde, dann könnte ich ja im Gerät eine spezifischere Definition hinterlegen.
Bei wem ein Mix auf HM-IP und HM-Classic zu Überschneidungen führt, kann ja dann andere Definitionen an den Geräten selbst hinterlegen oder ganz auf die ccudef-Variante verzichten.
Zitat von: zap am 23 Januar 2017, 17:33:50
Deshalb können ccudef-readingname und ccudef-substitute nur Datenpunkte und Werte enthalten, die für alle Typen gelten.
Das hat jetzt nichts mit hmstatevals zu tun, daher verwirrt mich der Satz an dieser Stelle.
Grundsätzlich hast du hier Recht. "können" wäre aber besser als "sollten" gelten, denn es kann für viele Installationen trotzdem Sinn machen das zu tun. Ich habe in ccudef-readingname auch STATE mit drin, um die führenden Ziffern zu entfernen, weiß aber, dass ich dabei aufpassen muss. Das ist auch nichts, was ich für ein Default-Setting vorschlagen würde, was HMCCU mitliefert.
Zitat von: fini am 23 Januar 2017, 17:57:38
ich möchte einfach nur die Aktuelle Aussentemperatur ???
Egel wie ... dachte nur es geht so wie in den beiden Bildern.
Wenn es anders geht?
Wind, Sonne u.s.w. sollen auch noch kommen.
Die Werte möchte ich dann in die Tablet UI einbinden.
Mein Beitrag bezog sich auf die laufende Diskussion mit Loredo. Das hat nichts mit Deinem Problem zu tun. In Deinem Fall:
Wann hast Du das letzte Update von FHEM gemacht? Mach bitte ein "update check" und prüfe, ob Dir 88_HMCCU.pm bzw. HMCCUConf.pm als Update angeboten werden. Wenn ja, mache ein update.
Alternativ: Setze das Attribut ccudef-readingfilter im HMCCU-Device auf .*
Um den RPC-Server wieder ans Laufen zu bekommen, stoppe FHEM, kille die übrig gebliebenen fhem.pl Prozesse und starte wieder FHEM.
P.S. wer hat hier im FHEM Forum eigentlich damit angefangen, alle Fragen zu einem Modul in den gleichen Thread zu packen? Ich habe das bisher in keinem anderen Forum so extrem erlebt wie hier. Wenn ich hier Threads sehe mit >1000 Beiträgen und >100000 Aufrufen, kann ich nur den Kopf schütteln. Und diese Threads gibt es reichlich.
Aber das nur am Rande. Und keine Angst, ich lesen und schreibe hier weiterhin, auch wenn ich es besser finden würde, wenn man für separate Probleme separate Threads starten würde.
Zitat von: fini am 23 Januar 2017, 17:57:38
ich möchte einfach nur die Aktuelle Aussentemperatur ???
Egel wie ... dachte nur es geht so wie in den beiden Bildern.
Wenn es anders geht?
Wind, Sonne u.s.w. sollen auch noch kommen.
Die Werte möchte ich dann in die Tablet UI einbinden.
Hi, müsste da nicht noch ein "attr device event-on-change-reading .*" hin?
VG
Christian
Zitat von: zap am 23 Januar 2017, 18:48:16
Mein Beitrag bezog sich auf die laufende Diskussion mit Loredo. Das hat nichts mit Deinem Problem zu tun. In Deinem Fall:
Wann hast Du das letzte Update von FHEM gemacht? Mach bitte ein "update check" und prüfe, ob Dir 88_HMCCU.pm bzw. HMCCUConf.pm als Update angeboten werden. Wenn ja, mache ein update.
Alternativ: Setze das Attribut ccudef-readingfilter im HMCCU-Device auf .*
Um den RPC-Server wieder ans Laufen zu bekommen, stoppe FHEM, kille die übrig gebliebenen fhem.pl Prozesse und starte wieder FHEM.
P.S. wer hat hier im FHEM Forum eigentlich damit angefangen, alle Fragen zu einem Modul in den gleichen Thread zu packen? Ich habe das bisher in keinem anderen Forum so extrem erlebt wie hier. Wenn ich hier Threads sehe mit >1000 Beiträgen und >100000 Aufrufen, kann ich nur den Kopf schütteln. Und diese Threads gibt es reichlich.
Aber das nur am Rande. Und keine Angst, ich lesen und schreibe hier weiterhin, auch wenn ich es besser finden würde, wenn man für separate Probleme separate Threads starten würde.
jetzt zeigt er alle Werte an ...
Aktualisiert werden aber nur die Channels 1
Bei statechannel steht auch nur 1
Wie bekomme ich Channel 1 und 2 hin?
Zitat von: fini am 23 Januar 2017, 19:17:27
jetzt zeigt er alle Werte an ...
Aktualisiert werden aber nur die Channels 1
Bei statechannel steht auch nur 1
Wie bekomme ich Channel 1 und 2 hin?
Ändere mal bitte die Definition des Gerätes. Lasse die 1 am Ende weg. Der Statechannel spielt hier keine Rolle.
Achte bitte darauf, dass im HMCCU Device ccudef-readingfiltet = .* ist. Führe dann im HMCCUDEV Device mal den Befehl "get update" aus. Es sollten dann alle Readings angezeigt werden.
@Loredo:
Eine Frage zu Deiner Funktion. Wenn man jetzt mal diesen Ausschnitt betrachtet:
# eval error parameters
if ( defined( $p->{UNREACH} ) && $p->{UNREACH} =~ /^(1|true|dead)$/i ) {
$stateHM = "unreachable";
}
# eval operational parameters
elsif ( defined( $p->{TEMPERATURE} ) || defined( $p->{HUMIDITY} ) ) {
...
}
# eval warning parameters
elsif ( defined( $p->{LOW_BAT} )
&& $p->{LOW_BAT} =~ /^(1|true|low)$/i )
{
$stateHM = "warn_battery";
}
Dann wird m.E. ein LOWBAT niemals in stateHM signalisiert, da die operational parameters immer existieren.
Daher war mein Ansatz: Wenn Fehler oder Warnings existieren, setze hmstate auf diese. Wenn nicht, setze hmstate = state. Letzteres hat den Nachteil, dass keine Kombination von Werten möglich ist. Könnte man aber so ändern:
1. Wenn ein Fehler existiert, setze hmstate auf den Fehler (so wie jetzt)
2. Wenn ein Warning existiert, setze hmstate auf das Warning (so wie jetzt)
3. In allen anderen Fällen setze hmstate = STATE. Das kann man dann per stateFormat individuell festlegen.
Zitat von: zap am 23 Januar 2017, 19:23:39
Ändere mal bitte die Definition des Gerätes. Lasse die 1 am Ende weg. Der Statechannel spielt hier keine Rolle.
Achte bitte darauf, dass im HMCCU Device ccudef-readingfiltet = .* ist. Führe dann im HMCCUDEV Device mal den Befehl "get update" aus. Es sollten dann alle Readings angezeigt werden.
habe es noch mal angelegt
define Wetterstation HMCCUDEV NEQ0343659
jetzt erscheinen nur die Channels 1 und werden auch aktualisiert
ccudef-readingfiltet = .*, was bedeutet das?
habe ich eingetragen
jetzt steht unter Attributes zusätzlich:
ccudef-readingfilter .* deleteattr
noch eine Frage, mit deficeinfo kommt:
CHN NEQ0343659:0 Wetterstation:0
DPT {b} BidCos-RF.NEQ0343659:0.UNREACH = false [RE]
DPT {b} BidCos-RF.NEQ0343659:0.STICKY_UNREACH = false [RWE]
DPT {b} BidCos-RF.NEQ0343659:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.NEQ0343659:0.LOWBAT = false [RE]
DPT {n} BidCos-RF.NEQ0343659:0.RSSI_DEVICE = 1 [RE]
DPT {n} BidCos-RF.NEQ0343659:0.RSSI_PEER = 212 [RE]
DPT {b} BidCos-RF.NEQ0343659:0.DEVICE_IN_BOOTLOADER = false [RE]
DPT {b} BidCos-RF.NEQ0343659:0.UPDATE_PENDING = false [RE]
CHN NEQ0343659:1 Wetterstation:1
DPT {f} BidCos-RF.NEQ0343659:1.TEMPERATURE = -0.700000 [RE]
DPT {i} BidCos-RF.NEQ0343659:1.HUMIDITY = 99 [RE]
DPT {b} BidCos-RF.NEQ0343659:1.RAINING = false [RE]
DPT {f} BidCos-RF.NEQ0343659:1.RAIN_COUNTER = 112.395000 [RE]
DPT {f} BidCos-RF.NEQ0343659:1.WIND_SPEED = 1.200000 [RE]
DPT {i} BidCos-RF.NEQ0343659:1.WIND_DIRECTION = 100 [RE]
DPT {i} BidCos-RF.NEQ0343659:1.WIND_DIRECTION_RANGE = 67 [RE]
DPT {i} BidCos-RF.NEQ0343659:1.SUNSHINEDURATION = 227 [RE]
DPT {i} BidCos-RF.NEQ0343659:1.BRIGHTNESS = 0 [RE]
DPT {f} Luftfeuchte Max Heute = 99.000000 [RWE]
DPT {f} Luftfeuchte Min Heute = 99.000000 [RWE]
DPT {f} Temp Max Heute = -0.600000 [RWE]
DPT {f} Temp Min Heute = -3.400000 [RWE]
DPT {f} Wind Max Heute = 4.800000 [RWE]
DPT {f} Wind Max Gestern = 5.400000 [RWE]
DPT {f} Sonnenminuten Heute = 154.000000 [RWE]
DPT {f} Sonnenstunden Heute = 2.566667 [RWE]
DPT {f} Sonnenstunden Gestern = 2.750000 [RWE]
DPT {f} Temp Max Gestern = 4.000000 [RWE]
DPT {f} Temp Min Gestern = -3.600000 [RWE]
DPT {f} Luftfeuchte Max Gestern = 99.000000 [RWE]
DPT {f} Luftfeuchte Min Gestern = 78.000000 [RWE]
DPT {f} Helligkeit gefiltert = 0.006399 [RWE]
DPT {f} Regen heute = 0.000000 [RWE]
DPT {f} Regen gestern = 0.295000 [RWE]
wie bekomme ich noch Luftfeuchte Max Heute, Luftfeuchte Min Heute u.s.w. angezeigt?
ach so, danke für deine Hilfe!
Mach mal bitte folgendes:
attr d_ccu ccudef-readingfilter .*
get Wetterstation update
Welche Readings werden jetzt angezeigt (ggf. Seite im Browser neu laden).
Zitat von: zap am 23 Januar 2017, 20:01:57
Mach mal bitte folgendes:
attr d_ccu ccudef-readingfilter .*
get Wetterstation update
Welche Readings werden jetzt angezeigt (ggf. Seite im Browser neu laden).
hab ich gemacht. sieht jetzt so aus:
der sensor hat nur folgende datenpunkte
TEMPERATURE float
HUMIDITY intege
RAINING boolean
RAIN_COUNTER float
WIND_SPEED float
WIND_DIRECTION
WIND_DIRECTION_RANGE
SUNSHINEDURATION integer
BRIGHTNESS integer
ZitatLuftfeuchte Max Heute, Luftfeuchte Min Heute u.s.w. angezeigt?
das sind sicher errechnete werte wie beim ks300 in fhem und wären dann durch dich/ddas modul zu erstellen (eigentlich logisch weil der sensor ja für max/min/avg werte in der lage seinmüsste werte zu speichern und damit zu rechnen was er sicher nicht kann)
für die regenwerte kannst du sicher das modul rain nutzen https://fhem.de/commandref.html#rain , so hast du rain tag/stunde/gesamt. sowas bräuchts dann halt auch für hum und temp
sind denn die max/min/avg in der ccu zu sehen?
Zitat von: zap am 23 Januar 2017, 19:44:43
Wenn man jetzt mal diesen Ausschnitt betrachtet:
[...]
Dann wird m.E. ein LOWBAT niemals in stateHM signalisiert, da die operational parameters immer existieren.
Das ist für LOWBAT auch gewollt so. LOWBAT ist nichts, was mich daran hindert das Gerät weiterhin zu bedienen. Es ist lediglich ein/e Warnung/Hinweis, der aber für die Bedienung keine Rolle spielt. Eine Benachrichtigung, dass eine Batterie schwächer wird, muss separat gehandhabt werden. Nur unmittelbare Fehler, die mich tatsächlich daran hintern ein Gerät zu bedienen, sollen höher priorisiert sein (UNREACH=1, ERROR>1, einige von FAULT*).
Wie gesagt mein Ziel ist es den Bedienstatus in einem kummulierten Reading logisch zusammenzufassen. Es eignet sich
nicht nur für devStateIcon, aber wenn dir das hilft, denk dabei an devStateIcon. Wenn die Batterie schwach ist, muss natürlich noch immer ein Icon angezeigt werden, welches eine Aktion auslöst. Wenn ich aber nur weiß, dass die Batterie schwach ist, kenne ich den aktuellen Zustand des Gerätes nicht mehr und kann weder eine sinnvolle Aktion hinterlegen noch ein Icon richtig darstellen.
Zitat von: zap am 23 Januar 2017, 19:44:43
Letzteres hat den Nachteil, dass keine Kombination von Werten möglich ist.
Es geht ja nicht nur darum Werte zu kombinieren oder umzubenennen. Es geht auch darum aktuelle Werte 1-zu-1 durchzureichen, wenn die Reihenfolge entsprechend gewählt ist. Also z.B. LEVEL. Wenn der Rollladen aber gerade bedient wird und hoch oder runter fährt oder eine Leuchte gerade dimmt, dann ist DIRECTION wichtiger angezeigt zu werden (oder hilfweise WORKING, wenn es kein DIRECTION gibt). Genau das bildet meine Funktion ab.
Da du ja auch Rollladen Aktoren hast, hier einmal ein Beispiel, was du auch bei dir ausprobieren kannst, um es besser zu verstehen (mein Aktor ist kopfüber eingebaut, daher entspricht 100=offen und 0=zu):
defmod LR_ShutterSouth HMCCUCHN JEQ0109322:1
attr LR_ShutterSouth userattr g_shutters g_shutters_map structexclude
attr LR_ShutterSouth IODev CCU2
attr LR_ShutterSouth alias Rollladen Süd
attr LR_ShutterSouth ccuscaleval LEVEL:0:1:0:100
attr LR_ShutterSouth cmdIcon up:control_arrow_upward stop:time_manual_mode down:control_arrow_downward
attr LR_ShutterSouth devStateIcon 100|off:fts_window_2w:level%2055 0|on:fts_shutter_100@green:level%2055 1[0-9].*:fts_shutter_90@orange:level 2[0-9].*:fts_shutter_80@orange:level 3[0-9].*:fts_shutter_70@orange:level 4[0-9].*:fts_shutter_60@orange:level 5[0-9].*:fts_shutter_50@orange:level 6[0-9].*:fts_shutter_40@orange:level 7[0-9].*:fts_shutter_30@orange:level 8[0-9].*:fts_shutter_20@orange:level 9[0-9].*:fts_shutter_10@orange:level [1-9].*:fts_shutter_0@orange:level out|down|closing:control_arrow_downward@orange:stop in|up|opening:control_arrow_upward@orange:stop OK|ok|Ok:general_ok@green:stop unreachable:light_question err.*:light_exclamation
attr LR_ShutterSouth event-on-change-reading .*
attr LR_ShutterSouth event-on-update-reading level,pct,Activity
attr LR_ShutterSouth eventMap /datapoint STOP 1:stop/datapoint LEVEL:level/datapoint LEVEL:pct/datapoint LEVEL 100:off/datapoint LEVEL 100:in/datapoint LEVEL 100:open/datapoint LEVEL 100:up/datapoint LEVEL 0:on/datapoint LEVEL 0:out/datapoint LEVEL 0:close/datapoint LEVEL 0:down/
attr LR_ShutterSouth g_shutters g_HSE_Shutters
attr LR_ShutterSouth g_shutters_map pct:0:closed pct:100:open pct:\b[1-9]\b:halfopen pct:\b[1-9][0-9]\b:halfopen
attr LR_ShutterSouth genericDeviceType blind
attr LR_ShutterSouth group Fenster & Türen
attr LR_ShutterSouth icon fts_shutter
attr LR_ShutterSouth powerMap {\
'stateHM' => {\
'*' => '0.5',\
'down' => 121,\
'unreachable' => 0,\
'up' => 121,\
}\
}
attr LR_ShutterSouth room HMCCU,Homekit,Wohnzimmer
attr LR_ShutterSouth siriName Living Room Blind
attr LR_ShutterSouth sortby 2
attr LR_ShutterSouth stateFormat stateHM
attr LR_ShutterSouth structexclude g_LR_Shutters:devStateIcon|webCmd|group|structexclude|icon
attr LR_ShutterSouth userReadings stateHM:^(?!stateHM).* { return myHMCCUstate($name,1);; }
attr LR_ShutterSouth verbose 3
attr LR_ShutterSouth webCmd pct:up:stop:down
attr LR_ShutterSouth widgetOverride control:slider,0,5,100 pct:slider,0,5,100 level:slider,0,5,100
Ich habe noch ein paar Screenshots angehängt.
Zitat von: zap am 23 Januar 2017, 19:44:43
Könnte man aber so ändern:
1. Wenn ein Fehler existiert, setze hmstate auf den Fehler (so wie jetzt)
2. Wenn ein Warning existiert, setze hmstate auf das Warning (so wie jetzt)
3. In allen anderen Fällen setze hmstate = STATE. Das kann man dann per stateFormat individuell festlegen.
1. ok.
2. ist genau
nicht gewollt.
3. Das würde vermutlich zu einer Schleife führen. Es genügt auch nicht, weil die Prioritäten abhängig vom Betriebsstatus sowie vom Vorhandensein eines Datenpunktes abhängt (letzteres weil man das ja vornehmlich gerne zentral pflegen will und pro Device nur in Ausnahmefällen). Eigentlich hatte ich ja deshalb schon einen Vorschlag gemacht, wie ccudef-hmstatevals aussehen könnte. Das müsste doch nur von links nach rechts abgearbeitet werden so wie alle anderen Attribute auch. Auch die Sache mit dem + hast du schon, es müsste dabei eben nur alles bisherige mit ".=" angeknüpft werden. Es fehlen dann nur noch Platzhalter um zu signalisieren, dass ein Value 1-zu-1 durchgereicht werden soll und optional mit Text drum herum. Es ist doch wirklich schon fast alles da an Logik aus den anderen Attributen.
Zitat von: chris1284 am 23 Januar 2017, 21:27:09
der sensor hat nur folgende datenpunkte
TEMPERATURE float
HUMIDITY intege
RAINING boolean
RAIN_COUNTER float
WIND_SPEED float
WIND_DIRECTION
WIND_DIRECTION_RANGE
SUNSHINEDURATION integer
BRIGHTNESS integer
das sind sicher errechnete werte wie beim ks300 in fhem und wären dann durch dich/ddas modul zu erstellen (eigentlich logisch weil der sensor ja für max/min/avg werte in der lage seinmüsste werte zu speichern und damit zu rechnen was er sicher nicht kann)
für die regenwerte kannst du sicher das modul rain nutzen https://fhem.de/commandref.html#rain , so hast du rain tag/stunde/gesamt. sowas bräuchts dann halt auch für hum und temp
sind denn die max/min/avg in der ccu zu sehen?
das sind Systemvariablen die mit einen Programm berechnet werden.
Ja, die Werte sind in der CCU zu sehen.
----------------------------------------------------------------------------
Habe die Werte jetzt mit get d_ccu vars hinbekommen
Jetzt bleibt noch, wie bekomme ich die Werte der Readings in die TabletUI?
ZitatJetzt bleibt noch, wie bekomme ich die Werte der Readings in die TabletUI?
na einbauen wie alle anderen readings, per label zum beispiel (
Zitat<div data-type="label" data-device="d_ccu" data-get="Luftfeuchte Max Gestern" data-unit=" %" ></div>
)eigentlich sollten die widget mit den leerzeichen im readingsnamen klar kommen, wenn nicht musst du diese variablen halt per userreadings (am besten im wettermast device) vernünftig anlegen oder in der ccu vernünftig benamen
Einfach mal die Doku lesen von Tablet UI könnte auch hilfreich sein. ;)
moin,
hab noch ein Problem, seit den anlegen der Systemvariablen mit get d_ccu vars werden diese unter Readings angezeigt, aber nicht aktualisiert.
get update habe ich schon gemacht ...
ich denke du musst diese regelmäßig abholen (get d_ccu vars in ein at das alle 5 minuten läuft oder ein notify auf eine aktualisierung des wettermast-device in fhem welches dann get d_ccu vars ausführt und die aktuellen werte holt).
alternativ das program auf der ccu nach dem es die werte neu berechnet hat sagen es soll die werte in fhem setzen( per telnet oder url zB) wenn die ccu sowas kann
Zitat von: chris1284 am 24 Januar 2017, 08:19:38
ich denke du musst diese regelmäßig abholen (get d_ccu vars in ein at das alle 5 minuten läuft oder ein notify auf eine aktualisierung des wettermast-device in fhem welches dann get d_ccu vars ausführt
kannst du mir erklären, wie man dat genau macht?
danke für die Hilfe!
Fini
Zitat von: Yil am 19 Januar 2017, 08:10:01
hi zap,
zwei HM-LC-Sw1PBU-FM (Unterputz Schaltaktoren) melden mir seit kurzem im reading 0.LOWBAT den Wert 1, den ich üblicherweise (bei Batterie betriebenen Homematic Komponenten) mit on interpretiere. Müsste ich das hier anders auslesen/intrepretieren (per subsitutue), oder kannst Du das beheben?
VG Yil
Darf ich da nochmal nachfragen. Problem ist, dass der Wert 1 ein Notify zur Batteriewarnung auslöst - da diese Komponenten keine Batterie haben, stimmt das natürlich nicht.
VG Yil
Zitat von: fini am 24 Januar 2017, 08:14:20
moin,
hab noch ein Problem, seit den anlegen der Systemvariablen mit get d_ccu vars werden diese unter Readings angezeigt, aber nicht aktualisiert.
get update habe ich schon gemacht ...
Die RPC Schnittstelle der CCU aktualisiert keine Systemvariablen. Am einfachsten in FHEM ein AT Device anlegen und get vars ausführen lassen
Zitat von: Yil am 24 Januar 2017, 09:04:31
Darf ich da nochmal nachfragen. Problem ist, dass der Wert 1 ein Notify zur Batteriewarnung auslöst - da diese Komponenten keine Batterie haben, stimmt das natürlich nicht.
VG Yil
Den Fall kenne ich auch. Das ist ein Fehler in der CCU oder der Firmware des Gerätes. Du hast 2 Möglichkeiten:
1. mit ccureadingfilter eine Liste ohne LOWBAT definieren
2. Mit substitute den Wert explizit auf 0 setzen: LOWBAT!(0|1|false|true):0
Zitat von: zap am 24 Januar 2017, 12:37:02
Die RPC Schnittstelle der CCU aktualisiert keine Systemvariablen. Am einfachsten in FHEM ein AT Device anlegen und get vars ausführen lassen
und wie genau mach ich dat mit AT Device anlegen und get vars ausführen?
das sollte helfen. https://fhem.de/commandref.html#at
ich würde dennoch ein notify auf die änderung von readings am hmccudev des wettermasten legen. hat den vorteil das ich die vars hole wenn sie auch geändert wurden
https://fhem.de/commandref.html#notify
Moin,
ich habe ein neues HM Gerät hinzugefügt.
Jetzt werden die Daten meiner Geräte nicht mehr automatisch aktualisiert.
Nur wenn ich get update ausführe werden die Daten aktualisiert.
Fini
mach mal ein list der ccu und ein list des neuen gerätes und poste das mal hier. deine ccu probleme sidn schon "merkwürdig". eine übersicht per list würde da sehr helfen grundlegende konfigurationsfehler/probleme zu beheben (und bei änderung in fhem "save" drücken nciht vergessen ;) )
Zitat von: chris1284 am 25 Januar 2017, 15:55:38
mach mal ein list der ccu und ein list des neuen gerätes und poste das mal hier. deine ccu probleme sidn schon "merkwürdig". eine übersicht per list würde da sehr helfen grundlegende konfigurationsfehler/probleme zu beheben (und bei änderung in fhem "save" drücken nciht vergessen ;) )
ich habe fhem neu gestartet und dann ging es wieder.
Aber danke für deine Hilfe!
Fini
wenn man in der CCU ein neues Gerät hinzufügt, muss man in FHEM für das IO Device ein "get devicelist" ausführen, damit FHEM von dem neuen Gerät erfährt.
Beim Neustart von FHEM passiert das automatisch. Vermutlich hat es deshalb wieder funktioniert. Ein get devicelist erspart den Neustart.
Kann es sein das readings mit ccudef-readingname erzeugt keine events generieren die gelogged werden können ? im dblog tauchen alle datapoints auf aber von den per "+" erzeugten readings keines, nur control, state und hmstate. das sollte per default ehr so sein das acuh für battery , desired.temp usw ein event kommt
Die zusätzlichen Readings werden in der gleichen Schleife aktualisiert wie die anderen. Eigentlich müssten Events kommen. Hast Du event-on Filter gesetzt? Ich habe jetzt mal bei einem Temperatursensor die "event-on-" Attribute gelöscht. Nach einem "get update" für das Device kommen alle Events:
2017-01-26 17:49:52 HMCCUDEV HM_KL_WR_TH activity: alive
2017-01-26 17:49:52 HMCCUDEV HM_KL_WR_TH battery: ok
2017-01-26 17:49:52 HMCCUDEV HM_KL_WR_TH 1.TEMPERATURE: 14
2017-01-26 17:49:52 HMCCUDEV HM_KL_WR_TH 1.DEWPOINT: 5.8
2017-01-26 17:49:52 HMCCUDEV HM_KL_WR_TH 14
2017-01-26 17:49:52 HMCCUDEV HM_KL_WR_TH 1.HUMIDITY: 57
2017-01-26 17:49:52 HMCCUDEV HM_KL_WR_TH hmstate: 14
Neue Version 3.9 verfügbar (Update vermutlich ab morgen)
Neue Funktionen:
Die neuen Funktionen sind diesmal v.a. für Fortgeschrittene Anwender gedacht. Kenntnisse in regulären Ausdrücken sind bei der Anwendung sehr hilfreich.
Das Attribut substitute unterstützt nun Variablen. Variablen können im Zieltext im Format ${name} angegeben werden, wobei name für den Namen eines Datenpunkts steht. Wenn ein Datenpunkt nicht eindeutig ist, kann zusätzlich noch die Kanalnummer mit einem '.' vorangestellt werden. Sonderfall: die Variable ${value} wird durch den Originalwert ersetzt. Beispiel:
# Luftfeuchte als "H: nn %" darstellen
attr mydev substitute HUMIDITY!.*:H: ${value} %
# Mehrere Werte in einem Reading darstellen
attr mydev substitute TEMPERATURE!.*:T: ${value} °C H: ${1.HUMIDITY} %
Die Attribute hmstatevals in HMCCUCHN/HMCCUDEV sowie das Attribut ccudef-hmstatevals in HMCCU erlauben nun eine weitgehend flexible Konfiguration der Ermittlung des HomeMatic Status. Die Syntax ist an das Attribut substitute angelehnt. Die Regeln werden von links nach rechts abgearbeitet. Wenn die erste Regel matched, wird die Verarbeitung abgebrochen. Der Inhalt von ccudef-hmstatevals wird an das lokale Attribut hmstatevals angehängt, ersetzt es also nicht. Wenn keine der Regeln matched, wird der HomeMatic Status auf den Inhalt des Readings 'state' gesetzt. Beispiele:
# hmstate = UNREACH oder LOWBAT
attr mydev hmstatevals UNREACH!(1|true):unreachable;LOW_?BAT!(1|true);warn_battery
# hmstate = UNREACH oder ERROR mit Variablen und Default = Datenpunkt LEVEL
# ERRORs 1-9 werden als "err_n" dargestellt.
attr mydev hmstatevals UNREACH!(1|true):unreachable;ERROR!#1-9:err_${value};.*!.*:${1.LEVEL}
# Reading ändern in homematicState
attr mydev hmstatevals =homematicState;UNREACH!(1|true):unreachable;^FAULT.*!#1-9:fault_${value}
# Werte aus Wetterstation darstellen wenn kein Fehler vorliegt.
attr mydev hmstatevals UNREACH!(1|true):unreachable;ERROR!#1-9:err_${value};(TEMPERATURE|HUMIDITY)!.*:T: ${TEMPERATURE} H: ${HUMIDITY} W: ${WIND_SPEED}
# Wie vorher, aber nur, wenn Temperatur zwischen 10 und 20 Grad
attr mydev hmstatevals UNREACH!(1|true):unreachable;ERROR!#1-9:err_${value};TEMPERATURE!#10-20:T: ${TEMPERATURE} H: ${HUMIDITY} W: ${WIND_SPEED}
Mit dem Attribut ccucalculate kann die Berechnung des Taupunkts veranlasst werden, sofern das Device über Datenpunkte für Temperatur und Luftfeuchte verfügt. Beispiel:
attr mydev ccucalculate dewpoint:Taupunkt:1.TEMPERATURE,1.HUMIDITY
Die Syntax ist also: dewpoint:ReadingName:DatenpunktTemp,DatenpunktHum
Bei HMCUDEV müssen die Datenpunkte mit Kanalnummer angegeben werden. Bei HMCCUCHN nicht. Das Attribut wird ggf. mit weiteren Berechnungsregeln erweitert werden.
Zitat von: zap am 26 Januar 2017, 18:44:12
kann die Berechnung des Taupunkts
wozu die mühe, gibt doch dewpoint welches auch noch absFeuchte kann?!
hast Du event-on Filter gesetzt? nichts der gleichen. es verhält sich so bei ALLEN devices vo readings zu den datapoint gekommen sind. die events kommen, aber scheinbar nicht so das sie gelogged werden könnten :o
EDIT erst wenn ich event-on-update-reading .* auf das device setzte logged es auch die per (+) erstellten readings was aber sicher nicht sinn der sache ist oder?
Zitat2017-01-26 20:05:52 HMCCUDEV az_wt Activity: alive
2017-01-26 20:05:52 HMCCUDEV az_wt 0.STICKY_UNREACH: false
2017-01-26 20:05:52 HMCCUDEV az_wt 0.CONFIG_PENDING: false
2017-01-26 20:05:52 HMCCUDEV az_wt 0.LOWBAT: ok
2017-01-26 20:05:52 HMCCUDEV az_wt battery: ok
2017-01-26 20:05:52 HMCCUDEV az_wt 0.RSSI_DEVICE: 1
2017-01-26 20:05:52 HMCCUDEV az_wt 0.RSSI_PEER: 204
2017-01-26 20:05:52 HMCCUDEV az_wt 0.INHIBIT: unlocked
2017-01-26 20:05:52 HMCCUDEV az_wt 0.DEVICE_IN_BOOTLOADER: false
2017-01-26 20:05:52 HMCCUDEV az_wt 0.UPDATE_PENDING: false
2017-01-26 20:05:52 HMCCUDEV az_wt sign: off
2017-01-26 20:05:52 HMCCUDEV az_wt 1.TEMPERATURE: 16.6
2017-01-26 20:05:52 HMCCUDEV az_wt 1.HUMIDITY: 51
2017-01-26 20:05:52 HMCCUDEV az_wt humidity: 51
2017-01-26 20:05:52 HMCCUDEV az_wt 2.CONTROL_MODE: 0
2017-01-26 20:05:52 HMCCUDEV az_wt controlMode: 0
2017-01-26 20:05:52 HMCCUDEV az_wt 2.LOWBAT_REPORTING: false
2017-01-26 20:05:52 HMCCUDEV az_wt 2.COMMUNICATION_REPORTING: false
2017-01-26 20:05:52 HMCCUDEV az_wt 2.WINDOW_OPEN_REPORTING: false
2017-01-26 20:05:52 HMCCUDEV az_wt 2.BATTERY_STATE: 2.9
2017-01-26 20:05:52 HMCCUDEV az_wt batteryLevel: 2.9
2017-01-26 20:05:52 HMCCUDEV az_wt 2.BOOST_STATE: 0
2017-01-26 20:05:52 HMCCUDEV az_wt 2.ACTUAL_TEMPERATURE: 16.6
2017-01-26 20:05:52 HMCCUDEV az_wt temperature: 16.6
2017-01-26 20:05:52 HMCCUDEV az_wt 2.ACTUAL_HUMIDITY: 51.0
2017-01-26 20:05:52 HMCCUDEV az_wt humidity: 51.0
2017-01-26 20:05:52 HMCCUDEV az_wt 2.SET_TEMPERATURE: 16.0
2017-01-26 20:05:52 HMCCUDEV az_wt desired-temp: 16.0
2017-01-26 20:05:52 HMCCUDEV az_wt control: 16.0
2017-01-26 20:05:52 HMCCUDEV az_wt 16.0
2017-01-26 20:05:52 HMCCUDEV az_wt 2.PARTY_TEMPERATURE: 5.0
2017-01-26 20:05:52 HMCCUDEV az_wt 2.PARTY_START_TIME: 0
2017-01-26 20:05:52 HMCCUDEV az_wt 2.PARTY_START_DAY: 1
2017-01-26 20:05:52 HMCCUDEV az_wt 2.PARTY_START_MONTH: 1
2017-01-26 20:05:52 HMCCUDEV az_wt 2.PARTY_START_YEAR: 0
2017-01-26 20:05:52 HMCCUDEV az_wt 2.PARTY_STOP_TIME: 0
2017-01-26 20:05:52 HMCCUDEV az_wt 2.PARTY_STOP_DAY: 1
2017-01-26 20:05:52 HMCCUDEV az_wt 2.PARTY_STOP_MONTH: 1
2017-01-26 20:05:52 HMCCUDEV az_wt 2.PARTY_STOP_YEAR: 0
2017-01-26 20:05:52 HMCCUDEV az_wt 7.DECISION_VALUE: 0
2017-01-26 20:05:52 HMCCUDEV az_wt hmstate: 16.0
2017-01-26 20:05:52 HMCCUDEV az_wt absFeuchte: 7.2
2017-01-26 20:05:52 HMCCUDEV az_wt dewpoint: 6.4
Die events kommen, werden aber nicht gelogged? Hab ich so noch nie gehabt. Aber lass mich mal noch etwas rumtesten ...
P.S. Dewpoint war schon immer in hmccu drin, da ich das Modul dewpoint nicht kannte. Ist auch nur ein erstes Beispiel für ccucalculate. Damit habe ich noch einiges vor.
bisher alles ok mit HMCCU. Habe jetzt geupdatet auf 3.9 und alle meine Thermostate zeigen nicht mehr das bisherige Ergebnis.
Jetzt kommt nur noch:
T: HM-DG-ST-THERMOSTAT.1.TEMPERATURE° H: HM-DG-ST-THERMOSTAT.1.HUMIDITY% D: HM-DG-ST-THERMOSTAT.2.SET_TEMPERATURE° P: n/a° M:HM-DG-ST-THERMOSTAT.2.CONTROL_MODE
Ist ein kurzer Hinweis möglich? Danke!
gibt es denn das reading HM-DG-ST-THERMOSTAT.1.TEMPERATURE noch in deinem device oder heist es nun evtl anderst (zb temprature)
Zitat von: wolfgang99 am 27 Januar 2017, 12:32:34
bisher alles ok mit HMCCU. Habe jetzt geupdatet auf 3.9 und alle meine Thermostate zeigen nicht mehr das bisherige Ergebnis.
Jetzt kommt nur noch:
T: HM-DG-ST-THERMOSTAT.1.TEMPERATURE° H: HM-DG-ST-THERMOSTAT.1.HUMIDITY% D: HM-DG-ST-THERMOSTAT.2.SET_TEMPERATURE° P: n/a° M:HM-DG-ST-THERMOSTAT.2.CONTROL_MODE
Ist ein kurzer Hinweis möglich? Danke!
Mit der Version 3.8 wurde das Default Format für Readingnamen von 'name' auf 'datapoint' geändert. Du hast 3 Möglichkeiten:
1. stateformat anpassen und z.B. HM-DG-ST-THERMOSTAT.1.TEMPERATURE durch 1.TEMPERATURE ersetzen
2. im betroffenen Device ccureadingformat auf name setzen
3. im I/O Device ccudef-readingformat auf name setzen (gilt dann für alle Devices, d.h. Verhalten wie vor 3.8)
Danke! Mit 1. geht das wieder!! (hätte ich selbst sehen können (müssen)!
Zitat von: chris1284 am 26 Januar 2017, 20:10:09
EDIT erst wenn ich event-on-update-reading .* auf das device setzte logged es auch die per (+) erstellten readings was aber sicher nicht sinn der sache ist oder?
Ich kann das Problem nicht nachstellen. Ich habe bei einem meiner Temperatursensoren folgendes definiert:
ccureadingname 1.TEMPERATURE:+temp;1.HUMIDITY:+hum
Außerdem beide "event-on-" Attribute gelöscht. Danach zeigt der Eventmonitor wie erwartet folgende Events an:
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH 1.TEMPERATURE: 14
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH temp: 142017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH 1.DEWPOINT: 6.1
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH 14
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH hmstate: 14
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH 1.HUMIDITY: 57
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH hum: 572017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH 1.DEWPOINT: 6.1
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH hmstate: 14
Die beiden zusätzlichen Readings sind also enthalten.
Ich habe nur ccudef-readingsname definiert, nichts in den devices selber. Evtl ist das der Grund . Ich teste morgen mal mit ccureadingasname
Zitat von: chris1284 am 27 Januar 2017, 19:36:58
Ich habe nur ccudef-readingsname definiert, nichts in den devices selber. Evtl ist das der Grund . Ich teste morgen mal mit ccureadingasname
wie sieht das ccudef-readingname aus?
so ^(.+\.)?AES_KEY$:sign;^(.+\.)?LOW_?BAT$:+battery;^(.+\.)?BATTERY_STATE:+batteryLevel;^(.+\.)?UNREACH$:Activity;^(.+\.)?SET_TEMPERATURE$:+desired-temp;^(.+\.)?HUMIDITY$:+humidity;^(.+\.)?LEVEL$:+pct;^(.+\.)?CONTROL_MODE$:+controlMode;^(.+\.)?ACTUAL_HUMIDITY:+humidity;^(.+\.)?ACTUAL_TEMPERATURE:+temperature;
Zitat von: zap am 26 Januar 2017, 18:44:12
Die Attribute hmstatevals in HMCCUCHN/HMCCUDEV sowie das Attribut ccudef-hmstatevals in HMCCU erlauben nun eine weitgehend flexible Konfiguration der Ermittlung des HomeMatic Status.
Ganz herzlichen Dank dafür! Das klingt jetzt genau richtig 👍🏼
Kann es sein, dass es noch ein paar Bugs dabei gibt? Mir scheint es so, als wenn auch bei Nutzung des Datapoints trotzdem ccuscaleval vorher nicht berücksichtigt wird (weder bei der Regexp noch als resultierender Wert). Zum Beispiel werden Temperaturen mit den üblich vielen Nachkommstellen angezeigt, LEVEL hat nur Werte zwischen 0 und 1 und MOTION wird mit true/false dargestellt.
Aus irgendeinem Grund, den ich mir wiederum gar nicht erklären kann, wird DIRECTION gar nicht bei mir beachtet; WORKING hingegen schon, obwohl es erst nach DIRECTION aufgeführt ist.
Mache ich was falsch?
Dies sind meine Definitionen im I/O Device, an den HMCCU.+ Geräten selbst habe ich keine. (
Der Übersicht halber hier mit Zeilenumbruch; vielleicht noch eine kleine Anregung die beim Einlesen aus den Attributen zu entfernen, dann könnte man das auch so übersichtlicher im Attribut direkt ablegen)
attr CCU2 ccudef-hmstatevals UNREACH!(1|true):unreachable;\
FAULT_REPORTING!#1-3:err_f_${value};\
FAULT_REPORTING!5:err_f_${value};\
FAULT_REPORTING!#7-9:err_f_${value};\
ERROR_OVERHEAT!(1|true):err_overheated;\
ERROR_OVERLOAD!(1|true):err_overloaded;\
ERROR_REDUCED!(1|true):err_reduced;\
ERROR!#1-3:err_${value};\
ERROR!#5-9:err_${value};\
INHIBIT!(1|true):locked;\
DIRECTION!1:up;\
DIRECTION!2:down;\
DIRECTION!3:undefined;\
WORKING!(1|true):working;\
MOTION!.*:${MOTION};\
LEVEL!#0-0:off;\
LEVEL!#1-99:${LEVEL};\
LEVEL!#100-100:on;\
STATE!.*:${STATE};\
VALVE_STATE!.*:${VALVE_STATE};\
(ACTUAL_TEMPERATURE|ACTUAL_HUMIDITY)!.*:T: ${ACTUAL_TEMPERATURE} °C H: ${ACTUAL_HUMIDITY} %;\
CONTROL_MODE!.*:${CONTROL_MODE};\
(TEMPERATURE|HUMIDITY)!.*:T: ${TEMPERATURE} °C H: ${HUMIDITY} %;\
FAULT_REPORTING!6:warn_battery;\
LOW_?BAT!(1|true):warn_battery;\
ERROR!4:warn_battery;\
UNREACH!0:ok;\
attr CCU2 ccudef-readingformat datapoint
attr CCU2 ccudef-readingname ^(.+\.)?ACTUAL_HUMIDITY$:humidity;\
^(.+\.)?ACTUAL_TEMPERATURE$:measured-temp;\
^(.+\.)?AES_KEY$:sign;\
^(.+\.)?BATTERY_STATE$:batteryLevel;\
^(.+\.)?BRIGHTNESS$:brightness;\
^(.+\.)?CONTROL_MODE$:controlMode;\
^(.+\.)?DIRECTION$:direction;\
^(.+\.)?ENERGY_COUNTER$:energy;\
^(.+\.)?FREQUENCY$:frequency;\
^(.+\.)?HUMIDITY$:humidity;\
^(.+\.)?INHIBIT$:lock;\
^(.+\.)?LEVEL$:+pct;\
^(.+\.)?LEVEL$:level;\
^(.+\.)?LOW_?BAT$:battery;\
^(.+\.)?MOTION$:motion;\
^(.+\.)?PARTY_START_TIME$:partyStart;\
^(.+\.)?PARTY_STOP_TIME$:partyEnd;\
^(.+\.)?PARTY_TEMPERATURE$:partyTemp;\
^(.+\.)?POWER$:consumption;\
^(.+\.)?SET_TEMPERATURE$:desired-temp;\
^(.+\.)?TEMPERATURE$:temperature;\
^(.+\.)?UNREACH$:Activity;\
^(.+\.)?VALVE_STATE$:valve;\
^(.+\.)?VOLTAGE$:voltage;\
^(.+\.)?WORKING$:working;\
attr CCU2 ccudef-substitute AES_KEY!(0|false):off,(1|true):on;\
CONTROL_MODE!0:auto,1:manual,2:party,3:boost;\
DIRECTION!0:stop,1:up,2:down,3:undefined;\
INHIBIT!(0|false):unlocked,(1|true):locked;\
LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;\
MOTION!(0|false):noMotion,(1|true):motion;\
UNREACH!(0|false):alive,(1|true):dead;\
WORKING!(0|false):false,(1|true):true;\
attr CCU2 rpcinterval 2
attr CCU2 rpcport 2001,2010,9292
attr CCU2 rpcserver on
attr CCU2 stateFormat rpcstate/state
Zitat von: Loredo am 28 Januar 2017, 14:58:13
Ganz herzlichen Dank dafür! Das klingt jetzt genau richtig 👍🏼
Bitte schön. Ich habe schon mit dem Gedanken gespielt, es Loredo-Release zu nennen ;-)
Zitat
Kann es sein, dass es noch ein paar Bugs dabei gibt? Mir scheint es so, als wenn auch bei Nutzung des Datapoints trotzdem ccuscaleval vorher nicht berücksichtigt wird (weder bei der Regexp noch als resultierender Wert). Zum Beispiel werden Temperaturen mit den üblich vielen Nachkommstellen angezeigt, LEVEL hat nur Werte zwischen 0 und 1 und MOTION wird mit true/false dargestellt.
Aus irgendeinem Grund, den ich mir wiederum gar nicht erklären kann, wird DIRECTION gar nicht bei mir beachtet; WORKING hingegen schon, obwohl es erst nach DIRECTION aufgeführt ist.
Mache ich was falsch?
Für die Definitionen in hmstatevals greifen ccuscaleval, substitute und stripnumber nicht. HMCCUDEV und HMCCUCHN speichern die aktuellen Werte all ihrer Datenpunkte im hash des jeweiligen Gerätes (mach mal ein list). Dabei werden die Originalwerte gespeichert, nicht die umformatierten. Ich schau mir das mal an ...
Bei DIRECTION fällt mir auf, dass das in Deinem Regelset mehrfach vorkommt. Sollte eigentlich kein Problem darstellen, aber ändere es trotzdem mal ab (hinter einem Datenpunktnamen kann eine Liste von Ersetzungen angegeben werden, analog substitute):
DIRECTION!1:up,2:down,3:undefined
Zitat von: zap am 28 Januar 2017, 15:42:18
Bitte schön. Ich habe schon mit dem Gedanken gespielt, es Loredo-Release zu nennen ;-)
Ich gehe ja noch immer davon aus, dass es auch andere brauchen können ;-)
Zitat von: zap am 28 Januar 2017, 15:42:18
Dabei werden die Originalwerte gespeichert, nicht die umformatierten. Ich schau mir das mal an ...
Ok, das wäre prima!
Zitat von: zap am 28 Januar 2017, 15:42:18
DIRECTION!1:up,2:down,3:undefined
Wenn ich so zusammenfasse, geht es in der Tat. Habe ich auch mit den anderen Dopplungen jetzt mal vorsichtshalber gemacht.
Hallo zusammen,
gibt es irgendwo eine Übersicht, welche HM-Devices mit dem Modul HMCCU funktionieren? Ich versuche seit einiger Zeit erfolglos folgende Wired-Typen einzubinden:
HMW-IO-12-Sw7-DR
HMW-IO-12-Sw14-DR
folgende Wired-Typen funktionieren ohne Probleme bei mir:
HMW-LC-Bl1-DR
HMW-Sen-SC-12-DR
Wenn ich ein get ccu3 devicelist dump absetze, sehe ich die HMW-IO-12-Sw7-DR und HMW-IO-12-Sw14-DR mit allen channels, ansprechen kann ich Sie aber nicht. Bei diesen beiden Typen kommt auf ein
get ccu3 device info MEQ0278851
nur folgendes:
DPT {i} Gateway-DP = 28 [RWE]
DPT {s} Gateway-IPDP = [RWE]
DPT {s} SMS = [W]
DPT {s} EMail = [W]
bei einem get ccu3 dump devtypes erscheinen die beiden Typen gar nicht.
Kann mir bitte jemand sagen, ob diese Devices unterstützt werden? Oder mir einen Tipp geben, wie ich diese beiden Typen einbinden kann?
Vielen Dank und viele Grüße
Grundsätzlich sollten alle Devices, die in der CCU angelernt sind, auch aus HMCCU ansprechbar sein. Ich habe da keine Device spezifischen Sachen drin.
Die Ausgabe von get devicinfo sieht jedenfalls seltsam aus. Die Kanalangaben fehlen.
Kannst Du für die Devices in FHEM Geräte anlegen (mit HMCCUDEV)? Oder kommt da eine Fehlermeldung?
Mach mal bitte ein get ccu3 devicelist ohne "dump" und danach nochmal ein get ccu3 deviceinfo <name>
Stehen nach der Ausführung dieses Befehls Fehlermeldungen im FHEM Log?
Hallo zap,
erstmal Danke für die Antwort. Wenn ich get ccu3 devicelist absetze, dann kommt als Antwort
Read 172 devices/channels from CCU
Hier werden alle Devices erkannt. Auch der HMW-IO-12-Sw7-DR ist dabei. Im Log File kommt dazu keine Fehlermeldung oder sowas.
Beim get ccu3 devicelist dump sieht man die Channels:
Device "12SW7001" [MEQ0278851] Type=HMW-IO-12-Sw7-DR
Channel 0 "12SW7001:0" [MEQ0278851:0]
Channel 1 "12SW7001:T1" [MEQ0278851:1]
Channel 2 "12SW7001:T10" [MEQ0278851:10]
Channel 3 "12SW7001:T11" [MEQ0278851:11]
Channel 4 "12SW7001:T12" [MEQ0278851:12]
Channel 5 "12SW7001:L1" [MEQ0278851:13]
Channel 6 "12SW7001:L2" [MEQ0278851:14]
Channel 7 "12SW7001:L3" [MEQ0278851:15]
Channel 8 "12SW7001:L4" [MEQ0278851:16]
Channel 9 "12SW7001:L5" [MEQ0278851:17]
Channel 10 "12SW7001:L6" [MEQ0278851:18]
Channel 11 "12SW7001:L7" [MEQ0278851:19]
Channel 12 "12SW7001:T2" [MEQ0278851:2]
Channel 13 "12SW7001:T3" [MEQ0278851:3]
Channel 14 "12SW7001:T4" [MEQ0278851:4]
Channel 15 "12SW7001:T5" [MEQ0278851:5]
Channel 16 "12SW7001:T6" [MEQ0278851:6]
Channel 17 "12SW7001:T7" [MEQ0278851:7]
Channel 18 "12SW7001:T8" [MEQ0278851:8]
Channel 19 "12SW7001:T9" [MEQ0278851:9]
Was mich halt stutzig macht ist die seltsame ausgäbe von get ccu3 deviceinfo MEQ0278851.
Vielleicht habe ich ja auch nur ein Verständnisproblem:
Ist es richtig, für das ganze HMW-IO-12-Sw7-DR einmal ein Device anzulegen, z.B. so:
defmod Licht1 HMCCUDEV BidCos-Wired.MEQ0278851
attr Licht1 IODev ccu3
attr Licht1 event-on-change-reading .*
attr Licht1 event-on-update-reading .*
attr Licht1 room KG.Raum1
attr Licht1 statevals on:true,off:false
Oder für die einzelnen Channels ein eigenes Device?
Mit der obigen Definition sehe ich einzelne Readings nach Betätigung der Taster:
Readings
1.PRESS_LONG
1
2017-01-28 22:51:22
1.PRESS_SHORT
1
2017-01-28 22:55:04
13.STATE
0
2017-01-28 22:55:06
13.WORKING
0
2017-01-28 22:55:06
14.STATE
0
2017-01-28 22:54:54
14.WORKING
0
2017-01-28 22:54:54
15.STATE
0
2017-01-28 22:54:52
15.WORKING
0
2017-01-28 22:54:52
16.STATE
0
2017-01-28 22:54:52
16.WORKING
0
2017-01-28 22:54:52
17.STATE
0
2017-01-28 22:54:50
17.WORKING
0
2017-01-28 22:54:50
18.STATE
0
2017-01-28 22:54:50
18.WORKING
0
2017-01-28 22:54:50
19.STATE
0
2017-01-28 22:54:56
19.WORKING
0
2017-01-28 22:54:56
Ich kann aber keine States verändern, oder ich stelle mich zu dumm:
set Licht1 datapoint 13.STATE on
kommt immer
HMCCUDEV: Licht1 Invalid datapoint
Nochmals vielen Dank für die Hilfe!!!!
Hallo zusammen,
eine Frage als Newbie, da ich scheinbar nicht die richtigen Stellen im Forum und in der commandref finde.
Ich nutze mit Schwerpunkt die CCU2 und habe mit HMCCU diverse andere Elemente angebunden (Harmony, Bose Soundtouch etc). Das klappt alles prima.
Nun möchte ich einfach nur zyklisch alle 60 min die Aussentemperatur vom Yahoo-Wetter (Device: Wetter, reading: temp_c) jede Stunde in eine Variable auf der CCU2 (mit Namen Aussentemperatur) schreiben, damit ich sie dort nutzen kann.
Genutzt habe ich den at-Befehl:
define aussen_temperatur_zyklisch at +*00:60:00 set my_ccu var Aussentemperatur temp_c
Wie sage ich FHEM, dass es sich bei "temp_c" um das ReadingVal von "Wetter" handelt? Ein Link an die richtige Stelle der commandref oder ins Forum fände ich auch super.
Vielen Dank
Gruß
Ulli
Die Antwort hast du schon selbst genannt ReadinsVal("Wetter","temp_c", 99.0) statt temp_c nehmen
@scm35768
Bitte mach mal ein get Licht1 update
Danach ein list Licht1 sowie ein get Licht1 deviceinfo
Die Ergebnisse bitte posten
@chris1284: funzt leider nicht. Irgendwo habe ich einen Gedanken- oder Schreibfehler. Ich erhalte in der Systemvariable in der CCU2 immer nur eine 0. Also wird der falsche Wert gelesen.
Aber das device heisst tatsächlich "Wetter". :(
Hallo zap,
nach dem get Licht1 update kam eine leere Box mit einem OK,
dann list Licht1 gibt folgendes:
Internals:
CFGFN
DEF BidCos-Wired.MEQ0278851
IODev ccu3
NAME Licht1
NR 479
STATE 0
TYPE HMCCUDEV
ccuaddr MEQ0278851
ccudevstate Active
ccuif BidCos-Wired
ccuname 12SW7001
ccutype HMW-IO-12-Sw7-DR
channels 20
statevals devstate|on|off
Readings:
2017-01-28 22:51:22 1.PRESS_LONG 1
2017-01-28 22:55:04 1.PRESS_SHORT 1
2017-01-28 22:55:06 13.STATE 0
2017-01-28 22:55:06 13.WORKING 0
2017-01-28 22:54:54 14.STATE 0
2017-01-28 22:54:54 14.WORKING 0
2017-01-28 22:54:52 15.STATE 0
2017-01-28 22:54:52 15.WORKING 0
2017-01-28 22:54:52 16.STATE 0
2017-01-28 22:54:52 16.WORKING 0
2017-01-28 22:54:50 17.STATE 0
2017-01-28 22:54:50 17.WORKING 0
2017-01-28 22:54:50 18.STATE 0
2017-01-28 22:54:50 18.WORKING 0
2017-01-28 22:54:56 19.STATE 0
2017-01-28 22:54:56 19.WORKING 0
2017-01-28 22:53:47 5.PRESS_SHORT 1
2017-01-28 22:53:49 6.PRESS_SHORT 1
2017-01-28 22:53:51 7.PRESS_SHORT 1
2017-01-29 21:17:53 hmstate 0
2017-01-28 22:55:06 state 0
Hmccu:
Dp:
1.press_long:
VAL 1
1.press_short:
VAL 1
13.state:
VAL 0
13.working:
VAL 0
14.state:
VAL 0
14.working:
VAL 0
15.state:
VAL 0
15.working:
VAL 0
16.state:
VAL 0
16.working:
VAL 0
17.state:
VAL 0
17.working:
VAL 0
18.state:
VAL 0
18.working:
VAL 0
19.state:
VAL 0
19.working:
VAL 0
5.press_short:
VAL 1
6.press_short:
VAL 1
7.press_short:
VAL 1
Attributes:
IODev ccu3
event-on-change-reading .*
event-on-update-reading .*
room KG.Raum1
statevals on:true,off:false
substitute true:on,false:off,1:on,0:off
dann get Licht1 update liefest folgendes:
DPT {i} Gateway-DP = 28 [RWE]
DPT {s} Gateway-IPDP = [RWE]
DPT {s} SMS = [W]
DPT {s} EMail = [W]
komisch ....
@ ukobusch: naja, wenn readingsval den wert nicht lesen würde sollte 99.0 auftauschen wenn du es so übernommen hast.
was sagen den die fhem logs? du weisst das die Funktion ReadingsVal eine Perl-function ist und du sie nicht einfach in dein at kopieren kannst? dein at könnte zb so aussehen:
define aussen_temperatur_zyklisch at +*00:60:00 {
my $temp = ReadinsVal("Wetter","temp_c", 99.0);
fhem("set my_ccu var Aussentemperatur $temp");
}
Zitat von: scm35768 am 29 Januar 2017, 21:20:52
DPT {i} Gateway-DP = 28 [RWE]
DPT {s} Gateway-IPDP = [RWE]
DPT {s} SMS = [W]
DPT {s} EMail = [W]
komisch ....
Die Readings sehen eigentlich gut aus, die Deviceinfo leider weniger. Jetzt geht es ans Eingemachte: Bitte gehe mal in die CCU2 und rufe "Programme und Verknüpfungen -> Programme und Zentraleverknüpfungen" auf. Dann unten auf der Seite den Button "Skript testen" drücken. Im Fenster, das aufgeht, folgenden Code einfügen:
string chnid;
string sDPId;
object odev = dom.GetObject ("12SW7001");
if (odev) {
foreach (chnid, odev.Channels()) {
object ochn = dom.GetObject(chnid);
if (ochn) {
foreach(sDPId, ochn.DPs()) {
object oDP = dom.GetObject(sDPId);
if (oDP) {
integer op = oDP.Operations();
string flags = "";
if (OPERATION_READ & op) { flags = flags # "R"; }
if (OPERATION_WRITE & op) { flags = flags # "W"; }
if (OPERATION_EVENT & op) { flags = flags # "E"; }
WriteLine ("C;" # ochn.Address() # ";" # ochn.Name() # ";" # oDP.Name() # ";" # oDP.ValueType() # ";" # oDP.State() # ";" # flags);
}
}
}
}
}
Hallo zap,
als Ausgabe kommt folgendes:
C;;Gateway;Gateway-DP;16;28;RWE
C;;Gateway;Gateway-IPDP;20;;RWE
C;;Communication;SMS;20;;W
C;;Communication;EMail;20;;W
Die Firmware ist die aktuellste: 3.06.
Das gleiche Ergebnis kommt auch beim HMW-IO-12-Sw14-DR
Beim HMW-Sen-SC-12-DR kommt folgende Ausgabe:
C;MEQ0200927:0;SEN.001:0;BidCos-Wired.MEQ0200927:0.UNREACH;2;false;RE
C;MEQ0200927:0;SEN.001:0;BidCos-Wired.MEQ0200927:0.STICKY_UNREACH;2;false;RWE
C;MEQ0200927:0;SEN.001:0;BidCos-Wired.MEQ0200927:0.CONFIG_PENDING;2;false;RE
C;MEQ0200927:1;SEN.001:1;BidCos-Wired.MEQ0200927:1.SENSOR;2;true;RE
C;MEQ0200927:1;SEN.001:1;BidCos-Wired.MEQ0200927:1.INSTALL_TEST;2;false;E
C;MEQ0200927:2;SEN.001:2;BidCos-Wired.MEQ0200927:2.SENSOR;2;true;RE
C;MEQ0200927:2;SEN.001:2;BidCos-Wired.MEQ0200927:2.INSTALL_TEST;2;false;E
C;MEQ0200927:3;SEN.001:3;BidCos-Wired.MEQ0200927:3.SENSOR;2;true;RE
C;MEQ0200927:3;SEN.001:3;BidCos-Wired.MEQ0200927:3.INSTALL_TEST;2;false;E
C;MEQ0200927:4;SEN.001:4;BidCos-Wired.MEQ0200927:4.SENSOR;2;true;RE
C;MEQ0200927:4;SEN.001:4;BidCos-Wired.MEQ0200927:4.INSTALL_TEST;2;false;E
C;MEQ0200927:5;SEN.001:5;BidCos-Wired.MEQ0200927:5.SENSOR;2;true;RE
C;MEQ0200927:5;SEN.001:5;BidCos-Wired.MEQ0200927:5.INSTALL_TEST;2;false;E
C;MEQ0200927:6;SEN.001:6;BidCos-Wired.MEQ0200927:6.SENSOR;2;true;RE
C;MEQ0200927:6;SEN.001:6;BidCos-Wired.MEQ0200927:6.INSTALL_TEST;2;false;E
C;MEQ0200927:7;SEN.001:7;BidCos-Wired.MEQ0200927:7.SENSOR;2;true;RE
C;MEQ0200927:7;SEN.001:7;BidCos-Wired.MEQ0200927:7.INSTALL_TEST;2;false;E
C;MEQ0200927:8;SEN.001:8;BidCos-Wired.MEQ0200927:8.SENSOR;2;true;RE
C;MEQ0200927:8;SEN.001:8;BidCos-Wired.MEQ0200927:8.INSTALL_TEST;2;false;E
C;MEQ0200927:9;SEN.001:9;BidCos-Wired.MEQ0200927:9.SENSOR;2;true;RE
C;MEQ0200927:9;SEN.001:9;BidCos-Wired.MEQ0200927:9.INSTALL_TEST;2;false;E
C;MEQ0200927:10;SEN.001:10;BidCos-Wired.MEQ0200927:10.SENSOR;2;true;RE
C;MEQ0200927:10;SEN.001:10;BidCos-Wired.MEQ0200927:10.INSTALL_TEST;2;false;E
C;MEQ0200927:11;SEN.001:11;BidCos-Wired.MEQ0200927:11.SENSOR;2;true;RE
C;MEQ0200927:11;SEN.001:11;BidCos-Wired.MEQ0200927:11.INSTALL_TEST;2;false;E
C;MEQ0200927:12;SEN.001:12;BidCos-Wired.MEQ0200927:12.SENSOR;2;true;RE
C;MEQ0200927:12;SEN.001:12;BidCos-Wired.MEQ0200927:12.INSTALL_TEST;2;false;E
Ah ja. Ich habe eine Vermutung: Deine Kanalnamen enthalten einen Doppelpunkt (z.B. SEN.001:1). Das könnte die Ursache sein, da der Punkt in HMCCU ggf. als Trenner zwischen Kanal und Datenpunkt verwendet wird (muss ich aber nochmal verifizieren).
Um das zu bestätigen, müsstest Du die Kanäle in der CCU mal umbenennen (sofern das nicht zuviel Aufwand ist).
Danach wäre in HMCCU ein "get xy devicelist" erforderlich und eine Neudefinition des Geräts mit define und HMCCUDEV.
Wenn dann ein "get deviceinfo" korrekte Werte liefert, war der Punkt im Namen der Auslöser.
P.S. An zentraler Stelle in HMCCU passiert das, wenn ein Objekt im Format Kanalname.Datenpunkt angegeben wird:
elsif ($object =~ /^(.+?)\.(.+)$/) {
#
# Name.Datapoint
#
($n, $d) = ($1, $2);
}
Soll heißen, der erste '.' trennt, und das ist in Deinem Fall leider falsch
@chris1284,
danke für die Unterstützung. Das war mir "natürlich" ;) nicht klar. Ich werde mal mehr lesen, ausprobieren, und mich dann ggf. in einem "Newbie-Threat" wieder melden, da mein Problem nichts mit HMCCU zu tun hat.
Gruß Ulli
Hallo zap,
ich habe nun alle Devices umbenannt und alle Punkte entfernt. Dann habe ich die Devices gelöscht und neu angelegt. Leider ändert es nichts an der Ausgabe:
Die Ausgabe des Scripts ist immer noch folgende:
C;;Gateway;Gateway-DP;16;28;RWE
C;;Gateway;Gateway-IPDP;20;;RWE
C;;Communication;SMS;20;;W
C;;Communication;EMail;20;;W
Der Sensor schaut jetzt so aus:
C;MEQ0200927:0;SENSOR001:0;BidCos-Wired.MEQ0200927:0.UNREACH;2;false;RE
C;MEQ0200927:0;SENSOR001:0;BidCos-Wired.MEQ0200927:0.STICKY_UNREACH;2;false;RWE
C;MEQ0200927:0;SENSOR001:0;BidCos-Wired.MEQ0200927:0.CONFIG_PENDING;2;false;RE
C;MEQ0200927:1;SENSOR001C1;BidCos-Wired.MEQ0200927:1.SENSOR;2;true;RE
C;MEQ0200927:1;SENSOR001C1;BidCos-Wired.MEQ0200927:1.INSTALL_TEST;2;false;E
C;MEQ0200927:2;SENSOR001C2;BidCos-Wired.MEQ0200927:2.SENSOR;2;true;RE
C;MEQ0200927:2;SENSOR001C2;BidCos-Wired.MEQ0200927:2.INSTALL_TEST;2;false;E
C;MEQ0200927:3;SENSOR001C3;BidCos-Wired.MEQ0200927:3.SENSOR;2;true;RE
C;MEQ0200927:3;SENSOR001C3;BidCos-Wired.MEQ0200927:3.INSTALL_TEST;2;false;E
C;MEQ0200927:4;SENSOR001C4;BidCos-Wired.MEQ0200927:4.SENSOR;2;true;RE
C;MEQ0200927:4;SENSOR001C4;BidCos-Wired.MEQ0200927:4.INSTALL_TEST;2;false;E
C;MEQ0200927:5;SENSOR001C5;BidCos-Wired.MEQ0200927:5.SENSOR;2;true;RE
C;MEQ0200927:5;SENSOR001C5;BidCos-Wired.MEQ0200927:5.INSTALL_TEST;2;false;E
C;MEQ0200927:6;SENSOR001C6;BidCos-Wired.MEQ0200927:6.SENSOR;2;true;RE
C;MEQ0200927:6;SENSOR001C6;BidCos-Wired.MEQ0200927:6.INSTALL_TEST;2;false;E
C;MEQ0200927:7;SENSOR001C7;BidCos-Wired.MEQ0200927:7.SENSOR;2;true;RE
C;MEQ0200927:7;SENSOR001C7;BidCos-Wired.MEQ0200927:7.INSTALL_TEST;2;false;E
C;MEQ0200927:8;SENSOR001C8;BidCos-Wired.MEQ0200927:8.SENSOR;2;true;RE
C;MEQ0200927:8;SENSOR001C8;BidCos-Wired.MEQ0200927:8.INSTALL_TEST;2;false;E
C;MEQ0200927:9;SENSOR001C9;BidCos-Wired.MEQ0200927:9.SENSOR;2;true;RE
C;MEQ0200927:9;SENSOR001C9;BidCos-Wired.MEQ0200927:9.INSTALL_TEST;2;false;E
C;MEQ0200927:10;SENSOR001C10;BidCos-Wired.MEQ0200927:10.SENSOR;2;true;RE
C;MEQ0200927:10;SENSOR001C10;BidCos-Wired.MEQ0200927:10.INSTALL_TEST;2;false;E
C;MEQ0200927:11;SENSOR001C11;BidCos-Wired.MEQ0200927:11.SENSOR;2;true;RE
C;MEQ0200927:11;SENSOR001C11;BidCos-Wired.MEQ0200927:11.INSTALL_TEST;2;false;E
C;MEQ0200927:12;SENSOR001C12;BidCos-Wired.MEQ0200927:12.SENSOR;2;true;RE
C;MEQ0200927:12;SENSOR001C12;BidCos-Wired.MEQ0200927:12.INSTALL_TEST;2;false;E
Keine Ahnung, was da falsch läuft
--------------
Kommando zurück:
Also,
ich hab gerade die beiden Devices nochmal gelöscht und einen reset gemacht, jetzt funktionieren sie.
Vielen Dank für die Hilfe, es muss wohl wirklich etwas mit den Namen zu tun gehabt haben.
get Licht1 device info liefert jetzt alle Daten:
CHN MEQ0278851:0 HMW-IO-12-Sw7-DR MEQ0278851:0
DPT {b} BidCos-Wired.MEQ0278851:0.UNREACH = false [RE]
DPT {b} BidCos-Wired.MEQ0278851:0.STICKY_UNREACH = false [RWE]
DPT {b} BidCos-Wired.MEQ0278851:0.CONFIG_PENDING = false [RE]
CHN MEQ0278851:1 HMW-IO-12-Sw7-DR MEQ0278851:1
DPT {b} BidCos-Wired.MEQ0278851:1.PRESS_SHORT = false [WE]
DPT {b} BidCos-Wired.MEQ0278851:1.PRESS_LONG = [WE]
DPT {b} BidCos-Wired.MEQ0278851:1.INSTALL_TEST = [E]
CHN MEQ0278851:2 HMW-IO-12-Sw7-DR MEQ0278851:2
DPT {b} BidCos-Wired.MEQ0278851:2.PRESS_SHORT = false [WE]
DPT {b} BidCos-Wired.MEQ0278851:2.PRESS_LONG = [WE]
DPT {b} BidCos-Wired.MEQ0278851:2.INSTALL_TEST = [E]
CHN MEQ0278851:3 HMW-IO-12-Sw7-DR MEQ0278851:3
DPT {b} BidCos-Wired.MEQ0278851:3.PRESS_SHORT = [WE]
DPT {b} BidCos-Wired.MEQ0278851:3.PRESS_LONG = [WE]
DPT {b} BidCos-Wired.MEQ0278851:3.INSTALL_TEST = [E]
CHN MEQ0278851:4 HMW-IO-12-Sw7-DR MEQ0278851:4
DPT {b} BidCos-Wired.MEQ0278851:4.PRESS_SHORT = [WE]
DPT {b} BidCos-Wired.MEQ0278851:4.PRESS_LONG = [WE]
DPT {b} BidCos-Wired.MEQ0278851:4.INSTALL_TEST = [E]
CHN MEQ0278851:5 HMW-IO-12-Sw7-DR MEQ0278851:5
DPT {b} BidCos-Wired.MEQ0278851:5.PRESS_SHORT = [WE]
DPT {b} BidCos-Wired.MEQ0278851:5.PRESS_LONG = [WE]
DPT {b} BidCos-Wired.MEQ0278851:5.INSTALL_TEST = [E]
CHN MEQ0278851:6 HMW-IO-12-Sw7-DR MEQ0278851:6
DPT {b} BidCos-Wired.MEQ0278851:6.PRESS_SHORT = false [WE]
DPT {b} BidCos-Wired.MEQ0278851:6.PRESS_LONG = [WE]
DPT {b} BidCos-Wired.MEQ0278851:6.INSTALL_TEST = [E]
CHN MEQ0278851:7 HMW-IO-12-Sw7-DR MEQ0278851:7
DPT {b} BidCos-Wired.MEQ0278851:7.PRESS_SHORT = [WE]
DPT {b} BidCos-Wired.MEQ0278851:7.PRESS_LONG = [WE]
DPT {b} BidCos-Wired.MEQ0278851:7.INSTALL_TEST = [E]
CHN MEQ0278851:8 HMW-IO-12-Sw7-DR MEQ0278851:8
DPT {b} BidCos-Wired.MEQ0278851:8.PRESS_SHORT = [WE]
DPT {b} BidCos-Wired.MEQ0278851:8.PRESS_LONG = [WE]
DPT {b} BidCos-Wired.MEQ0278851:8.INSTALL_TEST = [E]
CHN MEQ0278851:9 HMW-IO-12-Sw7-DR MEQ0278851:9
DPT {b} BidCos-Wired.MEQ0278851:9.PRESS_SHORT = [WE]
DPT {b} BidCos-Wired.MEQ0278851:9.PRESS_LONG = [WE]
DPT {b} BidCos-Wired.MEQ0278851:9.INSTALL_TEST = [E]
CHN MEQ0278851:10 HMW-IO-12-Sw7-DR MEQ0278851:10
DPT {b} BidCos-Wired.MEQ0278851:10.PRESS_SHORT = [WE]
DPT {b} BidCos-Wired.MEQ0278851:10.PRESS_LONG = [WE]
DPT {b} BidCos-Wired.MEQ0278851:10.INSTALL_TEST = [E]
CHN MEQ0278851:11 HMW-IO-12-Sw7-DR MEQ0278851:11
DPT {b} BidCos-Wired.MEQ0278851:11.PRESS_SHORT = [WE]
DPT {b} BidCos-Wired.MEQ0278851:11.PRESS_LONG = [WE]
DPT {b} BidCos-Wired.MEQ0278851:11.INSTALL_TEST = [E]
CHN MEQ0278851:12 HMW-IO-12-Sw7-DR MEQ0278851:12
DPT {b} BidCos-Wired.MEQ0278851:12.PRESS_SHORT = [WE]
DPT {b} BidCos-Wired.MEQ0278851:12.PRESS_LONG = [WE]
DPT {b} BidCos-Wired.MEQ0278851:12.INSTALL_TEST = [E]
CHN MEQ0278851:13 HMW-IO-12-Sw7-DR MEQ0278851:13
DPT {b} BidCos-Wired.MEQ0278851:13.STATE = true [RWE]
DPT {b} BidCos-Wired.MEQ0278851:13.INHIBIT = false [RWE]
DPT {b} BidCos-Wired.MEQ0278851:13.INSTALL_TEST = [W]
DPT {b} BidCos-Wired.MEQ0278851:13.WORKING = false [RE]
CHN MEQ0278851:14 HMW-IO-12-Sw7-DR MEQ0278851:14
DPT {b} BidCos-Wired.MEQ0278851:14.STATE = true [RWE]
DPT {b} BidCos-Wired.MEQ0278851:14.INHIBIT = false [RWE]
DPT {b} BidCos-Wired.MEQ0278851:14.INSTALL_TEST = [W]
DPT {b} BidCos-Wired.MEQ0278851:14.WORKING = false [RE]
CHN MEQ0278851:15 HMW-IO-12-Sw7-DR MEQ0278851:15
DPT {b} BidCos-Wired.MEQ0278851:15.STATE = true [RWE]
DPT {b} BidCos-Wired.MEQ0278851:15.INHIBIT = false [RWE]
DPT {b} BidCos-Wired.MEQ0278851:15.INSTALL_TEST = [W]
DPT {b} BidCos-Wired.MEQ0278851:15.WORKING = false [RE]
CHN MEQ0278851:16 HMW-IO-12-Sw7-DR MEQ0278851:16
DPT {b} BidCos-Wired.MEQ0278851:16.STATE = true [RWE]
DPT {b} BidCos-Wired.MEQ0278851:16.INHIBIT = false [RWE]
DPT {b} BidCos-Wired.MEQ0278851:16.INSTALL_TEST = [W]
DPT {b} BidCos-Wired.MEQ0278851:16.WORKING = false [RE]
CHN MEQ0278851:17 HMW-IO-12-Sw7-DR MEQ0278851:17
DPT {b} BidCos-Wired.MEQ0278851:17.STATE = true [RWE]
DPT {b} BidCos-Wired.MEQ0278851:17.INHIBIT = false [RWE]
DPT {b} BidCos-Wired.MEQ0278851:17.INSTALL_TEST = [W]
DPT {b} BidCos-Wired.MEQ0278851:17.WORKING = false [RE]
CHN MEQ0278851:18 HMW-IO-12-Sw7-DR MEQ0278851:18
DPT {b} BidCos-Wired.MEQ0278851:18.STATE = true [RWE]
DPT {b} BidCos-Wired.MEQ0278851:18.INHIBIT = false [RWE]
DPT {b} BidCos-Wired.MEQ0278851:18.INSTALL_TEST = [W]
DPT {b} BidCos-Wired.MEQ0278851:18.WORKING = false [RE]
CHN MEQ0278851:19 HMW-IO-12-Sw7-DR MEQ0278851:19
DPT {b} BidCos-Wired.MEQ0278851:19.STATE = true [RWE]
DPT {b} BidCos-Wired.MEQ0278851:19.INHIBIT = false [RWE]
DPT {b} BidCos-Wired.MEQ0278851:19.INSTALL_TEST = [W]
DPT {b} BidCos-Wired.MEQ0278851:19.WORKING = false [RE]
Echt schwer aus der Ferne zu diagnostizieren, da ich keine Wired Komponenten habe. Der Punkt im Namen ist zwar ein Fehler in HMCCU, allerdings müsste das Homematic Script trotzdem funktionieren.
Eine Idee habe ich noch: gibt es den Namen des Devices doppelt, oder den Namen eines der Kanäle? Mit doppelt meine ich auch Räume, Gruppen, Gewerke usw. Homematic unterscheidet bei Objekten nicht.
Wenn Du Dir nicht sicher bist, benenne eines der nicht funktionierenden Geräte um in irgendwas, was es sonst garantiert nicht gibt. Genauso die Kanäle. Dann nochmal das Homematic Script mit dem neuen Namen ausführen.
Das würde dann auch erklären, warum die Funktion Address() im Script keinen Wert zurückgibt (zwei ;; in der Ausgabe).
Etwas vereinfacht:
object odev = dom.GetObject ("12SW7001");
if (odev) {
if (odev.IsTypeOf (OT_DEVICE)) {
WriteLine ("Device");
}
else {
WriteLine ("No device");
}
}
else {
WriteLine ("No object");
}
Hallo Zap,
ich habe ein Problem beim auswählen/zuweisen der Device für ein Logfile. Es werden im "addRegexpPart" Auswahlfeld leider mehrere fast gleiche Device angezeigt, die aber in der Devicelist nicht auftauchen. Bei einigen wurde der Name einfach nochmal hinten angehängt, bei anderen kam noch einen Zahl hinzu. Das macht das ganze nicht übersichtlicher.
Hast du eine Idee/ Möglichkeit wie ich die zu viel angelegten Device wieder löschen kann,, ohne das ganze Modul neu zu installieren?
Merci & danke vielmals
Grüße
awa
Zitat von: wagenkna am 31 Januar 2017, 14:31:28
Hallo Zap,
ich habe ein Problem beim auswählen/zuweisen der Device für ein Logfile. Es werden im "addRegexpPart" Auswahlfeld leider mehrere fast gleiche Device angezeigt, die aber in der Devicelist nicht auftauchen. Bei einigen wurde der Name einfach nochmal hinten angehängt, bei anderen kam noch einen Zahl hinzu. Das macht das ganze nicht übersichtlicher.
Hast du eine Idee/ Möglichkeit wie ich die zu viel angelegten Device wieder löschen kann,, ohne das ganze Modul neu zu installieren?
Wenn Du viele Devices auf einmal Löschen möchtest, kannst Du bei "delete" entsprechende Filter angeben.
Ich nehme an, Du hast die Devices mit der Autocreate Funktion von "get devicelist" angelegt. Wenn Du dabei keinen Filter angibst, werden für die Homematic Geräte HMCCUDEV Devices angelegt. Außerdem (und das dürfte das Problem sein) für alle Kanäle HMCCUCHN Devices.
Wenn Du die Kanäle also nicht benötigst, kannst Du die z.B. mit
delete TYPE=HMCCUCHN
löschen. Vorher kannst Du nochmal mit "list TYPE=HMCCUCHN" prüfen, welche Du löschen würdest.
Hallo,
ich schalte in perl mehrere Thermostate auf Manuell und Automatik.
Beipiel:
fhem "set og_sz_thermostat datapoint 2.AUTO_MODE true";;
fhem "set og_bad_thermostat datapoint 2.AUTO_MODE true";;
fhem "set dg_st_thermostat datapoint 2.AUTO_MODE true";;
fhem "set eg_wo_thermostat datapoint 2.AUTO_MODE true";;
Nach 2 befehlen macht er die restlichen nicht mehr...
Muss man warten, oder auf "busy" abfragen oder jeweils kontrollieren?
Wie gehts am besten und warum gehts nicht so schön direkt?
Danke!
Hast du das Attribut ccuverify in den Devices gesetzt? Das könnte es evtl ausbremsen. Es wird zwar bei jedem Befehl ein Request an die CCU abgesetzt, aber das sollte auch mehrmals nacheinander kein Problem sein.
Neue Version 3.9.001 mit kleineren Änderungen eingecheckt. Vermutlich morgen per update verfügbar.
Änderungen:
- Fehler behoben, der die Zeitangabe bei der Option 'on-till' verhindert hat.
- Wenn in den Attributen 'hmstatevals' oder 'substitute' Variablen angegeben werden, wird nun beim Variablenwert das Attribut 'stripnumber' angewendet.
- Wenn ein Datenpunkt im Format Kanalname.Datenpunkt angegeben wird, kann der Kanalname nun Punkte enthalten.
- Das Attribut 'rpcinterfaces' ersetzt das Attribut 'rpcport'. Die CCU Interfaces können nun mit ihrem Namen angegeben werden. rpcport wird aber weiterhin unterstützt.
- Durch die Umstellung auf ParseParams konnte man beim ePaper Display den Datenpunkt SUBMIT nicht mehr setzen. Dieser Fehler wurde behoben.
- Im Modul HMCCUCHN wurden die Befehle get configlist, get configdesc, get config und set config um die Option 'device' erweitert. Wenn diese Option angegeben wird, beziehen sich die o.g. Befehle auf das Device und nicht auf den Kanal
Ergänzung: Leider gibt es einen Bug in der Berechnung von hmstate. Die Regeln in hmstatevals werden nicht von links nach rechts abgearbeitet. Dieser Fehler existiert schon in der Version 3.9.
Ausserdem funktioniert substitute bei numerischen Ersetzungen (zB #1-5:Text) nicht richtig.
Werde das asap beheben.
moin,
hatte
attr w_Wandthermostat userReadings TEMPERATURE { int ( 10 * ReadingsVal("w_Wandthermostat","1.TEMPERATURE",0) + 0.5 ) / 10 }
angelegt. es wurde bis heute auch der Wert unter TEMPERATURE aktualisiert.
Jetzt nicht mehr.
Ich habe
attr w_Wandthermostat userReadings TEMPERATURE { int ( 10 * ReadingsVal("w_Wandthermostat","1.TEMPERATURE",0) + 0.5 ) / 10 }
gelöscht. Der Befehl ist aus Attributes raus, aber TEMPERATURE steht immer noch unter Readings.
Das Löschen des Attributs userreading löscht nicht die Readings. Dazu musst du den FHEM Befehl deletereading oder in HMCCUDEV bzw. hMCCUCHN den Befehl set clear verwenden.
Wenn Du Werte runden möchtest, nimm stripnumber. Allerdings werden dann alle Werte gerundet.
Beispiel 1 Stelle nach dem Komma: stripnumber -1
Hallo zusammen.
Kann es sein, dass es kein Reading für 4.ACTUAL_TEMPERATURE bei den per CCU eingerichteten HM-CC-RT-DN
mehr gibt?
Zitat von: z400 am 02 Februar 2017, 12:36:03
Hallo zusammen.
Kann es sein, dass es kein Reading für 4.ACTUAL_TEMPERATURE bei den per CCU eingerichteten HM-CC-RT-DN
mehr gibt?
Den gibt es noch. Mach mal ein "get deviceinfo" und ein "list" auf das Device.
Hallo zap,
das hatte ich heute Nachmittag beim suchen auch mit einem get <device> datapoint 4.ACTUAL_TEMPERATURE
schon gemacht. Danach ist das Reading vorhanden, wird aber nicht mehr aktualisiert. (siehe Bild 1)
Nach einem erneuten get <device> datapoint 4.ACTUAL_TEMPERATURE wird der Wert dann auch aktualisiert. (Bild 3)
EDIT:
Mist, ich sehe gerade, dass alle meine Thermostate nicht aktualisiert werden (alle NUR 4.ACTUAL_TEMPERATURE,
alle anderen Readings werden aktualisiert)
Hast Du eine Idee wo ich mal nachgucken könnte?
EDIT2:
Auch bei einem get <device> update werden ALLE Readings aktualisiert, ausser 4.ACTUAL_TEMPERATURE!
Verdammte Axt, wassn hier los?! :)
Ein "list 2_Schlafzimmer" wäre echt hilfreich. Glaskugel ist gerade in der Wäsche ;-)
OMG. Voll verpeilt. Sorry! Guckst Du:
Internals:
CHANGED
DEF H_HKT_2_SZ
IODev CCU2
NAME 2_Schlafzimmer
NR 189
STATE Temp: 21.7° | Gewünscht: 20.0° | Ventil: 14%<br>Modus: AUTO
TYPE HMCCUDEV
ccuaddr NEQ0313876
ccudevstate Active
ccuif BidCos-RF
ccuname H_HKT_2_SZ
ccutype HM-CC-RT-DN
channels 7
statevals devstate
Readings:
2017-02-02 16:16:50 0.LOWBAT no
2017-02-02 20:34:20 4.ACTUAL_TEMPERATURE 21.7
2017-02-02 21:10:09 4.CONTROL_MODE AUTO
2017-02-02 21:10:09 4.SET_TEMPERATURE 20.0
2017-02-02 21:10:09 4.VALVE_STATE 14
2017-02-02 21:10:09 control 20.0
2017-02-02 21:10:09 hmstate 20.0
2017-02-02 21:10:09 state 20.0
Hmccu:
Dp:
0.aes_key:
VAL 1
0.config_pending:
VAL false
0.device_in_bootloader:
VAL false
0.inhibit:
VAL false
0.lowbat:
VAL false
0.rssi_device:
VAL 1
0.rssi_peer:
VAL 208
0.sticky_unreach:
VAL false
0.unreach:
VAL false
0.update_pending:
VAL false
4.actual_temperature:
VAL 21.200000
4.battery_state:
VAL 2.900000
4.boost_state:
VAL 0
4.control_mode:
VAL 0
4.fault_reporting:
VAL 0
4.party_start_day:
VAL 1
4.party_start_month:
VAL 1
4.party_start_time:
VAL 0
4.party_start_year:
VAL 0
4.party_stop_day:
VAL 1
4.party_stop_month:
VAL 1
4.party_stop_time:
VAL 0
4.party_stop_year:
VAL 0
4.party_temperature:
VAL 5.000000
4.set_temperature:
VAL 20.000000
4.valve_state:
VAL 14
Attributes:
IODev CCU2
ccureadingfilter (^SET_TEMPERATURE|^TEMPERATURE|^HUMIDITY|LOWBAT|^VALVE|^CONTROL|^WINDOW_OPEN)
cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
controldatapoint 4.SET_TEMPERATURE
event-on-change-reading .*
eventMap /datapoint 4.MANU_MODE 19.0:Manu/datapoint 4.AUTO_MODE 4:Auto/datapoint 4.BOOST_MODE 4:Boost/datapoint 4.MANU_MODE 10.0:off/datapoint 4.MANU_MODE 21.0:on/
group Heizung
icon temp_control
room 2_Schlafzimmer
stateFormat Temp: 4.ACTUAL_TEMPERATURE° | Gewünscht: 4.SET_TEMPERATURE° | Ventil: 4.VALVE_STATE%<br>Modus: 4.CONTROL_MODE
statechannel 4
statedatapoint SET_TEMPERATURE
stripnumber 1
substitute LOWBAT!(0|false):no,(1|true):yes;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed
webCmd control:Auto:Manu:Boost:on:off
widgetOverride control:slider,10.0,0.5,25.0,1
Der Datenpunkt fehlt im Attribut ccureadingfilter
(^SET_TEMPERATURE|^TEMPERATURE|^HUMIDITY|LOWBAT|^VALVE|^CONTROL|^WINDOW_OPEN|ACTUAL_TEMPERATURE)
Oder
(TEMPERATURE|^HUMIDITY|LOWBAT|^VALVE|^CONTROL|^WINDOW_OPEN)
Ey, das kann doch echt nicht wahr sein!
Ich brech zusammen.
Ich hab gefühlte 56x alles kontrolliert...
Funktioniert jetzt.
Danke zap!
Gibt es eventuell bei der automatischen Aktualisierung von CUxD Geräten Probleme?
Eine genaue Fehlerbeschreibung siehe hier:
https://forum.fhem.de/index.php/topic,67006.0.html
Siehe erste Seite dieses Threads.
ZitatEinschränkungen: Der RPC Server unterstützt nur BidCos-RF und Wired Devices, also keine CUxD Devices! Die Set/Get Befehle der 3 HMCCU* Module unterstützen hingegen CUxD Devices. Für die Aktualisierung von CUxD Devices in FHEM sollten entsprechende AT-Devices verwendet werden.
Zitat von: mw77 am 13 Februar 2017, 11:37:33
Siehe erste Seite dieses Threads.
Argh..
Danke dir! Hab ich wohl überlsen :(
Hallo zusammen,
ich möchte meine Homematicgeräte gern in Alexa und homekit einbinden.
Hat jemand die homebridge mappings für...
die Keymatic (HM-Sec-Key)
das Heizungsthermostat (HM-CC-RT-DN)
den Rolladenaktor (HM-LC-Bl1PBU-FM)
?
Hallo,
habe folgendes bzw. folgende Probleme. Über die Standard-ccudefreadingfilter werden bei meinem Thermostat HM-CC-RT-DN u.a. die Readings
4.Party
angezeigt. Da ich diese Readings zur Zeit nicht haben möchte, war meine Überlegung in dem Device ein negierenden ccureadingfilter zu setzen. Ich habe daher
1. attr KuecheThermostat ccureadingfilte (!PARTY)
2. deletereading KuecheThermostat .*
durchgeführt.
Danach stürzt FHEM ab. Im Log steht
Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE / at ./FHEM/88_HMCCU.pm line 1571.
mehr passiert nicht. Erst ein Neustart des Raspi löst mein Problem. Dabei ist mir dann der zweite Fehler/Problem aufgefallen. Nach dem Neustart bleibt das HMCCU device im Start Initialized stehen. Erst ein manuelles Betätigen des Buttons on führt zur korrekten Arbeitsweise von meinem HMCCU und den Devices. Ich habe zu diesem Punkt zwar schon einiges gelesen, finde die Stelle aber nicht wieder und weiß auch nicht mehr, ob das Verhalten gewollt ist.
Gruß
Mundus
In ccureadingfilter wird '!' als Trenner zwischen Kanalname und Filterausdruck verwendet, wenn sich ein Filter nur auf einen Datenpunkt beziehen soll. Dein Filter führt zu einem unvollständigen regulären Ausdruck "PARTY)". Daher der Absturz. Grundsätzlich ein guter Hinweis für mich, an dieser Stelle in HMCCU eval zu verwenden, damit es bei falschen regulären Ausdrücken nicht FHEM in den Abgrund reißt.
Momentan gibt es keine Lösung für Dein Vorhaben, da ccureadingfilter keine "negativen" Filter unterstützt.
UPDATE: Habe gerade eine Negierung des Readingfilters eingebaut. Werde es noch testen und dann einchecken. Noch ein wenig Geduld ...
Zum anderen Problem:
Wenn nach dem Start von FHEM der RPC-Server nicht automatisch gestartet wird, musst Du im IO Device das Attribut rpcserver auf on setzen. Der Default ist off.
Hallo zap,
vielen Dank für deine schnelle und kompetente Antwort.
Zitat von: zap am 16 Februar 2017, 19:00:54
UPDATE: Habe gerade eine Negierung des Readingfilters eingebaut. Werde es noch testen und dann einchecken. Noch ein wenig Geduld ...
Darauf warte ich natürlich gerne.
Das Attribut rpcserver on habe ich gesetzt und nun funktioniert es tadellos.
Also DANKE.
Gruß Fabian
Moin,
leider werden die Readings von meiner Wetterstation HM-WDS100-C6-O-2 seit den 14.02.17 nicht mehr aktualisiert.
hatte da ein define d_ccu_vars at +*00:01:00 get d_ccu vars Regen|Temp|Sonnenstunden|Wind angelegt weil ich die Systemvariablen auslesen wollte.
Die Systemvariablen werden auch unter HMCCU angezeigt und aktualisiert.
Nur bei den Readings der Wetterstaton erfolgt keine aktualisierung der readings mehr.
habe jetzt die Wetterstation noch mal angelegt
in den readings steht nur:
hmstate nitialized 2017-02-17 07:15:50
state Initialized 2017-02-17 06:59:12
nach get Update kam hinzu
Activity alive 2017-02-17 07:19:24
battery ok 2017-02-17 07:19:24
Update:
nach
attr d_ccu ccudef-readingfilter .*
get Wetterstation update
kommen alle readings wieder
Zitat von: fini am 17 Februar 2017, 07:26:27
habe jetzt die Wetterstation noch mal angelegt
in den readings steht nur:
hmstate nitialized 2017-02-17 07:15:50
state Initialized 2017-02-17 06:59:12
nach get Update kam hinzu
Activity alive 2017-02-17 07:19:24
battery ok 2017-02-17 07:19:24
Drei Dinge, die Du prüfen kannst:
1. Hast Du noch andere HMCCUDEV oder HMCCUCHN Devices definiert und wenn ja, werden bei denen die Readings aktualisiert?
2. Hast Du bei der Wetterstation das Attribut "ccureadingfilter" gesetzt und/oder hast Du im IO Device das Attribut ccudef-readingfilter gesetzt? Wenn ja, wie sehen die beiden Attribute aus?
3. Läuft der RPC-Server?
zap läuft wieder ...
nach
attr d_ccu ccudef-readingfilter .*
get Wetterstation update
ging es wieder.
Version 3.9.003 dürfte morgen per Update verfügbar sein.
Änderungen:
Die Abarbeitungsreihenfolge von ccudef-readingfilter und ccureadingfilter wurde umgekehrt. Das globale Attribut ccudef-readingfilter wird nun zuerst ausgewertet.
Wenn beim Attribut ccureadingfilter eine Filterregel mit "N:" beginnt, wird die Bedingung umgekehrt. Wenn man z.B. alle Datenpunkte außer solche die PARTY enthalten als Readings haben möchte, kann man ccureadingfilter so setzen
N:PARTY
Um mehr Datenpunkte auszuschließen:
N:(PARTY|^RSSI)
Oder alle STATE Datenpunkte außer dem von Kanal "TASTE1":
N:TASTE1!STATE;STATE
N: bezieht sich also immer auf genau einen Filter. Das STATE nach dem Semikolon ist wieder ein "Include" Filter. Das funktioniert deshalb, weil bei negierten Filtern die Regelverarbeitung fortgesetzt wird, wenn der Filter nicht passt.
Hallo,
ich versuche gerade meine CCU2 über dieses Modul in FHEM einzubinden. Die Definition habe ich nach Wiki vorgenommen mit:
define d_ccu2 HMCCU 192.168.0.200
attr d_ccu2 rpcinterfaces BidCos-RF,VirtualDevices
attr d_ccu2 rpcinterval 5
attr d_ccu2 rpcport 2001,9292
attr d_ccu2 rpcqueue /tmp/ccuqueue
attr d_ccu2 rpcserver on
attr d_ccu2 stateFormat rpcstate/state
Leider kommt das Device dann nicht aus dem Status "starting/busy" heraus. Ich bin mir nicht sicher, ob der RPC-Server wirklich startet, auch wenn es im Log erstmal danach aussieht:
2017.02.19 15:25:24 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.02.19 15:25:24 0: HMCCU: Child process for server CB2001 started with PID 11631
2017.02.19 15:25:24 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001_1
2017.02.19 15:25:24 0: CCURPC: Initializing RPC server CB2001
2017.02.19 15:25:24 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.02.19 15:25:24 0: HMCCU: Child process for server CB9292 started with PID 11632
2017.02.19 15:25:24 0: CCURPC: CB9292 Creating file queue /tmp/ccuqueue_9292_1
2017.02.19 15:25:24 0: CCURPC: Initializing RPC server CB9292
2017.02.19 15:25:24 0: RPC server(s) starting
2017.02.19 15:25:24 0: CCURPC: Callback server created listening on port 14702
2017.02.19 15:25:24 0: CCURPC: Callback server created listening on port 7411
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for events
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for events
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for new devices
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for new devices
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for deleted devices
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for deleted devices
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for modified devices
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for modified devices
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for replaced devices
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for replaced devices
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for readded devices
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for readded devices
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for list devices
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for list devices
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for event query
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for event query
2017.02.19 15:25:24 0: CCURPC: CB9292 Entering server loop
2017.02.19 15:25:24 0: CCURPC: CB2001 Entering server loop
2017.02.19 15:25:29 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2017.02.19 15:25:36 1: HMCCU: Registering callback http://192.168.0.30:7411/fh2001 with ID CB2001 at http://192.168.0.200:2001/
2017.02.19 15:25:36 1: HMCCU: RPC callback with URL http://192.168.0.30:7411/fh2001 initialized
2017.02.19 15:25:41 0: HMCCU: Received SL event. RPC server CB9292 enters server loop
2017.02.19 15:25:48 1: HMCCU: Registering callback http://192.168.0.30:14702/fh9292 with ID CB9292 at http://192.168.0.200:9292/groups
2017.02.19 15:25:58 1: HMCCU: RPC callback with URL http://192.168.0.30:14702/fh9292 initialized
2017.02.19 15:30:43 2: HMCCU: Received no events from CCU since 300 seconds
Aber: [root@T20 fhem]# "ps -ef | grep ccurpcd.pl
>
Ich arbeite unter Centos 7.3, falls das relevant ist. Wo sollte ich weiter forschen?
Thomas
schwierig. Bis einschließlich der Meldungen "RPC callback ... initialized" ist alles wie es sein soll. Aber danach kommt eben nichts mehr. Da fehlen noch einige Meldungen. Die CCU müsste auf die Registrierung mit Rückmeldungen reagieren.
Den Prozess ccurpcd wirst Du nicht finden. Der wird nicht mehr verwendet. Stattdessen starten 2 zusätzliche fhem.pl Prozesse. Das ist aber nicht das Problem. Ich denke, dass die korrekt gestartet werden.
Frage: Hat Dein System mehrere Netzwerk Interfaces oder eine Firewall?
Wie sieht die Ausgabe von "netstat -an | grep LISTEN" aus?
Super, das Stichwort "Firewall" war genau richtig. Ich habe jetzt die Ports 7411 und 14702, die ich im Logfile gefunden habe, geöffnet und nun wechselt der Status auch zu "running/OK".
Sind diese Ports fix? Kann und soll ich das mal in der Wiki ergänzen?
Viele Grüße
Thomas
Zitat von: ~Thomas am 19 Februar 2017, 17:36:03
Super, das Stichwort "Firewall" war genau richtig. Ich habe jetzt die Ports 7411 und 14702, die ich im Logfile gefunden habe, geöffnet und nun wechselt der Status auch zu "running/OK".
Sind diese Ports fix? Kann und soll ich das mal in der Wiki ergänzen?
Viele Grüße
Thomas
Nein die sind nicht fix sondern werden nach einer Formel berechnet. Hier der Auszug aus der Online Doku zum Attribut 'rpcserverport':
rpcserverport <base-port>
Specify base port for RPC server. The real listening port of an RPC server is calculated by the formula: base-port + rpc-port + (10 * ccu-number). Default value for base-port is 5400.
The value ccu-number is only relevant if more than one CCU is connected to FHEM. Example: If base-port is 5400, protocol is BidCos (rpc-port 2001) and only one CCU is connected the resulting RPC server port is 5400+2001+(10*1) = 7411
Moin,
habe mal wieder ein Problem.
Nachdem ich meine CCU2 neu gestartet habe, werden die Readings von allen Geräten nicht mehr aktualisiert.
Komisch nur, die Readings direkt unter MMCCU werden aktualisiert. Aber nicht die HMCCUDEV.
Bis zum Neustart der CCU2 lief alles ...
Nach get Update aktulisiert er die Gerätereadings einmal ... danach nicht mehr
RPCPRC internal
RPCState running
STATE running/OK
Wenn Du die CCU neu startest, musst Du danach auch den RPC-Server neu starten. Leider merkt sich die CCU beim einem Neustart nicht die registrierten Event-Empfänger (z.B. FHEM/HMCCU).
Hi,
ich muss hier noch eine Frage loswerden, damit ich mein HMIP-eTRV noch besser einbinden kann. Bei meinem Homematic Thermostat HM-CC-RT-DN habe ich mittels
get KuecheThermostat configlistüber die Readings hinaus weitere Werte ermittelt. Mit
attr KuecheThermostat userreading Gesperrt {fhem "get KuecheThermostat configlist LOCK"}habe ich für mich relevante Readings gespeichert und alles funktioniert wunderbar. Das gleiche möchte ich mit dem HMIP-eTRV auch erreichen. Wenn ich bei dem HMIP-eTRV den Befehl
get FlurThermostat configlistabsetze, erhalte ich die Antwort
ZitatHMCCUDEV: FlurThermostat No response from CCU
Wo liegt mein Fehler? Bzw. wie kann ich den Zustand Gesperrt für das HMIP-eTRV abfragen und im nächsten Schritt sogar setzen? Bei dem HM-CC-RT-DN hat es so funktioniert:
config BUTTON_LOCK=true:Sperren/config BUTTON_LOCK=false:EntsperrenGruß
Mundus
Viel zu kompliziert. Das Userreading brauchst Du nicht. Ich beziehe mich jetzt mal auf das alte Thermostat. Du machst einfach ein
get KuecheThermostat config LOCK
Dabei darauf achten, dass das Attribut ccureadingfilter LOCK enthält. Damit werden dann Readings erzeugt, die alle mit "R-" beginnen (als Abgrenzung zu den normalen Datenpunkt Readings).
Der Befehl "get configlist" ist nur dafür gedacht, sich die möglichen Config-Parameter anzeigen zu lassen, da diese im Gegensatz zu den Datenpunkten nicht dokumentiert sind.
Ein weiterer Unterschied zu Datenpunkten ist, dass Config-Parameter nicht nur an den Kanälen eines Gerätes hängen sondern auch am Gerät selbst (Datenpunkte sind ausschließlich Kanälen zugeordnet. Um die Config-Parameter eines Hm-IP Thermostaten zu ermitteln, solltest Du also den Befehl "get configlist" sowohl für das Device als auch für die einzelnen Kanäle ausführen:
get FlurThermostat configlist
get FlurThermostat 1 configlist
get FlurThermostat 2 configlist
usw.
Den 1. Befehl hast Du schon ausprobiert. Die Anzahl der Kanäle wird im Internal channels angezeigt. Wenn Du dann den richtigen Kanal mit dem entsprechenden Config-Parameter für den Lock gefunden hast, kannst Du die Readings wiederum so erzeugen:
get FlurThermostat 1 config xxxx
Zitat von: zap am 23 Februar 2017, 21:23:52
Viel zu kompliziert. Das Userreading brauchst Du nicht. Ich beziehe mich jetzt mal auf das alte Thermostat. Du machst einfach ein
get KuecheThermostat config LOCK
Dabei darauf achten, dass das Attribut ccureadingfilter LOCK enthält. Damit werden dann Readings erzeugt, die alle mit "R-" beginnen (als Abgrenzung zu den normalen Datenpunkt Readings).
Da das bei mir zu einer sehr unübersichtlichen Liste geführt hat -alle R- - erscheinen auch als Readings, habe ich den anderen Weg gewählt. Außerdem hat die Ergänzung des ccureadingfilter um LOCK, zu dem nachfolgenden Phänomen geführt -Es wird nur noch das userreading angezeigt-. Zur besseren Visualisierung die beiden entsprechenden list (zuerst mit LOCK):
Internals:
CHANGED
DEF MEQ
IODev myHomeMatic
NAME KuecheThermostat
NR 71
STATE Temp: 4.ACTUAL_TEMPERATURE° | Gewünscht: 4.SET_TEMPERATURE° | Modus: 4.CONTROL_MODE
TYPE HMCCUDEV
ccuaddr MEQ
ccudevstate Active
ccuif BidCos-RF
ccuname HM-RT-Kueche
ccutype HM-CC-RT-DN
channels 7
statevals devstate
Readings:
2017-02-23 23:04:52 Gesperrt BUTTON_LOCK=1
GLOBAL_BUTTON_LOCK=0
MODUS_BUTTON_LOCK=0
Hmccu:
Dp:
0.aes_key:
VAL 0
0.config_pending:
VAL false
0.device_in_bootloader:
VAL false
0.inhibit:
VAL false
0.lowbat:
VAL false
0.rssi_device:
VAL 1
0.rssi_peer:
VAL 161
0.sticky_unreach:
VAL false
0.unreach:
VAL false
0.update_pending:
VAL false
4.actual_temperature:
VAL 21.300000
4.battery_state:
VAL 3.000000
4.boost_state:
VAL 0
4.control_mode:
VAL 0
4.fault_reporting:
VAL 0
4.party_start_day:
VAL 1
4.party_start_month:
VAL 1
4.party_start_time:
VAL 0
4.party_start_year:
VAL 0
4.party_stop_day:
VAL 1
4.party_stop_month:
VAL 1
4.party_stop_time:
VAL 0
4.party_stop_year:
VAL 0
4.party_temperature:
VAL 5.000000
4.set_temperature:
VAL 17.000000
4.valve_state:
VAL 0
Attributes:
IODev myHomeMatic
ccureadingfilter N:(PARTY);LOCK
ccureadingformat datapoint
ccureadingname 4.BATTERY_STATE:Battery
ccureadings 1
cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus Sperren:secur_locked Entsperren:secur_open
controldatapoint 4.SET_TEMPERATURE
event-on-change-reading .*
eventMap /datapoint 4.MANU_MODE 20.0:Manu/datapoint 4.AUTO_MODE 1:Auto/datapoint 4.BOOST_MODE 1:Boost/datapoint 4.MANU_MODE 4.5:off/datapoint 4.MANU_MODE 30.5:on/config BUTTON_LOCK=true:Sperren/config BUTTON_LOCK=false:Entsperren
room HomeMatic
stateFormat Temp: 4.ACTUAL_TEMPERATURE° | Gewünscht: 4.SET_TEMPERATURE° | Modus: 4.CONTROL_MODE
statedatapoint 4.ACTUAL_TEMPERATURE
stripnumber 1
substexcl control
substitute UNREACH,LOWBAT!(0|false):no,(1|true):yes;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;SET_TEMPERATURE!#0-3.5:off,#30.5-40:on
userReadings Gesperrt {fhem "get KuecheThermostat configlist LOCK"}
webCmd control:Auto:Manu:Boost:on:off:Sperren:Entsperren
widgetOverride control:slider,4.5,0.5,30.5,1 und jetzt ohne LOCK im ccureadingfilter:
Internals:
DEF MEQ
IODev myHomeMatic
NAME KuecheThermostat
NR 71
STATE Temp: 21.3° | Gewünscht: 17.0° | Modus: AUTO
TYPE HMCCUDEV
ccuaddr MEQ
ccudevstate Active
ccuif BidCos-RF
ccuname HM-RT-Kueche
ccutype HM-CC-RT-DN
channels 7
statevals devstate
Readings:
2017-02-23 23:10:20 0.AES_KEY 0
2017-02-23 23:10:20 0.CONFIG_PENDING false
2017-02-23 23:10:20 0.DEVICE_IN_BOOTLOADER false
2017-02-23 23:10:20 0.INHIBIT false
2017-02-23 23:10:20 0.LOWBAT no
2017-02-23 23:10:20 0.RSSI_DEVICE 1
2017-02-23 23:10:20 0.RSSI_PEER 161
2017-02-23 23:10:20 0.STICKY_UNREACH false
2017-02-23 23:10:20 0.UNREACH no
2017-02-23 23:10:20 0.UPDATE_PENDING false
2017-02-23 23:10:20 4.ACTUAL_TEMPERATURE 21.3
2017-02-23 23:10:20 4.BOOST_STATE 0
2017-02-23 23:10:20 4.CONTROL_MODE AUTO
2017-02-23 23:10:20 4.FAULT_REPORTING 0
2017-02-23 23:10:20 4.SET_TEMPERATURE 17.0
2017-02-23 23:10:20 4.VALVE_STATE 0
2017-02-23 23:10:20 Battery 3.0
2017-02-23 23:10:20 Gesperrt BUTTON_LOCK=1
GLOBAL_BUTTON_LOCK=0
MODUS_BUTTON_LOCK=0
2017-02-23 23:10:20 control 17.0
2017-02-23 23:10:20 hmstate 21.3
2017-02-23 23:10:20 state 21.3
Hmccu:
Dp:
0.aes_key:
VAL 0
0.config_pending:
VAL false
0.device_in_bootloader:
VAL false
0.inhibit:
VAL false
0.lowbat:
VAL false
0.rssi_device:
VAL 1
0.rssi_peer:
VAL 161
0.sticky_unreach:
VAL false
0.unreach:
VAL false
0.update_pending:
VAL false
4.actual_temperature:
VAL 21.300000
4.battery_state:
VAL 3.000000
4.boost_state:
VAL 0
4.control_mode:
VAL 0
4.fault_reporting:
VAL 0
4.party_start_day:
VAL 1
4.party_start_month:
VAL 1
4.party_start_time:
VAL 0
4.party_start_year:
VAL 0
4.party_stop_day:
VAL 1
4.party_stop_month:
VAL 1
4.party_stop_time:
VAL 0
4.party_stop_year:
VAL 0
4.party_temperature:
VAL 5.000000
4.set_temperature:
VAL 17.000000
4.valve_state:
VAL 0
Attributes:
IODev myHomeMatic
ccureadingfilter N:(PARTY)
ccureadingformat datapoint
ccureadingname 4.BATTERY_STATE:Battery
ccureadings 1
cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus Sperren:secur_locked Entsperren:secur_open
controldatapoint 4.SET_TEMPERATURE
event-on-change-reading .*
eventMap /datapoint 4.MANU_MODE 20.0:Manu/datapoint 4.AUTO_MODE 1:Auto/datapoint 4.BOOST_MODE 1:Boost/datapoint 4.MANU_MODE 4.5:off/datapoint 4.MANU_MODE 30.5:on/config BUTTON_LOCK=true:Sperren/config BUTTON_LOCK=false:Entsperren
room HomeMatic
stateFormat Temp: 4.ACTUAL_TEMPERATURE° | Gewünscht: 4.SET_TEMPERATURE° | Modus: 4.CONTROL_MODE
statedatapoint 4.ACTUAL_TEMPERATURE
stripnumber 1
substexcl control
substitute UNREACH,LOWBAT!(0|false):no,(1|true):yes;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;SET_TEMPERATURE!#0-3.5:off,#30.5-40:on
userReadings Gesperrt {fhem "get KuecheThermostat configlist LOCK"}
webCmd control:Auto:Manu:Boost:on:off:Sperren:Entsperren
widgetOverride control:slider,4.5,0.5,30.5,1 Mit dem Hinweis
Zitat von: zap am 23 Februar 2017, 21:23:52
Ein weiterer Unterschied zu Datenpunkten ist, dass Config-Parameter nicht nur an den Kanälen eines Gerätes hängen sondern auch am Gerät selbst (Datenpunkte sind ausschließlich Kanälen zugeordnet. Um die Config-Parameter eines Hm-IP Thermostaten zu ermitteln, solltest Du also den Befehl "get configlist" sowohl für das Device als auch für die einzelnen Kanäle ausführen:
get FlurThermostat configlist
get FlurThermostat 1 configlist
get FlurThermostat 2 configlist
usw.
Den 1. Befehl hast Du schon ausprobiert. Die Anzahl der Kanäle wird im Internal channels angezeigt. Wenn Du dann den richtigen Kanal mit dem entsprechenden Config-Parameter für den Lock gefunden hast, kannst Du die Readings wiederum so erzeugen:
habe ich dann den Befehl
get FlurThermostat configlist 0 und somit das Merkmal GLOBAL_BUTTON_LOCK gefunden. Und jetzt wird es kurios bzw. ich verstehe immer weniger (dachte zwischenzeitlich wäre es teilweise andersrum ;D). Wenn ich den Befehl
set FlurThermostat config 0 GLOBAL_BUTTON_LOCK=false absetze, dann wird im WEB-Inferface der CCU2 der entsprechende Haken entfernt und das war es. Das Thermostat selbst kriegt den Befehl nicht mitgeteilt. Es erscheint zwar im UI von der CCU2 noch eine Hinweis, es steht eine Servicemeldung auf dem Kanal 0 für das FlurThermostat bereit, aber es passiert nichts.
Wieso wird der Befehl nicht weitergegeben?
Gruß
Mundus
Das mit den R- Readings und dem Readingfilter schaue ich mir an. So wie du es beschreibst soll es jedenfalls nicht sein. Möglicherweise noch ein Bug.
Beim Setzen von Config Parametern kann es sein, dass diese nur verzögert von der CCU an das Gerät gesendet werden bzw. dass der erste Versuch fehlschlägt. In dem Fall gibt es eine Service Meldung, dass Daten zur Übertragung anstehen. Irgendwann überträgt die CCU die Daten dann und die Meldung verschwindet automatisch.
Das gleiche Verhalten kann man feststellen, wenn man Parameter direkt im CCU WebUI ändert.
Da HMCCU nur indirekt über die CCU mit den Geräten kommunizieren kann, kann ich da Programm seitig nichts machen.
Hmmm, alles komisch, hier ein Auszug des Eventmonitors, wenn ich den Befehl
set FlurThermostat config 0 GLOBAL_BUTTON_LOCK=false
absetze.
2017.02.24 13:03:32 5 : Cmd: >set FlurThermostat config 0 GLOBAL_BUTTON_LOCK=false<
2017.02.24 13:03:33 1 : HMCCU: Invalid parameter or value
2017.02.24 13:03:33 1 : HMCCUDEV: FlurThermostat Execution of CCU script or command failed
2017.02.24 13:03:33 4 : name: /fhem&fw_id=201&fwcsrf=fhem_372513837193697&cmd=set+FlurThermostat+config+0+GLOBAL_BUTTON_LOCK%3Dfalse / RL:1474 / text/html; charset=UTF-8 / Content-Encoding: gzip /
2017.02.24 13:03:33 4 : WEB_192.168.130.8_56558 GET /fhem?XHR=1&inform=type=status;filter=;since=1487937812;fmt=JSON&fw_id=201×tamp=1487937813733; BUFLEN:0
2017.02.24 13:03:35 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 13:03:36 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=false
2017.02.24 13:03:36 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.CONFIG_PENDING: 1
2017-02-24 13:03:36 HMCCUDEV FlurThermostat 0.CONFIG_PENDING: 1
2017-02-24 13:03:36 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 13:03:36 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=false
2017.02.24 13:03:36 5 : End notify loop for FlurThermostat
Anschließend ändert sich das UI der CCU2. WIe beschrieben wird die Globale Bediensperre im UI entsperrt und die Servicemeldung erzeugt. Dann passiert, wie ebenfalls gesagt, gar nichts. Die Servicemeldung wird nicht abgesetzt. (Auch nach einer Stunde nicht).
Nun versuche ich mal eine SD-Karte zu finden und das LOG der CCU2 zu analysieren...
Das Reading bzw. der Datenpunkt CONFIG_PENDING=1 deutet genau auf das hin, was ich oben. Geschrieben habe. Die CCU hat versucht, das Gerät zu konfigurieren, wird die Daten aber nicht los.
UPDATE: Weiter oben habe ich Blödsinn geschrieben. Beim Befehl "get config" wird das Attribut ccureadingfilter nicht berücksichtigt. Deshalb kann auch als Parameter ein regulärer Ausdruck als Filter angegeben werden.
Wenn ich bei einem meiner Thermostate (alt, kein HM-IP) den Befehl "get config LOCK" ausführe, erhalte ich 3 Readings:
R-BUTTON_LOCK 0 2017-02-24 16:49:01
R-GLOBAL_BUTTON_LOCK 0 2017-02-24 16:49:01
R-MODUS_BUTTON_LOCK 0 2017-02-24 16:49:01
m.E. kannst Du also auf das Userreading verzichten. Der entsprechende Befehl für einen bestimmten Kanal (hier 0) lautet dann:
get config 0 LOCK
Zitat von: zap am 24 Februar 2017, 14:16:50
Wenn ich bei einem meiner Thermostate (alt, kein HM-IP) den Befehl "get config LOCK" ausführe, erhalte ich 3 Readings:
R-BUTTON_LOCK 0 2017-02-24 16:49:01
R-GLOBAL_BUTTON_LOCK 0 2017-02-24 16:49:01
R-MODUS_BUTTON_LOCK 0 2017-02-24 16:49:01
m.E. kannst Du also auf das Userreading verzichten. Der entsprechende Befehl für einen bestimmten Kanal (hier 0) lautet dann:
get config 0 LOCK
Ich hatte das soweit vorher ausprobiert, aber die Informationen wurden dann nicht als Reading abgelegt. Ich probiere aber an dieser Sache weiter;-).
Bei dem Problem GLOBAL_BUTTON_LOCK=[true/false] für das HMIP Thermostat abzusetzen, bin ich noch nicht schlauer. Leider ist dies eine Funktionalität, die ich für mich als wichtig erachte. Hier mal meine bisher ermittelten verschiedenen LOGS.
1. GLOBAL_BUTTON_LOCK über UI der CCU2 zu setzen
LOG der CCU2
20:39:02 24.02.2017 HMIP-FlurThermostat:0 Konfigurationsdaten stehen zur Übertragung an
20:39:06 24.02.2017 HMIP-FlurThermostat:0 RSSI Gerät 220, Gerätekommunikation OK, RSSI Gerät 220, Gerätekommunikation OK, RSSI Gerät 220, Gerätekommunikation OK, Es stehen keine Konfigurationsdaten zur Übertragung an
20:39:07 24.02.2017 HMIP-FlurThermostat:0 RSSI Gerät 220, Gerätekommunikation OK, RSSI Gerät 220, Dutycycle OK, Batterie OK, Gerätekommunikation OK, Betriebspannung in V: 2.90, RSSI Partner 219
20:39:08 24.02.2017 HMIP-FlurThermostat:1 Urlaubsmodus nicht aktiv, Adaptionsfahrt durchgeführt, Ist-Temperatur 20.90, Solltemperatur nicht geändert, Boost-Funktion, Frostschutz nicht aktiv, Modus für Solltemperatur 0, Solltemperatur 21.00, Ventil-Öffnungsgrad 0.95, Aktives Profil 1, Fenster geschlossen
20:39:08 24.02.2017 HMIP-FlurThermostat:0 Konfigurationsdaten stehen zur Übertragung an
20:39:10 24.02.2017 HMIP-FlurThermostat:0 Es stehen keine Konfigurationsdaten zur Übertragung anLOG aus /var/log/messages
Feb 24 20:39:13 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
Feb 24 20:39:13 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]2. GLOBAL_BUTTON_LOCK über FHEM setzen
LOG FHEM -mE relevanter Teil-
2017.02.24 20:47:46 4 : WEB_192.168.130.8_34070 POST /fhem&detail=FlurThermostat&fwcsrf=fhem_372513837193697&dev.setFlurThermostat=FlurThermostat&cmd.setFlurThermostat=set&arg.setFlurThermostat=config&val.setFlurThermostat=0+GLOBAL_BUTTON_LOCK%3Dtrue; BUFLEN:0
2017.02.24 20:47:46 5 : Cmd: >set FlurThermostat config 0 GLOBAL_BUTTON_LOCK=true<
2017.02.24 20:47:47 1 : HMCCU: Invalid parameter or value
2017.02.24 20:47:47 1 : HMCCUDEV: FlurThermostat Execution of CCU script or command failed
2017.02.24 20:47:47 4 : name: /fhem&detail=FlurThermostat&fwcsrf=fhem_372513837193697&dev.setFlurThermostat=FlurThermostat&cmd.setFlurThermostat=set&arg.setFlurThermostat=config&val.setFlurThermostat=0+GLOBAL_BUTTON_LOCK%3Dtrue / RL:1476 / text/html; charset=UTF-8 / Content-Encoding: gzip /
2017.02.24 20:47:49 4 : WEB_192.168.130.8_34070 GET /fhem?XHR=1&inform=type=status;filter=;since=1487965666;fmt=JSON&fw_id=294×tamp=1487965669132; BUFLEN:0
2017.02.24 20:47:51 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:47:51 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:47:51 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.CONFIG_PENDING: 1
2017.02.24 20:47:51 5 : createNotifyHash
2017.02.24 20:47:51 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:47:51 HMCCUDEV FlurThermostat 0.CONFIG_PENDING: 1
2017-02-24 20:47:51 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:47:51 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:47:51 5 : End notify loop for FlurThermostat
2017.02.24 20:48:37 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:37 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:37 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.RSSI_DEVICE: -36
2017.02.24 20:48:37 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:37 HMCCUDEV FlurThermostat 0.RSSI_DEVICE: -36
2017-02-24 20:48:37 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:37 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:37 5 : End notify loop for FlurThermostatLOG FHEM -mE nicht mehr so relevant-
2017.02.24 20:48:37 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:37 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:37 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.DUTY_CYCLE: 0
2017.02.24 20:48:37 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:37 HMCCUDEV FlurThermostat 0.DUTY_CYCLE: 0
2017-02-24 20:48:37 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:37 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:37 5 : End notify loop for FlurThermostat
2017.02.24 20:48:37 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:37 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:37 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.LOW_BAT: 0
2017.02.24 20:48:37 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:37 HMCCUDEV FlurThermostat 0.LOW_BAT: 0
2017-02-24 20:48:37 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:37 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:37 5 : End notify loop for FlurThermostat
2017.02.24 20:48:37 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:38 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:38 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.UNREACH: 0
2017.02.24 20:48:38 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:38 HMCCUDEV FlurThermostat 0.UNREACH: 0
2017-02-24 20:48:38 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:38 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:38 5 : End notify loop for FlurThermostat
2017.02.24 20:48:38 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:38 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:38 5 : Starting notify loop for FlurThermostat, 3 event(s), first is Battery: 2.9
2017.02.24 20:48:38 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:38 HMCCUDEV FlurThermostat Battery: 2.9
2017-02-24 20:48:38 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:38 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:38 5 : End notify loop for FlurThermostat
2017.02.24 20:48:38 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:38 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:38 5 : Starting notify loop for FlurThermostat, 2 event(s), first is hmstate: 21.0
2017.02.24 20:48:38 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:38 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:38 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:38 5 : End notify loop for FlurThermostat
2017.02.24 20:48:38 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:38 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:38 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.VALVE_STATE: 4
2017.02.24 20:48:38 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:38 HMCCUDEV FlurThermostat 1.VALVE_STATE: 4
2017-02-24 20:48:38 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:38 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:38 5 : End notify loop for FlurThermostat
2017.02.24 20:48:38 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:39 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:39 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.ACTUAL_TEMPERATURE: 21.1
2017.02.24 20:48:39 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:39 HMCCUDEV FlurThermostat 1.ACTUAL_TEMPERATURE: 21.1
2017-02-24 20:48:39 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:39 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:39 5 : End notify loop for FlurThermostat
2017.02.24 20:48:39 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:39 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:39 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.SWITCH_POINT_OCCURED: 0
2017.02.24 20:48:39 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:39 HMCCUDEV FlurThermostat 1.SWITCH_POINT_OCCURED: 0
2017-02-24 20:48:39 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:39 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:39 5 : End notify loop for FlurThermostat
2017.02.24 20:48:39 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:39 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:39 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.BOOST_MODE: 0
2017.02.24 20:48:39 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:39 HMCCUDEV FlurThermostat 1.BOOST_MODE: 0
2017-02-24 20:48:39 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:39 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:39 5 : End notify loop for FlurThermostat
2017.02.24 20:48:39 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:39 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:39 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.FROST_PROTECTION: 0
2017.02.24 20:48:39 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:39 HMCCUDEV FlurThermostat 1.FROST_PROTECTION: 0
2017-02-24 20:48:39 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:39 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:39 5 : End notify loop for FlurThermostat
2017.02.24 20:48:39 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:40 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:40 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.SET_POINT_MODE: Auto
2017.02.24 20:48:40 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:40 HMCCUDEV FlurThermostat 1.SET_POINT_MODE: Auto
2017-02-24 20:48:40 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:40 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:40 5 : End notify loop for FlurThermostat
2017.02.24 20:48:40 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:40 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:40 5 : Starting notify loop for FlurThermostat, 5 event(s), first is 1.SET_POINT_TEMPERATURE: 21.0
2017.02.24 20:48:40 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:40 HMCCUDEV FlurThermostat 1.SET_POINT_TEMPERATURE: 21.0
2017-02-24 20:48:40 HMCCUDEV FlurThermostat control: 21.0
2017-02-24 20:48:40 HMCCUDEV FlurThermostat 21.0
2017-02-24 20:48:40 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:40 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:40 5 : End notify loop for FlurThermostat
2017.02.24 20:48:40 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:40 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:40 5 : Starting notify loop for FlurThermostat, 3 event(s), first is valve_position: 95
2017.02.24 20:48:40 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:40 HMCCUDEV FlurThermostat valve_position: 95
2017-02-24 20:48:40 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:40 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:40 5 : End notify loop for FlurThermostat
2017.02.24 20:48:40 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:40 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:40 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.ACTIVE_PROFILE: 1
2017.02.24 20:48:40 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:40 HMCCUDEV FlurThermostat 1.ACTIVE_PROFILE: 1
2017-02-24 20:48:40 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:40 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:40 5 : End notify loop for FlurThermostat2017.02.24 20:48:40 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:41 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:41 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.WINDOW_STATE: closed
2017.02.24 20:48:41 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:41 HMCCUDEV FlurThermostat 1.WINDOW_STATE: closed
2017-02-24 20:48:41 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:41 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:41 5 : End notify loop for FlurThermostat
2017.02.24 20:48:41 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:41 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:41 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.CONFIG_PENDING: 1
2017.02.24 20:48:41 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:41 HMCCUDEV FlurThermostat 0.CONFIG_PENDING: 1
2017-02-24 20:48:41 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:41 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:41 5 : End notify loop for FlurThermostat
2017.02.24 20:48:41 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:41 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:41 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.CONFIG_PENDING: 1
2017.02.24 20:48:41 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:41 HMCCUDEV FlurThermostat 0.CONFIG_PENDING: 1
2017-02-24 20:48:41 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:41 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:41 5 : End notify loop for FlurThermostat
2017.02.24 20:48:41 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:41 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:41 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.CONFIG_PENDING: 1
2017.02.24 20:48:41 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:41 HMCCUDEV FlurThermostat 0.CONFIG_PENDING: 1
2017-02-24 20:48:41 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:41 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:41 5 : End notify loop for FlurThermostat2017.02.24 20:48:41 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:42 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:42 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.CONFIG_PENDING: 1
2017.02.24 20:48:42 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:42 HMCCUDEV FlurThermostat 0.CONFIG_PENDING: 1
2017-02-24 20:48:42 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:42 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:42 5 : End notify loop for FlurThermostat
2017.02.24 20:48:42 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:42 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:42 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.CONFIG_PENDING: 1
2017.02.24 20:48:42 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:42 HMCCUDEV FlurThermostat 0.CONFIG_PENDING: 1
2017-02-24 20:48:42 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:42 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:42 5 : End notify loop for FlurThermostat
2017.02.24 20:48:42 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:42 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:42 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.CONFIG_PENDING: 1
2017.02.24 20:48:42 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:42 HMCCUDEV FlurThermostat 0.CONFIG_PENDING: 1
2017-02-24 20:48:42 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:42 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:42 5 : End notify loop for FlurThermostat
2017.02.24 20:48:42 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 20:48:42 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:42 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.CONFIG_PENDING: 1
2017.02.24 20:48:42 5 : testBattStatus: not on any display, ignoring notify
2017-02-24 20:48:42 HMCCUDEV FlurThermostat 0.CONFIG_PENDING: 1
2017-02-24 20:48:42 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 20:48:42 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=true
2017.02.24 20:48:42 5 : End notify loop for FlurThermostatLOG der CCU2
20:47:47 24.02.2017 HMIP-FlurThermostat:0 Konfigurationsdaten stehen zur Übertragung an
20:48:33 24.02.2017 HMIP-FlurThermostat:0 RSSI Gerät 220, Dutycycle OK, Batterie OK, Gerätekommunikation OK, Betriebspannung in V: 2.90
20:48:33 24.02.2017 HMIP-FlurThermostat:1 Urlaubsmodus nicht aktiv, Adaptionsfahrt durchgeführt, Ist-Temperatur 21.10, Solltemperatur nicht geändert, Boost-Funktion, Frostschutz nicht aktiv, Modus für Solltemperatur 0, Solltemperatur 21.00, Ventil-Öffnungsgrad 0.95, Aktives Profil 1, Fenster geschlossen
20:48:34 24.02.2017 HMIP-FlurThermostat:0 Konfigurationsdaten stehen zur Übertragung an, Konfigurationsdaten stehen zur Übertragung an, Konfigurationsdaten stehen zur Übertragung an, Konfigurationsdaten stehen zur Übertragung an, Konfigurationsdaten stehen zur Übertragung an, Konfigurationsdaten stehen zur Übertragung an
20:48:35 24.02.2017 HMIP-FlurThermostat:0 Konfigurationsdaten stehen zur Übertragung anLOG aus /var/log/messages
ailed: [-1] 0 0x00 [0] 97 0x61 [1] 0 0x00 [2] 99 0x63 [3] 0 0x00 [4] 100 0x64 [../Platform/DOM/iseESPexec.cpp (11622)
Feb 24 20:45:55 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
Feb 24 20:45:55 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]Wo liegt denn eigentlich das Problem. Verarbeitet CCU2 die Befehle bei den HMIP anders oder wieso werden diese nicht abgesetzt?
Zitat von: zap am 24 Februar 2017, 07:29:26Da HMCCU nur indirekt über die CCU mit den Geräten kommunizieren kann, kann ich da Programm seitig nichts machen.
Aber bereits FHEM meldet direkt nach absetzen des Befehls
2017.02.24 20:47:47 1 : HMCCU: Invalid parameter or value
2017.02.24 20:47:47 1 : HMCCUDEV: FlurThermostat Execution of CCU script or command failed und trotzdem wird auf der CCU2 gearbeitet -zumindest ansatzweise :'(-.
Versuche mal:
set FlurThermostat config 0 GLOBAL_BUTTON_LOCK=0
Zitat von: zap am 26 Februar 2017, 09:34:31
Versuche mal:
set FlurThermostat config 0 GLOBAL_BUTTON_LOCK=0
Das führt leider zu keiner Veränderung... Die Fehlermeldungen sind nahezu identisch. Ich werde mal Kontakt zu eq3 aufnehmen, vielleicht gibt es eine Lösung.
Gruß
Mundus
Was wird bei
Get configlist 0
Angezeigt?
Btw: die RSSI Werte für dein Device sind sehr hoch. Deutet auf schlechte Verbindung hin und könnte die Ursache für den Fehler bei der Übertragung der Config an das Device sein. Das hat aber nichts mit der Fehlermeldung beim Set Befehl zu tun.
Hi zap,
kann ich eig. in einer FHEM-Installation 2 verschiedene CCUs einbinden die per VPN im gleichen Netzwerk wie FHEM hängen?
VG, Thomas
Hi ZAP,
get configlist 0
gibt
ARR_TIMEOUT=10
CYCLIC_INFO_MSG=1
CYCLIC_INFO_MSG_DIS=20
CYCLIC_INFO_MSG_DIS_UNCHANGED=0
CYCLIC_INFO_MSG_OVERDUE_THRESHOLD=2
DAYLIGHT_SAVINGS_TIME=1
DST_END_DAY_OF_WEEK=0
DST_END_MONTH=10
DST_END_TIME=180
DST_END_WEEK_OF_MONTH=5
DST_START_DAY_OF_WEEK=0
DST_START_MONTH=3
DST_START_TIME=120
DST_START_WEEK_OF_MONTH=5
DUTYCYCLE_LIMIT=180
ENABLE_ROUTING=1
GLOBAL_BUTTON_LOCK=0
LOCAL_RESET_DISABLED=0
LOW_BAT_LIMIT=2.2
UTC_DST_OFFSET=120
UTC_OFFSET=60
zurück.
Den Hinweis mit den RSSI-Werten verstehe ich nicht, den erstens ist nur eine Wand zwischen CCU2 und Thermostat und keine 10 m (eher 5m) Distanz. Und zweitens sendet die CCU2 die Befehle ja direkt und dann gibt es keine Probleme. Zudem ändert sich der RSSI-Wert nach absetzen des Befehls
2017.02.24 20:48:37 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.RSSI_DEVICE: -36
Gruß
Mundus
Moin,
verstehe nicht, wenn der meine PI neu starte, dass alle angelegten Geräte weg sind.
Muss sie dann immer neu anlegen.
Ist dat normal?
Zitat von: fini am 27 Februar 2017, 14:37:46
Moin,
verstehe nicht, wenn der meine PI neu starte, dass alle angelegten Geräte weg sind.
Muss sie dann immer neu anlegen.
Ist dat normal?
Sicher nicht. Ich nehme an, Du speicherst die Konfiguration nach dem anlegen?
Gibt es beim Start von FHEM irgendwelche Fehlermeldungen im Logfile mit Bezug zu HMCCU, HMCCUDEV oder HMCCUCHN?
Zitat von: Mundus am 27 Februar 2017, 13:08:37
zurück.
Den Hinweis mit den RSSI-Werten verstehe ich nicht, den erstens ist nur eine Wand zwischen CCU2 und Thermostat und keine 10 m (eher 5m) Distanz. Und zweitens sendet die CCU2 die Befehle ja direkt und dann gibt es keine Probleme. Zudem ändert sich der RSSI-Wert nach absetzen des Befehls
2017.02.24 20:48:37 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.RSSI_DEVICE: -36
Gruß
Mundus
Vergiss das mit dem RSSI Wert. Was meinst Du mit "sendet die CCU2 die Befehle ja direkt und dann gibt es keine Probleme"? Also wenn Du im WebUI der CCU den Haken bei Lock setzt, wird das auch korrekt zum Gerät übertragen?
Probiere bitte mal aus, ob der Befehl "get configdesc 0" funktioniert. Leider gibt es nicht für jedes Gerät diese Möglichkeit. Aber Versuch mach klug ;-)
Zitat von: zap am 27 Februar 2017, 16:19:31
Sicher nicht. Ich nehme an, Du speicherst die Konfiguration nach dem anlegen?
Gibt es beim Start von FHEM irgendwelche Fehlermeldungen im Logfile mit Bezug zu HMCCU, HMCCUDEV oder HMCCUCHN?
klar sicher ich die Einstellungen.
Komisch ist nur, dass nur alle HMCCUDEV weg sind.
Habe Sie jetzt wieder angelegt.
Server neu gestartet ...
Und wieder alle HMCCUDEV weg.
Unter im Anhang das Logfile
Hier liegt das Problem:
2017.02.27 17:11:46 1: HMCCU: 500 Can't connect to 192.168.178.116:8181
2017.02.27 17:11:47 1: define Sromzaehler1 HMCCUDEV MEQ1125981: Cannot detect IO device
In der ersten Zeile wird das HMCCU I/O Device definiert. Dabei wird versucht, von der CCU2 alle bekannten Devices abzufragen. Das schlägt fehl, weil kein Verbindungsaufbau zu CCU2 (192.168.178.116 Port 8181) möglich ist.
Danach schlagen die HMCCUDEV Defines fehl, weil das I/O Device die Geräte nicht kennt. Das funktioniert so: Wenn du beim Define mit HMCCUDEV eine Adresse oder einen Gerätenamen angibst, sucht HMCCUDEV ein I/O Device (HMCCU), das für diese Geräteadresse zuständig ist. Findet in dem Fall natürlich keins. Daher "cannot detect IO device".
Ggf. mal die CCU2 neu starten. Du musst die Geräte auch nicht nochmal definieren. Sie sollten im fhem.cfg File noch drin sein. Wenn Du das Verbindungsproblem mit der CCU gelöst hast, FHEM neu starten und dann sollte sie wieder da sein.
hmm ...
Die CCU2 ist eigentlich immer erreichbar.
Nur nicht wenn ich den PI neu starte
Das gleiche habe ich mit der Hue Bridge
Da ist wenn ich PI nue starte auch keine Verbindung.
Die Einträge in Fhem bleiben alle.
Noch ganz komisch ...
Direkt in den Readings von HMCCU werden die Werte aktualisiert nach PI neustart weiter.
habe noch den Fehler im Log
2017.02.27 20:58:07 3: Can't connect to 192.168.178.1:1012: Das Netzwerk ist nicht erreichbar
2017.02.27 20:58:07 3: Can't connect to 192.168.178.1:1012: connect to http://192.168.178.1:1012: Das Netzwerk ist nicht erreichbar
also kurz nach den Start kann er die Fritz Box nicht erreichen.
Dadurch auch nicht die CCU2 und die Hue Bridge.
Ach Mensch ... mein Kopf raucht schon ....
hier noch von hmccu direkt nach den Neustart des PI
Die Readings werden aktualisiert.
mit rereadcfg waren die Geräte wieder da.
Ja, immer wenn ich den PI neu starte lädt er die Geräte nicht.
Nach rereadcfg ist dann alles wieder ok ...
Wenn ich Fhem neu starte ist danach immer alles noch ok.
Nur wenn den PI neu starte dann nicht.
Du hast ein Netzwerk Problem oder FHEM wird gestartet, bevor der PI sein Netzwerk gestartet hat. wLAn?
Also die CCU ist per Wlan angeschlossen.
PI direkt an der Fritzbox per Kabel
Hallo fini,
hast Du einen Raspberry unter Jessie laufen? Dort wird das Netzwerk verspätet gestartet. Schau mal unter raspi-config/Boot Options/B2.
Gruß, Raymund
Ja, PI läuft auf Raspbian Jessie Lite
wo finde ich unter raspi-config/Boot Options/B2.
in root Verzeichnis finde ich es nicht
raspi-config in der Shell eingeben. Dann kommt ein Menu. Dort Boot Options wählen und unter B2 "ja".
ok, habe ich gemacht ...
Hat aber nichts gebracht :-[
Also nach Neustart des Server immer noch die gleichen Probleme.
Anbei Log ...
Schade, ich hatte ähnliche Symptome und das war's dann nach dem nächsten Reboot.
ein Versuch war es Wert ...
Naja, muss ich nach dem Neustart des Server Fhem noch mal neu starten und dann geht es.
Vielleicht hat ja noch einer eine Idee?
Bei jessi wird FHEM doch über systemctl gestartet. Im entsprechenden Config File kann man als Abhängigkeit das Netzwerk angeben. Dann klappt auch das korrekte Starten von FHEM.
Ist im Wiki beschrieben
https://wiki.fhem.de/wiki/Benutzer:Benheim/Startscript_systemd
Zitat von: zap am 28 Februar 2017, 12:01:13
Bei jessi wird FHEM doch über systemctl gestartet. Im entsprechenden Config File kann man als Abhängigkeit das Netzwerk angeben. Dann klappt auch das korrekte Starten von FHEM.
Ist im Wiki beschrieben
https://wiki.fhem.de/wiki/Benutzer:Benheim/Startscript_systemd
oje ... dass soll ich jetzt verstehen
Hab es mir angeschaut ... keine Ahnung wie ich das jetzt umsetzen soll 8)
Dann sag uns, wie Deine Datei JETZT aussieht ..... ... meine Glaskugel ist defekt ...
brauchst keine Glaskugel ... ;-)
Die Datei gibt es noch gar nicht und muss erstellt werden.
Aber was da jetzt rein muss ... keine Ahnung.
Mhhh ... und im Wiki steht ja überhaupt nichts ...
Nimm bitte den "Stänkermodus" nicht persönlich, ist nur hier gerade etwas "stressig"
doch da steht viel :o
Aber man muss es auch verstehen und umsetzen können ;-)
Zitat von: zap am 27 Februar 2017, 16:37:29
Was meinst Du mit "sendet die CCU2 die Befehle ja direkt und dann gibt es keine Probleme"? Also wenn Du im WebUI der CCU den Haken bei Lock setzt, wird das auch korrekt zum Gerät übertragen?
Genau, vom WebUI der CCU gelangt der Befehl zum Thermostat und wird auch relativ zeitnah abgearbeitet. s. hier:
Zitat von: Mundus am 24 Februar 2017, 21:35:04
Hier mal meine bisher ermittelten verschiedenen LOGS.
1. GLOBAL_BUTTON_LOCK über UI der CCU2 zu setzen
LOG der CCU2
20:39:02 24.02.2017 HMIP-FlurThermostat:0 Konfigurationsdaten stehen zur Übertragung an
20:39:06 24.02.2017 HMIP-FlurThermostat:0 RSSI Gerät 220, Gerätekommunikation OK, RSSI Gerät 220, Gerätekommunikation OK, RSSI Gerät 220, Gerätekommunikation OK, Es stehen keine Konfigurationsdaten zur Übertragung an
20:39:07 24.02.2017 HMIP-FlurThermostat:0 RSSI Gerät 220, Gerätekommunikation OK, RSSI Gerät 220, Dutycycle OK, Batterie OK, Gerätekommunikation OK, Betriebspannung in V: 2.90, RSSI Partner 219
20:39:08 24.02.2017 HMIP-FlurThermostat:1 Urlaubsmodus nicht aktiv, Adaptionsfahrt durchgeführt, Ist-Temperatur 20.90, Solltemperatur nicht geändert, Boost-Funktion, Frostschutz nicht aktiv, Modus für Solltemperatur 0, Solltemperatur 21.00, Ventil-Öffnungsgrad 0.95, Aktives Profil 1, Fenster geschlossen
20:39:08 24.02.2017 HMIP-FlurThermostat:0 Konfigurationsdaten stehen zur Übertragung an
20:39:10 24.02.2017 HMIP-FlurThermostat:0 Es stehen keine Konfigurationsdaten zur Übertragung an
LOG aus /var/log/messages
Feb 24 20:39:13 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
Feb 24 20:39:13 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
Direkt über das FHEM komme ich leider noch nicht weiter.
Zitat von: zap am 27 Februar 2017, 16:37:29
Probiere bitte mal aus, ob der Befehl "get configdesc 0" funktioniert. Leider gibt es nicht für jedes Gerät diese Möglichkeit. Aber Versuch mach klug ;-)
Hier das Ergebnis:
ARR_TIMEOUT: INTEGER [RW]
CYCLIC_INFO_MSG: INTEGER [RW]
CYCLIC_INFO_MSG_DIS: INTEGER [RW]
CYCLIC_INFO_MSG_DIS_UNCHANGED: INTEGER [RW]
CYCLIC_INFO_MSG_OVERDUE_THRESHOLD: INTEGER [RW]
DAYLIGHT_SAVINGS_TIME: BOOL [RW]
DST_END_DAY_OF_WEEK: ENUM [RW]
DST_END_MONTH: INTEGER [RW]
DST_END_TIME: INTEGER [RW]
DST_END_WEEK_OF_MONTH: ENUM [RW]
DST_START_DAY_OF_WEEK: ENUM [RW]
DST_START_MONTH: INTEGER [RW]
DST_START_TIME: INTEGER [RW]
DST_START_WEEK_OF_MONTH: ENUM [RW]
DUTYCYCLE_LIMIT: INTEGER [RW]
ENABLE_ROUTING: BOOL [RW]
GLOBAL_BUTTON_LOCK: BOOL [RW]
LOCAL_RESET_DISABLED: BOOL [RW]
LOW_BAT_LIMIT: FLOAT [RW]
UTC_DST_OFFSET: INTEGER [RW]
UTC_OFFSET: INTEGER [RW] Der Befehl GLOBAL_BUTTON_LOCK ist BOOL und RW. Also müsste er anpassbar sein. Alles merkwürdig.
Gruß
Mundus
Zitat von: fini am 28 Februar 2017, 16:52:23
doch da steht viel :o
Aber man muss es auch verstehen und umsetzen können ;-)
Auf dem Pi:
vi /etc/systemd/system/fhem.service
Falls Du nicht root bist, vornedran ein "sudo" stellen.
Folgendes eintragen:
[Unit]
Description=FHEM service
After=network.target
Wants=network.target
[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
[Install]
WantedBy=multi-user.target
Abspeichern. Dann folgende Befehle ausführen (wieder mit sudo davor, wenn Du kein root bist:
systemctl daemon-reload
systemctl enable fhem.service
Fertig.
Zitat von: Mundus am 28 Februar 2017, 17:47:30
Der Befehl GLOBAL_BUTTON_LOCK ist BOOL und RW. Also müsste er anpassbar sein. Alles merkwürdig.
Sehe ich auch so, zumal folgender Befehl bei einem nicht-IP Thermostaten funktioniert:
set mydev config GLOBAL_BUTTON_LOCK=true
Da ist der Parameter dem Device zugeordnet, nicht dem Kanal 0. Scheint beim IP-Thermostaten anders zu sein.
Prüfe bitte mal, ob in der Datei /var/log/messages auf der CCU irgendwelche Fehler auftauchen, wenn Du den set Befehl ausführst. Oder hattest Du das schon geprüft? Dann sorry, versuche den Überblick zu behalten ;-)
Zitat von: zap am 28 Februar 2017, 20:36:08
Auf dem Pi:
vi /etc/systemd/system/fhem.service
Falls Du nicht root bist, vornedran ein "sudo" stellen.
Folgendes eintragen:
[Unit]
Description=FHEM service
After=network.target
Wants=network.target
[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
[Install]
WantedBy=multi-user.target
Abspeichern. Dann folgende Befehle ausführen (wieder mit sudo davor, wenn Du kein root bist:
systemctl daemon-reload
systemctl enable fhem.service
Fertig.
also nach den reboot sind jetzt alle Geräte da ... rpc läuft.
Supi ... danke zap!!!
Kannst Du noch mal schaun ins Logfiles ob wiklich alles ok ist?
Zitat von: Mundus am 24 Februar 2017, 21:35:04
Hier mal meine bisher ermittelten verschiedenen LOGS.
1. GLOBAL_BUTTON_LOCK über UI der CCU2 zu setzen
LOG aus /var/log/messages
Feb 24 20:39:13 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
Feb 24 20:39:13 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
2. GLOBAL_BUTTON_LOCK über FHEM setzen
LOG aus /var/log/messages
ailed: [-1] 0 0x00 [0] 97 0x61 [1] 0 0x00 [2] 99 0x63 [3] 0 0x00 [4] 100 0x64 [../Platform/DOM/iseESPexec.cpp (11622)
Feb 24 20:45:55 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
Feb 24 20:45:55 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
Einen Unterschied in den LOGs erkenne ich nicht wirklich. Insgesamt scheint der Befehl seltsam verarbeitet zu werden (egal ob CCU2 oder FHEM).
Die Antwort von eQ-3 auf meine Anfrage war auch nicht zielführend:
Zitathiermit möchten wir uns für das von Ihnen entgegengebrachte Interesse an unseren Produkten bedanken.
Bitte haben Sie Verständnis, dass der technische Support der eQ-3 AG in erster Linie auf die Beantwortung von technischen Detailfragen im Aftersales-Service zu unseren Produkten ausgerichtet ist.
Folgende Serviceleistungen und Themenbereiche bearbeiten wir daher nicht selbst.
- individuelle Programmerstellung
- Skriptprogrammierung
- Zusatzsoftware
- Expertenparameter
- Open Source Projekte
- OEM Bausätze
- Support auf Bauteilebene
- XML-RPC Schnittstelle
- Vorort-Service
- Fernwartung
- etc.
Viele dieser Leistungen können jedoch weitgehend über unsere geschulten Fachpartner und Fachhandwerker abgedeckt werden.
Das Netzwerk an qualifizierten Fachpartnern wird stetig erweitert.
Eine Übersicht der Bezugsquellen finden Sie hier:
http://www.eq-3.de/partner/bezugsquellen.html
Mit freundlichen Grüßen aus Leer
Ihr eQ-3 Support-Team
Daher versuche ich mal einen Fachpartner... Zur Zeit vermute ich, dass die Befehlssyntax bei dem HM-IP Gerät anders lautet, nur wie, da habe ich keine Ahnung... [0/1|false/true] sind es scheinbar nicht. Kann ich ermitteln, was die CCU2 an das HMIP Thermostat sendet?
Gruß
Mundus
Zitat von: fini am 01 März 2017, 06:44:30
also nach den reboot sind jetzt alle Geräte da ... rpc läuft.
Supi ... danke zap!!!
Kannst Du noch mal schaun ins Logfiles ob wiklich alles ok ist?
ich habe doch ein neues Problem ...
Wenn ich Fhem neu starte
shutdown restart
dann will er all 5 sek. neu starten, also immer wieder neu
Wenn ich den PI neu starte ist alles ok
Machst du beim browser einen refresh? Falls ja, dann nach shutdown restart nicht refresh sondern "page zurück" drücken. Oder tab schliessen und im neuen tab auf fhem wieder zugreifen
Zitat von: klaso am 01 März 2017, 17:25:26
Machst du beim browser einen refresh? Falls ja, dann nach shutdown restart nicht refresh sondern "page zurück" drücken. Oder tab schliessen und im neuen tab auf fhem wieder zugreifen
nein ... mach kein browser refresh
gebe nur shutdown restart ein und oben steht dann immer wieder das er neu starte 5 sek
Stelle die Frage bitte mal im allgemeinen Forum. Das hat nichts mit HMCCU zu tun.
Zitat von: Mundus am 01 März 2017, 14:14:49
Einen Unterschied in den LOGs erkenne ich nicht wirklich. Insgesamt scheint der Befehl seltsam verarbeitet zu werden (egal ob CCU2 oder FHEM).
Die Antwort von eQ-3 auf meine Anfrage war auch nicht zielführend:
Daher versuche ich mal einen Fachpartner... Zur Zeit vermute ich, dass die Befehlssyntax bei dem HM-IP Gerät anders lautet, nur wie, da habe ich keine Ahnung... [0/1|false/true] sind es scheinbar nicht. Kann ich ermitteln, was die CCU2 an das HMIP Thermostat sendet?
Gruß
Mundus
Leider ist mir keine Möglichkeit bekannt, wie man da etwas tracen kann. Bei HM-IP schon gar nicht, da das verschlüsselt ist. Hier ist übrigens die Doku zu den IP-Devices:
http://www.eq-3.com/Downloads/eq3/download%20bereich/hm_web_ui_doku/HmIP_DeviceDocumentation.pdf
Da sind sogar die Config-Parameter (u.a. GLOBAL_BUTTON_LOCK) beschrieben. Liegt bei Deinem Thermostat in Kanal 0, ist RW und vom Typ BOOL. Also nichts neues.
Ein Unterschied zum alten Protokoll ist natürlich theoretisch denkbar. Ich schau mir mal die RPC Doku nochmal an. Ein Zitat aus dieser Doku:
"* die Parameterwerte entsprechen nicht komplett der alten Spezifikation (z.B. Flags werden nicht unterstützt oder bestimmte Werteausprägungen sind geändert worden)"
Was konkret geändert wurde, steht da natürlich nicht. >:(
(!) Aber mal ne blöde Frage: wenn Du ein "get deviceinfo" ausführst, enthält die Ausgabe dann vielleicht einen Datenpunkt "GLOBAL_BUTTON_LOCK"?
UPDATE: Ich habe gerade die Version 3.9.005 von HMCCU eingecheckt. Sollte morgen per update verteilt werden.
Wenn Du die morgen installiert hast, setze bitte bei dem Thermostatdevice das Attribut ccuflags auf trace. Danach den set config Befehl nochmal ausführen und sehen, was im Logfile ausgegeben wird. Verbose muss mindestens 2 sein.
Blöde Frage vielleicht, aber kann ich auch zwei neue Readings erstellen lassen?
Sprich HMCCU erzeugt mir derzeit im ccudef-readingname der CCU2 u.a.
^(.+\.)?ACTUAL_TEMPERATURE$:measured-temp;
Nun bräuchte ich den Wert aus ACTUAL_TEMPERATURE aber auch noch im Reading temperature (wegen Homekit).
Geht das oder habe ich einen Denkfehler? (ja, ich kann im Homebridge-Mapping natürlich measured-temp auf temperature mappen)
Zitat von: kjmEjfu am 01 März 2017, 18:39:08
Blöde Frage vielleicht, aber kann ich auch zwei neue Readings erstellen lassen?
Sprich HMCCU erzeugt mir derzeit im ccudef-readingname der CCU2 u.a.
^(.+\.)?ACTUAL_TEMPERATURE$:measured-temp;
Nun bräuchte ich den Wert aus ACTUAL_TEMPERATURE aber auch noch im Reading temperature (wegen Homekit).
Geht das oder habe ich einen Denkfehler? (ja, ich kann im Homebridge-Mapping natürlich measured-temp auf temperature mappen)
Das geht:
^(.+\.)?ACTUAL_TEMPERATURE$:+measured-temp;^(.+\.)?ACTUAL_TEMPERATURE$:temperature;Das '+' ist hier entscheidend und bedeutet: ersetze ACTUAL_TEMPERATURE nicht durch measured-temp, sondern füge ein neues Reading hinzu. Bei der 2. Regel wird dann ACTUAL_TEMPERATURE tatsächlich durch temperature ersetzt, weil hier das '+' fehlt. Wenn Du hier auch ein '+' einsetzt, hast Du am Ende sogar 3 Readings: ACTUAL_TEMPERATURE, measured-temp und temperature.
Zitat von: zap am 01 März 2017, 17:46:32
Stelle die Frage bitte mal im allgemeinen Forum. Das hat nichts mit HMCCU zu tun.
hab es ja hier nur hier rein geschrieben, weill es erst nach der Einbindung von
/etc/systemd/system/fhem.service
der Fehler kommt.
Beim PI start weden die HM Geräte jetzt erkannt.
Nur wenn ich Fhem neu starte ... sartet Fhem jede 5 sec neu
Also das Problem mit rpc server ist vorbei ... das mit Fhem ist neu
Zitathab es ja hier nur hier rein geschrieben, weill es erst nach der Einbindung von
/etc/systemd/system/fhem.service
der Fehler kommt.
Ich würde denken, das der systremd dafür verantwortlich ist ... aber das möchte ich nicht in diesem Thread diskutieren
Zitat von: Wernieman am 02 März 2017, 08:07:28
Ich würde denken, das der systremd dafür verantwortlich ist ... aber das möchte ich nicht in diesem Thread diskutieren
Ja ich auch (bezieht sich auf beide Teile Deiner Aussage).
Nur soviel: Der Effekt tritt bei mir auch auf. Habe es nur nicht bemerkt, da ich nach einem Update sowieso nie "shutdown restart" benutze sondern unter Linux:
1. systemctl stop fhem
Dann prüfen ob noch was läuft (geforkte Prozesse, z.B. SONOS oder HMCCU):
2. ps -ef | grep fhem.pl
3. systemctl start fhem
Zitat von: zap am 01 März 2017, 17:49:48
(!) Aber mal ne blöde Frage: wenn Du ein "get deviceinfo" ausführst, enthält die Ausgabe dann vielleicht einen Datenpunkt "GLOBAL_BUTTON_LOCK"?
get FlurThermostat deviceinfogibt nachfolgende Ausgabe
CHN 000397098A3254:0 HMIP-FlurThermostat:0
DPT {b} HmIP-RF.000397098A3254:0.CONFIG_PENDING = true [RE]
DPT {b} HmIP-RF.000397098A3254:0.DUTY_CYCLE = false [RE]
DPT {b} HmIP-RF.000397098A3254:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.000397098A3254:0.OPERATING_VOLTAGE = 2.900000 [RE]
DPT {n} HmIP-RF.000397098A3254:0.RSSI_DEVICE = 221 [RE]
DPT {n} HmIP-RF.000397098A3254:0.RSSI_PEER = 220 [RE]
DPT {b} HmIP-RF.000397098A3254:0.UNREACH = false [RE]
DPT {b} HmIP-RF.000397098A3254:0.UPDATE_PENDING = false [RE]
CHN 000397098A3254:1 HMIP-FlurThermostat:1
DPT {i} HmIP-RF.000397098A3254:1.ACTIVE_PROFILE = 1 [WE]
DPT {f} HmIP-RF.000397098A3254:1.ACTUAL_TEMPERATURE = 20.600000 [RE]
DPT {b} HmIP-RF.000397098A3254:1.BOOST_MODE = false [WE]
DPT {f} HmIP-RF.000397098A3254:1.CONTROL_DIFFERENTIAL_TEMP = [WE]
DPT {i} HmIP-RF.000397098A3254:1.CONTROL_MODE = [WE]
DPT {i} HmIP-RF.000397098A3254:1.DURATION_UNIT = [W]
DPT {i} HmIP-RF.000397098A3254:1.DURATION_VALUE = [W]
DPT {b} HmIP-RF.000397098A3254:1.FROST_PROTECTION = false [RE]
DPT {f} HmIP-RF.000397098A3254:1.LEVEL = 1.000000 [RWE]
DPT {b} HmIP-RF.000397098A3254:1.PARTY_MODE = false [RE]
DPT {f} HmIP-RF.000397098A3254:1.PARTY_SET_POINT_TEMPERATU = 0.000000 [RE]
DPT {s} HmIP-RF.000397098A3254:1.PARTY_TIME_END = [RWE]
DPT {s} HmIP-RF.000397098A3254:1.PARTY_TIME_START = [RWE]
DPT {i} HmIP-RF.000397098A3254:1.SET_POINT_MODE = 0 [RWE]
DPT {f} HmIP-RF.000397098A3254:1.SET_POINT_TEMPERATURE = 21.000000 [RWE]
DPT {b} HmIP-RF.000397098A3254:1.SWITCH_POINT_OCCURED = false [RE]
DPT {b} HmIP-RF.000397098A3254:1.VALVE_ADAPTION = [WE]
DPT {i} HmIP-RF.000397098A3254:1.VALVE_STATE = 4 [RE]
DPT {i} HmIP-RF.000397098A3254:1.WINDOW_STATE = 0 [WE]
Ein Datenpunkt GLOBAL_BUTTON_LOCK ist nicht dabei... Ich habe den Befehl auch für das alte Thermostat ausprobiert und auch dort taucht GLOBAL_BUTTON_LOCK nicht auf.
Zitat von: zap am 01 März 2017, 17:49:48
UPDATE: Ich habe gerade die Version 3.9.005 von HMCCU eingecheckt. Sollte morgen per update verteilt werden.
Wenn Du die morgen installiert hast, setze bitte bei dem Thermostatdevice das Attribut ccuflags auf trace. Danach den set config Befehl nochmal ausführen und sehen, was im Logfile ausgegeben wird. Verbose muss mindestens 2 sein.
Grundsätzlich ist global verbose =5, sodass ich verbose für das Thermostat nicht angepasst habe. Das LOG hat sich nicht geändert
2017.03.03 22:52:37 4 : WEB_192.168.130.8_52078 POST /fhem&detail=FlurThermostat&fwcsrf=fhem_222963384671245&dev.setFlurThermostat=FlurThermostat&cmd.setFlurThermostat=set&arg.setFlurThermostat=config&val.setFlurThermostat=0+GLOBAL_BUTTON_LOCK%3D1; BUFLEN:0
2017.03.03 22:52:37 5 : Cmd: >set FlurThermostat config 0 GLOBAL_BUTTON_LOCK=1<
2017.03.03 22:52:37 1 : HMCCU: Invalid parameter or value
2017.03.03 22:52:37 1 : HMCCUDEV: FlurThermostat Execution of CCU script or command failed
2017.03.03 22:52:37 4 : name: /fhem&detail=FlurThermostat&fwcsrf=fhem_222963384671245&dev.setFlurThermostat=FlurThermostat&cmd.setFlurThermostat=set&arg.setFlurThermostat=config&val.setFlurThermostat=0+GLOBAL_BUTTON_LOCK%3D1 / RL:1474 / text/html; charset=UTF-8 / Content-Encoding: gzip /
2017.03.03 22:52:37 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.03 22:52:37 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=CONFIG_PENDING, value=1
2017.03.03 22:52:37 2 : HMCCU: rm=0, r=(PARTY), dpt=CONFIG_PENDING
2017.03.03 22:52:37 2 : HMCCU: Check 0 = 1 AND CONFIG_PENDING = (PARTY) OR 0 = 0 AND CONFIG_PENDING = (PARTY)
2017.03.03 22:52:37 2 : HMCCU: Check negative
2017.03.03 22:52:37 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.03 22:52:37 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=0.CONFIG_PENDING, orgvalue=1 value=1
2017.03.03 22:52:37 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.03 22:52:37 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.03 22:52:37 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.03 22:52:37 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.CONFIG_PENDING: 1
2017.03.03 22:52:37 5 : createNotifyHash
2017.03.03 22:52:38 5 : testBattStatus: not on any display, ignoring notify
2017-03-03 22:52:38 HMCCUDEV FlurThermostat 0.CONFIG_PENDING: 1
2017-03-03 22:52:38 HMCCUDEV FlurThermostat hmstate: 17.0
2017-03-03 22:52:38 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.03 22:52:38 5 : End notify loop for FlurThermostat Im übrigen bleibt auch alles andere identisch
LOG aus messages:
Mar 3 22:53:50 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
Mar 3 22:53:50 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]Für mich die Verständnisfrage, das Attribut ccuflags=trace sollte doch lediglich das LOG verändern, oder?
Das Tracing ist aktiv (sehe ich an den Details bei der Log Ausgabe). Allerdings ist das nicht die korrekte Version von 88_HMCCU.pm. Sonst müsste die Ausgabe etwas anders aussehen. Kannst Du bitte nochmal updaten und FHEM neu starten?
Du könntest auch mal versuchen, irgendeinen anderen Config Parameter zu setzen. Möglichst einen, der einen nummerischen Wert erfordert. Bei Bool Werten weiß man nie so genau, ob jetzt false/true oder 0/1 erforderloch ist.
Dann kann man das Problem ggf. auf GLOBAL_LOCK eingrenzen.
So, habe den Parameter ARR_TIMEOUT auf 12 gesetzt.
set FlurThermostat config 0 ARR_TIMEOUT=12
Das dazugehörige LOG aus FHEM sieht wie folgt aus:
2017.03.05 17:59:09 4 : Connection closed for WEB_192.168.130.8_53632: EOF
2017.03.05 17:59:09 4 : Connection accepted from WEB_192.168.130.8_53882
2017.03.05 17:59:09 4 : WEB_192.168.130.8_53882 POST /fhem&detail=FlurThermostat&fwcsrf=fhem_222963384671245&dev.setFlurThermostat=FlurThermostat&cmd.setFlurThermostat=set&arg.setFlurThermostat=config&val.setFlurThermostat=0+ARR_TIMEOUT%3D12; BUFLEN:0
2017.03.05 17:59:09 5 : Cmd: >set FlurThermostat config 0 ARR_TIMEOUT=12<
2017.03.05 17:59:12 5 : Starting notify loop for FlurThermostat, 1 event(s), first is config 0 ARR_TIMEOUT=12
2017.03.05 17:59:12 5 : createNotifyHash
2017.03.05 17:59:13 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:13 HMCCUDEV FlurThermostat config 0 ARR_TIMEOUT=12
2017.03.05 17:59:13 5 : End notify loop for FlurThermostat
2017.03.05 17:59:13 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:13 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=CONFIG_PENDING, value=1
2017.03.05 17:59:13 2 : HMCCU: rm=0, r=(PARTY), dpt=CONFIG_PENDING
2017.03.05 17:59:13 2 : HMCCU: Check 0 = 1 AND CONFIG_PENDING = (PARTY) OR 0 = 0 AND CONFIG_PENDING = (PARTY)
2017.03.05 17:59:13 2 : HMCCU: Check negative
2017.03.05 17:59:13 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:13 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=0.CONFIG_PENDING, orgvalue=1 value=1
2017.03.05 17:59:13 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:13 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:13 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:13 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.CONFIG_PENDING: 1
2017.03.05 17:59:13 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:13 HMCCUDEV FlurThermostat 0.CONFIG_PENDING: 1
2017-03-05 17:59:13 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:13 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:13 5 : End notify loop for FlurThermostat
2017.03.05 17:59:13 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:13 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=RSSI_DEVICE, value=-37
2017.03.05 17:59:13 2 : HMCCU: rm=0, r=(PARTY), dpt=RSSI_DEVICE
2017.03.05 17:59:13 2 : HMCCU: Check 0 = 1 AND RSSI_DEVICE = (PARTY) OR 0 = 0 AND RSSI_DEVICE = (PARTY)
2017.03.05 17:59:13 2 : HMCCU: Check negative
2017.03.05 17:59:13 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:13 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=0.RSSI_DEVICE, orgvalue=-37 value=-37
2017.03.05 17:59:13 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:13 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:13 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:13 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.RSSI_DEVICE: -37
2017.03.05 17:59:13 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:13 HMCCUDEV FlurThermostat 0.RSSI_DEVICE: -37
2017-03-05 17:59:13 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:13 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:13 5 : End notify loop for FlurThermostat
2017.03.05 17:59:13 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:13 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=UNREACH, value=0
2017.03.05 17:59:13 2 : HMCCU: rm=0, r=(PARTY), dpt=UNREACH
2017.03.05 17:59:13 2 : HMCCU: Check 0 = 1 AND UNREACH = (PARTY) OR 0 = 0 AND UNREACH = (PARTY)
2017.03.05 17:59:13 2 : HMCCU: Check negative
2017.03.05 17:59:13 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:13 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=0.UNREACH, orgvalue=0 value=0
2017.03.05 17:59:13 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:13 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:13 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:13 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.UNREACH: 0
2017.03.05 17:59:13 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:13 HMCCUDEV FlurThermostat 0.UNREACH: 0
2017-03-05 17:59:13 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:13 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:13 5 : End notify loop for FlurThermostat
2017.03.05 17:59:13 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:13 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=RSSI_DEVICE, value=-37
2017.03.05 17:59:13 2 : HMCCU: rm=0, r=(PARTY), dpt=RSSI_DEVICE
2017.03.05 17:59:13 2 : HMCCU: Check 0 = 1 AND RSSI_DEVICE = (PARTY) OR 0 = 0 AND RSSI_DEVICE = (PARTY)
2017.03.05 17:59:13 2 : HMCCU: Check negative
2017.03.05 17:59:13 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:13 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=0.RSSI_DEVICE, orgvalue=-37 value=-37
2017.03.05 17:59:13 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:13 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:13 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:13 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.RSSI_DEVICE: -37
2017.03.05 17:59:13 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:13 HMCCUDEV FlurThermostat 0.RSSI_DEVICE: -37
2017-03-05 17:59:13 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:13 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:13 5 : End notify loop for FlurThermostat
2017.03.05 17:59:13 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:13 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=UNREACH, value=0
2017.03.05 17:59:13 2 : HMCCU: rm=0, r=(PARTY), dpt=UNREACH
2017.03.05 17:59:13 2 : HMCCU: Check 0 = 1 AND UNREACH = (PARTY) OR 0 = 0 AND UNREACH = (PARTY)
2017.03.05 17:59:13 2 : HMCCU: Check negative
2017.03.05 17:59:13 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:13 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=0.UNREACH, orgvalue=0 value=0
2017.03.05 17:59:13 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:13 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:14 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:14 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.UNREACH: 0
2017.03.05 17:59:14 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:14 HMCCUDEV FlurThermostat 0.UNREACH: 0
2017-03-05 17:59:14 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:14 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:14 5 : End notify loop for FlurThermostat
2017.03.05 17:59:14 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:14 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=RSSI_DEVICE, value=-37
2017.03.05 17:59:14 2 : HMCCU: rm=0, r=(PARTY), dpt=RSSI_DEVICE
2017.03.05 17:59:14 2 : HMCCU: Check 0 = 1 AND RSSI_DEVICE = (PARTY) OR 0 = 0 AND RSSI_DEVICE = (PARTY)
2017.03.05 17:59:14 2 : HMCCU: Check negative
2017.03.05 17:59:14 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:14 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=0.RSSI_DEVICE, orgvalue=-37 value=-37
2017.03.05 17:59:14 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:14 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:14 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:14 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.RSSI_DEVICE: -37
2017.03.05 17:59:14 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:14 HMCCUDEV FlurThermostat 0.RSSI_DEVICE: -37
2017-03-05 17:59:14 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:14 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:14 5 : End notify loop for FlurThermostat
2017.03.05 17:59:14 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:14 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=UNREACH, value=0
2017.03.05 17:59:14 2 : HMCCU: rm=0, r=(PARTY), dpt=UNREACH
2017.03.05 17:59:14 2 : HMCCU: Check 0 = 1 AND UNREACH = (PARTY) OR 0 = 0 AND UNREACH = (PARTY)
2017.03.05 17:59:14 2 : HMCCU: Check negative
2017.03.05 17:59:14 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:14 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=0.UNREACH, orgvalue=0 value=0
2017.03.05 17:59:14 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:14 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:14 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:14 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.UNREACH: 0
2017.03.05 17:59:14 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:14 HMCCUDEV FlurThermostat 0.UNREACH: 0
2017-03-05 17:59:14 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:14 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:14 5 : End notify loop for FlurThermostat
2017.03.05 17:59:14 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:14 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=CONFIG_PENDING, value=0
2017.03.05 17:59:14 2 : HMCCU: rm=0, r=(PARTY), dpt=CONFIG_PENDING
2017.03.05 17:59:14 2 : HMCCU: Check 0 = 1 AND CONFIG_PENDING = (PARTY) OR 0 = 0 AND CONFIG_PENDING = (PARTY)
2017.03.05 17:59:14 2 : HMCCU: Check negative
2017.03.05 17:59:14 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:14 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=0.CONFIG_PENDING, orgvalue=0 value=0
2017.03.05 17:59:14 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:14 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:14 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:14 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.CONFIG_PENDING: 0
2017.03.05 17:59:14 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:14 HMCCUDEV FlurThermostat 0.CONFIG_PENDING: 0
2017-03-05 17:59:14 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:14 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:15 5 : End notify loop for FlurThermostat
2017.03.05 17:59:15 4 : WEB_192.168.130.8_53882 GET /fhem?detail=FlurThermostat&fw_id=; BUFLEN:0
2017.03.05 17:59:15 4 : name: /fhem?detail=FlurThermostat&fw_id= / RL:13138 / text/html; charset=UTF-8 / Content-Encoding: gzip /
2017.03.05 17:59:16 4 : WEB_192.168.130.8_53882 GET /fhem?cmd={ReadingsVal(%22FlurThermostat%22,%22control%22,%22%22)}&XHR=1&fwcsrf=fhem_222963384671245; BUFLEN:0
2017.03.05 17:59:16 5 : Cmd: >{ReadingsVal("FlurThermostat","control","")}<
2017.03.05 17:59:16 4 : name: /fhem?cmd={ReadingsVal(%22FlurThermostat%22,%22control%22,%22%22)}&XHR=1&fwcsrf=fhem_222963384671245 / RL:25 / text/plain; charset=UTF-8 / Content-Encoding: gzip /
2017.03.05 17:59:16 4 : Connection accepted from WEB_192.168.130.8_53886
2017.03.05 17:59:16 4 : WEB_192.168.130.8_53886 GET /fhem?cmd={AttrVal(%22FlurThermostat%22,%22room%22,%22%22)}&XHR=1&fwcsrf=fhem_222963384671245; BUFLEN:0
2017.03.05 17:59:16 5 : Cmd: >{AttrVal("FlurThermostat","room","")}<
2017.03.05 17:59:16 4 : name: /fhem?cmd={AttrVal(%22FlurThermostat%22,%22room%22,%22%22)}&XHR=1&fwcsrf=fhem_222963384671245 / RL:40 / text/plain; charset=UTF-8 / Content-Encoding: gzip /
2017.03.05 17:59:16 4 : Connection accepted from WEB_192.168.130.8_53888
2017.03.05 17:59:16 4 : WEB_192.168.130.8_53888 GET /fhem?XHR=1&inform=type=status;filter=FlurThermostat;since=1488733154;fmt=JSON&fw_id=483×tamp=1488733155972; BUFLEN:0
2017.03.05 17:59:30 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:30 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=RSSI_DEVICE, value=-37
2017.03.05 17:59:30 2 : HMCCU: rm=0, r=(PARTY), dpt=RSSI_DEVICE
2017.03.05 17:59:30 2 : HMCCU: Check 0 = 1 AND RSSI_DEVICE = (PARTY) OR 0 = 0 AND RSSI_DEVICE = (PARTY)
2017.03.05 17:59:30 2 : HMCCU: Check negative
2017.03.05 17:59:30 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:30 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=0.RSSI_DEVICE, orgvalue=-37 value=-37
2017.03.05 17:59:30 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:30 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:30 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:30 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.RSSI_DEVICE: -37
2017.03.05 17:59:30 5 : createNotifyHash
2017.03.05 17:59:30 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:30 HMCCUDEV FlurThermostat 0.RSSI_DEVICE: -37
2017-03-05 17:59:30 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:30 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:30 5 : End notify loop for FlurThermostat
2017.03.05 17:59:30 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:30 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=DUTY_CYCLE, value=0
2017.03.05 17:59:30 2 : HMCCU: rm=0, r=(PARTY), dpt=DUTY_CYCLE
2017.03.05 17:59:30 2 : HMCCU: Check 0 = 1 AND DUTY_CYCLE = (PARTY) OR 0 = 0 AND DUTY_CYCLE = (PARTY)
2017.03.05 17:59:30 2 : HMCCU: Check negative
2017.03.05 17:59:30 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:30 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=0.DUTY_CYCLE, orgvalue=0 value=0
2017.03.05 17:59:30 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:30 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:30 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:30 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.DUTY_CYCLE: 0
2017.03.05 17:59:30 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:30 HMCCUDEV FlurThermostat 0.DUTY_CYCLE: 0
2017-03-05 17:59:30 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:30 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:30 5 : End notify loop for FlurThermostat
2017.03.05 17:59:30 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:30 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=LOW_BAT, value=0
2017.03.05 17:59:30 2 : HMCCU: rm=0, r=(PARTY), dpt=LOW_BAT
2017.03.05 17:59:30 2 : HMCCU: Check 0 = 1 AND LOW_BAT = (PARTY) OR 0 = 0 AND LOW_BAT = (PARTY)
2017.03.05 17:59:30 2 : HMCCU: Check negative
2017.03.05 17:59:30 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:30 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=0.LOW_BAT, orgvalue=0 value=0
2017.03.05 17:59:30 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:30 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:30 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:30 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.LOW_BAT: 0
2017.03.05 17:59:30 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:30 HMCCUDEV FlurThermostat 0.LOW_BAT: 0
2017-03-05 17:59:30 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:30 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:30 5 : End notify loop for FlurThermostat
2017.03.05 17:59:30 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:30 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=UNREACH, value=0
2017.03.05 17:59:30 2 : HMCCU: rm=0, r=(PARTY), dpt=UNREACH
2017.03.05 17:59:30 2 : HMCCU: Check 0 = 1 AND UNREACH = (PARTY) OR 0 = 0 AND UNREACH = (PARTY)
2017.03.05 17:59:30 2 : HMCCU: Check negative
2017.03.05 17:59:30 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:30 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=0.UNREACH, orgvalue=0 value=0
2017.03.05 17:59:30 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:30 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:30 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:31 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.UNREACH: 0
2017.03.05 17:59:31 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:31 HMCCUDEV FlurThermostat 0.UNREACH: 0
2017-03-05 17:59:31 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:31 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:31 5 : End notify loop for FlurThermostat
2017.03.05 17:59:31 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:31 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=OPERATING_VOLTAGE, value=2.9
2017.03.05 17:59:31 2 : HMCCU: rm=0, r=(PARTY), dpt=OPERATING_VOLTAGE
2017.03.05 17:59:31 2 : HMCCU: Check 0 = 1 AND OPERATING_VOLTAGE = (PARTY) OR 0 = 0 AND OPERATING_VOLTAGE = (PARTY)
2017.03.05 17:59:31 2 : HMCCU: Check negative
2017.03.05 17:59:31 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:31 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=Battery, orgvalue=2.9 value=2.9
2017.03.05 17:59:31 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:31 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:31 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:31 5 : Starting notify loop for FlurThermostat, 3 event(s), first is Battery: 2.9
2017.03.05 17:59:31 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:31 HMCCUDEV FlurThermostat Battery: 2.9
2017-03-05 17:59:31 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:31 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:31 5 : End notify loop for FlurThermostat
2017.03.05 17:59:31 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:31 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:1, dpt=PARTY_MODE, value=0
2017.03.05 17:59:31 2 : HMCCU: rm=0, r=(PARTY), dpt=PARTY_MODE
2017.03.05 17:59:31 2 : HMCCU: Check 0 = 1 AND PARTY_MODE = (PARTY) OR 0 = 0 AND PARTY_MODE = (PARTY)
2017.03.05 17:59:31 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:31 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:31 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:31 5 : Starting notify loop for FlurThermostat, 2 event(s), first is hmstate: 21.0
2017.03.05 17:59:31 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:31 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:31 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:31 5 : End notify loop for FlurThermostat
2017.03.05 17:59:31 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:31 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:1, dpt=VALVE_STATE, value=4
2017.03.05 17:59:31 2 : HMCCU: rm=0, r=(PARTY), dpt=VALVE_STATE
2017.03.05 17:59:31 2 : HMCCU: Check 0 = 1 AND VALVE_STATE = (PARTY) OR 0 = 0 AND VALVE_STATE = (PARTY)
2017.03.05 17:59:31 2 : HMCCU: Check negative
2017.03.05 17:59:31 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:31 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=1.VALVE_STATE, orgvalue=4 value=4
2017.03.05 17:59:31 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:31 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:31 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:31 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.VALVE_STATE: 4
2017.03.05 17:59:31 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:31 HMCCUDEV FlurThermostat 1.VALVE_STATE: 4
2017-03-05 17:59:31 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:31 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:31 5 : End notify loop for FlurThermostat
2017.03.05 17:59:31 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:31 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:1, dpt=ACTUAL_TEMPERATURE, value=21.1
2017.03.05 17:59:31 2 : HMCCU: rm=0, r=(PARTY), dpt=ACTUAL_TEMPERATURE
2017.03.05 17:59:31 2 : HMCCU: Check 0 = 1 AND ACTUAL_TEMPERATURE = (PARTY) OR 0 = 0 AND ACTUAL_TEMPERATURE = (PARTY)
2017.03.05 17:59:31 2 : HMCCU: Check negative
2017.03.05 17:59:31 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:31 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=1.ACTUAL_TEMPERATURE, orgvalue=21.1 value=21.1
2017.03.05 17:59:31 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:31 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:32 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:32 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.ACTUAL_TEMPERATURE: 21.1
2017.03.05 17:59:32 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:32 HMCCUDEV FlurThermostat 1.ACTUAL_TEMPERATURE: 21.1
2017-03-05 17:59:32 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:32 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:32 5 : End notify loop for FlurThermostat
2017.03.05 17:59:32 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:32 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:1, dpt=SWITCH_POINT_OCCURED, value=0
2017.03.05 17:59:32 2 : HMCCU: rm=0, r=(PARTY), dpt=SWITCH_POINT_OCCURED
2017.03.05 17:59:32 2 : HMCCU: Check 0 = 1 AND SWITCH_POINT_OCCURED = (PARTY) OR 0 = 0 AND SWITCH_POINT_OCCURED = (PARTY)
2017.03.05 17:59:32 2 : HMCCU: Check negative
2017.03.05 17:59:32 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:32 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=1.SWITCH_POINT_OCCURED, orgvalue=0 value=0
2017.03.05 17:59:32 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:32 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:32 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:32 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.SWITCH_POINT_OCCURED: 0
2017.03.05 17:59:32 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:32 HMCCUDEV FlurThermostat 1.SWITCH_POINT_OCCURED: 0
2017-03-05 17:59:32 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:32 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:32 5 : End notify loop for FlurThermostat
2017.03.05 17:59:32 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:32 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:1, dpt=BOOST_MODE, value=0
2017.03.05 17:59:32 2 : HMCCU: rm=0, r=(PARTY), dpt=BOOST_MODE
2017.03.05 17:59:32 2 : HMCCU: Check 0 = 1 AND BOOST_MODE = (PARTY) OR 0 = 0 AND BOOST_MODE = (PARTY)
2017.03.05 17:59:32 2 : HMCCU: Check negative
2017.03.05 17:59:32 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:32 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=1.BOOST_MODE, orgvalue=0 value=0
2017.03.05 17:59:32 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:32 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:32 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:32 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.BOOST_MODE: 0
2017.03.05 17:59:32 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:32 HMCCUDEV FlurThermostat 1.BOOST_MODE: 0
2017-03-05 17:59:32 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:32 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:32 5 : End notify loop for FlurThermostat
2017.03.05 17:59:32 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:32 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:1, dpt=FROST_PROTECTION, value=0
2017.03.05 17:59:32 2 : HMCCU: rm=0, r=(PARTY), dpt=FROST_PROTECTION
2017.03.05 17:59:32 2 : HMCCU: Check 0 = 1 AND FROST_PROTECTION = (PARTY) OR 0 = 0 AND FROST_PROTECTION = (PARTY)
2017.03.05 17:59:32 2 : HMCCU: Check negative
2017.03.05 17:59:32 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:32 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=1.FROST_PROTECTION, orgvalue=0 value=0
2017.03.05 17:59:32 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:32 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:32 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:32 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.FROST_PROTECTION: 0
2017.03.05 17:59:32 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:32 HMCCUDEV FlurThermostat 1.FROST_PROTECTION: 0
2017-03-05 17:59:32 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:32 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:32 5 : End notify loop for FlurThermostat
2017.03.05 17:59:32 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:32 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:1, dpt=SET_POINT_MODE, value=0
2017.03.05 17:59:32 2 : HMCCU: rm=0, r=(PARTY), dpt=SET_POINT_MODE
2017.03.05 17:59:32 2 : HMCCU: Check 0 = 1 AND SET_POINT_MODE = (PARTY) OR 0 = 0 AND SET_POINT_MODE = (PARTY)
2017.03.05 17:59:32 2 : HMCCU: Check negative
2017.03.05 17:59:32 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:32 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=1.SET_POINT_MODE, orgvalue=0 value=Auto
2017.03.05 17:59:32 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:32 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:33 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:33 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.SET_POINT_MODE: Auto
2017.03.05 17:59:33 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:33 HMCCUDEV FlurThermostat 1.SET_POINT_MODE: Auto
2017-03-05 17:59:33 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:33 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:33 5 : End notify loop for FlurThermostat
2017.03.05 17:59:33 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:33 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:1, dpt=SET_POINT_TEMPERATURE, value=21.0
2017.03.05 17:59:33 2 : HMCCU: rm=0, r=(PARTY), dpt=SET_POINT_TEMPERATURE
2017.03.05 17:59:33 2 : HMCCU: Check 0 = 1 AND SET_POINT_TEMPERATURE = (PARTY) OR 0 = 0 AND SET_POINT_TEMPERATURE = (PARTY)
2017.03.05 17:59:33 2 : HMCCU: Check negative
2017.03.05 17:59:33 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:33 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=1.SET_POINT_TEMPERATURE, orgvalue=21.0 value=21.0
2017.03.05 17:59:33 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:33 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:33 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:33 5 : Starting notify loop for FlurThermostat, 5 event(s), first is 1.SET_POINT_TEMPERATURE: 21.0
2017.03.05 17:59:33 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:33 HMCCUDEV FlurThermostat 1.SET_POINT_TEMPERATURE: 21.0
2017-03-05 17:59:33 HMCCUDEV FlurThermostat control: 21.0
2017-03-05 17:59:33 HMCCUDEV FlurThermostat 21.0
2017-03-05 17:59:33 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:33 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:33 5 : End notify loop for FlurThermostat
2017.03.05 17:59:33 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:33 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:1, dpt=LEVEL, value=0.81
2017.03.05 17:59:33 2 : HMCCU: rm=0, r=(PARTY), dpt=LEVEL
2017.03.05 17:59:33 2 : HMCCU: Check 0 = 1 AND LEVEL = (PARTY) OR 0 = 0 AND LEVEL = (PARTY)
2017.03.05 17:59:33 2 : HMCCU: Check negative
2017.03.05 17:59:33 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:33 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=valve_position, orgvalue=0.81 value=81
2017.03.05 17:59:33 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:33 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:33 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:33 5 : Starting notify loop for FlurThermostat, 3 event(s), first is valve_position: 81
2017.03.05 17:59:33 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:33 HMCCUDEV FlurThermostat valve_position: 81
2017-03-05 17:59:33 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:33 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:33 5 : End notify loop for FlurThermostat
2017.03.05 17:59:33 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:33 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:1, dpt=ACTIVE_PROFILE, value=1
2017.03.05 17:59:33 2 : HMCCU: rm=0, r=(PARTY), dpt=ACTIVE_PROFILE
2017.03.05 17:59:33 2 : HMCCU: Check 0 = 1 AND ACTIVE_PROFILE = (PARTY) OR 0 = 0 AND ACTIVE_PROFILE = (PARTY)
2017.03.05 17:59:33 2 : HMCCU: Check negative
2017.03.05 17:59:33 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:33 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=1.ACTIVE_PROFILE, orgvalue=1 value=1
2017.03.05 17:59:33 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:33 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:33 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:33 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.ACTIVE_PROFILE: 1
2017.03.05 17:59:33 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:33 HMCCUDEV FlurThermostat 1.ACTIVE_PROFILE: 1
2017-03-05 17:59:33 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:33 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:33 5 : End notify loop for FlurThermostat
2017.03.05 17:59:33 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:33 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:1, dpt=WINDOW_STATE, value=0
2017.03.05 17:59:33 2 : HMCCU: rm=0, r=(PARTY), dpt=WINDOW_STATE
2017.03.05 17:59:33 2 : HMCCU: Check 0 = 1 AND WINDOW_STATE = (PARTY) OR 0 = 0 AND WINDOW_STATE = (PARTY)
2017.03.05 17:59:33 2 : HMCCU: Check negative
2017.03.05 17:59:33 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.05 17:59:33 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=1.WINDOW_STATE, orgvalue=0 value=closed
2017.03.05 17:59:33 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.05 17:59:33 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.05 17:59:34 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:34 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 1.WINDOW_STATE: closed
2017.03.05 17:59:34 5 : testBattStatus: not on any display, ignoring notify
2017-03-05 17:59:34 HMCCUDEV FlurThermostat 1.WINDOW_STATE: closed
2017-03-05 17:59:34 HMCCUDEV FlurThermostat hmstate: 21.0
2017-03-05 17:59:34 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.05 17:59:34 5 : End notify loop for FlurThermostat
Die Abfrage get FlurThermostat configlist 0 ergibt dann
ARR_TIMEOUT=12
CYCLIC_INFO_MSG=1
CYCLIC_INFO_MSG_DIS=20
CYCLIC_INFO_MSG_DIS_UNCHANGED=0
CYCLIC_INFO_MSG_OVERDUE_THRESHOLD=2
DAYLIGHT_SAVINGS_TIME=1
DST_END_DAY_OF_WEEK=0
DST_END_MONTH=10
DST_END_TIME=180
DST_END_WEEK_OF_MONTH=5
DST_START_DAY_OF_WEEK=0
DST_START_MONTH=3
DST_START_TIME=120
DST_START_WEEK_OF_MONTH=5
DUTYCYCLE_LIMIT=180
ENABLE_ROUTING=1
GLOBAL_BUTTON_LOCK=1
LOCAL_RESET_DISABLED=0
LOW_BAT_LIMIT=2.2
UTC_DST_OFFSET=120
UTC_OFFSET=60
Der Befehl wird also perfekt abgearbeitet;-). Analog sieht es bei dem Befehl "CYCLIC_INFO_MSG_DIS" aus, daher scheint es etwas mit dem LOCK zu tun zu haben, oder?
Achso, meine HMCCU-Version lautet:
88_HMCCU.pm 13569 2017-03-01 18:11:41Z zap
88_HMCCUDEV.pm 13300 2017-02-01 17:45:04Z zap
Ich befürchte, das ist ein Firmware Bug. Ich habe im Homematic Forum einige Hinweise gefunden, dass das in der Anfangszeit von HMIP nicht funktioniert hat. Nach 1 Jahr hätte ich aber gedacht, dass das behoben ist.
M.E. müsste es mit GLOBAL_BUTTON_LOCK=false funktionieren, da es so auch mit dem alten Thermostat bei mir geht.
Zitat von: zap am 05 März 2017, 21:17:52
Ich befürchte, das ist ein Firmware Bug. Ich habe im Homematic Forum einige Hinweise gefunden, dass das in der Anfangszeit von HMIP nicht funktioniert hat. Nach 1 Jahr hätte ich aber gedacht, dass das behoben ist.
Um so besser ist die Antwort von eq3
Zitat von: Mundus am 01 März 2017, 14:14:49
Die Antwort von eQ-3 auf meine Anfrage war auch nicht zielführend:
Zitathiermit möchten wir uns für das von Ihnen entgegengebrachte Interesse an unseren Produkten bedanken.
Bitte haben Sie Verständnis, dass der technische Support der eQ-3 AG in erster Linie auf die Beantwortung von technischen Detailfragen im Aftersales-Service zu unseren Produkten ausgerichtet ist.
Folgende Serviceleistungen und Themenbereiche bearbeiten wir daher nicht selbst.
- individuelle Programmerstellung
- Skriptprogrammierung
- Zusatzsoftware
- Expertenparameter
- Open Source Projekte
- OEM Bausätze
- Support auf Bauteilebene
- XML-RPC Schnittstelle
- Vorort-Service
- Fernwartung
- etc.
Viele dieser Leistungen können jedoch weitgehend über unsere geschulten Fachpartner und Fachhandwerker abgedeckt werden.
Das Netzwerk an qualifizierten Fachpartnern wird stetig erweitert.
Eine Übersicht der Bezugsquellen finden Sie hier:
http://www.eq-3.de/partner/bezugsquellen.html
Mit freundlichen Grüßen aus Leer
Ihr eQ-3 Support-Team
Hmm, dann endet das bestimmt in einem Ping-Pong zwischen Fachpartner und eq3. Kannst du mir den Link zu dem Artikel im Homematic-Forum schreiben, denn dann würde ich auch telefonisch bei eq3 mein Glück versuchen. Ich bin leider ziemlich ratlos...
Das war in dem Thread nach Veröffentlichung der HMIP fähigen CCU Firmware:
https://homematic-forum.de/forum/viewtopic.php?f=26&t=28259&start=230
Ich habe noch eine andere Möglichkeit gefunden, Config Parameter an ein Dev zu schicken. Das werde ich mal testen und nochmal auf Dich zukommen wenn es grundsätzlich funktioniert. Dann kannst du es mal mit dem problematischen Parameter testen.
@Mundus: Ich hätte da ein kleines Script für Dich. Speichere das bitte z.B. unter /opt/fhem/setpar.hsc ab:
var vReturn;
object oChn = channels.Get ("$channel");
if (oChn) {
vReturn = xmlrpc.PutParamset (oChn.Interface(), oChn.Address(), "MASTER", "$param", $value);
WriteLine ("scriptres=" # vReturn);
}
else {
WriteLine ("scriptres=Channel not found");
}
Danach kannst Du das Script ausführen. Angenommen, Dein HMCCU Device heißt "d_ccu", wird es so ausgeführt (bitte "Kanalname" durch den Namen von Kanal 0 von Flurthermostat ersetzen (findest Du in der CCU unter Einstellungen/Geräte):
set d_ccu hmscript /opt/fhem/setpar.hsc channel=Kanalname param=GLOBAL_BUTTON_LOCK value=true
Im Reading "scriptres" von d_ccu steht dann das Ergebnis der Ausführung.
Zitat von: zap am 06 März 2017, 17:01:16
@Mundus: Ich hätte da ein kleines Script für Dich.
Das Skript funktioniert, nunmehr arbeitet alles wie gewünscht? Kannst du mir erklären, was das Problem war und wie du auf die Lösung gekommen bist?
Hat es etwas mit dem Attribut "MASTER" zu tun?
Vielen Dank bis hierher, eine
großartige Unterstützung deinerseits!
Gruß
Mundus
Nein mit MASTER hat das nichts zu tun. Das Script spricht lediglich die RPC Schnittstelle über den Umweg HomeMatic Script an, während HMCCU direkte RPC Calls absetzt.
M.E. Müsste daher auch der normale Befehl funktionieren:
Set xxxx config 0 GLOBAL_BUTTON_LOCK=true
Ich habe mal testweise bei einer meiner HmIP Steckdosen einen Config Parameter gesetzt. teilweise wurde das sofort ausgeführt, teilweise nur verzögert. Dann gab es in der CCU die Servicemeldung, dass Daten zur Übertragung anstehen. Ausserdem ging das Reading UPDATE_PENDING der Steckdose auf true.
Zitat von: zap am 09 März 2017, 07:12:45
Müsste daher auch der normale Befehl funktionieren:
Set xxxx config 0 GLOBAL_BUTTON_LOCK=true
Leider ist dies nicht der Fall, sondern nur der Umweg über das Skript führt zu dem erwünschten Erfolg. Über den Aufruf set xxxx config tritt das von mir beschriebene Verhalten auf und der Befehl gelangt nie zum Thermostat.
Gruß
Mundus
mm, bei mir kam es auch bei Verwendung des Scripts ab und zu zum Status "Update Pending". Einmal wurden die Daten erst nach ca. 1 Stunde an die Steckdose geschickt.
Das tritt nur bei HMIP auf. Bei anderen Geräten kommt es zwar auch ab und zu zu einer Verzögerung (auch aus dem WebUI heraus). Aber da liegt das bei maximal 1 Minute. Kann mir auch nicht vorstellen, dass hier der Duty Cycle zuschlägt. Dann müsste es auch bei BidCos-RF auftreten, denn das Nutzt ja das gleiche Frequenzband.
Scheint also die Implementierung in der CCU zu sein. Ich bleibe weiter dran an dem Thema. Bis zu einer Lösung kannst Du Dir mit dem Script behelfen. Ist halt etwas umständlicher.
Hallo,
ich habe heute nach längerer Zeit mal wieder einen FHEM Update gemacht.
Dabei stelle ich beim Anschauen der Devices fest: Alle HMCCU Devices bleiben in einem Status "Activated" stecken. Vorher gingen die alle in einen Status "Initialized".
Im Logfile steht auch "PERL WARNING: Argument "Activated" isn't numeric in multiplication (*) at (eval 341) line 1."
Ich muss jedes Device durchklicken und einen "Get update" machen.
Vor dem Update hat der rpcserver einwandfrei den Status automatisch geholt und upgedated. :-(
Wie kann ich das beheben?
Ist das die einzige Fehlermeldung im Logfile? Mir scheint, dass das Reading state eines Deiner Devices mit irgendetwas multipliziert werden soll. Wenn da "Activated" drin steht statt einem nummerischen Wert, geht das natürlich schief.
Zu den Stati:
- Wenn Du ein HMCCUDEV oder HMCCUCHN Device definierst, bekommt das erst mal den Status "initialized".
- Wenn dann der RPC Server gestartet wird, schickt ihm die CCU alle Geräte, die sie kennt. Daraufhin werden alle FHEM Devices, die zu dieser Geräteliste passen, auf "Activated" gesetzt.
- Wenn dann der RPC Server fertig initialisiert ist, wird einmal ein Update aller Geräte durchgeführt. D.h. für das I/O Device wird der Befehl "get update" aufgerufen. Das hat die gleiche Wirkung, wie wenn Du für jedes FHEM Device separat "get update" aufrufst, nur eben etwas einfacher mit nur einem Befehl. Als Ergebnis wird dann jeweils state = 'Activated' durch einen konkreten Wert ersetzt. (übrigens wird mit der nächstes Version aus Gründen der Vereinheitlichung aus "Activated" "active" werden.
Mir scheint eher, dass beim Start des RPC-Servers etwas schief geht. Das müsste sich aber im Logfile wiederfinden.
Normalerweise spare ich mir mittlerweile bei den Minor Releases diese Info. Da sich der Bugfix aber auf ein konkretes, hier diskutiertes Problem bezieht, hier die Info zur Version 3.9.007, die vermutlich morgen als Update bereitsteht:
- Es wurde ein Fehler bei der Erkennung laufender RPC Server Prozesse unter Windows behoben. Das heißt jedoch nicht zwingend, dass HMCCU unter Windows fehlerfrei läuft. Lediglich die Chancen haben sich erhöht. Es könnte z.B. Probleme beim Anhalten des RPC Servers geben.
Habe kein Windows, um das zu testen.
Ansonsten habe ich nur den Code etwas optimiert und weitere Vorbereitungen für die Version 4.0 getroffen.
Ich betreibe (sehr gerne) HMCCU mit einer CCU2 parallel zu einem HMLAN.
Analysiere dabei laufend und sporadisch Funkprobleme der HMLAN-Devices (Lampe steht auf ioerr etc)
Analyse per apptime zeigt eigentlich nur den folgenden bemerkenswerten Eintrag:
tmr-HMCCU_ReadRPCQueue HASH(0x2defb98) 2605 65 8431 129.71 2514 HASH(d_ccu)
HMLAN1 HMLAN_Ready 3004 25 3124 124.96 0 HASH(HMLAN1)
logdb DbLog_Log 1554 62 7597 122.53 0 HASH(logdb); HASH(eg_wz_sensor)
Ist der maxDLY für HMCCU normal? Oder legt mir hier HMCCU mein restliches FHEM lahm?
Muss ich für den Parallelbetrieb speziell etwas berücksichtigen?
Danke für Hinweise.
Habe mich noch nie mit apptime beschäftigt. Wenn ich das richtig interpretiere, benötigt bei Dir die Ausführung von ReadRPCQueue im Schnitt 2,5 Sekunden. Das ist lange. Da dürftest Du eigentlich sonst nicht mehr viel machen können in der Oberfläche. Ist das so?
Ich kann mir morgen mal Vergleichswerte bei mir ansehen.
BTW: Diese Timer Funktion mitsamt den Filequeues wird hoffentlich bald Geschichte sein.
Keine Ahnung, woher das mit dem Multiplikationsfehler kommt. Mir fiel es erst nach der Aktualisierung auf.
Der RPC-Server scheint bei mir zu laufen.
Allerdings macht er nach dem "shutdown restart" den "get update" scheinbar seit dem letzten Update
nicht mehr.
Vor dem Update sah das, z.B. im Floorplan, nach dem "shutdown restart" so aus:
1) Alle Devices stehen auf "initialized"
2) Es vergehen ca. 30 Sekunden
3) Der Gerätestatus aller Geräte wird richtig angezeigt.
Seit dem Update:1) Alle Devices gehen auf "initialized"
2) Einige Sekunden später: Alle Devices gehen auf "activated"
3) That's it. Ich warte, bis ich schwarz werde: Mehr passiert nicht.
4) Ich führe einen "get update" auf das I/O Device manuell aus.
5) Der Gerätestatus aller Geräte wird richtig angezeigt. Alles funktioniert wieder
:o
Zitat von: zap am 11 März 2017, 19:36:50
Ist das die einzige Fehlermeldung im Logfile? Mir scheint, dass das Reading state eines Deiner Devices mit irgendetwas multipliziert werden soll. Wenn da "Activated" drin steht statt einem nummerischen Wert, geht das natürlich schief.
Zu den Stati:
- Wenn Du ein HMCCUDEV oder HMCCUCHN Device definierst, bekommt das erst mal den Status "initialized".
- Wenn dann der RPC Server gestartet wird, schickt ihm die CCU alle Geräte, die sie kennt. Daraufhin werden alle FHEM Devices, die zu dieser Geräteliste passen, auf "Activated" gesetzt.
- Wenn dann der RPC Server fertig initialisiert ist, wird einmal ein Update aller Geräte durchgeführt. D.h. für das I/O Device wird der Befehl "get update" aufgerufen. Das hat die gleiche Wirkung, wie wenn Du für jedes FHEM Device separat "get update" aufrufst, nur eben etwas einfacher mit nur einem Befehl. Als Ergebnis wird dann jeweils state = 'Activated' durch einen konkreten Wert ersetzt. (übrigens wird mit der nächstes Version aus Gründen der Vereinheitlichung aus "Activated" "active" werden.
Mir scheint eher, dass beim Start des RPC-Servers etwas schief geht. Das müsste sich aber im Logfile wiederfinden.
Also nach einem manuellen get Update funktioniert dann auch die automatische Aktualisierung über den RPC Server?
Gibt es Fehlermeldungen im Log?
Zitat von: wolfgang99 am 12 März 2017, 18:52:10
Ich betreibe (sehr gerne) HMCCU mit einer CCU2 parallel zu einem HMLAN.
Analysiere dabei laufend und sporadisch Funkprobleme der HMLAN-Devices (Lampe steht auf ioerr etc)
Analyse per apptime zeigt eigentlich nur den folgenden bemerkenswerten Eintrag:
tmr-HMCCU_ReadRPCQueue HASH(0x2defb98) 2605 65 8431 129.71 2514 HASH(d_ccu)
HMLAN1 HMLAN_Ready 3004 25 3124 124.96 0 HASH(HMLAN1)
logdb DbLog_Log 1554 62 7597 122.53 0 HASH(logdb); HASH(eg_wz_sensor)
Ist der maxDLY für HMCCU normal? Oder legt mir hier HMCCU mein restliches FHEM lahm?
Muss ich für den Parallelbetrieb speziell etwas berücksichtigen?
Danke für Hinweise.
Hier die Werte, die ich bei mir gemessen habe:
name function max count total average maxDly
tmr-HMCCU_ReadRPCQueue HASH(0x3da6640) 1439 341 5560 16.30 418 HASH(d_ccu)
tmr-HUEBridge_GetUpdate HASH(0x53f0840) 76 6 222 37.00 3 HASH(d_hue)
tmr-PIONEERAVR_checkConnection HASH(0x24e9c48) 60 3 132 44.00 3 HASH(d_avr)
TCM_ESP3_2 TCM_Read 27 43 202 4.70 0 HASH(TCM_ESP3_2)
m.E. zeigt ein hoher MaxDelay Wert, dass FHEM grundsätzlich einiges zu tun hat. Die Ausführungszeit von ReadRPCQueue ist hingegen sehr kurz. Ich denke nicht, dass es an der Funktion liegt.
Zitat von: zap am 13 März 2017, 07:35:11
Also nach einem manuellen get Update funktioniert dann auch die automatische Aktualisierung über den RPC Server?
Gibt es Fehlermeldungen im Log?
Ja. Genau so ist es.
Fehlermeldungen im Log sehe ich keine.
Außer besagte mit "Activated", die ich schon geschickt hatte. Ich habe keine Ahnung, worauf die sich bezieht. Nur war sie vorher eben nicht da.
ok, wenn Du nicht so viele HMCCUDEV und HMCCUCHN Devices hast, gib mir bitte mal ein list von denen, insbesondere wenn Du das Attribut ccuscaleval verwendest.
Außerdem bitte die Attribute des I/O Device.
Zitat von: zap am 14 März 2017, 18:34:26
ok, wenn Du nicht so viele HMCCUDEV und HMCCUCHN Devices hast, gib mir bitte mal ein list von denen, insbesondere wenn Du das Attribut ccuscaleval verwendest.
Außerdem bitte die Attribute des I/O Device.
ccuscaleval benutze ich nirgendwo.
IO Device sieht so aus:
define ccu2 HMCCU 192.168.2.63
attr ccu2 ccuflags intrpc
attr ccu2 room Zentral
attr ccu2 rpcinterval 3
attr ccu2 rpcserver on
attr ccu2 stateFormat rpcstate/state
attr ccu2 stripnumber 2CCUDEVs und CCHCHNs hab ich fast ausschließlich, also jede Menge davon. Was meinst Du mit list? Was genau soll ich Dir schicken?
Wenn Du z.B. ein HMCCUDEV mit dem Namen "mein_dev" definiert hast, mach mal beispielhaft für eines dieser Devices:
list mein_dev
Außerdem bitte alle "HMCCU" und "CCURPC" Meldungen, die während dem Start von FHEM bzw. dem RPC-Server im Log auftauchen.
In etwa:
grep "CCU" fhem-xxxxx.log
Zitat von: zap am 14 März 2017, 19:48:11
Wenn Du z.B. ein HMCCUDEV mit dem Namen "mein_dev" definiert hast, mach mal beispielhaft für eines dieser Devices:
list mein_dev
Außerdem bitte alle "HMCCU" und "CCURPC" Meldungen, die während dem Start von FHEM bzw. dem RPC-Server im Log auftauchen.
In etwa:
grep "CCU" fhem-xxxxx.log
Gerne.
Device:Internals:
CHANGED
DEF W-Vitrine
IODev ccu2
NAME Vitrine
NR 45
STATE on
TYPE HMCCUDEV
ccuaddr LEQ1068630
ccudevstate Active
ccuif BidCos-RF
ccuname W-Vitrine
ccutype HM-LC-Sw1-Pl-2
channels 2
statevals devstate|on|off
Readings:
2017-03-14 19:07:52 1.STATE on
2017-03-14 21:02:09 hmstate on
2017-03-14 19:07:52 state on
Hmccu:
Dp:
0.aes_key:
VAL 1
0.config_pending:
VAL false
0.dutycycle:
VAL false
0.lowbat:
VAL false
0.rssi_device:
VAL 1
0.rssi_peer:
VAL 69
0.sticky_unreach:
VAL false
0.unreach:
VAL false
1.inhibit:
VAL false
1.state:
VAL 1
1.working:
VAL 0
Attributes:
IODev ccu2
ccureadingfilter (STATE|ON_TIME)
ccureadings 1
devStateIcon on:vitrine_on@green off:vitrine_off@black Initialized:10px-kreis-gelb
event-on-change-reading .*
fp_Home3D 339,315,0, ,Vitrine
group Lichter
room HomekitLights,Wohnzimmer
statechannel 1
statevals on:true,off:false
substitute STATE!true:on,false:off,1:on,0:off
userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 Logs:2017.03.11 16:07:27 1: UPD FHEM/88_HMCCU.pm
2017.03.11 16:07:28 1: UPD FHEM/HMCCUConf.pm
2017.03.11 16:07:30 1: - bugfix: 88_HMCCU: Fixed toggle bug
2017.03.11 16:07:30 1: - update: 88_HMCCU: added tracing for RPC set config
2017.03.11 16:09:41 1: HMCCU: Deregistering RPC server http://192.168.2.67:7411/fh2001 at http://192.168.2.63:2001/
2017.03.11 16:09:41 0: HMCCU: Stopping RPC server CB2001 with PID 9491
2017.03.11 16:09:41 0: CCURPC: CB2001 Server loop terminated
2017.03.11 16:09:41 2: CCURPC: Eventcount DD = 0
2017.03.11 16:09:41 2: CCURPC: Eventcount EV = 453494
2017.03.11 16:09:41 2: CCURPC: Eventcount EX = 1
2017.03.11 16:09:41 2: CCURPC: Eventcount IN = 1
2017.03.11 16:09:41 2: CCURPC: Eventcount ND = 208
2017.03.11 16:09:41 2: CCURPC: Eventcount RA = 0
2017.03.11 16:09:41 2: CCURPC: Eventcount RD = 0
2017.03.11 16:09:41 2: CCURPC: Eventcount SL = 1
2017.03.11 16:09:41 2: CCURPC: Eventcount ST = 906
2017.03.11 16:09:41 2: CCURPC: Eventcount UD = 0
2017.03.11 16:09:41 2: CCURPC: Eventcount total = 454611
2017.03.11 16:09:41 2: CCURPC: Eventcount writeerror = 0
2017.03.11 16:09:59 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2017.03.11 16:10:11 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.03.11 16:10:11 0: HMCCU: Child process for server CB2001 started with PID 9352
2017.03.11 16:10:11 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001_1
2017.03.11 16:10:11 0: CCURPC: Initializing RPC server CB2001
2017.03.11 16:10:12 0: CCURPC: Callback server created listening on port 7411
2017.03.11 16:10:12 1: CCURPC: CB2001 Adding callback for events
2017.03.11 16:10:12 1: CCURPC: CB2001 Adding callback for new devices
2017.03.11 16:10:12 1: CCURPC: CB2001 Adding callback for deleted devices
2017.03.11 16:10:12 1: CCURPC: CB2001 Adding callback for modified devices
2017.03.11 16:10:12 1: CCURPC: CB2001 Adding callback for replaced devices
2017.03.11 16:10:12 1: CCURPC: CB2001 Adding callback for readded devices
2017.03.11 16:10:12 1: CCURPC: CB2001 Adding callback for list devices
2017.03.11 16:10:12 1: CCURPC: CB2001 Adding callback for event query
2017.03.11 16:10:12 0: CCURPC: CB2001 Entering server loop
2017.03.11 16:10:14 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2017.03.11 16:10:21 1: HMCCU: Registering callback http://192.168.2.67:7411/fh2001 with ID CB2001 at http://192.168.2.63:2001/
2017.03.11 16:10:21 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.03.11 16:10:22 1: HMCCU: RPC callback with URL http://192.168.2.67:7411/fh2001 initialized
2017.03.11 16:10:23 2: CCURPC: CB2001 NewDevice received 208 device specifications
2017.03.11 16:10:25 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2017.03.11 16:10:28 2: HMCCU: Updated devices. Success=39 Failed=0
2017.03.11 16:10:28 1: HMCCU: All RPC servers running
2017.03.11 16:38:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.11 16:44:08 1: HMCCU: Deregistering RPC server http://192.168.2.67:7411/fh2001 at http://192.168.2.63:2001/
2017.03.11 16:44:08 0: HMCCU: Stopping RPC server CB2001 with PID 9352
2017.03.11 16:44:08 0: CCURPC: CB2001 Server loop terminated
2017.03.11 16:44:08 2: CCURPC: Eventcount DD = 0
2017.03.11 16:44:08 2: CCURPC: Eventcount EV = 573
2017.03.11 16:44:08 2: CCURPC: Eventcount EX = 1
2017.03.11 16:44:08 2: CCURPC: Eventcount IN = 1
2017.03.11 16:44:08 2: CCURPC: Eventcount ND = 208
2017.03.11 16:44:08 2: CCURPC: Eventcount RA = 0
2017.03.11 16:44:08 2: CCURPC: Eventcount RD = 0
2017.03.11 16:44:08 2: CCURPC: Eventcount SL = 1
2017.03.11 16:44:08 2: CCURPC: Eventcount ST = 1
2017.03.11 16:44:08 2: CCURPC: Eventcount UD = 0
2017.03.11 16:44:08 2: CCURPC: Eventcount total = 785
2017.03.11 16:44:08 2: CCURPC: Eventcount writeerror = 0
2017.03.11 16:44:44 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2017.03.11 16:44:56 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.03.11 16:44:56 0: HMCCU: Child process for server CB2001 started with PID 9484
2017.03.11 16:44:56 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001_1
2017.03.11 16:44:56 0: CCURPC: Initializing RPC server CB2001
2017.03.11 16:44:56 0: CCURPC: Callback server created listening on port 7411
2017.03.11 16:44:56 1: CCURPC: CB2001 Adding callback for events
2017.03.11 16:44:56 1: CCURPC: CB2001 Adding callback for new devices
2017.03.11 16:44:56 1: CCURPC: CB2001 Adding callback for deleted devices
2017.03.11 16:44:56 1: CCURPC: CB2001 Adding callback for modified devices
2017.03.11 16:44:56 1: CCURPC: CB2001 Adding callback for replaced devices
2017.03.11 16:44:56 1: CCURPC: CB2001 Adding callback for readded devices
2017.03.11 16:44:56 1: CCURPC: CB2001 Adding callback for list devices
2017.03.11 16:44:56 1: CCURPC: CB2001 Adding callback for event query
2017.03.11 16:44:56 0: CCURPC: CB2001 Entering server loop
2017.03.11 16:44:59 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2017.03.11 16:45:06 1: HMCCU: Registering callback http://192.168.2.67:7411/fh2001 with ID CB2001 at http://192.168.2.63:2001/
2017.03.11 16:45:06 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.03.11 16:45:07 1: HMCCU: RPC callback with URL http://192.168.2.67:7411/fh2001 initialized
2017.03.11 16:45:08 2: CCURPC: CB2001 NewDevice received 208 device specifications
2017.03.11 16:45:10 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2017.03.11 16:45:12 2: HMCCU: Updated devices. Success=39 Failed=0
2017.03.11 16:45:12 1: HMCCU: All RPC servers running
2017.03.11 16:46:46 1: HMCCU: Deregistering RPC server http://192.168.2.67:7411/fh2001 at http://192.168.2.63:2001/
2017.03.11 16:46:46 0: HMCCU: Stopping RPC server CB2001 with PID 9484
2017.03.11 16:46:46 0: CCURPC: CB2001 Server loop terminated
2017.03.11 16:46:46 2: CCURPC: Eventcount DD = 0
2017.03.11 16:46:46 2: CCURPC: Eventcount EV = 30
2017.03.11 16:46:46 2: CCURPC: Eventcount EX = 1
2017.03.11 16:46:46 2: CCURPC: Eventcount IN = 1
2017.03.11 16:46:46 2: CCURPC: Eventcount ND = 208
2017.03.11 16:46:46 2: CCURPC: Eventcount RA = 0
2017.03.11 16:46:46 2: CCURPC: Eventcount RD = 0
2017.03.11 16:46:46 2: CCURPC: Eventcount SL = 1
2017.03.11 16:46:46 2: CCURPC: Eventcount UD = 0
2017.03.11 16:46:46 2: CCURPC: Eventcount total = 241
2017.03.11 16:46:46 2: CCURPC: Eventcount writeerror = 0
2017.03.11 16:46:48 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2017.03.11 16:46:48 0: HMCCU: RPC server(s) with PID(s) 9484 shut down. f=1
2017.03.11 16:46:48 2: HMCCU: Eventcount DD = 0
2017.03.11 16:46:48 2: HMCCU: Eventcount EV = 30
2017.03.11 16:46:48 2: HMCCU: Eventcount EX = 1
2017.03.11 16:46:48 2: HMCCU: Eventcount IN = 1
2017.03.11 16:46:48 2: HMCCU: Eventcount ND = 208
2017.03.11 16:46:48 2: HMCCU: Eventcount RA = 0
2017.03.11 16:46:48 2: HMCCU: Eventcount RD = 0
2017.03.11 16:46:48 2: HMCCU: Eventcount SL = 1
2017.03.11 16:46:48 2: HMCCU: Eventcount ST = 0
2017.03.11 16:46:48 2: HMCCU: Eventcount UD = 0
2017.03.11 16:46:48 2: HMCCU: Eventcount total = 241
2017.03.11 16:46:48 0: HMCCU: Periodical check found no RPC Servers
2017.03.11 16:46:48 0: HMCCU: All RPC servers stopped
2017.03.11 16:47:03 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.03.11 16:47:03 0: HMCCU: Child process for server CB2001 started with PID 9491
2017.03.11 16:47:03 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001_1
2017.03.11 16:47:03 0: CCURPC: Initializing RPC server CB2001
2017.03.11 16:47:04 0: CCURPC: Callback server created listening on port 7411
2017.03.11 16:47:04 1: CCURPC: CB2001 Adding callback for events
2017.03.11 16:47:04 1: CCURPC: CB2001 Adding callback for new devices
2017.03.11 16:47:04 1: CCURPC: CB2001 Adding callback for deleted devices
2017.03.11 16:47:04 1: CCURPC: CB2001 Adding callback for modified devices
2017.03.11 16:47:04 1: CCURPC: CB2001 Adding callback for replaced devices
2017.03.11 16:47:04 1: CCURPC: CB2001 Adding callback for readded devices
2017.03.11 16:47:04 1: CCURPC: CB2001 Adding callback for list devices
2017.03.11 16:47:04 1: CCURPC: CB2001 Adding callback for event query
2017.03.11 16:47:04 0: CCURPC: CB2001 Entering server loop
2017.03.11 16:47:06 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2017.03.11 16:47:13 1: HMCCU: Registering callback http://192.168.2.67:7411/fh2001 with ID CB2001 at http://192.168.2.63:2001/
2017.03.11 16:47:13 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.03.11 16:47:14 1: HMCCU: RPC callback with URL http://192.168.2.67:7411/fh2001 initialized
2017.03.11 16:47:15 2: CCURPC: CB2001 NewDevice received 208 device specifications
2017.03.11 16:47:17 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2017.03.11 16:47:19 2: HMCCU: Updated devices. Success=39 Failed=0
2017.03.11 16:47:19 1: HMCCU: All RPC servers running
2017.03.11 16:56:24 1: HMCCU: Deregistering RPC server http://192.168.2.67:7411/fh2001 at http://192.168.2.63:2001/
2017.03.11 16:56:24 0: HMCCU: Stopping RPC server CB2001 with PID 9491
2017.03.11 16:56:24 0: CCURPC: CB2001 Server loop terminated
2017.03.11 16:56:24 2: CCURPC: Eventcount DD = 0
2017.03.11 16:56:24 2: CCURPC: Eventcount EV = 114
2017.03.11 16:56:24 2: CCURPC: Eventcount EX = 1
2017.03.11 16:56:24 2: CCURPC: Eventcount IN = 1
2017.03.11 16:56:24 2: CCURPC: Eventcount ND = 208
2017.03.11 16:56:24 2: CCURPC: Eventcount RA = 0
2017.03.11 16:56:24 2: CCURPC: Eventcount RD = 0
2017.03.11 16:56:24 2: CCURPC: Eventcount SL = 1
2017.03.11 16:56:24 2: CCURPC: Eventcount UD = 0
2017.03.11 16:56:24 2: CCURPC: Eventcount total = 325
2017.03.11 16:56:24 2: CCURPC: Eventcount writeerror = 0
2017.03.11 16:56:59 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2017.03.11 16:57:11 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.03.11 16:57:11 0: HMCCU: Child process for server CB2001 started with PID 9553
2017.03.11 16:57:11 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001_1
2017.03.11 16:57:11 0: CCURPC: Initializing RPC server CB2001
2017.03.11 16:57:11 0: CCURPC: Callback server created listening on port 7411
2017.03.11 16:57:11 1: CCURPC: CB2001 Adding callback for events
2017.03.11 16:57:11 1: CCURPC: CB2001 Adding callback for new devices
2017.03.11 16:57:11 1: CCURPC: CB2001 Adding callback for deleted devices
2017.03.11 16:57:11 1: CCURPC: CB2001 Adding callback for modified devices
2017.03.11 16:57:11 1: CCURPC: CB2001 Adding callback for replaced devices
2017.03.11 16:57:11 1: CCURPC: CB2001 Adding callback for readded devices
2017.03.11 16:57:11 1: CCURPC: CB2001 Adding callback for list devices
2017.03.11 16:57:11 1: CCURPC: CB2001 Adding callback for event query
2017.03.11 16:57:11 0: CCURPC: CB2001 Entering server loop
2017.03.11 16:57:14 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2017.03.11 16:57:21 1: HMCCU: Registering callback http://192.168.2.67:7411/fh2001 with ID CB2001 at http://192.168.2.63:2001/
2017.03.11 16:57:21 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.03.11 16:57:22 1: HMCCU: RPC callback with URL http://192.168.2.67:7411/fh2001 initialized
2017.03.11 16:57:23 2: CCURPC: CB2001 NewDevice received 208 device specifications
2017.03.11 16:57:25 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2017.03.11 16:57:28 2: HMCCU: Updated devices. Success=39 Failed=0
2017.03.11 16:57:28 1: HMCCU: All RPC servers running
2017.03.11 17:17:29 1: HMCCU: Deregistering RPC server http://192.168.2.67:7411/fh2001 at http://192.168.2.63:2001/
2017.03.11 17:17:29 0: HMCCU: Stopping RPC server CB2001 with PID 9553
2017.03.11 17:17:29 0: CCURPC: CB2001 Server loop terminated
2017.03.11 17:17:29 2: CCURPC: Eventcount DD = 0
2017.03.11 17:17:29 2: CCURPC: Eventcount EV = 319
2017.03.11 17:17:29 2: CCURPC: Eventcount EX = 1
2017.03.11 17:17:29 2: CCURPC: Eventcount IN = 1
2017.03.11 17:17:29 2: CCURPC: Eventcount ND = 208
2017.03.11 17:17:29 2: CCURPC: Eventcount RA = 0
2017.03.11 17:17:29 2: CCURPC: Eventcount RD = 0
2017.03.11 17:17:29 2: CCURPC: Eventcount SL = 1
2017.03.11 17:17:29 2: CCURPC: Eventcount UD = 0
2017.03.11 17:17:29 2: CCURPC: Eventcount total = 530
2017.03.11 17:17:29 2: CCURPC: Eventcount writeerror = 0
2017.03.11 17:18:06 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2017.03.11 17:18:18 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.03.11 17:18:18 0: HMCCU: Child process for server CB2001 started with PID 9759
2017.03.11 17:18:18 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001_1
2017.03.11 17:18:18 0: CCURPC: Initializing RPC server CB2001
2017.03.11 17:18:18 0: CCURPC: Callback server created listening on port 7411
2017.03.11 17:18:18 1: CCURPC: CB2001 Adding callback for events
2017.03.11 17:18:18 1: CCURPC: CB2001 Adding callback for new devices
2017.03.11 17:18:18 1: CCURPC: CB2001 Adding callback for deleted devices
2017.03.11 17:18:18 1: CCURPC: CB2001 Adding callback for modified devices
2017.03.11 17:18:18 1: CCURPC: CB2001 Adding callback for replaced devices
2017.03.11 17:18:18 1: CCURPC: CB2001 Adding callback for readded devices
2017.03.11 17:18:18 1: CCURPC: CB2001 Adding callback for list devices
2017.03.11 17:18:18 1: CCURPC: CB2001 Adding callback for event query
2017.03.11 17:18:18 0: CCURPC: CB2001 Entering server loop
2017.03.11 17:18:21 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2017.03.11 17:18:28 1: HMCCU: Registering callback http://192.168.2.67:7411/fh2001 with ID CB2001 at http://192.168.2.63:2001/
2017.03.11 17:18:28 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.03.11 17:18:28 1: HMCCU: RPC callback with URL http://192.168.2.67:7411/fh2001 initialized
2017.03.11 17:18:30 2: CCURPC: CB2001 NewDevice received 208 device specifications
2017.03.11 17:18:31 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2017.03.11 17:18:33 2: HMCCU: Updated devices. Success=39 Failed=0
2017.03.11 17:18:33 1: HMCCU: All RPC servers running
2017.03.11 17:44:35 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.11 18:07:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.11 18:34:07 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.11 19:07:47 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.11 19:43:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.11 20:18:57 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.11 20:53:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.11 21:28:49 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.11 22:06:09 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.11 22:41:46 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.11 23:16:13 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.11 23:50:08 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 00:25:41 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 00:57:03 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 01:14:19 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 01:44:12 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 02:20:05 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 02:54:43 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 03:30:13 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 04:05:33 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 04:40:42 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 05:15:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 05:51:31 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 06:25:59 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 07:00:37 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 07:37:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 08:12:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 08:44:46 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 09:03:07 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 09:31:57 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 10:02:54 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 10:36:46 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 11:08:40 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 11:36:15 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 12:04:59 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 12:36:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 13:05:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 13:35:54 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 14:06:28 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 14:34:48 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 15:02:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 15:34:50 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 16:07:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 16:40:32 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 17:08:28 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 17:31:57 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 17:59:34 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 18:30:28 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 19:05:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 19:36:25 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 20:11:48 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 20:32:23 1: HMCCU: Deregistering RPC server http://192.168.2.67:7411/fh2001 at http://192.168.2.63:2001/
2017.03.12 20:32:23 0: HMCCU: Stopping RPC server CB2001 with PID 9759
2017.03.12 20:32:23 0: CCURPC: CB2001 Server loop terminated
2017.03.12 20:32:23 2: CCURPC: Eventcount DD = 0
2017.03.12 20:32:23 2: CCURPC: Eventcount EV = 25978
2017.03.12 20:32:23 2: CCURPC: Eventcount EX = 1
2017.03.12 20:32:23 2: CCURPC: Eventcount IN = 1
2017.03.12 20:32:23 2: CCURPC: Eventcount ND = 208
2017.03.12 20:32:23 2: CCURPC: Eventcount RA = 0
2017.03.12 20:32:23 2: CCURPC: Eventcount RD = 0
2017.03.12 20:32:23 2: CCURPC: Eventcount SL = 1
2017.03.12 20:32:23 2: CCURPC: Eventcount ST = 51
2017.03.12 20:32:23 2: CCURPC: Eventcount UD = 0
2017.03.12 20:32:23 2: CCURPC: Eventcount total = 26240
2017.03.12 20:32:23 2: CCURPC: Eventcount writeerror = 0
2017.03.12 20:33:19 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2017.03.12 20:33:31 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.03.12 20:33:31 0: HMCCU: Child process for server CB2001 started with PID 16197
2017.03.12 20:33:31 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001_1
2017.03.12 20:33:31 0: CCURPC: Initializing RPC server CB2001
2017.03.12 20:33:31 0: CCURPC: Callback server created listening on port 7411
2017.03.12 20:33:31 1: CCURPC: CB2001 Adding callback for events
2017.03.12 20:33:31 1: CCURPC: CB2001 Adding callback for new devices
2017.03.12 20:33:31 1: CCURPC: CB2001 Adding callback for deleted devices
2017.03.12 20:33:31 1: CCURPC: CB2001 Adding callback for modified devices
2017.03.12 20:33:31 1: CCURPC: CB2001 Adding callback for replaced devices
2017.03.12 20:33:31 1: CCURPC: CB2001 Adding callback for readded devices
2017.03.12 20:33:31 1: CCURPC: CB2001 Adding callback for list devices
2017.03.12 20:33:31 1: CCURPC: CB2001 Adding callback for event query
2017.03.12 20:33:31 0: CCURPC: CB2001 Entering server loop
2017.03.12 20:33:34 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2017.03.12 20:33:41 1: HMCCU: Registering callback http://192.168.2.67:7411/fh2001 with ID CB2001 at http://192.168.2.63:2001/
2017.03.12 20:33:44 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.03.12 20:33:44 1: HMCCU: RPC callback with URL http://192.168.2.67:7411/fh2001 initialized
2017.03.12 20:33:45 2: CCURPC: CB2001 NewDevice received 208 device specifications
2017.03.12 20:33:47 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2017.03.12 20:33:49 2: HMCCU: Updated devices. Success=39 Failed=0
2017.03.12 20:33:49 1: HMCCU: All RPC servers running
2017.03.12 20:57:53 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 21:32:05 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 22:07:02 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 22:37:01 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 23:05:35 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.12 23:38:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 00:14:19 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 00:48:53 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 01:24:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 01:59:33 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 02:36:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 03:13:00 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 03:45:57 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 04:22:00 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 04:57:19 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 05:32:28 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 06:08:05 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 06:43:16 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 07:02:53 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 07:26:08 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 07:51:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 08:26:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 08:57:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 09:17:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 09:47:58 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 10:17:37 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 10:50:06 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 11:24:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 11:52:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 12:29:56 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 13:06:14 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 13:43:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 14:17:01 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 14:53:01 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 15:29:47 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 16:02:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 16:38:13 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 17:12:30 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 17:46:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 18:20:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 18:48:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 19:10:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 19:34:21 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 20:03:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 20:39:08 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 21:13:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 21:47:16 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 22:12:26 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 22:33:40 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 23:03:43 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.13 23:38:27 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 00:12:09 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 00:48:07 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 01:19:40 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 01:53:08 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 02:28:26 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 03:04:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 03:41:08 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 04:16:28 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 04:52:42 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 05:28:00 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 06:03:12 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 06:39:31 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 07:01:02 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 07:26:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 07:55:17 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 08:28:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 08:59:48 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 09:35:27 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 10:10:56 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 10:46:14 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 11:21:39 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 11:57:30 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 12:32:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 13:05:11 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 13:40:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 14:15:37 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 14:42:41 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 15:04:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 15:37:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 16:10:26 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 16:39:43 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 17:03:40 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 17:33:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 18:07:54 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 18:40:15 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 19:04:35 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 19:32:45 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 20:05:22 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.14 20:37:54 3: CCURPC: CB2001 Received 500 events from CCU since last check
Auf den ersten Blick sieht das alles gut aus, bis auf die Meldungen, dass seit xx Sekunden keine Events von der CCU kamen.
Vorschlag: RPC Server stoppen, CCU neu starten, RPC Server starten
Zitat von: zap am 15 März 2017, 07:19:58
Auf den ersten Blick sieht das alles gut aus, bis auf die Meldungen, dass seit xx Sekunden keine Events von der CCU kamen.
Vorschlag: RPC Server stoppen, CCU neu starten, RPC Server starten
Gerade probiert:
set ccu2 rpcserver off
Dann: CCU neu gestartet
Dann: set ccu2 rpcserver on
Ergebnis:
Alle Geräte bleiben auf "Activated".
Nach einem get update auf die ccu2 geht's wieder.
Logging:
2017.03.15 09:06:10 1: HMCCU: Deregistering RPC server http://192.168.2.67:7411/fh2001 at http://192.168.2.63:2001/
2017.03.15 09:06:10 0: HMCCU: Stopping RPC server CB2001 with PID 16197
2017.03.15 09:06:10 0: CCURPC: CB2001 Server loop terminated
2017.03.15 09:06:11 2: CCURPC: Eventcount DD = 0
2017.03.15 09:06:11 2: CCURPC: Eventcount EV = 56460
2017.03.15 09:06:11 2: CCURPC: Eventcount EX = 1
2017.03.15 09:06:11 2: CCURPC: Eventcount IN = 1
2017.03.15 09:06:11 2: CCURPC: Eventcount ND = 208
2017.03.15 09:06:11 2: CCURPC: Eventcount RA = 0
2017.03.15 09:06:11 2: CCURPC: Eventcount RD = 0
2017.03.15 09:06:11 2: CCURPC: Eventcount SL = 1
2017.03.15 09:06:11 2: CCURPC: Eventcount ST = 112
2017.03.15 09:06:11 2: CCURPC: Eventcount UD = 0
2017.03.15 09:06:11 2: CCURPC: Eventcount total = 56783
2017.03.15 09:06:11 2: CCURPC: Eventcount writeerror = 0
2017.03.15 09:06:13 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2017.03.15 09:06:13 0: HMCCU: RPC server(s) with PID(s) 16197 shut down. f=1
2017.03.15 09:06:13 2: HMCCU: Eventcount DD = 0
2017.03.15 09:06:13 2: HMCCU: Eventcount EV = 56459
2017.03.15 09:06:13 2: HMCCU: Eventcount EX = 1
2017.03.15 09:06:13 2: HMCCU: Eventcount IN = 1
2017.03.15 09:06:13 2: HMCCU: Eventcount ND = 208
2017.03.15 09:06:13 2: HMCCU: Eventcount RA = 0
2017.03.15 09:06:13 2: HMCCU: Eventcount RD = 0
2017.03.15 09:06:13 2: HMCCU: Eventcount SL = 1
2017.03.15 09:06:13 2: HMCCU: Eventcount ST = 112
2017.03.15 09:06:13 2: HMCCU: Eventcount UD = 0
2017.03.15 09:06:13 2: HMCCU: Eventcount total = 56782
2017.03.15 09:06:13 0: HMCCU: Periodical check found no RPC Servers
2017.03.15 09:06:13 0: HMCCU: All RPC servers stopped
2017.03.15 09:27:10 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.03.15 09:27:10 0: HMCCU: Child process for server CB2001 started with PID 29799
2017.03.15 09:27:10 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001_1
2017.03.15 09:27:10 0: CCURPC: Initializing RPC server CB2001
2017.03.15 09:27:10 0: RPC server(s) starting
2017.03.15 09:27:10 0: CCURPC: Callback server created listening on port 7411
2017.03.15 09:27:10 1: CCURPC: CB2001 Adding callback for events
2017.03.15 09:27:10 1: CCURPC: CB2001 Adding callback for new devices
2017.03.15 09:27:10 1: CCURPC: CB2001 Adding callback for deleted devices
2017.03.15 09:27:10 1: CCURPC: CB2001 Adding callback for modified devices
2017.03.15 09:27:10 1: CCURPC: CB2001 Adding callback for replaced devices
2017.03.15 09:27:10 1: CCURPC: CB2001 Adding callback for readded devices
2017.03.15 09:27:10 1: CCURPC: CB2001 Adding callback for list devices
2017.03.15 09:27:10 1: CCURPC: CB2001 Adding callback for event query
2017.03.15 09:27:10 0: CCURPC: CB2001 Entering server loop
2017.03.15 09:27:13 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2017.03.15 09:27:22 1: HMCCU: Registering callback http://192.168.2.67:7411/fh2001 with ID CB2001 at http://192.168.2.63:2001/
2017.03.15 09:27:22 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.03.15 09:27:22 1: HMCCU: RPC callback with URL http://192.168.2.67:7411/fh2001 initialized
2017.03.15 09:27:24 2: CCURPC: CB2001 NewDevice received 208 device specifications
2017.03.15 09:27:25 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2017.03.15 09:27:26 2: 41
2017.03.15 09:27:28 2: HMCCU: Updated devices. Success=39 Failed=0
2017.03.15 09:27:28 1: HMCCU: All RPC servers running
2017.03.15 09:27:28 1: PERL WARNING: Argument "Activated" isn't numeric in multiplication (*) at (eval 73346) line 1.
2017.03.15 09:27:28 1: PERL WARNING: Argument "Activated" isn't numeric in sprintf at (eval 73348) line 1.
2017.03.15 09:27:35 2: 100
2017.03.15 09:27:35 2: 100
2017.03.15 09:27:35 2: 100
2017.03.15 09:27:35 2: 100
2017.03.15 09:27:35 2: 100
2017.03.15 09:27:35 2: 100
2017.03.15 09:27:35 2: 100
2017.03.15 09:27:35 2: 100
2017.03.15 09:27:35 2: 41
2017.03.15 09:27:35 2: 100
2017.03.15 09:27:35 2: 100
2017.03.15 09:27:35 2: 100
2017.03.15 09:27:35 2: 100
2017.03.15 09:27:35 2: 100
2017.03.15 09:27:35 2: 60
2017.03.15 09:27:35 2: 74
2017.03.15 09:27:35 2: 78
2017.03.15 09:27:35 2: 22
2017.03.15 09:27:51 1: PERL WARNING: Argument "Activated" isn't numeric in multiplication (*) at (eval 73451) line 1.
2017.03.15 09:28:07 1: PERL WARNING: Argument "Activated" isn't numeric in multiplication (*) at (eval 73456) line 1.
2017.03.15 09:28:23 1: PERL WARNING: Argument "Activated" isn't numeric in multiplication (*) at (eval 73461) line 1.
2017.03.15 09:28:33 1: PERL WARNING: Argument "Activated" isn't numeric in multiplication (*) at (eval 73467) line 1.
Hallo,
für die CC2 ist jetzt die 2.27.7. draussen.
http://www.eq-3.de/Downloads/Software/HM-CCU2-Firmware_Updates/HM-CCU2-2.27.7/HM-CCU2-Changelog.2.27.7.pdf
Hat das schon jemand ausprobiert? Gibt es Probleme mit der Abnindung über HMCCU?
Es scheint ja auch eine neue Doku (V2.15) für die RPC-Schnittstelle zu geben...
http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HM_XmlRpc_API.pdf
VG
Christian
@chris8888: meistens ist es besser, die Reaktionen im Homematic Forum auf eine neue Firmware abzuwarten. Wenn dort keine Probleme gemeldet werden, kann man es mal installieren (Backup nicht vergessen).
Schwerpunkt der Changes scheint HM-IP zu sein. Möglicherweise wird das eine oder andere Problem gelöst, das mancher hier mit HM-IP Thermostaten hatte.
@aski71: langsam gehen mir die Ideen aus. Zumal Du der einzige mit diesen Problemen bist. Sind alle Versionen der Module aktuell (Einfach mal die Dateien öffnen und in den Header schauen)?
88_HMCCU.pm >= 3.9.007
88_HMCCUDEV.pm 3.9
88_HMCCUCHN.pm 3.9.003
Das "Argument Activated isn't numeric" ist mir auch ein Rätsel. Hast Du userreadings definiert?
Zitat von: zap am 15 März 2017, 16:59:29
@chris8888: meistens ist es besser, die Reaktionen im Homematic Forum auf eine neue Firmware abzuwarten. Wenn dort keine Probleme gemeldet werden, kann man es mal installieren (Backup nicht vergessen).
Schwerpunkt der Changes scheint HM-IP zu sein. Möglicherweise wird das eine oder andere Problem gelöst, das mancher hier mit HM-IP Thermostaten hatte.
@aski71: langsam gehen mir die Ideen aus. Zumal Du der einzige mit diesen Problemen bist. Sind alle Versionen der Module aktuell (Einfach mal die Dateien öffnen und in den Header schauen)?
88_HMCCU.pm >= 3.9.007
88_HMCCUDEV.pm 3.9
88_HMCCUCHN.pm 3.9.003
Das "Argument Activated isn't numeric" ist mir auch ein Rätsel. Hast Du userreadings definiert?
User-Readings: Ich glaube ja. Für Batterie oder so hatte ich mal was gemacht. Weiß das aber nicht mehr auswendig.
Module aktuell: Habe heute nochmal einen Update Check gemacht. Da gibt's inzwischen wieder neuere Module. Komme aber gerade nicht zum Updaten. Mache ich nochmal und schaue, was dann passiert.
Hallo,
ich habe das Update auf 2.27.7 einfach mal eingespielt. Auf den ersten Blick scheint alles wie vorher zu funktionieren.
Keine besonderen Log-Einträge, die RPC-Schnittstelle scheint in beide Richtungen zu laufen.
Ich beobachte das mal...
VG
Christian
Zitat von: aski71 am 15 März 2017, 17:36:03
User-Readings: Ich glaube ja. Für Batterie oder so hatte ich mal was gemacht. Weiß das aber nicht mehr auswendig.
Module aktuell: Habe heute nochmal einen Update Check gemacht. Da gibt's inzwischen wieder neuere Module. Komme aber gerade nicht zum Updaten. Mache ich nochmal und schaue, was dann passiert.
Heute auf die neuesten Module upgedated: Jetzt geht's wieder!
Danke!
Ich habe nach dem Update auf die CCU2 2.27 Firmware ein Mega Probleme.
Ich wollte ein paar weitere Devices in fhem anlegen.
Bei einem get devicelist schmierte mir fhem irgendwie ab.
Der RPC wurde beendet.
Durch einen Neustart hat Fhem gemeint es gibt kein IODEV für die Homematic Geräte
und hat die bereits vorhandenen aus der fhem.cfg rausgelöscht.
Dieses Verhalten war auch nach mehreren Starts der Fall.
Update der CCU2 retour auf 2.25 und jetzt geht wieder alles wie vorher.
Bin nur ich alleine mit dem Fehler? Oder habe ich wo einen Blödsinn gemacht?
LG Thomas
Ohne Logeinträge kann ich dazu nichts sagen. Zwei Posts weiter oben hat jemand das Update erfolgreich durchgeführt. Ich selbst bin noch auf der alten Version.
Vielleicht hast Du das get devicelist zu früh nach dem update dirchgeführt. Möglicherweise liefen noch nicht alle Prozesse auf der CCU. Abstürzen sollte FHEM deshalb aber nicht.
So ganz genau kann ich es jetzt nicht sagen aber das kam nach einem "get CCU2 devicelist".
FHEM reagierte einige Zeit nicht gar nicht.wie man sieht ca 3 minuten.
2017.03.21 15:05:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.21 15:07:47 1: HMCCU: HMScript failed. 500 Can't connect to 10.0.0.82:8181
2017.03.21 15:07:47 1: HMCCU: CCU2 Execution of CCU script or command failed
2017.03.21 15:10:05 1: HMCCU: HMScript failed. 500 Can't connect to 10.0.0.82:8181
2017.03.21 15:10:05 1: HMCCU: CCU2 Execution of CCU script or command failed
EDIT: Bevor ich weitere Devices hinzufügen wollte, konnte ich zb einen Powermeter per fhem Schalten.
erst durch das abfragen der devicelist fiel mir das Problem auf.
Also vielleicht fällt das Problem im normal Betrieb nicht auf.
LG
Ich vermute mal, dass die CCU noch nicht 100% lief, da die Verbindung zu Port 8181 fehl schlägt.
Wenn Du das Update noch mal versuchst, gehe am besten so vor:
- RPC Server in FHEM stoppen
- CCU Updaten
- Warten, bis Du Dich wieder zum CCU WebGUI verbinden kannst
- Nochmal 5 Minuten warten
- get devicelist ausführen
- RPC Server starten
Zitat
- RPC Server in FHEM stoppen
- CCU Updaten
- Warten, bis Du Dich wieder zum CCU WebGUI verbinden kannst
- Nochmal 5 Minuten warten
- get devicelist ausführen
- RPC Server starten
vorher den RPC starten und dann erst devicelist oder?
moin,
auch wenn es Dir nicht viel hilft, ich habe mal mit der ccu firmware 2.27.7 und aktuellem fhem ein "get deviceliste" auf meinen ccu device in fhem gemacht und hatte keine Probleme. Result "Read 11 devices with 99 channels from CCU". Auch andere Probleme sind mir nicht aufgefallen mit der neuen firmware.
RPC beendet - etwas gewartet
CCU2 update durchgeführt
nach neustart bestimmt 10 min gewartet.
CCU2 reagierte normal, alle Devices angezeigt......
RPC gestartet und ab dann hängt FHEM.
Das steht dann im LOG.
Er ist alle devices durchgegangen mit jeweils einem Fehler.
In der ganzen Zeit war Fhem nicht nutzbar.
2017.03.21 17:07:45 1: HMCCU: Deregistering RPC server http://10.0.0.80:7411/fh2001 at http://10.0.0.82:2001/
2017.03.21 17:07:45 1: HMCCU: Deregistering RPC server http://10.0.0.80:14702/fh9292 at http://10.0.0.82:9292/groups
2017.03.21 17:07:45 1: HMCCU: Deregistering RPC server http://10.0.0.80:7420/fh2010 at http://10.0.0.82:2010/
2017.03.21 17:07:45 0: HMCCU: Stopping RPC server CB2001 with PID 3881
2017.03.21 17:07:45 0: CCURPC: CB2001 Server loop terminated
2017.03.21 17:07:45 2: CCURPC: Eventcount DD = 0
2017.03.21 17:07:45 2: CCURPC: Eventcount EV = 3381
2017.03.21 17:07:45 2: CCURPC: Eventcount EX = 1
2017.03.21 17:07:45 2: CCURPC: Eventcount IN = 1
2017.03.21 17:07:45 2: CCURPC: Eventcount ND = 227
2017.03.21 17:07:45 2: CCURPC: Eventcount RA = 0
2017.03.21 17:07:45 2: CCURPC: Eventcount RD = 0
2017.03.21 17:07:45 2: CCURPC: Eventcount SL = 1
2017.03.21 17:07:45 0: HMCCU: Stopping RPC server CB9292 with PID 3883
2017.03.21 17:07:45 0: HMCCU: Stopping RPC server CB2010 with PID 3882
2017.03.21 17:07:45 0: CCURPC: CB2010 Server loop terminated
2017.03.21 17:07:45 2: CCURPC: Eventcount DD = 0
2017.03.21 17:07:45 2: CCURPC: Eventcount EV = 0
2017.03.21 17:07:45 2: CCURPC: Eventcount EX = 1
2017.03.21 17:07:45 2: CCURPC: Eventcount IN = 1
2017.03.21 17:07:45 2: CCURPC: Eventcount ND = 0
2017.03.21 17:07:45 2: CCURPC: Eventcount ST = 6
2017.03.21 17:07:45 2: CCURPC: Eventcount RA = 0
2017.03.21 17:07:45 2: CCURPC: Eventcount UD = 0
2017.03.21 17:07:45 2: CCURPC: Eventcount total = 3617
2017.03.21 17:07:45 2: CCURPC: Eventcount RD = 0
2017.03.21 17:07:45 2: CCURPC: Eventcount writeerror = 0
2017.03.21 17:07:45 2: CCURPC: Eventcount SL = 1
2017.03.21 17:07:45 2: CCURPC: Eventcount UD = 0
2017.03.21 17:07:45 2: CCURPC: Eventcount total = 3
2017.03.21 17:07:45 2: CCURPC: Eventcount writeerror = 0
2017.03.21 17:07:46 0: HMCCU: Stopping RPC server with PID 3883
2017.03.21 17:07:46 0: CCURPC: CB9292 Server loop terminated
2017.03.21 17:07:46 2: CCURPC: Eventcount DD = 0
2017.03.21 17:07:46 2: CCURPC: Eventcount EV = 1740
2017.03.21 17:07:46 2: CCURPC: Eventcount EX = 1
2017.03.21 17:07:46 2: CCURPC: Eventcount IN = 1
2017.03.21 17:07:46 2: CCURPC: Eventcount ND = 12
2017.03.21 17:07:46 2: CCURPC: Eventcount RA = 0
2017.03.21 17:07:46 2: CCURPC: Eventcount RD = 0
2017.03.21 17:07:46 2: CCURPC: Eventcount SL = 1
2017.03.21 17:07:46 2: CCURPC: Eventcount ST = 3
2017.03.21 17:07:46 2: CCURPC: Eventcount UD = 0
2017.03.21 17:07:46 2: CCURPC: Eventcount total = 1758
2017.03.21 17:07:46 2: CCURPC: Eventcount writeerror = 0
2017.03.21 17:07:47 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2017.03.21 17:07:47 0: HMCCU: Received EX event. RPC server CB2010 terminated.
2017.03.21 17:07:47 0: HMCCU: RPC server(s) with PID(s) 3881,3882 shut down. f=1
2017.03.21 17:07:47 2: HMCCU: Eventcount DD = 0
2017.03.21 17:07:47 2: HMCCU: Eventcount EV = 5112
2017.03.21 17:07:47 2: HMCCU: Eventcount EX = 2
2017.03.21 17:07:47 2: HMCCU: Eventcount IN = 3
2017.03.21 17:07:47 2: HMCCU: Eventcount ND = 239
2017.03.21 17:07:47 2: HMCCU: Eventcount RA = 0
2017.03.21 17:07:47 2: HMCCU: Eventcount RD = 0
2017.03.21 17:07:47 2: HMCCU: Eventcount SL = 3
2017.03.21 17:07:47 2: HMCCU: Eventcount ST = 9
2017.03.21 17:07:47 2: HMCCU: Eventcount UD = 0
2017.03.21 17:07:47 2: HMCCU: Eventcount total = 5368
2017.03.21 17:07:47 0: HMCCU: Periodical check found no RPC Servers
2017.03.21 17:07:47 0: HMCCU: All RPC servers stopped
2017.03.21 17:07:47 0: HMCCU: Periodical check found no RPC Servers
2017.03.21 17:07:47 0: HMCCU: All RPC servers stopped
2017.03.21 17:07:47 0: HMCCU: Periodical check found no RPC Servers
2017.03.21 17:07:47 0: HMCCU: All RPC servers stopped
2017.03.21 17:46:24 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.03.21 17:46:24 0: HMCCU: Child process for server CB2001 started with PID 4511
2017.03.21 17:46:24 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001_1
2017.03.21 17:46:24 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.03.21 17:46:24 0: CCURPC: Initializing RPC server CB2001
2017.03.21 17:46:24 0: HMCCU: Child process for server CB2010 started with PID 4512
2017.03.21 17:46:24 0: CCURPC: CB2010 Creating file queue /tmp/ccuqueue_2010_1
2017.03.21 17:46:24 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.03.21 17:46:24 0: CCURPC: Initializing RPC server CB2010
2017.03.21 17:46:24 0: HMCCU: Child process for server CB9292 started with PID 4513
2017.03.21 17:46:24 0: CCURPC: CB9292 Creating file queue /tmp/ccuqueue_9292_1
2017.03.21 17:46:24 0: CCURPC: Initializing RPC server CB9292
2017.03.21 17:46:24 0: RPC server(s) starting
2017.03.21 17:46:25 0: CCURPC: Callback server created listening on port 7411
2017.03.21 17:46:25 1: CCURPC: CB2001 Adding callback for events
2017.03.21 17:46:25 1: CCURPC: CB2001 Adding callback for new devices
2017.03.21 17:46:25 1: CCURPC: CB2001 Adding callback for deleted devices
2017.03.21 17:46:25 1: CCURPC: CB2001 Adding callback for modified devices
2017.03.21 17:46:25 1: CCURPC: CB2001 Adding callback for replaced devices
2017.03.21 17:46:25 1: CCURPC: CB2001 Adding callback for readded devices
2017.03.21 17:46:25 0: CCURPC: Callback server created listening on port 7420
2017.03.21 17:46:25 1: CCURPC: CB2010 Adding callback for events
2017.03.21 17:46:25 1: CCURPC: CB2001 Adding callback for list devices
2017.03.21 17:46:25 1: CCURPC: CB2010 Adding callback for new devices
2017.03.21 17:46:25 1: CCURPC: CB2001 Adding callback for event query
2017.03.21 17:46:25 1: CCURPC: CB2010 Adding callback for deleted devices
2017.03.21 17:46:25 1: CCURPC: CB2010 Adding callback for modified devices
2017.03.21 17:46:25 0: CCURPC: CB2001 Entering server loop
2017.03.21 17:46:25 1: CCURPC: CB2010 Adding callback for replaced devices
2017.03.21 17:46:25 1: CCURPC: CB2010 Adding callback for readded devices
2017.03.21 17:46:25 1: CCURPC: CB2010 Adding callback for list devices
2017.03.21 17:46:25 1: CCURPC: CB2010 Adding callback for event query
2017.03.21 17:46:25 0: CCURPC: CB2010 Entering server loop
2017.03.21 17:46:25 0: CCURPC: Callback server created listening on port 14702
2017.03.21 17:46:25 1: CCURPC: CB9292 Adding callback for events
2017.03.21 17:46:25 1: CCURPC: CB9292 Adding callback for new devices
2017.03.21 17:46:25 1: CCURPC: CB9292 Adding callback for deleted devices
2017.03.21 17:46:25 1: CCURPC: CB9292 Adding callback for modified devices
2017.03.21 17:46:25 1: CCURPC: CB9292 Adding callback for replaced devices
2017.03.21 17:46:25 1: CCURPC: CB9292 Adding callback for readded devices
2017.03.21 17:46:25 1: CCURPC: CB9292 Adding callback for list devices
2017.03.21 17:46:25 1: CCURPC: CB9292 Adding callback for event query
2017.03.21 17:46:25 0: CCURPC: CB9292 Entering server loop
2017.03.21 17:46:26 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2017.03.21 17:46:26 0: HMCCU: Received SL event. RPC server CB2010 enters server loop
2017.03.21 17:46:26 0: HMCCU: Received SL event. RPC server CB9292 enters server loop
2017.03.21 17:46:33 1: HMCCU: Registering callback http://10.0.0.80:7411/fh2001 with ID CB2001 at http://10.0.0.82:2001/
2017.03.21 17:46:33 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.03.21 17:46:34 1: HMCCU: RPC callback with URL http://10.0.0.80:7411/fh2001 initialized
2017.03.21 17:46:34 1: HMCCU: Registering callback http://10.0.0.80:7420/fh2010 with ID CB2010 at http://10.0.0.82:2010/
2017.03.21 17:46:34 1: HMCCU: RPC callback with URL http://10.0.0.80:7420/fh2010 initialized
2017.03.21 17:46:34 1: HMCCU: Registering callback http://10.0.0.80:14702/fh9292 with ID CB9292 at http://10.0.0.82:9292/groups
2017.03.21 17:46:35 1: CCURPC: CB2010 ListDevices. Sending init to HMCCU
2017.03.21 17:46:35 1: CCURPC: CB9292 ListDevices. Sending init to HMCCU
2017.03.21 17:46:35 2: CCURPC: CB9292 NewDevice received 12 device specifications
2017.03.21 17:46:36 2: CCURPC: CB2001 NewDevice received 227 device specifications
2017.03.21 17:46:44 1: HMCCU: RPC callback with URL http://10.0.0.80:14702/fh9292 initialized
2017.03.21 17:46:48 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2017.03.21 17:46:48 0: HMCCU: Received IN event. RPC server CB2010 initialized.
2017.03.21 17:46:48 0: HMCCU: Received IN event. RPC server CB9292 initialized.
2017.03.21 17:48:59 1: HMCCU: HMScript failed. 500 Can't connect to 10.0.0.82:8181
2017.03.21 17:48:59 2: HMCCU: Update of device LEQxxx failed
2017.03.21 17:51:12 1: HMCCU: HMScript failed. 500 Can't connect to 10.0.0.82:8181
2017.03.21 17:51:12 2: HMCCU: Update of device LEQxxx:1 failed
2017.03.21 17:53:25 1: HMCCU: HMScript failed. 500 Can't connect to 10.0.0.82:8181
2017.03.21 17:53:25 2: HMCCU: Update of device LEQxxx failed
2017.03.21 17:55:38 1: HMCCU: HMScript failed. 500 Can't connect to 10.0.0.82:8181
2017.03.21 17:55:38 2: HMCCU: Update of device LEQxxx failed
2017.03.21 17:57:51 1: HMCCU: HMScript failed. 500 Can't connect to 10.0.0.82:8181
2017.03.21 17:57:51 2: HMCCU: Update of device MEQxxx failed
2017.03.21 17:58:08 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.21 18:00:04 1: HMCCU: HMScript failed. 500 Can't connect to 10.0.0.82:8181
2017.03.21 18:00:04 2: HMCCU: Update of device LEQxxx failed
2017.03.21 18:02:18 1: HMCCU: HMScript failed. 500 Can't connect to 10.0.0.82:8181
2017.03.21 18:02:18 2: HMCCU: Update of device LEQxxx failed
2017.03.21 18:04:31 1: HMCCU: HMScript failed. 500 Can't connect to 10.0.0.82:8181
2017.03.21 18:04:31 2: HMCCU: Update of device NEQxxx failed
2017.03.21 18:06:44 1: HMCCU: HMScript failed. 500 Can't connect to 10.0.0.82:8181
2017.03.21 18:06:44 2: HMCCU: Update of device LEQxxx failed
2017.03.21 18:08:57 1: HMCCU: HMScript failed. 500 Can't connect to 10.0.0.82:8181
2017.03.21 18:08:57 2: HMCCU: Update of device LEQxxx:1 failed
2017.03.21 18:09:22 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.03.21 18:09:23 3: CCURPC: CB9292 Received 500 events from CCU since last check
2017.03.21 18:11:10 1: HMCCU: HMScript failed. 500 Can't connect to 10.0.0.82:8181
2017.03.21 18:11:10 2: HMCCU: Update of device LEQxxxx failed
2017.03.21 18:13:23 1: HMCCU: HMScript failed. 500 Can't connect to 10.0.0.82:8181
2017.03.21 18:13:23 2: HMCCU: Update of device LEQxxx failed
2017.03.21 18:13:23 2: HMCCU: Updated devices. Success=0 Failed=12
2017.03.21 18:13:23 1: HMCCU: All RPC servers running
setstate CCU2 running/OK
setstate CCU2 2017-03-21 17:46:48 rpcstate running
setstate CCU2 2017-03-21 17:46:48 state OK
RPC ist on und OK
Dann habe ich versucht ein device zu schalten.
dann kam
2017.03.21 18:14:18 1: HMCCUDEV: HM_KE_KG_PMS2 Execution of CCU script or command failed
RPC gestoppt
CCU2 wieder auf Firmware 2.25.15 zurück gespielt.
RPC gestartet
alles funktioniert einwandfrei.
Info:
RPC beendet.
Upgrade auf Firmware 2.27.7 auf CCU2 installiert.
Upgrade auf CuXD 2.9 installiert.
CCU neu gestartet.
RPC gestartet.
... läuft bei mir.
So jetzt funkt auch meine CCU2.
Problem war die Firewall der CCU2.
Habe nichts umgestellt nur dürfte sie seit dem Update auf 2.27 richtig greifen.
LG
Zitat von: mrfloppy am 21 März 2017, 21:08:36
So jetzt funkt auch meine CCU2.
Problem war die Firewall der CCU2.
Habe nichts umgestellt nur dürfte sie seit dem Update auf 2.27 richtig greifen.
LG
Wie hat sich das Problem gelöst, wenn du nichts umgestellt hast?
VG
In der Firewall der CCU2 steht "Remote HomeMatic-Script API: auf eingeschrenkt"
Und unten im Feld ist keine Ip eingetragen gewesen.
Bei der Version 2.25.15 war das aber irgendwie kein Problem nur seit 2.27 dürfte
diese Regel eben richtig greifen.
Habe nun meine Ip eingetragen und jetzt geht es.
LG
Oder "Remote Homematic Script API" auf Vollzugriff setzen.
Statt einer einzelnen IP kann man auch ein ganzes Netzsegment einschalten, wenn man bei "Eingeschränktem Zugriff" bleiben möchte, z.B.
192.168.0.0/16
Ja nur eben komisch das diese Firewall regel bei der alten Firmware nicht gegriffen hat.
Ja, sicherheitstechnisch hat EQ-3 mit der neuen Firmware einiges verbessert.
Hallo und guten Abend
ich habe heute noch einmal versucht, die 88_HMCCU.pm mit zu updaten, jedoch habe ich, wie bei den anderen Versuchen
fehlende Geräte
hier die Einträge der logdatei
2017.03.22 20:37:52 1: define SZlicht HMCCUDEV Schlafzimmerlicht 1: Invalid or unknown CCU device name or address
2017.03.22 20:37:54 1: define LichtObererFlur HMCCUDEV Licht-oberer-Flur: Invalid or unknown CCU device name or address
2017.03.22 20:37:56 1: define WZDeckenleuchte HMCCUDEV WZDeckenleuchte: Invalid or unknown CCU device name or address
2017.03.22 20:37:57 1: define WZWandleuchte HMCCUDEV WZWandleuchte: Invalid or unknown CCU device name or address
2017.03.22 20:37:59 3: tPortLocal: port 7073 opened
2017.03.22 20:38:00 3: TelegramBot_Define Telegram0176: called
2017.03.22 20:38:02 1: define Schloss HMCCUDEV Schloss: Invalid or unknown CCU device name or address
2017.03.22 20:38:04 3: Opening FB7390 device 192.168.1.9:1012
2017.03.22 20:38:05 1: Including /opt/fhem/log/fhem.save
Invalid or unknown CCU device name or address
Invalid or unknown CCU device name or address
Invalid or unknown CCU device name or address
Invalid or unknown CCU device name or address
/opt/fhem/log/fhem.save: Please define Schloss first
Please define Schloss first
Please define Schloss first
Please define Schloss first
Please define Schloss first
Please define Schloss first
Please define WZDeckenleuchte first
Please define WZDeckenleuchte first
Please define WZDeckenleuchte first
Please define WZDeckenleuchte first
Please define WZDeckenleuchte first
Please define WZDeckenleuchte first
2017.03.22 20:39:56 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.03.22 20:39:56 0: HMCCU: Child process for server CB2001 started with PID 21500
2017.03.22 20:39:56 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001_1
2017.03.22 20:39:56 0: CCURPC: Initializing RPC server CB2001
2017.03.22 20:39:56 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.03.22 20:39:56 0: HMCCU: Child process for server CB2010 started with PID 21501
2017.03.22 20:39:56 0: CCURPC: CB2010 Creating file queue /tmp/ccuqueue_2010_1
2017.03.22 20:39:56 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.03.22 20:39:56 0: CCURPC: Initializing RPC server CB2010
2017.03.22 20:39:56 0: HMCCU: Child process for server CB9292 started with PID 21502
2017.03.22 20:39:56 0: CCURPC: CB9292 Creating file queue /tmp/ccuqueue_9292_1
2017.03.22 20:39:56 0: CCURPC: Initializing RPC server CB9292
2017.03.22 20:39:56 0: CCURPC: Callback server created listening on port 7411
2017.03.22 20:39:56 1: CCURPC: CB2001 Adding callback for events
2017.03.22 20:39:56 1: CCURPC: CB2001 Adding callback for new devices
2017.03.22 20:39:56 1: CCURPC: CB2001 Adding callback for deleted devices
2017.03.22 20:39:56 1: CCURPC: CB2001 Adding callback for modified devices
2017.03.22 20:39:56 1: CCURPC: CB2001 Adding callback for replaced devices
2017.03.22 20:39:56 1: CCURPC: CB2001 Adding callback for readded devices
2017.03.22 20:39:56 1: CCURPC: CB2001 Adding callback for list devices
2017.03.22 20:39:56 1: CCURPC: CB2001 Adding callback for event query
2017.03.22 20:39:56 0: CCURPC: CB2001 Entering server loop
2017.03.22 20:39:56 0: CCURPC: Callback server created listening on port 14702
2017.03.22 20:39:56 1: CCURPC: CB9292 Adding callback for events
2017.03.22 20:39:56 1: CCURPC: CB9292 Adding callback for new devices
2017.03.22 20:39:56 1: CCURPC: CB9292 Adding callback for deleted devices
2017.03.22 20:39:56 1: CCURPC: CB9292 Adding callback for modified devices
2017.03.22 20:39:56 1: CCURPC: CB9292 Adding callback for replaced devices
2017.03.22 20:39:56 1: CCURPC: CB9292 Adding callback for readded devices
2017.03.22 20:39:56 1: CCURPC: CB9292 Adding callback for list devices
2017.03.22 20:39:56 1: CCURPC: CB9292 Adding callback for event query
2017.03.22 20:39:56 0: CCURPC: CB9292 Entering server loop
2017.03.22 20:39:56 0: CCURPC: Callback server created listening on port 7420
2017.03.22 20:39:56 1: CCURPC: CB2010 Adding callback for events
2017.03.22 20:39:56 1: CCURPC: CB2010 Adding callback for new devices
2017.03.22 20:39:56 1: CCURPC: CB2010 Adding callback for deleted devices
2017.03.22 20:39:56 1: CCURPC: CB2010 Adding callback for modified devices
2017.03.22 20:39:56 1: CCURPC: CB2010 Adding callback for replaced devices
2017.03.22 20:39:56 1: CCURPC: CB2010 Adding callback for readded devices
2017.03.22 20:39:56 1: CCURPC: CB2010 Adding callback for list devices
2017.03.22 20:39:56 1: CCURPC: CB2010 Adding callback for event query
2017.03.22 20:39:56 0: CCURPC: CB2010 Entering server loop
2017.03.22 20:39:56 0: RPC server(s) starting
2017.03.22 20:40:02 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2017.03.22 20:40:02 0: HMCCU: Received SL event. RPC server CB2010 enters server loop
2017.03.22 20:40:02 0: HMCCU: Received SL event. RPC server CB9292 enters server loop
2017.03.22 20:40:10 1: HMCCU: Registering callback http://192.168.1.85:7411/fh2001 with ID CB2001 at http://192.168.1.92:2001/
2017.03.22 20:40:10 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.03.22 20:40:10 1: HMCCU: RPC callback with URL http://192.168.1.85:7411/fh2001 initialized
2017.03.22 20:40:10 1: HMCCU: Registering callback http://192.168.1.85:7420/fh2010 with ID CB2010 at http://192.168.1.92:2010/
2017.03.22 20:40:10 1: HMCCU: RPC callback with URL http://192.168.1.85:7420/fh2010 initialized
2017.03.22 20:40:10 1: HMCCU: Registering callback http://192.168.1.85:14702/fh9292 with ID CB9292 at http://192.168.1.92:9292/groups
2017.03.22 20:40:11 1: CCURPC: CB2010 ListDevices. Sending init to HMCCU
2017.03.22 20:40:11 1: CCURPC: CB9292 ListDevices. Sending init to HMCCU
2017.03.22 20:40:11 2: CCURPC: CB2001 NewDevice received 118 device specifications
2017.03.22 20:40:11 2: CCURPC: CB2010 NewDevice received 27 device specifications
2017.03.22 20:40:20 1: HMCCU: RPC callback with URL http://192.168.1.85:14702/fh9292 initialized
2017.03.22 20:40:24 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2017.03.22 20:40:25 0: HMCCU: Received IN event. RPC server CB2010 initialized.
2017.03.22 20:40:25 0: HMCCU: Received IN event. RPC server CB9292 initialized.
2017.03.22 20:40:29 2: HMCCU: Updated devices. Success=14 Failed=0
2017.03.22 20:40:29 1: HMCCU: All RPC servers running
die CCU2 hat jetzt die vers 2.27 - in der Firewall habe ich vorerst Vollzugriff eingestellt
ich hatte jedoch bis gestern die Version 2.25 auf der CCu2 und Fhem hat nach dem update der 88_HMCCU.pm dieses Spielchen auch schon getrieben
ein restart nach dem update, meldet mir, das einige geräte fehlen, auch nach dem ersatz der cfg- werden mir nach einem erneuten restart fehlende Geräte angezeigt
spiele ich die vorangegangene 88_HMCCU.pm wieder ein und copiere wiederum meine komplette fhem.cfg zurück, meldet fhem auch nach dem reboot keine fehlende geräte
woran kann das liegen?
ich habe mal ein list eines der geräte angefügt, welches in der geupdateten version nicht mehr vorhanden ist
Internals:
DEF WZDeckenleuchte
IODev CCU2
NAME WZDeckenleuchte
NR 2335
STATE off
TYPE HMCCUDEV
ccuaddr NEQ1277395
ccudevstate active
ccuif BidCos-RF
ccuname WZDeckenleuchte
ccutype HM-LC-Sw1-FM
channels 2
firmware 2.8
statevals devstate|on|off
Readings:
2017-03-22 21:01:45 0.UNREACH no
2017-03-22 21:01:45 1.STATE off
2017-03-22 21:01:45 control off
2017-03-22 21:01:45 hmstate off
2017-03-22 21:01:45 state off
Hmccu:
Dp:
0.aes_key:
VAL 1
0.config_pending:
VAL false
0.dutycycle:
VAL false
0.lowbat:
VAL false
0.rssi_device:
VAL 1
0.rssi_peer:
VAL 55
0.sticky_unreach:
VAL false
0.unreach:
VAL false
1.inhibit:
VAL false
1.state:
VAL false
1.working:
VAL false
Attributes:
IODev CCU2
alexaName Deckenleuchte
alexaRoom Wohnzimmer
ccureadingfilter (STATE|^UNREACH)
ccureadings 1
controldatapoint 1.STATE
devStateIcon on: FS20.on off: FS20.off
fp_erdgeschoss 360,875,0
genericDeviceType light
group Beleuchtung
icon light_ceiling
room Wohnzimmer,alexa
statechannel 2
statedatapoint 1.STATE
statevals on:1,off:0
stripnumber 1
substitute STATE!(1|true):on,(0|false):off;UNREACH!(true|1):yes,(false|0):no
webCmd statusRequest:toggle:on:off
widgetOverride control:uzsuToggle,off,on
anbei mal das List eines der, nach dem 88_HMCCU.pm update fehlenden gerätes
weiss jemand , was die Ursache sein könnte?
Ich freue mich über jeden Hilfehinweis
gruss tagedieb
Möglicherweise liegt die Ursache in der Definition des IO Device. Wenn der Start von FHEM ungewöhnlich lange dauert, läuft evtl. die Abfrage der aktiven Geräte bei der CCU in einen Timeout. Das ist reproduzierbar,, wenn man get Devicelist aufruft und FHEM daraufhin für einige Minuten blockiert.
In diesem Fall hängt der Rega Prozess auf der CCU und es hilft nur ein Neustart der CCU.
Guten Morgen zap
danke für deine Info
Zitatwenn man get Devicelist aufruft und FHEM daraufhin für einige Minuten blockiert.
get device list geht in der ungeupdateten version schnell und blockiert auch nichts
CCU2 habe ich nach dem CCU update auch neu gestartet, dennoch werden Geräte nach dem update der 88_HMCCU.pm gelöscht und copiere ich die gelöschten wieder in die fhem cfg - fehlen anschliessend andere Geräte - stets im Wechsel
???????
Gruss tagedieb
Hallo zap
nach dem heutigen update ist alles bestens
Dankeschöööööön
ich wünsche einen schönen Tag
gruss tagedieb
Zitat von: mrfloppy am 22 März 2017, 18:16:11
In der Firewall der CCU2 steht "Remote HomeMatic-Script API: auf eingeschrenkt"
Und unten im Feld ist keine Ip eingetragen gewesen.
Bei der Version 2.25.15 war das aber irgendwie kein Problem nur seit 2.27 dürfte
diese Regel eben richtig greifen.
Habe nun meine Ip eingetragen und jetzt geht es.
LG
Danke, damit läuft es jetzt bei mir auch.
VG
Es gibt leider einen Bug in HMCCU. Betroffen sind Heizungsgruppen, d.h. virtuelle Geräte (Interface VirtualDevice).
Leider werden die Readings von Gruppenmitgliedern nicht oder nur sporadisch aktualisiert. Wenn also eine Heizungsgruppe aus einem Wandthermostaten, einem Heizungsthermostaten und einem Fenster besteht, werden nur die Readings der Gruppe und nicht die der Einzelgeräte aktualisiert.
Ich werde den Bug in den nächsten Tagen beheben.
Hallo, zum Thema Jalousienaktor: ich bekomme es nicht hin, bei falsch angeschlossenem up/down das Verhalten per Software "umzudrehen". Insbesondere der level sollte genau anders herum laufen, stateevals, substitue, ccuscaleval, alles spielt eine Rolle. P.S. mit einem userreading konnte ich meinen level "normieren", aber wie kann ich den userreading dem slider (und der level-Anzeige zuordnen?
Zitat von: wolfgang99 am 27 März 2017, 18:51:31
Hallo, zum Thema Jalousienaktor: ich bekomme es nicht hin, bei falsch angeschlossenem up/down das Verhalten per Software "umzudrehen". Insbesondere der level sollte genau anders herum laufen, stateevals, substitue, ccuscaleval, alles spielt eine Rolle. P.S. mit einem userreading konnte ich meinen level "normieren", aber wie kann ich den userreading dem slider (und der level-Anzeige zuordnen?
Hast Du schon folgendes versucht:
ccuscaleval !LEVEL:0:1:0:100
Das Ausrufezeichen sollte das Ergebnis umdrehen.
Mit substitute kannst Du dann z.B. folgendes einstellen:
substitute LEVEL!#0-0:offen,#100-100:geschlossen
Damit wird bei LEVEL=0 state auf offen gesetzt und bei LEVEL=100 auf geschlossen. Alle anderen Zustände werden mit der Prozentzahl angezeigt.
danke, ist ok!
zu früh gefreut: die Ansicht des Levels stimmt zwar,
ccuscaleval = !LEVEL:0:1:0:100
aber als Nebeneffekt ist up und down immer "down", lediglich die Steuerung über Werte zwischen 1 und 99 (für den Level) funktioniert.
als würde eventmap nicht mehr greifen:
eventmap = /datapoint 1.STOP true:stop/datapoint 1.LEVEL 100:down/datapoint 1.LEVEL 0:up/
zig Kombinationen versucht, keine Änderung, also muss ich doch umverdrahten?
Sollte eigentlich so funktionieren. Muss das nochmal testen.
Die Werte werden sollten auch beim Setzen umgedreht werden, d.h.
set datapoint 1.LEVEL 0 => Setzt LEVEL auf 100
set datapoint 1.LEVEL 100 => Setzt LEVEL auf 0
Ab morgen steht ein Update für 88_HMCCU.pm zur Verfügung, das die Probleme bei der Aktualisierung von Gruppen-Devices (virtuelle CCU Geräte) behebt.
Außerdem habe ich 88_HMCCURPC.pm (externer RPC-Server) aktualisiert. Dadurch bleibt der STATE des I/O Devices nach dem Starten des RPC-Servers nicht mehr auf busy stehen.
Zum Thema: Jalousie umgedreht angeschlossen: ich kann jetzt spezifizieren was NICHT geht.
Mit folgender Einstellung ist alles i.O. AUSSER SET 1.LEVEL 0, das wird NICHT gedreht!
Ich behelfe mir, dass ich Nicht auf 0, sondern auf 1,2 fahre, aber das ist keine Lösung.
Ist da eine Änderung mit dem nächsten Update denkbar?
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
define dg_flur_jalousie HMCCUDEV JAL-DG-FLUR
attr dg_flur_jalousie IODev d_ccu
attr dg_flur_jalousie ccureadingfilter (LEVEL|INHIBIT|DIRECTION|WORKING)
attr dg_flur_jalousie ccuscaleval !LEVEL:0:1:0:100
attr dg_flur_jalousie cmdIcon up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down
attr dg_flur_jalousie controldatapoint 1.LEVEL
attr dg_flur_jalousie eventMap /datapoint 1.STOP true:stop/datapoint 1.LEVEL 98:down/datapoint 1.LEVEL 2:up/
attr dg_flur_jalousie group Jalousien
attr dg_flur_jalousie icon fts_shutter_1w
attr dg_flur_jalousie room 40_Jalousien,30_DG
attr dg_flur_jalousie statedatapoint 1.LEVEL
attr dg_flur_jalousie stripnumber 1
attr dg_flur_jalousie substexcl control
attr dg_flur_jalousie substitute LEVEL!#96-100:unten,#0-4:oben;;DIRECTION!0:none,1:auf,2:ab,3:undefined;;WORKING!(0|false):no,(1|true):yes
attr dg_flur_jalousie webCmd control:up:stop:down
attr dg_flur_jalousie widgetOverride control:slider,0,1,100
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hallo,
ich bin gerade dabei, die Batterieanzeige anzeigen zu lassen. Aber irgendwie bekomme ich von meinem einen HM Thermostat kein Reading "LOWBAT" zurück.
Bei anderen geht es komischerweise.
Jemand eine Idee?
Anbei mal ein List:
Internals:
CHANGED
DEF LEQ1076581
IODev CCU2
NAME HM_DI_Thermostat
NR 256
STATE T: R-Diele.4.ACTUAL_TEMPERATURE° D: R-Diele.4.SET_TEMPERATURE° V: R-Diele.4.VALVE_STATE%
TYPE HMCCUDEV
ccuaddr LEQ1076581
ccudevstate active
ccuif BidCos-RF
ccuname Diele
ccutype HM-CC-RT-DN
channels 7
firmware 1.3
statevals devstate
Readings:
2017-04-02 14:21:33 HM-CC-RT-DN_LEQ1076581.4.ACTUAL_TEMPERATURE 20.8
2017-04-02 14:21:33 HM-CC-RT-DN_LEQ1076581.4.CONTROL_MODE MANU
2017-04-02 14:21:33 HM-CC-RT-DN_LEQ1076581.4.PARTY_TEMPERATURE 5.0
2017-04-02 14:21:33 HM-CC-RT-DN_LEQ1076581.4.SET_TEMPERATURE 19.0
2017-04-02 14:21:33 HM-CC-RT-DN_LEQ1076581.4.VALVE_STATE 0
2017-04-02 13:51:43 R-Diele.ADAPTIVE_REGULATION 2
2017-04-02 13:51:43 R-Diele.BACKLIGHT_ON_TIME 10
2017-04-02 13:51:43 R-Diele.BOOST_AFTER_WINDOW_OPEN 0
2017-04-02 13:51:43 R-Diele.BOOST_POSITION 80
2017-04-02 13:51:43 R-Diele.BOOST_TIME_PERIOD 1
2017-04-02 13:51:43 R-Diele.BURST_RX 1
2017-04-02 13:51:43 R-Diele.BUTTON_LOCK 0
2017-04-02 13:51:43 R-Diele.BUTTON_RESPONSE_WITHOUT_BACKLIGHT 0
2017-04-02 13:51:43 R-Diele.CYCLIC_INFO_MSG 1
2017-04-02 13:51:43 R-Diele.CYCLIC_INFO_MSG_DIS 0
2017-04-02 13:51:43 R-Diele.DAYLIGHT_SAVING_TIME 1
2017-04-02 13:51:43 R-Diele.DECALCIFICATION_TIME 660
2017-04-02 13:51:43 R-Diele.DECALCIFICATION_WEEKDAY 0
2017-04-02 13:51:43 R-Diele.DISPLAY_INFORMATION 0
2017-04-02 13:51:43 R-Diele.ENDTIME_FRIDAY_1 360
2017-04-02 13:51:43 R-Diele.ENDTIME_FRIDAY_10 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_FRIDAY_11 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_FRIDAY_12 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_FRIDAY_13 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_FRIDAY_2 540
2017-04-02 13:51:43 R-Diele.ENDTIME_FRIDAY_3 1020
2017-04-02 13:51:43 R-Diele.ENDTIME_FRIDAY_4 1320
2017-04-02 13:51:43 R-Diele.ENDTIME_FRIDAY_5 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_FRIDAY_6 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_FRIDAY_7 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_FRIDAY_8 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_FRIDAY_9 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_MONDAY_1 360
2017-04-02 13:51:43 R-Diele.ENDTIME_MONDAY_10 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_MONDAY_11 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_MONDAY_12 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_MONDAY_13 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_MONDAY_2 540
2017-04-02 13:51:43 R-Diele.ENDTIME_MONDAY_3 1020
2017-04-02 13:51:43 R-Diele.ENDTIME_MONDAY_4 1320
2017-04-02 13:51:43 R-Diele.ENDTIME_MONDAY_5 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_MONDAY_6 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_MONDAY_7 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_MONDAY_8 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_MONDAY_9 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SATURDAY_1 360
2017-04-02 13:51:43 R-Diele.ENDTIME_SATURDAY_10 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SATURDAY_11 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SATURDAY_12 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SATURDAY_13 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SATURDAY_2 1320
2017-04-02 13:51:43 R-Diele.ENDTIME_SATURDAY_3 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SATURDAY_4 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SATURDAY_5 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SATURDAY_6 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SATURDAY_7 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SATURDAY_8 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SATURDAY_9 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SUNDAY_1 360
2017-04-02 13:51:43 R-Diele.ENDTIME_SUNDAY_10 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SUNDAY_11 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SUNDAY_12 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SUNDAY_13 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SUNDAY_2 1320
2017-04-02 13:51:43 R-Diele.ENDTIME_SUNDAY_3 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SUNDAY_4 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SUNDAY_5 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SUNDAY_6 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SUNDAY_7 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SUNDAY_8 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_SUNDAY_9 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_THURSDAY_1 360
2017-04-02 13:51:43 R-Diele.ENDTIME_THURSDAY_10 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_THURSDAY_11 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_THURSDAY_12 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_THURSDAY_13 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_THURSDAY_2 540
2017-04-02 13:51:43 R-Diele.ENDTIME_THURSDAY_3 1020
2017-04-02 13:51:43 R-Diele.ENDTIME_THURSDAY_4 1320
2017-04-02 13:51:43 R-Diele.ENDTIME_THURSDAY_5 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_THURSDAY_6 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_THURSDAY_7 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_THURSDAY_8 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_THURSDAY_9 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_TUESDAY_1 360
2017-04-02 13:51:43 R-Diele.ENDTIME_TUESDAY_10 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_TUESDAY_11 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_TUESDAY_12 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_TUESDAY_13 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_TUESDAY_2 540
2017-04-02 13:51:43 R-Diele.ENDTIME_TUESDAY_3 1020
2017-04-02 13:51:43 R-Diele.ENDTIME_TUESDAY_4 1320
2017-04-02 13:51:43 R-Diele.ENDTIME_TUESDAY_5 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_TUESDAY_6 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_TUESDAY_7 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_TUESDAY_8 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_TUESDAY_9 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_WEDNESDAY_1 360
2017-04-02 13:51:43 R-Diele.ENDTIME_WEDNESDAY_10 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_WEDNESDAY_11 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_WEDNESDAY_12 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_WEDNESDAY_13 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_WEDNESDAY_2 540
2017-04-02 13:51:43 R-Diele.ENDTIME_WEDNESDAY_3 1020
2017-04-02 13:51:43 R-Diele.ENDTIME_WEDNESDAY_4 1320
2017-04-02 13:51:43 R-Diele.ENDTIME_WEDNESDAY_5 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_WEDNESDAY_6 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_WEDNESDAY_7 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_WEDNESDAY_8 1440
2017-04-02 13:51:43 R-Diele.ENDTIME_WEDNESDAY_9 1440
2017-04-02 13:51:43 R-Diele.GLOBAL_BUTTON_LOCK 0
2017-04-02 13:51:43 R-Diele.I_VALUE_EXTERN 15
2017-04-02 13:51:43 R-Diele.I_VALUE_INTERN 18
2017-04-02 13:51:43 R-Diele.LOCAL_RESET_DISABLE 0
2017-04-02 13:51:43 R-Diele.LOW_BAT_LIMIT 2.1
2017-04-02 13:51:43 R-Diele.MANU_MODE_PRIORITIZATION 1
2017-04-02 13:51:43 R-Diele.MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE 0
2017-04-02 13:51:43 R-Diele.MODUS_BUTTON_LOCK 0
2017-04-02 13:51:43 R-Diele.PARTY_MODE_PRIORITIZATION 1
2017-04-02 13:51:43 R-Diele.P_START_VALUE_EXTERN 30
2017-04-02 13:51:43 R-Diele.P_START_VALUE_INTERN 45
2017-04-02 13:51:43 R-Diele.P_VALUE_EXTERN 30
2017-04-02 13:51:43 R-Diele.P_VALUE_INTERN 33
2017-04-02 13:51:43 R-Diele.SHOW_WEEKDAY 0
2017-04-02 13:51:43 R-Diele.TEMPERATUREFALL_MODUS 0
2017-04-02 13:51:43 R-Diele.TEMPERATUREFALL_VALUE 1.4
2017-04-02 13:51:43 R-Diele.TEMPERATUREFALL_WINDOW_OPEN 12.0
2017-04-02 13:51:43 R-Diele.TEMPERATUREFALL_WINDOW_OPEN_TIME_PERIOD 15
2017-04-02 13:51:43 R-Diele.TEMPERATURE_COMFORT 21.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_FRIDAY_1 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_FRIDAY_10 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_FRIDAY_11 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_FRIDAY_12 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_FRIDAY_13 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_FRIDAY_2 21.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_FRIDAY_3 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_FRIDAY_4 21.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_FRIDAY_5 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_FRIDAY_6 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_FRIDAY_7 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_FRIDAY_8 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_FRIDAY_9 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_LOWERING 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MAXIMUM 30.5
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MINIMUM 4.5
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MONDAY_1 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MONDAY_10 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MONDAY_11 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MONDAY_12 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MONDAY_13 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MONDAY_2 21.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MONDAY_3 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MONDAY_4 21.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MONDAY_5 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MONDAY_6 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MONDAY_7 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MONDAY_8 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_MONDAY_9 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_OFFSET 7
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SATURDAY_1 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SATURDAY_10 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SATURDAY_11 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SATURDAY_12 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SATURDAY_13 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SATURDAY_2 21.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SATURDAY_3 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SATURDAY_4 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SATURDAY_5 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SATURDAY_6 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SATURDAY_7 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SATURDAY_8 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SATURDAY_9 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SUNDAY_1 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SUNDAY_10 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SUNDAY_11 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SUNDAY_12 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SUNDAY_13 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SUNDAY_2 21.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SUNDAY_3 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SUNDAY_4 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SUNDAY_5 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SUNDAY_6 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SUNDAY_7 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SUNDAY_8 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_SUNDAY_9 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_THURSDAY_1 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_THURSDAY_10 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_THURSDAY_11 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_THURSDAY_12 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_THURSDAY_13 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_THURSDAY_2 21.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_THURSDAY_3 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_THURSDAY_4 21.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_THURSDAY_5 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_THURSDAY_6 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_THURSDAY_7 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_THURSDAY_8 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_THURSDAY_9 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_TUESDAY_1 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_TUESDAY_10 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_TUESDAY_11 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_TUESDAY_12 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_TUESDAY_13 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_TUESDAY_2 21.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_TUESDAY_3 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_TUESDAY_4 21.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_TUESDAY_5 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_TUESDAY_6 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_TUESDAY_7 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_TUESDAY_8 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_TUESDAY_9 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_WEDNESDAY_1 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_WEDNESDAY_10 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_WEDNESDAY_11 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_WEDNESDAY_12 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_WEDNESDAY_13 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_WEDNESDAY_2 21.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_WEDNESDAY_3 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_WEDNESDAY_4 21.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_WEDNESDAY_5 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_WEDNESDAY_6 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_WEDNESDAY_7 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_WEDNESDAY_8 17.0
2017-04-02 13:51:43 R-Diele.TEMPERATURE_WEDNESDAY_9 17.0
2017-04-02 13:51:43 R-Diele.VALVE_ERROR_RUN_POSITION 15
2017-04-02 13:51:43 R-Diele.VALVE_MAXIMUM_POSITION 100
2017-04-02 13:51:43 R-Diele.VALVE_OFFSET 0
2017-04-02 14:21:33 control 19.0
2017-04-02 14:21:35 hmstate 19.0
2017-04-02 14:21:33 state 19.0
Hmccu:
Dp:
4.actual_temperature:
VAL 20.800000
4.battery_state:
VAL 3.000000
4.boost_state:
VAL 0
4.control_mode:
VAL 1
4.fault_reporting:
VAL 0
4.party_start_day:
VAL 1
4.party_start_month:
VAL 1
4.party_start_time:
VAL 0
4.party_start_year:
VAL 0
4.party_stop_day:
VAL 1
4.party_stop_month:
VAL 1
4.party_stop_time:
VAL 0
4.party_stop_year:
VAL 0
4.party_temperature:
VAL 5.000000
4.set_temperature:
VAL 19.000000
4.valve_state:
VAL 0
Attributes:
IODev CCU2
ccureadingfilter (LOWBAT|TEMPERATURE|VALVE_STATE|CONTROL)
ccureadingformat name
controldatapoint 4.SET_TEMPERATURE
event-on-change-reading .*
room Diele
stateFormat T: R-Diele.4.ACTUAL_TEMPERATURE° D: R-Diele.4.SET_TEMPERATURE° V: R-Diele.4.VALVE_STATE%
statechannel 4
statedatapoint SET_TEMPERATURE
stripnumber 1
substitute LOWBAT!(0|false):no,(1|true):yes;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST
webCmd control
widgetOverride control:slider,10,1,25
Mach mal ein "get update" für das Thermostat. Wird dann "battery" oder "LOWBAT" angezeigt?
Ansonsten: Hast Du im I/O Device das Attribut ccudef-readingfilter gesetzt?
BTW: Dein stateformat ist falsch, daher werden in STATE keine Werte angezeigt.
ZitatMach mal ein "get update" für das Thermostat. Wird dann "battery" oder "LOWBAT" angezeigt?
Hi zap,
get update liefert:
HMCCUDEV: HM_DI_Thermostat No readable datapoints foundZitatAnsonsten: Hast Du im I/O Device das Attribut ccudef-readingfilter gesetzt?
Ja, auch das habe ich gesetzt.
Anbei nochmal meine Definition.
define HM_DI_Thermostat HMCCUDEV LEQ1076581
attr HM_DI_Thermostat IODev CCU2
attr HM_DI_Thermostat ccureadingfilter (LOWBAT|TEMPERATURE|VALVE_STATE|CONTROL)
attr HM_DI_Thermostat ccureadingformat name
attr HM_DI_Thermostat controldatapoint 4.SET_TEMPERATURE
attr HM_DI_Thermostat event-on-change-reading .*
attr HM_DI_Thermostat room Diele
attr HM_DI_Thermostat stateFormat T: R-Diele.4.ACTUAL_TEMPERATURE° D: R-Diele.4.SET_TEMPERATURE° V: R-Diele.4.VALVE_STATE%
attr HM_DI_Thermostat statechannel 4
attr HM_DI_Thermostat statedatapoint SET_TEMPERATURE
attr HM_DI_Thermostat stripnumber 1
attr HM_DI_Thermostat substitute LOWBAT!(0|false):no,(1|true):yes;;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST
attr HM_DI_Thermostat webCmd control
attr HM_DI_Thermostat widgetOverride control:slider,10,1,25VG, Thomas
was ist mit "get deviceinfo"? Geht das?
Zitatwas ist mit "get deviceinfo"? Geht das?
get deviceinfo liefert auch einen Fehler:
HMCCUDEV: HM_DI_Thermostat Execution of CCU script or command failedKomischerweise werden aber die Readings wie
aktuelle Temperatur aktualisiert
Firewall Einstellungen der CCU nach Update auf 2.27 angepasst?
Ich verwende aktuell noch V2.25.15
Ok, setzte für das Thermostat Device das Attribut ccuflags auf trace, führe get update nochmal aus und poste dann die Logfile Einträge
Hi,
ich bekomme seit dem heutigen Update das hier:
Error evaluating Wandthermostat userReading DEWPOINT: Undefined subroutine &main::HMCCU_Dewpoint called at (eval 704) line 1.
Gibt es die Routine nicht mehr? Hab ich was verpasst?
Mein userReading lautet so:
userReadings
DEWPOINT {HMCCU_Dewpoint($name,"1.TEMPERATURE", "1.HUMIDITY","n/a")}
ZitatOk, setzte für das Thermostat Device das Attribut ccuflags auf trace, führe get update nochmal aus und poste dann die Logfile Einträge
Hallo zap, anbei der Log-Eintrag.
2017.04.02 20:43:35 2: HMCCU: Addr=LEQ1076581 Name=Diele
2017.04.02 20:43:35 2: HMCCU: Script response =
0
2017.04.02 20:43:35 2: HMCCU: Script =
string chnid;
string sDPId;
string sDevName;
string sDevList = "Diele";
integer c = 0;
foreach (sDevName, sDevList.Split(",")) {
object odev = dom.GetObject (sDevName);
if (odev) {
foreach (chnid, odev.Channels()) {
object ochn = dom.GetObject(chnid);
if (ochn) {
foreach(sDPId, ochn.DPs()) {
object oDP = dom.GetObject(sDPId);
if (oDP) {
if (OPERATION_READ & oDP.Operations()) {
WriteLine (ochn.Name() # "=" # oDP.Name() # "=" # oDP.Value());
c = c+1;
}
}
}
}
}
}
}
WriteLine (c);
2017.04.02 20:43:35 1: HMCCUDEV: HM_DI_Thermostat No readable datapoints found
Ich vermute mal, der Name Diele kommt in der CCU mehrfach vor, zB als Raum.
Die Script Funktion GetObject macht leider keinen Unterschied. Für die ist alles ein Objekt, egal ob Gerät oder Raum.
Wenn dem so ist, dem Gerät einen eindeutigen Namen geben, get Devicelist ausführen und Device am besten neu definieren.
ZitatIch vermute mal, der Name Diele kommt in der CCU mehrfach vor, zB als Raum.
Hallo Zap,
Laut CCU lautet der Name
HM-CC-RT-DN LEQ1076581:4.
In FHEM steht aber bei den Internals des Thermostats
ccuname Diele.
Dies steht so aber bei dem Thermostat in der Küche auch. Dort steht dann eben
ccuname Kueche. Und dieser Name ist auch als Raum in der CCU vergeben.
Irgendwie verwirrend.
Habe auch keinen Punkt in der CCU-Weboberfläche finden können wo ich das Thermostat umbenennen könnte.
VG, Thomas
Zitat von: aski71 am 02 April 2017, 20:40:14
Hi,
ich bekomme seit dem heutigen Update das hier:
Error evaluating Wandthermostat userReading DEWPOINT: Undefined subroutine &main::HMCCU_Dewpoint called at (eval 704) line 1.
Gibt es die Routine nicht mehr? Hab ich was verpasst?
Mein userReading lautet so:
userReadings
DEWPOINT {HMCCU_Dewpoint($name,"1.TEMPERATURE", "1.HUMIDITY","n/a")}
Hallo Zap,
nachdem ich nun heute erneut upgedated habe, zusätzlich zu obigem Problem noch folgendes:
Das erste Gerät, das mit HMCCUDEV konfiguriert ist, liefert folgenden Fehler:
define Vitrine HMCCUDEV W-Vitrine: Invalid or unknown CCU device name or addressAlle weiteren Geräte, die in der fhem.cfg danach stehen, werden einwandfrei erkannt.
Das Gerät W-Vitrine hat vor dem Update auch funktioniert.
Weitere Diagnose: Ich habe statt "W-Vitrine" die Geräte-Seriennummer für's define verwendet. Dann war die Vitrine wieder da, aber das nächste HMCCUDEV Gerät in der fhem.cfg nicht mehr. :o
Jetzt habe ich alle defines auf die Seriennummer abgeändert, statt den symbolischen Namen: Kein Problem mehr.
Offensichtlich hat sich da der Fehlerteufel eingeschlichen.
Kannst Du noch was zu ersterem Problem mit dem DEWPOINT sagen?
Danke und Gruß
Alex
Zitat von: aski71 am 02 April 2017, 20:40:14
Gibt es die Routine nicht mehr? Hab ich was verpasst?
Ich nehme an, das war das erste Update seit längerem. HMCCU_Dewpoint() existiert nicht mehr. Bitte schau Dir mal die Doku HMCCUCHN und dem Attribut ccucalculate an. Taupunkt und absolute Feuchtigkeit können jetzt direkt (ohne Userreading) berechnet werden.
Zum anderen Problem: irgendwie scheint sich da ein Fehler in die Verwaltung der Devicenames eingeschlichen zu haben. Muss ich mir anschauen.
Zitat von: zap am 03 April 2017, 12:04:37
Ich nehme an, das war das erste Update seit längerem. HMCCU_Dewpoint() existiert nicht mehr. Bitte schau Dir mal die Doku HMCCUCHN und dem Attribut ccucalculate an. Taupunkt und absolute Feuchtigkeit können jetzt direkt (ohne Userreading) berechnet werden.
Zum anderen Problem: irgendwie scheint sich da ein Fehler in die Verwaltung der Devicenames eingeschlichen zu haben. Muss ich mir anschauen.
Du nimmst richtig an. :D
Danke, habe jetzt nachgesehen und wiefolgt eingerichtet:
attr Wandthermostat ccucalculate dewpoint:DEWPOINT,1.TEMPERATURE:1.HUMIDITYDas userReading habe ich rausgenommen.
Leider ohne Effekt. :( Das Reading DEWPOINT bleibt auf der Fehlermeldung stehen.
Habe bereits rpcserver mal gestoppt und gestartet und auch fhem gestoppt und gestartet.
Was mach ich falsch?
Zitat von: aski71 am 03 April 2017, 12:47:21
Du nimmst richtig an. :D
Danke, habe jetzt nachgesehen und wiefolgt eingerichtet:
attr Wandthermostat ccucalculate dewpoint:DEWPOINT,1.TEMPERATURE:1.HUMIDITY
Das userReading habe ich rausgenommen.
Leider ohne Effekt. :( Das Reading DEWPOINT bleibt auf der Fehlermeldung stehen.
Habe bereits rpcserver mal gestoppt und gestartet und auch fhem gestoppt und gestartet.
Was mach ich falsch?
ARGH! Selber gesehen. :o
Manchmal sitzt man echt auf den Augen.
Muss natürlich so heißen:
attr Wandthermostat ccucalculate dewpoint:DEWPOINT[b]:[/b]1.TEMPERATURE[b],[/b]1.HUMIDITYJetzt geht's wieder.
Zitat von: ToM_ToM am 03 April 2017, 08:43:49
Hallo Zap,
Laut CCU lautet der Name HM-CC-RT-DN LEQ1076581:4.
In FHEM steht aber bei den Internals des Thermostats ccuname Diele.
Dies steht so aber bei dem Thermostat in der Küche auch. Dort steht dann eben ccuname Kueche. Und dieser Name ist auch als Raum in der CCU vergeben.
Irgendwie verwirrend.
Habe auch keinen Punkt in der CCU-Weboberfläche finden können wo ich das Thermostat umbenennen könnte.
VG, Thomas
Also irgendwas ist an Deiner Konfiguration verbogen. Bei mir stehen in allen Devices im Internal ccuname die korrekten Namen aus der CCU.
Hast Du nach dem letzten FHEM/HMCCU Update FHEM neu gestartet? Das wäre wichtig, da sich in einer der letzten HMCCU Versionen der Aufbau des internen Hashes geändert hat, in dem die Namen und Adressen der CCU-Geräte gespeichert werden.
ZitatHast Du nach dem letzten FHEM/HMCCU Update FHEM neu gestartet? Das wäre wichtig, da sich in einer der letzten HMCCU Versionen der Aufbau des internen Hashes geändert hat, in dem die Namen und Adressen der CCU-Geräte gespeichert werden.
Hi zap,
ja ich mache nach jedem Update einen Neustart von FHEM. Vor dem Neustart stoppe ich auch immer den RPCServer.
Anbei nochmal meine CCU - Definition:
define CCU2 HMCCU 192.168.178.42
attr CCU2 ccudef-readingfilter .*
attr CCU2 ccureadings 0
attr CCU2 devStateIcon (OK|Initialized):10px-kreis-gruen Error:10px-kreis-rot
attr CCU2 event-on-change-reading .*
attr CCU2 icon rc_HOME
attr CCU2 rpcinterfaces BidCos-RF,HmIP-RF
attr CCU2 rpcinterval 1
attr CCU2 rpcport 2001,2010
attr CCU2 rpcserver on
attr CCU2 stateFormat { $defs{$name}{RPCState} }
attr CCU2 stripchar :
attr CCU2 stripnumber 1
attr CCU2 verbose 2
Das ist nicht das Problem. In ccuname steht der falsche Name drin ("Diele") und auch im Dump von dem get update script taucht "Diele" auf. Das heißt, dass aus irgendwelchen Gründen HMCCU die Adresse nicht zum korrekten Namen auflöst.
Da geht vermutlich schon get devicelist schief.
Hallo Zap,
ich habe jetzt doch mal das CCU-Update durchgeführt auf die aktuelle Version durchgeführt und jetzt funktioniert es. :) Vielleicht hätte ich gleich mal ein Update ausführen sollen.
Vielen Dank für deine Unterstützung.
kurze rm: hmip-ps funktioniereb sauber! ;)
eine frage: bei den ccu programmen für einschaltdauer - sind die zeitangaben in s sekunden richtig? welchen wert kann ich dort max vergeben?
Ich weiß jetzt gerade nicht, worauf sich die Frage bezieht
in der ccu kann man ja eingene programme erstellen und gerät zb für eine bestimmte dauer einschalten (quasi on for timer). per klicken geht der wert max auf 100s setzen. ich würde gerne wissen was der max-wert sein kann. per hand kann man mehr eintragen
Die EQ-3 Doku zu Homematic Datenpunkten ist dein Freund:
http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/hm_devices_Endkunden.pdf
Vermutlich wird der Datenpunkt ON_TIME gesetzt. Hier mal ein Auszug aus der Doku für ein HM-LC-AO-SM (such einfach nach deinem Gerätetyp)
Parameter ON_TIME
Typ: float
Zugriffsart: schreibend
Minimaler Wert: 0.0
Maximaler Wert: 85825945.6
Standardwert: 0.0
Einheit: s
Zitat von: zap am 08 April 2017, 16:52:32
Maximaler Wert: 85825945.6
27jahre... sollte reichen, Danke!
Hallo,
ich habe heute ein neues Device angemeldet HmIP-STHD (also ein Thermostat wie WTH-2, nur ohne Stellrad).
Soweit läuft alles, die Konfig ist komplett analog zum WTH-2, alle Datenpunkte etc sind (soweit ich das sehe) 100% identisch.
Wen es interessiert, hier die Datenpunkte:
CHN 000E9569A2410C:0 Thermostat-Schlafzimmer:0
DPT {b} HmIP-RF.000E9569A2410C:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.000E9569A2410C:0.DUTY_CYCLE = false [RE]
DPT {b} HmIP-RF.000E9569A2410C:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.000E9569A2410C:0.OPERATING_VOLTAGE = 3.000000 [RE]
DPT {n} HmIP-RF.000E9569A2410C:0.RSSI_DEVICE = 202 [RE]
DPT {n} HmIP-RF.000E9569A2410C:0.RSSI_PEER = 210 [RE]
DPT {b} HmIP-RF.000E9569A2410C:0.UNREACH = false [RE]
DPT {b} HmIP-RF.000E9569A2410C:0.UPDATE_PENDING = false [RE]
CHN 000E9569A2410C:1 HmIP-STHD 000E9569A2410C:1
DPT {i} HmIP-RF.000E9569A2410C:1.ACTIVE_PROFILE = 1 [WE]
DPT {f} HmIP-RF.000E9569A2410C:1.ACTUAL_TEMPERATURE = 22.700000 [RE]
DPT {b} HmIP-RF.000E9569A2410C:1.BOOST_MODE = false [WE]
DPT {f} HmIP-RF.000E9569A2410C:1.CONTROL_DIFFERENTIAL_TEMP = [WE]
DPT {i} HmIP-RF.000E9569A2410C:1.CONTROL_MODE = [WE]
DPT {i} HmIP-RF.000E9569A2410C:1.DURATION_UNIT = [W]
DPT {i} HmIP-RF.000E9569A2410C:1.DURATION_VALUE = [W]
DPT {b} HmIP-RF.000E9569A2410C:1.FROST_PROTECTION = false [RE]
DPT {i} HmIP-RF.000E9569A2410C:1.HEATING_COOLING = 0 [RWE]
DPT {i} HmIP-RF.000E9569A2410C:1.HUMIDITY = 34 [RE]
DPT {b} HmIP-RF.000E9569A2410C:1.PARTY_MODE = false [RE]
DPT {f} HmIP-RF.000E9569A2410C:1.PARTY_SET_POINT_TEMPERATU = 0.000000 [RE]
DPT {s} HmIP-RF.000E9569A2410C:1.PARTY_TIME_END = [RWE]
DPT {s} HmIP-RF.000E9569A2410C:1.PARTY_TIME_START = [RWE]
DPT {i} HmIP-RF.000E9569A2410C:1.SET_POINT_MODE = 0 [RWE]
DPT {f} HmIP-RF.000E9569A2410C:1.SET_POINT_TEMPERATURE = 21.000000 [RWE]
DPT {b} HmIP-RF.000E9569A2410C:1.SWITCH_POINT_OCCURED = false [RE]
DPT {i} HmIP-RF.000E9569A2410C:1.WINDOW_STATE = 0 [WE]
@Zap: 2 Kleinigkeiten:
Was fehlt:
Bei den "Internals" fehlt der Eintrag Firmware (warum auch immer).
Im Log bei Aufruf "Set Defaults"
2017.04.28 17:56:27 1: HMCCUDEV: HM_Thermostat_Schlafzimmer HMCCU: No default attributes found
Use of uninitialized value $wert in numeric lt (<) at (eval 14562) line 1.
Viele Grüße
Christian
Update: ich habe noch einen weiteren Fensterkontakt angemeldet. Firmware fehlt ebenfalls, die Fehlermeldung im Log taucht auch 1x auf (hat aber doch nichts mit dem Set Defaults zu tun. Kam irgendwann während des Anmeldeprozesses.
In der neuen Funktion "Get CCU Firmware" taucht der Kontakt auch nicht auf.
Das Internal firmware wird nur beim Start des RPC Servers initialisiert, da nur dann die CCU diese Information per NewDevice Event an HMCCU schickt.
Der Fehler ist seltsam. Ich verwende normalerweise keine deutschen Variablennamen.
Hallo Zap,
nach Stop&Start des RPC-Servers sind die Readings da, in der Firmwarelist "Update" dann ebenfalls.
Viele Grüße
Christian
Update: Noch ein Hinweis: Beim get CCU deviceliste create HM-Fensterkontakt t=dev f=HM_Fensterkontakt room=Heizung
wurde das neue Device ohne Raum angelegt. Habe ich das Kommando falsch angegeben?
Nach dem heutigen Update startet mein FHEM nicht mehr.
2017.05.02 08:08:20 1: reload: Error:Modul 88_HMCCU deactivated:
Global symbol "$name" requires explicit package name at ./FHEM/88_HMCCU.pm line 2154, <$fh> line 99.
2017.05.02 08:08:20 0: Global symbol "$name" requires explicit package name at ./FHEM/88_HMCCU.pm line 2154, <$fh> line 99.
2017.05.02 08:08:21 1: define CCU2_rpc HMCCURPC 10.0.0.82: Can't find HMCCU I/O device
Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 141, <$fh> line 1039.
nach dem zurückspielen der 88_HMCCU.pm kann ich wieder normal starten.
Mist. Einmal FHEM nach Änderungen und vor dem Einchecken ins Repository nicht neu gestartet und schon einen Bug drin.
Ich korrigiere das und checke gleich ein Update ein. Also momentan bitte nicht das Modul updaten!
So, das Update von 88_HMCCU.pm (Version 4.0.004) ist im SVN und sollte morgen zur Verfügung stehen.
Hi,
ich habe ein seltsames Phänomen bei der Einbindung der HmIP-RC8.
Die Fernbedienung habe ich als HMCCUDEV angelegt, was auch soweit funktioniert. Allerdings wurden die diversen Kanäle nicht mit eingebunden, so dass ich auf die unterschiedlichen Tastendrücke nicht reagieren kann. Mit get deviceinfo werden aber alle Kanäle angezeigt.
Woran könnte das u.U. liegen?
Jede Taste einzeln per HMCCUCHN einzubinden, erscheint mir etwas von hinten durch die Brust.
Hab zuhause derzeit leider kein Internet, somit habe ich die Ausgaben nicht zur Hand.
Viele Grüße,
kjmEjfu
Bei Fernbedienungen oder auch bei Displays und Tastern sind die Datenpunkte PRESS_* meist rein Event gesteuert. Das erkennt man daran, dass bei "get deviceinfo" hinter diesen Datenpunkten nur W und/oder E, aber kein R angezeigt wird.
Ein Test per manuellem Update der Kanäle mit dem Befehl "get update" bringt aber nur etwas, wenn es auch lesbare Datenpunkte (R) gibt.
In Deinem Fall gehe ich davon aus, dass die CCU keine Events für Tastendrücke generiert. Da hilft auch keine Definition der Kanäle mit HMCCUCHN. Das liegt an einer Eigenart der CCU, die für einige Taster/Fernbedienungen nur dann ein Event generiert, wenn mit dem jeweiligen Kanal ein Aktor oder ein CCU-Programm verknüpf ist.
Du solltest also in der CCU ein Dummy Programm anlegen, das die einzelnen Tasten abfragt und als Reaktion darauf z.B. eine CCU Systemvariable auf irgendeinen Wert setzt. Mein entsprechendes Programm sieht ungefähr so aus:
Wenn "Geräteauswahl" KanalAB:1 "bei" Tastendruck kurz
Oder "Geräteauswahl" KanalAB:2 "bei" Tastendruck kurz
...
Aktivität Dann "Systemzustand" meineVar "sofort" true
Vorher muss natürlich eine Systemvariable "meineVar" vom Typ Bool angelegt werden.
mit dem Update von Heute kam fhem funktionierte nach einen Restart nichts mehr und ich habe das backup wieder eingespielt.
Folgendes habe ich im Log gefunden:
Zitat2017.05.02 18:40:49.229 1: HMCCURPC: RPC callback for server CB2001 deregistered
2017.05.02 18:40:49.229 2: HMCCURPC: Sending signal INT to thread CB2001 TID=2
2017.05.02 18:40:50.228 2: CCURPC: RPC server CB2001 stopped handling connections. TID=2
2017.05.02 18:40:50.231 1: HMCCURPC: Found 1 threads. Stopping ...
2017.05.02 18:40:53 1: PERL WARNING: Prototype mismatch: sub main::max ($@) vs (@) at /usr/share/perl/5.20/Exporter.pm line 66.
2017.05.02 18:40:53 2: Perfmon: ready to watch out for delays greater than one second
2017.05.02 18:40:53.630 2: eventTypes: loaded 2824 events from ./log/eventTypes.txt
2017.05.02 18:40:53.766 1: reload: Error:Modul 88_HMCCU deactivated:
Global symbol "$name" requires explicit package name at ./FHEM/88_HMCCU.pm line 2154.
2017.05.02 18:40:53.766 0: Global symbol "$name" requires explicit package name at ./FHEM/88_HMCCU.pm line 2154.
Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 141.
2017.05.02 18:42:19 1: PERL WARNING: Prototype mismatch: sub main::max ($@) vs (@) at /usr/share/perl/5.20/Exporter.pm line 66.
2017.05.02 18:42:19 2: Perfmon: ready to watch out for delays greater than one second
2017.05.02 18:42:19.438 2: eventTypes: loaded 2824 events from ./log/eventTypes.txt
2017.05.02 18:42:19.561 1: reload: Error:Modul 88_HMCCU deactivated:
Global symbol "$name" requires explicit package name at ./FHEM/88_HMCCU.pm line 2154.
2017.05.02 18:42:19.561 0: Global symbol "$name" requires explicit package name at ./FHEM/88_HMCCU.pm line 2154.
Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 141.
Mit der Version 4.0.004 aus dem svn startet FHEM bei mir wieder.
Siehe ein paar Beiträge weiter oben, die 4.0.003 hatte enen Bug. Die 004 gibt es morgen per update oder eben sofort per SVN download
Wie komme ich an das Update? Tante Google war nicht sehr ergiebig.
Bei mir läuft FHEM nämlich auch nicht mehr.
Entweder Du machst ein recover, startest danach FHEM und machst ein reguläres update.
Oder Du gehst auf die Seite https://svn.fhem.de/trac/browser/trunk/fhem/FHEM
Dort suchst Du den Eintrag 88_HMCCU.pm und lädtst die Datei per Klick auf das Pfeil nach unten Symbol herunter.
Die heruntergeladene Datei kopierst Du in das Verzeichnis /opt/fhem/FHEM/.
Danach sollte FHEM starten.
Vielen Dank für die schnelle Hilfe!
Der Download hat zwar geklappt, aber der Fehler ist geblieben.
Habe dann eine ältere Version aus einem Backup genommen und mit dieser funktioniert es jetzt erst mal wieder.
Mal schauen, ob nach dem Update heute Nacht noch alles klappt.
Das muss funktionieren. Ich habe das schon gestern eingecheckt. Das ist heute im Update drin.
Bei anderen Nutzern hat es funktioniert. Vielleicht hast Du beim Download oder der Installation einen Fehler gemacht.
Mit dem Update heute hat es zumindest bei mir geklappt.
- gestern nach den Fehler habe ich fhem aus dem backup wiederhergestellt
- heute erneut ein update und restart
- alle läuft aktuell wie gewohnt und ich habe viele meiner Funktionen einem Test unterzogen
ein backup kann ich nur empfehlen und ich habe auch in global
backup_before_update = 1gesetzt damit ich immer ein zusätzliches backup bei einem update habe.
Hallo zap,
du hast ja die Funktion get dutycycle eingebaut. Damit fragst du die Schnittstellen bzw. Gateways ab und speicherst die Werte in Readings.
Wenn ich das auf meinem Testsystem manuell anstoße, bekomme ich die Rückmeldung, dass 7 Werte eingelesen worden seien. In den Readings erscheinen die folgenden Einträge:
duty_cycle_ccu2 1 2017-05-10 11:19:16
duty_cycle_hmip_ccu2 1 2017-05-10 11:19:16
duty_cycle_hmlgw2 4 2017-05-10 11:19:16
duty_cycle_lan_interface 0 2017-05-10 11:19:16
Tatsächlich verfügt meine CCU neben den eigenen Gateways für BidCoS-RF und HmIP jedoch über weitere folgende Gateways:
HMLAN1
HMLAN2
HMUSB1
HM-LAN-GW1
HM-LAN-GW2
RS485
Mache ich eine RPC-Aufruf von listBidcosInterfaces, erhalte ich folgendes Array:
0 'ADDRESS' => 'LEQ1234567', 'CONNECTED' => 0, 'DEFAULT' => 0, 'DESCRIPTION' => '', 'DUTY_CYCLE' => 0, 'FIRMWARE_VERSION' => '', 'TYPE' => 'Lan Interface'
1 'ADDRESS' => 'LEQ2345678', 'CONNECTED' => 1, 'DEFAULT' => 0, 'DESCRIPTION' => '', 'DUTY_CYCLE' => 0, 'FIRMWARE_VERSION' => 965, 'TYPE' => 'Lan Interface'
2 'ADDRESS' => 'LEQ3456789', 'CONNECTED' => 1, 'DEFAULT' => 0, 'DESCRIPTION' => '', 'DUTY_CYCLE' => 0, 'FIRMWARE_VERSION' => 967, 'TYPE' => 'Lan Interface'
3 'ADDRESS' => 'MEQ4567890', 'CONNECTED' => 1, 'DEFAULT' => 0, 'DESCRIPTION' => '', 'DUTY_CYCLE' => 4, 'FIRMWARE_VERSION' => '1.4.1', 'TYPE' => 'HMLGW2'
4 'ADDRESS' => 'MEQ5678901', 'CONNECTED' => 1, 'DEFAULT' => 1, 'DESCRIPTION' => 'CCU2-Coprocessor', 'DUTY_CYCLE' => 1, 'FIRMWARE_VERSION' => '2.8.3', 'TYPE' => 'CCU2'
5 'ADDRESS' => 'NEQ6789012', 'CONNECTED' => 1, 'DEFAULT' => 0, 'DESCRIPTION' => '', 'DUTY_CYCLE' => 4, 'FIRMWARE_VERSION' => '1.4.1', 'TYPE' => 'HMLGW2'
Erkennst du in der von dir verwendeten Methode einen Fehler?
Des weiteren schlage ich vor, auch die übrigen Informationen mit einzubauen, insbesondere den Connect-Status. Durch entsprechendes event-on-change-reading kann man auf einen Ausfall von einem Gateway triggern, wenn man periodisch das get dutycycle durchführt.
Ich vermute, dass ich etwas schlampig war, was die Generierung der Readingnamen angeht. Vermutlich landen mehrere Werte im gleichen Reading. Werde es mir anschauen.
Außerdem muss man die Abfrage für alle Ports ausführen, die einen Duty Cycle haben, also für BidCos und HMIP.
Hallo zusammen,
ich habe eine Frage zu dem genannten Modul. Ist es damit auch möglich Geräte (z.B. Rolladen) die in FHEM eingebunden sind, auch per CCU2 anzusprechen ? Wenn ja, wie funktioniert das ? Ich habe leider keine Informationen dazu gefunden (oder ich bin einfach blind :)).
Vielen Dank!
Zitat von: redstar2003 am 11 Mai 2017, 14:14:12
ich habe eine Frage zu dem genannten Modul. Ist es damit auch möglich Geräte (z.B. Rolladen) die in FHEM eingebunden sind, auch per CCU2 anzusprechen ? Wenn ja, wie funktioniert das ? Ich habe leider keine Informationen dazu gefunden (oder ich bin einfach blind
Nein, das geht nicht. Das Modul ermöglicht den umgekehrten Weg: Geräte (u.a. Rollläden), die in die CCU eingebunden sind, können von FHEM aus gesteuert werden.
Allerdings ist das Steuern von FHEM Geräten aus der CCU heraus jetzt nicht so schwer. Alles was es braucht ist ein Shell-Script auf der CCU, das einen Befehl auf den Telnet Port von FHEM schickt (z.B. mit netcat). Dieses Script kann man aus der CCU z.B. mit einem CUxD Exec Device ausführen. Nicht schön, aber funktioniert.
Moin zusammen,
ich habe ein etwas seltsames Problem:
Das Modul läuft tadellos, dann, irgendwann bekomme ich keine readings mehr. Im fhem log sehe ich nichts, nur einige Minuten nach dem letzten Reading das:
2017.05.12 03:08:00 2: HMCCU: Received no events from CCU since 300 seconds
Ich muss dann den RPC im Modul stoppen und wieder starten und dann geht es wieder.
##------------------------------------------------------------------------------
## Connector_CCU2
##------------------------------------------------------------------------------
define Connector_CCU2 HMCCU 10.2.12.51
attr Connector_CCU2 ccudef-readingfilter ^(LOW_?BAT|UNREACH)$
attr Connector_CCU2 ccudef-readingformat datapoint
attr Connector_CCU2 ccudef-readingname ^(.+\.)?AES_KEY$:sign;;^(.+\.)?LOW_?BAT$:battery;;^(.+\.)?BATTERY_STATE$:batteryLevel;;^(.+\.)?UNREACH$:Activity;;^(.+\.)?TEMPERATURE$:+temperature;;^(.+\.)?SET_TEMPERATURE$:+desired-temp;;^(.+\.)?HUMIDITY$:+humidity;;^(.+\.)?LEVEL$:+pct;;^(.+\.)?CONTROL_MODE$:+controlMode
attr Connector_CCU2 ccudef-substitute AES_KEY!(0|false):off,(1|true):on;;LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;;UNREACH!(0|false):alive,(1|true):dead;;MOTION!(0|false):noMotion,(1|true):motion;;DIRECTION!0:stop,1:up,2:down,3:undefined;;WORKING!0:false,1:true;;INHIBIT!(0|false):unlocked,(1|true):locked
attr Connector_CCU2 devStateIcon running.*:rc_GREEN (starting|stopping).*:rc_YELLOW (stopped|[I|i]nitialized).*:rc_RED
attr Connector_CCU2 icon hm_ccu
attr Connector_CCU2 room 9.6.2_Connectoren
attr Connector_CCU2 rpcinterfaces BidCos-RF
attr Connector_CCU2 rpcinterval 5
attr Connector_CCU2 rpcport 2001
attr Connector_CCU2 rpcqueue /tmp/ccuqueue
attr Connector_CCU2 rpcserver on
attr Connector_CCU2 stateFormat rpcstate/state
Die /tmp/ccuqueue_2001_1.dat ist leer, die /tmp/ccuqueue_2001_1.idx enthält nur eine 0.
Ideen? :D
VG Jan
Schau mal auf der CCU in der Datei /var/log/messages nach, wenn das Problem auftritt, ob da irgendwelche Fehlermeldungen drin stehen. Diese Datei kann man auch über das CCU WebUI unter Eintellungen / Systemsteuerung runter laden.
Ansonsten kannst Du es ja mal mit dem externen RPC Server HMCCURPC versuchen. Ist deutlich performanter als die File Queue Geschichte. Vor der Verwendung darauf achten, dass die benötigten Perl Module installiert sind.
Zuerst solltest Du aber mal auf CCU Seite nachschauen. Wenn das Problem dort liegt, hilft Dir auch HMCCURPC nicht.
Hier noch der Link zur HMCCURPC Ankündigung:
https://forum.fhem.de/index.php/topic,69480.0.html
Zitat von: zap am 10 Mai 2017, 12:20:13
Ich vermute, dass ich etwas schlampig war, was die Generierung der Readingnamen angeht. Vermutlich landen mehrere Werte im gleichen Reading. Werde es mir anschauen.
Ich würde die Zeile
my $type = exists ($iface->{TYPE}) ? $iface->{TYPE} : $HMCCU_RPC_NUMPORT{$port};
durch
my $type = exists ($iface->{TYPE}) ? $iface->{TYPE}_$iface->{ADDRESS} : $HMCCU_RPC_NUMPORT{$port};
ersetzen. Damit wird eine Eindeutigkeit erreicht.
Und für den Connect-Status würde ich noch folgende Zeilen einbauen:
my $connect = exists ($iface->{CONNECTED}) ? $iface->{CONNECTED} : "???"};
$rn = HMCCU_CorrectName ("connect_status_$type");
readingsBulkUpdate ($hash, lc($rn), $connect);
Ja, die letzte Aktion auf meinem Macbook (R.I.P.) war, die Readingnamen durch eine Nummerierung unique zu machen. Außerdem gibt es jetzt mehrere Readings je interface (für type, connect state, ...)
Nur das Einchecken habe ich nicht mehr geschafft. Mal sehen, bin auf der Suche nach einem Workaround bis ich ein Ersatzgerät habe.
Zitat von: zap am 12 Mai 2017, 08:47:52
Ja, die letzte Aktion auf meinem Macbook (R.I.P.) war, ...
Mein Beileid :-\
Danke, dass du die Vorschläge annimmst.
Zitat von: zap am 11 Mai 2017, 16:34:38
Nein, das geht nicht. Das Modul ermöglicht den umgekehrten Weg: Geräte (u.a. Rollläden), die in die CCU eingebunden sind, können von FHEM aus gesteuert werden.
Allerdings ist das Steuern von FHEM Geräten aus der CCU heraus jetzt nicht so schwer. Alles was es braucht ist ein Shell-Script auf der CCU, das einen Befehl auf den Telnet Port von FHEM schickt (z.B. mit netcat). Dieses Script kann man aus der CCU z.B. mit einem CUxD Exec Device ausführen. Nicht schön, aber funktioniert.
Vielen Dank für die Antwort. Das reine Hoch- und Runterfahren habe ich schon per PHP-Skript und darin enthaltenem Shell-Skript gelöst. Mich interessiert aber mehr die Weiterentwicklung. Es gibt hier im Forum ja das Rollo-Modul, für mich wäre es interessant, wenn ich neben Hoch- und Runterfahren z.B. auch die aktuelle Position auslesen könnte oder das Rollo zu einer bestimmten Prozentzahl schließen könnte. Gibt es dafür irgendwie Möglichkeiten über den von dir beschriebenen Weg ?
Die Kommunikationsrichtung ist mir jetzt nicht ganz klar.
Fall 1: Rollladen ist per Homematic Aktor in die CCU integriert
In diesem Fall kann in FHEM das Modul HMCCU verwendet werden, um den Rollladen in der CCU zu steuern. Gleichzeitig bekommt FHEM alle Statusinfos des Rollladen Aktors von der CCU geschickt. Auch die Position.
Fall 2: Rollladen ist in FHEM integriert (SOMFY or whatever)
Hier könnte man per Notify auf Veränderungen der Rollladenposition reagieren und diese mittels HMCCU z.B. in eine Systemvariable in der CCU schreiben
Ich bringe dann noch mal ein bisschen Licht ins Dunkle. :)
Ich habe meine Rolladen in FHEM (Rademacher Fernotron) integriert und steuere diese über das Rollo Modul. Mein Ziel wäre aber, die Rolladen in der CCU als (virtuelles) Device anzeigen zu lassen, mit dem ich nicht nur Hoch- und Runterfahren kann, sondern auch bestimmte Prozentzahlen anfahren kann und auch den aktuellen Stand der Rolladen auslesen kann. Vielleicht gibt es ja dazu eine getrickste Möglichkeit. :)
Bisher steuere ich die Rollos aus der CCU nur per PHP Skript, das einen Shell befehl ausführt.
Das könnte mit Hilfe des CCU Addons CUxD funktionieren. Habe das gerade mal angetestet:
- in der CUxD Oberfläche auf "Geräte" gehen und dann links bei CUxD Gerätetyp "36 - Aktoren" auswählen. Unter Funktion "Jalousieaktor 1-4 Kanal" auswählen. Name angeben, das Symbol sowie die Anzahl der Kanäle. Dann Button "Gerät auf CCU erzeugen" anklicken.
- Im CCU WebUI auf Posteingang gehen und das neue virtuelle Gerät übernehmen.
- In FHEM HMCCU mit externem RPC-Server (nur der unterstützt CUxD) einrichten.
- FHEM Device mit HMCCUDEV für den Rollladen anlegen
- Ab jetzt kann das Device in der CCU angesprochen werden und der RPC-Server schickt Statusmeldungen.
Bei meinem Test habe ich ein Gerät "Rollo" auf der CCU angelegt. In FHEM über HMCCU kann ich von diesem Gerät folgende Datenpunkte auslesen:
CHN CUX3602001:0 Rollo:0
DPT {n} CUxD.CUX3602001:0.RSSI_PEER = 0 [RE]
DPT {b} CUxD.CUX3602001:0.UNREACH = false [RE]
DPT {b} CUxD.CUX3602001:0.STICKY_UNREACH = true [RWE]
CHN CUX3602001:1 Rollo:1
DPT {f} CUxD.CUX3602001:1.LEVEL = 0.000000 [RWE]
DPT {b} CUxD.CUX3602001:1.STOP = [W]
DPT {f} CUxD.CUX3602001:1.RAMP_TIME = [W]
DPT {f} CUxD.CUX3602001:1.ON_TIME = [W]
DPT {b} CUxD.CUX3602001:1.WORKING = false [RE]
DPT {i} CUxD.CUX3602001:1.DIRECTION = 0 [RE]
DPT {b} CUxD.CUX3602001:1.INHIBIT = false [RW]
Man kann nun z.B. aus FHEM mit dem Befehl set datapoint 1.LEVEL eine Rollo-Position setzen. Wenn man in der CCU das virtuelle Device anklickt (z.B. Down) sollten die Readings in FHEM aktualisiert werden. Du könntest dann per Notify darauf reagieren und auf deine PHP Scripte verzichten.
Vielen Dank schon mal. Das hört sich gut an. :)
Ich habe aber leider noch zwei Fragen. :(
1. Ich habe unter Clients im d_ccu dies stehen: ":HMCCUDEV:HMCCUCHN:HMCCURPC:" Heißt das es läuft ein externer RPC-Server, oder wie kann ich einen einrichten ?
2. Ich habe die Rolladen ja schon in FHEM integriert, kann ich diese auch irgendwie mit einem HMCCUDEV-Device verbinden oder dem bestehenden Rolladen eine Erweiterung als HMCCUDEV geben ?
Zitat von: redstar2003 am 12 Mai 2017, 14:46:19
1. Ich habe unter Clients im d_ccu dies stehen: ":HMCCUDEV:HMCCUCHN:HMCCURPC:" Heißt das es läuft ein externer RPC-Server, oder wie kann ich einen einrichten ?
Siehe Abschnitt "Inbetriebnahme" unter https://wiki.fhem.de/wiki/HMCCU
Zitat
2. Ich habe die Rolladen ja schon in FHEM integriert, kann ich diese auch irgendwie mit einem HMCCUDEV-Device verbinden oder dem bestehenden Rolladen eine Erweiterung als HMCCUDEV geben ?
Nein, das geht nur über den Umweg CCU und virtuelles CUxD Device.
Zitat von: zap am 12 Mai 2017, 15:23:07
Siehe Abschnitt "Inbetriebnahme" unter https://wiki.fhem.de/wiki/HMCCU
Nein, das geht nur über den Umweg CCU und virtuelles CUxD Device.
Zu 1.), danke. Hat funktioniert.
Zu 2.), Ich meinte eigentlich auf der FHEM selbst. Ich habe aktuell schon die Rollos angelegt, kann ich dann nicht sagen dieses Rollos ist auch ein HMCCUDEV ? Oder einfacher gesagt, wie kriege ich es hin, das mein bestehendes Rollo auch ein HMCCUDEV wird ?
Danke. :)
Mit HMCCUDEV kann man nur CCU Geräte in FHEM ansprechen. Daher die Empfehlung, in der CCU quasi das Gegenstück zu deinem FHEM Rollo anzulegen, das dann wiederum per HMCCUDEV in FHEM angelegt wird.
Nun kannst Du per Notify dein Rollo Device mit dem HMCCUDEV Device und damit dem virtuellen Device in der CCU verknüpfen.
Konkret: wenn sich die Position deines Rollos ändert (also das Reading), setzt Du den Datenpunkt LEVEL im HMCCUDEV Device auf diesen Wert. Damit ändert er sich auch im virtuellen Device in der CCU.
Und umgekehrt: wenn du in der CCU das Level des virtuellen Device auf x% setzt, gibt die CCU diesen Wert an das HMCCUDEV Device weiter. Du setzt auf das entsprechende Reading ein Notify an und setzt dein FHEM Rollo Device auf den neue Wert.
Ergebnis: eine transparente Verknüpfung zwischen deinem Rollo in FHEM und der CCU.
Okay, langsam verstehe auch ich wie es funktionieren soll. :)
Ich werde mich dann am Wochenende mal mit Notify auseinandersetzen. So wie ich die Wiki-Seite sehe, ist Notify ja wirklich mächtig. Tausend Dank aber schon mal für deine Hilfe (und Geduld ;) ).
Moin,
auf das CCU-Log hätte ich auch selber mal kommen können. :D
Das ist das letzte was er vor dem abschmieren des RPC-Servers von sich gibt:
May 12 03:00:39 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","MEQ1558169:4","CONTROL_MODE",1}],[methodName:"event",params:{"CB2001","MEQ1558169:4","FAULT_REPORTING",0}],[methodName:"event",params:{"CB2001","MEQ1558169:4"
May 12 03:00:39 homematic-ccu2 user.err rfd: XmlRpc transport error
May 12 03:00:39 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"homebridge_BidCos-RF.","MEQ1558169:4","CONTROL_MODE",1}],[methodName:"event",params:{"homebridge_BidCos-RF.","MEQ1558169:4","FAULT_REPORTING",0}],[methodName:"event",p
Und so weiter...
In diesem Fall ist das berechtigt, weil die Firewall (die alle Zonen hält und u.a. das fhem von der CCU trennt) um 3 durchbootet. Das war ein workaround für ein Firmwareproblem das mittlerweile gelöst sein sollte. Insofern kann ich den reboot entfernen.
Reagiert das HMCCURPC Modul besser auf unterbrechungen?
VG Jan
Da geben sich HMCCU und HMCCURPC nichts. Die lauschen ja nur auf Nachrichten der CCU. HMCCURPC verarbeitet diese nur deutlich schneller als HMCCU bzw. der Filequeue Mechanismus.
Das Problem ist die CCU. Die gibt relativ schnell auf, wenn der Partner (hier FHEM) nicht antwortet. Lässt sich nur beheben, wenn sich der Abnehmer neu bei der CCU registriert. Das passiert aber nur, wenn der RPC Server in FHEM gestartet wird.
Für das Problem gibt es keine einfache Lösung. Gleiches gilt für einen Neustart der CCU. Die vergisst dabei nämlich alle registrierten Abnehmer. Auch da muss man den RPC Server neu starten.
Zitat von: redstar2003 am 12 Mai 2017, 18:35:36
Okay, langsam verstehe auch ich wie es funktionieren soll. :)
Ich werde mich dann am Wochenende mal mit Notify auseinandersetzen. So wie ich die Wiki-Seite sehe, ist Notify ja wirklich mächtig. Tausend Dank aber schon mal für deine Hilfe (und Geduld ;) ).
Hallo Zap,
leider bin ich nicht soweit gekommen. Notify schafft mich irgendwie und ich weiss nicht wie ich die Verknüpfung sauber hinkriege.
Mein Rollo in FHEM verfügt über das Reading "position", mit dem ich die richtige Position ansteuern kann. Mein HMMCCUDEV verfügt aber das Reading "1.LEVEL". Wie bekomme ich nun in Notify hin, das die richtige Position übergeben wird ? Anbei findest du auch einen Screenshot von Notify.
Vielen Dank :)
Die Probleme mit Notify kann ich verstehen. Aber wenn Notify schlimm ist, schau Dir mal DOIF an. Davon lass ich auch die Finger weg. Dagegen ist Notify simpel.
Aber steck da mal nicht zu viel Arbeit rein. Habe gerade festgestellt, dass man in der CCU zwar ein virtuelles Jalousien Device mit CUxD anlegen und auch steuern kann (also hoch/runter usw.), aber leider aktualisiert CUxD die Datenpunkte nicht. Vielleicht habe ich es auch nicht richtig konfiguriert. Blöderweise ist das bei CUxD nicht dokumentiert.
Jedenfalls habe ich es nicht geschafft, dass die CCU Änderungen für das virtuelle Device an FHEM bzw. HMCU weiter gibt.
Hm, das hört sich ja leider nicht so gut an. Bei mir wurden die Datenpunkte auch leider nicht aktualisiert. Andere Möglichkeiten/Tools (was macht der ioBroker genau?) gibt es für diese Art von Anforderung nicht ?
Vielen Dank aber trotzdem schon mal für deine Hilfe.
Der iobroker macht das gleiche wie HMCCU. Er abonniert die Events der entsprechenden CCU Schnittstellen.
Das CUxD Jalousiendevice ist für Enocean gedacht. So losgelöst scheint das nicht zu funktionieren. Leider ist die Enocean Erweiterung kostenpflichtig. Sonst hätte ich da noch ein wenig mehr probiert.
Eine Möglichkeit: man verwendet 2 der 50 virtuellen Tasterkanäle der CCU für hoch und runter. Diese kann man per HMCCUCHN in FHEM anlegen. Die bekommen dann ein PRESSED Event, wenn man im WebGUI der CCU den virtuellen Knopf drückt.
Vielleicht kann man per HMScript dann irgendwie ein Virtuelles CUXD Jalousiendevice mit den virtuellen Tastern verknüpfen. Noch ne Stufe komplizierter ....
Hallo zusammen,
ich versuche gerade die CCU2 in FHEM einzurichten.
Klappt bislang auch ganz gut, aber folgendes Problem habe ich noch:
Hier mein define:
define WDS_NW HMCCUDEV LEQ0160229
attr WDS_NW IODev d_ccu
attr WDS_NW ccureadingname 0.(LOWBAT|LOW_BAT):battery;1.TEMPERATURE:temperature
attr WDS_NW substitute battery!(1|true):low,(0|false):ok
attr WDS_NW room HMCCU
Eigentlich habe ich erwartet, dass ich im reading "battery" eine ok statt false stehen habe und das attr "ccureadingname" enthält nur "0.(LOWBAT|LOW_BAT):battery"
Hat jemand eine Idee, was ich hier falsch mache?
Zusätzlich wäre für mich interessant, wie ich den Wert temperature auf eine Nachkommastelle kürzen kann. Statt 32.300000 benötige ich 32.3 im Reading "temperature"
VG
Marc
So geht's:
attr WDS_NW substitute LOWBAT,LOW_BAT!(1|true):low,(0|false):ok
attr WDS_NW stripnumber 1
Hintergrund: Die Angaben bei Attributen wie substitute, ccureadingfilter, ccuscaleval usw. beziehen sich immer auf Datenpunkte, nicht auf Readingsnames.
BTW: War eigentlich der Meinung, dass battery sowie die Ersetzung von LOWBAT und auch UNREACH Default ist.
Mit stripnumber lassen sich nummerische Werte formatieren. stripnumber = 1 schneidet nach der ersten Nachkommastelle ab, stripnumber -1 rundet auf eine Nachkommastelle.
Super das funktioniert!
Jetzt hab ich noch das Problem, dass von
attr WDS_NW ccureadingname 0.(LOWBAT|LOW_BAT):battery;1.TEMPERATURE:temperaturenur folgendes in FHEM ankommt:
ccureadingname 0.(LOWBAT|LOW_BAT):batteryHast du da auch eine Idee, was ich hier falsch mache?
ZitatBTW: War eigentlich der Meinung, dass battery sowie die Ersetzung von LOWBAT und auch UNREACH Default ist.
Hab das Device durch "get <io-dev> devicelist create <dev-expr> [Options ...] [defattr] [<attr>=<value [...]]" anlegen lassen.
Bei "get WDS_NW defaults" habe ich die Meldung "No default attributes defined" erhalten
Ich meinte, dass battery ein globales und internes Default ist. Das sollte man komplett weglassen können und das battery Reading müsste trotzdem kommen.
Das Ignorieren von der 2. Ersetzung schaue ich mir mal an. Fixen wird aber schwierig, da ich immer noch keinen Ersatz für mein kaputtes Macbook habe.
Wenn ich über die Oberfläche das attr ccureadingname setzte, dann bleiben beide erhalten. Es funktioniert nur über die fhem.cfg nicht.
Bezüglich battery - Wie kann ich checken, ob das battery reading global kommt?
Ein notify notify .*:[Bb]attery.* wird jedenfalls ohne "ccureadingname" nicht ausgelöst
Die Readings kannst du mit dem Befehl "get update" holen. Damit werden alle Datenpunkte abgefragt und je nach Attribut ccureadingfilter entsprechende Readings erzeugt.
Zum anderen Problem: editierst du die fhem.cfg manuell? Ich glaube, beim Semikolon gibt es da eine Besonderheit. Muss möglicherweise ein \ davor oder das Semikolon muss gedoppelt werden. Lässt sich am einfachsten bei Eingabe über das Webfrontend und anschließender Speicherung raus bekommen.
ja, ich editiere die cfg in eclipse.
Lösung ist:
0.(LOWBAT|LOW_BAT):battery;;1.TEMPERATURE:temperature
Demnach wir ein Semikolon in der cfg durch Verdopplung escaped.
Eine Frage hab ich aber noch - In State/hmstate steht "Initialized" statt der Temparatur.
Bekomme ich das irgendwie geändert?
Zitat von: Init am 18 Mai 2017, 13:58:24
Eine Frage hab ich aber noch - In State/hmstate steht "Initialized" statt der Temparatur.
Bekomme ich das irgendwie geändert?
Du musst zumindest noch statedatapoint setzen, z.B. auf 1.TEMPERATURE
hmstate hat dann per Default den gleichen Wert wie state oder ggf den von LOWBAT oder UNREACH, sofern eines von beiden true ist.
Beeinflussen kann man hmstate durch das Attribut hmstatevals. Da würde ich dann doch auf die commandref verweisen.
Ich habe mehrere Schalter die ich mit on-for-timer schalte.
In der CCU2 direkt sieht man ja dann so ein Zahnradsymbol wenn der on-for-timer aktiv ist.
Gibt es eine möglichkeit den Timer in FHEM auszulesen?
LG
Die Schalter bieten für das Auslesen einer eingestellten On-Time leider keinen Datenpunkt an. Der Datenpunkt "ON_TIME" ist nur beschreibbar, also zum Setzen der On-Time vorgesehen. Ein Lesen ist nicht möglich.
HMCCUDEV und HMCCUCHN müssten sich intern die On-Time merken und das entsprechend visualisieren. So wird es vermutlich auch die CCU machen.
Eigentlich eine gute Idee, mal sehen ...
Weiß jemand, wie sich das bei CUL_HM verhält? Wird ein aktives on-for-timer dort irgendwie visualisiert?
Zitat von: zap am 19 Mai 2017, 08:28:43
Du musst zumindest noch statedatapoint setzen, z.B. auf 1.TEMPERATURE
Super, hat funktioniert!
Zitat von: zap am 19 Mai 2017, 08:28:43
Da würde ich dann doch auf die commandref verweisen.
Muss ich dir recht geben. Hab die commandref nicht auf dem Schirm gehabt und hab mich durch das Wiki gearbeitet - Sorry
Zitat
WIKI HMCCU
Inbetriebnahme
- Nach dem Neustart der CCU2 muss auch der RPC-Server neu gestartet werden, da die CCU2 bei einem Neustart die registrierten RPC-Server "vergisst".
Hab gestern Abend einen Test gemacht und einen Neustart der CCU gemacht. Danach wurden die Readings nicht mehr aktiv verändert. Nur ein update führte zur Veränderung der Readings.
Gibt es nicht eine Methode/Callback oder ähnliches im RPC Server, welche auf ein disconnect reagiert?
Zitat von: zap am 15 Mai 2017, 18:59:42
Die Probleme mit Notify kann ich verstehen. Aber wenn Notify schlimm ist, schau Dir mal DOIF an. Davon lass ich auch die Finger weg. Dagegen ist Notify simpel.
Aber steck da mal nicht zu viel Arbeit rein. Habe gerade festgestellt, dass man in der CCU zwar ein virtuelles Jalousien Device mit CUxD anlegen und auch steuern kann (also hoch/runter usw.), aber leider aktualisiert CUxD die Datenpunkte nicht. Vielleicht habe ich es auch nicht richtig konfiguriert. Blöderweise ist das bei CUxD nicht dokumentiert.
Jedenfalls habe ich es nicht geschafft, dass die CCU Änderungen für das virtuelle Device an FHEM bzw. HMCU weiter gibt.
Hallo Zap,
ich bin nun schon mal ein gutes Stück weitergekommen und wäre gut, wenn du mir mit eventuell mit Notify helfen kann. :) Ich habe nun anscheinend in CUxD das richtige Device gewählt und z.B. das Level wird nun richtig an FHEM übergeben (siehe Screenshot 1 + 2). Wie kriege ich nun Notifiy hingebogen, das er das vom HMCCUDEV, die Werte an das FHEM Device übergibt (Screenshot 3) ? Schön wäre es, wenn ich eine Position angeben kann und Hoch- bzw. Runterfahren. Hast du da eine Idee ?
Hat sich schon wieder erledigt, ich glaube ich kriege das über den ioBroker hin. Danke aber trotzdem. :)
Zitat von: Init am 19 Mai 2017, 12:03:27
Hab gestern Abend einen Test gemacht und einen Neustart der CCU gemacht. Danach wurden die Readings nicht mehr aktiv verändert. Nur ein update führte zur Veränderung der Readings.
Gibt es nicht eine Methode/Callback oder ähnliches im RPC Server, welche auf ein disconnect reagiert?
Die CCU verbindet sich nur mit HMCCU, wenn Daten anstehen. Daher kann HMCCU nicht auf einen Verbindungsabbau reagieren. Ich werde (sobald ich wieder arbeitsfähig bin) einen Mechanismus einbauen, der ein FHEM Event triggert, wenn für eine bestimmte Zeit kein Event von der CCU kam. Da kann man dann drauf reagieren.
Zitat von: redstar2003 am 19 Mai 2017, 18:18:53
Ich habe nun anscheinend in CUxD das richtige Device gewählt und z.B. das Level wird nun richtig an FHEM übergeben (siehe Screenshot 1 + 2).
Auf den Devicetyp in CUxD wäre ich nie gekommen. Die Logik von dem Addon ist schon manchmal etwas seltsam. Werde das mal für meine Somfy Rollläden in der Küche nachbauen. Werde dann hier ein kurzes Howto inkl. der notwendigen Notifies bereitstellen.
Hi zusammen,
ich beobachte seit ca 2 Wochen dass seit dem Firmwareupdate der CCU2 auf 2.27.8 irgendetwas bei der RPC Kommunikation nicht mehr stimmt.
Manchmal schmiert alles ab dann reagiert auch FHEM nicht mehr, manchmal kommen nur keine Statusmeldungen von den IP Geräten. Wenn ich über Get devstate oder update gehe wird der korrekte Status gezeigt.
In der CCU wird auch weiterhin alles korrekt angezeigt.
Derzeit boote ich alles neu dann geht es wieder für eine Weile.
ein reiner Restart des RPC auf HMCCU Seite brachte keine Verbesserung.
Vor dem Upgrade lief alles super, nur brauchte ich das um die HMIP Schaltaktoren updten zu können damit deren Fehlverhalten aufhört. :/
das nennt man wohl vom Regen in die Traufe kommen :D
Hat jemand eine nTipp wie ich dieses Problem angehen könnte? Ohne alles neu starten zu müssen.
P.S. Firewall ist natürlich mittlerweile aus Verzweiflung auf Vollzugriff gestellt :D Und die Ports sind auch richtig (ging ja vor dem update)
Grüße Andreas
Verwendest Du den internen oder den externen RPC-Server (HMCCURPC) ?
Die 2.27.8 verwende ich auch und habe keine Probleme.
Hast Du Fehlermeldungen im FHEM Logfile oder auf der CCU in /var/log/messages ?
Die CCU ist relativ empfindlich, wenn die Verbindung zu FHEM unterbrochen wird. Dann gibt es in /var/log/messages "transport errors" und die CCU stellt die Weiterleitung von Events an FHEM ein. In dem Fall sollte aber ein Neustart des RPC Servers helfen, da sich HMCCU dann neu bei der CCU registriert.
vielleicht blöde Frage, aber kann ich über HMCCU erkennen, wenn ein Gerät in der CCU2 verschwunden ist?
Hintergrund: ich musste gestern mal über die CCU2 was konfigurieren und habe mich gewundert, dass das entsprechende Gerät dort nicht mehr gelistet war. Ein neues Anlernen brachte dann zu Tage, dass sogar 9 Geräte verschwunden waren. In FHEM habe ich das leider an keiner Stelle gemerkt. Dummerweise habe ich zwischendurch auch mal über die UI gespeichert und dadurch waren die Geräte gleich in FHEM auch weg.
War etwas frustrierend, die Geräte erst wieder in der CCU2 entsprechend benennen zu müssen und hinterher auch in FHEM die Konfig zu hinterlegen.
Mit einer Pushnachricht "Gerät XYZ aus der CCU2 verschwunden" hätte ich wenigstens vermeiden können in FHEM zu speichern ;)
Wobei man das erneute Anlernen und Umbenennen in der CCU2 hingegen nicht vermeiden kann.
Wie die Geräte in FHEM verschwinden können, weiß ich auch nicht. Wenn ein Gerät in der CCU gelöscht wird, wird das Internal "ccudevstate" der entsprechenden FHEM Devices vom Typ HMCCUDEV und HMCCUCHN auf "deleted" gesetzt. Intern führt HMCCU das gelöschte Device als "invalid", d.h. es kann kein neues Device dafür in FHEM definiert werden.
Man könnte natürlich ein Event triggern, wenn ein Device in der CCU gelöscht wird. Die Frage ist nur, was das bringt. Wie würdest Du auf ein solches Event reagieren?
Hallo Zap, was meinst du mit internem oder externen? Ich verwende den der mit dem Modul HMCCU installiert wird (also denke internen).
Dort steht auch immer running/ok
Im Fhem Log steht nur hin und wieder diese Meldung bei unterschiedlichen devices(Zeit steht auf 5Sek.):
2017.05.23 13:21:53 1: HMCCUDEV: HM_Heizung_Wohnzimmer Execution of CCU script or command failed.
Sorry für die Frage aber wie kann ich mir die Meldungen in der CCU anzeigen lassen? Wenn ich mich mit Putty verbinde komme ich mit cd /var/log bis hierhin. mit ls bekomme ich dann messages angezeigt aber wie kann ich sie öffnen, ein Ordner scheint es nicht zu sein und den nano editor schluckt er auch nicht?
Edit: hab es selbst rausgefunden. mit dem vi Editor geht es. Also seit 22.05.17 sind 404 Einträge da hatte ich sie neu gestartet.
Mit Error stehen teilweise folgendne Zeilen darin (aber bis jetzt ist die Kommuniaktion noch standhaft)
May 23 04:56:39 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::CallXmlrpcMethod: execute result isFault; method =setValue Params = {"000855699C4CAF:4","STATE",fal
May 23 04:56:39 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::CallSetValue: CallXmlrpcMethod failed [../Platform/DOM/iseXmlRpc.cpp (1517)]
May 23 04:56:39 homematic-ccu2 local0.err ReGaHss: Error: IseHssDP::WriteValue: CallSetValue failed; address = 000855699C4CAF:4 [../Platform/DOM/iseDOMdpHSS.cpp (77)]
May 23 08:46:49 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","NEQ1489363:4","CONTROL_MODE",1}],[methodName:"event
May 23 08:46:49 homematic-ccu2 user.err rfd: XmlRpc transport error
May 23 09:57:59 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","NEQ1489363:4","CONTROL_MODE",1}]}) on http://192.16
May 23 09:57:59 homematic-ccu2 user.err rfd: XmlRpc transport error
Grüße
Sind FHEM und/oder die CCU per WLAN angebunden? Oder wird die Netzwerkverbindung zwischen CCU und FHEM ab und zu aus anderen Gründen (Reset des Routers o.ä.) unterbrochen?
Die Meldung "Execution of CCU Script or command failed" kann entweder an einer falschen Befehlssyntax liegen oder daran, dass die CCU nicht erreichbar ist.
Mit externem RPC Server meine ich:
https://forum.fhem.de/index.php?topic=69480.0
Wird aber dein Problem vermutlich nicht lösen.
Zitat von: zap am 23 Mai 2017, 17:16:45
Wie die Geräte in FHEM verschwinden können, weiß ich auch nicht. Wenn ein Gerät in der CCU gelöscht wird, wird das Internal "ccudevstate" der entsprechenden FHEM Devices vom Typ HMCCUDEV und HMCCUCHN auf "deleted" gesetzt. Intern führt HMCCU das gelöschte Device als "invalid", d.h. es kann kein neues Device dafür in FHEM definiert werden.
Man könnte natürlich ein Event triggern, wenn ein Device in der CCU gelöscht wird. Die Frage ist nur, was das bringt. Wie würdest Du auf ein solches Event reagieren?
Nun ja, ich bin zumindest aktiv darüber informiert, dass die CCU Mist gemacht und Geräte "vergessen" hat. Was z.B. bei Bewegungsmeldern für außen ja durchaus recht wichtig sein kann.
Ich muss mal darauf achten, ob in diesem Fall - was ja kein echtes Löschen in der CCU, sondern eher ein Vergessen ist - dann auch das Internal ccudevstate auf "deleted" gesetzt wird. Dann könnte ich darüber was machen.
Mir ist natürlich bewusst, dass es sinnvoller wäre, wenn die CCU in der Hinsicht stabil wäre und nicht Geräte vergißt, aber das Problem scheint gemäß Homematic-Forum durchaus immer mal wieder aufzutauchen.
Meine CCU hat noch nie ein Gerät "vergessen". Selbst Geräte, die wg. Nichtnutzung und leerer Batterie schon seit einem Jahr unreachable sind, sind immer noch vorhanden.
@zap der Rasberry hängt via Wlan am Netzwerk.
heute Morgen war wieder der Fall dass alles ausgefallen ist.
der Wecker über das Resident Modul wurde allerdings noch ausgeführt aber 1h später als ich etwas schauen wollte, kein Zugriff mehr auf FHEM. Wieder eine Stunde später ging dann der Zugriff wieder aber es kamen keine Aktualisierungen mehr.
Neustart des internen RPC Servers und es kamen die aktualisierungen der normalen HM Geräte wieder an. HMIP allerdings weiterhin fehlanzeige. vermutlich bis ich die CCU neustarte.
Kann es sein das ich evt etwas an den HMIP Schaltaktoren falsch definiert habe da diese durch meinen Wecker eingeschalten werden?
Ich stelle hier mal ein LIST von meinem HMIP Gerät ein (UP Schaltaktor). Geschalten wird es im Resident Macro mit: fhem "set HM_Licht_Treppenhaus_OG on";
Internals:
DEF 000855699C5298 4
IODev d_ccu
NAME HM_Licht_Treppenhaus_OG
NR 313
STATE off
TYPE HMCCUDEV
ccuaddr 000855699C5298
ccudevstate Active
ccuif HmIP-RF
ccuname HmIP-BSM 000855699C5298
ccutype HmIP-BSM
channels 9
statevals devstate|on|off
Readings:
2017-05-24 12:17:28 3.STATE off
2017-05-24 12:17:28 4.STATE off
2017-05-24 12:17:28 5.STATE off
2017-05-24 12:17:28 6.STATE off
2017-05-24 12:17:28 control off
2017-05-24 12:17:28 state off
Attributes:
IODev d_ccu
alias Treppenhauslicht Oben
ccureadingfilter (STATE|PRESS_LONG|PRESS_SHORT)
ccureadingformat datapoint
controldatapoint 4.STATE
event-on-change-reading .*
genericDeviceType light
group Licht
room Homekit,Homematic,Treppenhaus,alexa,webview
statedatapoint 4.STATE
statevals on:true,off:false
substitute STATE!(0|false):off,(1|true):on
userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
Zitat von: zap am 24 Mai 2017, 12:22:26
Meine CCU hat noch nie ein Gerät "vergessen". Selbst Geräte, die wg. Nichtnutzung und leerer Batterie schon seit einem Jahr unreachable sind, sind immer noch vorhanden.
das kommt vor, aber nur dann wenn du geräte in der ccu angelernt hast und dich zb vor einem direkten neustart danach nicht von der ccu abmeldest oder den neustart nicht über die ccu durchführst (sprich steckerraus oder absturtz).
wenn man eine occu betreibt kann man schnell in diese falle tappen. die ccu speichert wohl regelmäßig in größeren abständen, bei neustart und bei abmelden an der webui selbstständig alles ab.
bei der occu war zb das ich geräte angelernt und eingerichtet habe, dann zeitnah den pi gebootet habe und alles war weg. die erklärung habe ich dann im homematic-forum erhalten.
verhält sich also wie fhem nur das du dort einen save button hast ;)
Zitat von: doessbaddel am 24 Mai 2017, 16:08:54
@zap der Rasberry hängt via Wlan am Netzwerk.
heute Morgen war wieder der Fall dass alles ausgefallen ist.
Ich vermute hier WLAN Probleme, die zu diesen Aussetzern führen. Das würde auch erklären, weshalb die CCU die Weiterleitung von Events einstellt.
Zitat
Kann es sein das ich evt etwas an den HMIP Schaltaktoren falsch definiert habe da diese durch meinen Wecker eingeschalten werden?
Die Definition sieht eigentlich weitgehend ok aus. Du solltest bei Geräten mit PRESS_xxxx Datenpunkten allerdings unbedingt statt event-on-change-reading das Attribut event-on-update-reading auf ".*" setzen. Grund: PRESS_xxxx kennt nur "true" bzw. 1. Das wird niemals "false" oder 0. Daher werden diesen Reading nur beim ersten Tastendruck aktualisiert und danach nie wieder (bei event-on-change-reading).
Zum Thema ausbleibende Aktualisierung nach Neustart RPC Server für HMIP: Gibt es beim Neustart irgendwelche Fehlermeldungen im FHEM-Log? Du könntest auch mal auf den externen RPC-Server umstellen. Bringt vielleicht auch was, zumal ich dort demnächst eine automatische Neuregistrierung beim Ausbleiben von CCU Events einbauen werde.
Ich würde auch denken, das dieses ein WLAN-Proble gibt.
Ist es eine FritzBox?
Wie voll sind die "Frequenzen"?
Sprichst Du die Gerätze mit ihrere IP oder mit den Namen an, die die FritzBox vergiebt?
Hmm hab das Modul im Betrieb. Gerade ein Fensterkontakt angelernt. Wie bekomme ich dei HM Geräte automatisch in mein FHEM ? getdevice sagt zwar das es Geräte gibt fügt diese nicht hinzu.
Hatte das Gerät paar mal angelegt und gelöscht im FHEM log:
017.05.26 20:09:59 2: HMCCU: Received no events from CCU since 300 seconds
2017.05.26 20:24:30 2: CCURPC: CB2001 NewDevice received 3 device specifications
2017.05.26 20:24:32 2: HMCCU: Duplicate name for device/channel HM-RCV-50 BidCoS-RF:45 address=MEQ1596346 in CCU.
2017.05.26 20:24:32 2: HMCCU: Duplicate name for device/channel HM-RCV-50 BidCoS-RF:45 address=MEQ1596346:0 in CCU.
2017.05.26 20:28:56 2: CCURPC: CB2001 DeleteDevice received 3 device addresses
2017.05.26 20:29:31 2: CCURPC: CB2001 NewDevice received 3 device specifications
2017.05.26 20:29:32 2: HMCCU: Duplicate name for device/channel HM-RCV-50 BidCoS-RF:45 address=MEQ1596346 in CCU.
2017.05.26 20:34:14 2: CCURPC: CB2001 DeleteDevice received 3 device addresses
2017.05.26 20:35:29 2: CCURPC: CB2001 NewDevice received 3 device specifications
2017.05.26 20:35:33 2: HMCCU: Duplicate name for device/channel HM-RCV-50 BidCoS-RF:45 address=MEQ1596346:0 in CCU.
Okay mit :
get d_ccu devicelist create HM_Tuer_Hof t=dev room=Homematic
hat es geklappt Raum Homematic wurde zwar nicht angelegt aber Okay..
Jedoch hab ich Status 0 und 1 nun.
Kenne es vom HMLAN und FHEM das er das volle Gerät direkt EIngefügt und erkannt wird ...
Die RPC Schnittstelle schickt immer 1/0, während die Logikschicht der CCU (zB mit dem Befehl get update) true/false zurück gibt.
Für diesen Fall gibt es das Attribut substitute. beispiel:
STATE!(0|false):open,(1|true):closed
Damit erhält man sinnvolle Werte in Readings. Gerne auch mal "set defaults" ausprobieren. Für viele Gerätetypen gibt es Default-Attribute.
Moin
Dumme frage zum WLAN...
Der Router schaltet Nachts das WLAN nicht irgend wann Zeitgesteuert aus und morgens wieder an?
In die Falle bin ich anfangs getappt ::)
Schönes warmes Wochenende
Gerd
Hallo zusammen,
habe plötzlich ein sehr seltsames Problem mit dem Modul. Seit heute werden mir keinerlei devices mehr angezeigt und im log sehe ich auch eine Meldung, dass diese alle nicht definiert werden konnten. Kenne das wenn die CCU offline ist aber aktuell ist sie erreichbar. Wenn ich fhem neu starte sehe ich, dass HMCCU noch nicht initialisiert ist, erst ein paar Sekunden später. Habe dann mal testweise ein Gerät manuell hinzugefügt und alles funktioniert damit (Status/Schalten usw). Irgendetwas scheint hier mit der Verbindung nicht zu stimmen bzw. scheint etwas geblockt zu werden. Aufgetreten ist dies alles heute nachdem ich mein komplettes Netzwerk auf UniFi umgestellt habe (Router, Switch, APs etc.)
Hat jemand schon so etwas vergleichbares gesehen?
Zitat von: zap am 20 Mai 2017, 09:25:36
Die CCU verbindet sich nur mit HMCCU, wenn Daten anstehen. Daher kann HMCCU nicht auf einen Verbindungsabbau reagieren. Ich werde (sobald ich wieder arbeitsfähig bin) einen Mechanismus einbauen, der ein FHEM Event triggert, wenn für eine bestimmte Zeit kein Event von der CCU kam. Da kann man dann drauf reagieren.
Das hört sich super an. Kenne mich mit der CCU leider noch nicht wirklich gut aus, aber könnte man da nicht ein virtualDevice erstellen, welches alle 5 Minuten einen Zeitstempel schickt?
Hi zusammen,
Danke für eure Hilfe.
Es scheinen wirklich WLAN Probleme gewesen zu sein.
Nach dem ersten Tipp habe ich mal im Router nachgeschaut und gesehen dass der Raspi sich permanent anmeldet obwohl ich WLAN Sleep aus habe.
Ich habe den Raspi jetzt per LAN angeschlossen, seitdem funktioniert alles einwandfrei.
Danke nochmal :)
Viele Grüße
Hallo zusammen,
ich habe nun mein erstes HMIP-Gerät () in Betrieb genommen.
Aber leider kommen die Werte nur manuell wenn ich "get SMO_BUERO update" ausführe.
Hier mein define
define SMO_BUERO HMCCUDEV 000BD5699DBD94
attr SMO_BUERO IODev d_ccu
attr SMO_BUERO room HMCCU
attr SMO_BUERO ccureadingfilter (LOW_BAT|ILLUMINATION|MOTION)
attr SMO_BUERO hmstatevals ERROR!1:sabotage
attr SMO_BUERO statedatapoint MOTION
attr SMO_BUERO substitute MOTION!(0|false):no,(1|true):yes;ERROR!0:no,1:sabotage;LOWBAT,LOW_BAT!(1|true):low,(0|false):ok
Hat jemand eine Idee, was mir hier fehlt?
VG
Marc
Vermutlich läuft der RPC Server nicht oder du hast beim Attribut rpcinterface hmip nicht angehakt.
Letzteres war mein Fehler!
Ich habe das rpcinterfaces "HmIP-RF" hinzugefügt und alles funktioniert :)
Kleine Anmerkung: Im Wiki steht "HmIP-RF" und in CommandRef steht "HmIP"
Danke!
Zitat von: ph4 am 28 Mai 2017, 23:13:56
Hallo zusammen,
habe plötzlich ein sehr seltsames Problem mit dem Modul. Seit heute werden mir keinerlei devices mehr angezeigt und im log sehe ich auch eine Meldung, dass diese alle nicht definiert werden konnten. Kenne das wenn die CCU offline ist aber aktuell ist sie erreichbar. Wenn ich fhem neu starte sehe ich, dass HMCCU noch nicht initialisiert ist, erst ein paar Sekunden später. Habe dann mal testweise ein Gerät manuell hinzugefügt und alles funktioniert damit (Status/Schalten usw). Irgendetwas scheint hier mit der Verbindung nicht zu stimmen bzw. scheint etwas geblockt zu werden. Aufgetreten ist dies alles heute nachdem ich mein komplettes Netzwerk auf UniFi umgestellt habe (Router, Switch, APs etc.)
Hat jemand schon so etwas vergleichbares gesehen?
Kann mir hier irgendwer helfen? Das Modul funktioniert seit dem nicht mehr bei mir.
Ich nehme an, dass HMCCU die CCU nicht erreichen kann. Das kann an deinem Netz liegen oder an den Firewall Einstellungen auf der CCU. unifi kenne ich nicht.
Interessant wäre, welche Meldungen beim Laden von HMCCU kommen, wenn FHEM startet. Dabei interessieren mich weniger die Folgefehler bei der Definition. Der Devices. Normalerweise meldet HMCCU, wie viele Geräte von der CCUgelesenwurden
Hallo zusammen,
ich habe in meiner CCU2 ein HMW_IO_12_Sw7_DR eingebunden und in FHEM über "get d_ccu devicelist create ^HMW.* t=dev f=%n room=HMCCU" geholt.
Es wurde jetzt ein Device erstellt, aber das Gerät hat 12 Taster und 7 Schalter.
Kann mir jemand sagen, wie ich diese Taster und Schalter einlesen kann?
VG
Marc
Zitat von: Init am 31 Mai 2017, 11:15:22
ich habe in meiner CCU2 ein HMW_IO_12_Sw7_DR eingebunden und in FHEM über "get d_ccu devicelist create ^HMW.* t=dev f=%n room=HMCCU" geholt.
Es wurde jetzt ein Device erstellt, aber das Gerät hat 12 Taster und 7 Schalter.
Kann mir jemand sagen, wie ich diese Taster und Schalter einlesen kann?
t=chn statt t=dev sollte das beheben.
Vielen Dank! So habe ich alles bekommen.
Wie würde man am besten vorgehen?
Geräte mit Channel 0+1 bsp. (0=Gerät / 1=Temperatur) als HMCCUDEV erstellen lassen
Und Geräte mit mehr Channel als HMCCUCHN erstellen lassen? Wären hierbei die Readings von HMCCUCHN mit Channel=0 identisch mit den Readings aus HMCCUDEV?
Viele Grüße
Marc
Habe einen optischen Fensterkontakt angelernt.
Wenn ich im Eventmanager mitschaue bekomme ich mehrmals den State open oder closed sie angehängtem Code
Vorallem bei der Statusänderung wird vorher nochmal der aktuelle Stand auch mitgeschickt.
Magnet Kontakt wird geöffnet:
2017-05-31 15:57:30 HMCCUCHN HM_FK battery: ok
2017-05-31 15:57:30 HMCCUCHN HM_FK 1.STATE: open
2017-05-31 15:57:30 HMCCUCHN HM_FK open
2017-05-31 15:57:30 HMCCUCHN HM_FK hmstate: open
Magnet Kontakt wird geschlossen:
2017-05-31 15:57:32 HMCCUCHN HM_FK 1.STATE: closed
2017-05-31 15:57:32 HMCCUCHN HM_FK closed
2017-05-31 15:57:32 HMCCUCHN HM_FK battery: ok
2017-05-31 15:57:32 HMCCUCHN HM_FK hmstate: closed
Optischer Kontakt wird geöffnet:
2017-05-31 16:01:05 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:05 HMCCUCHN HM_FK_OPT2 hmstate: closed
2017-05-31 16:01:06 HMCCUCHN HM_FK_OPT2 1.STATE: open
2017-05-31 16:01:06 HMCCUCHN HM_FK_OPT2 open
2017-05-31 16:01:06 HMCCUCHN HM_FK_OPT2 hmstate: open
2017-05-31 16:01:07 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:07 HMCCUCHN HM_FK_OPT2 hmstate: open
2017-05-31 16:01:09 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:09 HMCCUCHN HM_FK_OPT2 hmstate: open
2017-05-31 16:01:12 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:12 HMCCUCHN HM_FK_OPT2 hmstate: open
optischer Kontakt wird geschlossen:
2017-05-31 16:01:50 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:50 HMCCUCHN HM_FK_OPT2 hmstate: open
2017-05-31 16:01:50 HMCCUCHN HM_FK_OPT2 1.STATE: closed
2017-05-31 16:01:50 HMCCUCHN HM_FK_OPT2 closed
2017-05-31 16:01:50 HMCCUCHN HM_FK_OPT2 hmstate: closed
2017-05-31 16:01:51 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:51 HMCCUCHN HM_FK_OPT2 hmstate: closed
2017-05-31 16:01:53 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:53 HMCCUCHN HM_FK_OPT2 hmstate: closed
Ist das so gewünscht das mehrmals der Status gesendet wird?
LG
Zitat von: Init am 31 Mai 2017, 12:07:23
Vielen Dank! So habe ich alles bekommen.
Das hätte auch mit HMCCUDEV funktionieren müssen.
Zitat
Wie würde man am besten vorgehen?
Geräte mit Channel 0+1 bsp. (0=Gerät / 1=Temperatur) als HMCCUDEV erstellen lassen
Und Geräte mit mehr Channel als HMCCUCHN erstellen lassen? Wären hierbei die Readings von HMCCUCHN mit Channel=0 identisch mit den Readings aus HMCCUDEV?
Viele Grüße
Marc
Jedes Gerät in der CCU hat einen Statuskanal 0 und mindestens 1 normalen Kanal für die Nutzdaten. Ein mit HMCCUDEV definiertes Device enthält alle Kanäle des CCU Gerätes. Ein mit HMCCUCHN definiertes Device enthält den entsprechenden Datenkanal plus den Kanal 0.
HMCCUCHN nimmt man, wenn man auf einen Datenkanal zugreifen möchte. HMCCUDEV wenn man auf mehrere Datenkanäle zugreifen will.
Ein Sonderfall sind Mehrfachschalter. Diese haben üblicherweise mehrere Datenkanäle, die alle einen Datenpunkt STATE oder PRESS_SHORT haben. Hier kann es von Vorteil sein, jeden Datenkanal als HMCCUCHN zu definieren, wenn man die einzelnen Schaltkanäle separat betrachten möchte.
Zitat von: mrfloppy am 31 Mai 2017, 16:06:50
Habe einen optischen Fensterkontakt angelernt.
Wenn ich im Eventmanager mitschaue bekomme ich mehrmals den State open oder closed sie angehängtem Code
Vorallem bei der Statusänderung wird vorher nochmal der aktuelle Stand auch mitgeschickt.
Optischer Kontakt wird geöffnet:
2017-05-31 16:01:05 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:05 HMCCUCHN HM_FK_OPT2 hmstate: closed
2017-05-31 16:01:06 HMCCUCHN HM_FK_OPT2 1.STATE: open
2017-05-31 16:01:06 HMCCUCHN HM_FK_OPT2 open
2017-05-31 16:01:06 HMCCUCHN HM_FK_OPT2 hmstate: open
2017-05-31 16:01:07 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:07 HMCCUCHN HM_FK_OPT2 hmstate: open
2017-05-31 16:01:09 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:09 HMCCUCHN HM_FK_OPT2 hmstate: open
2017-05-31 16:01:12 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:12 HMCCUCHN HM_FK_OPT2 hmstate: open
Ist das so gewünscht das mehrmals der Status gesendet wird?
LG
Ich nehme mal an, das liegt daran, dass bei jedem Update eines Datenpunktes "hmstate" neu berechnet wird. Diesen Overhead sollte man natürlich vermeiden. Da muss ich nochmal Hand anlegen.
Du kannst die nutzlosen Events vorerst mit event-on-change-reading = .* unterbinden.
Kannst Du bitte mal ein list des magnetischen und des optischen Sensors posten?
Bitte hier die beiden listings
Der magnetische Kontakt:
Internals:
DEF MEQ1592858:1 defaults
IODev CCU2
NAME HM_FK
NR 691
STATE open
TYPE HMCCUCHN
ccuaddr MEQ1592858:1
ccudevstate active
ccuif BidCos-RF
ccuname HM_Kontakt:1
ccutype HM-Sec-SC-2
channels 1
chntype SHUTTER_CONTACT
firmware 2.4
statevals devstate
Readings:
2017-05-31 15:57:50 1.STATE open
2017-05-29 11:39:04 Activity alive
2017-05-31 15:57:50 battery ok
2017-05-31 15:57:50 hmstate open
2017-05-31 15:57:50 state open
Hmccu:
Dp:
0.aes_key:
VAL 1
0.config_pending:
VAL false
0.lowbat:
VAL false
0.rssi_device:
VAL 1
0.rssi_peer:
VAL 1
0.sticky_unreach:
VAL false
0.unreach:
VAL false
1.error:
VAL 0
1.lowbat:
VAL 0
1.state:
VAL 1
Attributes:
IODev CCU2
ccureadingfilter STATE
group Fensterkontakte
hmstatevals ERROR!7:sabotage;SABOTAGE!1:sabotage
room HM_CCU2
statedatapoint STATE
substitute STATE!(0|false):closed,(1|true):open
der optische Fensterkontakt:
Internals:
DEF OEQ0226088:1 defaults
IODev CCU2
NAME HM_FK_OPT1
NR 708
STATE closed
TYPE HMCCUCHN
ccuaddr OEQ0226088:1
ccudevstate active
ccuif BidCos-RF
ccuname FK-OPT1:1
ccutype HM-Sec-SCo
channels 1
chntype SHUTTER_CONTACT
firmware 1.0
statevals devstate
Readings:
2017-05-31 19:13:14 1.STATE closed
2017-05-29 11:39:04 Activity alive
2017-05-31 19:13:14 battery ok
2017-05-31 19:13:14 hmstate closed
2017-05-31 19:13:14 state closed
Hmccu:
Dp:
0.aes_key:
VAL 1
0.config_pending:
VAL false
0.device_in_bootloader:
VAL false
0.lowbat:
VAL false
0.rssi_device:
VAL 1
0.rssi_peer:
VAL 200
0.sticky_unreach:
VAL false
0.unreach:
VAL false
0.update_pending:
VAL false
1.error:
VAL 0
1.lowbat:
VAL 0
1.state:
VAL 0
Attributes:
IODev CCU2
ccureadingfilter STATE
group Fensterkontakte
hmstatevals ERROR!7:sabotage;SABOTAGE!1:sabotage
room HM_CCU2
statedatapoint STATE
substitute STATE!(0|false):closed,(1|true):open
Habe gerade noch beim ThreeState Sensor geschaut da sieht es ähnlich aus.
von closed auf tilted:
2017-05-31 19:45:28 HMCCUCHN HM_WZ_EG_FK3 battery: ok
2017-05-31 19:45:28 HMCCUCHN HM_WZ_EG_FK3 hmstate: closed
2017-05-31 19:45:30 HMCCUCHN HM_WZ_EG_FK3 battery: ok
2017-05-31 19:45:30 HMCCUCHN HM_WZ_EG_FK3 1.STATE: open
2017-05-31 19:45:30 HMCCUCHN HM_WZ_EG_FK3 open
2017-05-31 19:45:30 HMCCUCHN HM_WZ_EG_FK3 hmstate: open
tiltet auf open:
2017-05-31 19:45:46 HMCCUCHN HM_WZ_EG_FK3 battery: ok
2017-05-31 19:45:46 HMCCUCHN HM_WZ_EG_FK3 hmstate: open
2017-05-31 19:45:48 HMCCUCHN HM_WZ_EG_FK3 1.STATE: tilted
2017-05-31 19:45:48 HMCCUCHN HM_WZ_EG_FK3 tilted
2017-05-31 19:45:48 HMCCUCHN HM_WZ_EG_FK3 battery: ok
2017-05-31 19:45:48 HMCCUCHN HM_WZ_EG_FK3 hmstate: tilted
von tilted auf closed
2017-05-31 19:46:04 HMCCUCHN HM_WZ_EG_FK3 battery: ok
2017-05-31 19:46:04 HMCCUCHN HM_WZ_EG_FK3 hmstate: tilted
2017-05-31 19:46:06 HMCCUCHN HM_WZ_EG_FK3 battery: ok
2017-05-31 19:46:06 HMCCUCHN HM_WZ_EG_FK3 1.STATE: open
2017-05-31 19:46:06 HMCCUCHN HM_WZ_EG_FK3 open
2017-05-31 19:46:06 HMCCUCHN HM_WZ_EG_FK3 hmstate: open
2017-05-31 19:46:07 HMCCUCHN HM_WZ_EG_FK3 battery: ok
2017-05-31 19:46:07 HMCCUCHN HM_WZ_EG_FK3 hmstate: open
auch noch das listing zum ThreeStateKontakt:
Internals:
DEF NEQ1477782:1 defaults
IODev CCU2
NAME HM_WZ_EG_FK3
NR 706
STATE closed
TYPE HMCCUCHN
ccuaddr NEQ1477782:1
ccudevstate active
ccuif BidCos-RF
ccuname WZ-EG-FK3:1
ccutype HM-Sec-RHS
channels 1
chntype ROTARY_HANDLE_SENSOR
firmware 2.4
statevals devstate
Readings:
2017-05-31 19:46:08 1.STATE closed
2017-05-29 11:39:05 Activity alive
2017-05-31 19:46:07 battery ok
2017-05-31 19:46:08 hmstate closed
2017-05-31 19:46:08 state closed
Hmccu:
Dp:
0.aes_key:
VAL 1
0.config_pending:
VAL false
0.lowbat:
VAL false
0.rssi_device:
VAL 1
0.rssi_peer:
VAL 212
0.sticky_unreach:
VAL false
0.unreach:
VAL false
1.error:
VAL 0
1.lowbat:
VAL 0
1.state:
VAL 0
Attributes:
IODev CCU2
alias FK_Balkontuer3
ccureadingfilter STATE
devStateIcon tilted:fts_window_2w_tilt_l@yellow open:fts_window_2w_open_l@yellow closed:fts_window_2w@grey
group Fensterkontakte
hmstatevals ERROR!1:sabotage
room HM_CCU2
statedatapoint STATE
substitute STATE!0:closed,1:tilted,2:open;ERROR!0:no,1:sabotage
Ok, ich schaue es mir später mal an. Bei einem meiner optischen Kontakte ist es nicht so wie bei Dir:
2017-05-31 19:43:21 HMCCUCHN HM_TF_KU_Fenster1 1.STATE: open
2017-05-31 19:43:21 HMCCUCHN HM_TF_KU_Fenster1 open
2017-05-31 19:43:21 HMCCUCHN HM_TF_KU_Fenster1 battery: ok
2017-05-31 19:43:21 HMCCUCHN HM_TF_KU_Fenster1 hmstate: open
2017-05-31 19:44:06 HMCCUCHN HM_TF_KU_Fenster1 battery: ok
2017-05-31 19:44:06 HMCCUCHN HM_TF_KU_Fenster1 1.STATE: closed
2017-05-31 19:44:06 HMCCUCHN HM_TF_KU_Fenster1 closed
2017-05-31 19:44:06 HMCCUCHN HM_TF_KU_Fenster1 hmstate: closed
Kommt das vielleicht auf darauf an wie die Devices angelegt wurden und mit welchen Attributen?
Ev doppelte readings oder was weis ich?
LG
Die Definition der Fensterkontakte sieht eigentlich gut aus. Was mich irritiert ist der zeitliche Versatz zwischen den Events. Kann natürlich seinen Grund darin haben, dass FHEM gut ausgelastet ist.
Nutzt Du den internen oder den externen RPC Server (HMCCURPC).
Den neuen rpc.
Hast Du im IO-Device das Attribut ccudef-hmstatevals gesetzt? Wenn ja, auf welchen Wert?
ZitatHast Du im IO-Device das Attribut ccudef-hmstatevals gesetzt? Wenn ja, auf welchen Wert?
Nein habe ich nicht.
Sollte das gesetzt sein?
Zitat von: zap am 31 Mai 2017, 07:56:38
Ich nehme an, dass HMCCU die CCU nicht erreichen kann. Das kann an deinem Netz liegen oder an den Firewall Einstellungen auf der CCU. unifi kenne ich nicht.
Interessant wäre, welche Meldungen beim Laden von HMCCU kommen, wenn FHEM startet. Dabei interessieren mich weniger die Folgefehler bei der Definition. Der Devices. Normalerweise meldet HMCCU, wie viele Geräte von der CCUgelesenwurden
Ich habe hier mal das Log bei einem Neustart von FHEM. Habe das gröbste bereinigt was nichts mit HMCCU zu tun hat.
2017.06.01 19:18:24 1: HMCCURPC: Found 2 threads. Stopping ...
2017.06.01 19:18:24 1: HMCCURPC: Deregistering RPC server http://10.11.30.99:7411/fh2001 with ID CB2001 at http://10.11.30.100:2001/
2017.06.01 19:18:24 1: HMCCURPC: RPC callback for server CB2001 deregistered
2017.06.01 19:18:24 2: HMCCURPC: Sending signal INT to thread CB2001 TID=2
2017.06.01 19:18:24 2: CCURPC: RPC server CB2001 stopped handling connections. TID=2
2017.06.01 19:18:25 1: HMCCURPC: Found 1 threads. Stopping ...
2017.06.01 19:18:31 1: Including fhem.cfg
2017.06.01 19:18:31 3: telnetPort: port 7072 opened
2017.06.01 19:18:31 3: WEB: port 8083 opened
2017.06.01 19:18:31 3: WEBphone: port 8084 opened
2017.06.01 19:18:31 3: WEBtablet: port 8085 opened
2017.06.01 19:18:32 2: eventTypes: loaded 1615 events from ./log/eventTypes.txt
2017.06.01 19:18:32 3: Opening TRX_0 device /dev/ttyUSB0
2017.06.01 19:18:32 3: Setting TRX_0 serial parameters to 38400,8,N,1
2017.06.01 19:18:35 1: TRX: Init OK
2017.06.01 19:18:35 1: TRX: Init status: '433.92MHz transceiver, firmware=251, protocols enabled: ByronSX LightwaveRF AC ARC X10 '
2017.06.01 19:18:35 3: TRX_0 device opened
2017.06.01 19:18:36 3: tablet_ui: new ext defined infix:tablet: dir:./www/tablet:
2017.06.01 19:18:36 3: Registering HTTPSRV tablet_ui for URL /tablet and assigned link tablet ...
2017.06.01 19:18:36 3: Opening FB_FritzBox device 78.94.150.73:1012
2017.06.01 19:18:37 2: FRITZBOX FritzBox: Define.252 Modul functionality limited because of missing perl modules: Net::Telnet
2017.06.01 19:18:39 1: HMCCU: Device HMCCU. Initialized version 4.0.004
2017.06.01 19:18:39 1: PERL WARNING: Use of uninitialized value $dt in string ne at ./FHEM/88_HMCCU.pm line 3120, <$fh> line 787.
2017.06.01 19:18:40 1: HMCCU: Read 50 devices with 162 channels read from CCU 10.11.30.100
2017.06.01 19:18:40 3: HOMBOT (Hombot) - defined with host 10.11.30.120 on port 6260 and interval 180 (sec)
2017.06.01 19:18:40 1: HMCCURPC: Device HMCCU_rpc. Initialized version 0.95 beta
2017.06.01 19:18:40 1: Including ./log/fhem.save
2017.06.01 19:18:43 3: FB_CALLMONITOR (FB_FritzBox) - phonebooks found: Telefonbuch (id: 0)
2017.06.01 19:18:44 2: FB_CALLMONITOR (FB_FritzBox) - read 65 contacts from remote phonebook "Telefonbuch"
2017.06.01 19:18:44 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2017.06.01 19:18:51 3: LH_hub: connected
2017.06.01 19:18:51 1: usb create starting
2017.06.01 19:18:52 3: Probing CUL device /dev/ttyAMA0
2017.06.01 19:18:52 3: Can't open /dev/ttyAMA0: Permission denied
2017.06.01 19:18:52 1: usb create end
2017.06.01 19:18:52 2: SecurityCheck: WEBphone,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2017.06.01 19:18:52 0: Featurelevel: 5.8
2017.06.01 19:18:52 0: Server started with 175 defined entities (fhem.pl:14348/2017-05-22 perl:5.020002 os:linux user:fhem pid:12527)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 174 1046 --:--:-- --:--:-- --:--:-- 1200
2017.06.01 19:18:52 3: AT_HM_LC_DIM_Flur: []
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 98 590 --:--:-- --:--:-- --:--:-- 666
2017.06.01 19:18:52 3: AT_HM_LC_DIM_Eingang: []
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 195 1170 --:--:-- --:--:-- --:--:-- 1333
2017.06.01 19:18:52 3: AT_HM_LC_DIM_Esstisch: []
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 234 1404 --:--:-- --:--:-- --:--:-- 1714
2017.06.01 19:18:52 3: AT_HM_LC_DIM_Kueche: []
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 170 1020 --:--:-- --:--:-- --:--:-- 1333
2017.06.01 19:18:53 3: AT_HM_LC_DIM_Wintergarten: []
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 186 1118 --:--:-- --:--:-- --:--:-- 1333
2017.06.01 19:18:53 3: AT_HM_LC_BLND_Balkon01: []
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 259 1554 --:--:-- --:--:-- --:--:-- 1714
2017.06.01 19:18:53 3: AT_HM_LC_BLND_Balkon02: []
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 233 1399 --:--:-- --:--:-- --:--:-- 1714
2017.06.01 19:18:53 3: AT_HM_LC_BLND_Wohnzimmer: []
Device is not available.
2017.06.01 19:18:56 2: HMCCURPC: Starting thread for data processing
2017.06.01 19:18:57 2: HMCCURPC: Started thread for data processing. TID=1
2017.06.01 19:18:57 2: CCURPC: Thread DATA processing RPC events. TID=1
2017.06.01 19:18:57 2: HMCCURPC: RPC server thread started for interface BidCos-RF with TID=2
2017.06.01 19:18:57 2: CCURPC: Initializing RPC server CB2001 for interface BidCos-RF
2017.06.01 19:18:57 2: HMCCURPC: Callback server CB2001 created. Listening on port 7411
2017.06.01 19:18:57 2: HMCCURPC: Adding callback for events for server CB2001
2017.06.01 19:18:57 2: HMCCURPC: Adding callback for new devices for server CB2001
2017.06.01 19:18:57 2: HMCCURPC: Adding callback for deleted devices for server CB2001
2017.06.01 19:18:57 2: HMCCURPC: Adding callback for modified devices for server CB2001
2017.06.01 19:18:57 2: HMCCURPC: Adding callback for replaced devices for server CB2001
2017.06.01 19:18:57 2: HMCCURPC: Adding callback for readded devices for server CB2001
2017.06.01 19:18:57 2: HMCCURPC: Adding callback for list devices for server CB2001
2017.06.01 19:18:57 2: CCURPC: CB2001 accepting connections. TID=2
2017.06.01 19:18:58 1: HMCCURPC: RPC server(s) starting
2017.06.01 19:18:58 1: HMCCURPC: Received SL event. RPC server DATA enters server loop
2017.06.01 19:18:58 1: HMCCURPC: Received SL event. RPC server CB2001 enters server loop
2017.06.01 19:18:58 1: HMCCURPC: All threads working
2017.06.01 19:18:58 1: HMCCURPC: Registering callback http://10.11.30.99:7411/fh2001 with ID CB2001 at http://10.11.30.100:2001/
2017.06.01 19:18:58 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.06.01 19:18:59 1: HMCCURPC: RPC callback with URL http://10.11.30.99:7411/fh2001 registered
2017.06.01 19:18:59 1: HMCCURPC: Received IN event. RPC server CB2001 running.
2017.06.01 19:18:59 1: HMCCURPC: All RPC servers running
2017.06.01 19:18:59 2: HMCCU: No client devices matching .*
2017.06.01 19:18:59 2: HMCCURPC: Updated devices. Success=0 Failed=0
2017.06.01 19:19:00 2: CCURPC: CB2001 NewDevice received 189 device and channel specifications
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 55 331 --:--:-- --:--:-- --:--:-- 342
2017.06.01 19:19:00 3: AT_HM_LC_DIM_Flur: []
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 254 1529 --:--:-- --:--:-- --:--:-- 1714
2017.06.01 19:19:00 3: AT_HM_LC_DIM_Eingang: []
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 210 1264 --:--:-- --:--:-- --:--:-- 1714
2017.06.01 19:19:00 3: AT_HM_LC_DIM_Esstisch: []
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 233 1398 --:--:-- --:--:-- --:--:-- 1714
2017.06.01 19:19:00 3: AT_HM_LC_DIM_Kueche: []
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 236 1419 --:--:-- --:--:-- --:--:-- 1714
2017.06.01 19:19:00 3: AT_HM_LC_DIM_Wintergarten: []
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 231 1388 --:--:-- --:--:-- --:--:-- 1714
2017.06.01 19:19:00 3: AT_HM_LC_BLND_Balkon01: []
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 234 1404 --:--:-- --:--:-- --:--:-- 1714
2017.06.01 19:19:00 3: AT_HM_LC_BLND_Balkon02: []
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 14 0 2 100 12 229 1374 --:--:-- --:--:-- --:--:-- 1500
2017.06.01 19:19:01 3: AT_HM_LC_BLND_Wohnzimmer: []
Auffällig ist definitiv folgende Zeile:
2017.06.01 19:18:39 1: PERL WARNING: Use of uninitialized value $dt in string ne at ./FHEM/88_HMCCU.pm line 3120, <$fh> line 787.Seltsam finde ich noch:
2017.06.01 19:18:51 1: usb create starting
2017.06.01 19:18:52 3: Probing CUL device /dev/ttyAMA0
2017.06.01 19:18:52 3: Can't open /dev/ttyAMA0: Permission deniedIch habe seit Jahren keinen CUL mehr und sehen auch nicht wo hier noch etwas definiert sein könnte.
Zitat von: mrfloppy am 01 Juni 2017, 19:22:18
Nein habe ich nicht.
Sollte das gesetzt sein?
Nein, muss nicht. Habe ich auch nicht. Bin nur auf der Suche nach Unterschieden zwischen Deiner und meiner Konfiguration.
Zitat von: ph4 am 01 Juni 2017, 19:24:54
Auffällig ist definitiv folgende Zeile:
2017.06.01 19:18:39 1: PERL WARNING: Use of uninitialized value $dt in string ne at ./FHEM/88_HMCCU.pm line 3120, <$fh> line 787.
Seltsam finde ich noch:
2017.06.01 19:18:51 1: usb create starting
2017.06.01 19:18:52 3: Probing CUL device /dev/ttyAMA0
2017.06.01 19:18:52 3: Can't open /dev/ttyAMA0: Permission denied
Ich habe seit Jahren keinen CUL mehr und sehen auch nicht wo hier noch etwas definiert sein könnte.
Mit der CUL Meldung hat HMCCU definitiv nichts zu tun. Dazu solltest Du nochmal eine separate Frage im Forum stellen.
Die Fehlermeldung mit der dt Variable ist da evtl. schon hilfreicher.
Kannst Du bitte noch eine der Fehlermeldungen posten, die bei der Definition eines der Devices mit HMCCUDEV oder HMCCUCHN beim Starten von FHEM kommen?
Ich habe mir gerade die cfg angeschaut und bemerkt, dass alle meine HMCCU defines weg waren ....
Ich habe mal eine alte fhem.cfg wiederhergestellt und aktuell läuft alles wieder. Ich habe gerade wirklich keine Ahnung was da passiert ist.
Ich gehe am Wochenende noch einmal auf die Suche und berichte dann.
Wenn beim Start von FHEM aus welchen Gründen auch immer die Definition der HMCCUDEV/HMCCUCHN Devices fehl schlägt und Du z.B. autosave aktiv hast oder auch mal den Save Knopf drückst, wird natürlich ein fhem.cfg ohne diese Geräte gespeichert. Das gilt natürlich grundsätzlich für Devices in FHEM.
Da die Probleme aufgetreten sind, nachdem Du Deine Netzwerkkonfiguration geändert hast, würde ich erst mal bei Netzwerk mit der Fehlersuche anfangen.
Hallo zusammen,
ich würde gerne den ACK Status abfragen, damit ich mitbekommen, wenn etwas nicht funktioniert.
Ich habe mal folgendes Device hinzugefügt, aber bekomme kein Reading, auf welches ich reagieren könnte.
define EG_7_NW_Rollo_Gaestezimmer HMCCUDEV JEQ1234239
attr EG_7_NW_Rollo_Gaestezimmer IODev d_ccu
attr EG_7_NW_Rollo_Gaestezimmer ccuackstate 1
attr EG_7_NW_Rollo_Gaestezimmer room EG_Gäste,HMCCU
Was fehlt mit hier?
VG
Marc
Zitat von: Init am 03 Juni 2017, 16:13:24
ich würde gerne den ACK Status abfragen, damit ich mitbekommen, wenn etwas nicht funktioniert.
Ich habe mal folgendes Device hinzugefügt, aber bekomme kein Reading, auf welches ich reagieren könnte.
define EG_7_NW_Rollo_Gaestezimmer HMCCUDEV JEQ1234239
attr EG_7_NW_Rollo_Gaestezimmer IODev d_ccu
attr EG_7_NW_Rollo_Gaestezimmer ccuackstate 1
attr EG_7_NW_Rollo_Gaestezimmer room EG_Gäste,HMCCU
Wenn Du den Übertragungsstatus auf Protokollebene meinst: Den kennt nur die CCU. Wenn irgendwas bei der Kommunikation zwischen CCU und Geräten schief geht, wird das über die Datenpunkte UNREACH und STICKY_UNREACH signalisiert. Beide stehen in allen Homematic Geräten im Kanal 0 zur Verfügung. Normalerweise wertet HMCCU den Datenpunkt UNREACH automatisch aus und signalisiert eine Nichterreichbarkeit eines Gerätes über das Reading hmstate. Du kannst Dir die beiden Datenpunkte aber auch direkt als Reading holen, indem Du das Attribut ccureadingfilter entsprechend ergänzt, z.b.
ccureadingfilter mydev (STATE|UNREACH)
UNREACH kann 0/false oder 1/true werden. 1/true bedeutet "nicht erreichbar".
Das Attribut ccuackstate hat eine andere Funktion. Wenn das gesetzt ist, liest HMCCU direkt nach dem Setzen eines Datenpunktes über "Set datapoint" den aktuellen Wert von der CCU. Das hatte ich mal eingebaut, damit Statusänderungen beim internen RPC Server schneller zurückkommen. Seit es den externen RPC-Server gibt, ist das überflüssig geworden.
Danke für die Erklärung, dann nehme ich ccuackstate wieder raus.
Gibt es einen reading zur Überwachung der Kommunikation zwischen HMCCU und CCU?
Und wo du gerade über ccureadingfilter sprichst, worin besteht der Unterschied in der Filterung mittels ccureadingfilter und event-on-change-reading bzw. event-on-update-reading?
Die beiden letzteren sind mir klar, aber wo greift ccureadingfilter? Würde erst ccureadingfilter ziehen und dann update-reading und dann change-reading?
Reduziert ccureadingfilter das Datenaufkommen direkt im RPC-Server?
VG
Marc
Zitat von: Init am 04 Juni 2017, 16:02:35
Gibt es einen reading zur Überwachung der Kommunikation zwischen HMCCU und CCU?
Nein. Aber wenn beim Zugriff von HMCCU, HMCCUDEV oder HMCCUCHN auf die CCU etwas schief geht, wird STATE bzw. state des betroffenen Device auf "error" gesetzt. Probleme bei der umgekehrten Richtung CCU > FHEM landen im File /var/log/messages auf der CCU.
Zitat
Und wo du gerade über ccureadingfilter sprichst, worin besteht der Unterschied in der Filterung mittels ccureadingfilter und event-on-change-reading bzw. event-on-update-reading?
Die beiden letzteren sind mir klar, aber wo greift ccureadingfilter? Würde erst ccureadingfilter ziehen und dann update-reading und dann change-reading?
Die CCU schickt grundsätzlich alle geänderten Datenpunkte aller CCU Devices an den RPC-Server. Aber nur die Datenpunkte, die in ccureadingfilter enthalten sind, werden als Reading gespeichert.
Die event-on-... Attribute steuern nicht die Aktualisierung der Readings sondern in welchen Fällen FHEM ein Event generiert. Nämlich entweder nur dann, wenn sich ein Reading ändert oder auch dann, wenn ein Reading nur aktualisiert wird (auch mit dem gleichen Wert).
Zitat
Reduziert ccureadingfilter das Datenaufkommen direkt im RPC-Server?
Nein, s. Erklärung oben.
Guten Tag,
ich möchte mich daran machen, die Installation an meinem "Standort 2" (fast ausschließlich HM-Wired über CCU2) in fhem einzubuinden und habe nun schon viel über das HMCCU-Modul gelesen - aber eins wurde mir nicht ganz klar: Das gesamte Senden & Empfangen geht auch mit HMCCU nach wie vor über die CCU2 - oder könnte man da auch einen CUL einbinden bzw. würde das Vorteile bringen?
Sorry für die Grundsatzfrage, ich hoffe, ich habe nichts Offensichtliches übersehen.
Grüße
Martin
Zitat von: dadoc am 07 Juni 2017, 14:11:06
Das gesamte Senden & Empfangen geht auch mit HMCCU nach wie vor über die CCU2 - oder könnte man da auch einen CUL einbinden bzw. würde das Vorteile bringen?
HMCCU ist eine Schnittstelle zwischen FHEM und einer CCU. Du brauchst also entweder eine CCU2 oder OCCU bzw. Raspimatic für einen Raspberry mit entsprechendem Funkmodul (wobei ich nicht mal weiß, ob das wired unterstützt).
Mit der CCU2 bist Du jedenfalls auf der sicheren Seite.
Aber Du hast ja eigentlich schon alles was du brauchst. Warum also noch ein CUL kaufen.
Danke, dann werde ich mich ab Mitte des Monats mal reinstürzen. Den CUL habe ich allerdings eh schon seit längerem (HM-Konfigurationsadapter, auch an Standort 1 seit Jahren mit einem Raspi problemlos im Einsatz). Wenn alle Stricke reissen, kann ich die CCU2 also auch mal auf Pause setzen...
Grüße
Martin
Aus irgendeinem Grund wird mir ein bereitstehendes Firmware-Update nicht angezeigt.
Das Device List sagt:
Internals:
DEF 000855699C3194
IODev d_ccu
NAME HM_Licht_Aussen_Haustuer
NR 192
STATE true
TYPE HMCCUDEV
ccuaddr 000855699C3194
ccudevstate active
ccuif HmIP-RF
ccuname HM-Licht-Aussen-Haustuer
ccutype HmIP-BSM
channels 9
firmware 1.4.0
statevals devstate
Readings:
2017-06-08 20:16:27 0.CONFIG_PENDING false
2017-06-08 20:16:27 0.DUTY_CYCLE false
2017-06-08 20:16:27 0.ERROR_CODE 0
2017-06-08 20:16:27 0.ERROR_OVERHEAT false
2017-06-08 20:16:27 0.OPERATING_VOLTAGE 0.000000
2017-06-08 20:16:27 0.RSSI_DEVICE 199
2017-06-08 20:16:27 0.RSSI_PEER 199
2017-06-08 20:16:27 0.UPDATE_PENDING false
2017-06-04 22:36:37 1.PRESS_LONG 1
2017-06-08 09:27:21 1.PRESS_SHORT 1
2017-06-02 20:29:24 2.PRESS_LONG 1
2017-06-08 19:27:05 2.PRESS_SHORT 1
2017-06-08 20:16:27 3.PROCESS 0
2017-06-08 20:16:27 3.SECTION 2
2017-06-08 20:16:27 3.STATE true
2017-06-08 20:16:27 4.PROCESS 0
2017-06-08 20:16:27 4.SECTION 2
2017-06-08 20:16:27 4.STATE true
2017-06-08 20:16:27 5.PROCESS 0
2017-06-08 20:16:27 5.SECTION 0
2017-06-08 20:16:27 5.STATE false
2017-06-08 20:16:27 6.PROCESS 0
2017-06-08 20:16:27 6.SECTION 0
2017-06-08 20:16:27 6.STATE false
2017-06-08 20:16:27 7.CURRENT 0.000000
2017-06-08 20:16:27 7.ENERGY_COUNTER_OVERFLOW false
2017-06-08 20:16:27 Activity alive
2017-05-26 17:43:04 consumption 0.02
2017-06-08 20:16:27 energy 8.700000
2017-06-08 20:16:27 frequency 49.980000
2017-06-08 20:16:27 hmstate true
2017-06-08 20:16:27 measured-temp 0.000000
2017-06-08 20:16:27 power 0.020000
2017-06-08 20:16:27 state true
2017-06-08 20:16:27 temperature 0.000000
2017-06-08 20:16:27 voltage 228.200000
Hmccu:
Dp:
0.actual_temperature:
VAL 0.000000
0.config_pending:
VAL false
0.duty_cycle:
VAL false
0.error_code:
VAL 0
0.error_overheat:
VAL false
0.operating_voltage:
VAL 0.000000
0.rssi_device:
VAL 199
0.rssi_peer:
VAL 199
0.unreach:
VAL false
0.update_pending:
VAL false
1.press_long:
VAL 1
1.press_short:
VAL 1
2.press_short:
VAL 1
3.process:
VAL 0
3.section:
VAL 2
3.state:
VAL true
4.process:
VAL 0
4.section:
VAL 2
4.state:
VAL true
5.process:
VAL 0
5.section:
VAL 0
5.state:
VAL false
6.process:
VAL 0
6.section:
VAL 0
6.state:
VAL false
7.current:
VAL 0.000000
7.energy_counter:
VAL 8.700000
7.energy_counter_overflow:
VAL false
7.frequency:
VAL 49.980000
7.power:
VAL 0.020000
7.voltage:
VAL 228.200000
Attributes:
IODev d_ccu
room Homematic
Auf der CCU2 wird mir für das Gerät allerdings die Firmware 1.4.3 als Update angeboten.
Zugehöriges HMCCU Device:
Internals:
CCUNum 1
Clients :HMCCUDEV:HMCCUCHN:HMCCURPC:
DEF 192.168.188.28
NAME d_ccu
NR 161
NTFY_ORDER 50-d_ccu
RPCDEV d_ccu_rpc
RPCState running
STATE running/OK
TYPE HMCCU
ccuaddr BidCoS-RF
ccuchannels 229
ccudevices 50
ccuif BidCos-RF
ccuinterfaces BidCos-RF,HmIP-RF
ccuname HM-RCV-50 BidCoS-RF
ccutype CCU2
host 192.168.188.28
version 4.0.004
Readings:
2017-02-04 12:11:27 batterycount 3
2017-02-04 12:11:27 batterylist no match
2017-02-04 12:11:27 batterymatch 0
2017-02-04 12:11:27 batterystate no
2017-06-04 11:52:45 rpcstate running
2017-06-04 11:52:45 state OK
Hmccu:
evtime 0
evtimeout 0
rpccount 0
rpcports 2001,2010,9292
updatetime 0
Adr:
Hm-bm-aussen-hwr:
address 000955699D3F5E
addtype dev
valid 1
Hm-bm-aussen-hwr:0:
address 000955699D3F5E:0
addtype chn
valid 1
Hm-bm-aussen-hwr:1:
address 000955699D3F5E:1
addtype chn
valid 1
Hm-bm-eg-hwr:
address 0009156993C0BB
addtype dev
valid 1
Hm-bm-eg-hwr:0:
address 0009156993C0BB:0
addtype chn
valid 1
Hm-fernbedienung:
address 000B1569A3A70F
addtype dev
valid 1
Hm-fernbedienung:0:
address 000B1569A3A70F:0
addtype chn
valid 1
Hm-fernbedienung:1:
address 000B1569A3A70F:1
addtype chn
valid 1
Hm-fernbedienung:2:
address 000B1569A3A70F:2
addtype chn
valid 1
Hm-fernbedienung:3:
address 000B1569A3A70F:3
addtype chn
valid 1
Hm-fernbedienung:4:
address 000B1569A3A70F:4
addtype chn
valid 1
Hm-fernbedienung:5:
address 000B1569A3A70F:5
addtype chn
valid 1
Hm-fernbedienung:6:
address 000B1569A3A70F:6
addtype chn
valid 1
Hm-fernbedienung:7:
address 000B1569A3A70F:7
addtype chn
valid 1
Hm-fernbedienung:8:
address 000B1569A3A70F:8
addtype chn
valid 1
Hm-kontakt-aussen-garage-tuer:
address 0000D7098E3E3A
addtype dev
valid 1
Hm-kontakt-aussen-garage-tuer:0:
address 0000D7098E3E3A:0
addtype chn
valid 1
Hm-kontakt-eg-esszimmer-verandatuer:
address 0000D569A1ABC7
addtype dev
valid 1
Hm-kontakt-eg-esszimmer-verandatuer:0:
address 0000D569A1ABC7:0
addtype chn
valid 1
Hm-kontakt-eg-flur-haustuer:
address 0000D569A4A3B3
addtype dev
valid 1
Hm-kontakt-eg-flur-haustuer:0:
address 0000D569A4A3B3:0
addtype chn
valid 1
Hm-kontakt-eg-hwr-nebeneingang:
address 0000D569A4A1E2
addtype dev
valid 1
Hm-kontakt-eg-hwr-nebeneingang:0:
address 0000D569A4A1E2:0
addtype chn
valid 1
Hm-lc-bl1-fm neq1556470:1:
address NEQ1556470:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1556490:1:
address NEQ1556490:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1556498:1:
address NEQ1556498:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1556501:1:
address NEQ1556501:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1556506:1:
address NEQ1556506:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1556529:1:
address NEQ1556529:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1556533:1:
address NEQ1556533:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1556536:1:
address NEQ1556536:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1556537:1:
address NEQ1556537:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1556538:1:
address NEQ1556538:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1556541:1:
address NEQ1556541:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1556543:1:
address NEQ1556543:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1556573:1:
address NEQ1556573:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1556613:1:
address NEQ1556613:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1556615:1:
address NEQ1556615:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1558290:1:
address NEQ1558290:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1558291:1:
address NEQ1558291:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1558302:1:
address NEQ1558302:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1558314:1:
address NEQ1558314:1
addtype chn
valid 1
Hm-lc-bl1-fm neq1558421:1:
address NEQ1558421:1
addtype chn
valid 1
Hm-lc-bl1pbu-fm oeq0270036:1:
address OEQ0270036:1
addtype chn
valid 1
Hm-lc-sw4-dr neq0713037:
address NEQ0713037
addtype dev
valid 1
Hm-lc-sw4-dr neq0713037:0:
address NEQ0713037:0
addtype chn
valid 1
Hm-lc-sw4-dr neq0713037:2:
address NEQ0713037:2
addtype chn
valid 1
Hm-lc-sw4-dr neq0713037:3:
address NEQ0713037:3
addtype chn
valid 1
Hm-lc-sw4-dr neq0713037:4:
address NEQ0713037:4
addtype chn
valid 1
Hm-lc-sw4-dr neq1693996:
address NEQ1693996
addtype dev
valid 1
Hm-lc-sw4-dr neq1693996:0:
address NEQ1693996:0
addtype chn
valid 1
Hm-licht-aussen-hwr:
address NEQ1693996:2
addtype chn
valid 1
Hm-licht-aussen-hausdach:
address NEQ0713037:1
addtype chn
valid 1
Hm-licht-aussen-haustuer:
address 000855699C3194
addtype dev
valid 1
Hm-licht-aussen-haustuer:0:
address 000855699C3194:0
addtype chn
valid 1
Hm-licht-aussen-terrasse:
address 000855699C3153
addtype dev
valid 1
Hm-licht-aussen-terrasse:0:
address 000855699C3153:0
addtype chn
valid 1
Hm-licht-aussen-wohnzimmerdach:
address NEQ1693996:3
addtype chn
valid 1
Hm-licht-eg-esszimmer:
address 0008D5699C6021:4
addtype chn
valid 1
Hm-licht-eg-esszimmer:0:
address 0008D5699C6021:0
addtype chn
valid 1
Hm-licht-eg-flur:
address 000855699C314C
addtype dev
valid 1
Hm-licht-eg-flur:0:
address 000855699C314C:0
addtype chn
valid 1
Hm-licht-eg-hwr:
address 000855699C314F
addtype dev
valid 1
Hm-licht-eg-hwr:0:
address 000855699C314F:0
addtype chn
valid 1
Hm-licht-eg-treppe:
address 000895699E6615:2
addtype chn
valid 1
Hm-licht-eg-treppe:0:
address 000895699E6615:0
addtype chn
valid 1
Hm-licht-og-flur:
address 0008D5699C6001:4
addtype chn
valid 1
Hm-licht-og-flur:0:
address 0008D5699C6001:0
addtype chn
valid 1
Hm-licht-og-treppe:
address NEQ1693996:4
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:
address BidCoS-RF
addtype dev
valid 1
Hm-rcv-50 bidcos-rf:0:
address BidCoS-RF:0
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:1:
address BidCoS-RF:1
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:10:
address BidCoS-RF:10
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:11:
address BidCoS-RF:11
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:12:
address BidCoS-RF:12
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:13:
address BidCoS-RF:13
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:14:
address BidCoS-RF:14
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:15:
address BidCoS-RF:15
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:16:
address BidCoS-RF:16
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:17:
address BidCoS-RF:17
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:18:
address BidCoS-RF:18
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:19:
address BidCoS-RF:19
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:2:
address BidCoS-RF:2
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:20:
address BidCoS-RF:20
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:21:
address BidCoS-RF:21
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:22:
address BidCoS-RF:22
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:23:
address BidCoS-RF:23
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:24:
address BidCoS-RF:24
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:25:
address BidCoS-RF:25
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:26:
address BidCoS-RF:26
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:27:
address BidCoS-RF:27
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:28:
address BidCoS-RF:28
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:29:
address BidCoS-RF:29
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:3:
address BidCoS-RF:3
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:30:
address BidCoS-RF:30
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:31:
address BidCoS-RF:31
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:32:
address BidCoS-RF:32
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:33:
address BidCoS-RF:33
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:34:
address BidCoS-RF:34
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:35:
address BidCoS-RF:35
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:36:
address BidCoS-RF:36
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:37:
address BidCoS-RF:37
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:38:
address BidCoS-RF:38
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:39:
address BidCoS-RF:39
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:4:
address BidCoS-RF:4
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:40:
address BidCoS-RF:40
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:41:
address BidCoS-RF:41
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:42:
address BidCoS-RF:42
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:43:
address BidCoS-RF:43
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:44:
address BidCoS-RF:44
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:45:
address BidCoS-RF:45
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:46:
address BidCoS-RF:46
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:47:
address BidCoS-RF:47
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:48:
address BidCoS-RF:48
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:49:
address BidCoS-RF:49
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:5:
address BidCoS-RF:5
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:50:
address BidCoS-RF:50
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:6:
address BidCoS-RF:6
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:7:
address BidCoS-RF:7
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:8:
address BidCoS-RF:8
addtype chn
valid 1
Hm-rcv-50 bidcos-rf:9:
address BidCoS-RF:9
addtype chn
valid 1
Hm-rauch-eg-flur:
address 000A55699D5760
addtype dev
valid 1
Hm-rauch-eg-flur:0:
address 000A55699D5760:0
addtype chn
valid 1
Hm-rauch-eg-gaeste:
address 000A55699D5DB3
addtype dev
valid 1
Hm-rauch-eg-gaeste:0:
address 000A55699D5DB3:0
addtype chn
valid 1
Hm-rauch-og-flur:
address 000A55699D5703
addtype dev
valid 1
Hm-rauch-og-flur:0:
address 000A55699D5703:0
addtype chn
valid 1
Hm-rauch-og-kind1:
address 000A55699D56F2
addtype dev
valid 1
Hm-rauch-og-kind1:0:
address 000A55699D56F2:0
addtype chn
valid 1
Hm-rauch-og-kind2:
address 000A55699D570A
addtype dev
valid 1
Hm-rauch-og-kind2:0:
address 000A55699D570A:0
addtype chn
valid 1
Hm-rauch-og-schlafzimmer:
address 000A55699D5770
addtype dev
valid 1
Hm-rauch-og-schlafzimmer:0:
address 000A55699D5770:0
addtype chn
valid 1
Hm-rollo-eg-bad-ost:
address NEQ1556501
addtype dev
valid 1
Hm-rollo-eg-bad-ost:0:
address NEQ1556501:0
addtype chn
valid 1
Hm-rollo-eg-flur-ost:
address NEQ1556490
addtype dev
valid 1
Hm-rollo-eg-flur-ost:0:
address NEQ1556490:0
addtype chn
valid 1
Hm-rollo-eg-gaeste-sued:
address NEQ1556536
addtype dev
valid 1
Hm-rollo-eg-gaeste-sued:0:
address NEQ1556536:0
addtype chn
valid 1
Hm-rollo-eg-gaeste-west:
address NEQ1556537
addtype dev
valid 1
Hm-rollo-eg-gaeste-west:0:
address NEQ1556537:0
addtype chn
valid 1
Hm-rollo-eg-kueche-west:
address NEQ1556541
addtype dev
valid 1
Hm-rollo-eg-kueche-west:0:
address NEQ1556541:0
addtype chn
valid 1
Hm-rollo-eg-speisekammer-ost:
address NEQ1556543
addtype dev
valid 1
Hm-rollo-eg-speisekammer-ost:0:
address NEQ1556543:0
addtype chn
valid 1
Hm-rollo-eg-wohnzimmer-nord:
address NEQ1556613
addtype dev
valid 1
Hm-rollo-eg-wohnzimmer-nord:0:
address NEQ1556613:0
addtype chn
valid 1
Hm-rollo-eg-wohnzimmer-sued-1:
address NEQ1556573
addtype dev
valid 1
Hm-rollo-eg-wohnzimmer-sued-1:0:
address NEQ1556573:0
addtype chn
valid 1
Hm-rollo-eg-wohnzimmer-sued-2:
address NEQ1556615
addtype dev
valid 1
Hm-rollo-eg-wohnzimmer-sued-2:0:
address NEQ1556615:0
addtype chn
valid 1
Hm-rollo-eg-wohnzimmer-sued-3:
address NEQ1558302
addtype dev
valid 1
Hm-rollo-eg-wohnzimmer-sued-3:0:
address NEQ1558302:0
addtype chn
valid 1
Hm-rollo-eg-wohnzimmer-tuer-west:
address OEQ0270036
addtype dev
valid 1
Hm-rollo-eg-wohnzimmer-tuer-west:0:
address OEQ0270036:0
addtype chn
valid 1
Hm-rollo-eg-wohnzimmer-west-1:
address NEQ1556533
addtype dev
valid 1
Hm-rollo-eg-wohnzimmer-west-1:0:
address NEQ1556533:0
addtype chn
valid 1
Hm-rollo-eg-wohnzimmer-west-2:
address NEQ1558290
addtype dev
valid 1
Hm-rollo-eg-wohnzimmer-west-2:0:
address NEQ1558290:0
addtype chn
valid 1
Hm-rollo-og-allrum-west:
address NEQ1556538
addtype dev
valid 1
Hm-rollo-og-allrum-west:0:
address NEQ1556538:0
addtype chn
valid 1
Hm-rollo-og-ankleide-ost:
address NEQ1556498
addtype dev
valid 1
Hm-rollo-og-ankleide-ost:0:
address NEQ1556498:0
addtype chn
valid 1
Hm-rollo-og-bad-west:
address NEQ1558291
addtype dev
valid 1
Hm-rollo-og-bad-west:0:
address NEQ1558291:0
addtype chn
valid 1
Hm-rollo-og-kind1-sued:
address NEQ1556470
addtype dev
valid 1
Hm-rollo-og-kind1-sued:0:
address NEQ1556470:0
addtype chn
valid 1
Hm-rollo-og-kind1-west:
address NEQ1558314
addtype dev
valid 1
Hm-rollo-og-kind1-west:0:
address NEQ1558314:0
addtype chn
valid 1
Hm-rollo-og-kind2-ost:
address NEQ1556529
addtype dev
valid 1
Hm-rollo-og-kind2-ost:0:
address NEQ1556529:0
addtype chn
valid 1
Hm-rollo-og-kind2-sued:
address NEQ1558421
addtype dev
valid 1
Hm-rollo-og-kind2-sued:0:
address NEQ1558421:0
addtype chn
valid 1
Hm-rollo-og-schlafzimmer-ost:
address NEQ1556506
addtype dev
valid 1
Hm-rollo-og-schlafzimmer-ost:0:
address NEQ1556506:0
addtype chn
valid 1
Hm-schalter-og-kind1:
address NEQ0300159
addtype dev
valid 1
Hm-schalter-og-kind1:0:
address NEQ0300159:0
addtype chn
valid 1
Hm-schalter-og-kind1:1:
address NEQ0300159:1
addtype chn
valid 1
Hm-schalter-og-kind1:2:
address NEQ0300159:2
addtype chn
valid 1
Hm-schalter-og-kind2:
address NEQ0299748
addtype dev
valid 1
Hm-schalter-og-kind2:0:
address NEQ0299748:0
addtype chn
valid 1
Hm-schalter-og-kind2:1:
address NEQ0299748:1
addtype chn
valid 1
Hm-schalter-og-kind2:2:
address NEQ0299748:2
addtype chn
valid 1
Hm-strom-eg-steckdosen:
address NEQ1693996:1
addtype chn
valid 1
Hm-temperatur-aussen-garage:
address NEQ1141618
addtype dev
valid 1
Hm-temperatur-aussen-garage:0:
address NEQ1141618:0
addtype chn
valid 1
Hm-temperatur-wohnzimmer:
address 000E5569A2457D
addtype dev
valid 1
Hm-temperatur-wohnzimmer:0:
address 000E5569A2457D:0
addtype chn
valid 1
Hm-wds30-t-o neq1141618:1:
address NEQ1141618:1
addtype chn
valid 1
Hmip-swdo 0000d569a1abc7:1:
address 0000D569A1ABC7:1
addtype chn
valid 1
Hmip-swdo 0000d569a4a1e2:1:
address 0000D569A4A1E2:1
addtype chn
valid 1
Hmip-swdo 0000d569a4a3b3:1:
address 0000D569A4A3B3:1
addtype chn
valid 1
Hmip-swdo 0000d7098e3e3a:1:
address 0000D7098E3E3A:1
addtype chn
valid 1
Hmip-bdt 0008d5699c6001:1:
address 0008D5699C6001:1
addtype chn
valid 1
Hmip-bdt 0008d5699c6001:2:
address 0008D5699C6001:2
addtype chn
valid 1
Hmip-bdt 0008d5699c6001:3:
address 0008D5699C6001:3
addtype chn
valid 1
Hmip-bdt 0008d5699c6001:5:
address 0008D5699C6001:5
addtype chn
valid 1
Hmip-bdt 0008d5699c6001:6:
address 0008D5699C6001:6
addtype chn
valid 1
Hmip-bdt 0008d5699c6021:1:
address 0008D5699C6021:1
addtype chn
valid 1
Hmip-bdt 0008d5699c6021:2:
address 0008D5699C6021:2
addtype chn
valid 1
Hmip-bdt 0008d5699c6021:3:
address 0008D5699C6021:3
addtype chn
valid 1
Hmip-bdt 0008d5699c6021:5:
address 0008D5699C6021:5
addtype chn
valid 1
Hmip-bdt 0008d5699c6021:6:
address 0008D5699C6021:6
addtype chn
valid 1
Hmip-bsm 000855699c314c:1:
address 000855699C314C:1
addtype chn
valid 1
Hmip-bsm 000855699c314c:2:
address 000855699C314C:2
addtype chn
valid 1
Hmip-bsm 000855699c314c:3:
address 000855699C314C:3
addtype chn
valid 1
Hmip-bsm 000855699c314c:4:
address 000855699C314C:4
addtype chn
valid 1
Hmip-bsm 000855699c314c:5:
address 000855699C314C:5
addtype chn
valid 1
Hmip-bsm 000855699c314c:6:
address 000855699C314C:6
addtype chn
valid 1
Hmip-bsm 000855699c314c:7:
address 000855699C314C:7
addtype chn
valid 1
Hmip-bsm 000855699c314c:8:
address 000855699C314C:8
addtype chn
valid 1
Hmip-bsm 000855699c314f:1:
address 000855699C314F:1
addtype chn
valid 1
Hmip-bsm 000855699c314f:2:
address 000855699C314F:2
addtype chn
valid 1
Hmip-bsm 000855699c314f:3:
address 000855699C314F:3
addtype chn
valid 1
Hmip-bsm 000855699c314f:4:
address 000855699C314F:4
addtype chn
valid 1
Hmip-bsm 000855699c314f:5:
address 000855699C314F:5
addtype chn
valid 1
Hmip-bsm 000855699c314f:6:
address 000855699C314F:6
addtype chn
valid 1
Hmip-bsm 000855699c314f:7:
address 000855699C314F:7
addtype chn
valid 1
Hmip-bsm 000855699c314f:8:
address 000855699C314F:8
addtype chn
valid 1
Hmip-bsm 000855699c3153:1:
address 000855699C3153:1
addtype chn
valid 1
Hmip-bsm 000855699c3153:2:
address 000855699C3153:2
addtype chn
valid 1
Hmip-bsm 000855699c3153:3:
address 000855699C3153:3
addtype chn
valid 1
Hmip-bsm 000855699c3153:4:
address 000855699C3153:4
addtype chn
valid 1
Hmip-bsm 000855699c3153:5:
address 000855699C3153:5
addtype chn
valid 1
Hmip-bsm 000855699c3153:6:
address 000855699C3153:6
addtype chn
valid 1
Hmip-bsm 000855699c3153:7:
address 000855699C3153:7
addtype chn
valid 1
Hmip-bsm 000855699c3153:8:
address 000855699C3153:8
addtype chn
valid 1
Hmip-bsm 000855699c3194:1:
address 000855699C3194:1
addtype chn
valid 1
Hallo zusammen,
im Wiki steht:
In den CCU2 Gerätenamen dürfen keine Umlaute verwendet werden. Leerzeichen sind zulässig, können aber u.U. bei einigen Funktionen zu Problemen führen.
Da ich ein paar Dutzend Geräte mit hunderten von Kanäle habe und evtl. für die Nutzung mit HMCCU einzeln manuell umbenennen muss, die Frage:
- Bezieht sich obiges ausschließlich auf den Gerätenamen oder gilt das auch für die Kanalnamen eines Geräts?
- Was ist mit anderen Sonderzeichen wie / oder - oder : oder ñ usw?
- Welche Probleme können Leerzeichen verursachen?
- [edit] Gilt das auch für Gewerke- und Programmnamen und Systemvariablen?
Ideal wäre es, wenn man das positiv definieren könnte, d.h. welche Zeichen können problemlos genutzt werden.
Danke & Grüße
Martin
Zitat von: kjmEjfu am 08 Juni 2017, 20:25:48
Aus irgendeinem Grund wird mir ein bereitstehendes Firmware-Update nicht angezeigt.
Hast Du "get d_ccu firmware" ausgeführt? Nur dann werden die Firmware Infos aktualisiert, und das auch nur, wenn EQ3 auf der Download Seite keine syntaktischen Änderungen vorgenommen hat.
Die CCU informiert leider nicht aktiv per RPC Schnittstelle über Firmware Updates.
Zitat von: zap am 09 Juni 2017, 16:07:24
Hast Du "get d_ccu firmware" ausgeführt? Nur dann werden die Firmware Infos aktualisiert, und das auch nur, wenn EQ3 auf der Download Seite keine syntaktischen Änderungen vorgenommen hat.
Die CCU informiert leider nicht aktiv per RPC Schnittstelle über Firmware Updates.
ach so, schade.
Hatte gedacht, ich könnte mir über das Reading anzeigen lassen, wenn für die Geräte Firmware-Updates bereitstehen.
Wäre eine praktische Funktion gewesen, da die CCU2 meistens nicht anzeigt, wenn ein Update für ein beliebiges Gerät auf Durchführung wartet und man dadurch immer alle Geräte durchklicken muss.
So muss ich das wohl direkt auf der CCU2 mit einem Script lösen.
Zitat von: dadoc am 09 Juni 2017, 13:01:22
Ideal wäre es, wenn man das positiv definieren könnte, d.h. welche Zeichen können problemlos genutzt werden.
Danke & Grüße
Martin
Mit den druckbaren 7 Bit Ascii Zeichensatz bist Du auf der sicheren Seite. Also alle Zeichencodes zwischen 32 und 127.
Leerzeichen kannst Du verwenden. Habe ich auch und keine Probleme.
Die Regel gilt für Geräte, Kanäle, Programme und Systemvariablen. Aber eben nur für die Objekte, die Du in FHEM benutzen möchtest.
Zitat von: kjmEjfu am 09 Juni 2017, 16:11:53
ach so, schade.
Hatte gedacht, ich könnte mir über das Reading anzeigen lassen, wenn für die Geräte Firmware-Updates bereitstehen.
Wäre eine praktische Funktion gewesen, da die CCU2 meistens nicht anzeigt, wenn ein Update für ein beliebiges Gerät auf Durchführung wartet und man dadurch immer alle Geräte durchklicken muss.
So muss ich das wohl direkt auf der CCU2 mit einem Script lösen.
Du könntest einmal am Tag oder einmal pro Woche den get firmware Befehl per "at" ausführen lassen.
Zitat von: zap am 09 Juni 2017, 16:13:11
Mit den druckbaren 7 Bit Ascii Zeichensatz bist Du auf der sicheren Seite. Also alle Zeichencodes zwischen 32 und 127.
Danke - also auch den Bindestirch
- da hatte ich irgendwo hier im Thread gelesen, dass der wegen der "fhem-Bindestrich-Intoleranz" in Devicenamen nicht verwendet werden darf?
Hallo miteinander bin langsam mit den lesen und versuchen am Ende. Hab nach langen üben den CCU2 ins Fhem rein gekriegt und es zeigt mir auch den HMIP Wandthermostat an. Jetzt kommen meine Probleme wo ich nicht weiter komme. Wie kann ich automatisch z.b. alle 5 Minuten den Status von get HmIP_WTH_2_000A97098A31DF_1 abrufen lassen. Und wie kann ich über einen Fhem Befehl die Temperatur der Heizung ändern. Gibt es da vielleicht auch die Möglichkeit damit man die Temperatur über einen Schieber regeln kann? Genauso wollte ich die Temperatur Änderung auch später über ein notify mit einbauen.
Zitat von: dadoc am 09 Juni 2017, 16:19:56
Danke - also auch den Bindestirch - da hatte ich irgendwo hier im Thread gelesen, dass der wegen der "fhem-Bindestrich-Intoleranz" in Devicenamen nicht verwendet werden darf?
Du musst den Bindestrich in FHEM ja nicht verwenden. Beispiel: einer meiner Fenstersensoren heiß TF-WZ-Terrasse und der Kanal 1 heißt TF-WZ-Terrasse:1
Jetz kann ich z.B. in FHEM folgendes definieren:
define TF_WZ_Terrasse HMCCUDEV TF-WZ-Terrasse
Oder
define TF_WZ_Terrasse HMCCUCHN TF-WZ-Terrasse:1
sofern du den vollen Namen als Readingname verwendest, ersetzt HMCCU automatische ungültige Readingzeichen
Zitat von: Roland303 am 10 Juni 2017, 18:47:56
Hallo miteinander bin langsam mit den lesen und versuchen am Ende. Hab nach langen üben den CCU2 ins Fhem rein gekriegt und es zeigt mir auch den HMIP Wandthermostat an. Jetzt kommen meine Probleme wo ich nicht weiter komme. Wie kann ich automatisch z.b. alle 5 Minuten den Status von get HmIP_WTH_2_000A97098A31DF_1 abrufen lassen. Und wie kann ich über einen Fhem Befehl die Temperatur der Heizung ändern. Gibt es da vielleicht auch die Möglichkeit damit man die Temperatur über einen Schieber regeln kann? Genauso wollte ich die Temperatur Änderung auch später über ein notify mit einbauen.
Hast Du auch die Beiträge im Wiki gelesen? Dort erfährst Du, dass nach der Aktivierung des RPC Servers die Stati der Geräte in FHEM automatisch aktualisiert werden.
Für Dein Thermostat Device solltest du mal set defaults ausführen.
Dank dir für die Info, jetzt bin ich schon wieder viel weiter gekommen. Aber eine Frage hab ich noch, wie kann ich auch gleich die Zimmertemperatur und die Luftfeuchtigkeit mit anzeigen lassen. Wenn ich get HmIP_WTH_2_000A97098A31DF_1 deviceinfo eingebe steht es eben unter 1.ACTUAL_TEMPERATURE bzw.1.HUMIDITY drin. Ach und wie kann ich einstellen damit der Slider bei der Eingestellten Temperatur fest bleibt, den er stellt sich immer wieder auf 4,5 zurück. Die eingegenene Werte stimmen aber immer mit den HM Gerät überein.
Also entweder hast Du ccureadingfilter nicht korrekt gesetzt (sollte mit set defaults aber passieren). Oder der RPC Server läuft nicht oder du hast in rpcinterfaces nicht die HMIP Schnittstelle ausgewählt.
Verstehe leider gerade Bahnhof, ich habe es nach den Wiki gemacht. Ich habe in der config das drin:
define d_ccu HMCCU 192.168.178.62
attr d_ccu ccudef-readingfilter ^(LOW_?BAT|UNREACH)$
attr d_ccu ccudef-readingformat datapoint
attr d_ccu ccudef-readingname ^(.+\.)?AES_KEY$:sign;;^(.+\.)?LOW_?BAT$:battery;;^(.+\.)?BATTERY_STATE$:batteryLevel;;^(.+\.)?UNREACH$:Activity;;^(.+\.)?TEMPERATURE$:+temperature;;^(.+\.)?SET_TEMPERATURE$:+desired-temp;;^(.+\.)?HUMIDITY$:+humidity;;^(.+\.)?LEVEL$:+pct;;^(.+\.)?CONTROL_MODE$:+controlMode
attr d_ccu ccudef-substitute AES_KEY!(0|false):off,(1|true):on;;LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;;UNREACH!(0|false):alive,(1|true):dead;;MOTION!(0|false):noMotion,(1|true):motion;;DIRECTION!0:stop,1:up,2:down,3:undefined;;WORKING!0:false,1:true;;INHIBIT!(0|false):unlocked,(1|true):locked
attr d_ccu ccuflags extrpc
attr d_ccu rpcinterfaces BidCos-Wired,BidCos-RF,VirtualDevices
attr d_ccu rpcinterval 2
attr d_ccu rpcport 2000,2001,9292
attr d_ccu rpcqueue /tmp/ccuqueue
attr d_ccu rpcserver on
attr d_ccu stateFormat rpcstate/state
define d_ccu_rpc HMCCURPC 192.168.178.62
attr d_ccu_rpc stateFormat rpcstate/state
attr d_ccu_rpc verbose 2
dann mit den Befehl :
get d_ccu devicelist create ^Ther.* t=dev f=HM_%n room=Homematic und danach set HM_Thermostat defaults
die Sachen geholt und das ist raus gekommen
define HM_Thermostat HMCCUDEV 000A97098A31DF
attr HM_Thermostat IODev d_ccu
attr HM_Thermostat controldatapoint 1.SET_POINT_TEMPERATURE
attr HM_Thermostat eventMap /datapoint 1.BOOST_MODE true:Boost/datapoint 1.CONTROL_MODE 0:Auto/datapoint 1.CONTROL_MODE 1:Manual/datapoint 1.CONTROL_MODE 2:Holiday/datapoint 1.SET_POINT_TEMPERATURE 4.5:off/datapoint 1.SET_POINT_TEMPERATURE 30.5:on/
attr HM_Thermostat room Wohnzimmer
attr HM_Thermostat statedatapoint 1.SET_POINT_TEMPERATURE
attr HM_Thermostat stripnumber 1
attr HM_Thermostat substexcl control
attr HM_Thermostat substitute SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;;WINDOW_STATE!(0|false):closed,(1|true):open
attr HM_Thermostat webCmd control:Boost:Auto:Manual:Holiday:on:off
attr HM_Thermostat widgetOverride control:slider,4.5,0.5,30.5,1
Wäre super wenn du mir sagen könntest wo mein Fehler ist
Zunächst wäre es hilfreich, wenn Du nächstes Mal den code Tag benutzt (die Raute im Forum Editor). Dann wird das etwas übersichtlicher.
Du hast doch HM-IP Geräte, oder? Dann musst Du beim Attribut rpcinterfaces auch HM-IP auswählen. Wenn dann nach einem Neustart des RPC-Servers immer noch keine Readings automatisch aktualisiert werden, solltest Du Dir mal das FHEM Logfile anschauen und prüfen, ob da Fehlermeldungen von HMCCU oder HMCCURPC drin sind.
Dank dir, du hast mir super weiter geholfen. Wieder was gelernt, so macht es Spaß
Hallo zusammen,
gibt es die Möglichkeit bei einem Taster die Zeit von
1\.PRESS_(SHORT|LONG).*
als Status anzeigen zu lassen?
Momentan habe ich dort immer "Initialized" stehen.
VG
Marc
Möchtest du den Status von PFESS_XX in STATE oder was meinst du genau mit "Zeit"?
Ne, der Status von PRESS_XX ist bei mir ja immer pressed, daher hatte ich drüber nachgedacht, was hier Sinn ergeben könnte. Und da dachte ich mir, dass ich von 1\.PRESS_(SHORT|LONG).* die Zeit des letzten updates anzeigen könnte.
Hallo zusammen,
ich habe folgenden Taster über RaspberryMatic in FHEM eingebunden:
https://www.elv.de/homematic-schaltaktor-fuer-batteriebetrieb-komplettbausatz.html
Was muß ich jetzt wie konfigurieren, damit ich beim Device einen Button sehe, der beim drücken für eine Sekunde schließt und dann wieder öffnet. Ich möchte damit ein Garagentor steuern, das über eine Ein-Knopf-Steuerung funktioniert.
Vielen Dank.
Grüße Mave
Zitat von: Mave am 17 Juni 2017, 16:54:44
Was muß ich jetzt wie konfigurieren, damit ich beim Device einen Button sehe, der beim drücken für eine Sekunde schließt und dann wieder öffnet. Ich möchte damit ein Garagentor steuern, das über eine Ein-Knopf-Steuerung funktioniert.
Ich habe mein Garagentor über einen HM-LC-Sw1-Pl-CT-R1 angebunden (das ist die Schaltsteckdose mit potenzialfreiem Ausgang). Das dürfte weitgehend ähnlich sein. Wenn Du Deinen Schalter mit HMCCUCHN definierst, könnte es wie folgt aussehen:
attr mydev ccureadingfilter (STATE|WORKING)
attr mydev cmdIcon press:fts_garage
attr mydev event-on-change-reading .*
attr mydev eventMap /on-for-timer 1:press/
attr mydev statedatapoint STATE
attr mydev statevals on:true,off:false
attr mydev substitute STATE!(0|false):off,(1|true):on;WORKING!(0|false):no,(1|true):yes
attr mydev webCmd press
Bei HMCCUDEV ersetzt Du beim Attribut statedatapoint STATE durch 1.STATE
Außerdem musst Du beim Attribut eventMap aufpassen. Ich habe hier als Schaltdauer für on-for-timer 1 Sekunde angegeben. Der Wert ist abhängig von der Motorsteuerung.
Das eventMap Attribut erzeugt einen "Set press" Befehl. Dafür wird mit CmdIcon und WebCmd ein Button definiert.
Zitat von: Init am 17 Juni 2017, 16:01:44
Ne, der Status von PRESS_XX ist bei mir ja immer pressed, daher hatte ich drüber nachgedacht, was hier Sinn ergeben könnte. Und da dachte ich mir, dass ich von 1\.PRESS_(SHORT|LONG).* die Zeit des letzten updates anzeigen könnte.
Das geht über das FHEM Standardattribut stateFormat. Dieses Attribut setzt Du nicht auf einen Readingname sondern auf einen Perl-Code, der mit der Funktion ReadingsTimestamp die Zeit der letzten Änderung ermittelt.
Ungefähr so (nicht getestet):
attr mydev stateFormat { ReadingsTimestamp ("mydev", "1.PRESS_SHORT", "n/a") }
Hallo zap,
super, vielen Dank. Hat super funktioniert.
Allerdings würde ich gerne das, was Du jetzt alles geschrieben und ich umgesetzt habe, auch verstehen.
Ich möchte nämlich gleich im Anschluß noch eine Aussenlampe über einen Bewegungsmelder schalten, die aber nur bei Dunkelheit angehen soll.
Auch da stehe ich im Moment noch voll auf dem Schlauch und aus dem Wiki werde ich teilweise nicht wirklich schlau.
Wärst Du so lieb und würdest mir noch erklären, was die einzelnen Attribute genau machen?
Vielen Dank.
Grüße Mave
Mach das doch besser in der CCU! Entweder per Direktverknüpfung oder per Programm.
zap,
eines ist mir noch aufgefallen:
Als StatusIcon bekomme ich die Glühbirne, die nach Klicken des GaragenIcons für 1 Sekunde an geht. Damit wird quasi das Drücken des Tasters symbolisiert.
Allerdings kann ich auch auf die Glühbirne draufklicken und dann bleibt sie dauerhaft an. Ist damit der Taster auch dauerhaft gedrückt?
Kann ich eventuell das Klicken auf die Glühbirne ohne Funktion setzen?
Vielen Dank.
Grüße Mave
Hallo Ralli,
vielen Dank für den Tipp. Das wäre auch eine Möglichkeit, ja.
Allerdings würde ich das gerne zu Übungszwecken in FHEM realisieren.
Irgendwie muß ich das ja alles mal lernen....
Grüße Mave
Wirf das statevals Attribut wieder raus, dann sollte die Lampe verschwinden.
Mit der Verknüpfung hat Ralli recht. Ziel von HMCCU ist es nicht, die CCU zu ersetzen, sondern FHEM mit der CCU zu verbinden. Das, was man besser in der CCU machen kann, sollte man auch da machen (direkte Verknüpfungen bzw Peering oder auch Heizungsgruppen). Das meine ich mit "best of both worlds".
Natürlich kannst du das auch alles in FHEM machen, ist aber viel aufwändiger (mit Noftify und anderen Nettigkeiten).
Zur Erklärung der Attribute (nur die nicht FHEM Standard sind):
ccureadingfilter legt fest, welche Datenpunkte eines CCU Gerätes als Readings gespeichert werden.
Substitute ersetzt Werte der CCU durch sprechendere Werte
Statedatapoint lett fest, welcher Datenpunkt als STATE im FHEM Device angezeigt wird.
Das ist eigentlich schon alles. Der Rest ist FHEM Standard.
Super, vielen Dank.
Zitat von: zap am 17 Juni 2017, 19:04:28
Ungefähr so (nicht getestet):
attr mydev stateFormat { ReadingsTimestamp ("mydev", "1.PRESS_SHORT", "n/a") }
Hi zap,
jetzt funktioniert alles - danke!
Musste allerdings noch ein paar Anpassungen machen, da ich den ReadingsTimestamp von (PRESS_SHORT|PRESS_LONG) haben wollte.
Habe hierzu ein Substitute angelegt und noch mein event-on-update-reading auf das neue attr angepasst.
Hier mein komplettes define:
define HMW_HSK1_BM_Esszimmer HMCCUCHN LEQ1286184:3
attr HMW_HSK1_BM_Esszimmer IODev d_ccu
attr HMW_HSK1_BM_Esszimmer ccureadingname 3.PRESS_(SHORT|LONG):pressed
attr HMW_HSK1_BM_Esszimmer dependencyDevice HMW_HSK1_Strahler_Terrasse
attr HMW_HSK1_BM_Esszimmer dependencyValue 30
attr HMW_HSK1_BM_Esszimmer event-on-update-reading pressed
attr HMW_HSK1_BM_Esszimmer group Bewegungsmelder,HMW_HSK1_Hauptsicherungskasten
attr HMW_HSK1_BM_Esszimmer room Garten,HMCCU
attr HMW_HSK1_BM_Esszimmer stateFormat { ReadingsTimestamp ("HMW_HSK1_BM_Esszimmer", "pressed", "n/a") }
attr HMW_HSK1_BM_Esszimmer substitute PRESS_SHORT,PRESS_LONG!(1|true):pressed
Achja, ich musste auch noch ccureadingname um das neue attr erweitern, wobei mir nicht ganz klar ist warum. Dachte das ccureadingname nur auf die "echten" Datenpunkte der CCU reagiert.
VG
Marc
In deinem Fall reagiert doch ccureadingname auf echte Datenpunkte, nämlich auf PRESS_SHORT oder PRESS_LONG. Du hast das genau richtig gemacht, denn das Attribut kann nicht nur Readings umbenennen sondern auch wie in Deinem Fall mehrere zusammenfassen.
Nach über 100 Seiten und mehr als 100000 Aufrufen mache ich den Thread hier dicht. Lesen tut das eh keiner alles und übersichtlich ist es auch nicht.
Bitte Fragen und Probleme zu HMCCU, HMCCUDEV, HMCCUCHN und HMCCURPC in neuen, dedizierten Threads im FHEM Homematic Forum einstellen. Bitte beim Subject wenn möglich den Modulnamen davor schreiben, damit man den Beitrag von CUL, HMLAN usw unterscheiden kann.