HMCCU: Version 4.3 verfügbar

Begonnen von zap, 11 September 2018, 10:40:03

Vorheriges Thema - Nächstes Thema

zap

Zitat von: kotaro am 06 Oktober 2019, 11:35:59
so wie ich das verstanden habe, ist es für eine bessere Steuerung der Geräte gedacht. Aus Programmen soll man die Virtuellen Taster drücken. Diese Virtuellen Taster kannst du aber direkt mit dem Gerät peeren, und hast eine bessere Latenz und so...
zumindest, habe ich das so verstanden mal..

Kann man so nutzen, man kann aber auch nach Druck auf eine virtuelle Taste ein Programm ausführen lassen, da z.B. mehrere andere Aktoren auslöst.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

kotaro

Ich habe mal eine frage,
und zwar kann ich bei HmIP-Devices kein get configlist, oder get configdesc machen, bzw kommt dabei nix zurück....
Hast du da eine Idee??
würde ja gerne meine Wochenprogramme abfragen mit get xx configlist P1

lg

zap

Zitat von: kotaro am 06 Oktober 2019, 11:43:43
Ich habe mal eine frage,
und zwar kann ich bei HmIP-Devices kein get configlist, oder get configdesc machen, bzw kommt dabei nix zurück....
Hast du da eine Idee??
würde ja gerne meine Wochenprogramme abfragen mit get xx configlist P1

lg

Da unterscheiden sich die Config-Parameter von den Datenpunkten: Datenpunkte hängen immer an Kanälen, Config-Parameter können Device oder Kanal bezogen sein. In letzterem Fall könnte z.B.

get xx configlist 1

funktionieren. Könnte, weil vom Devicetype abhängig. Am einfachsten bekommst Du die Kanalnummern raus, indem Du Dir in der CCU unter den Geräteeinstellungen anschaust, in welchem Kanal das Wochenprogramm liegt.

Übrigens: get configlist gibt nur die Werte auf dem Bildschirm aus. Um sie als Readings zu bekommen, musst Du "get config" benutzen.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

kotaro

Danke, klappt mit 1... bei HM braucht man garnix einzugeben, und erhält alle werde, was manchmal für erste suche ganz praktisch ist

gibt es eigentlich eine Möglichkeit, die Werte, mit get configlist in einem eigenen Modul auszuwerten? oder benötigt man dazu Reading-Werte?
Okay, das gehört bestimmt nicht hier rein ^^

zap

Ich kann mich irren, aber soweit ich weiß, liefern einige HmIP Geräte die Wochenprogramme auch als Datenpunkte. Das hätte den Vorteil, dass die CCU aktiv darüber informiert während du bei get config die Parameter explizit abfragen musst.

Schau dir mal mit "get deviceinfo " die verfügbaren Datenpunkte an.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

zap

Es gibt ein kleines Update für HMCCU, HMCCUCHN und HMCCUDEV im SVN mit folgenden Änderungen:


  • Die Fehlerbehandlung wurde optimiert
  • Der Befehl set datapoint im HMCCU I/O Device akzeptiert nun Standard FHEM Devspecs
  • Fehler bei set/get Befehlen korrigiert, der zu ungewollten Bildschirmausgaben führte
  • Erste, experimentelle Unterstützung von attrTemplates
  • Neues ccuflag logCommand. Protkollierung von set und get Befehlen bei Verbose Level >= 3

Die attrTemplates werden mittelfristig die Default-Settings ablösen.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

slor

Danke für das Update!
Gibt es schon Beispiele, Anleitung, Dokumentation zu attrTemplates und HMCCU?

Habe nur einen Eintrag im Dev Forum dazu gefunden.
Setze gerade mein Fhem neu mit HMCCu auf und würde das gerne nutzen für ein paar Gerätetypen.
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

zap

Die entsprechenden Template Files liegen im FHEM Verzeichnis unter

FHEM/lib/AttrTemplate

Die Datei hmccu.template enthält einige Templates für Homematic Devices. Die Devices vom Typ HMCCUDEV und HMCCUCHN haben - sofern für den Typ ein Template hinterlegt ist - den Befehl set attrTemplate
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Dek

#353
Hallo zusammen,

ich habe ein Problem damit einen Config-Parameter bei einem HMIP Gerät zu setzen.

