Neues (altes) Modul: Homematic CCU mit XML-RPC an FHEM, HMRPC reborn

[trilu]

@Ralli - vielen Dank, jetzt klappt es.

Ich habe das Modul zusammen mit Homegear in Betrieb und für einfache Schaltaufgaben komme ich jetzt damit klar.
Interessant wird es bei komplexeren Sachen, wie Wochenprogramm für Thermostate

Code Auswählen Erweitern


ENDTIME_FRIDAY_1
ENDTIME_FRIDAY_10
ENDTIME_FRIDAY_11
ENDTIME_FRIDAY_12
ENDTIME_FRIDAY_13
...
TEMPERATURE_FRIDAY_1
TEMPERATURE_FRIDAY_10
TEMPERATURE_FRIDAY_11
TEMPERATURE_FRIDAY_12
TEMPERATURE_FRIDAY_13
...


Im Normalfall werden diese Variablen gesetzt und mit einem putParamSet ans Device übertragen.
So wie ich das RPC Modul verstehe, wird hier jeder einzelne Wert mit setValue übertragen. Was ein sofortiges Update ans Device veranlasst.

Hast Du eine Idee wie man das lösen könnte?

Viele Grüße
Horst

[Ralli]

Hallo Horst,

fein, dass es jetzt klappt.

... bisher nicht, da ich diese im Regelfall eher selten zu ändernden Dinge aus der CCU2 heraus mache. Ich fürchte, dafür wäre eine größere Modifikation notwendig.

[Raymund]

@trilu

putParamSet ist wohl schon implementiert: https://groups.google.com/forum/#!topic/fhem-users/xKMH_4ZoMNA

Siehe auch in der 60_HMRPC, sub HMRPC_Set. Habe es aber noch nicht getestet.

Gruß
Raymund

[trilu]

Hatte ich auch entdeckt, bin gerade am testen

[zap]

Also in henryks HMRPC Set gibt es zwar einen putparamset Call, allerdings setzt der nur einen Wert gleichzeitig.
Das müsste man noch ausbauen ...
Aber wie stellt Ihr Euch eigentlich den Aufruf eines solchen Set Befehls in FHEM vor?

Sowas in der Form:

set xy paramset Datapoint Value Datapoint Value ...

Nur so als Anregung für mich

[Ralli]

putParamSet ist wohl schon implementiert: https://groups.google.com/forum/#!topic/fhem-users/xKMH_4ZoMNA
Siehe auch in der 60_HMRPC, sub HMRPC_Set. Habe es aber noch nicht getestet.

Im Code ist nur (rudimentär) die Möglichkeit eingebaut, putParamset zu nutzen:

Code Auswählen Erweitern


my $paramset={$a[3]=>$a[4]};

$ret=$hash->{client}->simple_request("putParamset",$a[1],$a[2],$paramset);


Eine komfortable Möglichkeit, wie sie wahrscheinlich Horst (trilu) vorschwebt, ist damit m.E. noch nicht realisierbar. Daher: um bspw. die gleiche Funktionalität wie im Modul CUL_HM einzubauen, dürften deutliche Modifikationen/Ergänzungen notwendig sein.

[zap]

Code Auswählen Erweitern


ENDTIME_FRIDAY_1
ENDTIME_FRIDAY_10
ENDTIME_FRIDAY_11
ENDTIME_FRIDAY_12
ENDTIME_FRIDAY_13


