Neues Modul HMCCU für Homematic CCU

[zap]

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

[zap]

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.

[chris1284]

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)

[zap]

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.

[Loredo]

Wofür ist denn dann INHIBIT? Verstehe ich nicht.

[rubinho]

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 
Und ich geb dir recht, EQ3 könnte da mehr dokumentieren. Das ist ja wie im drüben zu fischen.... 

[rubinho]

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.

[zap]

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.

[chris1284]

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)

[zap]

und nochmal ein Update für 88_HMCCU.pm hinterher ...
Kleiner Bug in "substexcl" gefixt.

[chris1284]

Wenn "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?

[zap]

ä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

[chris1284]

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

[zap]

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

[chris1284]

kein problem iss dich satt, ruh dich aus 

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)

   "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
   },

Readingname mit einem "+" beginnt, wird dieses Reading zusätzlich erzeugt

top, danke somit fliegen diverse userreadings raus