Es ist ein HmIP-eTRV-C, bei dem ich gerne die maximale Ventilöffnung setzen möchte.
Ech bekomme den Wert ausgelesen, und wenn ich ihn vorher per HM-Script gesetzt habe, passt das auch, und das Ventil verfährt, funktioniert also mal prinzipiell.

Wenn ich jetzt aber

set HMIP.compact rpcparameter 1 MASTER VALVE_MAXIMUM_POSITION=0.77
oder auch nur
set HMIP.compact config 1  VALVE_MAXIMUM_POSITION=0.77


Dann bekomme ich den Fehler:

HMCCUDEV: HMIP.compact Execution of CCU script or command failed



Ich hab auch schon per ccuflag=trace mal geschaut:

2019.11.02 20:42:14 2: HMCCUDEV: [HMIP.compact] GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;VALVE_STATE!0:STATE_NOT_AVAILABLE,1:RUN_TO_START,2:WAIT_FOR_ADAPTION,3:ADAPTION_IN_PROGRESS,4:ADAPTION_DONE,5:TOO_TIGHT,6:ADJUSTMENT_TOO_BIG,7:ADJUSTMENT_TOO_SMALL,8:ERROR_POSITION
2019.11.02 20:42:14 2: HMCCUDEV: [HMIP.compact] RPCRequest: Dump of RPC request putParamset 001198A9ABA7DC:1. Result type=HASH
2019.11.02 20:42:14 2: HMCCUDEV: [HMIP.compact] RPCRequest: {
,faultCode=-5,faultString=Invalid parameter or value
}
2019.11.02 20:42:14 1: HMCCURPCPROC: [d_rpc000014HmIP_RF] Invalid parameter or value
2019.11.02 20:42:14 1: HMCCUDEV: [HMIP.compact] HMCCUDEV: HMIP.compact Execution of CCU script or command failed


--> faultString=Invalid parameter or value
Ich wüsste aber nicht, wie ich den Wert anders übergeben könnte, laut Doku ist das ein float double.

In der HM Webgui steht jetzt bei den Serviemeldungen: "Konfigurationsdaten stehen zur Übertragung an".

Und wenn ich einmal das Gerät konfiguriere (ohne was zu ändern) dann wird scheinbar der Parameter an den Thermostat geschickt.

Ich bin etwas ratlos. Was mache ich falsch?

Dek


jsChris

FYI:

habe die CCU3 gerade auf 3.47.22 updated. FHEM ebenfalls auf den heutigen aktuellen Stand gebracht. Erst einmal keine Problem. rpcinterfaces stabil.

/o\ \o/ /o\ \o/
Chris


Dek

#355
Hallo zusammen,

Meine Erkentnisse:

Datentyp: double

set HMIP.compact rpcparameter 1 MASTER VALVE_MAXIMUM_POSITION=0.44 -->Fehler
set HMIP.compact config 1 VALVE_MAXIMUM_POSITION=0.44 --> Fehler


Datentyp Enum:

set HMIP.compact config 1 ADAPTIVE_REGULATION=2  --> klappt
set HMIP.compact rpcparameter 1 MASTER ADAPTIVE_REGULATION=2 --> klappt


kann also am Datentyp liegen.

Wenn ich in der HM-Shell mir die Datenpunkte anzeigen lasse mit:

(...)
xmlrpc.GetParamset()

Dann scheint das xml auch eine leicht andere Struktur zu haben:

<name>ADAPTIVE_REGULATION</name>    <value>1                         </value></member><member>
<name>VALVE_MAXIMUM_POSITION</name> <value><double>1.000000</double> </value></member><member>


Es gibt dann auch noch andere Typen:
boolean| i4:

<name>BOOST_AFTER_WINDOW_OPEN</name><value><boolean>0</boolean></value></member><member>
<name>BOOST_POSITION</name><value><i4>80</i4></value></member><member>


Ich würde mal vermuten, da gibt es irgendeinen Zusammenhang.

[update]:
Es scheint so zu sein, dass der HMIP XML-Server etwas "anspruchsvoller" ist, als der normale HM-Server. Siehe Post:
https://homematic-forum.de/forum/viewtopic.php?t=30192#p274945

Dek

Dek

#356
Hallo zusammen,

es lässt mir keine Ruhe :-)

Ich hab' mir mal den Traffic auf dem interface mit tcpdump angeschaut, um zu sehen, was denn tatsächlich gesendet wird.  Siehe da, da liegt tatsächlich der Hase im Pfeffer:

<?xml version="1.0" encoding="us-ascii"?>
<methodCall>
<methodName>putParamset</methodName>
<params>
<param><value><string>001198A9ABA7DC:1</string></value></param>
<param><value><string>MASTER</string></value></param>
<param>
<value>
<struct>
<member>
<name>VALVE_MAXIMUM_POSITION</name>
<value><string>0.55</string></value>
member>
</struct>
</value>
</param>
</params>
</methodCall>


der Typ des übergebenen Werts ist im XML mit String angegeben. Laut den Infos aus meinem verlinkten Post aus dem Home-matic forum ist zumindest das XML-Interface der HmIP Komponenten sehr strikt, was die Typizierung angeht.

Soweit ich im Perl-Code gesehen habe, kapselt der RPC::XML::Client die XML-Kommunikation und setzt die Parameter-Typen.

Es gibt wohl den sub "HMCCURPCPROC_EncValue", der genau die Typwandlung machen soll, aber offensichtlich nicht korrekt funktioniert, weil vor dem Aufruf der typ hart auf "STRING" gesetzt wird:


sub HMCCURPCPROC_SendRequest ($@)
(...)
while (my $p = shift @param) {
                                        my $pt = "STRING";   ######<<<<<<<<<< HIER!!!!                                       
                                        if ($p =~ /${re}/) {
                                                $pt = $1;
                                                $p =~ s/${re}//;
                                        }
                                        my ($pn, $pv) = split ('=', $p, 2);
                                        next if (!defined ($pv));
                                        $hparam{$pn} = HMCCURPCPROC_EncValue ($pv, $pt);
                                }
(...)


Wenn ich die markierte Stelle ersetze durch

my $pt;

sprich: die Variable deklariere aber nicht setze, dann funktioniert die TYPE-Magic der HMCCURPCPROC_EncValue und das gesendete XML ist korrekt und das Ventil reagiert sofort! Jetzt sollte nur jemand prüfen, was ich mit der Änderung sonst so kaputt mache?!? bevor ich das bei mir aktiv so umsetze

Dek

P.S. Ich habe jetzt einen funktionierenden Workaround implementiert:

  • setze eine Systemvariable in der CCU aus fhem heraus (mit set <ccu> var )
  • das triggert ein HM-Script auf der CCU
  • das Script setzt dann den Parameter mittels
    xmlrpc.PutParamset(dev.Interface(), dev.Address()+":1", "MASTER", "VALVE_MAXIMUM_POSITION", value);

Dek

Alternative Lösung!!!

Die ich aber erst im Kommentar zu den Funktionen im Perl-Code entdeckt habe, und nicht in der commandref aufgeführt wird(?)

Wenn man den Datentyp hier:DOUBLE mitgibt:

set DG.HMIP.Radiator config 1 VALVE_MAXIMUM_POSITION=0.0:DOUBLE


klappts auch, allerdings ist das etwas, das dann doch sehr viel recherche bedeutet, bevor man es anwenden kann.


Dek
(3. Post in Folge, ich hoffe es liest überhaupt jemand mit)


Der Kommentar in 88_HMCCURPCPROC.pm zu
HMCCURPCPROC_SendRequest ($@):

######################################################################
# Send RPC request to CCU.
# Supports XML and BINRPC requests.
# Parameter $request contains the RPC command (i.e. "init" or
# "putParamset"). If RPC command is a parameter set command, two
# additional parameters address and key (MASTER or VALUE) must be
# specified.
# If RPC command is putParamset or setValue, the remaining elements
# in array @param contains the request parameters in format:
#   ParameterName=Value[:ParameterType]
# For other RPC command the array @param contains the parameters in
# format:
#   Value[:ParameterType]
# For BINRPC interfaces ParameterType is mapped as follows:
#   "INTEGER" = $BINRPC_INTEGER
#   "BOOL"    = $BINRPC_BOOL
#   "STRING"  = $BINRPC_STRING
#   "FLOAT"   = $BINRPC_DOUBLE
#   "DOUBLE"  = $BINRPC_DOUBLE
#   "BASE64"  = $BINRPC_BASE64
#   "ARRAY"   = $BINRPC_ARRAY
#   "STRUCT"  = $BINRPC_STRUCT
# Return response or undef on error.
######################################################################

Maista

Hallo Dek.

Zap wird sich sicher melden wenn er dazu kommt.

Gruss Gerd


Dek

Hi,

Klar, davon gehe ich aus, war auch eher mit   ;)

Dek