Die Verwaltung der einzelnen Zeiten/Werte müsste hier im FHEM Modul erfolgen, da die Thermostate keine Datenpunkte dafür anbieten (und nur die können ja per setvalue/putparamset gesetzt werden.
Sehr aufwändig.

[trilu]

Klar bietet der Thermostat diese Datenpunkte, die sind nur nicht sichtbar, weil im Master Set. Das MDDEV liest derzeit aber nur VALUE nach Channel aus.
Ich bin mir noch nicht ganz sicher, wie ich es eigentlich gerne möchte - Man kann ja derzeit ein Gerät, oder eine Reihe von Geräten nach Channel definieren.

Also entweder etwas wie HMDEV_JEQ0276495
oder eine Geräteliste wie HMDEV_JEQ0276495:0, HMDEV_JEQ0276495:1 usw.

Von der Übersichtlichkeit auf erster Ebene würde sich die generelle Definition anbieten (HMDEV_JEQ0276495), es gibt nur ein Gerät mit allen Parametern im Bauch.
Allerdings wäre die Readingsliste bei einem Thermostat ziemlich lang und man müsste allen Readings ein Flag bzgl Kanal und MASTER/VALUES mitgeben.

Die Alternative, Geräte werden mit :0, :1, etc angelegt - damit wäre es auf erster Ebene unübersichtlicher, aber die Readingsliste würde sich in Grenzen halten und bräuchte nur das Flag bzgl MASTER/VALUE.

Was meint ihr?

[Ralli]

Hat beides sein Für und Wieder.

Ich habe mich entscheiden, auf den jeweiligen Channel zu gehen - der Übersichtlichkeit halber und weil die verschiedenen Channel teilweise auch verschiedenen Räumen zugeordnet werden.

Der für mich einzige Nachteil besteht darin, dass ein UNREACH auf :0 empfangen wird und so ins Leere läuft. Da überlege ich aber zur Zeit, ob ich diesen Spezialfall nicht im HMDEV-Code abfange und auf jeden Channel, welches zu dem entsprechenden Device gehört, gebe.

Die Thermostate sind ebenfalls recht spezielle Devices, bei denen die jeweiligen Kanäle (oder zumindest Teile daraus) m.E. durchaus in einem einzigen fhem-Device abgebildet sein sollten. Es kommt halt immer darauf an, was man für einen Ansatz wählt. Mein Ansatz besteht nicht darin, die Wochenprogramme zwingend über fhem ändern zu lassen.

[trilu]

Shit, jetzt bin ich so schlau wie vorher

Derzeit stelle ich das Wochenprogramm auch nicht über FHEM, aber es hätte was, das über ein Modul der Tablet UI zu machen.
Da ist es dann aber egal, ob alles in ein Device oder mehrere geht. Momentan tendiere ich auch zu mehreren Devices.

Wozu brauchst Du den UNREACH in allen Kanälen?

[Ralli]

Stelle Dir einen Doppel-Schalter-Aktor vor. Der eine Kanal ist für das Licht in einem Raum, der andere Kanal für das Licht in einem anderen Raum. Also sind für mich grds. :1 und :2 interessant. Aber in :0 stehen für mich (in fhem) grds. keine interessanten Dinge drin - ausser, das Device ist nicht erreichbar. Aber nur dafür will ich nicht noch extra ein :0 in fhem definieren. Da gebe ich lieber dann, wenn das Problem auftritt, ein UNREACH in fhem an die Kanäle des betroffenen Devices weiter.

Bei einem Rolladen-Aktor ist es gleich. :1 ist interessant für mich, :0 normalerweise nicht - nur bei einem UNREACH.

[trilu]

ich schau mal was sich machen lässt. hat es eigentlich einen grund warum du die readings spezifizierst?

Code Auswählen Erweitern

case ["SHUTTER_CONTACT","ROTARY_HANDLE_SENSOR"] {
@readingslist=("STATE","LOWBAT");
}


man könnte doch alle abfragen?

Code Auswählen Erweitern

2015.12.01 11:27:05 0: HMRPC hmrf statusRequest JEQ0276495:0: TYPE is MAINTENANCE
2015.12.01 11:27:06 0: HMRPC hmrf $ret = {
         'CONFIG_PENDING' => 0,
         'RSSI_PEER' => '0',
         'BOOT' => 0,
         'RSSI_DEVICE' => '-69',
         'STICKY_UNREACH' => 0,
         'LOWBAT' => 0,
         'UNREACH' => 0
       };

2015.12.01 11:27:06 0: HMRPC hmrf got 7 keys, @keylist = (
             'CONFIG_PENDING',
             'RSSI_PEER',
             'BOOT',
             'RSSI_DEVICE',
             'STICKY_UNREACH',
             'LOWBAT',
             'UNREACH'
           );

2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: updating Reading CONFIG_PENDING to 0
2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: updating Reading RSSI_PEER to 0
2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: updating Reading BOOT to 0
2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: updating Reading RSSI_DEVICE to -69
2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: updating Reading STICKY_UNREACH to 0
2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: updating Reading LOWBAT to 0
2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: updating Reading UNREACH to 0
2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: succesful


[Ralli]

Mir ging es wirklich nur um einen statusRequest - und nicht um ein getConfig. Darum habe ich nur die für den Betrieb wesentlichen Datenpunkte/Readings hier abgefragt - wie gesagt, im Hinterkopf behalten, dass ich normalerweise kein :0 habe.

Bei einem getConfig würde ich hingegen tatsächlich immer das :0 mit allen Datenpunkten und alle verfügbaren Datenpunkte aller Channels abfragen und entsprechend in den Readings aktualisieren. Das habe ich aber bisher eben nicht implementiert, da ich keinen Anwendungszweck dafür habe .

[trilu]

Du hast recht, ich baue gerade ein getConfig

[Ralli]

Ich habe meine 60_HMDEV.pm bezüglich des thematisierten UNREACH auf alle Channels erweitert. Quick and dirty nach Zeile 83:

Code Auswählen Erweitern


      if($msg =~ /HMDEV ([A-Z]{3}[0-9]{7}):[0-9]{1,2} UNREACH ([01])/) {
      fhem("setreading DEF=$1:..? unreachable $2");
      }


Edit: Funktioniert aber bewusst nur, wenn der Channel (also normalerweise :0), welcher UNREACH produziert, nicht definiert ist.