Die Version 4.4 von HMCCU steht nun als Beta im SVN zur Verfügung. Die Beta-Phase wird bald enden (Stand Ende 2020). Da aber noch nicht alles getestet ist und stabil läuft, habe ich die 4 Module zunächst unter
contrib/HMCCU/FHEMsowie auf Github abgelegt.
Installation und Konfigurationupdate all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txtoder
update all https://svn.fhem.de/trac/browser/trunk/fhem/contrib/HMCCU/controls_HMCCU.txtZurück zur alten Version 4.3Dazu einfach FHEM Update ohne separate Quellenangabe ausführen.
Fehler und ErweiterungswünscheAuf Github gibt es eine Liste der bekannten Fehler und Erweiterungswünsche: https://github.com/zapccu/HMCCU/issues
Vorgehen bei der Konfiguration:
- IO-Device mit Angabe der IP-Adresse der CCU definieren: define myCCU HMCCU IP-Addresse
- Zu verwendenden Schnittstellen auswählen: Aus Dropdown-Liste beim Attribut 'rpcInterfaces' die gewünschten Einträge auswählen
- RPC-Server starten: set myCCU on
- Optional: Autostart der RPC-Server aktivieren: attr myCCU rpcserver on
- Nachdem die RPC Server gestartet wurden (Status ist "running"), die FHEM Config speichern, da beim ersten Start der RPC-Server automatisch für jede ausgewählte Schnittstelle ein FHEM Device vom Typ HMCCURPCPROC angelegt wird
Autodetect von Homematic GerätenBeim Starten von FHEM liest HMCCU nun alle Geräteparameter von der CCU. Diese Parameter werden verwendet, um bei der Definition eines Device in FHEM anhand der Kanalrolle das neue Device automatisch zu konfigurieren. Dadurch entfallen viele der bisher notwendigen Attribute. Die vorhandenen Devices der HMCCU Version 4.3 kann man auf das neue Verfahren umstellen, indem man für jedes Device einmal den Befehl
set defaults reset ausführt. Dabei werden alle HMCCU 4.3 relevanten Attribute gelöscht. Grundsätzlich werden die bisherigen Attribute weiterhin unterstützt, sind aber nicht mehr explizit erforderlich.
Empfehlung: Wer keine allzu große Homematic-Installation hat, sollte überlegen, seine Geräte einfach neu zu definieren. Dann wird man bei der Gerätedefinition auch darauf hingewiesen, HMCCUCHN statt HMCCUDEV zu verwenden, sofern dies möglich und sinnvoll ist.
Definition von FHEM Devices für Homematic Geräte (Autodetect)Wenn möglich sollte für die Definition von FHEM-Devices das Modul HMCCUCHN verwendet werden. Die meisten Homematic Geräte können über einen einzelnen Kanal gesteuert werden. Wenn HMCCUDEV verwendet wird, obwohl HMCCUCHN möglich ist, weist HMCCU darauf hin, dass HMCCUCHN verwendet werden sollte. Diese Empfehlung kann durch Angabe der Option 'force' beim 'define' ignoriert werden.
Hinweis: Der Kanal 0 ist sowohl bei HMCCUCHN als auch bei HMCCUDEV immer enthalten. Es ist also nicht notwendig, HMCCUDEV zu verwenden, nur im die Datenpunkte aus dem Kanal 0 als Readings darstellen zu können.
Automatische Definition von FHEM Devices mit 'get create' oder 'get createDev'Der Autodetect-Mechanismus wird nun auch von den Befehlen
get create und
get createDev verwendet. Daher entfällt hier die Option 't=dev/chn'. Der bei diesen Befehlen anzugebende reguläre Ausdruck bzw. Name für den CCU Gerätenamen bezieht sich nun immer(!) auf Geräte, niemals auf Kanäle. HMCCU erkennt selbständig, ob ein HMCCUDEV oder ein/mehrere HMCCUCHN Device(s) angelegt werden müssen.
Der Befehl
get deviceInfo in HMCCU (IO-Device) wurde erweitert. Er zeigt für das abgefragte Gerät eine Empfehlung an, ob HMCCUCHN oder HMCCUDEV für eine Gerätedefinition verwendet werden sollte.
Beispiel: Wenn alle Heizungsgruppen in der CCU mit "G-Heizung" beginnen, legt der folgende Befehl ein FHEM Device für jede Heizungsgruppe an und weist ihm die Attribute 'room' und 'group' zu. Die Geräte in FHEM werden mit dem Präfix "HM_" angelegt:
get myCCU create G-Heizung.* p=HM_ room=Homematic group=HeizungHinweis: Für die Heizungsgruppen wird HMCCUDEV verwendet, da bei diesen neben dem eigentlichen Kanal zur Temperatursteuerung ein weiterer Kanal existiert, der den Zustand der eingebundenen Fenstersensoren abbildet.
Auch wenn HMCCU den Gerätetyp nicht exakt identifizieren kann, werden die Attribute 'statedatapoint' und 'controldatapoint' nun mit Auswahllisten vorbelegt, die verhindern, dass ungeeignete Datenpunkte für die Steuerung bzw. Statusanzeige ausgewählt werden. Wenn eines der beiden Attribute nicht verfügbar ist, hat das jeweilige Gerät keine lesbaren (statedatapoint) bzw. schreibbaren (controldatapoint) Datenpunkte. Wenn man die FHEM Eingabezeile für das Setzen dieser Attribute verwendet, kann jeder Datenpunkt angegeben werden. Ein 'statedatapoint' muss lesbar, ein 'controldatapoint' beschreibbar sein.
SonderfälleSonderfall FernbedienungenFür Geräte mit mehreren identischen Kanälen wie z.B. Fernbedienungen empfehle ich, für jeden Kanal ein HMCCUCHN Device anzulegen. Wenn HMCCUDEV verwendet wird, setzt HMCCU die Attribute 'statedatapoint' und 'controldatapoint' auf den ersten verwendbaren Kanal. Um einen anderen Kanal (eine andere Taste) zu verwenden, müssen beide Attribute entsprechend angepasst werden.
Bei Verwendung von
get create oder
get createdev legt HMCCU automatisch ein HMCCUCHN Device je Schaltkanal an. An den Devicenamen wird die Kanalnummer angehängt.
Sonderfall Mehrfachschalter mit KanalgruppenEin weiterer Sonderfall sind Mehrfachschalter mit Kanalgruppen, wie sie m.W. nur bei HmIP-Wired vorkommen. Bei diesen Geräten sind immer 2 oder 4 Kanäle zu einem Schaltausgang zusammengefasst. Hier muss zwingend HMCCUDEV verwendet werden, wenn sich Status- und Steuerungskanal unterscheiden. Auch hier erfolgt die Auswahl der gewünschten Kanäle über die Attribute 'statedatapoint' und 'controldatapoint'.
Neue / geänderte BefehleNeue Befehle des Moduls HMCCU:
- set on/off: Startet oder stoppt die RPC-Server Prozesse, Abkürzung für set rpcserver on/off
- get ccuConfig: Liest die Konfigurationsparameter der CCU (Geräte, Programme, ...) neu ein
- get ccuDevices: Zeigt eine Liste aller Geräte der CCU an
- get create: Definiert FHEM Geräte für eine Gruppe von CCU Geräten. Die Auswahl von HMCCUDEV oder HMCCUCHN erfolgt automatisch
- get createDev: Definiert ein oder mehrere FHEM Gerät(e) für ein CCU Gerät. Die Auswahl von HMCCUDEV oder HMCCUCHN erfolgt automatisch
- get deviceinfo: Zeigt Detailinformationen zu einem CCU Gerät an inkl. Empfehlung für das für die FHEM Gerätedefinition zu verwendende Modul (HMCCUDEV oder HMCCUCHN)
- get paramsetDesc: Zeigt Detailinformationen zu den Parametern eines CCU Gerätes an
Standard Befehle der Module HMCCUDEV und HMCCUCHN:Die Befehle der Module HMCCUDEV und HMCCUCHN wurden komplett überarbeitet. Viele redundanten Befehle sind weggefallen oder wurden durch andere ersetzt. Sorry, wenn dadurch Aufwand bei der Anpassung von Notifies oder DOIFs entstehen.
- set clear: Readings löschen
- set config: Ein oder mehrere Konfigurations- oder Link-Parameter setzen
- set datapoint: Einen oder mehrere Datenpunkte setzen
- set defaults: Default Attribute setzen. Sollte nur verwendet werden, wenn ein Gerät nicht automatisch von HMCCU erkannt wurde
- set readingFilter: Vereinfacht die Definition des Attributs 'ccureadingfilter'. Die gewünschten Datenpunkte können aus einer Liste ausgewählt werden. Das Attribut 'ccureadingfilter' wird automatisch aus der Auswahl heraus gesetzt
- get config: Liest Konfigurations- und Linkparameter und zeigt sie an. Damit alle Parameter als Readings erscheinen, müssen im Attribut 'ccuflags' die Flags 'showMasterReadings', 'showLinkReadings' 'showServiceReadings' und/oder 'showDeviceReadings' gesetzt werden
- get datapoint: Liest einen Datenpunkt
- get deviceInfo: Zeigt Informationen zu Kanälen und Datenpunkten eines Gerätes an. Die Ausgabe dieses Befehls zusammen mit der Ausgabe von get paramsetDesc hilft mir, nicht automatisch erkannte Geräte in HMCCU zu integrieren. Wenn also ein Gerät nicht erkannt wird, bitte diese beiden Befehle ausführen und die Ausgabe an mich schicken. Beide Befehle können auch direkt im I/O Device ausgeführt werden (also ohne vorher ein HMCCUDEV/CHN Device zu definieren)
- get paramsetDesc: Zeigt Detailinformationen zu den Parametern eines Gerätes an. Zur Verwendung s.o.
- get update: Aktualisiert alle Parameter und Datenpunkte eines Gerätes
- get values: Aktualisiert nur die Datenpunkte eines Gerätes
Für die genaue Syntax der Befehle siehe FHEM Commandref.
ReadingsPer Default werden nur Readings zu Datenpunkten (Parameterset VALUES) angezeigt. Die Voreinstellung für 'ccureadingfilter' ist nun '.*'. D.h. es werden keine Datenpunkte gefiltert. Die Anzeige von Readings zum Device, zu Links oder zu Konfigurationsparametern wird über das Attribut 'ccuflags' im jeweiligen FHEM-Device gesteuert. Hier können die Flags 'showDeviceReadings', 'showMasterReadings', 'showLinkReadings' und/oder 'showServiceReadings' gesetzt werden, um die entsprechenden Readings anzeigen zu lassen.
Hinweise:
- Nur die Readings zu Datenpunkten werden von der CCU automatisch aktualisiert (sofern die RPC-Server gestartet sind). Alle anderen Readings müssen mit dem Befehl 'get config' explizit aktualisiert werden.
- Wenn Reading bezogene Attribute geändert werden und die betroffenen Readings bereits intern vorhanden sind, werden die Readings automatisch mit den intern gespeicherten Werten aktualisiert bzw. ergänzt
Einige wichtige Änderungen:
- HMCCU: Der interne RPC Server wurde entfernt. Es wird nur noch HMCCURPCPROC unterstützt. Das Flag procrpc muss nun nicht mehr gesetzt werden. Es wird immer der externe RPC Server verwendet.
- HMCCU: Neues globales Flag 'logCommand' für das Attribut 'ccuflags'. Dadurch werden alle set und get Befehle im FHEM Logfile protokolliert.
- Alle Module: Die Logfile Einträge wurden vereinheitlicht. Neben dem Modulnamen wird nun auch immer die Prozess-ID ausgegeben. Das hilft, Fehler in RPC Server Prozessen zuzuordnen
- HMCCURPCPROC: Jedes RPC-Device liest während der Definition bzw. der Initialisierung Gerätebeschreibungen von der CCU und speichert sie im I/O Device. Dies dauert auf einer CCU3 mit 80 Geräten einige Sekunden. Auf einer CCU2 dürfte es deutlich länger dauern. Dies verzögert den Start von FHEM
- HMCCURPCPROC: Fehler im Handling binärer RPC-Requests (CUxD) behoben.
Bei mir funktioniert es nicht. Seit dem test, welcher schief ging, bekomme ich die RPC interfaces nicht mehr zum Laufen. Ich bin auf die 4.3 zurückgegangen - ohne Erfolg.
State "inactive/Error"
RPCState inactive
Internals:
CCUNum 1
CFGFN ./setup/c_hmCCU.cfg
Clients :HMCCUDEV:HMCCUCHN:HMCCURPC:HMCCURPCPROC:
DEF 192.168.178.46
FUUID 5c95d10d-f33f-1a31-fbb0-16b25dbd514f7621
NAME HMccu
NOTIFYDEV global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
NR 733
NTFY_ORDER 50-HMccu
RPCState inactive
STATE inactive/Error
TYPE HMCCU
ccuip 192.168.178.46
ccustate active
ccutype CCU2/3
host 192.168.178.46
prot http
version 4.3.020
READINGS:
2020-01-06 11:33:16 battery_count 154
2020-01-06 11:33:16 battery_list Batterien OK
2020-01-06 11:33:16 battery_match 0
2020-01-06 11:33:16 battery_state ok
2020-01-05 16:02:45 count_channels 259
2020-01-05 16:02:45 count_devices 28
2020-01-05 16:02:45 count_groups 0
2020-01-05 16:02:45 count_interfaces 3
2020-01-05 16:02:45 count_programs 5
2020-01-06 12:48:39 rpcstate inactive
2020-01-06 13:35:14 state Error
hmccu:
defInterface BidCos-RF
defPort 2001
evtime 0
evtimeout 0
rpccount 0
rpcports
updatetime 0
adr:
agg:
battery:
fcoll comment
fcond any
fdflt Batterien OK
felse ok
fexcl
fexpr ^HMc_.*
fpref battery_
fread battery
ftrue low
ftype name
voltage:
fcoll comment
fcond le
fdflt Batteriespannung OK
felse 0
fexcl
fexpr (HM-CC-RT-DN|HM-TC-IT-WM-W-EU)
fpref voltage_
fread BATTERY_STATE
ftrue 2.2
ftype type
ccu:
delay 180
delayed 1
timeout 1
dev:
ifports:
interfaces:
rpc:
Attributes:
ccuaggregate name:battery,filter:name=^HMc_.*,read:battery,if:any=low,else:ok,prefix:battery_,coll:comment!Batterien OK;
name:voltage,filter:type=(HM-CC-RT-DN|HM-TC-IT-WM-W-EU),read:BATTERY_STATE,if:le=2.2,else:0,prefix:voltage_,coll:comment!Batteriespannung OK;
ccudef-readingfilter .*
ccudef-readingformat datapointlc
ccudef-readingname 0.(LOWBAT|LOW_BAT):battery;..LEVEL:+pct;..SET_TEMPERATURE:desired-temp;..ACTUAL_TEMPERATURE:measured-temp;4.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
ccuflags procrpc
cmdIcon on:general_an off:general_aus
eventMap /rpcserver on:on/rpcserver off:off/
group IOdev
room HMccu,Homematic
rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
rpcport 2001,2010
rpcserver on
stateFormat rpcstate/state
stripnumber 2
Lösche mal das Attribut rpcport und am besten auch eventuell vorhandene HMCCURPCPROC Devices. Dann FHEM neu starten.
Der Hash vom I/O Device enthält keine Interfaces. Das ist seltsam. Auch das Internal ccuinterfaces fehlt im I/O Device.
Hat nicht funktioniert.
Ich werde erst am Wochenende wieder Zeit investieren können
ok, bis dahin wird es noch das eine oder andere Update geben
Ich habe die Module in contrib/HMCCU/FHEM aktualisiert. Die Befehle vom Modul HMCCUCHN wurden angepasst:
set paramsetErsetzt
set config und
set rpcparameter. Beide Befehle stehen noch als Alias zur Verfügung. Die Syntax sieht so aus:
set <name> paramset [device] [<paramset>] <parameter>=<value>[:<type>]
Wenn die Option
device angegeben ist, bezieht sich der Befehl auf die Geräteadresse. Ansonsten bezieht er sich auf den Kanal des HMCCUCHN Device.
Der Parameter
paramset ist der Name eines gültigen Parameter Sets vom Gerät oder Kanal. Gültige Parameter Sets kann man sich mit dem Befehl
get devicedesc anzeigen lassen.
Einige Parameter erfordern einen bestimmten Datentyp. Wenn
type nicht angegeben ist, wird STRING angenommen. Weiter Datentypen sind BOOL, FLOAT, DOUBLE, INTEGER. Der Datentyp kann der Ausgabe von
get paramsetdesc entnommen werden.
get devicedescget <name> devicedesc [
channel|device]
Zeigt die Geräte- oder die Kanalbeschreibung an. Die Kanalbeschreibung enthält bei einem HMCCUCHN Device immer auch den Kanal 0.
get paramsetdescget <name> paramsetdesc [
channel|device]
Zeigt die Beschreibung aller Parameter Sets eines Geräts oder eines Kanals an. Bei
channel werden auch die Paramsets von Kanal 0 angezeigt.
get configlistget <name> configlist [
channel|device] [<paramset>|
ALL] [<filter-expr>]
Zeigt die Parameter eines oder aller Parameter Sets eines Geräts oder eines Kanals an. Bei
channel wird immer auch Kanal 0 angezeigt. Wenn keine Parameter Set angegeben wird, werden alle Parameter Sets angezeigt. Mit
filter-expr kann die Ausgabe nach einem regulären Ausdruck gefiltert werden.
get configget <name> config [
channel|device] [<paramset>|
ALL] [<filter-expr>]
Wie get configlist, speichert die Werte jedoch als Readings.
Hört sich gut an (noch nichts getestet :( )
Besonders gefällt mir der Ansatz, dass ch 0 und das device quasi nicht unterschieden werden.
A) das ist 90% da im set parmset der Anwender das wissen muss. Kannst du das nicht weglassen?
B) ich hätte es anders herum gemacht. Ch0 beinhaltet das device. Somit ist die addresse einer chn entity immer sernr:chan.
Konsequent durchgezogen verschmilzt also (im chan Sektor! ) das device komplett mit ch0. Der Anwender unterscheidet nicht mehr, braucht kein wissen ob ch0 ober device,... . Du solltest auch unterbinden, dass gesonderte entities angelegt werden können.
Die vereinheitlichung erlaubt dem Anwender immer noch alles, aber du hast weniger varianten. M.E. ist macht es auch das Verständnis einfachen. Ob der Parameter nun in ch0 oder dem device verwaltet wird ist schlussendlich egal und rein intern.
Es sowieso hilfreich dem Anwender solche Entscheidungen abzunehmen. Er fragt sich sofort was für einen Unterschied es macht. Keinen. Warum also muss er wählen?
Wieder ein langes Plädoyer ;)
Ich hätte grundsätzlich nichts gegen die Verschmelzung von Channel 0 und dem Device, zumindest für den Anwender. Dann habe ich mir die Device- und Parameterset Descriptions angeschaut.
Laut Device Descriptions verfügt der Kanal 0 über die Parameter Sets "MASTER" und "VALUES". Das Device selbst nur über "MASTER". Ein Auslesen des Parameter Sets "MASTER" von Kanal 0 funktioniert jedoch nicht (zumindest habe ich bisher kein Device gefunden).
Kannst Du diesen Widerspruch erklären? Hier mal ein einfaches Beispiel für einen Fensterkontakt:
Device LEQ0919881
PARAMSETS: MASTER
Channel LEQ0919881:0
PARAMSETS: MASTER,VALUES
Channel LEQ0919881:1
PARAMSETS: LINK,MASTER,VALUES
Wie soll ein Nutzer nun zwischen Device-MASTER und Kanal-0-MASTER entscheiden? Wie gesagt: Kanal-0-MASTER lässt sich nicht auslesen, obwohl er eigentlich da sein müsste. Wenn das immer so ist, kann ich Kanal-0-MASTER immer mit Device-MASTER gleich setzen und alles ist gut. Die Frage ist nur, kann man sich tatsächlich darauf verlassen.
Hier noch die Paramset Description. Wie du siehst, fehlt 0.MASTER
Channel 0
Paramset VALUES
AES_KEY: INTEGER [R] [] RANGE=0-127 DFLT=0 UNIT=
CONFIG_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0-1 DFLT=0 UNIT=
DEVICE_IN_BOOTLOADER: BOOL [R,E] [Visible,Sticky,Service] RANGE=0-1 DFLT=0 UNIT=
LOWBAT: BOOL [R,E] [Visible,Sticky,Service] RANGE=0-1 DFLT=0 UNIT=
RSSI_DEVICE: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648-2147483647 DFLT=0 UNIT=
RSSI_PEER: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648-2147483647 DFLT=0 UNIT=
STICKY_UNREACH: BOOL [R,W,E] [Sticky,Internal] RANGE=0-1 DFLT=0 UNIT=
UNREACH: BOOL [R,E] [Visible,Sticky,Service] RANGE=0-1 DFLT=0 UNIT=
UPDATE_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0-1 DFLT=0 UNIT=
Channel 1
Paramset LINK
EXPECT_AES: BOOL [R,W] [Visible,Sticky] RANGE=0-1 DFLT=0 UNIT=
PEER_NEEDS_BURST: BOOL [R,W] [Visible,Sticky] RANGE=0-1 DFLT=0 UNIT=
Paramset MASTER
AES_ACTIVE: BOOL [R,W] [Visible,Sticky,Internal] RANGE=0-1 DFLT=0 UNIT=
EVENT_DELAYTIME: FLOAT [R,W] [Visible,Sticky] RANGE=0.000000-7620.000000 DFLT=0.000000 UNIT=s
MSG_FOR_POS_A: ENUM [R,W] [Visible,Sticky] RANGE=0-2 DFLT=2 UNIT=
MSG_FOR_POS_B: ENUM [R,W] [Visible,Sticky] RANGE=0-2 DFLT=1 UNIT=
TRANSMIT_TRY_MAX: INTEGER [R,W] [Visible,Sticky] RANGE=1-10 DFLT=6 UNIT=
Paramset VALUES
ERROR: ENUM [R,E] [Visible,Sticky,Service] RANGE=0-7 DFLT=0 UNIT=
INSTALL_TEST: ACTION [E] [Visible,Sticky,Internal] RANGE=0-1 DFLT=0 UNIT=
LOWBAT: BOOL [R,E] [Visible,Sticky] RANGE=0-1 DFLT=0 UNIT=
STATE: BOOL [R,E] [Visible,Sticky] RANGE=0-1 DFLT=0 UNIT=
zuerst einmal mein Status: Es funktioniert nicht.
Ich hatte einen Update gemacht, dann die 4 Files aus contribute ein-kopiert.
nachdem nichts funktioniert hat habe ich alle HMCCU-elemente aus Config entfernt und neu gestarted.
HMCCU wiki und best-practice genutzt die ccu neu anzulegen. RPC funktioniert nicht.
Zum Anlegen sollte es reichen, die ccu zu definieren und die RPC services in den Attributen zu wählen. Den Rest macht die SW selbst - korrekt?
Beim Anlegen des attr rpcinterfaces bekomme ich
ZitatHMCCU: Illegal RPC interface BidCos-RF
Wäre cool wenn du mir helfen könntest - sonst muss ich tiefer debuggen :)
zu deiner Frage:
Ich werde es testen, wenn es wieder läuft.
Grundsätzlich muss der Anwender nichts über "master" und "Values" wissen. (Link nicht vergessen, allerdings nur für Kanäle >0)
Ich definiere die Gruppen einmal so:
Register: Mein Begriff für remanente Einstellungen welche im Device vorgenommen werden können.
Master: Register welche der entity zugeordnet sind. Sind immer verfügbar (also nicht peer abhängig)
Values: dynamische, nicht remanente Werte wie Status, Batterie, Interface-status,....
Link: Nach dem direkten Peeren einer entity mit einer anderen wird ggf je ein Satz von Registern angelegt. Device und Channel 0 kann man nicht "peeren".
Für Link gibt es also EINE Definition je kanal und N Instanzen, je nachdem wie oft die Entity gepeert ist.
Bei der kombi-Entity Ch0/Device könnte man die beiden Gruppen schlicht zusammenfassen.
Dem Anwender muss man folgende Infos transportieren
- Register (remanente Steicherung im Device)
+ Diese Werte kann er beeinflussen/setzen/Ändern und muss sie dem Device übertragen. ggf. das Device aufwecken,...
+ Unterschiedung cached, noch nicht übertragen, Setzen erledigt und geprüft,... sind hier wichtig
- Zustände(readings ausser Register-readings)
+ kann man manchmal setzen (level), sind nicht remanent und manchmal zur lesbar (Battery state)
MASTER ist bei Devices wohl immer angelegt, machmal aber leer.
Ich würde einmal einen RT als Testfall nutzen. Da hat eq3 einige besonderheiten eingebaut. Hier bspw sollte MASTER einiges an Inhalt haben. (in CUL_HM habe ich dies mutwillig für den User nach Kanal 4 "verschoben", weil es besser passt.)
so, bin wieder "on-target". Das Problem war, dass HMCCUConf.pm "falsch" war. Scheinbar haben die kompletten Scripts gefehlt.
Das file in SVN ist korrekt. Wie auch immer dieses Update-Problem entstehen konnte, mir unklar. Vielleicht habe ich es auf selbst verschuldet...
nun kann ich auch testen. Hier also einmal ein RT Device.
Beim RT sehe ich gesonderten Handlungsberarf. Will sagen:
- typisch werden die Daten wie aus der CCU geliefert ausgegebe
- In wenigen Fällen, wie bei der "ellenlangen" Liste der RT oder TC Temparaturen sollte man eine Zusammenfassung erstellen - nur für die Temperaturlisten. Die lange Liste ist störend und hat in voller Länge keinen tieferen Sinn.
Aber hier sind tatsächlich Daten im MASTER des Device.
==> Grundsätzlich alle angegebenen Listen prüfen, auslesen, zusammenfassen, darstellen.
model: HM-CC-RT-DN
----No: 0 typ: dev
:CHILDREN : 7
:FLAGS : Visible
:RX_MODE : CONFIG,BURST,WAKEUP
:UPDATABLE : 1
IF type: MASTER
MIN |MAX |TYPE |UNIT |DEF |OPER |FLAGS |VALUE_LIST
ADAPTIVE_REGULATION : |3 |ENUM |- |- |RW |Visible |OFF with default values,OFF with determined values,ON |
BACKLIGHT_ON_TIME : |255 |INTEGER |s |1 |RW |Visible |- |
BOOST_AFTER_WINDOW_OPEN : |1 |BOOL |- | |RW |Visible |- |
BOOST_POSITION : |1 |INTEGER |% |8 |RW |Visible |- |
BOOST_TIME_PERIOD : |7 |ENUM |- |- |RW |Visible |0 min,5 min,10 min,15 min,20 min,25 min,30 min |
BURST_RX : |1 |BOOL |- |1 |RW |Visible |- |
BUTTON_LOCK : |1 |BOOL |- | |RW |Visible |- |
BUTTON_RESPONSE_WITHOUT_BACKLIGHT : |1 |BOOL |- | |RW |Visible |- |
CYCLIC_INFO_MSG : |255 |INTEGER |- |1 |RW |Visible |- |
CYCLIC_INFO_MSG_DIS : |255 |INTEGER |- |1 |RW |Visible |- |
DAYLIGHT_SAVING_TIME : |1 |BOOL |- |1 |RW |Visible |- |
DECALCIFICATION_TIME : |141 |INTEGER |minutes |66 |RW |Visible |- |
DECALCIFICATION_WEEKDAY : |7 |ENUM |- |- |RW |Visible |SATURDAY,SUNDAY,MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY |
DISPLAY_INFORMATION : |2 |ENUM |- |- |RW |Visible |TIME,DATE |
ENDTIME_FRIDAY_1 :5 |144 |INTEGER |minutes |36 |RW |Visible |- |
ENDTIME_FRIDAY_10 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_FRIDAY_11 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_FRIDAY_12 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_FRIDAY_13 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_FRIDAY_2 :5 |144 |INTEGER |minutes |54 |RW |Visible |- |
ENDTIME_FRIDAY_3 :5 |144 |INTEGER |minutes |102 |RW |Visible |- |
ENDTIME_FRIDAY_4 :5 |144 |INTEGER |minutes |132 |RW |Visible |- |
ENDTIME_FRIDAY_5 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_FRIDAY_6 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_FRIDAY_7 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_FRIDAY_8 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_FRIDAY_9 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_MONDAY_1 :5 |144 |INTEGER |minutes |36 |RW |Visible |- |
ENDTIME_MONDAY_10 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_MONDAY_11 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_MONDAY_12 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_MONDAY_13 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_MONDAY_2 :5 |144 |INTEGER |minutes |54 |RW |Visible |- |
ENDTIME_MONDAY_3 :5 |144 |INTEGER |minutes |102 |RW |Visible |- |
ENDTIME_MONDAY_4 :5 |144 |INTEGER |minutes |132 |RW |Visible |- |
ENDTIME_MONDAY_5 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_MONDAY_6 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_MONDAY_7 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_MONDAY_8 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_MONDAY_9 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SATURDAY_1 :5 |144 |INTEGER |minutes |36 |RW |Visible |- |
ENDTIME_SATURDAY_10 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SATURDAY_11 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SATURDAY_12 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SATURDAY_13 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SATURDAY_2 :5 |144 |INTEGER |minutes |132 |RW |Visible |- |
ENDTIME_SATURDAY_3 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SATURDAY_4 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SATURDAY_5 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SATURDAY_6 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SATURDAY_7 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SATURDAY_8 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SATURDAY_9 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SUNDAY_1 :5 |144 |INTEGER |minutes |36 |RW |Visible |- |
ENDTIME_SUNDAY_10 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SUNDAY_11 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SUNDAY_12 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SUNDAY_13 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SUNDAY_2 :5 |144 |INTEGER |minutes |132 |RW |Visible |- |
ENDTIME_SUNDAY_3 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SUNDAY_4 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SUNDAY_5 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SUNDAY_6 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SUNDAY_7 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SUNDAY_8 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_SUNDAY_9 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_THURSDAY_1 :5 |144 |INTEGER |minutes |36 |RW |Visible |- |
ENDTIME_THURSDAY_10 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_THURSDAY_11 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_THURSDAY_12 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_THURSDAY_13 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_THURSDAY_2 :5 |144 |INTEGER |minutes |54 |RW |Visible |- |
ENDTIME_THURSDAY_3 :5 |144 |INTEGER |minutes |102 |RW |Visible |- |
ENDTIME_THURSDAY_4 :5 |144 |INTEGER |minutes |132 |RW |Visible |- |
ENDTIME_THURSDAY_5 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_THURSDAY_6 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_THURSDAY_7 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_THURSDAY_8 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_THURSDAY_9 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_TUESDAY_1 :5 |144 |INTEGER |minutes |36 |RW |Visible |- |
ENDTIME_TUESDAY_10 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_TUESDAY_11 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_TUESDAY_12 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_TUESDAY_13 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_TUESDAY_2 :5 |144 |INTEGER |minutes |54 |RW |Visible |- |
ENDTIME_TUESDAY_3 :5 |144 |INTEGER |minutes |102 |RW |Visible |- |
ENDTIME_TUESDAY_4 :5 |144 |INTEGER |minutes |132 |RW |Visible |- |
ENDTIME_TUESDAY_5 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_TUESDAY_6 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_TUESDAY_7 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_TUESDAY_8 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_TUESDAY_9 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_WEDNESDAY_1 :5 |144 |INTEGER |minutes |36 |RW |Visible |- |
ENDTIME_WEDNESDAY_10 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_WEDNESDAY_11 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_WEDNESDAY_12 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_WEDNESDAY_13 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_WEDNESDAY_2 :5 |144 |INTEGER |minutes |54 |RW |Visible |- |
ENDTIME_WEDNESDAY_3 :5 |144 |INTEGER |minutes |102 |RW |Visible |- |
ENDTIME_WEDNESDAY_4 :5 |144 |INTEGER |minutes |132 |RW |Visible |- |
ENDTIME_WEDNESDAY_5 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_WEDNESDAY_6 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_WEDNESDAY_7 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_WEDNESDAY_8 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
ENDTIME_WEDNESDAY_9 :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
GLOBAL_BUTTON_LOCK : |1 |BOOL |- | |RW |Visible |- |
I_VALUE_EXTERN :1 |2 |INTEGER |- |15 |RW |Visible |- |
I_VALUE_INTERN :1 |2 |INTEGER |- |15 |RW |Visible |- |
LOCAL_RESET_DISABLE : |1 |BOOL |- | |RW |Visible |- |
LOW_BAT_LIMIT :0 |12 |FLOAT |V |3 |RW |Visible |- |
MANU_MODE_PRIORITIZATION : |5 |ENUM |- |- |RW |Visible |SET_TEMPERATURE_CHANGE_ONLY_BY_RT_TC_SC_SELF,SET_TEMPERATURE_CHANGE_BY_ALL,SET_TEMPERATURE_CHANGE_ONLY_BY_RT_TC_CCU_SELF,SET_TEMPERATURE_CHANGE_ONLY_BY_CCU,SET_TEMPERATURE_CHANGE_ONLY_BY_SELF |
MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE : |1 |BOOL |- | |RW |Visible |- |
MODUS_BUTTON_LOCK : |1 |BOOL |- | |RW |Visible |- |
PARTY_MODE_PRIORITIZATION : |5 |ENUM |- |- |RW |Visible |SET_TEMPERATURE_CHANGE_ONLY_BY_RT_TC_SC_SELF,SET_TEMPERATURE_CHANGE_BY_ALL,SET_TEMPERATURE_CHANGE_ONLY_BY_RT_TC_CCU_SELF,SET_TEMPERATURE_CHANGE_ONLY_BY_CCU,SET_TEMPERATURE_CHANGE_ONLY_BY_SELF |
P_START_VALUE_EXTERN :5 |45 |INTEGER |- |3 |RW |Visible |- |
P_START_VALUE_INTERN :5 |45 |INTEGER |- |3 |RW |Visible |- |
P_VALUE_EXTERN :25 |35 |INTEGER |- |3 |RW |Visible |- |
P_VALUE_INTERN :25 |35 |INTEGER |- |3 |RW |Visible |- |
SHOW_WEEKDAY : |1 |BOOL |- | |RW |Visible |- |
TEMPERATUREFALL_MODUS : |5 |ENUM |- |- |RW |Visible |DEAKTIV,AUTOMODE,AUTO + MANUMODE,AUTO + PARTYMODE,AKTIV |
TEMPERATUREFALL_VALUE :0.5 |2.5 |FLOAT |K |1.4 |RW |Visible |- |
TEMPERATUREFALL_WINDOW_OPEN :5 |30 |FLOAT |�C |12 |RW |Visible |- |
TEMPERATUREFALL_WINDOW_OPEN_TIME_PERIOD : |6 |INTEGER |minutes |15 |RW |Visible |- |
TEMPERATURE_COMFORT :15 |30 |FLOAT |�C |21 |RW |Visible |- |
TEMPERATURE_FRIDAY_1 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_FRIDAY_10 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_FRIDAY_11 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_FRIDAY_12 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_FRIDAY_13 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_FRIDAY_2 :5 |30 |FLOAT |�C |21 |RW |Visible |- |
TEMPERATURE_FRIDAY_3 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_FRIDAY_4 :5 |30 |FLOAT |�C |21 |RW |Visible |- |
TEMPERATURE_FRIDAY_5 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_FRIDAY_6 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_FRIDAY_7 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_FRIDAY_8 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_FRIDAY_9 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_LOWERING :5 |25 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_MAXIMUM :15 |30.5 |FLOAT |�C |30.5 |RW |Visible |- |
TEMPERATURE_MINIMUM :4.5 |14.5 |FLOAT |�C |4.5 |RW |Visible |- |
TEMPERATURE_MONDAY_1 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_MONDAY_10 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_MONDAY_11 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_MONDAY_12 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_MONDAY_13 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_MONDAY_2 :5 |30 |FLOAT |�C |21 |RW |Visible |- |
TEMPERATURE_MONDAY_3 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_MONDAY_4 :5 |30 |FLOAT |�C |21 |RW |Visible |- |
TEMPERATURE_MONDAY_5 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_MONDAY_6 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_MONDAY_7 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_MONDAY_8 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_MONDAY_9 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_OFFSET : |15 |ENUM |- |- |RW |Visible |-3.5K,-3.0K,-2.5K,-2.0K,-1.5K,-1.0K,-0.5K,0.0K,0.5K,1.0K,1.5K,2.0K,2.5K,3.0K,3.5K |
TEMPERATURE_SATURDAY_1 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SATURDAY_10 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SATURDAY_11 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SATURDAY_12 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SATURDAY_13 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SATURDAY_2 :5 |30 |FLOAT |�C |21 |RW |Visible |- |
TEMPERATURE_SATURDAY_3 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SATURDAY_4 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SATURDAY_5 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SATURDAY_6 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SATURDAY_7 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SATURDAY_8 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SATURDAY_9 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SUNDAY_1 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SUNDAY_10 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SUNDAY_11 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SUNDAY_12 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SUNDAY_13 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SUNDAY_2 :5 |30 |FLOAT |�C |21 |RW |Visible |- |
TEMPERATURE_SUNDAY_3 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SUNDAY_4 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SUNDAY_5 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SUNDAY_6 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SUNDAY_7 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SUNDAY_8 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_SUNDAY_9 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_THURSDAY_1 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_THURSDAY_10 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_THURSDAY_11 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_THURSDAY_12 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_THURSDAY_13 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_THURSDAY_2 :5 |30 |FLOAT |�C |21 |RW |Visible |- |
TEMPERATURE_THURSDAY_3 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_THURSDAY_4 :5 |30 |FLOAT |�C |21 |RW |Visible |- |
TEMPERATURE_THURSDAY_5 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_THURSDAY_6 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_THURSDAY_7 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_THURSDAY_8 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_THURSDAY_9 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_TUESDAY_1 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_TUESDAY_10 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_TUESDAY_11 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_TUESDAY_12 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_TUESDAY_13 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_TUESDAY_2 :5 |30 |FLOAT |�C |21 |RW |Visible |- |
TEMPERATURE_TUESDAY_3 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_TUESDAY_4 :5 |30 |FLOAT |�C |21 |RW |Visible |- |
TEMPERATURE_TUESDAY_5 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_TUESDAY_6 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_TUESDAY_7 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_TUESDAY_8 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_TUESDAY_9 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_WEDNESDAY_1 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_WEDNESDAY_10 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_WEDNESDAY_11 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_WEDNESDAY_12 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_WEDNESDAY_13 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_WEDNESDAY_2 :5 |30 |FLOAT |�C |21 |RW |Visible |- |
TEMPERATURE_WEDNESDAY_3 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_WEDNESDAY_4 :5 |30 |FLOAT |�C |21 |RW |Visible |- |
TEMPERATURE_WEDNESDAY_5 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_WEDNESDAY_6 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_WEDNESDAY_7 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_WEDNESDAY_8 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
TEMPERATURE_WEDNESDAY_9 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
VALVE_ERROR_RUN_POSITION : |1 |INTEGER |% |15 |RW |Visible |- |
VALVE_MAXIMUM_POSITION : |1 |INTEGER |% |1 |RW |Visible |- |
VALVE_OFFSET : |1 |INTEGER |% | |RW |Visible |- |
MIN |MAX |TYPE |UNIT |DEF |OPER |FLAGS |VALUE_LIST
----No: 0 typ: MAINTENANCE
:DIRECTION : NONE
:DPs : VALUES,MASTER
:FLAGS : Internal,Visible
:PARAMSETS : MASTER,VALUES
IF type: MASTER
IF type: VALUES
MIN |MAX |TYPE |UNIT |DEF |OPER |FLAGS |VALUE_LIST
AES_KEY : |127 |INTEGER |- | |R |- |- |
CONFIG_PENDING : |1 |BOOL |- | |RE |Visible,Service |- |
DEVICE_IN_BOOTLOADER : |1 |BOOL |- | |RE |Service,Visible |- |
INHIBIT : |1 |BOOL |- | |RWE |Visible |- |
LOWBAT : |1 |BOOL |- | |RE |Visible,Service |- |
RSSI_DEVICE :-128 |127 |INTEGER |- | |RE |Visible |- |
RSSI_PEER :-128 |127 |INTEGER |- | |RE |Visible |- |
STICKY_UNREACH : |1 |BOOL |- | |RWE |Service,Sticky,Visible |- |
UNREACH : |1 |BOOL |- | |RE |Sticky,Service,Visible |- |
UPDATE_PENDING : |1 |BOOL |- | |RE |Service,Visible |- |
MIN |MAX |TYPE |UNIT |DEF |OPER |FLAGS |VALUE_LIST
Möglicherweise reden wir aneinander vorbei. Mein Problem ist nicht MASTER vom Device, sondern die Tatsache, dass sowohl das Device als auch der Kanal 0 jeweils einen MASTER haben (laut RPC Device Description). Wenn das nicht so wäre, könnte ich einfach den Kanal 0 mit dem Device gleichsetzen und könnte mir die leidige "device" Option in den Befehlen schenken.
Bei allen meinen Tests hat MASTER vom Kanal 0 niemals Werte geliefert. Auch eine Paramset Description kann man dafür nicht abfragen. Wenn das immer so wäre, könnte man also das Kanal 0 MASTER ignorieren bzw. automatisch auf das Device MASTER gehen. Die Frage ist halt: hat sich EQ-3 dabei etwas gedacht und gibt es Geräte, die im MASTER von Kanal 0 tatsächlich Parameter haben.
Ich habe das noch nicht endgültig probiert, wo master zu finden sind und wo nicht. Ich sehe es aber
A) als notwendig immer auf inhalte zu prüfen. Eq3 könnte ein neues device auf den markt bringen
B) für die implementierung den user interface als irrelevant, ob das register im device oder kanal0 enthalten ist. Der user bekommt einen registernamen in welchen er inhalte schreiben kann. Deine sw muss in diesem fall wissen ob es ins device oder den kanal geschrieben wird.
Semantisch verstehe ich kanal0 als das Kommunikations interface und device als kanalübergreifende settings.
Am interface kann man bisher wenig einstellen. Ich muss aber einmal prüfen wo die re-transmitt register verankert sind.
In culhm habe ich hier nicht unterschieden. Die addressierung geht gemäß eq3 nach listen. Diese haben einen wertebereich von 0 bis 9.
Der anwender muss sich aber darum nicht kümmern, das mache ich intern. Nur wenn er auf die raw ebene zugreift ist es relevant. Das hat nach meiner Kenntnis noch niemand genutzt (außer mir). Warum auch.
So, habe nun (endlich) deine neuen Kommandos getestst. Allerdings ohne Erfolg.
Bei unterschiedlichen kanäle habe ich keine Antwort bekommen auf
- configlist device/channel
- config
- devicedesc device/channel
- paramsetdesc device/channel
Einzig deviceinfo geht wir vor.
Mache ich grundsätzlich etwas falsch?
Oh!
Da habe ich wohl eine falsche Version von 88_HMCCURPCPROC im contrib eingecheckt. Da werden beim Start von FHEM leider die RPC Definitionen nicht gelesen.
Du kannst Dir behelfen, indem Du im jeweiligen HMCCURPCPROC DEvice einmal "get devicedesc" ausführst. Das liest die Paramset Definitionen neu ein. Danach müssten die Befehle funktionieren.
Ich checke auch gleich das korrigierte Modul ein.
Update: Hab's eingecheckt. Die anderen 3 Module sind von gestern Abend. Die musst Du natürlich auch installieren.
klappt nun alles, danke.
Ich fange einmal mit dem Review an.
get <HMccuChn> paramsetdescIch würde die Auswahl channel/device streichen. Mein Vorschlag ist wie schon vormals erwähnt, das "Device" im "Chan0" zusammenzufassen.
Wähle ich "Channel" als Option bei einem Kanal >0 bekomme ich immer auch Kanal0. Das macht keinen Sinn und ist typisch eh wenig interessante Info. Ch0 bezieht sich auf "die Kommunikation" und ist bei 90% aller Geräte identisch.
Antrag 1) Kanal 0 wird nur für Kanal 0 ausgegeben.
Antrag 2) Device wird immer automatisch bei Kanal 0 ausgegeben
Antrag 3) als Überschrift wäre der DeviceTyp und der KanalTyp schön
Beim Parametersatz "link" der Aktoren gibt es immer short/long. Diese sind identisch.
Einschub: Ausnahme ist Multiexec welches nur bei Long Sinn macht. Das unterschlage ich, da es am Ende weder einen inhaltlichen noch einen funktionalen oder semanitschen unterschied machtKompakter wäre es, den Block als short/long zu markieren und nur "short" anzuzeigen. Hinweis einbauen, dass Long parallel exitiert.
Antrag 4) short/long nur einmal darstellen
Anmerkung: Wenn der Linktyp short/long beinhaltet, dann komplett. Wenn der Linktyp dies nicht beinhaltet, dann auch komplett
get <HMccuChn> config/configList- Ich sehe nicht, dass bei config die Register als Readings gespeichert werden
- ich verstehe nicht, warum man speichern in Readings manuell anstossen muss. Das sollte immer passieren, wenn gelesen wurde. In CUL_HM speichere ich die Register in "hidden" readings. Über das Attribut "expert" kann man es sichtbar schalten. Ok, ist einiges an Arbeit, die Umschaltung. Aber sinnvoll.
Zum Inhalt: Link Readings
Im Gegensatz zu Parameter-Description gibt es
den Link Satz bei den eigentlichen Parametern. Link bedeutet, dass das Device gepeert ist und zu diesem peering ein Registersatz existiert.
=> für jedes einzelne Peering existiert ein Link-Datensatz.
=> du musst also zuerst die Links auslesen, dann die Link-Parametersätze
Antrag 5) Liste aller Peers des Kanals ausgeben.
Mit dem Hintergrund wird die Liste mit Unter ziemlich lang.
In CUL_HM habe ich aus genau diesem Grund bei der Ausgabe die tabellarische Form gewählt. Also eine Zeile je Register und eine Spalte je peer.
Bei Short/long habe ich es noch einmal verkürzt: eine Zeile je Register"Typ" und je eine Spalte je Peer-Short Peer-Long
Antrag 6) Tabelarische Ausgabe der Link-Basierenden Register
get <HMccuChn> DevicedescriptionAntrag 7) eine Option Device/Channel. Device wie immer in Channel0 darstellen. Channel 0 in allen anderen Channels ausblenden.
Wie bei allen Kommandos
Antrag 8) Ausblenden (unterdrücken) unnötiger Zeilen. Dies sind ADDRESS,INDEX,PARENT,VERSION
Antrag 9) Optional: Ausblenden (unterdrücken) leerer Zeilen.
Antrag 10) TARGET_ROLES ist eigentlich eine Liste. Dies sollte auch so dargestellt werden. Der Trenner ist das Leerzeichen. Das werden wir später noch brauchen, wenn PeeringOptionen ergründet werden :)
ZitatChannel IEQ0545891:0
AES_ACTIVE: 0
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT_TYPE: HM-LC-Dim1TPBU-FM
TYPE: MAINTENANCE
ZitatChannel IEQ0545891:1
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT_TYPE: HM-LC-Dim1TPBU-FM
TYPE: DIMMER
get <HMccuChn> deviceinfodas wird, nehme ich an, obsolet.
get <HMccuChn> datapointklappt bei mir nicht. Muss ich etwa besonderes tun?
Nachtrag:klappt jetzt.
Antrag 11) alle Datenpunkte aus der "VALUES" Liste auf einmal lesen und IMMER in Readings darstellen.
Das sind operationelle Zustände. Diese einzeln zu Lesen macht keinen Sinn, jeder will immer alle sehen. Diese müssen auch immer in Readings dargestellt werden. Bedingungslos!
Eingeltlich sollten die Readings automatisch, ohne Kommando, upgedated werden. Ein "force-read-device-states" wäre notwendig, wenn es bedenken beim automatischen update gibt. Sonst ist es obsolet.
Eine Ausgabe in ein Reply-Fenster ist nicht notwendig. Die Readings sind bedingungslos sichtbar. Methoden zum Abgragen/Ausgeben von Readings sind in FHEM standart. Modul-spezifische Methoden sollten nur angeboten werden, wenn es gewichtige Gründe gibt.
Nächstes Thema:
Die "config" Kommandos beziehen sich auf "Register"
Die "device" kommandos auf "Zustände"
=> korrekt soweit?
Bei der Namensgebung habe ich (wieder einmal) ein Problem. Welche Bedeutung willst du dem Anwender mitgeben? Hier mein Vorschlag
- "config" bezieht sich auf Renamente Daten (hatten wir schon, scheint auch so durchgezogen
- "device" sollte nur ein einer Bedeutung im UI genutzt werden. In der CHN Welt sehe ich es erst einmal garnicht. Bestenfalls wenn wir von CHN0/Device reden.
- "Zustände" brauchen einen Namen. Da datapoint für Config und Zustände als Sammelbegriff genutzt wird ist es "verbraten". "State" ist nicht passend, schon zu häufig genutzt. "Value" wäre noch frei.
=> damit wären die Kommandos
* devicedesc => "description"
* devstate => "values"
Mir klar, es ist eine lästige Änderung zum Zeupunkt nach der einführung. Allerdings ist eine unsaubere Nomenklatur ein ewiges Problem.
Natürlich können auch andere Namen gewählt werden, nur eben eindeutig und FHEM passend.
Noch ein Problem bei mir:
ein
set <device> datapoint LEVEL 1
funktioniert genaus wenig wie ein "on". Keine Fehlermeldung, keine Reaktion.
Ich würde gerne bei der EQ-3 Logik bleiben:
- Ein Device verfügt über kein oder ein Paramset MASTER.
- Ein Kanal verfügt über ein oder mehrere Paramsets aus der Menge MASTER, LINK, VALUES, SERVICE.
- Ein Device entspricht NICHT(!) dem Kanal 0.
- Das Paramset MASTER von Kanal 0 ist NICHT(!) identisch mit dem Paramset MASTER vom Device. Daher ist eine Zusammenlegung von device und channel 0 zwar möglich, aber für den erfahrenen Nutzer eventuell verwirrend. =>
Ich setzte es jetzt aber mal so um, wohlwissend, dass es Chaos gibt, sobald EQ-3 ein Device rausbringt, das auch in Kanal 0 einen MASTER verwenden.!- Ich unterscheide Datenpunkte (VALUES), Konfigurationsparameter (MASTER) und Linkparameter (LINK)
Zuordnung der Befehle zu Paramsets:set/get config, get configlist => MASTER, LINK
set/get datapoint, get update => VALUES
set/get paramset, get paramsetlist => Alle Paramsets.
Folgende Befehle dienen der reinen Informationsanzeige:
get devicedesc, get paramsetdesc
=> Kanal 0 und 'device' in HMCCUCHN Devices ist eine Krücke, damit der Nutzer nicht auch noch ein HMCCUDEV definieren muss, um Parameter in MASTER abfragen und setzen zu können. Am liebsten würde ich HMCCUCHN entfernen, da HMCCUDEV alles eigentlich viel logischer implementiert. Ist allerdings Overhead, wenn man z.B. ein einfaches Device wie einen Fenstersensor einbinden möchte.
Das Paramset VALUES entspricht den Datenpunkten (Datapoints). Die Befehle
get/set datapoint und
get update beziehen sich auf das Paramset VALUES. Das Paramset VALUES ist das einzige, dessen Werte von der CCU per RPC Server automatisch aktualisiert werden. Die Befehle get datapoint und get update sind daher nur notwendig, wenn man mal explizit Werte von der CCU holen möchte. get datapoint ist dabei die "kleinste" Einheit. Es entspricht im Prinzip der State() bzw. Value() HMScript-Methode eines Datenpunktes. get update hingegen ruft Value()/State() für alle Datenpunkte eines Kanals oder aller Kanäle eines Gerätes auf (HMCCUDEV).
Die Datapoint Befehle verwenden nicht RPC sondern HMScripts. Das hat den Vorteil, dass man mit einem Befehl Datenpunkte aus mehreren Kanälen / Paramsets setzen kann. Der RPC Request setParamset kann immer nur Parameter innerhalb eines Paramsets setzen.
Zitat von: martinp876 am 12 Januar 2020, 12:08:32
get <HMccuChn> paramsetdesc
Ich würde die Auswahl channel/device streichen. Mein Vorschlag ist wie schon vormals erwähnt, das "Device" im "Chan0" zusammenzufassen.
Wähle ich "Channel" als Option bei einem Kanal >0 bekomme ich immer auch Kanal0. Das macht keinen Sinn und ist typisch eh wenig interessante Info. Ch0 bezieht sich auf "die Kommunikation" und ist bei 90% aller Geräte identisch.
Antrag 1) Kanal 0 wird nur für Kanal 0 ausgegeben.
Antrag 2) Device wird immer automatisch bei Kanal 0 ausgegeben
Antrag 3) als Überschrift wäre der DeviceTyp und der KanalTyp schön
Ch0 unterscheidet sich je nach Interface (BidCos, IP, ...). Ch0 enthält z.B. auch LOWBAT, ist also durchaus hilfreich. Als User möche ich nicht für jedes Device auch noch ein HMCCUCHN Device für Kanal 0 definieren, um diese Infos zu bekommen. Die Bildschirmausgaben kann ich alle noch anpassen (auch Dinge wie short / long bei Links). Im Moment liegt die Prio auf funktionalen Dingen bzw. die v4.4. benutzbar zu machen.
Zitat
get <HMccuChn> config/configList
- Ich sehe nicht, dass bei config die Register als Readings gespeichert werden
- ich verstehe nicht, warum man speichern in Readings manuell anstossen muss. Das sollte immer passieren, wenn gelesen wurde.
Vielleicht noch ein Fehler. Normalerweise sollten die Readings mit "R-..." auftauchen.
Zitat
Zum Inhalt: Link Readings
Im Gegensatz zu Parameter-Description gibt es den Link Satz bei den eigentlichen Parametern. Link bedeutet, dass das Device gepeert ist und zu diesem peering ein Registersatz existiert.
=> für jedes einzelne Peering existiert ein Link-Datensatz.
=> du musst also zuerst die Links auslesen, dann die Link-Parametersätze
Kommt, nur nicht alles auf einmal. Muss nebenher noch arbeiten.
Links haben im Moment niedrige Prio. Bis ich das implementiert haben, kann man sie in der CCU einfach und komfortabel einrichten.
Zitat
get <HMccuChn> deviceinfo
das wird, nehme ich an, obsolet.
Ja.
Zitat
get <HMccuChn> datapoint
klappt bei mir nicht. Muss ich etwa besonderes tun?
Vermutlich das leidige ccureadingfilter Thema. Setze mal das Attribut auf .* oder lösche ccudef-readingfilter im I/O Device.
Zitat
Eingeltlich sollten die Readings automatisch, ohne Kommando, upgedated werden. Ein "force-read-device-states" wäre notwendig, wenn es bedenken beim automatischen update gibt. Sonst ist es obsolet.
Genau das macht ja der RPC-Server.
Zitat von: zap am 12 Januar 2020, 16:57:07
... Am liebsten würde ich HMCCUCHN entfernen, da HMCCUDEV alles eigentlich viel logischer implementiert. Ist allerdings Overhead, wenn man z.B. ein einfaches Device wie einen Fenstersensor einbinden möchte
Genau - und speziell bspw. dann, wenn man ein Wired-Device mit 12 Kanälen eingebunden hat, von denen jeder Kanal einem anderen Raum für einen Fensterkontakt zugeordnet ist. Und deswegen plädiere ich dafür, grds. auch nur einen Kanal als fhem-Device definieren zu können.
Ok, das ist jetzt ein Argument für HMCCUCHN. Für HMCCUDEV spricht, dass es Geräte gibt, deren Datenpunkte in verschiedenen Kanälen liegen (HmIP Steckdosen mit Energiemessung, Thermostate, ...). Da macht dann HMCCUDEV das Leben leichter.
Vielleicht finde ich ja mal eine Lösung, die beidem gerecht wird.
Beispiel:
CHN 0001D3C990BC3C:1 ST-WR-Trockner:1
DPT {b} HmIP-RF.0001D3C990BC3C:1.PRESS_LONG = [E]
DPT {b} HmIP-RF.0001D3C990BC3C:1.PRESS_SHORT = [E]
CHN 0001D3C990BC3C:3 ST-WR-Trockner:3
DPT {f} HmIP-RF.0001D3C990BC3C:3.ON_TIME = [W]
DPT {i} HmIP-RF.0001D3C990BC3C:3.PROCESS = 0 [RE]
DPT {i} HmIP-RF.0001D3C990BC3C:3.SECTION = 0 [RE]
DPT {i} HmIP-RF.0001D3C990BC3C:3.SECTION_STATUS = 0 [RE]
DPT {b} HmIP-RF.0001D3C990BC3C:3.STATE = false [RWE]
CHN 0001D3C990BC3C:6 ST-WR-Trockner:6
DPT {f} HmIP-RF.0001D3C990BC3C:6.CURRENT = 0.000000 [RE]
DPT {i} HmIP-RF.0001D3C990BC3C:6.CURRENT_STATUS = 0 [RE]
DPT {f} HmIP-RF.0001D3C990BC3C:6.ENERGY_COUNTER = 89936.700000 [RE]
DPT {b} HmIP-RF.0001D3C990BC3C:6.ENERGY_COUNTER_OVERFLOW = false [RE]
DPT {f} HmIP-RF.0001D3C990BC3C:6.FREQUENCY = 49.970000 [RE]
DPT {i} HmIP-RF.0001D3C990BC3C:6.FREQUENCY_STATUS = 0 [RE]
DPT {f} HmIP-RF.0001D3C990BC3C:6.POWER = 0.000000 [RE]
DPT {i} HmIP-RF.0001D3C990BC3C:6.POWER_STATUS = 0 [RE]
DPT {f} HmIP-RF.0001D3C990BC3C:6.VOLTAGE = 233.100000 [RE]
DPT {i} HmIP-RF.0001D3C990BC3C:6.VOLTAGE_STATUS = 0 [RE]
CHN 0001D3C990BC3C:8 ST-WR-Trockner:8
DPT {i} HmIP-RF.0001D3C990BC3C:8.WEEK_PROGRAM_CHANNEL_LOCKS = 0 [RE]
DPT {i} HmIP-RF.0001D3C990BC3C:8.WEEK_PROGRAM_TARGET_CHANNEL_LOCK = [W]
DPT {i} HmIP-RF.0001D3C990BC3C:8.WEEK_PROGRAM_TARGET_CHANNEL_LOCKS = [W]
Um das mit HMCCUCHN abzubilden, bräuchte ich also mindestens 4 Devices. Mit HMCCUDEV habe ich alles an einer Stelle.
Verstehe.
Ich habe noch ein Argument: Der 2-Kanal-Switch. Den verwende ich bspw. für Licht in zwei verschiedenen Räumen.
Mal die ersten antworten :
Hnccudev und chn parallen ist aufwändig.
Für mich gibt es nur chn. Ggf muss ich es mir selbst basteln. Als ich vor jahren anfing und mit rudi diskutierte hat er klar gesagt, dass fhem funktionen Einzel verwaltet. Devices sind nicht wirklich konform.
Deine Entscheidung. Gib mir rechtzeitig Bescheid.
Klar sind die master sets des device und chn0 unterschiedlich. Wo ist das problem? Alles kaum ein Aufwand. Nur eine Festlegung.
Ein paar "erfahrene" user sind einfacher umgestellt als hoffentlich viele neulinge. Das device und chn0 sind notwendig. Aber sehen will sie der user fast nie.
Wie gesagt, nenne deine Ziele. Wenn sie zu mir passen, ok. Sonst werde ich den Chanel layer selbst umsetzen. Keine Drohung, nur eine Klarstellung. Es sind schlicht 2 Wege. Der device-ansatz findet mit Sicherheit Freunde!
Nachtrag: genau wie ralli gesagt hat ist fhem nach funktionen getrennt. All Darstellungen. Wäre schade ( für mich nicht nutzbar) wenn hmccu das nicht unterstützt und sei eigenes ding dreht.
Ich habe kein Problem damit, HMCCUDEV und HMCCUCHN parallel zu unterstützen. Beide Module sind einfach gehalten. Die "Intelligenz" steckt in HMCCU und HMCCURPCPROC. Wenn jemand nur HMCCUCHN nutzen möchte, kann er das gerne tun.
Als Nutzer ist es für mich logischer, wenn ein Homematic Gerät einem FHEM Gerät entspricht => HMCCUDEV.
Keine Regel ohne Ausnahme: Es gibt Geräte (Fernbedienungen, Mehrfachschalter), bei denen HMCCUCHN die bessere Wahl ist.
Aber als Nutzer möchte ich nicht für die Steuerung eines Thermostaten oder einer Steckdose mehrere Devices definieren und verwenden müssen, um Temperatur und Wochenprogramm zu steuern, nur weil EQ-3 diese Funktionen in verschiedene Kanäle gepackt hat. Wenn ich die Fragen in diesem Forum zu HMCCU sehe, sehen das die Nutzer genauso und nutzen hauptsächlich HMCCUDEV.
Und wenn jetzt das Argument kommt, dass man das in FHEM ja alles schön mit Readinggroups und ähnlichen Konstrukten abbilden kann: Warum sollte man sich das antun? Das macht die Welt dann eher noch komplexer. Man baut etwas nach, was rein logisch in der CCU und in HMCCUDEV schon existiert.
Das Motto von HMCCU ist: Best of both worlds (FHEM + CCU). Soll heißen: Dinge, die die CCU gut kann und/oder die man eher selten anfassen muss, macht man in der CCU. Alles andere in FHEM.
Beispiel:
CCU: Anlernen von Devices, Verknüpfung von Devices, Anlegen von Wochenprogrammen, ...
FHEM: Steuerung, Anzeige von Zuständen, ...
Der Vorteil dieser Aufteilung zeigt sich am besten bei HmIP und HmIP-Wired: Ich musste so ziemlich genau 2 Zeilen Code in HMCCU ändern, damit die beiden neuen Protokolle unterstützt werden (damit das neue Adressformat erkannt wird).
Je mehr man von den Funktionen der CCU in FHEM nachbaut, desto anfälliger und vor allem aufwändiger werden diese Lösungen bei Änderungen auf Herstellerseite.
Ich hoffe, damit wird klarer, welche Ziele ich mit HMCCU verfolge.
@Martin: Was sind Deine Ziele? Wofür möchtest Du HMCCUCHN / HMCCU verwenden? Schwebt Dir eine Integration in VCCU vor? Vielleicht kannst Du darauf mal etwas genauer eingehen.
Ich muss bei der Weiterentwicklung von HMCCU alle User berücksichtigen.
Nächste Iteration der 4.4 ist im contrib eingecheckt. Die HMCCUCHN Befehle habe ich nochmal angepasst. Kurze Zusammenfassung weiter unten. Sonstige Änderungen.
Die Readings werden nun einigermaßen intelligent aktualisiert:
- Wenn eine Regel im Attribut substitute existiert, greift diese zuerst
- Wenn nicht, werden Default Werte eingesetzt, z.B. true/false bei BOOL Parametern. Außerdem werden ENUM Werte übernommen, z.B. beim Datenpunkt ERROR (z.B. NO_ERROR, SABOTAGE). Dafür muss man also keine substitute Regel mehr erstellen.
Die (geänderten) Befehle aus der CommandRef:set <name> paramset [device] [<paramset>] <parameter>=<value[:<type>]> [...]
Set multiple datapoints or config parameters by using RPC interface instead of Rega. With option 'device' a parameter set of the device is set instead of the current channel. Parameter paramset is a valid parameter set name (i.e. MASTER, LINK, ...). The default parameter set is 'VALUES'. Supports attribute 'ccuscaleval' for datapoints. Parameter parameter must be a valid datapoint or config parameter name. If type is not specified, it's taken from parameter set definition. The default type is STRING. Valid types are STRING, BOOL, INTEGER, FLOAT, DOUBLE
set values => Alias für
set paramset mit paramset = VALUES
set link => Alias für
set paramset mit paramset = LINK
set config => Alias für
set paramset mit paramset = MASTER
get <name> paramset [<paramset>[,...]] [<filter-expr>]
Get parameters from all or specific parameter sets of device and channel. If attribute 'ccureadings' is 0 results are displayed in browser window. Otherwise they are stored as readings beginning with "R-" for MASTER parameters and "L-" for LINK parameters. Values from other parameter sets are stored without prefix. Prefixes can be modified with attribute 'ccuReadingPrefix'. If no paramset is specified, all parameter sets will be read. Parameters can be filtered by filter-expr. If option 'device' is specified parameters of device are read. Without option 'device' parameters of current channel and channel 0 are read.
get values => Alias für
get paramset mit paramset = VALUES
get links => Alias für
get paramset mit paramset = LINK
get config => Alias für
get paramset mit paramset = MASTER
Hört sich gut an.
A) braucht man den parameterset im komando? Die parameter sind m.e eindeutig. Die zuordnung kannst du selbst machen.
B) mir ist nicht klar, ob du LINK verstanden hast. Es gibt schlicht keinen Parametersatz LINK. es gibt einen parametersatzTYP LINK. Jedes (JEDES) direkte peering erzeugt einen eigenen parametersatz vom typ LINK. Als Adresse des jeweiligen link satzen musst du die Adresse des peers angeben. Steht im dokument zu den Datenpunkten von eq3 beschrieben. Funktioniert genau so. Auch in culhm.
Für link brauchst du somit in jedem fall eine 2 stufige Adressierung. Peeraddr:Parameter.
Natürlich muss als peeradresse der name der gepeerten hmccuchn entity genutzt werden. Wir arbeiten ja auf hochsprache und nicht im maschinencode :)
Am Wochenende werde ich es testen. Danke
get links liest Link spezifische Parameter, die im Parameterset LINK liegen. Die sind immer da, auch wenn ein Kanal gar nicht verknüpft ist. Beispiel für einen Fensterkontakt:
1.EXPECT_AES = false
1.PEER_NEEDS_BURST = false
Links an sich (also Verknüpfungen wie Fensterkontakt mit Thermostat) werden (noch) nicht unterstützt.
Und ich bin mir auch nicht sicher, ob die kurzfrisitg unterstützt werden, s.a. meinen vorvorherigen Post ("best of both worlds").
Vielleicht ist "get links" hier etwas misleading. Ich denke mir nen anderen Befehl aus. Oder es kommt irgendwann ein "get peer"
Ich bin ein Freund von getallconfig in einem Schuss.
Da es aus dem Cache gelesen wird ist es kein funkproblem.
Was link ohne Adresse soll ist mir nicht klar. Evtl das senden an die zentrale.
Bei hm rf existiert es nicht.
Um die Anforderung mit dem auslesen zu präzisieren: einzeln lesen ist Mist. Ich hole sowieso immer alles. Am ende will ich wieder templates zu anwenden und prüfen. Es muss ein Kommando geben, welches am schluss meine komplette hmccu konfiguration auf Probleme prüft. Hat sich in culhm sehr gut bewährt.
Bei hmccu ist es erst einmal einfacher, da es um den abgleich mit dem ccu cache geht. Kein funk.
Ein forceReadDevice ist dann noch ein weiteres Thema.
Ein getConfig liest demnach die configuration was da ist MASTER plus alle LINKS.
Values sind nicht konfiguration sondern operational. Diese erwarte ich sowieso komplett in den readings.
Ein updateValues sollte also den kompletten readable value satz der ccu entlocken und in readings packen. So meine vorstellung.
Der anwender kommt mit den begriffen master\values\link hier nicht in kontakt.
Bezüglich des set datapoint sehe ich ein leichtes problem. Die aktuelle, flexibele Implementierung ist für mich zu flexibel und nicht userführend. Wir sind hier auf Assembler level, knapp über machinencode. Aber es fehlt noch ein gutes stück zur hochsprache. Und da müssen wir hin.
Ich würde i einem set nur Daten eines typs zulassen. Master parameter ODER link parameter EINES peers ODER operational values.
Für operational values sehe ich eigentlich keine setdatapoint. Das sind typisch eigenständige komandos. Der user muss hier geführt werden, was zusammen gehört. Beispiel ein set level (also "ON") . Das ist ein wert. Aber in dem kommando kann man eine einschaltdauer mitgeben. Oder bei dimmern einen level.
Einfache, einzelne kommandos kann man selbst generierent machen. Andere muss man im verbund anbieten. Das ist dann handarbeit.
Bspw kann man parameter aus value wie inhibit aus dem parametersatz lesen. Man erkennt dass es bool ist und der code generiert selbständig ein set inhibit On/off oder true/false.
Und, es ist mir klar, dass alles zeit braucht. Ich arbeite auch nebenbei ;) .Mich interessiert erst einmal was dein plan und die architektur sowie das look and feel sein soll.
Die Config wird ja jetzt schon automatisch und in einem Rutsch gelesen, teilweise schon bei der Definition von IO und RPC Device, teilweise nach dem Start der RPC Server. Ebenso stehen sowohl in HMCCURPCPROC als auch HMCCU Befehle zur Verfügung, um die Daten zu aktualisieren.
Die "Einzelbefehle" in HMCCUCHN und HMCCUDEV sind insbesondere dafür gedacht, wenn ein neues Gerät bzw. ein neuer Gerätetyp erstmalig konfiguriert werden soll. Die angezeigten Informationen sollen eine Hilfe für den Nutzer sein, wenn er die für ihn interessanten Datenpunkte und Parameter ermitteln will. Dadurch muss er nicht darauf warten, dass ein neuer Gerätetyp komfortabel von HMCCU unterstützt wird. Durch den generischen Einsatz kann ein Nutzer einen neuen Gerätetyp sofort nutzen, sobald er auf den Markt kommt.
Ich möchte eben nicht wie in CUL_HM jeden einzelnen Wert für den Nutzer hardcoded im Modul implementieren.
Einige Dinge erledigt HMCCUCHN / HMCCUDEV jedoch heute schon dynamisch. So werden automatisch pct oder on-for-timer BEfehle bereitgstellt , wenn bestimmte Datenpunkte verüfgbar sind.
ZitatDie Config wird ja jetzt schon automatisch und in einem Rutsch gelesen, teilweise schon bei der Definition von IO und RPC Device, teilweise nach dem Start der RPC Server. Ebenso stehen sowohl in HMCCURPCPROC als auch HMCCU Befehle zur Verfügung, um die Daten zu aktualisieren.
Super!
Warum sind die Kommandos in HMCCURPCPROC zu finden? Mein Wunsch wäre, mich im die "PROC" nicht zu kümmern. Ich will HMCCU und HMCCUCHN als bedin-interfaces. "PROC" sollten aus meiner Sicht "hidden" sein. Wenn du sie benötigt, ok. Aber muss mich (als Anwender) das interessieren?
ZitatDie angezeigten Informationen sollen eine Hilfe für den Nutzer sein, wenn er die für ihn interessanten Datenpunkte und Parameter ermitteln will
Dadurch muss er nicht darauf warten, dass ein neuer Gerätetyp komfortabel von HMCCU unterstützt wird
Verstehe ich nicht. Du musst doch kein Gerät manuell eintragen. Du solltest das Pauschal machen. In CULHM habe ich die XML Dateien nicht gehabt und somit alles manuell eintragen müssen. Allerdings zusammengefasst. Weiter ist HM-RF quasi tot. Die Maintenance hat also ein Ende - sowieso. Ist auch schon lange Stabil.
Du - mit der CCU im Hintergrund - kannst jede Menge "Services" wie Kommandos und Readings automatisch generieren. Die CCU bietet dir alle Optionen. Wenn in der CCU ein neues Device erscheint DARF es KEINER Aktion deinerseits benötigen, das Device per default zu unterstützen. Und das geht!!!
So - hier einmal meine Betrachtung der "Operational Parameter". Ich hatte mich schon über Konfigurations-parameter ausgelassen und meine Vorstellungen grob skiziert. Jetzt also "Operational"
1) Definition
Operational parameter sind alle Parameter im Set "VALUES". Welche ein Kanal besitzt und welche Readable sind bekommst du von der CCU mitgeteilt. Diese parameter sollten (müssen) alle in Readings dargestellt werden. Immer und gnadenlos.
2) Update der Oper-param
dies funktioniert typisch automatisch. Das ist schon jetzt so -zumindest habe ich noch keine Ausnahme gesehen. Also prima.
3) Manueller Update
Der User könnte den Verdacht haben, dass etwas nicht stimmt. Dann braucht er die Möglichkeit, einen Update anzustossen. Das will er nicht reading-für-reading machen. Macht auch keinen Sinn, da du die Werte mit einem einzigen Kommando en-bloc geliefert bekommst.
Schön wäre es, sich an die Kommandos der CUL_HM zu halten. In FHEM gibt es immer wieder (sinnvolle) Bestrebungen den Wildwuchs der Kommandos einzudämmen. CUL_HM nutzt hier "set <entity> statusRequest". Es ist ein "set" kommanod, da Rudi festgelegt hat dass ein "get" einen direkten Return-wert liefert. Also eine System-festlegung ... nicht immer beachtet (schade). Wenn du dich für ein anderes kommando entschiedest, auch gut. Hauptsache es gibt one-shot ein webCmd zum Update aller Oper-Param.
4) System-start
startet FHEM oder startet die CCU nach FHEM sind diese nicht Synchron. Ach wenn es andere Stimmen gibt ist es in meiner Welt ZWINGEND notwendig, die Systeme zu Synchronisieren!!!. Um den vorsichtigen Usern entgegen zu kommen habe ich es abschaltbar gemacht. Über ein Attribut kann man die Schärfe der Synchronisation einstellen. Nach einem Anfänglichen Schreck nutzen wohl die meisten Anwender den Service. Die Schärfe unterscheidet OperValue vs ConfigParam. Thema heute ist "OperValue".
Um dies zu realisieren braucht es a) ein Attribut in HMCCU welches die "autoReadValues" funktion steuert. Per Defaults "syncAllOperParams" b) braucht es möglicherweise eine Steuerung, die Abfrage zeitlich zu entzerren. In CUL_HM bspw ist es als Hintergrund-Job angelegt und wird verzögert wenn bspw der credit-value einen Wert unterschreitet. Das ist einstellbar - braucht aber auch niemand - klappt mit den Default-Werten.
5) Reading-Validity
Nur Readings mit nach bestem wissen gültigen Werten werden angezeit. Der "Ersteller" des Readings trägt die Verantwortung. In der Konsequenz heist dies, wenn eine Option angeboten wird die Readings lower-case oder upper-case darzustellen dann muss (MUSS) mit der Umstellung auf die neuen Werte der alte Bestand gelöscht werden.
6) Device-readings
im Kanal macht es Sinn, den Operationellen Zustand des Device (Kanal-0) darzustellen. Allerdings nur als Zusammenfassung.
Ich stelle mir das so vor:
Reading deviceState [ok|dead|unreachable|configPending|...]
Hierbei gibt es eine Prio, welche du festlegst. Ist bspw dass Device unreachable dann wird ein config-pending unterdrückt.
Welche Werte es gibt ist offen. Sollte und kann für alle aber gleich sein. Die abstrakten Darstellungen sind einfach. Das Reading sagt dem Anwender, dass es notwendig ist, im Device sich im Maintenance zu kümmern.
Noch eines zum Channel0: eq3 fasst kanal0 und "das Device" in einer Entity zusammen. Habe ich gerade noch einmal nachgesehen. Ich spreche vom User-Interface. Damit liege ich mit eq3 auf einer Line.
Der Anweder muss nicht, an keiner Stelle - zwischen "Kanal 0 " und "device" unterscheiden. Der Programmierer schon, das bist du.
Das will ich auch in HMCCUCHN.
Deine Anmerkung, EQ3 würde devices verwalten ist falsch. Es werden nur Kanäle verwaltet - welche ggf Abhängigkeiten haben. Im Web-Interface gibt es neben der "Room" Ansicht (wie fhem) auch eine "device" Ansicht ( nicht in FHEM verfügbar). Die Architektur und organisation, zuordenbarkeit, filter-optionen, benamung ist ausschliesslich auf Kanal-Ebene organisert.
Genau so wünsche ich es mir auch.
Noch ein Satz zum Service-Kanal. Dieser ist in jeder Entity verfügbar. Ich habe mir den Inhalt angesehen - er ist identisch für alle. Inhalt ist auch nur Information über den FW Stand. Diese Information würde ich nur im Kanal-0 CHN anbieten um die Schwemme an sinnlosen Informationen einzudämmen.
Anbei die Ergebnisse meines (kurzen) Tests der HMCCUCHN get kommandos
get config: keine Antwort. Es sollte ein Feedback geben.
get datapoint: ein get allOperParams muss es geben.
get deviceinfo: Nachkomma -nullen sollten bei Float gelöscht werden. Sonst ist es erst einmal ok
get links: Funktioniert nicht.
get paramset: Funktioniert nicht.
get paramsetList: Funktioniert nicht.
get paramsetdesc: funktioniert gut. Die Temperaturliste eines RT/TC kann man so nicht darstellen. Das muss man konsolidieren!
get update: sieht prima aus
get vales: sieht prima aus - was ist der Unterschied zu get update?
Attr stripbumber funktioniert bei den Registern nicht. Auch sonst scheint es nicht zu klappen.... mus weiter testen.
Hier noch die Ausgabe zum Kanal und welche Werte ich korrigieren würde um sinnlose info zu entfernen. Das sehe ich als einen generellen Filter welchen du hart kodierst. Es geht keine Information verloren!
Device 000E9A498DFE15 HmIP-STHD 000E9A498DFE15 [HmIP-STHD]
Type: HmIP-STHD #dieses Datenfeld fehlt im Kanal 0
AES_ACTIVE: 1 # sinnlos bei IP. AES ist immer aktiv => filtern
AVAILABLE_FIRMWARE: 0.0.0 # ok
CHILDREN: 000E9A498DFE15:0,000E9A498DFE15:1,000E9A49# ok
DIRECTION: # sinnlos bei CHN0. Kann bei NULL weggelassen werden oder nur bei CH0
FIRMWARE: 2.2.2 # ok
FIRMWARE_UPDATE_STATE: UP_TO_DATE # ok
FLAGS: Visible # ok
INDEX: 0 # sinnlos - steht schon in der Definition
PARAMSETS: MASTER,SERVICE # ok
RF_ADDRESS: 10548197 # ok - sollte in hex dargestellt werden
ROAMING: 0 # ok
RX_MODE: ALWAYS,LAZY_CONFIG,BURST # ok
SUBTYPE: STHD # ok
UPDATABLE: 1 # ok
VERSION: 3 # sinnlos. Kann keiner etwas mit anfangen
Channel 000E9A498DFE15:0 HmIP-STHD 000E9A498DFE15:0 [M# Type muss in die Liste der Attribute. Wird dringend benötigt
AES_ACTIVE: 1 # sinnlos bei IP. AES ist immer aktiv => filtern
DIRECTION: # sinnlos bei CHN0. Kann bei NULL weggelassen werden oder nur bei CH0
FLAGS: Visible # ok
INDEX: 0 # sinnlos - steht schon in der Definition
PARAMSETS: MASTER,VALUES,SERVICE # ok
PARENT: 000E9A498DFE15 # fraglich. CHN0 wird eh mit device zusammengefasst - damit ist es obsolet
PARENT_TYPE: HmIP-STHD # holt man vom Master - hier sinnlos
RF_ADDRESS: 0 # holt man vom Master - hier sinnlos
ROAMING: 0 # holt man vom Master - hier sinnlos
RX_MODE: # holt man vom Master - hier sinnlos
UPDATABLE: 1 # holt man vom Master - hier sinnlos
VERSION: 3 # sinnlos. Kann keiner etwas mit anfangen
Channel 000E9A498DFE15:1 HmIP-STHD 000E9A498DFE15:1 [H# Type muss in die Liste der Attribute. Wird dringend benötigt
AES_ACTIVE: 1 # sinnlos bei IP. AES ist immer aktiv => filtern
DIRECTION: SENDER # ok
FLAGS: Visible # ok
INDEX: 1 # sinnlos - steht schon in der Definition
LINK_SOURCE_ROLES: CLIMATE_CONTROL_WTH_TRV # ok
PARAMSETS: MASTER,VALUES,LINK,SERVICE # ok
PARENT: 000E9A498DFE15 # holt man vom Master - hier sinnlos
PARENT_TYPE: HmIP-STHD # holt man vom Master - hier sinnlos
RF_ADDRESS: 0 # holt man vom Master - hier sinnlos
ROAMING: 0 # holt man vom Master - hier sinnlos
RX_MODE: # holt man vom Master - hier sinnlos
UPDATABLE: 1 # holt man vom Master - hier sinnlos
VERSION: 3 # sinnlos. Kann keiner etwas mit anfangen
Zitat von: martinp876 am 18 Januar 2020, 12:04:34
Super!
Warum sind die Kommandos in HMCCURPCPROC zu finden? Mein Wunsch wäre, mich im die "PROC" nicht zu kümmern. Ich will HMCCU und HMCCUCHN als bedin-interfaces. "PROC" sollten aus meiner Sicht "hidden" sein. Wenn du sie benötigt, ok. Aber muss mich (als Anwender) das interessieren?
OK
Zitat
Du - mit der CCU im Hintergrund - kannst jede Menge "Services" wie Kommandos und Readings automatisch generieren. Die CCU bietet dir alle Optionen. Wenn in der CCU ein neues Device erscheint DARF es KEINER Aktion deinerseits benötigen, das Device per default zu unterstützen. Und das geht!!!
In 90% der Fälle ja. Aber es gibt eine Reihe von Geräten/Datenpunkten, die eine Sonderbehandlung benötigen (kennst Du sicher, E-Paper Display, Rollladen mit Lamellenverstellung => LEVEL_COMBINED und was sich EQ-3 sonst noch an hässlichen Lösungen ausdenkt)
Zitat
Operational parameter sind alle Parameter im Set "VALUES". Welche ein Kanal besitzt und welche Readable sind bekommst du von der CCU mitgeteilt. Diese parameter sollten (müssen) alle in Readings dargestellt werden. Immer und gnadenlos.
ccureadingfilter wird es weiterhin geben, allerdings mit .* als Default. Hintergrund: Sonst entstehen bei einigen Geräten, die z.B. Wochenprogramme als Values anbieten, gigantische Reading Listen.
Zitat
Der User könnte den Verdacht haben, dass etwas nicht stimmt. Dann braucht er die Möglichkeit, einen Update anzustossen. Das will er nicht reading-für-reading machen. Macht auch keinen Sinn, da du die Werte mit einem einzigen Kommando en-bloc geliefert bekommst.
=> "get update", gibts bereits für das I/O Device sowie HMCCUCHN und HMCCUDEV.
Zitat
Schön wäre es, sich an die Kommandos der CUL_HM zu halten. In FHEM gibt es immer wieder (sinnvolle) Bestrebungen den Wildwuchs der Kommandos einzudämmen. CUL_HM nutzt hier "set <entity> statusRequest". Es ist ein "set" kommanod, da Rudi festgelegt hat dass ein "get" einen direkten Return-wert liefert.
Mit dieser seltsamen Logik werde ich mich nie anfreunden können. Aber wenn es Dich glücklich macht, lasse ich jeden get BEfehl eben etwas anzeigen und/oder baue auch noch ein set statusRequest ein, das intern einen "get update" macht.
Was ich nicht machen werde: Alle BEfehle von CUL_HM nachbauen. Es gibt durchaus einige User, die sich an die HMCCU Befehle gewöhnt haben. Etwas geistige Flexibilität der CUL_HM User kann ich hoffentlich erwarten.
Zitat
4) System-start
startet FHEM oder startet die CCU nach FHEM sind diese nicht Synchron. Ach wenn es andere Stimmen gibt ist es in meiner Welt ZWINGEND notwendig, die Systeme zu Synchronisieren!!!.
Das ist schon seit x Versionen in HMCCU integriert. HMCCU wartet, bis die CCU fertig ist. Danach werden die RPC-Server gestartet und danach wird alles synchronisiert.
Zitat
Nur Readings mit nach bestem wissen gültigen Werten werden angezeit. Der "Ersteller" des Readings trägt die Verantwortung. In der Konsequenz heist dies, wenn eine Option angeboten wird die Readings lower-case oder upper-case darzustellen dann muss (MUSS) mit der Umstellung auf die neuen Werte der alte Bestand gelöscht werden.
OK
Zitat
6) Device-readings
im Kanal macht es Sinn, den Operationellen Zustand des Device (Kanal-0) darzustellen. Allerdings nur als Zusammenfassung.
Ich stelle mir das so vor:
Reading deviceState [ok|dead|unreachable|configPending|...]
Hierbei gibt es eine Prio, welche du festlegst. Ist bspw dass Device unreachable dann wird ein config-pending unterdrückt.
Welche Werte es gibt ist offen. Sollte und kann für alle aber gleich sein. Die abstrakten Darstellungen sind einfach. Das Reading sagt dem Anwender, dass es notwendig ist, im Device sich im Maintenance zu kümmern.
Im Prinzip hast Du das heute schon im "hmstate" Reading. Blöderweise hat EQ-3 bei einigen Geräten LOW_BAT in Kanal 1 gepackt. Aber mit solchen Querschlägern muss man halt leben.
Zitat
Noch eines zum Channel0: eq3 fasst kanal0 und "das Device" in einer Entity zusammen. Habe ich gerade noch einmal nachgesehen. Ich spreche vom User-Interface. Damit liege ich mit eq3 auf einer Line.
Da werden wir uns wohl nie einig. Beispiel:
CCU Menü Start > Geräte: Die Geräte gruppieren die Kanäle, über die dann die Steuerung erfolgt.
CCU Menü Einstellungen > Geräte: Parameter (=MASTER) gibt es für das Gerät (manchmal) und für Kanäle (auch manchmal), manchmal auch für beide.
Mit der automatischen Erkennung, ob ein Parameter zum Device oder einem Kanal gehört, wird es auch nicht klappen. Niemand wird Dir garantieren, dass EQ-3 nicht irgendwann einen Parameter MASTER.FLAGS für das Device UND einen Kanal einführt (nur als Beispiel). Was dann? Soll das Modul dann beide setzen oder einen auswürfeln?
Also: den Kanal 0 in ein zusammengefasstes Reading legen: von mir aus. Die Trennung von Device und Kanal bei konfigurativen Parametern (MASTER) muss es aber weiter geben.
Hört sich schon gut an. Ich werde das epaper ein mal im Hinblick auf den service Kanal inspizieren. Klar ist sowie: sollte weitergehende info enthalten sein muss sie verarbeitet werden. Allerdings ist es kein Grund, unnötige und doppelte Werte im Kanal darzustellen.
Bei "get" stimme ich dir zu. Ich wollte es auch do implementieren. Allerdings habe ich mich dem chef Architekten Rudi untergeordnet. In der Hoffnung dass fhem im userinterface einer einheitlichen Semantik folgt. Nun ja.....
Und ja, es gibt ein paar kuriose details von eq3... Das ist dann so. Ausrutscher vermute ich.
Zu MASTER: hat eine entity register welche nicht zu einem link gehören sind sie in MASTER zu finden. Bei Gerätetypen mit definitiv einem Kanal hatte eq3 die wahl die config im kanal oder im device zu platzieren. Ein Dimmer oder rolloaktor könnte auch mehrere Kanäle haben. So ist also driveup und down im Kanal zu finden. Einstellungen zu statusmsgs im device.
Grundsâtzlich sind VALUES operationell und MASTER sowie LINK config. Das ist immer so. LINK gibt er nur beim peeren. Auch bei den Device internen peerings, logisch. LINK ist also eine dynamische Menge an Daten.
Hier ist zur Darstellung derselben ein frontend zu gestalten. Mit einer endlos langen Ausgabe ist keinem gedient.
Das mit den readings updates ist prima!!!
Leider erst wieder am Wochenende. Wegen den Brötchen.
@Martin: Im Moment machen weitere Tests keinen Sinn. Morgen gibt es (hoffentlich) ein Update
moin,
ist es über hmccu eigentlich möglich für ein "beliebiges" device registerbeschreibungen aus der ccu zu bekommen, ohne dass das device in der ccu angelernt ist?
also ein get cmd dem ich model und firmware version übergebe und als antwort eine liste sämtlicher parameter beschreibungen aller channel erhalte.
theoretisch müsste es doch machbar sein, oder nicht?
Ja das geht, da das IO Device (in der 4.4) sowieso alle Infos hat. Es gibt nur noch nicht die entsprechenden Befehle. Aber demnächst.
Nun, testen kann man immer. Und noch habe ich kein Wochenende.
Aber bspw die internals sind sinnlos:
Channels ist immer 1 bei hmccuchn
Ccuaddr ist immer identisch der DEF.
Beide sind also obsolet.
Weiter wünsche ich mir das in der hmccu das abgleichen der entities wie schon angesprochen in 3 level:
Verify: zeigt Unterschiede zwischen ccu und fhem
Update: legt alle Kanäle an, welche fehlen. Kein löschen.
Force: legt an und löscht . Master ist die ccu.
Das kommando sollte keinen weiteren Optionen haben damit es per pulldown Liste ausgeführt werden kann.
Bei verify werden natürlich alle notwendigen Definitionen und values nachgeladen.
hmm, mein Anspruch ist eigentlich, dass FHEM und CCU jederzeit synchron sind, und zwar ohne Eingriff des Nutzers. Das bezieht sich jetzt auf
- das I/O Device, das alle Geräte mit ihren Kanälen und Parametern kennt
- die FHEM Devices, die die in ihren Readings die aktuellen Zustände der Geräte/Kanäle in der CCU widerspiegeln
ich vermute, Deine Überlegungen gehen noch einen Schritt weiter: In FHEM sollen auch für alle Geräte/Kanäle in der CCU Instanzen - sprich Devices - existieren (also "autocreate"). Kann man drüber nachdenken, sollte es aber konfigurierbar machen.
Ich persönlich brauche nicht alle CCU Kanäle auch in FHEM.
ccuaddr ist essentiell und wird an vielen Stellen in den Modulen (auch im I/O Device) verwendet. Hintergrund: Der define Befehl akzeptiert auch einen CCU-Device oder Kanalnamen. channels ist tatsächlich obsolet.
Zitatmein Anspruch ist eigentlich, dass FHEM und CCU jederzeit synchron sind, und zwar ohne Eingriff des Nutzers.
uneingeschränkte Zustimmung.
Ich fühle mich wohler wenn der User ein Kommando hat, die Synchronität zu prüfen/ einen manuellen, kompletten sync starten kann. Aber typisch (98% der Fälle) muss es laufen.
ZitatDeine Überlegungen gehen noch einen Schritt weiter: In FHEM sollen auch für alle Geräte/Kanäle in der CCU Instanzen - sprich Devices - existieren (also "autocreate")
Logisch - die natüliche konsequenz.
Allerdings ist "autocreate" zu definieren. So würde ich es machen
a) autocreate ist keine Einstellung. Ohne Kommando werden keine FHEM entities erzeugt oder gelöscht
b) Der Anwender kann per Kommando eine Prüfung anstossen, welche devices in der CCU und in FHEM existieren
c) Der Anwender kann per Kommando fehlende Entites in FHEM erzeugen
d) Der Anwender kann per Kommando fehlende Entites in FHEM erzeugen UND "überschüssige" löschen
Da der User evtl lieber die CHN oder die DEV implementierung wünscht kann man das auch anbieten.
Somit habe ich ein Kommando syncDevices [verifyCHN,updateCHN,forceCHN,verifyDEV,updateDEV,forceDEV]
Default ist verify - CHN oder DEV, deine Entscheidung.
Ein Verfiy gibt eine Liste zurück
1) "fehlende" entites: in der ccu, nicht in FHEM. (wir arbeiten in FHEM. Fehlend ist also fehlt in FHEM)
2) "obsolet" entites: nicht der ccu, in FHEM.
3) "in-Sync" entites: existieren in beiden Welten
I) Der User kann diese Liste nutzen, wenn er einzelne Entites manuell instanziieren oder löschen will.
Verify kann man noch smart gestalten. Dann kann DEV/CHN hier entfallen. Du zeigt, in welcher welt (CHN/DEV) das Element existiert. Oder in beiden. Nur wenn es komplett fehlt kommt es in die "missing" Liste. => smart ist die eigentliche Anforderung!
Dein aktuelles pendant ist "get HMccu devicelist create". Allerdings ist das Kommando bei weitem zu sperrig. Zu viele
(unnötige) parameter. Default output ist die Anzahl der Devices - nicht hilfreich/unnötig.
Ob das Kommando "get devicelist" oder "get syncDevices" oder "set syncDevices" genannt wird ist mir an Ende des Tages egal.
Ich habe gerade 3 neue Geräte installiert - mein "syncDevices create" funktioniert schon. Implementierung ist (wem sage ich das) denkbar einfach. Natürlich funktioniert auch das verify schon. Schliesslich will ich bei solchen Kommandos gerne eine simlation vor ausführung haben.
Und klar ist mir die Bedeutung von ccuaddr klar - auch dei Verwendung. Es ist eben nur doppelt. Und der Platz in "internals" ist kostbar - bitte nicht zu-müllen. Bei Devices sollte auch die Addresse in der Definition stehen. Wird bei jeden Kanal um dessen nummer ergänzet - alles klar.
=> Der Anwender braucht die Addresse quasi nie. Er kann sie bei Bedarf sehen - logisch. Aber alles (ALLES) was das Frontend anbietet wird auf Basis der Namen der entites gemacht. In CUL_HM ist die Adresse die RF-Addr der Devices - und dessen Kanalnummern. Könnte jeder lesen. Anwenden muss es NIEMAND.
Es gibt eine neue Version von der Beta in contrib/HMCCU/FHEM
Neu:
- Nach dem Start von FHEM wird eine Synchronisation mit der CCU getriggert. Bei dieser Synchronisation werden alle Device Descriptions, Parameterset Descriptions und Peerings aller Geräte und Gerätetypen gelesen.
- Nach der Synchronisation werden die Peerings in allen existierenden FHEM Devices eingetragen. In den Internals gibt es je Sender einen Eintrag mit allen Empfängern sowie je Empfänger einen Eintrag mit allen Sendern. Wenn möglich und vorhanden werden die Namen der verknüpften FHEM Devices eingetragen, ansonsten die Namen in der CCU oder als letzten Fallback die Adressen. Der Status der Peering wird in den Readings eingetragen. Hier gibt es ein Reading je Sender/Empfänger Paar. Readingsvalue ist dann OK, oder BROKEN oder whatever. Wichtig: Derzeit werden die Peeringinfos nur einmal beim Start aktualisiert. Ist also noch nicht ganz fertig.
Die Get-Befehle in HMCCUCHN Devices wurden weiter vereinfacht und liefern nun - wie es sich für Get-Befehle gehört - immer auch eine Bildschirmausgabe. Reine Ausgabebefehle (ohne Speicherung der Infos in Readings) gibt es nicht mehr.
Im I/O Device kann eine neue Synchronisation der CCU Konfiguration mit dem Befehl "get ccuConfig" ausgelöst werden (dabei werden auch die Peerings aktualisiert, allerdings werden dabei veraltete Infos nicht gelöscht > Baustelle).
Nach wie vor bleibt CUxD außen vor. Auch HMCCUDEV ist noch nicht auf dem Level von HMCCUCHN angekommen.
Hier mal ein Beispiel für Peering Infos eines Fensterkontakts, der in einer Heizungsgruppe ist:
Internal (Name: L=Link, S=Sender, 1=Kanalnummer):L-S-1 = HM_KL_BO_TH,HM_KL_BO_HZ
Die Devices HM_... sind die Empfänger (Wand- und Heizkörperthermostat)
Readings: (Name: L=Link, S=Sender, 1=Kanalnumer + ZieldeviceL-S-1-HM_KL_BO_HZ = OK
L-S-1-HM_KL_BO_TH = OK
Hört sich gut an. Leider stürtzt es be mir ab. Somit kein Test.
Verdächtig ist erst einmal die sub HMCCU_FindClientDevices ($$$$) routine welche in Zeile 6188 einen Fehler bringt. Ich habe einmal begonnen zu debuggen und habe festgestellt, dass diese Routine offenbar endlos oft aufgerufen wird. Und ich meine endlos oft.
Ich habe noch nicht regründet, was das machen soll - aber das scheint wirklich nicht effizient. Vergleicht hier jeder Kanal sich mit jedem Kanal?
Kennst du die Funktion devspec2array? Diese sollte man zum Suchen von Entites verwenden.
Beachte, dass ich peerings mit Devices habe, welche in der CCU unbekannt sind. Die CCU gibt dann die RFID aus.
Wenn du wissen willst, was gepeert ist musst du nicht suchen, die Liste gibt dir die CCU. Und diese solltest du nutzen! keine eigenen!
Die von der CCU ausgegebenene Adressen sind dann einfach auf Namen zu mappen. Mehr ist nicht zutun.
Schneller und sicherer.
Jetzt muss ich repaieren ;)
Zitat von: martinp876 am 26 Januar 2020, 18:39:55
Beachte, dass ich peerings mit Devices habe, welche in der CCU unbekannt sind. Die CCU gibt dann die RFID aus.
Wenn du wissen willst, was gepeert ist musst du nicht suchen, die Liste gibt dir die CCU. Und diese solltest du nutzen! keine eigenen!
Die von der CCU ausgegebenene Adressen sind dann einfach auf Namen zu mappen. Mehr ist nicht zutun.
Schneller und sicherer.
Jetzt muss ich repaieren ;)
Selbstverständlich nutze ich getLinks()
Mir scheint, Du nutzt eine alte Version von 88_HMCCU.pm. Zeile 6188 ist die erste Kommentarzeile der Funktion HMCCU_GetRPCDevice.
Ok, schaue ich mir an. Hatte frisch geladen...
Ah, nee. Sind ein paar zeilen von mir die es gerutscht haben.
Siehe zeile 6176.
Ich habe die funktion still gelegt, jetzt stürzt es nicht mehr ab.
Scheinbar hat $v keinen Inhalt was das m/ nicht verträgt.
& exists ($ch->{$i}) & wird 2 mal abgefragt. Kostet unnötige Performance.
Wenn die abfrage so oft benötigt wird (code review habe ich nicht gemacht) solltest du einen hash bauen.
Allerdings scheint internals ccuaddr gesucht zu werden. Xzig Mal. Sollte das nicht performanter gehen? Unter Nutzung von DEF{}?
Das wird für jede Device Description aufgerufen. Leider verlasse ich mich darauf, dass die CCU keinen Müll liefert. Macht sie aber doch, zumindest für einen Kanal. Aber gut. Ich baue das um.
Ok. Infos von Fremdsystemen muss man leider immer anzweifeln.
Das mit der devicedescription habe ich nicht verstanden. Hier scheint jede entity mit allen abgeglichen zu werden. Das würde dann exponentiell ansteigen. Wenn das so ist muss es geändert werden -logisch!
Inhaltlich hat mich das nun neugierig genacht. Die ccu gibt alle abhängigkeiten der kanäle eines device vor. Fängt man am device an muss nichts gesucht werden, man weiss es einfach.
Gleiches gilt für peers.
Sucht man nicht nach ccuaddr in internals sondern nutzt einfach die definition hat man das ergebnis sofort. Wieder keine suchschleifen.
Vielleicht habe ich die Notwendigkeit noch nicht erkannt.
Ich habe es jetzt über ne simple lookup Tabelle gelöst. Nun weiß das iO Device jederzeit, welche FHEM Devices zu einer Adresse gehören. Update gibt es morgen.
Die DEFs kann ich nicht verwenden, da ich auch den CCU Geräte- oder Kanalnamen beim Define zulasse. Das will ich auch beibehalten für die, die nur einzelne Geräte der CCU in FHEM definieren möchten. Namen kann man sich leichter merken als Adressen.
Außerdem ist es möglich, für ein CCU Gerät mehrere FHEM Devices zu definieren, z.B. um Werte unterschiedlich darzustellen oder einfach nur zum Testen.
Da bin ich nun zum ersten mal ganz klar anderer Meinung.
In fhem hat absolut JEDES device mehrere readings. Und m.W. macht das keiner so wie du. Fhem hat ausreichend Möglichkeiten, so etwas zu realisieren.
Ich finde es extrem Schade wenn man sich einfach über Konventionen hinwegsetzt.
Natürlich kann sich keiner den Namen aus DEF merken. Daher gibt es in jedem device neben DEF den NAME. Den kann man frei wählen.
Device kann man auch über die Adresse definiere ( wäre logisch)
Nutzt man den device Level braucht man diese Option. Daher befürworte ich channels.
Ich bin aktuell wirklich enttäuscht. Das Konstrukt wird dadurch wilder und entfernt sich vom üblichen fhem. Schade.
Zitat von: martinp876 am 28 Januar 2020, 19:06:05
Da bin ich nun zum ersten mal ganz klar anderer Meinung.
In fhem hat absolut JEDES device mehrere readings. Und m.W. macht das keiner so wie du. Fhem hat ausreichend Möglichkeiten, so etwas zu realisieren.
Ich finde es extrem Schade wenn man sich einfach über Konventionen hinwegsetzt.
Ich verstehe überhaupt nicht, was Du meinst. Selbstverständlich hat jedes Device mehrere Readings. Wo habe ich das Gegenteil behauptet? In meinem vorherigen Post kommt das Wort "Reading" nicht mal vor.
Zitat
Natürlich kann sich keiner den Namen aus DEF merken. Daher gibt es in jedem device neben DEF den NAME. Den kann man frei wählen.
Device kann man auch über die Adresse definiere ( wäre logisch)
Nutzt man den device Level braucht man diese Option. Daher befürworte ich channels.
Ich bin aktuell wirklich enttäuscht. Das Konstrukt wird dadurch wilder und entfernt sich vom üblichen fhem. Schade.
Kann ich alles nicht nachvollziehen, sorry. Ich nehme an, das ist ein Missverständnis.
Vielleicht wird es klarer mit einem Beispiel:
Angenommen, ich habe in der CCU einen Kanal, der wie folgt benannt ist: "Fenster-Wohnzimmer-Links", Adress = 000213C98DD91F:1
Wenn der Nutzer für diesen Kanal ein HMCCUCHN Device definieren möchte, hat er 2 Möglichkeiten:
1.
define Fenster_Wohnzimmer_Links HMCCUCHN Fenster-Wohnzimmer-Links2.
define Fenster_Wohnzimmer_Links HMCCUCHN 000213C98DD91F:1Das ist auch schon alles, was ich mit meinem letzen Post sagen wollte. Wo ist nun das Problem? Welcher Konvention widerspricht das?
P.S. Leider lässt FHEM nicht den gleichen "Zeichenraum" für Devicenames zu wie die CCU. Man kann die Namen also nicht einfach 1:1 übernehmen.
P.S.P.S. Auch folgendes ist mit HMCCUCHN möglich, wenn auch nicht häufig genutzt (2xHMCCUCHN für den gleichen Kanal):
define Fenster_Wohnzimmer_Links HMCCUCHN Fenster-Wohnzimmer-Links
define Fenster_Wohnzimmer_Links_Test HMCCUCHN Fenster-Wohnzimmer-LinksOder ein HMCCUCHN und ein HMCCUDEV (dafür könnte es schon eher Anwendungsfälle geben, gerade im UI Bereich):
define Fenster_Wohnzimmer_Links HMCCUCHN Fenster-Wohnzimmer-Links
define Fenster_Wohnzimmer_Links_CCUDev HMCCUDEV Fenster-Wohnzimmer-Links-Dev
Es gibt ein Update für die 4.4 Beta in contrib/HMCCU/FHEM. Die meisten Änderungen betreffen das HMCCUCHN Modul. Das Modul bietet nun folgende Befehle an:
get config: Liest die konfigurativen Parameter eines Kanals aus der CCU. Die Werte werden angezeigt und als Readings gespeichert. Es werden Parameter zum Device und zum Kanal gelesen. Außerdem werden Verknüpfungsparameter gelesen. Für die Experten: Der Befehl liest die Parameter Sets MASTER und LINK.
get values: List die Werte aus dem Parameter Set VALUES, also die Datenpunkte. Es werden die Werte vom zugeordneten Kanal sowie dem Kanal 0 gelesen. Die Werte werden angezeigt und als Readings gespeichert. Im Gegensatz zu "get update" verwendet "get values" die RPC Schnittstelle der CCU.
get update: Wie "get values", allerdings werden die Werte über die ReGa Schnittstelle mit Homematic Script gelesen. Diese Methode benötigt nur 1 CCU-Request, während "get values" einen Request je Kanal braucht.
get deviceDesc: Zeigt die Geräte- und Kanalbeschreibung an.
get paramsetDesc: Zeigt die Modell-Parameter an.
Beim Start von FHEM werden neben den Geräten und ihren Parametern auch die Verknüpfungen von der CCU gelesen. Die Verknüpfungen werden als Internals "receiver" und "sender" in die einzelnen FHEM Devices eingetragen. Somit ist nun auch in FHEM erkennbar, welche Geräte miteinander verknüpft sind.
Das ebenfalls neue Internal "ccurole" enthält die Rolle eines Kanals (HMCCUCHN) oder der Kanäle (HMCCUDEV). Beispiel: "SHUTTER_CONTACT".
Auch im Modul HMCCU gibt es einige Änderungen:
get ccuconfig: Liest die Geräte mit ihren Konfiguration inklusive der Verknüpfungen neu von der CCU.
get paramsetDesc: Zeigt die Parameterbeschreibung eines CCU Device an.
get deviceDesc: Zeigt die Gerätebeschreibung eines CCU Device an.
Aktualisierung von Readings:
Mittlerweile kommen die FHEM Devices weitgehend ohne die Attribute "substitute" und "ccuscaleval" aus. Die Werte werden abhängig von der Rolle eines Gerätes/Kanals automatisch angepasst. Beispiel: LEVEL wird automatisch von 0-1 auf 0-100 skaliert. Bei Fensterkontakten wird true/false automatisch durch open oder closed ersetzt.
Die nächsten Schritte:
- Übernahme der HMCCUCHN Funktionalität in HMCCUDEV.
- HMCCUDEV und HMCCUCHN "schlauer" machen, d.h. weitgehend automatisch an den Gerätetyp anpassen (Readings, Befehle, ...)
Module nochmal aktualisiert. Übersicht siehe vorheriger Post.
Nun, ich stimme nicht zu, bei den Grundsätzen.
ZitatDie DEFs kann ich nicht verwenden, da ich auch den CCU Geräte- oder Kanalnamen beim Define zulasse.
Namen sind besser - daher vergibt man auch "NAME". Mehr ist nicht notwendig. Das ist FHEM Standart, alles andere nicht.
ZitatDas will ich auch beibehalten für die, die nur einzelne Geräte der CCU in FHEM definieren möchten.
Einzelne Geräte zu definieren ist jederzeit möglich - auch ohne Sonderwege.
ZitatNamen kann man sich leichter merken als Adressen.
Ich verstehe den Inhalt der Aussage nicht. Adressen sind für den User indiskutabel. NAME ist sein zugang. Hatten wir schon. Es bedarf keiner sonderwege, ist alles incl. in Standard.
ZitatAußerdem ist es möglich, für ein CCU Gerät mehrere FHEM Devices zu definieren, z.B. um Werte unterschiedlich darzustellen oder einfach nur zum Testen.
Sind "Werte" etwas anderes als Readings? Dann habe ich es in der Tat nicht verstanden.
Das (für mich unumstößliche Prinzip) in FHEM ist, dass eine Entity ein-eindeutig definiert wird. Darstellungen und tests lassen sich alle (ALLE) mit FHEM bordmitteln erstellen. Das hat erst einmal nichts mit DEV und CHN zu tun.
In FHEM kenne ich nicht alles - aber ALLES was ich bisher genutzt habe arbeitet EXAKT nach dieser Devise. Als Anhänger einer STRIKTEN Nomenklatur ist und bleibt es ein böses Foul hiervon abzuweichen.
Mir sind hierbei jegliche Diskussionen über die Vorteile egal - sorry. Die Konformität in einer modulaen SW ist für mich nicht verhandelbar.
Was sehe ich nun als Konform - Das Layering-model.
A) Die Topographie
FHEM versteht sich als Zentrale. Es verbindet sich mit externen "Entites", also Sensoren und Aktoren. Diese sind typisch Schalter und Taster aber auch Wetterstationen, Stereoanlagen,..... .
Um diese zu Kontaktieren bedarf es möglicherweise IO devices.
=> Die CCU ist demnach ein IO device welches den Zugang zu den Aktoren/Sensoren ermöglicht. Nicht mehr.
=> Will ein User nicht alle Aktoren einbinden ist das kein Problem - warum auch.
B) Die Architektur
Es gibt also den Entity-Interface Layer welcher HMCCUCHN oder DEV ist. Hier werden die Entity Daten (Readings jeder Art) dargestellt und die Komamndos an die Entity geschickt.
Das Interface hierzu "nach oben" sollte möglichst einheitlich zu bestehenden sein.
=> Eine Entity wird also nur einmal definiert
=> die Darstellung/akkumulation/konsolidierung von Werten (Readings) in gesonderten Module (bereits sehr erfolgreich) angeboten
Die CCU ist demnach also für FHEM ein IO-Device. Nicht mehr. Jedes IO hat seine Eigenheiten, genau wie jede Kommunikation. Bei der CCU kann hat man caches mit welchen man umgehen muss. Es können virtuelle Devices erstellt werden, alles kein Problem.
ZitatWenn der Nutzer für diesen Kanal ein HMCCUCHN Device definieren möchte, hat er 2 Möglichkeiten:
er braucht nur eine. Kein added value zu sehen - nur andere Methoden welche bei dir am Ende des Tagen komplexe Suchen und LUTs notwendig machen.
ZitatLeider lässt FHEM nicht den gleichen "Zeichenraum" für Devicenames zu wie die CCU. Man kann die Namen also nicht einfach 1:1 übernehmen.
Sollte für dich kein wirkliches Problem sein - oder? Ich habe aus dem Stand 2-3 Ideen, das zu lösen.
ZitatP.S.P.S. Auch folgendes ist mit HMCCUCHN möglich, wenn auch nicht häufig genutzt (2xHMCCUCHN für den gleichen Kanal):
Ist ja auch nicht sinnvoll.
Also nichts für ungut. Das ist meine Meinung, mein Verständniss von FHEM. Und bei Architektur, Konformotät und Layering sehe ich wenig bis keinen Spielraum für Abweichungen.
Ich wünsche mir eine geradlinige, einfachen Abstraktion der Entites in FHEM ohne jegliche Sonderwege (welche sonst auch keiner braucht).
Die kommandos hören sich schon einmal hervorragend an.
Mal sehen, ob ich heute zum testen komme :)
So nebenbei: dass ich in der ccu die interfaces auswählen muss, welche genutzt werden ist unnötig. Das attribut sollte stillgelegt werden. Offensichtlich ermittelst du sowieso, welchen IF bedient werden kann. User interaktion ist unnötig.
Zitat
Werte über die ReGa Schnittstelle mit Homematic Script gelesen. Diese Methode benötigt nur 1 CCU-Request, während "get values" einen Request je Kanal braucht.
Super. Was auch immer effizient ist, einfach und robust.
Zitat von: martinp876 am 01 Februar 2020, 09:02:30
Nun, ich stimme nicht zu, bei den Grundsätzen. Namen sind besser - daher vergibt man auch "NAME". Mehr ist nicht notwendig. Das ist FHEM Standart, alles andere nicht.
Einzelne Geräte zu definieren ist jederzeit möglich - auch ohne Sonderwege.Ich verstehe den Inhalt der Aussage nicht. Adressen sind für den User indiskutabel. NAME ist sein zugang.
....
Also nichts für ungut. Das ist meine Meinung, mein Verständniss von FHEM. Und bei Architektur, Konformotät und Layering sehe ich wenig bis keinen Spielraum für Abweichungen.
Ich wünsche mir eine geradlinige, einfachen Abstraktion der Entites in FHEM ohne jegliche Sonderwege (welche sonst auch keiner braucht).
Ich glaube, wir meinen das gleiche. Am besten Du schaust Dir die Module an, testest sie und sagst mir, was Du konkret gerne anders hättest. Die Missverständnisse entstehen vermutlich auch dadurch, dass ich nicht immer in "FHEM-Begriffen" spreche bzw. schreibe.
Speziell nochmal zum Thema NAME vs. Name: Auch hier meinen wir vermutlich das gleiche. Klar wird's so:
define NAME HMCCUCHN CCU-Name
Das ist auch schon alles, was ich damit sagen wollte. Es gibt den FHEM-NAME (den ich natürlich nicht in Frage stelle) und es gibt den CCU-Name. Die ganze Diskussion ist ja daraus entstanden, dass Du mal vorgeschlagen hast, ich solle den Lookup Adresse auf FHEM-Name über sie Gerätedefinition machen. Und ich wollte einfach nur darauf hinweisen, dass das nicht geht, da der Nutzer statt der CCU-Adresse auch den CCU-Namen angeben kann.
Zum Thema eindeutige Entities: Inszwischen hatte ich eine kleine Umfrage gestartet. Keiner scheint mehrere FHEM-Devices je CCU DEvice anzulegen. Das "Feature" ist also spätestens mit dem nächsten Update Geschichte und damit alles wieder schön FHEM-Standard konform.
Da habe ich mich sicher unklar ausgedrückt.
Der Name der entity in der ccu, welcher auf Kanalbasis vergeben wird ist der ccu-name. Für fhem ist es nur ein reading oder internal. Nicht von Bedeutung, nur informativ. Einzige Nutzung ist bei der automatischen Definition. Hier konnte man es als default namen nutzen.
Der NAME in fhem ist, wenn wir uns aus Sicht fhem unterhalten, der Name der entity. Dieser wird in fhem genutzt um entities anzusprechen.
Die DEF, also definition, sollte eine ein- eindeutige Identifikation der entity sein. Unveränderlich. Da bietet sich die addresse wie nichts anderes an. Drängt sich auf. Für mich alternativlos.
Ich habe es nicht mehr komplett im Kopf. ich wollte das rpc interface umbenennen. Dabei wird in fhem das internal NAME geändert. Es wurde aber ein alias eingetragen. Das wollte ich nicht. Sonst hätte ich einen alias gesetzt. Das ist ein Beispiel einer nicht Konformität. M.e. unnötig. Man kann es wie alle anderen auch machen.
Ich habe einmal getestet. Dass ich die dinge anspreche bei welchen ich handlungbedarf sehe ist hoffenlich klar.
Das was schon gut geht sehe ich - danke dafür!
get config:
1) Die Kanalnummer in den Readings muss eliminiert werden. Wir sind Kontext-sensitiv / Objekt orentiert.
Ich weiss also, dass ich Kanal 1 nutze bzw will es nicht wissen. Ich sehe das "kellerlicht". Das macht auch Probleme beim systematischen Auslesen der Readings.
Maximal kann man es mit einer einzigen einstellung in HMCCU direkt umschalten.
2) Die LINK Reading sind ohne Angabe des Peers sinnlos. Das Reading zu Links braucht zwingend die Angabe des Peers. Hier muss demnach auch ein Reading-name welcher den Peer beinhaltet gewählt werden. Anders geht es nicht
3) das Internal "receiver" kann entfernt werden wenn der Kanal kein Receiver ist. Und Umgekehrt
4) Die Liste "sender" in Internals ist sehr hilfreich. Allerdings sollten die " #[OK]" entfernt werden. Eigentlich auch die [SENDER_BROKEN], aber da lasse ich mit mir reden.
Wenn das bei OK entfernt wird kann ich drauf clicken und den Peer betrachten.
5) im Rahmen der Objektorientierung sollte die Device Readings nicht im Kanal dargestellt werden. Das erweckt den Eindruck, dass diese nur für den Kanal eingestellt werden, as falsch ist.
6) Optimierung: Die Basis stimmt also schon. Allerdings hatte ich das identische Problem mit den Registern auch in CUL_HM (logisch, ist identisch). Mein Weg ist, die Anzeige der Readings zu schalten. Die Readings sind als immer vorhanden - je nach sichtbarkeit benenne ich sie um (Rudi war nicht bereit, ein Visiblity-flag einzuführen und hat die Unix-übliche "." variante als einzige Option zugelassen).
Implementiert habe ich das Attribut "expert" welchem ich am ende eine binär-kodierte Zahl hinterlegt habe. Muss der User natürlich nicht verstehen, es gibt vordefinierte settings. Ich extrahiere die Zahl am Begin des Strings und habe einen erklärenden Text nachfolgend. Ich unterscheide "wichtige" register, "alle" register, "raw" (kennt CCU nicht) und Template (muss HMCCU noch kennenlernen!) Hier könnte ich mir vorstellen:
expert 0_off
expert 1_defaultlReg
expert 2_allReg
expert 4_Template
expert 5_Template&defaultReg
expert 255_anything
Da steckt dann etwas arbeit drin. Du musst sämtliche betroffenen Readings von ".LONG_OFF_LEVEL" nach "LONG_OFF_LEVEL" umbenennen und zurück.
Weiter habe ich ein get Kommando im Angbot, welches die Abfrage einzelner Registerwerte erlaubt - oder das ganze als Tabelle.
Ersteres ist für weiterführene Module welche irgendetwas abfragen und Einstellen wollen
zweitere ist für Anwender welche ein Ansprechende Darstellung "in einem Fenster" haben wollen welche sie dann bspw mit einem Text-editor oder excel zwecks vergleich darstellen wollen.
get values:
1) Frage: was ist der Unterschied für den Anwender get update/values? Sind die Werte 'gleichwertig'? Ist das caching unterschiedlich? Wenn ja müssen wir dies internsiv betrachten. Wenn kein solltes du immer das gleiche Interface nutzen
2) Kanal 0 will ich im CHN immer noch nicht sehen. Ein Akkumulierter Status des kanal 0 ist notwendig (Protokol / error), alle Readings pauschal definitiv nicht.
3) Da es sich um einen Update handelt ist eine Anzeige im Resonse-Fenster eher hinderlich.
get update:
1) siehe oben. Warum 2 Kommandos? Was ist der added value?
get deviceDesc:
1) das Device gefällt mir hier nicht. Es zeigt mir nicht, was hier eingestellt werden kann. Mögliche Lösung sind 2 Kommandos. a) get deviceDesc und b) get desc.
get paramsetDesc:
1) hier brauche ich nur die Entity. Wenn ich das Device ändern will sollte ich auch das Device (also CHN_0) öffnen. Das ist bei Kontext-bezogenen Darstellungen so. Damit ist auch klarer, dass es alle Untergeordneten Kanäle betrifft.
2) die enums werden nicht dargestellt. Es macht keinen Sinn, anstelle der Enums die Werte anzuzeigen.
LONG_ACTION_TYPE: ENUM [R,W] [Visible,Sticky] RANGE=0-3 DFLT=1 UNIT=
Mit 0-3 kann keiner etwas anfangen.
3) Aufgrund der Anzahl der Parameter sollte man konsolidieren.
3a) Long/short sind immer identisch mit Ausnahme von Multiexec. Es reicht also diesen Satz einmal anzuzeigen
3b) die Angaben zu Wochenlisten sind entlos lang. Das muss zusammengefasst weren
4) (optional) UNIT könnte weggelassen werden, wenn es leer ist.
Default ... hm. brauche ich nicht. Ich werden immer die Werte lesen, will ich wissen, was eingestellt ist. Aber es wird sicher jemanden interessieren, auch wennn er nichts damit anfangen kann.
5) Range sollte man nicht 0-8 darstellen sondern 0...8. Hat den Vorteil dass ggf auch -5...-1 sauber dargestellt werden kann.
Beispiel: -2147483648-2147483647 ist zumindest unschön. -2147483648...2147483647
Aber eingentlich sollte man es als Min/Max darstellen. Die einzelnen Parameter wird man intern abfragen müssen, wenn man die Eingabe der Datenpunkte unterstützt.
Zu dem, was ich mir bei einer kompakten Registertabelle vorstelle hier ein Beispiel eines Rollos in meinem System.
Natürlich sind die Adressen durch Namen zu ersetzen. Es sind nicht alle Devices in der CCU angelernt - ich betreibe es parallel zu CUL_HM. Geht übrigens prima...
Ich denke die Menge der Daten macht deutlich, dass man diese nicht einfach in Readings plumbsen lassen kann. Es Bedarf einer Darstellung.
Auch das Aufräumen MUSS das Modul automatisch übernehmen. Bspw wenn man ein peering entfernt sind mit unter Duzende Register zu entfernen. Muss das System automatisch machen - geht nicht anders.
Natürlich sind Master und Link (Alles mit "ls") "Config" Daten und value "Operational".
So langsam will ich dann auch einmal bedienen. Nun habe ich so einen Steckdosenschalten. Da bekomme ich kein "on" Kommando. Allerdings ein on-for-timer. Das allerdings funktioniert nicht.
Diese Kommandos sollten automatisch generiert werden. Wenn ein Kanal ein Level Bool hat ist sind Kommandos "on/off/toggle" ohne Parameter schon einmal gesetzt. On-For-Timer muss ich noch einmal prüfen. Evlt geht dies nicht immer.... Die Messages sollten alle aber definiert und abrufbar sein. Daraus sollte sich viele Kommandos automatisch erstellen lassen.
*** HMc_raEss_1 addr:JEQ0116737 chn:1
AES_ACTIVE : 0
CHTyp : BLIND
peerlist:@1743BF:2,@182083:10,@182083:9,HMc_raEss_1,JEQ0116737:2,HMc_fW_19,HMc_fW_20
@1743BF:2: UI_HINT:
@182083:10: UI_HINT:
@182083:9: UI_HINT:
JEQ0116737:1: UI_HINT: 5
JEQ0116737:2: UI_HINT:
MASTER: AES_ACTIVE: false
MASTER: CHANGE_OVER_DELAY: 1.2
MASTER: REFERENCE_RUNNING_TIME_BOTTOM_TOP: 29
MASTER: REFERENCE_RUNNING_TIME_TOP_BOTTOM: 29
MASTER: REFERENCE_RUN_COUNTER: 0
MASTER: STATUSINFO_MINDELAY: 3
MASTER: STATUSINFO_RANDOM: 0
MASTER: TRANSMIT_TRY_MAX: 6
OEQ1978993:19: UI_HINT:
OEQ1978993:20: UI_HINT:
VALUES: DIRECTION: NONE
VALUES: INHIBIT: false
VALUES: LEVEL: 1
VALUES: WORKING: false
Peer: @1743BF:2 long short @182083:10 long short @182083:9 long short JEQ0116737:1 long short JEQ0116737:2 long short OEQ1978993:19 long short OEQ1978993:20 long short
ls: ACTION_TYPE: JUMP_TO_TARGET JUMP_TO_TARGET INACTIVE JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET
ls: COND_VALUE_HI: 100 100 0 100 100 100 100 100 100 100 100 100 100 100
ls: COND_VALUE_LO: 50 50 0 50 50 50 50 50 50 50 50 50 50 50
ls: CT_OFF: VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO
ls: CT_OFFDELAY: VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO
ls: CT_ON: VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO
ls: CT_ONDELAY: VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO
ls: CT_RAMPOFF: X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO
ls: CT_RAMPON: X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO
ls: CT_REFOFF: X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO
ls: CT_REFON: X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO
ls: DRIVING_MODE: DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY
ls: JT_OFF: ON_DELAY RAMP_OFF NOP ON_DELAY RAMP_OFF RAMP_OFF RAMP_OFF RAMP_OFF ON_DELAY ON_DELAY RAMP_OFF ON_DELAY ON_DELAY ON_DELAY
ls: JT_OFFDELAY: ON_DELAY OFF NOP ON_DELAY OFF OFF OFF OFF ON_DELAY ON_DELAY OFF ON_DELAY ON_DELAY ON_DELAY
ls: JT_ON: ON_DELAY RAMP_OFF NOP ON_DELAY RAMP_OFF RAMP_OFF RAMP_OFF RAMP_OFF ON_DELAY ON_DELAY RAMP_OFF ON_DELAY ON_DELAY ON_DELAY
ls: JT_ONDELAY: RAMP_ON RAMP_OFF NOP RAMP_ON RAMP_OFF RAMP_OFF RAMP_OFF RAMP_OFF RAMP_ON RAMP_ON RAMP_OFF RAMP_ON RAMP_ON RAMP_ON
ls: JT_RAMPOFF: 8 8 NO_JUMP_IGNORE_COMMAND 8 8 8 8 8 8 8 8 8
ls: JT_RAMPON: OFFDELAY OFFDELAY NO_JUMP_IGNORE_COMMAND OFFDELAY OFFDELAY OFFDELAY OFFDELAY OFFDELAY ON OFFDELAY OFFDELAY OFFDELAY ON ON
ls: JT_REFOFF: OFF RAMPOFF OFF OFF RAMPOFF RAMPOFF RAMPOFF RAMPOFF OFF OFF RAMPOFF OFF OFF OFF
ls: JT_REFON: RAMPON ON RAMPON RAMPON ON ON ON ON RAMPON RAMPON ON RAMPON RAMPON RAMPON
ls: MAX_TIME_FIRST_DIR: 0.3 0.3 0.5 25.5 0.5 25.5 0.5 25.5 0.5 25.5 25.5 25.5 0.5 25.5
ls: MULTIEXECUTE: OFF OFF ON ON ON OFF ON
ls: OFFDELAY_TIME: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ls: OFF_LEVEL: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ls: OFF_TIME: 111600 111600 0 111600 111600 111600 111600 111600 111600 111600 111600 111600 111600 111600
ls: OFF_TIME_MODE: TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE
ls: ONDELAY_TIME: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ls: ON_LEVEL: 1 1 1 1 1 1 1 1 1 1 1 1 1 1
ls: ON_TIME: 111600 111600 0 111600 111600 111600 111600 111600 111600 111600 111600 111600 111600 111600
ls: ON_TIME_MODE: TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE
p.s.: Im Link ist jede Spalte ein halber registersatz. Also Short/long ist je eine Spalte je peer.
Das ist ein normales Device in einer Konfiguration. Extreme habe ich auch ;)
Das Fehlen von 'on' und 'off' ist ein Bug bzw. da habe ich etwas vergessen. Die Befehle toggle, on-for-timer, level, pst, up, down werden ja bereits automatisch generiert. Insofern ist das eine "kleine" Erweiterung.
Zum Thema formatierte Ausgabe: Momentan haben funktionale Dinge Vorrang (wie eben on/off). Mit den Feinheiten der Bildschirmausgabe beschäftige ich mich danach.
Derzeitiger Fahrplan (Reihenfolge):
- Funktionale Dinge in HMCCUCHN komplettieren
- Automatische Generierung von Befehlen
- Automatisches Erkennen von Einstellungen, die derzeit noch über Attribute gelöst sind
- Angleichung HMCCUDEV and HMCCUCHN
- Sync CCU/FHEM verbessern (RPC-Server Events usw.)
- Bildschirmausgaben
Das dauert halt, da ich immer Randbedingungen im Auge behalten muss:
- CCU unterstützt neben BidCos und HmIP noch mindestens 6 weitere Protokolle (die mir adhoc einfallen). Die entsprechenden Geräte muss ich entweder rausfiltern oder unterstützen
- Nicht alle CCU Protokolle bieten eine vollwertige RPC-Schnittstelle an
- Manche CCU RPC-Schnittstellen sind binär (kein XML/ASCII). Dafür gibt es keine Standard. Entsprechend implementiert das jeder anders.
- Es gibt User, die mehrere CCUs haben. HMCU unterstützt das zwar, jedoch muss ich aufpassen, dass ich da nichts kaputt mache
- Einige CCU Schnittstellen sind sehr fragil oder sind einfach buggy. Gerade mit CCU2 gibt es immer wieder Performance Engpässe.
- Ich darf keine undokumentierten "Spezialitäten" verwenden. Sowas rächt sich immer, spätestens wenn EQ-3 etwas verändert. Manchmal geht es nicht ohne (Abfrage der CCU Schnittstellen).
- ...
Ich werde im Laufe der Woche hier immer mal wieder eine Antwort einfügen. Mit Tests oder direkten Kommentaren bitte bis Freitag warten, da die aktuelle Version im SVN die hier dokumentierten Änderungen noch nicht enthält.
- In Rot Dinge, die ich anders sehe bzw. wo es noch Diskussionsbedarf gibt
- In Blau Dinge, die ich so umsetze oder bereits umgesetzt habe
Zitat von: martinp876 am 02 Februar 2020, 14:25:56
get config:
1) Die Kanalnummer in den Readings muss eliminiert werden. Wir sind Kontext-sensitiv / Objekt orentiert.
Ich weiss also, dass ich Kanal 1 nutze bzw will es nicht wissen. Ich sehe das "kellerlicht". Das macht auch Probleme beim systematischen Auslesen der Readings.
Maximal kann man es mit einer einzigen einstellung in HMCCU direkt umschalten.
Bei Device vom Typ HMCCUCHN haben die Readings per Default nun keine Kanalnummern mehr (gilt für alle Befehle, die Readings erzeugen oder aktualisieren).
Zitat
2) Die LINK Reading sind ohne Angabe des Peers sinnlos. Das Reading zu Links braucht zwingend die Angabe des Peers. Hier muss demnach auch ein Reading-name welcher den Peer beinhaltet gewählt werden. Anders geht es nicht
Das sind Link
unabhängige Parameter aus dem Parameter Set LINK. Diese können auch dann gelesen und gesetzt werden, wenn gar keine Verknüpfung vorhanden ist.
Beispiel für einen Fensterkontakt (Kanal 1):
Paramset LINK
EXPECT_AES: BOOL [R,W] [Visible,Sticky] RANGE=0-1 DFLT=0 UNIT=
PEER_NEEDS_BURST: BOOL [R,W] [Visible,Sticky] RANGE=0-1 DFLT=0 UNIT=Ich gehe davon aus, dass diese Parameter relevant sein können, sobald man eine Verknüpfung einrichtet. Insofern macht es für mich Sinn, solche - bezogen auf einen Kanal - globalen Link Einstellungen zuzulassen und auch anzuzeigen.
Zitat
3) das Internal "receiver" kann entfernt werden wenn der Kanal kein Receiver ist. Und Umgekehrt
Du meinst, wenn in der Device Description keine LINK_SOURCE_ROLE oder keine LINK_TARGET_ROLE definiert ist? Warum gibt es dann für Kanäle, bei denen eine der Rollen fehlt, trotzdem Link-Einträge? Sind das dann Geräte interne Verknüpfungen (gibt es)?
Zitat
4) Die Liste "sender" in Internals ist sehr hilfreich. Allerdings sollten die " #[OK]" entfernt werden. Eigentlich auch die [SENDER_BROKEN], aber da lasse ich mit mir reden.
Wenn das bei OK entfernt wird kann ich drauf clicken und den Peer betrachten.
Die OKs sind raus. Letztlich interessiert sowieso nur, ob ein Link "broken" ist. Dementsprechend werden nur noch Fehlerstati angezeigt.
Zitat
5) im Rahmen der Objektorientierung sollte die Device Readings nicht im Kanal dargestellt werden. Das erweckt den Eindruck, dass diese nur für den Kanal eingestellt werden, as falsch ist.
Die sind jetzt raus. Die Readings werden so gemappt:
- LOW_BAT und LOWBAT auf "battery"
- UNREACH auf "activity"
- Alle anderen auf "devstate", sofern sie nicht den Status "normal" bzw "ok" haben.
Man kann die Readings aktivieren, indem man im Attribut "ccuflags" das Flag "devState" setzt. Das Flag "noChn0" wird ignoriert (das ist nun der Default).
Zitat
6) Optimierung: Die Basis stimmt also schon. Allerdings hatte ich das identische Problem mit den Registern auch in CUL_HM (logisch, ist identisch). Mein Weg ist, die Anzeige der Readings zu schalten. Die Readings sind als immer vorhanden - je nach sichtbarkeit benenne ich sie um (Rudi war nicht bereit, ein Visiblity-flag einzuführen und hat die Unix-übliche "." variante als einzige Option zugelassen).
Implementiert habe ich das Attribut "expert" welchem ich am ende eine binär-kodierte Zahl hinterlegt habe. Muss der User natürlich nicht verstehen, es gibt vordefinierte settings. Ich extrahiere die Zahl am Begin des Strings und habe einen erklärenden Text nachfolgend. Ich unterscheide "wichtige" register, "alle" register, "raw" (kennt CCU nicht) und Template (muss HMCCU noch kennenlernen!) Hier könnte ich mir vorstellen:
expert 0_off
expert 1_defaultlReg
expert 2_allReg
expert 4_Template
expert 5_Template&defaultReg
expert 255_anything
Da steckt dann etwas arbeit drin. Du musst sämtliche betroffenen Readings von ".LONG_OFF_LEVEL" nach "LONG_OFF_LEVEL" umbenennen und zurück.
Weiter habe ich ein get Kommando im Angbot, welches die Abfrage einzelner Registerwerte erlaubt - oder das ganze als Tabelle.
Ersteres ist für weiterführene Module welche irgendetwas abfragen und Einstellen wollen
zweitere ist für Anwender welche ein Ansprechende Darstellung "in einem Fenster" haben wollen welche sie dann bspw mit einem Text-editor oder excel zwecks vergleich darstellen wollen.
Zitat
get values:
1) Frage: was ist der Unterschied für den Anwender get update/values? Sind die Werte 'gleichwertig'? Ist das caching unterschiedlich? Wenn ja müssen wir dies internsiv betrachten. Wenn kein solltes du immer das gleiche Interface nutzen
2) Kanal 0 will ich im CHN immer noch nicht sehen. Ein Akkumulierter Status des kanal 0 ist notwendig (Protokol / error), alle Readings pauschal definitiv nicht.
3) Da es sich um einen Update handelt ist eine Anzeige im Resonse-Fenster eher hinderlich.
1) hatte ich schonmal geschrieben: "get update" nutzt die ReGa Schnittstelle der CCU. Benötigt nur einen Request, beliebig viele Kanäle eines CCU Device abzufragen. "get values" nutzt die RPC Schnittstelle. Hier ist ein Request je Kanal notwendig. Ich bin immer noch unschlüssig, ob ich "get values" behalten will oder nicht.
2) Ist nun so umgesetzt, siehe Kommentar weiter oben.
3) Du hattest ja darauf hingewiesen, dass es FHEM-Standard ist, dass jeder Get-Befehl Werte zurückgeben muss. Daran habe ich mich nun gehalten. Ein bißchen Standard ist nicht.
Zitat
get deviceDesc:
1) das Device gefällt mir hier nicht. Es zeigt mir nicht, was hier eingestellt werden kann. Mögliche Lösung sind 2 Kommandos. a) get deviceDesc und b) get desc.
Im Moment lasse ich es so wie es ist. Es zeigt halt mehr Informationen an, als tatsächlich notwendig. Aber damit kann man erst mal leben.
Zitat
get paramsetDesc:
1) hier brauche ich nur die Entity. Wenn ich das Device ändern will sollte ich auch das Device (also CHN_0) öffnen. Das ist bei Kontext-bezogenen Darstellungen so. Damit ist auch klarer, dass es alle Untergeordneten Kanäle betrifft.
Bitte nenne mir mal die Quelle bei EQ-3, wo beschrieben ist, dass Kanal 0 für das Device steht. Dann werde ich das sofort akzeptieren. Ansonsten gilt: Kanal 0 und das Device haben unterschiedlich Descriptions, verschiedene Parametersets und verschiedene Parameter. Insofern sind sie nicht identisch.
Zitat
2) die enums werden nicht dargestellt. Es macht keinen Sinn, anstelle der Enums die Werte anzuzeigen.
LONG_ACTION_TYPE: ENUM [R,W] [Visible,Sticky] RANGE=0-3 DFLT=1 UNIT=
Mit 0-3 kann keiner etwas anfangen.
Hatte ich vergessen, die ENUM-Werte werden nun angezeigt.
Zitat
3) Aufgrund der Anzahl der Parameter sollte man konsolidieren.
3a) Long/short sind immer identisch mit Ausnahme von Multiexec. Es reicht also diesen Satz einmal anzuzeigen
3b) die Angaben zu Wochenlisten sind entlos lang. Das muss zusammengefasst weren
4) (optional) UNIT könnte weggelassen werden, wenn es leer ist.
Default ... hm. brauche ich nicht. Ich werden immer die Werte lesen, will ich wissen, was eingestellt ist. Aber es wird sicher jemanden interessieren, auch wennn er nichts damit anfangen kann.
Um die Konsolidierung der Ausgabe kümmere ich mich, wenn die funktionalen Themen umgesetzt sind. Das ist alles nur Info, für viele Nutzer eher zweitrangig.
Zitat
5) Range sollte man nicht 0-8 darstellen sondern 0...8. Hat den Vorteil dass ggf auch -5...-1 sauber dargestellt werden kann.
Beispiel: -2147483648-2147483647 ist zumindest unschön. -2147483648...2147483647
Aber eingentlich sollte man es als Min/Max darstellen. Die einzelnen Parameter wird man intern abfragen müssen, wenn man die Eingabe der Datenpunkte unterstützt.
Wird jetzt als Min ... Max dargestellt.
Die prio hört sich sinnvoll an!
Peerneedsburst ist ein linkspezifischer parameter. Ebenso wie expectaes. Das liegt bei sendern in der Liste 4. Der sensor sender MUSS als Initiator wissen, ob der Empfänger uber burst geweckt werden muss. Ähnliches gilt für aes. Ich setze es in alles peerings sorgfältig, prüfe es im system check kommando und setze es automatisch beim peeren.Das ist alles für eine peer<>peer beziehung benötigt. Sonst für nichts.
Ich bin mir hier mehr sicher. Ich habe es schon oft und intensiv genutzt. Diese register kenne ich persönlich ;)
Zu receiver: bei ip decives ist offensichtlich der eingebaute button auch als taster und sender nutzbar. Ip habe ich noch nichts gemacht. Kommt wenn wir voranschreiten. Ansonsten ist ip faktisch wie rt. Mit wenigen erweiterungen.
Kanal0. Das ist im web interface so realisiert. Ein kanal 0 sehe ich hier nicht. Das ist zusammengafasst.
Warum sollte man es auch trennen? Es ist IMMER eine 1:1beziehung. Niemand muss den unterschied kennen. Es gibt keine überlappungen. Es kann keine verdopplung des kanal 0 geben. Es also zusammenzufassen entspricht dem ccu interface. Es zu trennen bietet keinerlei komfortgewinn sondern eine reduktion. Es verbaut keine eventuellen funktionalitäten für die Zukunft. Die granularität wird nicht verbessert.
Was spricht für die trennung? Ich sehe nichts ausser dass in einem internen interface eine interne unterschiedliche adresse genutzt wird. Diese sollte weitgehend sowieso unsichtbar sein.
Nur zur Info: ich habe das Update noch nicht eingecheckt.
Nur mal aus Neugier: wie stellst Du Dir die Abbildung der Device Parameter in einem HMCCUCHN Device vor? Ich meine Paramset MASTER.
Sollen die Readings gar nicht dargestellt werden? Oder doch mit einem Kenner davor, der aufs Device hindeutet?
Setzen der Device Parameter dann doch mit einer "device" Option im Befehl?
Und nein, ich verlasse mich keinesfalls darauf, dass es keine Dopplungen bei Parametenamen in Device und Channel gibt.
Ich habe das Update für die Beta mal eingecheckt. Gibt noch das eine oder andere Perl Warning. Aber läuft.
Das Wochenende wird eng bei mir. Unklar ob ich zum Testen komme.
Registerdarstellung. Schwierig. Ich meine in culhm einen flexiblen und sinnvollen weg gefunden zu haben. Ist aber nicht unerheblich arbeit deinerseits.
Mein Vorschlag:
1) register haben immer einen Präfix. Bei mir ist es "R-". Der Anwender sollte/muss/darf wissen, dass es sich um remandnte werte handelt. Ich als admin muss verstanden haben welcher Wert nach einem powerup im device stehen wird
2)link bezogene register haben den Präfix "R-<peername>"-. Hier beginnt schon der erste Arbeitsblock.
2a) bei chn musst du das rename einer peerentity abfangen und die register umbenennen.
2b) nicht vorhandene peers müssen zur Löschung der zugehörigen register führen. D.h. immer wenn du die peerliste eines kanals liest musst du prüfen ob die register der links vollständig sind, wenn nicht holen. Und ob ein peer nicht mehr peer ist, dann die readings löschen.
2c) in der dev Variante musst du dir für den peernamen etwas einfallen lassen. Besonders hässlich ist der Mischbetrieb. Ein grund, warum ich es mir nicht antun würde.
2d) in jedem fall muss ich die peerlists mit den peerreadings sofort und anhand der namen assoziieren können. Und drauf clicken.
3) register sind immer in de readings. Ggf. Sind sie nicht sichtbar. Das reading hat dann den präPräfix ".".
4) der anwender kann den sichtbarkeitslevel über ein attribut steuern. Hierzu habe ich registerklassen festgelegt
A) raw register. Das sind binärwerte welche du glücklicherweise nicht siehst.
B) default register. Hier habe ich ein paar aus gewählt welche ich für wichtiger hielt. Du könntest alle master register des kanals hier einsetzen. Dann brauchst du keine selektionsliste.
C) nondefault regs. Konnten bspw die link register sein.
D) templates.das sind dann frei programmierbare registerabstraktionen. Das wird der eigentliche operator level.
Die sichtbarkeit der einzelnen level lässt sich über einen parameter mit bitmaske einstellen. Der user kann die suchtbarkeit über ein einziges attribut steuern. Je kanal. Sinnvoller default ist notwendig. Evtl in hmccu.
5) einzelne werte sind immer über ein get abfragbar. Für evtl. Nachgelagerte scriptverarbeitung.
6) register einer entity kann man über ein get als Tabelle abfragen. Möglichst kompakt und so, dass man es in ein excel bekommt.
7) temperaturlisten sollte man gesondert behandeln. Das ist eine unmenge an registern. Man kann sie hervorragend zusammenfassen. Das braucht man für ein- sowie Ausgabe. Ich stelle hier das profil eines tages in einem Reading dar. Selbstverständlich nur die relevanten. Wenn der letzte Eintrag rekannt ist werden die letzten verschluckt
Der temperaturlisten heisen R_x_templistSun wobei x =0 für sonntag die Sortierung erstellt. Also 1 für Mon
So, das war glaube ich das wesentliche.
P.s. um hm devices zu verstehen lohnt sich e.m. ein blick in das Einsteiger doc, Kapitel hm. Das habe ich vor jahren verfasst. Das Verständnis zu culhm ist nicht so wichtig für dich. Allerdings funktionieren die hm devices aller serien nach dem prinzip. Nich vom Namen "Einsteiger" abschrecken lassen wie viele, denen es unter der würde ist. Ich enpfehle es jedem, der sicher mit den ddvices umgehen will
Ich denke, ich werde es so realisieren wie von Dir vorgeschlagen:
- Grundsätzlich werden alle Readings aktualisiert und gespeichert
- Readings können mit . ausgeblendet werden
- Ich verwende dafür das schon vorhandene Attribut "ccureadingfilter". Das werde ich noch etwas ausbauen in Richtung verschiedener Sichtbarkeitslevel.
Da ich jetzt schon alle Werte im Hash des FHEM Device speichere, sollte ein nachträgliches Umbauen der Readings auch keine große Sache sein.
Ist nicht schlimm, wenn Du nicht zum Testen kommst, habe ja noch genug zu tun ;)
Mittlerweile sollten folgende Channel-Types weitgehend ohne Extra-Attribute out of the box funkionieren: SWITCH, BLIND, SHUTTER_CONTACT
Bei anderen Typen muss man nach wie vor "statedatapoint", "controldatapoint", "statevals", "substitute" usw. definieren, damit alles funktioniert.
ok, hört sich gut an.
ccuReadingsFilter ist ok. Es sollte eine Option geben, welche mir erlaubt, einen einfachen default Filter zu nutzen.
Bei CULHM schalte ich Register per default aus. Diese werden nur bei gewissen maintenance aktionen temporär eingeschaltet. Templates sind dagegen immer an und zeigen mir die Funtktion abstrakt, lesbar und reproduzierbar an.
Noch ein Scenario zu duplikate entites:
In meiner Welt sind alle Channels instanziiert, jedes einmal. Nun habe ich bspw einen Button Channel mit einem Schalt-Channel gepeert.
Button Addr 11111111:3, name Btn_Wohn_rechts
Schalter Addr 22222222:5, name Licht_Wohn_Decke
In der jeweiligen Entity will ich die Referenz sehen, natürlich als Name und verlinkt. Jeden Peer nur einmal:
Btn_Wohn_rechts:
PeerList: Licht_Wohn_Decke,<otherPeer>,...
R-Licht_Wohn_Decke-PeerNeedsBurst on
R-Licht_Wohn_Decke-AESexpected off
R-<otherPeer>-PeerNeedsBurst off
Licht_Wohn_Decke
PeerList: Btn_Wohn_rechts,<otherPeer4Switch>,...
R-Btn_Wohn_rechts-onTime 100
R-Btn_Wohn_rechts-offTime infinite
R-<otherPeer4Switch>-onTime 1000
So etwas läuft fluffig wenn man eine 1:1 zuordnung von Adresse zu Name hat (FHEM typisch). Wenn du nun einen Kanal mehrfach instanziieren kannst ... was machst du dann? Alle Einträge duplizieren?
Du wirst eine Lösung brauchen. Mit der FHEM tpischen Installation (Adresse =DEF => Name ) gibt es diese Frage garnicht.
Bei HMCCUCHN wird mittlerweile auf existierende Devices geprüft, jeder Channel hat also maximal 1 FHEM Device.
Bei HMCCUDEV muss ich doppelte Definitionen zulassen, v.a. wg. HmIP-Wired. Hier gibt es komplex Mehrfachaktoren, z.B. für FB-Heizungen. Da hast du ein Gerät mit 16 Kanälen, wobei jeweils 4 Kanäle verwendet werden, um einen Heizkreis zu steuern. Durch die Mehrfachdefiniton kann der Nutzer mit gerade mal 4 Devices seine 4 Heizkreise steuern. Alternative wären 16 HMCCUCHN Devices, und das ist nur der kleine FB-Aktor.
Macht die Welt unnötig kompliziert.
Vielleicht führe ich mal sowas wie einen virtuellen Kanal ein, der mehrere physikalische Kanäle zusammenfasst. Ist aber auch nicht trivial, da die Kanäle teilweis identische Datenpunkte haben.
Das solltest du einführen. Allerdings solltest du die wortwahl virtuell tunlichst vermeiden. Der begriff ist schon belegt durch virtuelle kanäle der ccu selbst sowie bspw teamleads.
Was du einführen kannst sind groups, also funktionsgruppen. Diese sind funktional notwendig. Allerdings solltest du zuerst prüfen, was fhem bietet. Reading groups u.ä. wenn es damit abzudecken ist solltest du nichts neues erfinden. Ich kenne hier nicht alle optionen.
Mir würde hier eine allgemeine anwendung gefallen. Bspw habe ich rt und tc gepeert. Das ist also eine gruppe. Hier können es auch mehrere rts sein. Dann können noch fensterkontakte hinzukommen. Dies zusammen ergibt das heizmodul eines zimmers. Alle funktionskanäle des verbunds (funktionsgruppe) werden einbezogen. Automatisch nach auswerten der peerings.
Ein kanal kann in mehreren funktionsgruppen vorkommen. So z.b. der fensterkontakt in der home-security.
Somit könnte man den zwischenschritt der funktionsgruppen eines device gleich überspringen.
Chn:
Wenn du also nur eine instanziierung eines kanals zulässt kannst du gleich die adresse in def festlegen. Dann musst du nichts prüfen. Für mich der Königsweg.
Mischung:
Ein kanal kann nun, so verstehe ich es, in chn und auch (mehrfach) in dev angelegt werden. Bleibt die Frage nach der benamung der peerings weiter offen.
Neue Versionen im Contrib.
Readings
Die Readings eines HMCCUCHN Device werden über die Attribute ccuflags und ccureadingfilter gesteuert. In ccuflags wird das Level festgelegt. Readings für Datenpunkte werden immer angezeigt (also Parameterset VALUES). In ccuflags können folgende Werte gesetzt werden:
showMasterReadings - Zeigt Readings vom Parameterset MASTER an (die Konfigurationsparameter)
showLinkReadings - Zeigt Readings vom Parameterset LINK an (1 Reading je Receiver und Parameter)
showDeviceReadings - Zeigt Readings vom Parameterset VALUES für den Kanal 0 und vom Parameterset MASTER für das Device an
Readings werden grundsätzlich nach den Angaben in ccureadingfilter nochmal gefiltert. Wenn man alle Readings haben möchte, setzt man:
ccuflags = showMasterReadings,showLinkReadings,showDeviceReadings
ccureadingfilter = .*
ccureadingfilter hat den Default .* (alle Werte)
Das Prefix für Readings kann mit dem Attribut ccuReadingPrefix eingestellt werden. Defaults:
R- => MASTER Parameterset (Kanal)
D- => MASTER Parameterset (Device) und VALUES Parameterset (Kanal 0)
L- => LINK Parameterset (Kanal)
Werte im VALUES Parameterset haben kein Prefix.
Wenn Reading bezogene Attribute geändert werden, werden alle Readings automatisch aktualisiert (aus dem Cache in FHEM, nicht aus der CCU).
Es gibt einige Standard-Readings in jedem HMCCUCHN Device:
battery => low, ok oder unknown (keine Batterie)
activity => alive oder dead
devState => Liste von Fehlerzuständen aus Kanal 0 (ohne LOW_BAT und UNREACH, die über battery und activity dargestellt werden)
Set (Auszug)
Mit folgendem Befehl können Link-Parameter gesetzt werden:
set xy link Chn-Receiver Parameter=Value [...]
set xy link Dev-Receiver Channel Parameter=Value [...]
set xy link Parameter=Value [...]
Als Receiver kann man eine Kanaladresse oder den Namen eines HMCCUCHN Device angeben. In der 2. Variante wird der Name eines HMCCUDEV Device und zusätzlich eine Kanalnummer angegeben. Es werden nur existierende Receiver für den aktuellen Kanal akzeptiert.
Bei der 3. Variante werden die angegebenen Parameter für alle existierenden Receiver gesetzt.
Get (Auszug)
get config - Liest die MASTER und LINK Parameter Sets von Kanal und Device (Steuerung der Darstellung über ccuflags / ccureadingfilter)
get values - Liest die VALUES Parameter Sets vom aktuellen Kanal und Kanal 0 ( --- " --- )
get update - Liest alle Parameter Sets (noch nicht implementiert)
Hört sich gut an.
Set xy link parameter
Ist ambitioniert und für anwender gefährlich. Würde ich nie verwenden. Ich würde es nicht anbieten. Du schreibst es dann folglich in alle peer datensätze die du anhand der gecachten peerlists kennst. Ich glaube das kommando macht neben mehr arbeit auch die Fehleranfälligkeit deutlich größer. Der funkverkehr zum device wird auch nicht belastet. Im Gegenteil, bei vielen peers ist es richtig viel. Das setzen von registern ist so das aufwändigste in der Luft.
Short und long sind dediziert als Parameter anzugeben. Passt.
Meine implementierung war (übersetzt)
Set xy param <register> <value> [<peer>]
Das kommando gilt dann für alle register. Peer / link/ master ... egal.
Sollte ein peer notwendig sein muss er angegeben werden, sonst gibt es eine fehlermeldung. Daher steht peer auch am ende er Parameterliste.
Für meinen geschmack eleganter weil 1 Kommando weniger.
DevReceiver Channel ist sicher ein Parameter in der schreibweise welche du in hmccudev generel nutzt.
Du solltest aber nicht von receiver reden. Das konnen auch sender assotiationen sein. Es sind schlicht linked channels. Immer channels > 0. Der begriff peer ist eigentlich eingeführt hierfür.
Die Darstellung der Link parameter ist spannend - wegen der namensgebung und der doppelten instanziierung der peers. Sehe ich hoffentlich heute abend.
Die aktuelle Version crached in Zeile 4482.
Addresse ist ok
channel ist ok
parameterset ist aber der Parameter, nicht das set. Und dann cracht es - FHEM kommt nicht mehr hoch.
ich habe die Funktion einmal abgeklemmt - jetzt bootet das System wieder.
Unklar:
- Das Update der Readings wird extrem verzögert gestartet
- Die Performance ist nicht sehr hoch - mir noch unklar, woran es liegt. Wenn es nicht besser wird werde ich es später betrachten müssen.
Klar:
- Nachdem ich die Readings abgeklemmt habe funktionieren auch die Readings nicht. Ich warte auf den Update.
Kommandos:
- Mein Rollo hat jetzt level und pct als Kommando. Warum doppelt?
- pct sollte einen Slider haben
Den Fehler schaue ich mir gleich an. Einige Nutzer verwenden pct, andere level (bisher hatte ich nur pct). Aber ich bin gerade sowieso dabei, für diese Channel Role spezifischen Befehle eine etwas generischere Lösung zu bauen. Das ist mi mir momentan noch zu statisch. Ziel ist ja weiterhin, dass auch neue Geräte auf dem Markt sofort nutzbar sind, ohne dass ich die Module erst anpassen muss.
Bzgl. der Benennung Link Receiver: Ich verwende die Terminologie von EQ-3, d.h. Kanäle sind Sender/Receiver, wenn sie in der Link-Liste der CCU so benannt sind.
Den Set link Befehl werde ich entschärfen und nur noch den Receiver zulassen. Über die Zusammenlegung mit set config denke ich mal nach. Man könnte ja immer, wenn eine Receiver-Adresse angegeben ist, vom LINK Paramset ausgehen. Bei get gibt es ja auch kein get link.
Update: Dachte eigentlich, das ich mit der RPC Schnittstelle das meiste erschlagen kann. Finde aber immer mehr Punkte, die doch wieder die ReGa / HMScript Schnittstelle erforderlich machen. Aktuell: Verknüpfte CCU Systemvariablen. Die legt die CCU beim Anlernen eines Gerätes an. Sie verhalten sich wie normale Datenpunkte. Davon weiß RPC nichts.
Zum Fehler: Mach bitte nochmal ein Update, bei mir sehen die Zeilen ab 4482 so aus:
# Modify value: scale, format, substitute
$sv = HMCCU_ScaleValue ($clHash, $c, $p, $v, 0);
$fv = HMCCU_FormatReadingValue ($clHash, $sv, $p);
$cv = HMCCU_Substitute ($fv, $clHash, 0, $c, $p, $chnType, $devDesc);
$cv = HMCCU_GetParamValue ($ioHash, $devDesc, $ps, $p, $fv) if ("$fv" eq "$cv");
Das wöchentliche Update der Beta steht unter contrib/HMCCU/FHEM zur Verfügung.
Neu:
Der Befehl "set link" ist in "set config" aufgegangen. Um einen Link-Parameter zu setzen, verwendet man folgende Syntax:
set xy config receiver [channelNumber] Parameter=Value [...]
Der Parameter receiver ist entweder ...
- eine Kanaladresse
- der Name eines FHEM Device vom Typ HMCCUCHN oder HMCCUDEV
- ein CCU Kanalname
Wenn ein HMCCUDEV Device angegeben wird, muss zusätzlich die Nummer des Empfangskanals angegeben werden.
Sonst: Der Befehl "set defaults" kann nun einige Attribute anhand der Kanal-Rolle erkennen und setzen.
Unbedingt alle Module aus dem contrib Verzeichnis installieren, inkl. HMCCUConf.pm
Receiver kann also ein Aktor oder ein Sensor sein. Na gut, es ist eben der peer.
Es gibt links ohne weitere Parameter. Ob es Parameter in Link gibt siehst du in der description.
Wenn keine da sind ist das kommando ungültig. Die Prüfung des Kommandos muss anhand der description erfolgen. Eine Auswahl an Optionen ist die Rückgabe bei Fehler
habe gerade die Version 02.21 eingespielt
2020.02.23 08:08:37.911 1: HMCCURPCPROC: [d_rpc178046BidCos_RF : 13359] RPC server CB2001178064178046 running
2020.02.23 08:08:37.919 1: HMCCU: [HMccu : 13359] All RPC servers running
2020.02.23 08:08:38.076 1: HMCCURPCPROC: [d_rpc178046BidCos_RF : 13359] Scheduled CCU ping every 300 seconds
2020.02.23 08:08:39.032 2: HMCCURPCPROC: [d_rpc178046BidCos_RF : 13365] CB2001178064178046 NewDevice received 226 device and channel specifications
2020.02.23 08:08:39.334 2: HMCCURPCPROC: [d_rpc178046HmIP_RF : 13366] CB2010178064178046 NewDevice received 103 device and channel specifications
Can't use string ("1") as a HASH ref while "strict refs" in use at ./FHEM/88_HMCCU.pm line 4498.
leider nix gefixed. Brauchst du Informationen?
a) Absturz muss verhindert werden - wir brauchen also eine Prüfung
b) muss ich irgend etwas neu einlesen? Habe ich alte Daten welche die Abfrage korumpieren?
ZitatUpdate: Dachte eigentlich, das ich mit der RPC Schnittstelle das meiste erschlagen kann. Finde aber immer mehr Punkte, die doch wieder die ReGa / HMScript Schnittstelle erforderlich machen. Aktuell: Verknüpfte CCU Systemvariablen. Die legt die CCU beim Anlernen eines Gerätes an. Sie verhalten sich wie normale Datenpunkte. Davon weiß RPC nichts.
Deine Erkenntnis erschreckt mich. Das ist doch irgendwie klar gewesen. Ich rate dringend dazu, ein Dokument zu schreiben, welches die Architektur beschreibt und namen definiert. Ebenso die Ziele der Module.
Eine Dokumentation (wird von SW-Schreibern oft ungern gemacht - dauert....) ist aus meiner Erfahrung exterm hilfreich, nciht nur für andere sondern auch für einen selbst, sich eine Architektur darzulegen und diese dann konsequent zu implementieren. Es verhindert, dass man am Ende ein fragiles Kontrukt an SW erstellt hat welches nicht mehr wartbar ist. Professionell wäre man ohne dies sicher schnell am Ende.
Ich mache einmal einen Anfang.
1) Die Device Ebene (nicht mit DEV verwechseln)
- Device: ein externes Gerät welches es zu steuern gilt.
- channel: Funktionseinheit eines Devices
- Channel0: (unser Streitpunkt). Vereinigt daten der internen Device-ebene sowie des Channel 0. Das vereinfacht für den User einiges, da es überflüssig ist, eine weitere ebene (device-register) in einer weiteren Channe-art darzustellen.
- register: Remanente Konfigurationsdaten in einem Channel. Da Die Device-ebene aus User-sicht in Channel0 aufgeht ist diese Definition umfassend.
- values: Status-werte eines kanals
- peers: Links zwischen channels. Das sind immer Punkt-zu-Punkt Verbindungen
- virtuelle Devices: Nachbildungen von devices welche quasi den gleichen Regeln genügen. Hier ist luft zur präzisen definition
=> Diese Ebene lässt sich nahezu zu 100% aus dem RPC-Interface bedienen. Sicher kann man das Gateway auch nutzen, die Informationen zu erhalten, aber eben nur diese ebene. Man sollte die Level nicht mischen
=> DEV und CHN sollte man als Ebenen einführen. DEV ist m.E. nicht notwendig, aber möglich. Mit dieser Aussage im Hinterkopf (dokumentiert) . Unterste ebene ist das IO (HMCCU) auf welcher die Channels (HMCCUCHN) liegen sollten. HMCCUDEV sind dann gruppierungen von Channels. Wer keine Channels sehen möchte könnte diese "invisible" setzen. Damit hättest du eine saubere und eindeutige Struktur. Leider bist du nicht strikt und versuchtst den unsauberen Weg, alles in die HMCCU zu packen und nur noch visualisierungen der Entites in CHN und DEV zu erstellen.
2) CCU-Level
- Die CCU stellt diverse Funktionalität zu Verfügung. Diese spielt sich komplett on top der Device-ebene ab. Daher sollte eine separate Ebene eingeführt werden, welche die Elemente hier darstellt. Das sind nicht nur Variablen sondern auch Scripte.
- Die Ebenen on Top der Devices kann komplett von FHEM abgefrühstückt werden. Allerdings ist dies langsamer und evtl nicht effizient. Will ein Anwender Scripten und Variablen,... aus der CCU nutzen sollte man diese Elemente als neue Typen in FHEM darstellen. Man könnte die Verknüpfungen darstellen (welche channels haben mir dem Script zutun (-indirekt-verlinkungen)
Die Ebene enthält neben Variablen auch Räume, gewerke,...
==> Würdest du dich entscheiden, die Ebenen konsequent zu trennen wäre es ein leichtes die Ebene Device erst einmal abzuschliessen. Du wärst m.E. schon lange fertig und könntest dich der Mehrwert-ebenen widmen.
==> Die bedienung, Konfiguration und überwachung der Device-ebene ist nicht schwer. RPC ist hierfür gedacht und zu 90% hinreichend
==> überdenke noch einmal das Layering deiner SW-Architektur.
Zitat von: martinp876 am 23 Februar 2020, 08:14:19
habe gerade die Version 02.21 eingespielt
2020.02.23 08:08:37.911 1: HMCCURPCPROC: [d_rpc178046BidCos_RF : 13359] RPC server CB2001178064178046 running
2020.02.23 08:08:37.919 1: HMCCU: [HMccu : 13359] All RPC servers running
2020.02.23 08:08:38.076 1: HMCCURPCPROC: [d_rpc178046BidCos_RF : 13359] Scheduled CCU ping every 300 seconds
2020.02.23 08:08:39.032 2: HMCCURPCPROC: [d_rpc178046BidCos_RF : 13365] CB2001178064178046 NewDevice received 226 device and channel specifications
2020.02.23 08:08:39.334 2: HMCCURPCPROC: [d_rpc178046HmIP_RF : 13366] CB2010178064178046 NewDevice received 103 device and channel specifications
Can't use string ("1") as a HASH ref while "strict refs" in use at ./FHEM/88_HMCCU.pm line 4498.
leider nix gefixed. Brauchst du Informationen?
a) Absturz muss verhindert werden - wir brauchen also eine Prüfung
b) muss ich irgend etwas neu einlesen? Habe ich alte Daten welche die Abfrage korumpieren?
Version 02.21 bezieht sich jetzt worauf ??
Die fragliche Zeile sieht im aktuellen Modul 88_HMCCU.pm so aus:
4497: # Store raw value in client device hash
4498: HMCCU_UpdateInternalValues ($clHash, $chKey, $ps, 'VAL', $v);
Die Fehlermeldung passt irgendwie nicht dazu.
Zitat
Es gibt links ohne weitere Parameter. Ob es Parameter in Link gibt siehst du in der description.
Wenn keine da sind ist das kommando ungültig. Die Prüfung des Kommandos muss anhand der description erfolgen. Eine Auswahl an Optionen ist die Rückgabe bei Fehler
Ich gehe davon aus, dass ein Link ohne Parameter auch kein Parameterset LINK besitzt. Das wird abgefragt und entsprechend eine Fehlermeldung ausgegeben. Die Parameter selbst werden tatsächlich noch nicht auf Gültigkeit geprüft.
Zu Dokumentation / Architektur / Channel vs. Device:ich denke, dass HMCCUCHN mittlerweile Deiner Vorstellung entspricht, abgesehen vom leidigen 'device' Parameter. Letzteren kann man gerne ignorieren und stattdessen zusätzlich noch ein HMCCUDEV Device definieren, wenn man auf Device Parameter zugreifen möchte.
Wenn man alles architektonisch sauber aufsetzen wollte, müsste man ein mehrstufiges FHEM Client / Master Modell verwenden:
HMCCU >istMasterFür> HMCCURPCPROC >IstMasterFür> HMCCUDEV >IstMasterFür> HMCCUCHN
Darüber hatte ich ganz am Anfang mal nachgedacht, es dann aber aufgrund der Komplexität verworfen (eigentlich ist das FHEM Modell nur für eine (1 Ebene) Client-Master Beziehung gedacht).
Herausgekommen ist dann eben sowas:
HMCCURPCPROC <IstMasterFür< HMCCU >IstMasterFür> HMCCUCHN,HMCCUDEV
HMCCU ist der zentrale Vermittler, der alle Interfaces kennt.
Das ist aber immer noch um Längen strukturierter als die sonst üblichen, monolithischen Module in FHEM.
Für Dokumentation ist das Wiki der richtige Platz. Da gibt es auch schon einige Seiten.
Ein weiteres Update:
Die Definition von HMCCUCHN Devices ist nun komfortabler. Man definiert wie gehabt das Device, z.B. einen Wandthermostaten (in Kanal 2 liegen die Datenpunkte für die Steuerung): Hier hat der Kanal 2 in der CCU den Namen Thermostat-2
define myTH HMCCUCHN Thermostat-2
Schon bei der Definition werden die Readings aktualisiert. Danach führt man einmal "set defaults" aus:
set myTH defaults
Anhand der Kanalrolle setzt HMCCUCHN nun alle notwendigen Attribute und definiert Buttons, Slider etc.
Der 2. Schritt wird demnächst überflüssig.
mein Fehler - ich habe ein paar Zeilen eingebaut (nicht problematisch!) Das erzeugt die Verschiebung.
Hier die Referenz:
foreach my $c (keys %{$objects->{$a}}) {
next if (($clType eq 'HMCCUCHN' && "$c" ne "$chnNo" && "$c" ne "0" && "$c" ne "d"));
my $chnAddr = "$a:$c";
my $devDesc = HMCCU_GetDeviceDesc ($ioHash, $chnAddr, $clHash->{ccuif});
my $chnType = defined($devDesc) ? $devDesc->{TYPE} : HMCCU_GetChannelRole ($clHash, $c);
# Loop over all parameter sets
foreach my $ps (keys %{$objects->{$a}{$c}}) {
# Loop over all parameters
next; ##<<< Eigeneinbau - bricht ab damit das System bootet
foreach my $p (keys %{$objects->{$a}{$c}{$ps}}) {##<<< Zeile 4498!!!!
my $v = $objects->{$a}{$c}{$ps}{$p};
02.21: 21.februar
ZitatIch gehe davon aus, dass ein Link ohne Parameter auch kein Parameterset LINK besitzt.
klar. Ich wollte sagen, es gibt Links(peers) ohne Parameter-sätze.
ZitatDie Parameter selbst werden tatsächlich noch nicht auf Gültigkeit geprüft.
Ist ja auch nicht das Erste - wird aber sicher noch kommen :)
ZitatHMCCU >istMasterFür> HMCCURPCPROC >IstMasterFür> HMCCUDEV >IstMasterFür> HMCCUCHN
ein(nicht mein) Ansatz.
ZitatHMCCU ist der zentrale Vermittler, der alle Interfaces kennt.
Das ist nur ein Teil seiner Aufgaben.
HMCCU hat einige Aufgaben. Somit ist die HMCCU ggf nur Cache.
1) RPC-PROC ist ein Interface zur HMCCU. Mehr nicht - sollte man bestmöglich verbergen.
2) HMCCU ist ein IO für die Devices. (channel/device bitte definieren)
==> ab hier könnte man sich entkopplen - oder auch nicht.
3) HMCCU stellt Variablen und Scripten zu verfügung. Das ist ein ganz anderer Level. Diesen würde ich in jeden Fall einer eigenen Intanz zuordnen. Einer Instanzgruppe
3a) sollten Scripten/Variablen der CCU verwaltet werden
3b) falls dem so ist müssen Querverbindungen dargestellt werden
3c) unklar, welchen Level der Scripten man darstellen will/kann. Hier kenne ich mic nicht aus.
=> in jedem Fall ist das eine eigene Gruppe von Entities.
ZitatEin weiteres Update:
hört sich gut an - super-cool sogar. Allerdings kann ich nicht testen da mein System abstürzt an der betreffenden Zeile.
Zitat von: martinp876 am 23 Februar 2020, 19:13:19
mein Fehler - ich habe ein paar Zeilen eingebaut (nicht problematisch!) Das erzeugt die Verschiebung.
Hier die Referenz:
foreach my $c (keys %{$objects->{$a}}) {
next if (($clType eq 'HMCCUCHN' && "$c" ne "$chnNo" && "$c" ne "0" && "$c" ne "d"));
my $chnAddr = "$a:$c";
my $devDesc = HMCCU_GetDeviceDesc ($ioHash, $chnAddr, $clHash->{ccuif});
my $chnType = defined($devDesc) ? $devDesc->{TYPE} : HMCCU_GetChannelRole ($clHash, $c);
# Loop over all parameter sets
foreach my $ps (keys %{$objects->{$a}{$c}}) {
# Loop over all parameters
next; ##<<< Eigeneinbau - bricht ab damit das System bootet
foreach my $p (keys %{$objects->{$a}{$c}{$ps}}) {##<<< Zeile 4498!!!!
my $v = $objects->{$a}{$c}{$ps}{$p};
Mein liebster Perl-Fehler. Wann tritt der Fehler auf? Nach dem Start der RPC Server? Wenn ja, dann vermutlich bei der Aktualisierung aller Devices. Das kannst Du verhindern, indem Du im I/O Device im Attribut ccuflags das Flag noInitialUpdate setzen.
Kannst Du bitte Deinen Eigenbau durch folgende Zeilen ersetzen:
if (ref($objects->{$a}{$c}{$ps}) ne 'HASH') {
HMCCU_Log ($clHash, 2, "a=$a, c=$c, ps=$ps");
}
next;
Zur Erklärung: Diese Funktion aktualisiert Readings. Der Hash $objects enthält die zu aktualisierenden Werte:
$objects->{deviceAdresse}{Kanalnummer}{ParameterSet}{ParameterName} = Wert
Falls der Code oben keinen Hinweis auf die Ursache liefert, hilft nur Data::Dumper.
Werde ich machen. Geloggt hatte ich schon vor 2 Wochen. Die grundsätzliche funktion ist sowieso klar :)
Der workaround hört sich mies an. Die datenstruktur ist korrupt. Fragt fich ob ich alte daten habe bzw diese beim aufstarten nicht korrekt in object abgebildet werden,....
Eigentlich speichert fhem alle readings in readings. Du hast hier wieder einmal einen eigenen Mechanismus.... Eine eigene welt neben fhem.... Hm... Aber das ist wohl deine komplette struktur.
Faktisch hat die ebene ps gefehlt. Das reading war bereits in ps anstelle von p. Die ps ebene fehlt komplett bei mir
Ich habe nochmal ein Update eingestellt. Bitte stelle sicher, dass Du alle 4 Module aktualisierst und FHEM neu startest.
In der problematischen Funktion wird nun ein Stacktrace mitgeloggt, falls eine Ebene im Hash fehlt. Dann kann ich sehen, in welcher Funktion die Datenstruktur falsch zusammengebaut wird.
Wenn bei Dir die Paramset Ebene komplett fehlt, vermute ich, Du benutzt bei einem der Module eine alte Version.
Ich kopiere nach so einem Update immer alle deine files in das System und mache einen reboot. Alles andere wäre nicht reproduzierbar.
Jetzt jendenfalls klappt es. :)
Mal sehen
1) get config
a) alle peers scheinen vorhanden - ok
- peerNamen sind noch nicht enthalten - es sind die Adressen.
b) Reihenfolge: Master würde ich zuerst ausgeben (bessere Lesbarkeit)
c) eine Liste der Peers sollte vor den Links stehen (Lesbarkeit)
d) optional: eine andere Darstellungsform wäre eine Tabelle in der die Links in Spalten ausgegeben werden, Register in Zeilen. Geschmackssache!( mein klarer Favorit)
2) get datapoint
- wenn kein Datenpunkt vorhanden ist sollte das Kommando nicht verfügbar sein.
- alles prima!
3) get defaults
- mir noch unklar, was hier bestehen bleiben wird.
4) deviceDesc
a) Namen: es ist die Entity description. Device ist ... eben der device-level
b) Namen... fehlen. Das JEQ0116737:1 ist bei mir ein HMc_raEss_1. Ich denke der 1. Eintrag sollte der Namen sein?
Channel JEQ0116737:1 HM-LC-Bl1PBU-FM JEQ0116737:1 [BLIND]
c) Unnötige Einträge sollten unterdrückt werden. Parent wird genau in dieser Maske ausgegeen - und in der Überschrift...
- PARENT: JEQ0116737
- PARENT_TYPE: HM-LC-Bl1PBU-FM
- Devicetyp im channel ist sowieso im Device enthalten
=> einfach einmal ansehen, was schlicht klar oder doppelt (3-fach,...) ist
=> make the information smart - es sind immer die gleichen Einträge, also nicht device/channel individuell
5) deviceInfo
a) wie überall auch hier channel 0 - nicht notwendig (unser streitpunkt)
b) in jeder Zeile steht "BidCos-RF.JEQ0116737". Das kann man weglassen, steht schon in der Überschrift
c) hier werden noch alle Kanäle angezeigt
6) paramsetDesc
a) es sollte ein Trenner vorhanden sein, damit man diese Liste nach Excel kopieren kann. Space ist schon einmal drin. Aber das kommt auch in den Literals vor. Schwierig... Evlt mit Tab als trenner arbeiten
die Liste ist so schwer handelbar... wenn man sich eine Übersicht bauen will.
b) DFLT ist nicht bei Liternals als Nummer nicht lesebar - keiner weiss was "8" ist. Ist DFLT dann sinnvoll?
c) UNIT ist nicht immer vorhanden. Schlecht für die Erstellung einer Tabelle.
Die Set kommandos sehen schon gut aus. Allerdings verstehe ich noch nicht alle, muss ich mir einmal zeit nehmen.
Bei 'pct' sollte immer einen Slider haben. Es ist notwendig auch ein Reading "pct" zu erstellen (auch wenn dopplet) - das braucht FHEM um den Slider zu 'Füllen'
Schon einmal super!!
Habe mal in die Attribute geschaut. Flag showlinkreadings passt vom namen nicht.
Klare wortwahl konsequent durchziehen so lange du noch kannst.
Das schow sind sicher register oder config. Also immer wenn du config meinst schreibe config. Oder register - geht m.e. synonym. Register ist ein oder mehrere werte. Config ist die Gesamtzeit der register ( mein Vorschlag)
Readings.... Nicht mit values verwechsel. Datapoint sind die Zustands werte welche du über values erhältst...!?
Masterreadings geht also nicht. Könnten alle values der masterebene sein.
Ziel sollte es sein: hat man die semantik der Begriffe erfasst kann man den befehl oder das attribut ohne docu nutze und deuten. Selbst nach dem lesen ist es schnell vergessen.
Ist kleinkarriert. Aber die schlamperei zu beginn ist extrem schwer nach einführung auszubügeln. Es lohnt sich.
Ich fange einmal an, mit einem RT-IP operational zu werden.
get deviceDesc ist m.E. zu ausgibig. Schon durch die Anzahl der Kanäle wird das Fenster zu breit und unbedienbar. dabei ist die Info auch noch redundant (und sowieso ständig in den Internals.
Also mein Vorschlag
Device 000A18A996E9DA HmIP-eTRV-2 000A18A996E9DA [HmIP-eTRV-2]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 000A18A996E9DA:0,000A18A996E9DA:1,000A18A996E9DA:2,000A18A996E9DA:3,000A18A996E9DA:4,000A18A996E9DA:5,000A18A996E9DA:6,000A18A996E9DA:7
CHILDREN: 000A18A996E9DA:0,:1,:2,:3,:4,:5,:6,:7
oder
CHILDREN: name_0,name_1,name_2,name_3,name_4,..
DIRECTION: NONE
FIRMWARE: 2.0.2
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 10083543
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG
SUBTYPE: TRV
UPDATABLE: 1
Channel 000A18A996E9DA:0 HmIP-eTRV-2 000A18A996E9DA:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 000A18A996E9DA
PARENT_TYPE: HmIP-eTRV-2
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000A18A996E9DA:1 HMc_hc_1 HmIP-eTRV-2 000A18A996E9DA:1 [HEATING_CLIMATECONTROL_TRANSCEIVER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CLIMATE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000A18A996E9DA
PARENT_TYPE: HmIP-eTRV-2
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Nachdem das ganze Systemaitsch ist sollte es einfach machbar sein.
next: Schaltlisten / Wochenpläne.
Die ausgegebene Liste der Wochenpläne ist (sicher klar) indiskutablen. Eine Registerliste ist nicht mehr lessbar und die Zahlen sowieso nicht.
P1_ENDTIME_FRIDAY_1 = 360
P1_ENDTIME_FRIDAY_10 = 1440
P1_ENDTIME_FRIDAY_11 = 1440
P1_ENDTIME_FRIDAY_12 = 1440
P1_ENDTIME_FRIDAY_13 = 1440
P1_ENDTIME_FRIDAY_2 = 540
P1_ENDTIME_FRIDAY_3 = 1020
P1_ENDTIME_FRIDAY_4 = 1320
P1_ENDTIME_FRIDAY_5 = 1440
P1_ENDTIME_FRIDAY_6 = 1440
P1_ENDTIME_FRIDAY_7 = 1440
P1_ENDTIME_FRIDAY_8 = 1440
P1_ENDTIME_FRIDAY_9 = 1440
a) die Sortierung. P1_ENDTIME_FRIDAY_1 => P1_ENDTIME_FRIDAY_01 zwingend erforderlich in dieser Darstellung
b) P1_ENDTIME_FRIDAY_01 = 360 => P1_ENDTIME_FRIDAY_1 = 06:00 in Uhrzeit umwandeln
c) optional: Werte nach dem ersten "1440" können entfallen, da sie ignoriert werden.
P1_ENDTIME_FRIDAY_1 = 360
P1_TEMPERATURE_FRIDAY_1 = 17.0
d) Kombinieren der Uhrzeit mit der Temperatur
P1_FRIDAY_1 = 17.0 06:00
Temperatur besser vor der Zeit angeben. Ich habe es wie von eq3 anders herum gemacht - das verwirrt quasi alle (incl mir)
und
e) Ein Tag in einer Zeile
e1) stoppen nach der 24:00 eingabe
e2) immer fixe stringlänge (leading '0')
P1_Friday = 17.0 06:00 24.0 22:00 05.0 24:00
=> die Eingabe (set datapoint) sollte hier entsprechend gemacht werden.
=> das ist demnach eine Abweichung von der strikten Datapoint ein/ausgabe. Aber bei der Länge der Listen ist dies unabdingbar. So ist es nicht lesbar
f) Praktisch ist es, die Wochentage zu nummerieren. Das ist zum Sortieren notwendig
P1_1_MONDAY
P1_2_TUESDAY
...
Ich werde Deine Hinweise morgen mal der Reihe nach angehen. Vorab 2 Punkte:
- Ich hatte ja schon mal erwähnt, dass ich mich zunächst auf die funktionalen Dinge konzentriere und die Schleifchen bei den reinen Bildschirmausgabe-Befehlen (get xyDesc) später kommt. Ich habe es aber nicht vergessen
- Wenn Du ein neues Device anlegst, sollten automatisch einige Attribute gesetzt werden, auch Widget Attribute. Bestehende Devices, die beim Starten aus der fhem.cfg definiert werden, müssen einmalig mit "set defaults" aktualisiert werden. Das setzt dann nachträglich die Attribute.
Rt temperaturen:
A) auch wenn die values set_point_temperature u.ä. heisen solltest du dies desired-temp nennen. Und actual measured-temp. Es gibt mehrere module welche Heizung unterstützen und quasi alle thermostate in fhem ansteuern. Hier ist es sinnvoll und wünschenswert für gleiche readings die selben Namen zu verwenden. Auch ich musste einst anpassen
B) für Temperatur einstellungen sollte es einen slider geben.
C) wo wir beim Thema sind: sollten nicht alle schreibbaren VALUES ein eigenes kommando habe ? Ich habe es aktuell nicht geprüft... VALUES mit literals sollten eine dropdown liste erhalten. So bspw der mode beim rt
Es gibt sicher Ausnahmen. So kann man beim dimmer level die Rampe Zeit, level und ontime angeben. Dies muss atomar gesendet werden. Also eine Ausnahme, ein multiparameter kommando. Die Frames welche in xml beschrieben sind müssen implementiert werden. Allerdings habe ich noch nicht gesehen, wie du sie der ccu entlocken kannst
Habe set defaults gemacht. Es existiert für den rt nicht.
Ich hoffe, das in zukunft nicht zu brauchen. Die standart kommandos müssen schlicht eingebaut werden, ungefragt. Der user kann weitere on top implementieren, keine Frage. Deswegen werden die normale nicht angefasst. Der user sollte in fhem hinreichend optionen haben, alles zu verbiegen. Hmccu muss und sollte hier nichts neues anbieten, was es schon gibt, nur um es noch einmal neu anzubieten.
Ich habe leider kein IP Thermostat. Das ist alles recht leicht in HMCCUConf.pm konfigurierbar. Kannst Du mir bitte die Rolle von dem Kanal sagen? Ist das HEATING_CLIMATECONTROL_TRANSCEIVER?
Ich kann das rel. einfach einbauen.
Moin,
nach allerlei Kampf mit mehreren Geräten vom Typ HMCCUDEV für virtuelle HmIP-Heating Geräte (s. https://forum.fhem.de/index.php/topic,108902.0.html) habe ich den Eindruck, dass die Dokumentation verbessert werden könnte, indem man angibt, auf welche Events, die von der CCU geliefert werden, die regex der ccureadingffilter angewendet werden (bzw. wie man die für ein Gerät ermitteln kann). Ich bin lange davon ausgegangen, dass bei einem virtuellen Gerät auch nur die Liste von "get deviceinfo" betrachtet wird. Alternativ schlage ich vor, HMCCU so zu ändern, dass das nur die o. g. devicenfo Daten betrachtet werden. Das würde zumindest meiner Intuition folgen, da das virtuelle Gerät ja unter anderem den Rest verbergen soll.
Ansonsten kann ich mit HMCCU jetzt genau das machen, was ich möchte. Danke dafür!
Gruß
Thomas
Ein neues Update für HMCCU 4.4 ist in contrib/HMCCU/FHEM verfügbar.
@Martin: Bitte Dein IP-Thermostat nochmal neu anlegen (nach dem Update). Es sollte jetzt erkannt werden.
Um alle Readings zu bekommen:
attr xy ccuflags showMasterReadings,showLinkReadings,showDeviceReadings
get xy values oder get xy update
get xy config
@Zap: ist eingeabut, sieht schon einmal gut aus
@Thomas: Mir ist nicht klar, was du erreichen willst. Erst einmal schliesse ich mich dem Dank an zap für die unermüdliche Arbeit an. Allerdings fehlen mir noch einige Details (es ist also noch viel zu tun und wird einiges an Zeit kosten).
Zitatauf welche Events, die von der CCU geliefert werden, die regex der ccureadingffilter angewendet werden
in FHEM ist es üblich, alle Events in Readings abzubilden. Die uralten Attribute event-on-change-reading und event-on-update-reading sind für die Steuerung verantwortlich, welches Reading ein event auslösen soll und welches nicht. "ccureadingffilter" sollte entweder eine
wichtige Erweiterung liefern welche nicht zentral realisiert werden kann/sollte - oder es sollte entfernt werden. Wir arbeiten hier an der FHEM platform und nicht in einer HMCCU-internen Lösung.
@zap: Wir gesagt, noch einmal danke. Ich werden (natürlich) weiter testen und versuchen konstruktiv zu kommentieren.
Die Heizung - set kommandos
- control/desired-temp: Diese sind doppelt. Kann man "control" entfernen?
- auto/holiday/boost: Das sollte m.E. ein Kommando sein. Set entity coltrolMode [auto|boost|holiday]. Eine Drop-down liste ist angebracht. Es fehlen day/night/manu
- manu: passt fast zu controlMode. Hier sollte es aber ein weiteres kommando geben, in dem man die Temperatur gleich angeben kann. Das ist der typische fall (set entity controlManu 21)
- on/off: Das ist wohl ein Überbleibsel von etwas altem. noArg ist nicht korrekt implementiert - wenn es aber komplett gelöscht wird ist es wurscht.
- control: das ist das setzen der Register. Die Syntax sollte a) in der Fehlermeldung kommen wenn man keine Parameter angibt und b) empfehle ich ein get entity cmdList welche die komplette Liste der möglchen Kommandos incl parameter listet. Sollte m.E. jedes modul implementieren
Weiter:
Readings sollten per default immer automatisch aktualisiert werden. Wenn FHEM die Zentrale ist (das ist m.E. das Ziel) sind alle Events immer abzuholen. Ich kann mir keinen anderen Betrieb vorstellen.
Was natürlich noch fehlt ist die Peering-Struktur, wochenplan und Wochenplan-auswahl. Hier ist einiges zutun - und hier muss man über eq3 hinaus erweitern. Ein Wochenplan bspw darf nicht nur eine Nummer sein, ich brauche einen Namen hierzu. Heating ist ein recht komplexes Thema - mit vielen Usern.
Noch ein kommentar:
Ccureadingnames: das duplizieren von readings in fhem macht man mit userreading.
Das renamen von readings um sie den fhem Systemgepflogenheiten anzupassen sollte intern geschehen.
Warum also brauche ich diese Einträge? Das attribut ist überflüssig incl der funktionen welche du sicher intern implementiert hast ( duplicate) und die default umsetzung sollte immer und intern passieren, so wie es alle anderen module auch machen.
Zitat von: martinp876 am 08 März 2020, 10:32:25
Die Heizung - set kommandos
- control/desired-temp: Diese sind doppelt. Kann man "control" entfernen?
control ist noch so ein Relikt, das ich mich noch nicht getraut habe zu entfernen. Muss erst prüfen, ob es Seiteneffekte hat.
Zitat
- auto/holiday/boost: Das sollte m.E. ein Kommando sein. Set entity coltrolMode [auto|boost|holiday]. Eine Drop-down liste ist angebracht. Es fehlen day/night/manu
Das liegt an der Implementierung dieser Controlmodes in den IP-Thermostaten. Bei den alten BidCos-Thermostaten gab es einen Datenpunkt CONTROL_MODE, über den man die Modi gesteuert hat. Bei IP hat jeder Modus seinen eigenen Datenpunkt zur Steuerung und CONTROL_MODE hält lediglich den (readonly) Status.
Zitat
- manu: passt fast zu controlMode. Hier sollte es aber ein weiteres kommando geben, in dem man die Temperatur gleich angeben kann. Das ist der typische fall (set entity controlManu 21)
Sollte eigentlich so sein (mit Termperaturangabe). Vermutlich ein Fehler in der Befehlsdefinition.
Zitat
- on/off: Das ist wohl ein Überbleibsel von etwas altem. noArg ist nicht korrekt implementiert - wenn es aber komplett gelöscht wird ist es wurscht.
Wird weiter gebraucht. Schaltet die Heizung dauerhaft aus (Setzen der Temperatur auf 4.5 Grad) oder dauerhaft ein (Temperatur = 30.5, quasi boost ohne Berücksichtigung der boost-Dauer).
Zitat
Weiter:
Readings sollten per default immer automatisch aktualisiert werden. Wenn FHEM die Zentrale ist (das ist m.E. das Ziel) sind alle Events immer abzuholen. Ich kann mir keinen anderen Betrieb vorstellen.
Die get-Befehle im Beitrag oben waren nur für Dich zum schnellen Testen gedacht. Die Readings der VALUES Parametersets werden automatisch aktualisiert, wenn der RPC-Server gestartet ist. Bei den MASTER Parametersets aktualisiert die CCU das leider nicht automatisch. Bin noch unschlüssig, ob ich einen internen Timer implementiere, der das erledigt oder es dem Nutzer überlasse (per at Befehl).
Zitat
Was natürlich noch fehlt ist die Peering-Struktur, wochenplan und Wochenplan-auswahl. Hier ist einiges zutun - und hier muss man über eq3 hinaus erweitern. Ein Wochenplan bspw darf nicht nur eine Nummer sein, ich brauche einen Namen hierzu. Heating ist ein recht komplexes Thema - mit vielen Usern.
Wochenplan ist in Arbeit. Hat jetzt zwar nochmal etwas Zeit gekostet, aber ich habe jetzt in HMCCUConf.pm recht flexible Datenstrukturen implementiert, um Befehle, Attribute, Konvertierungen von Werten abhängig von der Kanal-Rolle definieren zu können. Das erleichtert die Implementierung Gerätetyp abhängiger Befehle ungemein, da ich nichts am Code von HMCCUCHN oder HMCCUDEV ändern muss.
Bei Interesse kannst Du Dir ja mal die ersten 4 oder 5 Hashes in HMCCUConf.pm anschauen.
genau umgekehrt: bei IP-Thermostaten erfolgt die Steuerung über CONTROL_MODE, bei BidCos über einzelne Datenpunkte.
Zumindest bei IP wird es dann eine Auswahlliste geben. Die Enums sind noch nicht implementiert, aber gerade in Arbeit (s.a. Wochenprogramme). Enums sind dann die Einträge der Auswahlliste
Das liegt an der Implementierung dieser Controlmodes in den IP-Thermostaten. ok, die Entscheidung ist nicht ganz einfach. Soll man sich strikt an die Kommandos von EQ3 halten oder hier händisch ein "neues" Kommando implementieren.
De-Factor ist es auch in der HMIp nur ein Value der durch mehrere Kommandos verädert wird.
Ich sehe, hier, dass man (du) es manuell a implementieren solltest, analog wie es bei BidCos war.
Das Frontend der HMCCU (eq3) sieht für beiden identisch aus. Ich sehe hier, dass ein gleiches Frontend vorrang vor der strikten Einhaltung der Schnittstellendefinition hat.
Also mit anderen Worten: Alles was bei BidCos und HMIP gleich ist sollte es auch gleich aussehen. Ich als User will mir am Ende nicht Gedanke machen "wie ist das nun bei HMIP? anderes Kommando?"
Gleiches gilt für die Module welche die beiden RTs bedienen wollen.
ZitatWird weiter gebraucht. Schaltet die Heizung dauerhaft aus
Sehe ich nicht so. Alle andere machen es über das Setzen der Temperatur auf off. Das ist sowieso nicht dauerhaft sondern hängt vom Controlmode ab. Neben desired-temp ist dies also nicht notwendig und nicht üblich.
Zitat(Temperatur = 30.5, quasi boost ohne Berücksichtigung der boost-Dauer).
Würde ich so nicht ausdrücken. Boost hat eigene Einstellungen wie boost-valve-position. Also vorsicht, so etwas "offentlich" gleich zu setzen. Ähnlich ist ok.
ZitatDie Readings der VALUES Parametersets werden automatisch aktualisiert, wenn der RPC-Server gestartet ist.
klappt bei mir nicht. Was muss ich einstellen? Hoffetlich nichts :)
ZitatWochenplan ist in Arbeit. ...
Bei Interesse kannst Du Dir ja mal die ersten 4 oder 5 Hashes in HMCCUConf.pm anschauen.
super - schaue ich mir an.
@matinp876
Zitatauf welche Events, die von der CCU geliefert werden, die regex der ccureadingffilter angewendet werden (bzw. wie man die für ein Gerät ermitteln kann).
Ja, Du hast recht, das habe ich sehr schlecht formuliert. Es ist definitiv unverständlich, sorry.
Wenn ich z. B. mit dem vi einen Text bearbeite, kann ich z. B. erkennen, ob das, was ich suche, immer am Anfang einer Zeile beginnt, und kann dann das regex pattern mit einem ^ versehen. Bei den ccureadingfiltern kann ich nur annehmen, wie der Text aussieht, die die CCU per rpcproc an HMCCU liefert, und was dann von HMMCU davon tatsächlich verwendet wird. Ich muss die regex quasi "blind" formulieren in der Hoffnung, dass es schon zu den richtigen Readings führen wird.
Meine Annahme war, dass 1. nur genau die events auf updates von den Kanalparametern, die im deviceinfo auf das HMCCUDEV Gerät gelistet werden, auch für das mapping mit den ccrureadingfiltern auf dies Gerät herangezogen werden, und das 2. dann z. B. (LEVEL|...) genau mit dem einem Level, der in Kanal 1 des virtuellen CCU-Gerätes gesendet wird, zu einem Update des Readings benutzt wird. Dem ist aber nicht so. Es werden anscheinend die Events zu allen Kanalparametern aller Geräte der Gruppe auf die regex gemappt (die, die bei "list <virtual-dev>" angezeigt werden).
Und nun komme ich zu dem, was ich möchte. Ich habe 2 Räume, in denen jeweils 2 eTRV-B mit einem WTH eine Heatinggroup bilden.
Alle 3 Geräte haben einen Temperatursensor und jeder der beiden eTRV ihren "eigenen" Öffnungslevel. Das virtuelle Gerät der CCU konsolidiert die Werte so, dass als Raumtemperatur immer die Temperatur des WTH gilt, und dass als LEVEL der eTRV immer der Öffnungsgrad des eTRV genommen wird, der den größeren LEVEL hat. Kann man mit z. B. TinyMatic gut sehen, weil die App das sauber separiert bekommt.
Diese Konsolidierung wollte ich nicht in FHEM machen, wenn sie schon im virtuellen Gerät gemacht wid. Mit HMCCUDEV bekam ich aber gelegentlich in kurzer Folge 3 unterschiedliche Temperaturen und 2 unterschiedliche Levels in meine Readings, so dass die Plots etwas zickzackartig verliefen. Was nicht wirklich gut ist, wenn ich später mal das An- und Abschalten der Heizung auf der Basis dieser Daten steuern möchte.
Ich hoffe, das ist nun etwas verständlicher formuliert. Falls nicht, bitte fragen.
Danke und Gruß
Thomas
Derzeit ist es so gelöst, dass ein Device einer virtuellen Gruppe nicht nur die Readings der Gruppe sondern auch die der Gruppenmitglieder enthält. Das ist tatsächlich verwirrend. Früher dachte ich mal, dass das nützliche Infos sind.
In der 4.4 werde ich das beerdigen. Macht den Code auch deutlich einfacher.
Ich habe gerade eine neue Version der Beta in contrib/HMCCU/FHEM eingecheckt. Änderungen:
- Fehler in HMCCURPCPROC behoben, der die automatische Aktualisierung der HmIP Devices verhindert hat (danke EQ3 :( )
Folgende Kanaltypen sollten nun automatisch erkannt werden, sofern das Modul HMCCUCHN verwendet wird:
'SHUTTER_CONTACT'
'SHUTTER_CONTACT_TRANSCEIVER'
'ROTARY_HANDLE_TRANSCEIVER'
'ALARM_SWITCH_VIRTUAL_RECEIVER'
'SMOKE_DETECTOR'
'LUXMETER'
'MOTIONDETECTOR_TRANSCEIVER'
'KEY'
'KEY_TRANSCEIVER'
'BLIND'
'BLIND_VIRTUAL_RECEIVER'
'SWITCH'
'SWITCH_VIRTUAL_RECEIVER'
'DIMMER'
'DIMMER_VIRTUAL_RECEIVER'
'WEATHER_TRANSMIT'
'THERMALCONTROL_TRANSMIT'
'CLIMATECONTROL_RT_TRANSCEIVER'
'HEATING_CLIMATECONTROL_TRANSCEIVER'
Die Kanäle mit _TRANSCEIVER oder _RECEIVER am Ende gehören zu HmIP Geräten.
@Thomas
ZitatBei den ccureadingfiltern kann ich nur annehmen, wie der Text aussieht,....
keine Frage: regexp ist eindeutig definiert und ccureadingfiltern sollte sich an die Syntax halten. Die "rohwerte" auf welche der/ein Filter angewendet wird müssen 1:1 in der entsprechenden "Beschreibung", also get ... ausgegeben werden. Dann (und nur dann) kann man arbeiten.
Dann musst du nicht mehr "blind" arbeiten.
ZitatIch habe 2 Räume, in denen jeweils 2 eTRV-B mit einem WTH eine Heatinggroup bilden.
ok, heizung und deren Gruppierungen. Da gibt es einiges zu sagen .... und noch zu tun.
1) Ist-Temperatur
ZitatDas virtuelle Gerät der CCU konsolidiert die Werte so...
nicht (ganz) korrekt.
a) man kann RTs unterschiedlich peeren - z.B. nur die Ist-temperatur. Anwendung ist, wenn man einen RT-externen Temperaturfühler hat. Das kann ein einfaches Thermometer sein oder ein "IT". Sobald der Temperatur-kanal des RT gepeert (und aktiv) ist schaltet der RT seine interne Temperaturmessung ab. Man kommt an die Temperatur des RT nicht mehr heran. Das macht nicht die Zentrale sondern der RT selbst. Sollte der RT nichts mehr empfangen (externer Sensor tot) schaltet er seine interne Messung wieder ein.
b) Öffnungsgrad
natürlich hat jedes Ventil einen eigenen Öffnungsgrad und diesen will ich sehen - von jeden Device separat - unbedingt
c) RT teaming
Sind 2 RTs in einem Team wird die soll-temperatur von einem zum anderen übertragen. D.h. wenn ich am Stellrad eines RTs die soll-temp einstelle wird es an den 2. übertragen. Setze ich nun die Solltemp eines RTs in der Zentrale muss ich sicherstellen, dass es an alle Team-mitglieder übertagen wird. Das muss die Zentrale sicherstellen. Aktuell ist mir noch nicht klar, ob das die CCU automatisch erkennt und ausführt oder ob das FHEM machen muss. In CUL_HM habe ich das so realisiert (keine CCU im Spiel).
Sollte man einen "IT" nutzen verteilt dieser nach spätestens 3 min die neue soll-temp.
Mit virtuellen Teams in der CCU habe ich keinerlei erfahrungen - habe ich aktuell auch nicht vor.
FHEM sollte in DEV oder CHN sauber die Werte der entsprechenden entites darstellen - das muss primäres Ziel sein.
3 unterschiedliche Raumtemperaturen kann ich mir nicht vorstellen - das muss ein bug sein. Oder ich habe die Konfiguration nicht verstanden.
falls eine Akkumulation der Ventile gewünscht ist sollte das das in einem übergeordneten Device machen - in DEV der CHN hat es m.E. nichts verloren. Ich akkumuliere unterschiedliche Werte für meine Auswertung - nach meinen Wünschen. Auch Ventile zu einer Gesamtübersicht im Haus... im Verhältniss zur Heizung. Das sollte DEV und CHN nicht machen, das macht der Anwender separat.
Unterschiedliche Temperaturen in virtuellen Gruppen kommen dadurch zustande, dass hier die Werte aller Devices der Gruppe (HK Thermostat, Wandthermostat) dargestellt werden. Das ist eine Erweiterung in HMCCUDEV. Da das mehr verwirrt als hilft, werde ich das entfernen, wenn ich demnächst HMCCUDEV angehe.
Habe jetzt etwas mehr Zeit, da dank Dauer-Homeoffice die täglichen 90 Stauminuten wegfallen :o
@martinp876
Zitat
Die "rohwerte" auf welche der/ein Filter angewendet wird müssen 1:1 in der entsprechenden "Beschreibung", also get ... ausgegeben werden. Dann (und nur dann) kann man arbeiten.
Dann musst du nicht mehr "blind" arbeiten.
Ja, genau da lag mein Problem. HMCCUDEV zeigte bei get deviceinfo nur die Werte des virtuellen Gerätes, der HmIP-Heizungsgruppe an. Aber der ccureadingfilter wurde im Hintergrund nicht nur auf diesen "get deviceinfo" Text angewendet, sondern zusätzlich auf das, was die "echten" Geräte liefern. Da Filter auf ACTUAL_TEMPERATURE z. B. hat also von allen Geräten die Temperatur extrahiert und in ein einziges reading geschrieben. Dito bei den LEVELs.
Zitat
Mit virtuellen Teams in der CCU habe ich keinerlei erfahrungen - habe ich aktuell auch nicht vor.
FHEM sollte in DEV oder CHN sauber die Werte der entsprechenden entites darstellen - das muss primäres Ziel sein.
Das funktioniert für mich nun auch gut, wenn ich statt mit HMCCUDEV mit HMCCUCHN ein Gerät für Kanal 1 des virtuellen HmIP-Gerätes definiere. Und natürlich kann ich auch für die physikalischen HmIP-Geräte der Gruppe ein fhem device erzeugen, um an deren Werte zu gelangen.
Ein potentieller Nachteil der Verwendung von HMCCUCHN ist, dass ich im zugehörigen fhem device die Daten der anderen Kanäle, also z. B. 0 für den Status, nicht habe. Ich bin mir aber nicht sicher, ob dass tatsächlich ein Nachteil ist.
Zitat
Mit virtuellen Teams in der CCU habe ich keinerlei erfahrungen - habe ich aktuell auch nicht vor.
FHEM sollte in DEV oder CHN sauber die Werte der entsprechenden entites darstellen - das muss primäres Ziel sein.
3 unterschiedliche Raumtemperaturen kann ich mir nicht vorstellen - das muss ein bug sein. Oder ich habe die Konfiguration nicht verstanden.
falls eine Akkumulation der Ventile gewünscht ist sollte das das in einem übergeordneten Device machen - in DEV der CHN hat es m.E. nichts verloren.
In der aktuellen CCU3 gibt es nur die Heizungsgruppe als mögliches, virtuelles Gerät. Dies in zwei Varianten abhängig von der HW - Hm oder HmIP. Die Aufgabe, per virtuellem Gerät bestehend aus z. B. einem Wandthermostat und zwei Heizkörperthermostaten die Erwärmung des Raumes zu steuern, scheint mir für die HmIP-Geräte gut gelungen. Beim Anlegen der Heizungsgruppe werden die direkten Verknüpfungen zwischen den Geräten automatisch erzeugt, da muss ich nichts zusätzlich machen. Das oder die Wochenprogramme definiere ich nur für das virtuelle Gerät, und die CCU überträgt das dann automatisch an alle Gruppengeräte.
Wird ein Gerät defekt, lösche ich es aus der Gruppe, lösche seine direkten Verknüpfungen und dann das Gerät selbst. Danach kann ich ein neues Gerät anlernen und zur Gruppe hinzufügen. Mit diesem Hinzufügen wird es automatisch mit den Programmen der Gruppe versorgt.
Man kann auch eine virtuelles Gerät Heizungsgruppe definieren mit nur einem zugeordneten Heizkörperthermostaten. Ich habe allerdings noch nicht probiert, ob die Gruppe verschwinden würde, wenn man den einzigen Thermostaten darin herauslöscht.
Zu den unterschiedlichen Werten habe ich mal einen screenshot von der TinyMatic-App gemacht. Heizung-Wohnzimmer-1 ist das virtuelle Gerät (die HmIP-Heizungsgruppe), TH die Heizkörperthermostaten und WTH der Wandthermostat.
Das virtuelle Gerät verwendet für die Konsolidierung die Temperatur und Luftfeuchte des WTH, und den jeweils größeren Öffnungs-LEVEL der TH. Nach weiterer Beobachtung scheint diese Aussage doch nicht richtig zu sein. Aktuell sieht es so aus, als würde einfach der zuletzt von einem eTRV gesendete Wert als aktueller LEVEL in das virtuelle Gerät übernommen. Ich werde das weiter untersuchen und berichten. Eine erste Anfrage bei eQ-3 brachte leider keine Antwort dazu.Zitat
Ich akkumuliere unterschiedliche Werte für meine Auswertung - nach meinen Wünschen. Auch Ventile zu einer Gesamtübersicht im Haus... im Verhältniss zur Heizung. Das sollte DEV und CHN nicht machen, das macht der Anwender separat.
DEV bzw. CHN akkumulieren nicht. Sie greifen nur auf die fertigen Daten des virtuellen Gerätes zu (bei DEV leider noch nicht richtig, aber zap hat das ja schon auf dem Zettel). Und der TinyMatic screenshot zeigt auch, dass keinerlei Detailinformationen durch das virtuelle Gerät verloren gehen, da alle echten Geräte vollständig zugreifbar sind.
Gruß
Thomas
Moin,
es hat etwas gedauert, aber nun kann ich die Analyse liefern, ob die "virtuellen" HmIP-Heizunggruppen die LEVEL-Datenpunkte konsolidieren oder nicht.
Sie tun es nicht.
Im Bild Themostat-LEVEL sieht man die Level der einzelnen Thermostaten als Punktdarstellung in grün und rot, die blaue Linie verbindet die Level-Werte, die das virtuelle Gerät liefert. Der Level des virtuellen Gerätes ist also nur der Level desjenigen Thermostaten, der zuletzt einen Wert geliefert hat.
Für die Temperatur habe ich es mal ähnlich gemacht. Im Bild Thermostate-Temperatur sind die Punkte die Temperaturwerte der Heizkörperthermostaten, die braue Linie verbindet die Werte des Wandthermostaten, und die rote Linie verbindet die vom virtuellen Gerät gesendeten Temperaturen. Man kann erkennen, dass das virtuelle Gerät nur die Temperatur des WTH heranzieht, aber zusätzlich noch Temperatur-Werte generiert (zuletzt gesnedete Temperatur), wenn der WTH länger nichts gesendet hat. Das ist aus meiner Sicht völlig sinnfrei.
Mein Fazit: Die Datenpunkte des virtuellen Geräts, zumindest die für LEVEL und ACTUAL_TEMPERATURE, sind nicht zur Auswertung geeignet.
Gruß
Thomas
Wäre cool, wenn mal jemand außer Martin die 4.4 testen würde. Gerne Nutzer, die BidCos und HmIP Geräte in einer CCU/HMCCU Umgebung haben. Dazu muss aber mit Bedacht vorgegangen werden:
Angenommen, das FHEM Verzeichnis ist /opt/fhem, dann:
1. FHEM anhalten (shutdown)
2. cd /opt/fhem
3. cp fhem.cfg fhem.cfg.43
4. cd FHEM
5. for i in 88_HMCCU*pm HMCCU*pm; do cp $i $i.43; done
3. Alle Module der Version 4.4 manuell aus https://svn.fhem.de/trac/browser/trunk/fhem/contrib/HMCCU/FHEM runterladen und in das FHEM Modulverzeichnis /opt/fhem/FHEM kopieren
4. FHEM wieder starten und hoffen, dass alles läuft
Achtung! Wenn Ihr in FHEM ein Update ausführt, werden die Beta-Module wieder durch die Version 4.3 überschrieben!
Wenn irgendwas nicht läuft:
1. Fehlermeldungen im FHEM Logfile notieren
2. FHEM anhalten, falls es noch läuft
3. cd /opt/fhem
4. cp fhem.cfg.43 fhem.cfg
5. cd FHEM
6. for i in *pm.43; do mv $i ${i%.43}; done
7. FHEM starten
Wichtige Änderungen von Version 4.3 nach Version 4.4:
- Der interne RPC Server wird nicht mehr unterstützt. Das Attribut ccuflags=procrpc ist damit hinfällig
- Je CCU Device-Channel kann nur noch 1 HMCCUCHN Device definiert werden. Mehrere HMCCUDEV-Devices je CCU Device sind nach wie vor möglich. Das ist insbesondere für HmIP-Wired wichtig
- Bei der interaktiven Definition von Devices (HMCCUCHN und HMCCUDEV) versucht HMCCU nun, anhand der Kanalrolle Default-Attribute zu setzen. Wenn das nicht funktioniert, werden wie bisher die Defaults aus HMCCUConf.pm verwendet. Das Setzen der Defaultattribute kann mit der Option 'noDefaults' beim define Befehl verhindert werden.
- Per Default werden nun alle Datenpunkte gelesen und als Reading dargestellt. Der Readingfilter (ccureadingfilter) ist per Default = .*
- Bei virtuellen Devices (z.B. Heizungsgruppen) werden nun nicht mehr die Readings der Gruppen-Devices gespeichert, sondern nur noch die des virtuellen Devices. Das alter Verhalten kann man mit dem Attribute ccuflags=updGroupMembers im IO-Device wieder aktivieren
- Allgemein: Die Module arbeiten nun wesentlich "intelligenter", indem sie bestimmte Befehle und Parameter aus den Parameterdefinitionen der CCU ermitteln. Dadurch sind in vielen Fällen Attribute wie 'substitute', 'ccuscaleval', 'ccureadingname' u.a. nicht mehr erforderlich.
Hallo zap,
gerade habe ich mal den Update von 4.3 auf 4.4 gemacht. FHEM ließ sich anstandslos wieder starten. Hier das logfile:
2020.04.09 11:36:45 1: HMCCU: [d_ccu : 7697] Graceful shutdown in 8 seconds
2020.04.09 11:36:45 3: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] StopRPCServer()
2020.04.09 11:36:45 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Stopping RPC server CB2001000001000001
2020.04.09 11:36:45 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Deregistering RPC server http://127.0.0.1:7411/fh2001 with ID CB2001000001000001 at http://127.0.0.1:2001
2020.04.09 11:36:45 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Callback for RPC server CB2001000001000001 deregistered
2020.04.09 11:36:45 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Sending signal INT to RPC server process CB2001000001000001 with PID=7706
2020.04.09 11:36:45 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Cleaning up immediately
2020.04.09 11:36:45 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Housekeeping called. Cleaning up RPC environment
2020.04.09 11:36:45 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7706] CB2001000001000001 received signal INT
2020.04.09 11:36:45 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7706] CB2001000001000001 received signal INT
2020.04.09 11:36:45 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7706] RPC server CB2001000001000001 stopped handling connections. PID=7706
2020.04.09 11:36:45 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7706] Number of I/O errors = 0
2020.04.09 11:36:47 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] RPC server process CB2001000001000001 deleted
2020.04.09 11:36:47 1: HMCCU: [d_ccu : 7697] All RPC servers inactive
2020.04.09 11:36:47 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Stop I/O handling
2020.04.09 11:36:47 3: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Close child socket
2020.04.09 11:36:47 3: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Close parent socket
2020.04.09 11:36:47 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] RPC server stopped. Cancel delayed shutdown.
2020.04.09 11:36:48 3: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] StopRPCServer()
2020.04.09 11:36:48 1: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Stopping RPC server CB2010000001000001
2020.04.09 11:36:48 1: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Deregistering RPC server http://127.0.0.1:7420/fh2010 with ID CB2010000001000001 at http://127.0.0.1:2010
2020.04.09 11:36:48 1: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Callback for RPC server CB2010000001000001 deregistered
2020.04.09 11:36:48 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Sending signal INT to RPC server process CB2010000001000001 with PID=7707
2020.04.09 11:36:48 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Cleaning up immediately
2020.04.09 11:36:48 1: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Housekeeping called. Cleaning up RPC environment
2020.04.09 11:36:48 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7707] CB2010000001000001 received signal INT
2020.04.09 11:36:48 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7707] CB2010000001000001 received signal INT
2020.04.09 11:36:48 1: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7707] RPC server CB2010000001000001 stopped handling connections. PID=7707
2020.04.09 11:36:48 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7707] Number of I/O errors = 0
2020.04.09 11:36:50 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] RPC server process CB2010000001000001 deleted
2020.04.09 11:36:50 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Stop I/O handling
2020.04.09 11:36:50 3: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Close child socket
2020.04.09 11:36:50 3: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Close parent socket
2020.04.09 11:36:50 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] RPC server stopped. Cancel delayed shutdown.
2020.04.09 11:36:51 3: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] StopRPCServer()
2020.04.09 11:36:51 1: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Stopping RPC server CB9292000001000001
2020.04.09 11:36:51 1: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Deregistering RPC server http://127.0.0.1:14702/fh9292 with ID CB9292000001000001 at http://127.0.0.1:9292/groups
2020.04.09 11:36:51 1: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Callback for RPC server CB9292000001000001 deregistered
2020.04.09 11:36:51 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Sending signal INT to RPC server process CB9292000001000001 with PID=7708
2020.04.09 11:36:51 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Cleaning up immediately
2020.04.09 11:36:51 1: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Housekeeping called. Cleaning up RPC environment
2020.04.09 11:36:51 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7708] CB9292000001000001 received signal INT
2020.04.09 11:36:51 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7708] CB9292000001000001 received signal INT
2020.04.09 11:36:51 1: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7708] RPC server CB9292000001000001 stopped handling connections. PID=7708
2020.04.09 11:36:51 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7708] Number of I/O errors = 0
2020.04.09 11:36:53 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] RPC server process CB9292000001000001 deleted
2020.04.09 11:36:53 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Stop I/O handling
2020.04.09 11:36:53 3: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Close child socket
2020.04.09 11:36:53 3: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Close parent socket
2020.04.09 11:36:53 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] RPC server stopped. Cancel delayed shutdown.
Select error -1 (3)
2020.04.09 11:44:35 0: HMCCU: [d_ccu : 13128] Scheduling post FHEM initialization tasks in 12 seconds
2020.04.09 11:44:35 0: Featurelevel: 5.9
2020.04.09 11:44:35 0: Server started with 39 defined entities (fhem.pl:21044/2020-01-24 perl:5.028001 os:linux user:fhem pid:13128)
2020.04.09 11:44:47 1: HMCCU: [d_ccu : 13128] Reading device config from CCU. This may take a couple of seconds ...
2020.04.09 11:44:57 2: HMCCU: [d_ccu : 13128] Read device configuration: devices/channels=258 parametersets=153 links=27
2020.04.09 11:44:57 2: HMCCU: [d_ccu : 13128] Get RPC device for interface BidCos-RF
2020.04.09 11:44:57 2: HMCCU: [d_ccu : 13128] Get RPC device for interface HmIP-RF
2020.04.09 11:44:57 2: HMCCU: [d_ccu : 13128] Get RPC device for interface VirtualDevices
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13128] RPC server process started for interface BidCos-RF with PID=13149
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13149] Initializing RPC server CB2001000001000001 for interface BidCos-RF
2020.04.09 11:44:57 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13128] RPC server starting
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13128] RPC server process started for interface HmIP-RF with PID=13150
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13150] Initializing RPC server CB2010000001000001 for interface HmIP-RF
2020.04.09 11:44:57 1: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13128] RPC server starting
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13128] RPC server process started for interface VirtualDevices with PID=13151
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13151] Initializing RPC server CB9292000001000001 for interface VirtualDevices
2020.04.09 11:44:57 1: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13128] RPC server starting
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13149] Callback server CB2001000001000001 created. Listening on port 7411
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13149] CB2001000001000001 accepting connections. PID=13149
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13128] RPC server CB2001000001000001 enters server loop
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13128] Registering callback http://127.0.0.1:7411/fh2001 of type A with ID CB2001000001000001 at http://127.0.0.1:2001
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13150] Callback server CB2010000001000001 created. Listening on port 7420
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13150] CB2010000001000001 accepting connections. PID=13150
2020.04.09 11:44:57 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13128] RPC server CB2001000001000001 running
2020.04.09 11:44:57 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13128] Scheduled CCU ping every 300 seconds
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13151] Callback server CB9292000001000001 created. Listening on port 14702
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13151] CB9292000001000001 accepting connections. PID=13151
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13128] RPC server CB2010000001000001 enters server loop
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13128] Registering callback http://127.0.0.1:7420/fh2010 of type A with ID CB2010000001000001 at http://127.0.0.1:2010
2020.04.09 11:44:57 1: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13128] RPC server CB2010000001000001 running
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13128] RPC server CB9292000001000001 enters server loop
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13128] Registering callback http://127.0.0.1:14702/fh9292 of type A with ID CB9292000001000001 at http://127.0.0.1:9292/groups
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13149] CB2001000001000001 NewDevice received 52 device and channel specifications
2020.04.09 11:44:58 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13151] CB9292000001000001 NewDevice received 35 device and channel specifications
2020.04.09 11:44:58 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13150] CB2010000001000001 NewDevice received 171 device and channel specifications
2020.04.09 11:45:07 1: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13128] RPC server CB9292000001000001 running
2020.04.09 11:45:07 1: HMCCU: [d_ccu : 13128] All RPC servers running
2020.04.09 11:45:07 2: HMCCU: [d_ccu : 13128] Updating 5 of 5 client devices matching devexp=.* filter=ccudevstate=active,ccuif=BidCos-RF|HmIP-RF|VirtualDevices
2020.04.09 11:45:08 2: HMCCU: [d_ccu : 13128] Update success=5 failed=0
Seltsamerweise ist aber nun ein device "verschwunden". Es wird per webui nicht mehr angezeigt, auch nicht in everything. Die Definition ist aber im fhme.cfg noch enthalten:
define wz_hzg HMCCUCHN Heizung-Wohnzimmer-1 defaults
setuuid wz_hzg 5e62461f-f33f-f867-319e-fecd2c08abf0ffe7
attr wz_hzg IODev d_ccu
attr wz_hzg ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL|HUMIDITY)
attr wz_hzg room Wohnzimmer
Heizung-Wohnzimmer-1 ist Kanal 1 des virtuellen HmIP-Heizungsgruppe Gerätes. Alle 4 für anderen Räume identisch definierten devices sind nach wie vor sichtbar.
Der Austausch der pm-Module war die einzige Änderung, die ich gemacht habe. Stop und start von FHEM erfolgte über systemctl <command> FHEM (unter debmatic.
Falls Du eine Idee hast, was ich prüfen könnte, würde ich das gerne tun.
Gruß
Thomas
Danke für die Unterstützung beim Test. Kann es sein, dass es bereits ein Device für diesen Kanal gibt? HMCCUCHN erlaubt nämlich nur noch eine Instanz je Kanal.
Du müsstest in dem Fall aber eine Fehlermeldung im Log finden, die darauf hinweist.
Ich danke für die Hm-Module :).
Der Verdacht kam mir nach dem post auch. Ich habe das geprüft, aber es war nicht so.
root@tinkerboard:/opt/fhem# grep HMCCUCHN fhem.cfg
define wz_hzg HMCCUCHN Heizung-Wohnzimmer-1 defaults
define az_hzg HMCCUCHN Heizung-Arbeitszimmer-1
define bo_hzg HMCCUCHN Heizung-Bad-Oben-1
define gz_hzg HMCCUCHN Heizung-Gaestezimmer-1
define bz_hzg HMCCUCHN Heizung-Bastelzimmer-1
define wz_th_west HMCCUCHN Wohnzimmer-TH-West:1 defaults
define wz_th_ost HMCCUCHN Wohnzimmer-TH-Ost:1 defaults
define az_th_west HMCCUCHN Arbeitszimmer-TH-West:1 defaults
define az_th_ost HMCCUCHN Arbeitszimmer-TH-Ost:1 defaults
define az_th_wth HMCCUCHN Arbeitszimmer-WTH-1 defaults
define wz_th_wth HMCCUCHN Wohnzimmer-WTH-1 defaults
define bo_th_wth HMCCUCHN Bad-Oben-WTH-1 defaults
define bz_th_wth HMCCUCHN Bastelzimmer-WTH:1 defaults
define gz_th_wth HMCCUCHN Gaestezimmer-WTH-1 defaults
Da ist kein Kanal 2 mal verwendet.
Allerdings ist die Definition der devices für die 5 Räume doch nicht völlig identisch:
root@tinkerboard:/opt/fhem# grep "_hzg.*HMCCUCHN" fhem.cfg
define wz_hzg HMCCUCHN Heizung-Wohnzimmer-1 defaults
define az_hzg HMCCUCHN Heizung-Arbeitszimmer-1
define bo_hzg HMCCUCHN Heizung-Bad-Oben-1
define gz_hzg HMCCUCHN Heizung-Gaestezimmer-1
define bz_hzg HMCCUCHN Heizung-Bastelzimmer-1
Ich hatte mal das "defaults" aus dem .cfg für wz_hzg entfernt, aber da startete FHEM nicht mehr (mit allerlei Fehlermeldungen).
Nun habe ich wieder das originale .cfg:
root@tinkerboard:/opt/fhem# cat fhem.cfg
attr global userattr cmdIcon devStateIcon:textField-long devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride
attr global autoload_undefined_devices 1
attr global autosave 0
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd SecurityCheck:\
WEB is not password protected\
\
Protect this FHEM installation by configuring the allowed device allowed\
You can disable this message with attr global motd none
attr global statefile ./log/fhem.save
attr global verbose 0
define WEB FHEMWEB 8083 global
setuuid WEB 5e2d67b1-f33f-f867-8b85-7484f1688337510d
attr WEB stylesheetPrefix dark
# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
setuuid Logfile 5e2d67b1-f33f-f867-b11c-eb4e6619584191a7
define autocreate autocreate
setuuid autocreate 5e2d67b1-f33f-f867-6d98-2d9b2b74ac7927c2
attr autocreate filelog ./log/%NAME-%Y.log
define eventTypes eventTypes ./log/eventTypes.txt
setuuid eventTypes 5e2d67b1-f33f-f867-ff1b-5433466d6fc90f8e
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
setuuid initialUsbCheck 5e2d67b1-f33f-f867-d162-671d1a8971c89cdf
attr initialUsbCheck disable 1
define allowed allowed
setuuid allowed 5e2d6b20-f33f-f867-c054-8837bd6346d0d5d3
define d_ccu HMCCU localhost ccudelay=180
setuuid d_ccu 5e2dc28a-f33f-f867-d6a9-cfa538ff89ad3600
attr d_ccu ccudef-readingfilter ^(LOW_?BAT|UNREACH)$
attr d_ccu ccudef-readingname ^(.+\.)?LOW_?BAT$:battery;;^(.+\.)?UNREACH$:activity
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 procrpc,logEvents
attr d_ccu cmdIcon on:general_an off:general_aus
attr d_ccu eventMap /rpcserver on:on/rpcserver off:off/
attr d_ccu room ccu
attr d_ccu rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
attr d_ccu rpcport 2001,2010,9292
attr d_ccu rpcserver on
attr d_ccu stateFormat rpcstate/state
attr d_ccu verbose 3
define d_rpc000001HmIP_RF HMCCURPCPROC http://127.0.0.1 HmIP-RF
setuuid d_rpc000001HmIP_RF 5e2f3bda-f33f-f867-2b11-a22d740f333e2b16
attr d_rpc000001HmIP_RF alias CCU RPC HmIP-RF
attr d_rpc000001HmIP_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpc000001HmIP_RF room ccu
attr d_rpc000001HmIP_RF stateFormat rpcstate/state
attr d_rpc000001HmIP_RF verbose 3
define d_rpc000001VirtualDevices HMCCURPCPROC http://127.0.0.1 VirtualDevices
setuuid d_rpc000001VirtualDevices 5e2f3bda-f33f-f867-12a4-914118afad54879a
attr d_rpc000001VirtualDevices alias CCU RPC VirtualDevices
attr d_rpc000001VirtualDevices eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpc000001VirtualDevices room ccu
attr d_rpc000001VirtualDevices stateFormat rpcstate/state
attr d_rpc000001VirtualDevices verbose 3
define d_rpc000001BidCos_RF HMCCURPCPROC http://127.0.0.1 BidCos-RF
setuuid d_rpc000001BidCos_RF 5e30880e-f33f-f867-6e8c-78c4b3caeb42ef6b
attr d_rpc000001BidCos_RF alias CCU RPC BidCos-RF
attr d_rpc000001BidCos_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpc000001BidCos_RF room ccu
attr d_rpc000001BidCos_RF stateFormat rpcstate/state
attr d_rpc000001BidCos_RF verbose 3
define wz_schalter HMCCUDEV Schalter-Gartenlicht
setuuid wz_schalter 5e36f60f-f33f-f867-eece-57ddfbfe47750a56
attr wz_schalter IODev d_ccu
attr wz_schalter ccureadingfilter (STATE|PRESS|CURRENT|POWER)
attr wz_schalter controldatapoint 4.STATE
attr wz_schalter room Wohnzimmer
attr wz_schalter statedatapoint 4.STATE
attr wz_schalter statevals on:true,off:false
attr wz_schalter substitute STATE!(true|1):on,(false|0):off
attr wz_schalter webCmd control
attr wz_schalter widgetOverride control:uzsuToggle,off,on
define Dashboard Dashboard
setuuid Dashboard 5e493865-f33f-f867-89ed-2bbded80ad6a6c5c
attr Dashboard userattr dashboard_homeTab:1 dashboard_tab2backgroundimage dashboard_tab2colcount dashboard_tab2devices dashboard_tab2groups dashboard_tab2icon dashboard_tab2name dashboard_tab2rowcentercolwidth dashboard_tab2sorting dashboard_webRefresh:multiple-strict,WEB
attr Dashboard dashboard_showtabs tabs-and-buttonbar-at-the-top
attr Dashboard dashboard_tab1devices THLevel
attr Dashboard dashboard_tab1groups Set your FHEM groups here and arrange them on tab 1
attr Dashboard dashboard_tab1name Raumtemperaturen
attr Dashboard dashboard_width 80%
attr Dashboard group Heizung
define battStatus readingsGroup .*:[Bb]attery
setuuid battStatus 5e4947a2-f33f-f867-7340-71c60f9abbb4ddfb
attr battStatus room ccu
define THLevel readingsGroup <%sani_heating>,<Ventil>,<Ist>,<Soll> .*_hzg:1.LEVEL,1.ACTUAL_TEMPERATURE,1.SET_POINT_TEMPERATURE
setuuid THLevel 5e496363-f33f-f867-8a3a-3fffce8fbeeb1e00
attr THLevel alias Raumheizung
attr THLevel mapping %ROOM
attr THLevel notime 1
attr THLevel room ccu
attr THLevel valueFormat { '1.LEVEL' => "%.2f %%", '1.ACTUAL_TEMPERATURE' => "%.1f °C", '1.SET_POINT_TEMPERATURE' => "%.1f °C" }
define hzg_event notify THLevel:.* Log 3, ('THLevel Event');;
setuuid hzg_event 5e529505-f33f-f867-eec5-179694e38621c3c8
attr hzg_event room ccu
define wz_hzg_notify_1 notify .*_hzg:.*.(LEVEL|ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE):.* {\
my $brauche_waerme=0;;;;\
my $ventile_mit_bedarf=0;;;;\
my $ventile_im_leerlauf=0;;;;\
my $heizung_status=ReadingsVal("thision","state","off");;;;\
my @thermostat = devspec2array(".*_hzg");;;;\
foreach(@thermostat) {\
my $ventil=ReadingsVal($_, "1.LEVEL", "1.0");;;;\
$ventil=substr($ventil, 0, (length($ventil)));;;;\
#Log(3,"HKE - Ventilöffnung: " . $_ . " " . $ventil);;;;\
if ($ventil > 0.12) {\
$brauche_waerme=1;;;;\
$ventile_mit_bedarf++;;;;\
}\
if ($ventil < 0.10) {\
$ventile_im_leerlauf++;;;;\
}\
}\
if ($brauche_waerme != 0) {\
if ($heizung_status ne "on") {\
fhem("set thision on");;;;\
Log(3,"HKE - Wärme benötigt. Vorheriger Heizungsstatus: " . $heizung_status);;;;\
Log(3,"HKE - " . $ventile_mit_bedarf . " Heizkörper von " . @thermostat . " melden Bedarf (> 12 %Öffnung)");;;;\
}\
}\
else {\
if ($ventile_im_leerlauf == @thermostat) {\
if ($heizung_status eq "on") {\
fhem("set thision off");;;;\
Log(3,"HKE - Keine Wärme (mehr) benötigt. Vorheriger Heizungsstatus: " . $heizung_status);;;;\
}\
}\
#else {\
# Log(3,"HKE - Heizbedarf: " . $ventile_im_leerlauf . " von " . @thermostat . " Ventile stehen bei 0 %.");;;;\
#}\
}\
}\
setuuid wz_hzg_notify_1 5e52a539-f33f-f867-f59f-55228ffd555ab83d
attr wz_hzg_notify_1 room ccu
define thision dummy
setuuid thision 5e541e16-f33f-f867-b5c5-30cf06ffa6e50a7d
attr thision room ccu
attr thision webCmd toggle:on:off:statusRequest
define FileLog_thision FileLog /opt/fhem/log/thision-%Y-%m.log thision:(on|off)
setuuid FileLog_thision 5e541f1c-f33f-f867-c1cd-677f7d6fa282060b
attr FileLog_thision logtype text
attr FileLog_thision room Logs,ccu
define SVG_thision SVG FileLog_thision:thisionOnOff:CURRENT
setuuid SVG_thision 5e542061-f33f-f867-daf9-3a929e9be4feb6a5
attr SVG_thision plotsize 1000,500
attr SVG_thision room Heizung
define wz_hzg_log FileLog /opt/fhem/log/wz_hzg_log-%Y-%m.log wz_hzg:.*.(LEVEL|ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|HUMIDITY):.*
setuuid wz_hzg_log 5e54e2a4-f33f-f867-43b5-a5088caa157faa76
attr wz_hzg_log logtype text
attr wz_hzg_log room Logs,Wohnzimmer
define SVG_wz_hzg_log_1 SVG wz_hzg_log:SVG_wz_hzg_log_1:CURRENT
setuuid SVG_wz_hzg_log_1 5e54e3ec-f33f-f867-103a-22dc60e7760f11dd
attr SVG_wz_hzg_log_1 plotsize 1000,500
attr SVG_wz_hzg_log_1 room Wohnzimmer
define az_hzg_log FileLog /opt/fhem/log/az_hzg_log-%Y-%m.log az_hzg:.*.(LEVEL|ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|HUMIDITY):.*
setuuid az_hzg_log 5e551f71-f33f-f867-9b21-46bb0da73a3e50eb
attr az_hzg_log logtype text
attr az_hzg_log room Arbeitszimmer,Logs
define SVG_az_hzg_log_1 SVG az_hzg_log:SVG_az_hzg_log_1:CURRENT
setuuid SVG_az_hzg_log_1 5e551fe6-f33f-f867-4c74-774157e9b8d0461f
attr SVG_az_hzg_log_1 plotsize 1000,500
attr SVG_az_hzg_log_1 room Plots,Arbeitszimmer
define bz_hzg_log FileLog /opt/fhem/log/bz_hzg_log-%Y-%m.log bz_hzg:.*.(LEVEL|ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|HUMIDITY):.*
setuuid bz_hzg_log 5e5524de-f33f-f867-a1ec-337bcac139bccd89
attr bz_hzg_log room Bastelzimmer,Logs
define gz_hzg_log FileLog /opt/fhem/log/gz_hzg_log-%Y-%m.log gz_hzg:.*.(LEVEL|ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|HUMIDITY):.*
setuuid gz_hzg_log 5e55250e-f33f-f867-3de4-c38a304802799337
attr gz_hzg_log room Gästezimmer,Logs
define bo_hzg_log FileLog /opt/fhem/log/bo_hzg_log-%Y-%m.log bo_hzg:.*.(LEVEL|ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|HUMIDITY):.*
setuuid bo_hzg_log 5e55253a-f33f-f867-70f3-8a1dae5909d0a168
attr bo_hzg_log room Bad_oben,Logs
define SVG_bz_hzg_log_1 SVG bz_hzg_log:SVG_bz_hzg_log_1:CURRENT
setuuid SVG_bz_hzg_log_1 5e552b58-f33f-f867-8d23-ec7ed907b4a624ab
attr SVG_bz_hzg_log_1 plotsize 1000,500
attr SVG_bz_hzg_log_1 room Bastelzimmer
define SVG_bo_hzg_log_1 SVG bo_hzg_log:SVG_bo_hzg_log_1:CURRENT
setuuid SVG_bo_hzg_log_1 5e552d2f-f33f-f867-cddd-e00fb81db182144d
attr SVG_bo_hzg_log_1 plotsize 1000,500
attr SVG_bo_hzg_log_1 room Bad_oben
define SVG_gz_hzg_log_1 SVG gz_hzg_log:SVG_gz_hzg_log_1:CURRENT
setuuid SVG_gz_hzg_log_1 5e553142-f33f-f867-72a1-077e325117b0ec5d
attr SVG_gz_hzg_log_1 plotsize 1000,500
attr SVG_gz_hzg_log_1 room Gästezimmer
define d_wz_hzg_log FileLog /opt/fhem/log/d_wz_hzg_log-%Y-%m.log d_wz_hzg:1.(LEVEL|ACTUAL_TEMPERATURE|^SET_POINT_TEMPERATURE|HUMIDITY):.*
setuuid d_wz_hzg_log 5e5d622a-f33f-f867-ed7d-d58672d3659e5393
define wz_hzg_wth HMCCUDEV Wohnzimmer-WTH defaults
setuuid wz_hzg_wth 5e60d243-f33f-f867-066d-a7f926df6cc4d3e5
attr wz_hzg_wth IODev d_ccu
attr wz_hzg_wth ccureadingfilter .*
attr wz_hzg_wth room Wohnzimmer
define wz_hzg HMCCUCHN Heizung-Wohnzimmer-1 defaults
setuuid wz_hzg 5e62461f-f33f-f867-319e-fecd2c08abf0ffe7
attr wz_hzg IODev d_ccu
attr wz_hzg ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL|HUMIDITY)
attr wz_hzg room Wohnzimmer
define az_hzg HMCCUCHN Heizung-Arbeitszimmer-1
setuuid az_hzg 5e625ca4-f33f-f867-fb42-a8fe166643293cda
attr az_hzg IODev d_ccu
attr az_hzg ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL|HUMIDITY)
attr az_hzg room Arbeitszimmer
define bo_hzg HMCCUCHN Heizung-Bad-Oben-1
setuuid bo_hzg 5e626064-f33f-f867-9464-4a8fc85c65824bcd
attr bo_hzg IODev d_ccu
attr bo_hzg ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL|HUMIDITY)
attr bo_hzg room Bad_oben
define gz_hzg HMCCUCHN Heizung-Gaestezimmer-1
setuuid gz_hzg 5e62611a-f33f-f867-0406-29210a6667967a02
attr gz_hzg IODev d_ccu
attr gz_hzg ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL|HUMIDITY)
attr gz_hzg room Gästezimmer
define bz_hzg HMCCUCHN Heizung-Bastelzimmer-1
setuuid bz_hzg 5e6266ab-f33f-f867-fe86-1e2566e18e6de2d5
attr bz_hzg IODev d_ccu
attr bz_hzg ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL|HUMIDITY)
attr bz_hzg room Bastelzimmer
define wz_th_west HMCCUCHN Wohnzimmer-TH-West:1 defaults
setuuid wz_th_west 5e75e6f1-f33f-f867-d0eb-c7eb434f460bd661
attr wz_th_west IODev d_ccu
attr wz_th_west ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL)
attr wz_th_west room Wohnzimmer
define wz_th_ost HMCCUCHN Wohnzimmer-TH-Ost:1 defaults
setuuid wz_th_ost 5e75eb1c-f33f-f867-8a55-e6aa1ce148a1df45
attr wz_th_ost IODev d_ccu
attr wz_th_ost ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL)
attr wz_th_ost room Wohnzimmer
define az_th_west HMCCUCHN Arbeitszimmer-TH-West:1 defaults
setuuid az_th_west 5e75ebd0-f33f-f867-99f3-f61743dfa888b8a6
attr az_th_west IODev d_ccu
attr az_th_west ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL)
attr az_th_west room Arbeitszimmer
define az_th_ost HMCCUCHN Arbeitszimmer-TH-Ost:1 defaults
setuuid az_th_ost 5e75ec0f-f33f-f867-cc5b-97937453c7a062f2
attr az_th_ost IODev d_ccu
attr az_th_ost ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL)
attr az_th_ost room Arbeitszimmer
define az_th_log FileLog /opt/fhem/log/az_th_log-%Y-%m.log az_th_.*:.*.(ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL|HUMIDITY):.*
setuuid az_th_log 5e76359f-f33f-f867-f80c-2e9f00d645634fa8
attr az_th_log logtype text
attr az_th_log room Arbeitszimmer,Logs
define wz_th_log FileLog /opt/fhem/log/wz_th_log-%Y-%m.log wz_th_.*:.*.(ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL|HUMIDITY):.*
setuuid wz_th_log 5e7636ee-f33f-f867-6dad-bc15d36ca9530523
attr wz_th_log logtype text
attr wz_th_log room Logs,Wohnzimmer
define SVG_az_th_log_1 SVG az_th_log:SVG_az_th_log_1:CURRENT
setuuid SVG_az_th_log_1 5e772362-f33f-f867-8a44-138568427cf6f52c
attr SVG_az_th_log_1 plotsize 1000,400
attr SVG_az_th_log_1 room Arbeitszimmer,Plots
define az_th_wth HMCCUCHN Arbeitszimmer-WTH-1 defaults
setuuid az_th_wth 5e772767-f33f-f867-adad-c1d19b0b8953cc19
attr az_th_wth IODev d_ccu
attr az_th_wth ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL|HUMIDITY)
attr az_th_wth room Arbeitszimmer
define wz_th_wth HMCCUCHN Wohnzimmer-WTH-1 defaults
setuuid wz_th_wth 5e773c22-f33f-f867-4d21-7c46bb035dbcab25
attr wz_th_wth IODev d_ccu
attr wz_th_wth ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL|HUMIDITY)
attr wz_th_wth room Wohnzimmer
define SVG_wz_th_log_1 SVG wz_th_log:SVG_wz_th_log_1:CURRENT
setuuid SVG_wz_th_log_1 5e773cdf-f33f-f867-2d02-d0ab91e188c610c8
attr SVG_wz_th_log_1 plotsize 1000,400
attr SVG_wz_th_log_1 room Plots,Wohnzimmer
define bo_th_wth HMCCUCHN Bad-Oben-WTH-1 defaults
setuuid bo_th_wth 5e7c9746-f33f-f867-4ece-f0a97bf276523b28
attr bo_th_wth IODev d_ccu
attr bo_th_wth ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL|HUMIDITY)
attr bo_th_wth room Bad_oben
define bz_th_wth HMCCUCHN Bastelzimmer-WTH:1 defaults
setuuid bz_th_wth 5e7c9804-f33f-f867-7af4-6d281b63e1c55ce3
attr bz_th_wth IODev d_ccu
attr bz_th_wth ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL|HUMIDITY)
attr bz_th_wth room Bastelzimmer
define gz_th_wth HMCCUCHN Gaestezimmer-WTH-1 defaults
setuuid gz_th_wth 5e7c98a3-f33f-f867-35da-b71010a761061842
attr gz_th_wth IODev d_ccu
attr gz_th_wth ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL|HUMIDITY)
attr gz_th_wth room Gästezimmer,Wohnzimmer
Vielleicht springt Dir da ja was ins Auge, was ich falsch gemacht habe :).
Viele Grüße
Thomas
Moin zap,
habe gerade erstmal wieder auf 4.3 zurückgerüstet, da ich festgestellt habe, dass seit dem Umstellung gestern gegen Mittag keinerlei Daten mehr in den FileLogs gelandet sind.
Jetzt nach dem Aktivieren der originalen Module funktioniert alles wieder wie vorher.
Gruß
Thomas
Zitat von: thomas.z am 10 April 2020, 07:46:18
Moin zap,
habe gerade erstmal wieder auf 4.3 zurückgerüstet, da ich festgestellt habe, dass seit dem Umstellung gestern gegen Mittag keinerlei Daten mehr in den FileLogs gelandet sind.
Jetzt nach dem Aktivieren der originalen Module funktioniert alles wieder wie vorher.
Gruß
Thomas
Die Option "defaults" macht nur bei der Definition eines Device in der FHEM-Oberfläche Sinn. Sie ist außerdem die Default-Option ('defaults' ist Default ;) ). Die Default-Attribute werden ja bei der 1. Definition eines Device gesetzt und dann in der fhem.cfg gespeichert. Daher wird die Option bei späteren Starts von FHEM ignoriert. Ich schaue mir das in HMCCUCHN nochmal an. Vielleicht gibt es an der Stelle noch einen Bug.
Die Filelogs basieren ja auf Events. Hier hat sich mit der 4.4 insbesondere bei den virtuellen Geräten etwas entscheidend geändert. Jetzt werden nur noch die Readings aktualisiert, die tatsächlich zum virtuellen Device gehören. Wenn man auch die Readings (Events) der Mitglieder der Gruppe haben möchte, muss man im IO-Device im Attribut ccuflags das Flag updGroupMembers setzen.
Danke für den Hinweis zu "defaults".
Der Punkt mit den Mitglieder der Gruppe dürfte bei meinem Fall nicht zutreffen, da ich das HMCCUCHN Device auf den Kanal 1 des virtuellen Devices gemapped habe:
Heizung-Wohnzimmer-1:
address INT0000004:1
addtype chn
valid 1
"INT0000004:X" sind die typischen IDs für virtuelle Devices.
Hier die vollständige Liste:
INT0000004:
addtype dev
channels 6
chndir 0
firmware 1.0.0
interface VirtualDevices
name Wohnzimmer-Heizung
rxmode 1
type HmIP-HEATING
valid 1
version 65536
INT0000004:0:
addtype chn
channels 1
chndir 0
name Wohnzimmer-Heizung:0
usetype MAINTENANCE
valid 1
version 65536
INT0000004:1:
addtype chn
channels 1
chndir 0
name Heizung-Wohnzimmer-1
usetype HEATING_CLIMATECONTROL_TRANSCEIVER
valid 1
version 65536
INT0000004:2:
addtype chn
channels 1
chndir 0
name Heizung-Wohnzimmer-2
usetype HEATING_CLIMATECONTROL_SWITCH_TRANSMITTER
valid 1
version 65536
INT0000004:3:
addtype chn
channels 1
chndir 0
name Heizung-Wohnzimmer-3
usetype ROTARY_HANDLE_TRANSCEIVER
valid 1
version 65536
INT0000004:4:
addtype chn
channels 1
chndir 0
name Heizung-Wohnzimmer-4
usetype SWITCH_TRANSMITTER
valid 1
version 65536
INT0000004:5:
addtype chn
channels 1
chndir 0
name Heizung-Wohnzimmer-5
usetype KEY_TRANSCEIVER
valid 1
version 65536
Die Geräte der anderen Räume sind mit gleichem identisch benannt.
INT0000006:0:
addtype chn
channels 1
chndir 0
name Arbeitszimmer-Heizung:0
usetype MAINTENANCE
valid 1
version 65536
INT0000006:1:
addtype chn
channels 1
chndir 0
name Heizung-Arbeitszimmer-1
usetype HEATING_CLIMATECONTROL_TRANSCEIVER
valid 1
version 65536
INT0000006:2:
addtype chn
channels 1
chndir 0
name Heizung-Arbeitszimmer-2
usetype HEATING_CLIMATECONTROL_SWITCH_TRANSMITTER
valid 1
version 65536
INT0000006:3:
addtype chn
channels 1
chndir 0
name Heizung-Arbeitszimmer-3
usetype ROTARY_HANDLE_TRANSCEIVER
valid 1
version 65536
INT0000006:4:
addtype chn
channels 1
chndir 0
name Heizung-Arbeitszimmer-4
usetype SWITCH_TRANSMITTER
valid 1
version 65536
INT0000006:5:
addtype chn
channels 1
chndir 0
name Heizung-Arbeitszimmer-5
usetype KEY_TRANSCEIVER
valid 1
version 65536
Nach meinem Verständnis müssten Events für ein Device mit der Definition z. B. "def az_hzg HMCCUCHN Heizung-Arbeitszimmer-1" generiert werden. Oder liege ich falsch?
Gruß
Thomas
Hallo zap,
ich habe die Version 4.4 nun auch in meinem Tessystem installliert. Bis auf den Türdrehgriff sieht es gut aus. Dort liefert die Version allerdings falsche Statusinformationen. Anstatt open, closed und tilted kommt nur false. Hier mein "list"
Internals:
DEF NEQ1477040
FUUID 5c435f29-f33f-4885-0d55-cc25f5a636d92568
IODev HMCCU3
NAME HM_Sec_RHS_NEQ1477040
NR 159
STATE Status: false / LastOpen: 11.04.2020 - 22:40:42 / LastClose: 11.04.2020 - 22:40:45
TYPE HMCCUDEV
ccuaddr NEQ1477040
ccudevstate active
ccuif BidCos-RF
ccuname HM_Sec_RHS_NEQ1477040
ccutype HM-Sec-RHS
readonly no
OLDREADINGS:
READINGS:
2020-04-11 22:13:45 1.ERROR NO_ERROR
2020-04-11 22:42:53 1.LOWBAT ok
2020-04-11 22:42:07 1.STATE false
2020-04-11 22:40:44 LastClose 11.04.2020 - 22:40:45
2020-04-11 22:40:44 LastOpen 11.04.2020 - 22:40:42
2020-04-11 22:42:53 activity alive
2020-04-11 22:42:53 battery ok
2020-04-11 22:42:07 control false
2020-04-11 22:42:53 devstate ok
2020-04-11 22:42:53 hmstate false
2020-04-11 22:42:07 state false
hmccu:
channels 2
devspec NEQ1477040
role 0:MAINTENANCE,1:ROTARY_HANDLE_SENSOR
control:
chn 1
dpt STATE
dp:
0.AES_KEY:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.LOWBAT:
VALUES:
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
VALUES:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
0.RSSI_PEER:
VALUES:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
0.STICKY_UNREACH:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.UNREACH:
VALUES:
OSVAL alive
OVAL false
SVAL alive
VAL false
1.ERROR:
VALUES:
OSVAL NO_ERROR
OVAL 0
SVAL NO_ERROR
VAL 0
1.LOWBAT:
VALUES:
OSVAL ok
OVAL 0
SVAL ok
VAL false
1.STATE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
state:
chn 1
dpt STATE
Attributes:
IODev HMCCU3
alexaName Balkontür
alias Balkontür
devStateStyle style="text-align:right"
event-min-interval battery:3600
event-on-change-reading .*
genericDeviceType contact
group HM Fenster-/Türkontakte
hmstatevals ERROR!1:sabotage
homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;open:CONTACT_NOT_DETECTED;tilted:CONTACT_NOT_DETECTED
icon hm-sec-win@black
stateFormat {"Status: ".ReadingsVal($name,"state" ,"")." / LastOpen: ".ReadingsVal("HMCCU3","Balkontuer_auf","")." / LastClose: ".ReadingsVal("HMCCU3","Balkontuer_zu","")}
statedatapoint 1.STATE
substitute STATE!0:closed,1:tilted,2:open;ERROR!0:no,1:sabotage
userReadings LastOpen:hmstate.* {ReadingsVal("HMCCU3","Balkontuer_auf","")},LastClose:hmstate.* {ReadingsVal("HMCCU3","Balkontuer_zu","")}
Viele Grüße
Jürgen
Ah ja, die Rolle ist noch nicht bekannt. Trage ich nach.
Hallo zap,
anbei ein paar weitere Problemchen.
- Schalter (HM-LC-Sw1PBU-FM und HmIP-BSM) werden nicht korrekt angelegt. Beim Versuch diesen zu schalten, kommt die Meldung "Unknown argument control, choose one of clear defaults:noArg datapoint rpcparameter config datapoint toggle:noArg on-for-timer on-till "
Hier das dazugehörige list:
Internals:
CFGFN
DEF OEQ0625708
FUUID 5e932f83-f33f-4885-12f5-ad345349b460a6ad
IODev HMCCU3
NAME HM_LC_Sw1PBU_FM_OEQ0625708
NR 1072
STATE false
TYPE HMCCUDEV
ccuaddr OEQ0625708
ccudevstate active
ccuif BidCos-RF
ccuname HM-LC-Sw1PBU-FM OEQ0625708
ccutype HM-LC-Sw1PBU-FM
readonly no
OLDREADINGS:
READINGS:
2020-04-12 17:15:36 1.STATE false
2020-04-12 17:15:36 activity alive
2020-04-12 17:15:36 battery ok
2020-04-12 17:15:36 control false
2020-04-12 17:15:36 devstate stickyUnreach
2020-04-12 17:15:36 hmstate false
2020-04-12 17:15:36 state false
hmccu:
channels 2
devspec OEQ0625708
control:
chn 1
dpt STATE
dp:
0.AES_KEY:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.DUTYCYCLE:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.LOWBAT:
VALUES:
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
VALUES:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
0.RSSI_PEER:
VALUES:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
0.STICKY_UNREACH:
VALUES:
OSVAL true
OVAL true
SVAL 1
VAL 1
0.UNREACH:
VALUES:
OSVAL dead
OVAL 1
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
1.INHIBIT:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
1.STATE:
VALUES:
OSVAL true
OVAL 1
SVAL false
VAL 0
1.WORKING:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
state:
chn 1
dpt STATE
Attributes:
IODev HMCCU3
ccureadingfilter STATE
controldatapoint 1.STATE
room Homematic
statedatapoint 1.STATE
statevals on:true,off:false
substitute STATE!(true|1):on,(false|0):off
webCmd control
widgetOverride control:uzsuToggle,off,onWenn man "control" durch toggle ersetzt, funktioniert es zumindest teilweise. Über on/off geht über die Lampe geht nicht. Hier kommt die Meldung "Invalid datapoint". Das gleiche gilt für die "Mess-Steckdose" (HM-ES-PMSw1-Pl-DN-R1).
Auch die Daten für den Klingelsensor (HM-Sen-DB-PCB) passen nicht. Hier das list:
Internals:
DEF NEQ0956261
FUUID 5c435f29-f33f-4885-08c0-d71aec0289a46d72
IODev HMCCU3
NAME HM_Sen_DB_PCB_NEQ0956261
NR 158
STATE 08.04.2020 - 18:40:39
TYPE HMCCUDEV
ccuaddr NEQ0956261
ccudevstate active
ccuif BidCos-RF
ccuname HM_Sen_DB_PCB_NEQ0956261
ccutype HM-Sen-DB-PCB
readonly no
READINGS:
2020-04-11 20:10:30 0.AES_KEY off
2020-04-11 20:10:30 0.CONFIG_PENDING false
2020-04-11 20:10:30 0.DEVICE_IN_BOOTLOADER false
2019-01-11 22:05:25 0.LOWBAT ok
2020-04-11 20:10:30 0.RSSI_DEVICE 1
2020-04-11 20:10:30 0.RSSI_PEER 1
2020-04-11 20:10:30 0.STICKY_UNREACH false
2019-01-11 22:05:25 0.UNREACH alive
2020-04-11 20:10:30 0.UPDATE_PENDING false
2020-04-08 18:40:39 1.INSTALL_TEST 1
2020-04-12 15:16:30 activity alive
2020-04-12 15:16:30 battery ok
2020-04-12 15:16:30 devstate ok
2020-04-12 15:16:30 hmstate Initialized
2020-04-08 18:40:39 klingeln 1
2020-01-05 15:16:40 state Initialized
hmccu:
channels 2
devspec NEQ0956261
role 0:MAINTENANCE,1:KEY
control:
chn 1
dpt PRESS_SHORT
dp:
0.AES_KEY:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.LOWBAT:
VALUES:
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
VALUES:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
0.RSSI_PEER:
VALUES:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
0.STICKY_UNREACH:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.UNREACH:
VALUES:
OSVAL alive
OVAL false
SVAL alive
VAL false
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
state:
chn 1
dpt PRESS_SHORT
Attributes:
IODev HMCCU3
alias HM Klingelsensor
ccureadingname ^(.+\.)?PRESS_SHORT?:klingeln
devStateStyle style="text-align:right"
event-min-interval battery:3600
group Statusinformationen
icon Wecker.Aus
room Flur,Homematic,Statuszentrale
sortby 07
stateFormat {ReadingsTimestamp($name,"klingeln","") =~ /^(\d+)-(\d+)-(\d+)\s(\d+:\d+:\d+)$/; return "$3.$2.$1 - $4";}Ich testen nun die nächsten Geräte 8)
Viele Grüße
Jürgen
Das sind alles HMCCUDEV Devices. Vielleicht ein systematischer Fehler in diesem Modul. Ich schaue mir das erst mal an, bevor du zu viel Zeit ins Testen investierst
Update: Kannst Du für den Klingelsensor bitte die Ausgabe von "get deviceinfo" posten?
Und für das andere Gerät bitte die Ausgabe von "get devicedesc".
gerne ;D
Hier der Klingelsensor:
CHN NEQ0956261:0 HM_Sen_DB_PCB_NEQ0956261:0
DPT {b} BidCos-RF.NEQ0956261:0.UNREACH = false [RE]
DPT {b} BidCos-RF.NEQ0956261:0.STICKY_UNREACH = false [RWE]
DPT {b} BidCos-RF.NEQ0956261:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.NEQ0956261:0.LOWBAT = false [RE]
DPT {n} BidCos-RF.NEQ0956261:0.RSSI_DEVICE = 1 [RE]
DPT {n} BidCos-RF.NEQ0956261:0.RSSI_PEER = 1 [RE]
DPT {b} BidCos-RF.NEQ0956261:0.DEVICE_IN_BOOTLOADER = false [RE]
DPT {b} BidCos-RF.NEQ0956261:0.UPDATE_PENDING = false [RE]
DPT {n} BidCos-RF.NEQ0956261:0.AES_KEY = 0 [R]
CHN NEQ0956261:1 HM_Sen_DB_PCB_NEQ0956261:1
DPT {b} BidCos-RF.NEQ0956261:1.PRESS_SHORT = [WE]
DPT {b} BidCos-RF.NEQ0956261:1.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0956261:1.PRESS_CONT = [E]
StateDatapoint = 1.PRESS_SHORT
ControlDatapoint = 1.PRESS_SHORT
Anbei die Info für die Schaltsteckdose:
Device NEQ1662710 HM_ES_PMSw1_Pl_DN_R1_NEQ1662710 [HM-ES-PMSw1-Pl-DN-R1]
CHILDREN: NEQ1662710:0,NEQ1662710:1,NEQ1662710:2,NEQ1662710:3,NEQ1662710:4,NEQ1662710:5,NEQ1662710:6
FIRMWARE: 2.6
FLAGS: Visible
INTERFACE: PEQ1950749
PARAMSETS: MASTER
RF_ADDRESS: 5410176
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG
UPDATABLE: 1
Channel NEQ1662710:0 HM_ES_PMSw1_Pl_DN_R1_NEQ1662710:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: NEQ1662710
PARENT_TYPE: HM-ES-PMSw1-Pl-DN-R1
Channel NEQ1662710:1 HM Funksteckdose Bad [SWITCH]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: NEQ1662710
PARENT_TYPE: HM-ES-PMSw1-Pl-DN-R1
Channel NEQ1662710:2 HM_ES_PMSw1_Pl_DN_R1_NEQ1662710:2 [POWERMETER]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES
PARENT: NEQ1662710
PARENT_TYPE: HM-ES-PMSw1-Pl-DN-R1
Channel NEQ1662710:3 HM_ES_PMSw1_Pl_DN_R1_NEQ1662710:3 [CONDITION_POWER]
AES_ACTIVE: 0
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: KEYMATIC,SWITCH,WINMATIC
PARAMSETS: LINK,MASTER,VALUES
PARENT: NEQ1662710
PARENT_TYPE: HM-ES-PMSw1-Pl-DN-R1
Channel NEQ1662710:4 HM_ES_PMSw1_Pl_DN_R1_NEQ1662710:4 [CONDITION_CURRENT]
AES_ACTIVE: 0
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: KEYMATIC,SWITCH,WINMATIC
PARAMSETS: LINK,MASTER,VALUES
PARENT: NEQ1662710
PARENT_TYPE: HM-ES-PMSw1-Pl-DN-R1
Channel NEQ1662710:5 HM_ES_PMSw1_Pl_DN_R1_NEQ1662710:5 [CONDITION_VOLTAGE]
AES_ACTIVE: 0
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: KEYMATIC,SWITCH,WINMATIC
PARAMSETS: LINK,MASTER,VALUES
PARENT: NEQ1662710
PARENT_TYPE: HM-ES-PMSw1-Pl-DN-R1
Channel NEQ1662710:6 HM_ES_PMSw1_Pl_DN_R1_NEQ1662710:6 [CONDITION_FREQUENCY]
AES_ACTIVE: 0
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: KEYMATIC,SWITCH,WINMATIC
PARAMSETS: LINK,MASTER,VALUES
PARENT: NEQ1662710
PARENT_TYPE: HM-ES-PMSw1-Pl-DN-R1
Anbei die Info für den HM-Schalter:
evice OEQ0625708 HM-LC-Sw1PBU-FM OEQ0625708 [HM-LC-Sw1PBU-FM]
CHILDREN: OEQ0625708:0,OEQ0625708:1
FIRMWARE: 2.8
FLAGS: Visible
INTERFACE: PEQ1950749
PARAMSETS: MASTER
RF_ADDRESS: 6000987
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG
UPDATABLE: 1
Channel OEQ0625708:0 HM-LC-Sw1PBU-FM OEQ0625708:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: OEQ0625708
PARENT_TYPE: HM-LC-Sw1PBU-FM
Channel OEQ0625708:1 Lichtschalter Kammer [SWITCH]
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: OEQ0625708
PARENT_TYPE: HM-LC-Sw1PBU-FM
Hier die Info vom HM-IP-Schalter:
Device 000858A9ABDF0E HmIP-BSM 000858A9ABDF0E [HmIP-BSM]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 000858A9ABDF0E:0,000858A9ABDF0E:1,000858A9ABDF0E:2,000858A9ABDF0E:3,000858A9ABDF0E:4,000858A9ABDF0E:5,000858A9ABDF0E:6,000858A9ABDF0E:7,000858A9ABDF0E:8,000858A9ABDF0E:9
DIRECTION: NONE
FIRMWARE: 1.12.6
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 7857971
ROAMING: 0
RX_MODE:
SUBTYPE: BSM
UPDATABLE: 1
Channel 000858A9ABDF0E:0 HmIP-BSM 000858A9ABDF0E:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:1 HmIP-BSM 000858A9ABDF0E:1 [KEY_TRANSCEIVER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:2 HmIP-BSM 000858A9ABDF0E:2 [KEY_TRANSCEIVER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:3 HmIP-BSM 000858A9ABDF0E:3 [SWITCH_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:4 Lichtschalter B�ro [SWITCH_VIRTUAL_RECEIVER]
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,REMOTE_CONTROL,LEVEL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:5 HmIP-BSM 000858A9ABDF0E:5 [SWITCH_VIRTUAL_RECEIVER]
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,REMOTE_CONTROL,LEVEL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:6 HmIP-BSM 000858A9ABDF0E:6 [SWITCH_VIRTUAL_RECEIVER]
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,REMOTE_CONTROL,LEVEL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:7 HmIP-BSM 000858A9ABDF0E:7 [ENERGIE_METER_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:8 HmIP-BSM 000858A9ABDF0E:8 [COND_SWITCH_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:9 HmIP-BSM 000858A9ABDF0E:9 [SWITCH_WEEK_PROFILE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Viele Grüße
Jürgen
Das Problem ist: ich habe den control Befehl wegrationalisiert und damit die Abwärtskompatibilität gekillt. War keine gute Idee. Baue ich wieder ein.
Hallo zap,
es fehlt an der ein oder anderen Stelle auch der Bateriestatus (z.B. Fensterkontakte HMIP-SWDO).
Viele Grüße
Jürgen
So, habe auch wieder einmal etwas angesehen. Ich wollte einmal die RTs ansehen. Wie auch bei den IP Schaltern kann man hier wochenprogramme eingeben. Die rohwerte hierzu gibst du alle aus. So kann es aber fast keiner überhaupt lesen. Es ist notwendig hier eine tabellarische Ausgabe zu machen. Auch muss man nicht die komplette Liste ausgeben. Es reicht abzubrechen, wenn der terminierungswert erkannt ist. Es soll ja ein userintrface werden. Auch für die Eingabe muss etwas erstellt werden.
Ja, ich weiß :)
Ich hatte mich in den letzten Tagen / Wochen v.a. auf die Anpassung von HMCCUDEV an HMCCUCHN konzentriert. In den nächsten Tagen gibt es ein Update, das den set control Befehl zurückbringt. Sonst müssen allen Nutzer ihre Devices neu konfigurieren. Wird allerdings nicht mehr in der Dropdown Liste angezeigt. Ich denke mal über eine automatische Migration nach.
Dann hätte ich mal Zeit, mich mit benutzerfreundlichen Aus- und Eingaben zu beschäftigen.
Ich kann dir bei Bedarf einmal beispiele schicken, wie Ausgaben bei CUL_HM aussehen. Natürlich sind die Voraussetzungen leicht unterschiedliche, die Werte allerdings nicht.
Servus zusammen,
ich würde ja gern mit folgender HM-Gerätelandschaft
HM-CC-RT-DN
HM-ES-PMSW1-DR
HM-ES-PMSW1-PL
HM-LC-DIM1PWM-CV
HM-LC-SW1-FM
HM-LC-SW1-PL-CT-R1
HM-LC-SW1-PL2
HM-LC-SW2-FM
HM-LC-SW4-DR
HM-MOD-EM-8
HM-MOD-RE-8
HM-PB-2-WM55
HM-PB-6-WM55
HM-RC-4-3
HM-SEC-SCO
HM-WDS10-TH-O
beim Test von HMCCU 4.4 unterstützen aber aktuell nutze ich noch
CUL_HM wo leider der HM-CFG-LAN langsam das zeitliche segnet.
Daher hatte ich letzte Woche mal begonne HMCCU auf einen Test-System zu testen.
(Noch Version 4.3)
Der Raspberry Pi auf dem der Test gestartet wurde ist leider eine Heizung geworden.
Im Leerlauf steigt die CPU-Temperatur auf 85°C. (Hardware-Defekt)
Damit fällt der Test bis zum eintreffen vom neuen Raspberry Pi aus.
Wenn ich von Euch noch etwas geleitet werde, ist es vielleicht als Wechseler / Neueinsteiger
in HMCCU einfacher die komplette HM-Welt in Verson 4.4 abzubilden. Ich muss ja scheinbar eh
alle FHEM Aufgabe / DOIF anpassen.
Also wenn ich mit meinem Wissen was testen soll, einfach melden.
Zitat von: martinp876 am 18 April 2020, 08:06:27
Ich kann dir bei Bedarf einmal beispiele schicken, wie Ausgaben bei CUL_HM aussehen. Natürlich sind die Voraussetzungen leicht unterschiedliche, die Werte allerdings nicht.
Das Angebot nehme ich gerne an. Ein Beispiel für die tabellarische Darstellung der Heizprogramme würde mir helfen. Mittlerweile speichert HMCCU die Heizprogramme in IT-gerechter Form im Hash der Client-Devices. Jetzt fehlt noch die Darstellung.
Es gibt mal wieder ein Update für die 4.4 Beta. Bitte alle Module in contrib/HMCCU/FHEM aktualisieren.
- Der Code für den internen RPC Server wurde entfernt. Dadurch ist HMCCU.pm um mehr als 2000 Zeilen "leichter" geworden
- HMCCUCHN und HMCCUDEV unterstützen nun wieder den "set control" Befehl. Allerdings nur per Kommandozeile, nicht per UI in der Dropdown-Liste auswählbar
- Es gab noch ein Problem mit dem Befehl "get config" bzw. "get values" bei HMCCUDEV Devices
Hinweis zur manuellen Aktualisierung von Readings:
- Der Befehl get config aktualisiert die Readings der Gerätekonfiguration. Diese werden über den RPC Server nicht automatisch aktualisiert. Damit die Werte tatsächlich als Reading auftauchen, muss im Attribut ccuflags eines oder mehrere der Flags showMasterReadings, showLinkReadings, showDeviceReadings gesetzt sein (Bedeutung der Flags siehe Commandref zu HMCCUCHN).
- Der Befehl get values aktualisiert nur die Datenpunkte (werden normalerweise vom RPC Server automatisch aktualisiert)
- Der Befehl get update aktualisiert Datenpunkte und Gerätekonfiguration.
Servus Zap,
so ich habe oder vesuche gerade bei meiner Mama die 4.4 Beta-Version zum laufen zu bekommen.
Was vielleicht an mir oder meinen Rechner liegt, wenn ich versuche deine Dateien zu laden sind die um Faktor 1000 zu groß (MB statt kB)
Daher habe ich das Raw gewählt, kopiert und auf dem Raspberry geladen.
Scheinbar fuktioniert HMCCU auch Geräte wurden gefunden. Die Einrichtung habe ich über den CCU-Namen durchgeführt.
Leider schaltet aber kein Gerät oder der Status wird nicht verändert.
Kann ich irgendwo direkt auf die Fehler suche gehen
oder kann ich die Kommunikation zwischen CCU und Fhem überprüfen?
Danke
Hm, da stimmt mit dem Download etwas nicht. Aber warte mal mit dem Testen. Ich aktualisiere die Dateien im Laufe der Woche
Hallo Zap,
bin dabei meine ersten HMIP-Geräte einzubinden. Funktioniert mit der Beta ganz gut.
Aber das Reading "1.desired-temp" läßt sich mit dem Attribut ccureadingname nicht umbenennen. Absicht?
Bei den großgeschriebenen Readings "1.XXX" funktioniert das umbennen.
vg Jens
Zitat von: Newbie am 29 Mai 2020, 14:40:46
Hallo Zap,
bin dabei meine ersten HMIP-Geräte einzubinden. Funktioniert mit der Beta ganz gut.
Aber das Reading "1.desired-temp" läßt sich mit dem Attribut ccureadingname nicht umbenennen. Absicht?
Bei den großgeschriebenen Readings "1.XXX" funktioniert das umbennen.
vg Jens
Die aktuelle Beta im SVN hat schon noch einige Bugs. Ich habe gerade eine deutlich stabilere Version im Test. Wollte ich eigentlich heute schon hochladen, bin aber mit dem Testen noch nicht durch.
Du kannst nur die original Datenpunkte umbenennen. Also SET_TEMPERATURE statt desired-temp.
Hallo Zap,
beim Versuch ein HMCCUDEV-Device zu löschen stürzt FHEM sofort ab.
Auch mit Verbose 3 steht im Log-File nur das:
Undefined subroutine &main::HMCCUCHN_Undef called at fhem.pl line 3789.
HMCCUCHN-Device sind keine definiert, FHEM ist tagesaktuell.
Diese Funktion hatte ich versehentlich gelöscht. Du kannst schon mal einen Blick auf das kommende Update werfen, das ich gerade teste. Kann jetzt auch per FHEM update installiert werden:
update https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
Hallo zap,
mit diesem update-Befehl kommt bei mir :
Downloading https://fhem.de/fhemupdate/controls_fhem.txt
nothing to do...
Viele Grüße
Jürgen
Möglicherweise muss man doch eine andere Syntax verwenden. Was kommt bei
update check https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
Gerade mal nachgelesen. Folgendes müsste funktionieren:
update all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
Downloading https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
List of new / modified files since last update:
UPD FHEM/88_HMCCURPCPROC.pm
UPD FHEM/HMCCUConf.pm
UPD FHEM/88_HMCCUCHN.pm
UPD FHEM/88_HMCCU.pm
UPD FHEM/88_HMCCUDEV.pm
New entries in the CHANGED file:
404: Not Found
Viele Grüße
Jürgen
update all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
Hallo zap,
Test kann beginnen :)
Nach dem ersten restart gab es diese Meldungen:
020.05.31 15:30:32 1: Messages collected while initializing FHEM:configfile: HMCCU3: unknown attribute ccudef-readingname. Type 'attr HMCCU3 ?' for a detailed list.
HM_ES_PMSw1_Pl_DN_R1_NEQ1662710: unknown attribute ccureadings. Type 'attr HM_ES_PMSw1_Pl_DN_R1_NEQ1662710 ?' for a detailed list.
Autosave deactivated
2020.05.31 15:30:32 0: HMCCU:1039 [HMCCU3 : 3876] Scheduling post FHEM initialization tasks in 12 seconds
Ansonsten sieht es erst einmal gut aus.
Viele Grüße
Jürgen
und schon geht es los:
Der Befehl
set HM_MOD_Re_8_OEQ0206895_5 on-for-timer 0.5
liefert folgende Fehlermeldung:
2020.05.31 15:34:34 1: HMCCUCHN:2568 [HM_MOD_Re_8_OEQ0206895_5 : 3876] HMCCUCHN: HM_MOD_Re_8_OEQ0206895_5 Wrong time format. Use seconds or HH:MM[:SS]
Alles andere sieht gut aus. Respekt!
Viele Grüße
Jürgen
Danke für's Feedback. Das Attribut ccudef-readingname habe ich entsorgt. Kann also ignoriert werden. HMCCU sucht sich seine Standard Readingnames jetzt anhand der erkannten Kanalrollen selbst zusammen.
Das Attribut ccureadingname in den einzelnen Devices gibt es natürlich weiterhin.
Der Fehler bei on-for-timer ist soweit auch klar. Vermutlich akzeptiert der Befehl keine Zahlen mit Dezimalteil. Korrigiere ich.
Hallo Zap,
Update eingespielt. Gruppen aus der CCU(Debmatik) werden nicht übernommen
ZitatCan't create device Bad_Heizung_INT0000004. No devices in group
Devices wurden alle übernommen, einige Reading-Namen bedürfen wohl noch ein bisschen Kosmetik z.B:
Zitatdesired-temp_0-9_1
1.PARTY_2_._ACTUAL_HUMIDITY_
oder muss das so?
Device löschen geht auch mit dieser Version nicht
Wie sehen denn die Attribute von dem Device mit den komischen Readingnames aus?
Kannst Du mal folgendes versuchen (für dieses Device):
set xy clear
get xy values
set xy clear
get xy values
danach sieht es dann so aus
defmod WZ_Thermostat HMCCUDEV XXXXXXXXXXXX
attr WZ_Thermostat IODev myccu
attr WZ_Thermostat alias Wohnzimmer
attr WZ_Thermostat ccureadingfilter .*
attr WZ_Thermostat cmdIcon auto:sani_heating_automatic manu:sani_heating_manual boost:sani_heating_boost on:general_an off:general_aus
attr WZ_Thermostat controldatapoint 1.SET_POINT_TEMPERATURE
attr WZ_Thermostat event-on-change-reading .*
attr WZ_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 WZ_Thermostat genericDeviceType thermostat
attr WZ_Thermostat room Debmatic
attr WZ_Thermostat statedatapoint 1.SET_POINT_TEMPERATURE
attr WZ_Thermostat stripnumber 1
attr WZ_Thermostat substexcl control
attr WZ_Thermostat substitute SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;;WINDOW_STATE!(0|false):closed,(1|true):open
attr WZ_Thermostat webCmd desired-temp:auto:manu:boost
attr WZ_Thermostat widgetOverride desired-temp:slider,4.5,0.5,30.5,1
setstate WZ_Thermostat 17.5
setstate WZ_Thermostat 2020-05-31 22:14:01 .0.CONFIG_PENDING false
setstate WZ_Thermostat 2020-05-31 22:12:37 .0.DUTY_CYCLE false
setstate WZ_Thermostat 2020-05-31 22:12:37 .0.LOW_BAT ok
setstate WZ_Thermostat 2020-05-31 22:12:37 .0.OPERATING_VOLTAGE 2.8
setstate WZ_Thermostat 2020-05-31 22:12:37 .0.OPERATING_VOLTAGE_STATUS NORMAL
setstate WZ_Thermostat 2020-05-31 22:14:01 .0.RSSI_DEVICE -88
setstate WZ_Thermostat 2020-05-31 22:12:37 .0.RSSI_PEER -88
setstate WZ_Thermostat 2020-05-31 22:14:01 .0.UNREACH alive
setstate WZ_Thermostat 2020-05-31 22:12:37 .0.UPDATE_PENDING true
setstate WZ_Thermostat 2020-05-31 22:12:37 1.ACTIVE_PROFILE 1
setstate WZ_Thermostat 2020-05-31 22:12:37 1.ACTUAL_TEMPERATURE 22.2
setstate WZ_Thermostat 2020-05-31 22:12:37 1.ACTUAL_TEMPERATURE_STATUS NORMAL
setstate WZ_Thermostat 2020-05-31 22:12:37 1.BOOST_MODE false
setstate WZ_Thermostat 2020-05-31 22:12:37 1.BOOST_TIME 0
setstate WZ_Thermostat 2020-05-31 22:12:37 1.FROST_PROTECTION false
setstate WZ_Thermostat 2020-05-31 22:12:37 1.HEATING_COOLING HEATING
setstate WZ_Thermostat 2020-05-31 22:12:37 1.HUMIDITY 42
setstate WZ_Thermostat 2020-05-31 22:12:37 1.HUMIDITY_STATUS NORMAL
setstate WZ_Thermostat 2020-05-31 22:12:37 1.PARTY_MODE false
setstate WZ_Thermostat 2020-05-31 22:12:37 1.QUICK_VETO_TIME 0
setstate WZ_Thermostat 2020-05-31 22:12:37 1.SET_POINT_MODE 1
setstate WZ_Thermostat 2020-05-31 22:12:37 1.SWITCH_POINT_OCCURED false
setstate WZ_Thermostat 2020-05-31 22:12:37 1.WINDOW_STATE closed
setstate WZ_Thermostat 2020-05-31 22:12:37 2_._ACTUAL_HUMIDITY_ 17.5
setstate WZ_Thermostat 2020-05-31 22:14:01 activity alive
setstate WZ_Thermostat 2020-05-31 22:14:01 battery ok
setstate WZ_Thermostat 2020-05-31 22:12:37 control 17.5
setstate WZ_Thermostat 2020-05-31 22:12:37 desired-temp_0-9_1 17.5
setstate WZ_Thermostat 2020-05-31 22:14:01 devstate updPending
setstate WZ_Thermostat 2020-05-31 22:14:01 hmstate 17.5
setstate WZ_Thermostat 2020-05-31 22:12:37 measured-temp 22.2
setstate WZ_Thermostat 2020-05-31 22:12:37 state 17.5
Attribute wurden mit "set defaults" angelegt
Kannst Du mal bitte versuchen, ein identisches Device anzulegen:
define ThermostatTest HMCCUDEV XXXXXXXXX
Kein 'set defaults' ausführen. Die werden automatisch ermittelt (hoffentlich).
Danach mal die Readings abrufen
get ThermostatTest values
Und danach einmal
list ThermostatTest
Die Ausgabe vom letzten Befehl wäre interessant.
get WZ_Test values:
Device 000XXXXXXXXX
Channel 0 [VALUES]
CONFIG_PENDING = false
DUTY_CYCLE = false
LOW_BAT = ok
OPERATING_VOLTAGE = 2.8
OPERATING_VOLTAGE_STATUS = NORMAL
RSSI_DEVICE = -86
RSSI_PEER = -88
UNREACH = alive
UPDATE_PENDING = true
Channel 1 [VALUES]
ACTIVE_PROFILE = 1
ACTUAL_TEMPERATURE = 21.0
ACTUAL_TEMPERATURE_STATUS = NORMAL
BOOST_MODE = false
BOOST_TIME = 0
FROST_PROTECTION = false
HEATING_COOLING = HEATING
HUMIDITY = 44
HUMIDITY_STATUS = NORMAL
PARTY_MODE = false
QUICK_VETO_TIME = 0
SET_POINT_MODE = 1
SET_POINT_TEMPERATURE = 17.5
SWITCH_POINT_OCCURED = false
WINDOW_STATE = closed
list WZ_Test:
Internals:
DEF 000XXXXXXXX
FUUID 5ed4e2e5-f33f-df36-cb0e-c2a583545acdc19b
IODev myccu
NAME WZ_Test
NR 295
STATE 21.0
TYPE HMCCUDEV
ccuaddr 000XXXXXXXX
ccudevstate active
ccuif HmIP-RF
ccuname WZ_Thermostat
ccutype HmIP-WTH-2
readonly no
receiver WZ_Ventil_Rechts,WZ_Ventil_Links,WZ_Ventil_Rechts,WZ_Ventil_Links,WZ_Ventil_Rechts,WZ_Ventil_Links
sender WZ_Ventil_Rechts,WZ_Ventil_Links
Helper:
DBLOG:
measured-temp:
logdb:
TIME 1591010155.98907
VALUE 21.0
READINGS:
2020-06-01 13:15:55 1.ACTIVE_PROFILE 1
2020-06-01 13:15:55 1.ACTUAL_TEMPERATURE 21.0
2020-06-01 13:15:55 1.ACTUAL_TEMPERATURE_STATUS NORMAL
2020-06-01 13:15:55 1.BOOST_MODE false
2020-06-01 13:15:55 1.BOOST_TIME 0
2020-06-01 13:15:55 1.FROST_PROTECTION false
2020-06-01 13:15:55 1.HEATING_COOLING HEATING
2020-06-01 13:15:55 1.HUMIDITY 44
2020-06-01 13:15:55 1.HUMIDITY_STATUS NORMAL
2020-06-01 13:13:41 1.PARTY_2_._ACTUAL_HUMIDITY_ 0.0
2020-06-01 13:15:55 1.PARTY_MODE false
2020-06-01 13:13:41 1.PARTY_TIME_END
2020-06-01 13:13:41 1.PARTY_TIME_START
2020-06-01 13:15:55 1.QUICK_VETO_TIME 0
2020-06-01 13:15:55 1.SET_POINT_MODE 1
2020-06-01 13:15:55 1.SWITCH_POINT_OCCURED false
2020-06-01 13:15:55 1.WINDOW_STATE closed
2020-06-01 13:15:55 2_._ACTUAL_HUMIDITY_ 17.5
2020-06-01 13:15:55 activity alive
2020-06-01 13:15:55 battery ok
2020-06-01 13:15:55 control 17.5
2020-06-01 13:15:55 desired-temp_0-9_1 17.5
2020-06-01 13:15:55 devstate updPending
2020-06-01 13:15:55 hmstate 21.0
2020-06-01 13:15:55 measured-temp 21.0
2020-06-01 13:15:55 state 21.0
hmccu:
channels 8
cmdlist boost:noArg manu:noArg desired-temp auto:noArg holiday:noArg on:noArg off:noArg
devspec 000A9A49A6B256
role 0:MAINTENANCE,1:HEATING_CLIMATECONTROL_TRANSCEIVER,2:HEATING_CLIMATECONTROL_RECEIVER,3:HEATING_CLIMATECONTROL_CL_TRANSMITTER,4:HEATING_SHUTTER_CONTACT_RECEIVER,5:HEATING_CLIMATECONTROL_SWITCH_TRANSMITTER,6:HEATING_KEY_RECEIVER,7:CLIMATECONTROL_FLOOR_TRANSMITTER
control:
chn 1
dpt SET_POINT_TEMPERATURE
dp:
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL 0
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.LOW_BAT:
VALUES:
OSVAL ok
OVAL false
SVAL ok
VAL 0
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 2.8
OVAL 2.800000
SVAL 2.8
VAL 2.8
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -86
OVAL -86
SVAL -86
VAL -86
0.RSSI_PEER:
VALUES:
OSVAL 168
OVAL 168
SVAL -88
VAL -88
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL 1
1.ACTIVE_PROFILE:
VALUES:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.ACTUAL_TEMPERATURE:
VALUES:
OSVAL 21.0
OVAL 21.000000
SVAL 21.0
VAL 21.0
1.ACTUAL_TEMPERATURE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.BOOST_MODE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
1.BOOST_TIME:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.FROST_PROTECTION:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL 0
1.HEATING_COOLING:
VALUES:
OSVAL HEATING
OVAL 0
SVAL HEATING
VAL 0
1.HUMIDITY:
VALUES:
OSVAL 44
OVAL 44
SVAL 44
VAL 44
1.HUMIDITY_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.PARTY_MODE:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL 0
1.PARTY_SET_POINT_TEMPERATURE:
VALUES:
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
1.PARTY_TIME_END:
VALUES:
OSVAL
OVAL
SVAL
VAL
1.PARTY_TIME_START:
VALUES:
OSVAL
OVAL
SVAL
VAL
1.QUICK_VETO_TIME:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.SET_POINT_MODE:
VALUES:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.SET_POINT_TEMPERATURE:
VALUES:
OSVAL 17.5
OVAL 17.500000
SVAL 17.5
VAL 17.5
1.SWITCH_POINT_OCCURED:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL 0
1.WINDOW_STATE:
VALUES:
OSVAL closed
OVAL 0
SVAL closed
VAL 0
roleCmds:
auto:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:CONTROL_MODE:0
usage auto
subcmd:
000:
args 0
dpt CONTROL_MODE
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
unit
boost:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:BOOST_MODE:1
usage boost
subcmd:
000:
args 1
dpt BOOST_MODE
max 1
min 0
parname BOOST_MODE
partype 3
ps VALUES
unit
desired-temp:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:SET_POINT_TEMPERATURE:?temperature
usage desired-temp temperature
subcmd:
000:
args 4.5
dpt SET_POINT_TEMPERATURE
max 30.5
min 4.5
parname temperature
partype 2
ps VALUES
unit �C
holiday:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:CONTROL_MODE:2
usage holiday
subcmd:
000:
args 2
dpt CONTROL_MODE
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
unit
manu:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:CONTROL_MODE:1
usage manu
subcmd:
000:
args 1
dpt CONTROL_MODE
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
unit
off:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 2
syntax V:CONTROL_MODE:1 V:SET_POINT_TEMPERATURE:4.5
usage off
subcmd:
000:
args 1
dpt CONTROL_MODE
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
unit
001:
args 4.5
dpt SET_POINT_TEMPERATURE
max 30.5
min 4.5
parname SET_POINT_TEMPERATURE
partype 3
ps VALUES
unit �C
on:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 2
syntax V:CONTROL_MODE:1 V:SET_POINT_TEMPERATURE:30.5
usage on
subcmd:
000:
args 1
dpt CONTROL_MODE
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
unit
001:
args 30.5
dpt SET_POINT_TEMPERATURE
max 30.5
min 4.5
parname SET_POINT_TEMPERATURE
partype 3
ps VALUES
unit �C
state:
chn 1
dpt ACTUAL_TEMPERATURE
Attributes:
IODev myccu
cmdIcon auto:sani_heating_automatic manu:sani_heating_manual boost:sani_heating_boost on:general_an off:general_aus
webCmd desired-temp:auto:manu:boost
widgetOverride desired-temp:slider,4.5,0.5,30.5,1
Sieht soweit gut aus. Ich kann mir allerdings nicht erklären, wo dieses seltsame Reading ACTUAL_HUMIDITY her kommt.
Auf Github gibt's eine neue Version.
- Der Fehler bei on-for-timer ist behoben. Der Befehl akzeptiert nun auch Dezimalzahlen
- Der Befehl "set defaults" hat nun 2 Optionen: Mit "reset" werden vorhandene Attribute gelöscht, sofern sie nicht mehr erforderlich sind. Mit "update" werden lediglich Attribute aktualisiert oder hinzugefügt. Empfehlenswert ist "reset", default ist "update"
Installation mit
update all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
Hallo zap,
on-for-timer funktioniert nun. Allerdings ist mir aufgefallen, dass der Status bei dem Türdrehgriff jetzt in Großbuchstaben kommt. Bisher war dies immer in Kleinbuchstaben. Anbei der Vergleich:
neu:
nternals:
DEF NEQ1477040
FUUID 5c435f29-f33f-4885-0d55-cc25f5a636d92568
IODev HMCCU3
NAME HM_Sec_RHS_NEQ1477040
NR 158
STATE Status: OPEN / LastOpen: 02.06.2020 - 20:33:52 / LastClose: 02.06.2020 - 20:21:47
TYPE HMCCUDEV
ccuaddr NEQ1477040
ccudevstate active
ccuif BidCos-RF
ccuname HM_Sec_RHS_NEQ1477040
ccutype HM-Sec-RHS
readonly no
OLDREADINGS:
READINGS:
2020-06-02 21:23:08 1.ERROR NO_ERROR
2020-06-02 21:23:08 1.LOWBAT ok
2020-06-02 21:23:08 1.STATE OPEN
2020-06-02 21:22:01 LastClose 02.06.2020 - 20:21:47
2020-06-02 21:22:01 LastOpen 02.06.2020 - 20:33:52
2020-06-02 21:23:08 activity alive
2020-06-02 21:23:08 battery ok
2020-06-02 21:23:08 control 2
2020-06-02 21:23:08 devstate ok
2020-06-02 21:23:08 hmstate OPEN
2020-06-02 21:23:08 state OPEN
alt:
Internals:
DEF NEQ1477040
FUUID 5c50be57-f33f-ca7c-fb5f-a2a2f253ab770d4c
IODev HMCCU3
NAME HM_Sec_RHS_NEQ1477040
NR 158
STATE Status: open / LastOpen: 02.06.2020 - 20:33:52 / LastClose: 02.06.2020 - 20:21:47
TYPE HMCCUDEV
ccuaddr NEQ1477040
ccudevstate active
ccuif BidCos-RF
ccuname HM_Sec_RHS_NEQ1477040
ccutype HM-Sec-RHS
channels 2
firmware 2.4
statevals devstate
READINGS:
2020-06-01 17:12:55 0.AES_KEY off
2020-06-01 17:12:55 0.CONFIG_PENDING false
2020-06-01 17:12:55 0.RSSI_DEVICE 1
2020-06-01 17:12:55 0.RSSI_PEER 1
2020-06-01 17:12:55 0.STICKY_UNREACH false
2020-06-01 17:12:55 1.ERROR no
2020-06-02 20:33:52 1.STATE open
2020-06-02 20:33:52 LastClose 02.06.2020 - 20:21:47
2020-06-02 20:33:52 LastOpen 02.06.2020 - 20:33:52
2020-04-27 21:29:38 R-CYCLIC_INFO_MSG 1
2020-04-27 21:29:38 R-SABOTAGE_MSG 1
2020-04-27 21:29:38 R-TRANSMIT_DEV_TRY_MAX 6
2020-06-01 17:12:55 activity alive
2020-06-02 20:33:52 battery ok
2020-06-02 20:33:52 control open
2020-06-02 20:33:52 hmstate open
2020-06-02 20:33:52 state open
Diese beiden Meldungen habe ich noch im Log gefunden.
2020.06.02 20:47:05 1: PERL WARNING: Use of uninitialized value $type in exists at ./FHEM/88_HMCCU.pm line 3973.
2020.06.02 20:47:05 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/88_HMCCU.pm line 3975.
Viele Grüße
Jürgen
Wegen OPEN: Bitte mal folgenden Befehl ausführen:
get HM_Sec_RHS_NEQ1477040 paramsetDesc
Wegen den beiden Log-Meldungen: Das nächste Update enthält einige Erweiterungen, damit bei diesem Fehler mehr Informationen über das auslösende Gerät ausgegeben werden.
Update: Neue Version im Git verfügbar und unter contrib/HMCCU/FHEM im SVN.
Hallo zap,
anbei die gewünschte Info:
device
Paramset MASTER
CYCLIC_INFO_MSG: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SABOTAGE_MSG: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=1
TRANSMIT_DEV_TRY_MAX: INTEGER [R,W] [Visible,Sticky] RANGE=1...10 DFLT=6
Channel 0
Paramset VALUES
AES_KEY: INTEGER [R] [] RANGE=0...127 DFLT=0
CONFIG_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
LOWBAT: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
RSSI_DEVICE: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648...2147483647 DFLT=0
RSSI_PEER: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648...2147483647 DFLT=0
STICKY_UNREACH: BOOL [R,W,E] [Sticky,Internal] RANGE=0...1 DFLT=0
UNREACH: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
Channel 1
Paramset LINK
EXPECT_AES: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
PEER_NEEDS_BURST: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
Paramset MASTER
AES_ACTIVE: BOOL [R,W] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
EVENT_DELAYTIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...7620 DFLT=0 UNIT=s
LED_ONTIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...1.275 DFLT=0.5 UNIT=s
MSG_FOR_POS_A: ENUM [R,W] [Visible,Sticky] RANGE=0...3 DFLT=1 VALUES=NO_MSG,CLOSED,OPEN,TILTED
MSG_FOR_POS_B: ENUM [R,W] [Visible,Sticky] RANGE=0...3 DFLT=2 VALUES=NO_MSG,CLOSED,OPEN,TILTED
MSG_FOR_POS_C: ENUM [R,W] [Visible,Sticky] RANGE=0...3 DFLT=3 VALUES=NO_MSG,CLOSED,OPEN,TILTED
TRANSMIT_TRY_MAX: INTEGER [R,W] [Visible,Sticky] RANGE=1...10 DFLT=6
Paramset VALUES
ERROR: ENUM [R,E] [Visible,Sticky,Service] RANGE=0...7 DFLT=0 VALUES=NO_ERROR,,,,,,,SABOTAGE
INSTALL_TEST: ACTION [E] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
LOWBAT: BOOL [R,E] [Visible,Sticky] RANGE=0...1 DFLT=0
STATE: ENUM [R,E] [Visible,Sticky] RANGE=0...2 DFLT=0 VALUES=CLOSED,TILTED,OPEN
Die Unterschiede zu bisher:
alt: open closed tilted
neu: OPEN closed open
Viele Grüße
Jürgen
Das habe ich vermutet: wenn Du Dir die Definition von STATE in der letzten Zeile anschaust, siehst Du, dass es sich um einen ENUM Typ handelt. HMCCU übernimmt in diesem Fall die Werte von der CCU Konfiguration. Auch diese stehen in besagter Zeile. Das hat den Vorteil, dass man sich ausufernde Substitute Attribute spart, die noch in 4.3 notwendig waren. Nachteil: man muss die Werte so übernehmen wie sie sind. Wenn Du die alten Werte haben möchtest, kannst Du mit substitute diese explizit festlegen
attr xy substitute STATE!0:closed,1:tilted,2:open
Hallo zap,
das ist aber schon so vorhanden ???
defmod HM_Sec_RHS_NEQ1477040 HMCCUDEV NEQ1477040
attr HM_Sec_RHS_NEQ1477040 IODev HMCCU3
attr HM_Sec_RHS_NEQ1477040 alexaName Balkontür
attr HM_Sec_RHS_NEQ1477040 alias Balkontür
attr HM_Sec_RHS_NEQ1477040 devStateStyle style="text-align:right"
attr HM_Sec_RHS_NEQ1477040 event-min-interval battery:3600
attr HM_Sec_RHS_NEQ1477040 event-on-change-reading .*
attr HM_Sec_RHS_NEQ1477040 genericDeviceType contact
attr HM_Sec_RHS_NEQ1477040 group HM Fenster-/Türkontakte
attr HM_Sec_RHS_NEQ1477040 hmstatevals ERROR!1:sabotage
attr HM_Sec_RHS_NEQ1477040 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED;;tilted:CONTACT_NOT_DETECTED
attr HM_Sec_RHS_NEQ1477040 icon hm-sec-win@black
attr HM_Sec_RHS_NEQ1477040 stateFormat {"Status: ".ReadingsVal($name,"state" ,"")." / LastOpen: ".ReadingsVal("HMCCU3","Balkontuer_auf","")." / LastClose: ".ReadingsVal("HMCCU3","Balkontuer_zu","")}
attr HM_Sec_RHS_NEQ1477040 statedatapoint 1.STATE
attr HM_Sec_RHS_NEQ1477040 substitute STATE!0:closed,1:tilted,2:open;;ERROR!0:no,1:sabotage
attr HM_Sec_RHS_NEQ1477040 userReadings LastOpen:hmstate.* {ReadingsVal("HMCCU3","Balkontuer_auf","")},LastClose:hmstate.* {ReadingsVal("HMCCU3","Balkontuer_zu","")}
Viele Grüße
Jürgen
Ok, das Attribut sollte Priorität haben. Also ein Bug.
Kannst Du bitte die Ausgabe von
get deviceDesc
hier posten? Dann lernt HMCCU den Devicetyp kennen
Bitteschön
Device NEQ1477040 HM_Sec_RHS_NEQ1477040 [HM-Sec-RHS]
CHILDREN: NEQ1477040:0,NEQ1477040:1
FIRMWARE: 2.4
FLAGS: Visible
INTERFACE: PEQ1950749
PARAMSETS: MASTER
RF_ADDRESS: 5305185
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG
UPDATABLE: 0
Channel NEQ1477040:0 HM_Sec_RHS_NEQ1477040:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: NEQ1477040
PARENT_TYPE: HM-Sec-RHS
Channel NEQ1477040:1 HM_Sec_RHS_NEQ1477040:1 [ROTARY_HANDLE_SENSOR]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: KEYMATIC,SWITCH,WINDOW_SWITCH_RECEIVER,WINMATIC
PARAMSETS: LINK,MASTER,VALUES
PARENT: NEQ1477040
PARENT_TYPE: HM-Sec-RHS
Viele Grüße
Jürgen
Danke, ich habe nun noch etwas bei der Ersetzung der Werte korrigiert (noch nicht im Git verfügbar).
Bis heute Abend werde ich es hochladen.
Zitat von: zap am 04 Juni 2020, 08:58:05
Danke, ich habe nun noch etwas bei der Ersetzung der Werte korrigiert (noch nicht im Git verfügbar).
Bis heute Abend werde ich es hochladen.
Gibt es noch Probleme ::)
Viele Grüße
Jürgen
Ja ;)
Neues Update verfügbar mit diversen Bug Fixes.
- Ersetzung von Reading Werten korrigiert
- Bei Verwendung von HMCCUDEV wird nun eine Fehlermeldung ausgegeben, wenn der Steuerkanal nicht automatisch identifiziert werden kann. In diesem Fall muss beim Define eine Kanalnummer angegeben werden
Installation:
update all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
Oder Download von:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/HMCCU/FHEM
Hallo Zusammen,
wie gesagt würde ich gern mit der Version 4.4 starten anstatt nun alles auf Version 4.3 umzuschreiben und dann ggf. wieder anfangen zu müssen.
Vielleicht passt die Frage nicht hierher aber schalten kann ich scheinbar Gerät aus dem FHEM heraus.
Leider passiert bei der FHEM-Anzeige oder Reading nichts.
Ist das wieder ein Schicht 8-Fehler oder jemand eine Idee
Danke
Zitat von: aherby am 09 Juni 2020, 18:18:25
Hallo Zusammen,
wie gesagt würde ich gern mit der Version 4.4 starten anstatt nun alles auf Version 4.3 umzuschreiben und dann ggf. wieder anfangen zu müssen.
Vielleicht passt die Frage nicht hierher aber schalten kann ich scheinbar Gerät aus dem FHEM heraus.
Leider passiert bei der FHEM-Anzeige oder Reading nichts.
Ist das wieder ein Schicht 8-Fehler oder jemand eine Idee
Danke
Die Infos sind jetzt etwas knapp gehalten, um zu verstehen, was da schief geht oder nicht funktioniert.
Zitat von: zap am 09 Juni 2020, 13:26:18
Neues Update verfügbar mit diversen Bug Fixes.
Hallo zap,
bei mir waren alle Tests erfolgreich. Passt!
Viele Grüße
Jürgen
Servus,
ja sorry mein Hauptsystem macht gerade (über das Funkmodul) nichts mehr da war die Nachricht für über das Testsystem
etwas kurz.
Ich habe glaube ich das Testsystem am 1 Juni "eingerichtet" aber auch vorhin noch erneut das Update vom HMCCU 4.4038 eingespielt.
Die Funktion schalte Geräte xy ein / aus über FHEM hat funktioniert. Nur die Readings bleiben auf 2020-06-01-xxx stehen.
attr d_ccu ccureadings 1
aus dem Best Practice ist ja entfernt worden oder?
attr d_ccu event-on-change-reading .*
muss man event-on-change-reading .* auch noch bei jedem Gerät setzen?
Wobei ich jetzt zusätzlich das "Problem" habe, dass die Kommunikation von den Geräten zu CCU gestört ist / wird.
Beispielsweise will ich gerade das HM-Gerät vom Typ: "HM-LC-Sw1-Pl-2" anlernen, steuern oder einfach angezeigt bekommen.
Sorry die Umstellung von HMLAN auf HMCCU fällt mir aus welchen Gründen auch immer nicht leicht.
Mein Ziel ist es ja die folgenden Gerätetypen:
HM-CC-RT-DN
HM-ES-PMSW1-DR
HM-ES-PMSW1-PL
HM-LC-DIM1PWM-CV
HM-LC-SW1-FM
HM-LC-SW1-PL-CT-R1
HM-LC-SW1-PL2
HM-LC-SW2-FM
HM-LC-SW4-DR
HM-MOD-EM-8
HM-MOD-RE-8
HM-PB-2-WM55
HM-PB-6-WM55
HM-RC-4-3
HM-SEC-SCO
HM-WDS10-TH-O
von HMLAN auf HMCCU umzustellen....
Ist ggf. wer aus der Nähe von Kassel hier?
Ich glaube ich benötige mal einen Experten, der mir bei der cfg hilft oder mir den Fehler direkt vor Augen präsentiert :(
Gruß aherby
Die Attribute event-on-change-reading oder event-on-update-reading sind FHEM Standardattribute. Sie müssen / können für jedes Device separat gesetzt werden.
Bitte lies den HMCCU Wiki Artikel: https://wiki.fhem.de/wiki/HMCCU
Insbesondere den RPC-Server und den Firewall Teil.
Hallo,
gibt es eigentlich Einschränkungen wenn man den Web-Port der CCU / Debmatic von
Port 80 auf 8070, 8090 oder so ändert?
kannst du eigentlich diesen Punkt als Config mit aufnehmen oder ist es unnötig?
Zitat von: aherby am 14 Juni 2020, 21:56:13
Hallo,
gibt es eigentlich Einschränkungen wenn man den Web-Port der CCU / Debmatic von
Port 80 auf 8070, 8090 oder so ändert?
kannst du eigentlich diesen Punkt als Config mit aufnehmen oder ist es unnötig?
Nein, der Web-Port wird von HMCCU nicht verwendet.
Hallo Zusammen,
da ich mich langsam an HMCCU gewöhne will ich nun alle Geräte neu einbinden.
Ich dachte erst mit den einzelnen Kanälen komme ich besser zurecht. Daher bei x-Wandtaster die einzelnen Tasten der Geräte mit HMCCCHN und leider nur ein Wandtaster als Gerät unter Version 4.4.038 angelegt.
Aber jetzt in der Verson 4.4.040
kommt gefühlt immer die Fehlermeldung:
Control channel ambiguous. Please specify control channel in device definition
Wie ist die genaue Syntax?
Beispiel:
define Badtaster1 HMCCUDEV KEQxxxxxxx
Die betroffenen Gerätetypen sind:
- HM-PB-2-WM55
- HM-PB-6-WM55
Nun, für die Syntax könnte es sich lohnen, mal einen Blick in die (lokal installierte) Commandref zu werfen ;)
Wenn Du einen Taster mit mehreren Schaltkanälen hast, musst Du HMCCUDEV sagen, welcher dieser Kanäle bei bestimmten Befehlen verwendet werden soll.
Beispiel: Du hast eine 4-Kanal Fernbedienung. Um einen Tastendruck zu simulieren, kannst Du dann folgendes schreiben (vorausgesetzt, Tasten werden über PRESS gesteuert)
set xy datapoint 1.PRESS 1
set xy datapoint 2.PRESS 1
usw.
Ohne controldatapoint wird aber folgendes nicht funktionieren
set xy press
Denn woher soll HMCCUDEV wissen, welchen der 4 Kanäle es schalten soll?
Hallo Zap,
Dankeschön :)
Mit einem Wandtaster 2 fach (HM-PB-2-WM55) oder 6 fach (HM-PB-6-WM55) habe ich ja meine Notify oder DOIF umgesetzt bekommen, wenn ich
den Wandtaster als HMCCUDEV
define Badtaster1 HMCCUDEV KEQxxxxxxx in FHEM bekannt gemacht habe.
(War unter Version 4.4.038)
Aber bei mir ist seit der Verson 4.4.040 das definieren mit dem oben dargestellten Code nicht mehr möglich.
Dann kommt die Fehlermeldung:
Zitat
Control channel ambiguous. Please specify control channel in device definition
Daher bin ich kurz zurück auf die Version 4.3.xx habe mit :
define Badtaster1 HMCCUDEV KEQxxxxxxx
den Badwandtaster definiert (Ohne Fehler) und kann Ihn jetzt in der Version 4.4.040 verwenden.
Hier schalte ich ja noch nichts
Das liegt daran, dass die 4.4 so gebaut ist, dass man auf spezielle Attribute wie zB controldatapoint oder statedatapoint verzichten kann. Wenn möglich, ermittelt HMCCU die entsprechenden Werte selbst.
Mal sehen, vielleicht werfe ich diese Fehlermeldung beim define wieder raus und lasse sie später bei set Befehlen anzeigen.
Bis dahin kannst Du Dir behelfen, indem Du an das Define noch eine vorhandene Kanalnummer anhängst (mit Leerzeichen zwischen Adresse und Kanalnummer.
Hallo zap,
ich habe noch einen Bug gefunden ;D.
Bei den IP-Fensterkontakten erhalte ich folgende Meldungen:
2020.06.23 21:25:33 2: HMCCU [HMCCU3] Can't get type of 0000DA498D425C:1:VALUES:PRESS_SHORT
2020.06.23 21:25:45 2: HMCCU [HMCCU3] Can't get type of 0000DA498D425C:1:VALUES:PRESS_SHORT
2020.06.23 21:31:02 2: HMCCU [HMCCU3] Can't get type of 0000DA498D4303:1:VALUES:PRESS_SHORT
Hier ein List:
Internals:
DEF 0000DA498D425C
FUUID 5eb5aac2-f33f-4885-63c9-6f9add9a9f24471f
IODev HMCCU3
NAME HMIP_SWDO_0000DA498D425C
NR 338
STATE Status: closed / LastOpen: 23.06.2020 - 21:25:33 / LastClose: 23.06.2020 - 21:25:45
TYPE HMCCUDEV
ccuaddr 0000DA498D425C
ccudevstate active
ccuif HmIP-RF
ccuname HMIP-SWDO 0000DA498D425C
ccutype HMIP-SWDO
readonly no
OLDREADINGS:
READINGS:
2020-06-23 21:25:45 1.PRESS_SHORT 1
2020-06-23 21:40:16 1.STATE closed
2020-06-23 21:25:45 LastClose 23.06.2020 - 21:25:45
2020-06-23 21:25:45 LastOpen 23.06.2020 - 21:25:33
2020-06-23 21:40:16 activity alive
2020-06-23 21:40:16 battery ok
2020-06-23 21:40:16 control closed
2020-06-23 21:40:16 devstate ok
2020-06-23 21:40:16 hmstate closed
2020-06-23 21:40:16 state closed
hmccu:
channels 3
cmdlist
devspec 0000DA498D425C
nodefaults 1
role 0:MAINTENANCE,1:SHUTTER_CONTACT,2:ALARM_COND_SWITCH_TRANSMITTER
semDefaults 0
control:
chn 1
dpt STATE
dp:
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.LOW_BAT:
VALUES:
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 1.4
OVAL 1.4
SVAL 1.4
VAL 1.4
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -50
OVAL -50
SVAL -61
VAL -61
0.RSSI_PEER:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.SABOTAGE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
1.PRESS_SHORT:
VALUES:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.STATE:
VALUES:
OSVAL closed
OVAL 0
SVAL closed
VAL 0
roleCmds:
state:
chn 1
dpt STATE
Attributes:
IODev HMCCU3
alias Bürofenster
devStateStyle style="text-align:right"
event-min-interval battery:3600
event-on-change-reading .*
genericDeviceType contact
group HM Fenster-/Türkontakte
hmstatevals ERROR!7:sabotage;SABOTAGE!1:sabotage
homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;open:CONTACT_NOT_DETECTED
icon hm-sec-win@black
room GoogleAssistant
sortby 02
stateFormat {"Status: ".ReadingsVal($name,"state" ,"")." / LastOpen: ".ReadingsVal("HMCCU3","Fenster_Buero_auf","")." / LastClose: ".ReadingsVal("HMCCU3","Fenster_Buero_zu","")}
statedatapoint 1.STATE
substitute STATE!(0|false):closed,(1|true):open
userReadings LastOpen:hmstate.* {ReadingsVal("HMCCU3","Fenster_Buero_auf","")},LastClose:hmstate.* {ReadingsVal("HMCCU3","Fenster_Buero_zu","")}
Viele Grüße
Jürgen
Hmm, was macht der Fensterkontakt mit einem PRESS_SHORT?
Das gibt es dort nicht, bzw. sollte es nicht geben ;D
Viele Grüße
Jürgen
Führe für das Device bitte mal folgende Befehle aus:
get deviceinfo
get paramsetdesc
Ergänzung: Die Fehlermeldung wird im nächsten Update nicht mehr drin sein. Die Ursache ist damit allerdings nicht behoben.
Hallo zap,
anbei die gewünschten Infos:
CHN 0000DA498D4303:0 HMIP-SWDO 0000DA498D4303:0
DPT {b} HmIP-RF.0000DA498D4303:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.0000DA498D4303:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.0000DA498D4303:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.0000DA498D4303:0.INSTALL_TEST = true [RW]
DPT {b} HmIP-RF.0000DA498D4303:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.0000DA498D4303:0.OPERATING_VOLTAGE = 1.400000 [RE]
DPT {i} HmIP-RF.0000DA498D4303:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.0000DA498D4303:0.RSSI_DEVICE = 190 [RE]
DPT {n} HmIP-RF.0000DA498D4303:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.0000DA498D4303:0.SABOTAGE = false [RE]
DPT {b} HmIP-RF.0000DA498D4303:0.UNREACH = false [RE]
DPT {b} HmIP-RF.0000DA498D4303:0.UPDATE_PENDING = false [RE]
CHN 0000DA498D4303:1 HMIP-SWDO 0000DA498D4303:1
DPT {i} HmIP-RF.0000DA498D4303:1.STATE = 0 [RE]
StateDatapoint = 1.STATE
ControlDatapoint = 1.STATE
Device
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Channel 0
Paramset MASTER
ARR_TIMEOUT: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=10
CYCLIC_INFO_MSG: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=1
CYCLIC_INFO_MSG_DIS: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=20
CYCLIC_INFO_MSG_DIS_UNCHANGED: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
CYCLIC_INFO_MSG_OVERDUE_THRESHOLD: INTEGER [R,W] [Visible,Sticky] RANGE=0...2147483647 DFLT=2
DISABLE_MSG_TO_AC: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
DUTYCYCLE_LIMIT: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=180
ENABLE_ROUTING: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=1
LOCAL_RESET_DISABLED: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
LOW_BAT_LIMIT: FLOAT [R,W] [Visible,Sticky] RANGE=0...25.2 DFLT=1.1 UNIT=V
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Paramset VALUES
CONFIG_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
DUTY_CYCLE: BOOL [R,E] [Visible,Sticky] RANGE=0...1 DFLT=0
ERROR_CODE: INTEGER [R,E] [Visible,Sticky,Service] RANGE=0...255 DFLT=0
INSTALL_TEST: BOOL [R,W] [Internal] RANGE=0...1 DFLT=0
LOW_BAT: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
OPERATING_VOLTAGE: FLOAT [R,E] [Visible,Sticky] RANGE=0...25.2 DFLT=0
OPERATING_VOLTAGE_STATUS: ENUM [R,E] [Visible,Sticky] RANGE=NORMAL...OVERFLOW DFLT=NORMAL VALUES=NORMAL,UNKNOWN,OVERFLOW
RSSI_DEVICE: INTEGER [R,E] [Visible,Sticky] RANGE=-128...127 DFLT=0
RSSI_PEER: INTEGER [R,E] [Visible,Sticky] RANGE=-128...127 DFLT=0
SABOTAGE: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
UNREACH: BOOL [R,E] [Sticky,Internal] RANGE=0...1 DFLT=0
UPDATE_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
Channel 1
Paramset MASTER
EVENT_DELAY_UNIT: ENUM [R,W] [Visible,Sticky] RANGE=100MS...H DFLT=100MS VALUES=100MS,S,M,H
EVENT_DELAY_VALUE: INTEGER [R,W] [Visible,Sticky] RANGE=0...63 DFLT=0
MSG_FOR_POS_A: ENUM [R,W] [Visible,Sticky] RANGE=NO_MSG...OPEN DFLT=OPEN VALUES=NO_MSG,CLOSED,OPEN
MSG_FOR_POS_B: ENUM [R,W] [Visible,Sticky] RANGE=NO_MSG...OPEN DFLT=CLOSED VALUES=NO_MSG,CLOSED,OPEN
SAMPLE_INTERVAL: FLOAT [R,W] [Visible,Sticky] RANGE=0.1...25.5 DFLT=0.5
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Paramset VALUES
STATE: ENUM [R,E] [Visible,Sticky] RANGE=CLOSED...OPEN DFLT=CLOSED UNIT="" VALUES=CLOSED,OPEN
Channel 2
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Viele Grüße
Jürgen
Wie erwartet kein PRESS_SHORT weit und breit. Das ist wirklich krass.
Ich habe eine Idee.
Den Eintrag gab es schon unter 4.3. Ich lösche einmal die Readings und lasse diese neu anlegen.
Und schon passt alles. ;D
Eventuell sollten die Devices beim Upgrade ein "set clear" durchlaufen.
Viele Grüße
Jürgen
Hallo zap,
und schon ist das Reading wieder vorhanden :(
Ich habe den genericDeviceType geändert. Das ist wohl der Auslöser. Vielleicht hilft Dir das bei der Suche.
Viele Grüße
Jürgen
Hallo,
ich habe jetzt nochmal geschaut den Wandtaster vom Typ
ZitatHM-PB-6-WM55
definiert zu bekommen.
Der Taster wird erkannt aber scheinbar nur die Readings
"n.INSTALL_TEST" zurückgegeben.
Unter oder nach
set BadTaster1 deviceInfo werden z. B. folgende Infos angezeigt:
Zitat
DPT {b} BidCos-RF.KEQ0xxxxx2:1.PRESS_SHORT = [WE]
DPT {b} BidCos-RF.KEQ0xxxxx2:1.PRESS_LONG = [WE]
DPT {b} BidCos-RF.KEQ0xxxxx2:1.INSTALL_TEST = false [E]
DPT {b} BidCos-RF.KEQ0xxxxx2:1.PRESS_CONT = [E]
DPT {b} BidCos-RF.KEQ0xxxxx2:1.PRESS_LONG_RELEASE = [E]
Somit kann ich scheinbar eine Abfrage auf langen oder kurzen Tastendruck nicht abfragen.
Was ich in der CCU festgestellt habe ist, dass die Firmare vom Taster die Version 1.1 ist.
Alle andere Wandtaster vom Typ
ZitatHM-PB-6-WM55
haben die Version 1.2
Ist die Firmware die Ursache vom Anlern- / Definierungs- und Readingproblem?
Gruß aherby
Ich würde Dir schon empfehlen, die Firmware zu aktualisieren. Hat aber nichts mit Deinem Problem zu tun.
Wie bei den meisten Tastern musst Du in der CCU ein Dummy Programm erstellen, das die Tasten abfragt (aber nichts macht). Nur dann sendet die CCU die Events der Tasten an FHEM.
Hier ist es beschrieben (einige Beiträge nach unten scrollen) https://forum.fhem.de/index.php/topic,51339.msg650563.html#msg650563
Und Du musst event-on-update-reading auf .* oder PRESS setzen.
Dankeschön,
Ein Firmware-Update kann ich nicht machen da ich die Firmware nicht finde oder für CCU3 angeboten wird.
Das mit den Dummy in der CCU ist aber umständlich. Naja.
Alle anderen Taster melden direkt ohne Programm an FHEM nur der besagt eben nicht.
Jetzt mit zwei Programmen auf zwei Virtuelle HM-Geräte verknüpft und funktioniert.
Dankeschön
Ich kann da leider nichts machen, das ist ein EQ3 Problem
Zitat von: juemuc am 24 Juni 2020, 20:54:03
Hallo zap,
und schon ist das Reading wieder vorhanden :(
Ich habe den genericDeviceType geändert. Das ist wohl der Auslöser. Vielleicht hilft Dir das bei der Suche.
Viele Grüße
Jürgen
Hallo zap,
kannst Du mit dieser Info etwas anfangen? Das gleiche passiert auch unter 4.3. Benötigst Du mehr Infos?
Viele Grüße
Jürgen
Ich kann mir nicht vorstellen, dass der genericDeviceType das Reading PRESS_SHORT generiert. HMCCU ignoriert dieses Attribut.
Hallo zap.
Du hast recht. Ich kann es wie folgt reproduzieren:
Keine "Filter" !
1. set clear => als Readings sind nur control und state vorhanden.
2. get update => nun sind die Readings 1.STATE, LastClose, LastOpen, activity, battery, control, devstate, hmstate und state vorhanden.
3. Irgendein Attribut z.B. room verändert und schon ist 1.PRESS_SHORT mit dem Wert 1 vorhanden.
Viele Grüße
Jürgen
Das Setzen eines Attributs erzwingt die Aktualisierung aller Readings aus dem internen Speicher. Wenn Du nach einem set clear ein list vom Device machst, dürfte das PRESS_SHORT in der Ausgabe auftauchen.
Ich müsste also set clear erweitern, damit es auch die internen Werte löscht.
Du kannst mal folgendes versuchen: entweder das Device löschen und neu anlegen oder set clear ausführen und dann FHEM neu starten.
Hallo zap,
Du hast recht. Ich habe nach dem set clear FHEM neu gestartet und alles ist ok. Die Änderungen der Attribute zaubern das 1.PRESS_SHORT nicht mehr hervor. ;D
Eine Erweiterung des set clearf wäre super.
Viele Grüße
Jürgen
Hallo,
ich habe das Problem mit dem Reading:
Zitatbattery
nach einem
set clear hat ein festeingebautes HM-Gerät keine Reading
Zitatbattery
mehr.
selbst nach einem
shutdown restart oder
sudo invoke-rc.d fhem stop
sudo invoke-rc.d fhem start
Kommen die Readings wieder >:(
Gibt es eine andere Möglichkeit das zu definieren oder bei Geräten mit Netzspannung das komplett nicht auszuwerten?
Wäre es möglich eine Art "Config-Datei" einzubauen wo man für jeden Gerätetyp
attr ...
reading ... yes / no
definieren kann?
HMCCU Version 4.4.040
Du hast also ein Gerät, das am Stromnetz hängt, aber trotzdem ein Reading "battery" anzeigt? Kannst Du bitte mal ein "list" von diesem Geräte machen und vielleicht noch ein "get deviceinfo" ?
Hallo zap,
das sind die Schaltaktoren (ohne IP).
Hier ein List
Internals:
DEF OEQ0625708
FUUID 5c435f29-f33f-4885-e938-de27f08aed40b44c
IODev HMCCU3
NAME HM_LC_Sw1PBU_FM_OEQ0625708
NR 172
STATE off
TYPE HMCCUDEV
ccuaddr OEQ0625708
ccudevstate active
ccuif BidCos-RF
ccuname HM-LC-Sw1PBU-FM OEQ0625708
ccutype HM-LC-Sw1PBU-FM
readonly no
receiver HM_LC_Sw1PBU_FM_OEQ0625708 [SENDER_BROKEN],HM_LC_Sw1PBU_FM_OEQ0625708 [SENDER_BROKEN]
sender OEQ0625708:2,HM_LC_Sw1PBU_FM_OEQ0625708 [SENDER_BROKEN]
READINGS:
2020-06-29 11:02:29 1.STATE off
2020-06-29 11:02:29 activity alive
2020-06-29 11:02:29 battery ok
2020-06-29 11:02:29 control off
2020-06-29 11:02:29 devstate stickyUnreach
2020-06-29 11:02:29 hmstate off
2020-06-29 11:02:29 state off
hmccu:
channels 2
cmdlist off:noArg on-till on-for-timer on:noArg toggle:noArg
devspec OEQ0625708
nodefaults 1
role 0:MAINTENANCE,1:SWITCH
semDefaults 0
control:
chn 1
dpt STATE
dp:
0.AES_KEY:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.DUTYCYCLE:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.LOWBAT:
VALUES:
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
VALUES:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
0.RSSI_PEER:
VALUES:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
0.STICKY_UNREACH:
VALUES:
OSVAL true
OVAL 1
SVAL true
VAL true
0.UNREACH:
VALUES:
OSVAL alive
OVAL false
SVAL alive
VAL false
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
1.INHIBIT:
VALUES:
OSVAL unlocked
OVAL false
SVAL unlocked
VAL false
1.STATE:
VALUES:
OSVAL off
OVAL false
SVAL off
VAL false
1.WORKING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
roleCmds:
off:
channel 1
role SWITCH
subcount 1
syntax V:STATE:0
usage off
subcmd:
000:
args 0
dpt STATE
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on:
channel 1
role SWITCH
subcount 1
syntax V:STATE:1
usage on
subcmd:
000:
args 1
dpt STATE
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on-for-timer:
channel 1
role SWITCH
subcount 2
syntax V:ON_TIME:?duration V:STATE:1
usage on-for-timer duration
subcmd:
000:
args 0.000000
dpt ON_TIME
max 85825945.600000
min 0.000000
parname duration
partype 2
ps VALUES
unit s
001:
args 1
dpt STATE
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on-till:
channel 1
role SWITCH
subcount 2
syntax V:ON_TIME:?duration V:STATE:1
usage on-till duration
subcmd:
000:
args 0.000000
dpt ON_TIME
max 85825945.600000
min 0.000000
parname duration
partype 2
ps VALUES
unit s
001:
args 1
dpt STATE
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
state:
chn 1
dpt STATE
Attributes:
IODev HMCCU3
alias HM Funkschalter Kammer
assistantName Licht Kammer
ccureadingfilter STATE
controldatapoint 1.STATE
devStateStyle style="text-align:right"
event-on-change-reading .*
group HM Funkschalter
icon li_wht_dimmer
room Alexa,GoogleAssistant,Homematic,Kammer,Schaltzentrale,Statuszentrale
sortby 09
statedatapoint 1.STATE
statevals on:true,off:false
userattr Schalter Schalter_map structexclude
webCmd :
und get deviceinfo
CHN OEQ0625708:0 HM-LC-Sw1PBU-FM OEQ0625708:0
DPT {b} BidCos-RF.OEQ0625708:0.UNREACH = false [RE]
DPT {b} BidCos-RF.OEQ0625708:0.STICKY_UNREACH = true [RWE]
DPT {b} BidCos-RF.OEQ0625708:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.OEQ0625708:0.LOWBAT = false [RE]
DPT {b} BidCos-RF.OEQ0625708:0.DUTYCYCLE = false [RE]
DPT {n} BidCos-RF.OEQ0625708:0.RSSI_DEVICE = 1 [RE]
DPT {n} BidCos-RF.OEQ0625708:0.RSSI_PEER = 1 [RE]
DPT {b} BidCos-RF.OEQ0625708:0.DEVICE_IN_BOOTLOADER = false [RE]
DPT {b} BidCos-RF.OEQ0625708:0.UPDATE_PENDING = false [RE]
DPT {n} BidCos-RF.OEQ0625708:0.AES_KEY = 0 [R]
CHN OEQ0625708:1 Lichtschalter Kammer
DPT {b} BidCos-RF.OEQ0625708:1.STATE = false [RWE]
DPT {f} BidCos-RF.OEQ0625708:1.ON_TIME = [W]
DPT {b} BidCos-RF.OEQ0625708:1.INHIBIT = false [RWE]
DPT {b} BidCos-RF.OEQ0625708:1.INSTALL_TEST = [W]
DPT {b} BidCos-RF.OEQ0625708:1.WORKING = false [RE]
StateDatapoint = 1.STATE
ControlDatapoint = 1.STATE
Viele Grüße
Jürgen
Hallo zap,
ich wollte heute einen neuen IP-Schalter definieren und bin kläglich gescheitert :(
Ein create ^HmIP.* t=dev save room=Homematic liefert:
Can't create device HmIP_BSM_00085A49A3F759. Control channel ambiguous. Please specify control channel in device definition
Can't create device HmIP_RCV_50_001F58A9A72C1D. Control channel ambiguous. Please specify control channel in device definition
Created 0 client devices
Auch über defmod kann ich das Device aus 4.3 nicht übernehmen. Hier erhalte ich die Meldung:
Control channel ambiguous. Please specify control channel in device definition
Viele Grüße
Jürgen
HMCCUDEV versucht beim Define den Schaltkanal und -datenpunkt zu erkennen. Wenn ein Gerät mehrere gleiche Kanäle hat, die alle als Schaltkanal in Frage kommen, geht das schief. In diesem Fall muss man entweder die Kanalnummer als Parameter mitgeben oder das Attribut controldatapoint setzen. Leider habe ich da einen Denkfehler drin, denn wenn man das Device nicht definieren kann, kann man auch kein Attribut setzen.
Ich werde die Fehlermeldung in ein Warning verwandeln. Bis ich das korrigiert habe, bleibt Dir nur, beim Define die Nummer des Schaltkanals anzugeben. Also etwa so
define myDev HMCCUDEV DevAddress 5
In dem Fall wäre 5 der Schaltkanal.
Hallo zap,
danke. Damit hat es funktioniert. Wenn Du noch Infos benötigst, bitte melden.
Viele Grüße
Jürgen
Hallo Zusammen,
hat einer von Euch einen funktionierende Config für den HM-LC-Dim1PWM-CV?
Bei mir steht im "Level", "pct" und "control" immer auf "off".
"LEVEL_REAL" auf "0" oder "1".
Sobald ist z.B.:
set WZ_Dimmer2 pct 13
geht der Dimmer auf "100%"
Bei dem List steht der Dimmer auf 50%
Internals:
CFGFN
DEF MEQ0344xxx:1
FUUID 5f426c08-f33f-94da-f189-3a57f6d5ccc369a5
IODev d_ccu
NAME Wz_Dimmer2
NR 932
STATE off
TYPE HMCCUCHN
ccuaddr MEQ0344xxx:1
ccudevstate active
ccuif BidCos-RF
ccuname Wz_Dimmer2_CH1_HM_MEQ0344xxx:1
ccutype HM-LC-Dim1PWM-CV
readonly no
receiver Wz_Dimmer2 [SENDER_BROKEN],ccu:Wz_Dimmer2_HMMEQ0344xxx [SENDER_BROKEN],ccu:Wz_Dimmer2_HMMEQ0344xxx [SENDER_BROKEN]
sender Wz_Dimmer2 [SENDER_BROKEN]
OLDREADINGS:
READINGS:
2020-08-24 06:56:54 DIRECTION stop
2020-08-24 06:56:54 ERROR_OVERHEAT false
2020-08-24 06:56:54 ERROR_REDUCED false
2020-08-24 06:55:13 INHIBIT unlocked
2020-08-24 06:56:54 LEVEL off
2020-08-24 06:56:54 LEVEL_REAL 0
2020-08-24 06:56:54 WORKING false
2020-08-24 06:56:54 activity alive
2020-08-24 06:56:54 control off
2020-08-24 06:56:54 devstate stickyUnreach
2020-08-24 06:56:54 hmstate off
2020-08-24 06:56:54 pct 0
2020-08-24 06:56:54 state off
hmccu:
channels 1
cmdlist on:noArg stop:noArg pct off:noArg
devspec MEQ0344xxx:1
nodefaults 0
role 1:DIMMER
semDefaults 0
control:
chn 1
dpt LEVEL
dp:
0.AES_KEY:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.DUTYCYCLE:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.RSSI_DEVICE:
VALUES:
OSVAL 128
OVAL 128
SVAL 128
VAL 128
0.RSSI_PEER:
VALUES:
OSVAL 188
OVAL 188
SVAL 188
VAL 188
0.STICKY_UNREACH:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
Da das "list" so lang ist, sind leider die Attribute nicht dabei. Kannst Du bitte nur die Attribute posten?
Servus,
habe gerade den Dimmer als DEV neu angelegt, da sind die Attribute folgende:
define Wz_Dimmer2DEV HMCCUDEV MEQ0344xxx
attr Wz_Dimmer2DEV IODev d_ccu
attr Wz_Dimmer2DEV substexcl pct
attr Wz_Dimmer2DEV webCmd pct
attr Wz_Dimmer2DEV widgetOverride pct:slider,0,10,100
jetzt schon erweitert um:
substitute LEVEL!#0-0:off,#100-100:on
oder
ccuscaleval LEVEL!#0-0:off,#100-100:on
sowie die Attribute mit "1.LEVEL..." getestet
Beim Dimmer eingerichtet über HMCCUCHN sehen die DevieInfo so aus:
CHN MEQ0344xxx:0 Wz_Dimmer2_HMMEQ0344xxx:0
DPT {b} BidCos-RF.MEQ0344xxx:0.UNREACH = false [RE]
DPT {b} BidCos-RF.MEQ0344xxx:0.STICKY_UNREACH = true [RWE]
DPT {b} BidCos-RF.MEQ0344xxx:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.MEQ0344xxx:0.DUTYCYCLE = false [RE]
DPT {n} BidCos-RF.MEQ0344xxx:0.RSSI_DEVICE = 128 [RE]
DPT {n} BidCos-RF.MEQ0344xxx:0.RSSI_PEER = 188 [RE]
DPT {b} BidCos-RF.MEQ0344xxx:0.DEVICE_IN_BOOTLOADER = false [RE]
DPT {b} BidCos-RF.MEQ0344xxx:0.UPDATE_PENDING = false [RE]
DPT {n} BidCos-RF.MEQ0344xxx:0.AES_KEY = 0 [R]
CHN MEQ0344xxx:1 Wz_Dimmer2_CH1_HM_MEQ0344xxx:1
DPT {a} BidCos-RF.MEQ0344xxx:1.LEVEL = 0.400000 [RWE]
DPT {b} BidCos-RF.MEQ0344xxx:1.OLD_LEVEL = [W]
DPT {f} BidCos-RF.MEQ0344xxx:1.LEVEL_REAL = 0.400000 [RE]
DPT {f} BidCos-RF.MEQ0344xxx:1.RAMP_TIME = [W]
DPT {f} BidCos-RF.MEQ0344xxx:1.ON_TIME = [W]
DPT {b} BidCos-RF.MEQ0344xxx:1.RAMP_STOP = [W]
DPT {b} BidCos-RF.MEQ0344xxx:1.INHIBIT = false [RWE]
DPT {b} BidCos-RF.MEQ0344xxx:1.ERROR_REDUCED = false [RE]
DPT {b} BidCos-RF.MEQ0344xxx:1.ERROR_OVERHEAT = false [RE]
DPT {i} BidCos-RF.MEQ0344xxx:1.DIRECTION = 0 [RE]
DPT {b} BidCos-RF.MEQ0344xxx:1.INSTALL_TEST = [W]
DPT {b} BidCos-RF.MEQ0344xxx:1.WORKING = false [RE]
CHN MEQ0344xxx:2 HM-LC-Dim1PWM-CV MEQ0344xxx:2
DPT {a} BidCos-RF.MEQ0344xxx:2.LEVEL = 0.000000 [RWE]
DPT {b} BidCos-RF.MEQ0344xxx:2.OLD_LEVEL = [W]
DPT {f} BidCos-RF.MEQ0344xxx:2.LEVEL_REAL = 0.400000 [RE]
DPT {f} BidCos-RF.MEQ0344xxx:2.RAMP_TIME = [W]
DPT {f} BidCos-RF.MEQ0344xxx:2.ON_TIME = [W]
DPT {b} BidCos-RF.MEQ0344xxx:2.RAMP_STOP = [W]
DPT {b} BidCos-RF.MEQ0344xxx:2.INHIBIT = false [RWE]
DPT {b} BidCos-RF.MEQ0344xxx:2.ERROR_REDUCED = false [RE]
DPT {b} BidCos-RF.MEQ0344xxx:2.ERROR_OVERHEAT = false [RE]
DPT {i} BidCos-RF.MEQ0344xxx:2.DIRECTION = 0 [RE]
DPT {b} BidCos-RF.MEQ0344xxx:2.INSTALL_TEST = [W]
DPT {b} BidCos-RF.MEQ0344xxx:2.WORKING = false [RE]
CHN MEQ0344xxx:3 HM-LC-Dim1PWM-CV MEQ0344xxx:3
DPT {a} BidCos-RF.MEQ0344xxx:3.LEVEL = 0.000000 [RWE]
DPT {b} BidCos-RF.MEQ0344xxx:3.OLD_LEVEL = [W]
DPT {f} BidCos-RF.MEQ0344xxx:3.LEVEL_REAL = 0.400000 [RE]
DPT {f} BidCos-RF.MEQ0344xxx:3.RAMP_TIME = [W]
DPT {f} BidCos-RF.MEQ0344xxx:3.ON_TIME = [W]
DPT {b} BidCos-RF.MEQ0344xxx:3.RAMP_STOP = [W]
DPT {b} BidCos-RF.MEQ0344xxx:3.INHIBIT = false [RWE]
DPT {b} BidCos-RF.MEQ0344xxx:3.ERROR_REDUCED = false [RE]
DPT {b} BidCos-RF.MEQ0344xxx:3.ERROR_OVERHEAT = false [RE]
DPT {i} BidCos-RF.MEQ0344xxx:3.DIRECTION = 0 [RE]
DPT {b} BidCos-RF.MEQ0344xxx:3.INSTALL_TEST = [W]
DPT {b} BidCos-RF.MEQ0344xxx:3.WORKING = false [RE]
StateDatapoint = 1.LEVEL
ControlDatapoint = 1.LEVEL
Reichen die Infos?
Dankeschön
Hallo Zap,
ich kann keine angelegten HMCCUDEV-Devices löschen, FHEM stürzt dann ab.
Das ist das einzige was das Log(Verbose 5) auswirft:
Undefined subroutine &main::HMCCUCHN_Undef called at fhem.pl line 3816.
vG Jens
Zitat von: Newbie am 06 September 2020, 18:23:58
Hallo Zap,
ich kann keine angelegten HMCCUDEV-Devices löschen, FHEM stürzt dann ab.
Das ist das einzige was das Log(Verbose 5) auswirft:
Undefined subroutine &main::HMCCUCHN_Undef called at fhem.pl line 3816.
vG Jens
Das ist noch ein Bug in HMCCUDEV. In den nächsten Tagen gibt es ein Update für die 4.4 Beta. Da sollte das dann behoben sein.
Zitat von: aherby am 24 August 2020, 21:30:03
Reichen die Infos?
Dankeschön
Ja, und ich kann es mittlerweile auch reproduzieren.
Zitat von: zap am 07 September 2020, 12:57:29
In den nächsten Tagen gibt es ein Update für die 4.4 Beta. Da sollte das dann behoben sein.
Dann bereite ich schon mal mein Testsystem vor ;D
Viele Grüße
Jürgen
Hallo zusammen,
ich habe ein Update für die 4.4 Beta eingecheckt (in FHEM contrib und in Github). Update Anweisung siehe erster Beitrag dieses Threads.
Ich habe diverse Bugs behoben.
Wichtige Änderung: Wenn ein neues CCU bzw. I/O Device angelegt wird, muss man explizit die Option "sync" angeben, damit alle CCU Informationen synchronisiert werden. Beim Starten von FHEM wird diese Option ignoriert und die CCU Infos werden synchronisiert.
Eine spätere Synchronisation ist jederzeit mit dem Befehl "get ccuConfig" möglich.
update lief problemlos.
Test läuft.
Viele Grüße
Jürgen
Hallo zap,
ich weiß nicht, ob das aufgrund der aktuellen Version kommt oder ob in den Definitionen noch ein Fehler schlummert. Ich finde im Log diese Meldungen:
2020.09.21 20:32:37 1: PERL WARNING: Use of uninitialized value $sr in substitution (s///) at ./FHEM/88_HMCCU.pm line 2192.
2020.09.21 20:32:37 1: PERL WARNING: Use of uninitialized value $sr in substitution (s///) at ./FHEM/88_HMCCU.pm line 2193.
2020.09.21 20:32:37 1: PERL WARNING: Use of uninitialized value $sr in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 2211.
2020.09.21 20:32:37 1: PERL WARNING: Use of uninitialized value $sr in split at ./FHEM/88_HMCCU.pm line 2266.
Viele Grüße
Jürgen
Ist nun behoben.
leider bin ich erst mit HMCCU 4.4 Beta richtig eingestiegen daher kenne ich das vorherige Verhalten nicht.
Ist es normal, dass ich eine angelegte Gruppe nicht sehe, wenn ich get debmatic ccudevices mache?
In der wiki ist übrigens überall etwas von Devicelist geschrieben, welches bei mir unter get gar nicht angezeigt wird...
Der Befehl "get ccuDevices" zeigt die CCU-Devices an, die FHEM bekannt sind. Bei mir werden da auch die Gruppen angezeigt (ggf. mal scrollen). Die Liste ist nach dem zugehörigen Interface sortiert. Ich bin mir jetzt nich ganz sicher, aber es könnte hilfreich sein, auch im Attribut rpcinterfaces den Haken bei VirtualDevices zu setzten.
Den Befehl "get devicelist" gibt es in 4.4 nicht mehr (das Wiki ist Stand Version 4.3). Dieser Befehl wurde durch 2 neue Befehle ersetzt:
"get ccuConfig" liest die Geräte von der CCU neu ein und ersetzt damit "get devicelist" ohne "create".
"get create" legt automatisch neue Geräte an und ersetzt damit "get devicelist create".
Zitat von: zap am 29 Juni 2020, 09:32:26
Du hast also ein Gerät, das am Stromnetz hängt, aber trotzdem ein Reading "battery" anzeigt? Kannst Du bitte mal ein "list" von diesem Geräte machen und vielleicht noch ein "get deviceinfo" ?
Hallo Zap,
hast du dir das Thema mit den Batterie-Readings mal angeschaut?
Ich hatte kein "list" oder "get deviceinfo" gemacht, da ich die Antwort vom Jürgen
Zitat
Hallo zap,
das sind die Schaltaktoren (ohne IP).
als Erklärung gesehen habe.
Leider habe ich die Batterie-Readings noch bei den Geräten.
Ein
set clearhat es leider nur kurzzeitig gelöscht.
Danke
Wenn es keine Umstände macht, wäre ein get deviceinfo schon hilfreich
Mal wieder ein Update mit einigen Bugfixes. Installation siehe erster Beitrag.
Wichtigste Neuerung: Der Befehl "get week-program" zeigt - sofern vorhanden - Heizprogramme an.
Ich werde nächste Woche einen Termin bekannt geben, zu dem ich die Beta beende und die Module in den produktiven Zweig des SVN einchecke. Auf jeden Fall noch dieses Jahr.
Zitat von: zap am 08 November 2020, 18:03:09
Ich werde nächste Woche einen Termin bekannt geben, zu dem ich die Beta beende und die Module in den produktiven Zweig des SVN einchecke. Auf jeden Fall noch dieses Jahr.
Was bedeutet das dann eigentlich für den Nutzer?
Muss ich alle Geräte neu anlegen? Werden die automatisch angepasst?
Macht es eigentlich Sinn jetzt schon umzustellen, wenn man gerade etwas Zeit hat? Oder rätst du vom produktiven Einsatz vorerst noch ab?
Zitat von: kjmEjfu am 09 November 2020, 07:57:15
Was bedeutet das dann eigentlich für den Nutzer?
Muss ich alle Geräte neu anlegen? Werden die automatisch angepasst?
Macht es eigentlich Sinn jetzt schon umzustellen, wenn man gerade etwas Zeit hat? Oder rätst du vom produktiven Einsatz vorerst noch ab?
Für den Benutzer bedeutet es (hoffentlich), dass die Definition von Geräten einfacher wird. HMCCU erkennt nun anhand der Kanalrolle, wie ein Gerät eingebunden werden muss. Viele der aktuellen Attribute werden dadurch überflüssig, werden aber weiterhin unterstützt. Man kann ein schon existierendes HMCCUDEV oder HMCCUCHN Device auf die neuen Defaults umstellen, indem man den Befehl "set defaults reset" ausführt.
Die gebräuchlichsten Geräte wie Thermostate, Schalter, Rollladen usw werden jetzt schon unterstützt. Da die alten Defaults nach wir vor vorhanden sind, kann eigentlich nichts bzw wenig schiefgehen.
Natürlich bleibt ein Restrisikio. Trotzdem würde ich jedem, der jetzt über den Einstieg mit HMCCU nachdenkt, gleich mit der 4.4 Beta zu starten.
Für alle anderen, die einen existierende HMCCU Umgebung haben, empfehle ich: probiert die Umstellung mal aus. Dabei würde ich so vorgehen:
- fhem.cfg sichern
- RPC Server stoppen (set rpcserver off)
- Autostart der RPC Server deaktivieren (attr rpcserver off)
- Update auf 4.4. Beta durchführen (siehe 1. Post in diesem Thread, am besten die Github Quelle verwenden)
- FHEM neu starten
- Optional: die Defaults bei einigen / allen Geräten zurücksetzen (set defaults reset)
- RPC Server starten
Es wäre für mich sehr hilfreich, wenn das möglichst viele versuchen und Feedback geben.
Falls Ihr zurück auf die alte Version wollt:
- RPC Server stoppen
- Normales FHEM Update ausführen
- FHEM stoppen
- Alte fhem.cfg zurück kopieren
- FHEM starten
Ich habe mich mal getraut ...
Im Anhang mal der optische Unterschied zwischen nach "set defaults reset" (oben) und vorher (unten).
Beim alten ist gesetzt:
cmdIcon up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down
dürfte damit zusammen hängen, dass jetzt
webCMD open:close:stop:pct
ist.
Dann sind folgende Attribute weggefallen:
attr Rollo_OG_Allrum_West ccureadingname ^(.+\.)?DIRECTION$:+motor
attr Rollo_OG_Allrum_West ccuscaleval LEVEL:0:1:0:100
attr Rollo_OG_Allrum_West eventMap /datapoint 1.STOP true:stop/datapoint 1.LEVEL 0:down/datapoint 1.LEVEL 100:up/datapoint 1.INHIBIT 0:inhibit off/datapoint 1.INHIBIT 1:inhibit on/
attr Rollo_OG_Allrum_West substitute LEVEL!#0-0:none,#100-100:open;;DIRECTION!0:stop,1:up,2:down,3:undefined;;WORKING!(0|false):no,(1|true):yes
das ist so Absicht?
Und verändert hat sich
attr Rollo_OG_Allrum_West substexcl control|pct
attr Rollo_OG_Allrum_West widgetOverride control:slider,0,10,100
beim ersten ist control raus und beim zweiten control zu pct geworden.
Generell steht jetzt im pct immer der Wert (auch 0 oder 100), im control dann angepasst (also open statt 100, ...). Passt soweit. Muss mal schauen, ob das Auswirkungen auf meine ASC-Steuerung hat.
Frage: brauche ich controldatapoint und statedatapoint noch?
Mir ist gerade auch aufgefallen, bei einer Außensirene (HmIP-ASIR-O) existieren Setter für on und off. Was genau lösen die aus? ;-)
Einen habe ich noch.
2020.11.11 10:49:00.582 2: HMCCUDEV [Sensor_Aussen_Carport_Temperatur] Cannot detect control channel role of Sensor_Aussen_Carport_Temperatur
2020.11.11 10:49:00.587 1: HMCCUDEV [Sensor_Aussen_Carport_Temperatur] HMCCUDEV: Sensor_Aussen_Carport_Temperatur No default attributes found
Ist ein HmIP-STHO
DeviceInfo:
CHN XXXXXX:0 HM-Temperatur-Aussen-Carport:0
DPT {b} HmIP-RF.XXXXXX:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.XXXXXX:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.XXXXXX:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.XXXXXX:0.INSTALL_TEST = true [RW]
DPT {b} HmIP-RF.XXXXXX:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.XXXXXX:0.OPERATING_VOLTAGE = 2.800000 [RE]
DPT {i} HmIP-RF.XXXXXX:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.XXXXXX:0.RSSI_DEVICE = 185 [RE]
DPT {n} HmIP-RF.XXXXXX:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.XXXXXX:0.TEMPERATURE_OUT_OF_RANGE = false [RE]
DPT {b} HmIP-RF.XXXXXX:0.UNREACH = false [RE]
DPT {b} HmIP-RF.XXXXXX:0.UPDATE_PENDING = false [RE]
CHN XXXXXX:1 HmIP-STHO XXXXXX:1
DPT {f} HmIP-RF.XXXXXX:1.ACTUAL_TEMPERATURE = 7.500000 [RE]
DPT {i} HmIP-RF.XXXXXX:1.ACTUAL_TEMPERATURE_STATUS = 0 [RE]
DPT {i} HmIP-RF.XXXXXX:1.HUMIDITY = 98 [RE]
DPT {i} HmIP-RF.XXXXXX:1.HUMIDITY_STATUS = 0 [RE]
StateDatapoint = .
ControlDatapoint = .
Device XXXXXX HM-Temperatur-Aussen-Carport [HmIP-STHO]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: XXXXXX:0,XXXXXX:1,XXXXXX:2,XXXXXX:3
DIRECTION: NONE
FIRMWARE: 1.0.6
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 5565695
ROAMING: 0
RX_MODE: CONFIG
SUBTYPE: STHO
UPDATABLE: 1
Channel XXXXXX:0 HM-Temperatur-Aussen-Carport:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-STHO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:1 HmIP-STHO XXXXXX:1 [CLIMATE_TRANSCEIVER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-STHO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:2 HmIP-STHO XXXXXX:2 [COND_SWITCH_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-STHO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:3 HmIP-STHO XXXXXX:3 [COND_SWITCH_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-STHO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Values:
Device XXXXX
Channel 0 [VALUES]
CONFIG_PENDING = false
DUTY_CYCLE = false
ERROR_CODE = 0
LOW_BAT = ok
OPERATING_VOLTAGE = 2.8
OPERATING_VOLTAGE_STATUS = NORMAL
RSSI_DEVICE = -71
TEMPERATURE_OUT_OF_RANGE = false
UNREACH = alive
UPDATE_PENDING = false
Channel 1 [VALUES]
ACTUAL_TEMPERATURE = 7.5
ACTUAL_TEMPERATURE_STATUS = NORMAL
HUMIDITY = 98
HUMIDITY_STATUS = NORMAL
Und noch was:
Bei dem Device handelt es sich um ein HmIP-BDT.
Vor dem "set defaults reset" sahen die Attribute so aus:
attr Licht_OG_Badezimmer IODev d_ccu
attr Licht_OG_Badezimmer alias Licht Badezimmer
attr Licht_OG_Badezimmer ccureadingfilter (ERROR_CODE|ERROR_OVERHEAT|ACTUAL_TEMPERATURE|ACTIVITY_STATE|LEVEL)
attr Licht_OG_Badezimmer ccuscaleval LEVEL:0:1:0:100
attr Licht_OG_Badezimmer controldatapoint 3.LEVEL
attr Licht_OG_Badezimmer event-on-change-reading .*
attr Licht_OG_Badezimmer genericDeviceType light
attr Licht_OG_Badezimmer group Licht
attr Licht_OG_Badezimmer hmstatevals ACTUAL_TEMPERATURE_STATUS!2:tempOverflow,3:tempUnderflow;;ERROR_OVERHEAT!(1|true):overheat
attr Licht_OG_Badezimmer room Badezimmer,Homematic
attr Licht_OG_Badezimmer statedatapoint 4.LEVEL
attr Licht_OG_Badezimmer statevals on:100,off:0
attr Licht_OG_Badezimmer stripnumber 1
attr Licht_OG_Badezimmer substexcl control
attr Licht_OG_Badezimmer substitute LEVEL!#0-0:off,#1-100:on;;ACTIVITY_STATE!0:unknown,1:up,2:down,3:stop;;ERROR_OVERHEAT!(0|false):no,(1|true):yes;;ACTUAL_TEMPERATURE_STATUS!0:normal,1:unknown,2:overflow,3:underflow
attr Licht_OG_Badezimmer webCmd control:on:off
attr Licht_OG_Badezimmer widgetOverride control:slider,0,10,100
Jetzt sieht es so aus:
attr Licht_OG_Badezimmer IODev d_ccu
attr Licht_OG_Badezimmer alias Licht Badezimmer
attr Licht_OG_Badezimmer ccureadingfilter (ERROR_CODE|ERROR_OVERHEAT|ACTUAL_TEMPERATURE|ACTIVITY_STATE|LEVEL)
attr Licht_OG_Badezimmer controldatapoint 3.LEVEL
attr Licht_OG_Badezimmer event-on-change-reading .*
attr Licht_OG_Badezimmer genericDeviceType light
attr Licht_OG_Badezimmer group Licht
attr Licht_OG_Badezimmer hmstatevals ACTUAL_TEMPERATURE_STATUS!2:tempOverflow,3:tempUnderflow;;ERROR_OVERHEAT!(1|true):overheat
attr Licht_OG_Badezimmer room Badezimmer,Homematic
attr Licht_OG_Badezimmer statedatapoint 4.LEVEL
attr Licht_OG_Badezimmer statevals on:100,off:0
attr Licht_OG_Badezimmer stripnumber 1
attr Licht_OG_Badezimmer substexcl control
Im set habe ich kein off/on mehr. Auch der Slider für den Dimmer ist verschwunden.
Ein "get defaults" für das Device zeigt mir an:
ccuscaleval = LEVEL:0:1:0:100
statevals = on:100,off:0
controldatapoint = 4.LEVEL
statedatapoint = 4.LEVEL
widgetOverride = control:slider,0,10,100
hmstatevals = ACTUAL_TEMPERATURE_STATUS!2:tempOverflow,3:tempUnderflow;ERROR_OVERHEAT!(1|true):overheat
substitute = LEVEL!#0-0:off,#1-100:on;ACTIVITY_STATE!0:unknown,1:up,2:down,3:stop;ERROR_OVERHEAT!(0|false):no,(1|true):yes;ACTUAL_TEMPERATURE_STATUS!0:normal,1:unknown,2:overflow,3:underflow
webCmd = control:on:off
substexcl = control
ccureadingfilter = (ERROR_CODE|ERROR_OVERHEAT|ACTUAL_TEMPERATURE|ACTIVITY_STATE|LEVEL)
stripnumber = 1
Es sind also ein paar Attribute gelöscht worden. Ein paar sind anders als der default vorgibt (z.B. controldatapoint 3.LEVEL).
Was läuft da schief?
Soweit meine Tests für heute :-)
Erst mal danke für's Testen!!
Der Befehl "set defaults reset" löscht erstmal folgende Attribute:
'ccureadingname', 'ccuscaleval', 'eventMap','substitute', 'webCmd', 'widgetOverride'
Anschließend werden dann - je nach Typ des Control-Channels - neue Attribute gesetzt. Wenn HMCCU den Typ des Control-Channels nicht unterstützt, werden wieder die alten Default-Attribute gesetzt. In diesem Fall wäre die Ausgabe von "get deviceinfo" interessant. Dann kann ich den Channel-Typ aufnehmen. Ein Channel-Typ ist z.B. SHUTTER_CONTACT.
Für das Rollo: Ich passe die webCmds an und ergänze die Befehle, die Du bisher hattest. Macht Sinn für mich.
Für HmIP-STHO: Den Channel-Typ CLIMATE_TRANSCEIVER hatte ich tatsächlich noch nicht drin. Füge ich hinzu, dann sollte das funktionieren.
Für HmIP-BDT: Den Befehl "get defaults" kannst Du bei unterstützten Geräten (bei denen der Channel-Typ erkannt wird) vergessen. Der zeigt die alten Default-Attribute an. Bitte mach mal ein "get deviceinfo" für dieses Gerät.
Ach ja: Für die Alarmsirene bitte auch ein "get deviceinfo".
Den Befehl "get deviceinfo" gibt es auch für das I/O Device. Als Parameter erwartet er den Gerätenamen in der CCU. Das erspart die Defintion eines Device, nur um die Info auszulesen.
Kriegst du :-)
der BDT:
CHN XXXXXX:0 HM-Licht-OG-Badezimmer:0
DPT {f} HmIP-RF.XXXXXX:0.ACTUAL_TEMPERATURE = 0.000000 [RE]
DPT {b} HmIP-RF.XXXXXX:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.XXXXXX:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.XXXXXX:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.XXXXXX:0.ERROR_OVERHEAT = false [RE]
DPT {b} HmIP-RF.XXXXXX:0.ERROR_OVERLOAD = false [RE]
DPT {b} HmIP-RF.XXXXXX:0.ERROR_UPDATE = false [RE]
DPT {f} HmIP-RF.XXXXXX:0.OPERATING_VOLTAGE = 0.000000 [RE]
DPT {n} HmIP-RF.XXXXXX:0.RSSI_DEVICE = 179 [RE]
DPT {n} HmIP-RF.XXXXXX:0.RSSI_PEER = 183 [RE]
DPT {b} HmIP-RF.XXXXXX:0.UNREACH = false [RE]
DPT {b} HmIP-RF.XXXXXX:0.UPDATE_PENDING = false [RE]
CHN XXXXXX:1 HmIP-BDT XXXXXX:1
DPT {b} HmIP-RF.XXXXXX:1.PRESS_LONG = [E]
DPT {b} HmIP-RF.XXXXXX:1.PRESS_SHORT = [E]
CHN XXXXXX:2 HmIP-BDT XXXXXX:2
DPT {b} HmIP-RF.XXXXXX:2.PRESS_LONG = [E]
DPT {b} HmIP-RF.XXXXXX:2.PRESS_SHORT = [E]
CHN XXXXXX:3 HmIP-BDT XXXXXX:3
DPT {a} HmIP-RF.XXXXXX:3.LEVEL = 0.000000 [RE]
DPT {i} HmIP-RF.XXXXXX:3.PROCESS = 0 [RE]
DPT {i} HmIP-RF.XXXXXX:3.SECTION = 15 [RE]
CHN XXXXXX:4 HmIP-BDT XXXXXX:4
DPT {a} HmIP-RF.XXXXXX:4.LEVEL = 0.000000 [RWE]
DPT {f} HmIP-RF.XXXXXX:4.ON_TIME = [W]
DPT {i} HmIP-RF.XXXXXX:4.PROCESS = 0 [RE]
DPT {f} HmIP-RF.XXXXXX:4.RAMP_TIME = [W]
DPT {i} HmIP-RF.XXXXXX:4.SECTION = 0 [RE]
CHN XXXXXX:5 HmIP-BDT XXXXXX:5
DPT {a} HmIP-RF.XXXXXX:5.LEVEL = 0.000000 [RWE]
DPT {f} HmIP-RF.XXXXXX:5.ON_TIME = [W]
DPT {i} HmIP-RF.XXXXXX:5.PROCESS = 0 [RE]
DPT {f} HmIP-RF.XXXXXX:5.RAMP_TIME = [W]
DPT {i} HmIP-RF.XXXXXX:5.SECTION = 0 [RE]
CHN XXXXXX:6 HmIP-BDT XXXXXX:6
DPT {a} HmIP-RF.XXXXXX:6.LEVEL = 0.000000 [RWE]
DPT {f} HmIP-RF.XXXXXX:6.ON_TIME = [W]
DPT {i} HmIP-RF.XXXXXX:6.PROCESS = 0 [RE]
DPT {f} HmIP-RF.XXXXXX:6.RAMP_TIME = [W]
DPT {i} HmIP-RF.XXXXXX:6.SECTION = 0 [RE]
CHN XXXXXX:7 HmIP-BDT XXXXXX:7
DPT {i} HmIP-RF.XXXXXX:7.WEEK_PROGRAM_CHANNEL_LOCKS = 0 [RE]
DPT {i} HmIP-RF.XXXXXX:7.WEEK_PROGRAM_TARGET_CHANNEL_LOCK = [W]
DPT {i} HmIP-RF.XXXXXX:7.WEEK_PROGRAM_TARGET_CHANNEL_LOCKS = [W]
StateDatapoint = 3.LEVEL
ControlDatapoint = 4.LEVEL
Device XXXXXX HM-Licht-OG-Badezimmer [HmIP-BDT]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 1.4.8
CHILDREN: XXXXXX:0,XXXXXX:1,XXXXXX:2,XXXXXX:3,XXXXXX:4,XXXXXX:5,XXXXXX:6,XXXXXX:7
DIRECTION: NONE
FIRMWARE: 1.4.8
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 3683136
ROAMING: 0
RX_MODE:
SUBTYPE: BDT
UPDATABLE: 1
Channel XXXXXX:0 HM-Licht-OG-Badezimmer:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:1 HmIP-BDT XXXXXX:1 [KEY_TRANSCEIVER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:2 HmIP-BDT XXXXXX:2 [KEY_TRANSCEIVER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:3 HmIP-BDT XXXXXX:3 [DIMMER_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:4 HmIP-BDT XXXXXX:4 [DIMMER_VIRTUAL_RECEIVER]
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: LEVEL,REMOTE_CONTROL,SWITCH,CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:5 HmIP-BDT XXXXXX:5 [DIMMER_VIRTUAL_RECEIVER]
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: LEVEL,REMOTE_CONTROL,SWITCH,CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:6 HmIP-BDT XXXXXX:6 [DIMMER_VIRTUAL_RECEIVER]
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: LEVEL,REMOTE_CONTROL,SWITCH,CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:7 HmIP-BDT XXXXXX:7 [DIMMER_WEEK_PROFILE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Und der STHO:
CHN XXXXXX:0 HM-Sirene-Aussen-Sued:0
DPT {b} HmIP-RF.XXXXXX:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.XXXXXX:0.DUTY_CYCLE = false [RE]
DPT {b} HmIP-RF.XXXXXX:0.ERROR_BAD_RECHARGEABLE_BATTERY_HEALTH = false [RE]
DPT {n} HmIP-RF.XXXXXX:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.XXXXXX:0.INSTALL_TEST = true [RW]
DPT {b} HmIP-RF.XXXXXX:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.XXXXXX:0.OPERATING_VOLTAGE = 4.100000 [RE]
DPT {i} HmIP-RF.XXXXXX:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.XXXXXX:0.RSSI_DEVICE = 183 [RE]
DPT {n} HmIP-RF.XXXXXX:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.XXXXXX:0.SABOTAGE = false [RE]
DPT {b} HmIP-RF.XXXXXX:0.UNREACH = false [RE]
DPT {b} HmIP-RF.XXXXXX:0.UPDATE_PENDING = false [RE]
CHN XXXXXX:3 HmIP-ASIR-O XXXXXX:3
DPT {b} HmIP-RF.XXXXXX:3.ACOUSTIC_ALARM_ACTIVE = false [RE]
DPT {i} HmIP-RF.XXXXXX:3.ACOUSTIC_ALARM_SELECTION = [W]
DPT {i} HmIP-RF.XXXXXX:3.DURATION_UNIT = [W]
DPT {i} HmIP-RF.XXXXXX:3.DURATION_VALUE = [W]
DPT {b} HmIP-RF.XXXXXX:3.OPTICAL_ALARM_ACTIVE = false [RE]
DPT {i} HmIP-RF.XXXXXX:3.OPTICAL_ALARM_SELECTION = [W]
StateDatapoint = 1.PRESS_SHORT
ControlDatapoint = 1.PRESS_SHORT
Device XXXXXX HM-Sirene-Aussen-Sued [HmIP-ASIR-O]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: XXXXXX:0,XXXXXX:1,XXXXXX:2,XXXXXX:3
DIRECTION: NONE
FIRMWARE: 1.0.6
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 7785172
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG,BURST
SUBTYPE: ASIR-O
UPDATABLE: 1
Channel XXXXXX:0 HM-Sirene-Aussen-Sued:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-ASIR-O
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:1 HmIP-ASIR-O XXXXXX:1 [KEY_TRANSCEIVER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: ALARM_MODE_CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-ASIR-O
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:2 HmIP-ASIR-O XXXXXX:2 [ALARM_COND_SWITCH_RECEIVER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS:
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-ASIR-O
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:3 HmIP-ASIR-O XXXXXX:3 [ALARM_SWITCH_VIRTUAL_RECEIVER]
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: REMOTE_CONTROL,SWITCH,CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-ASIR-O
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
OK
Hab auch noch einen ASIR, der setzt auch on/off wie die Außensirene:
CHN XXXXXX:0 HM-Sirene-EG-Flur:0
DPT {b} HmIP-RF.XXXXXX:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.XXXXXX:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.XXXXXX:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.XXXXXX:0.INSTALL_TEST = true [RW]
DPT {b} HmIP-RF.XXXXXX:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.XXXXXX:0.OPERATING_VOLTAGE = 3.700000 [RE]
DPT {i} HmIP-RF.XXXXXX:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.XXXXXX:0.RSSI_DEVICE = 195 [RE]
DPT {n} HmIP-RF.XXXXXX:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.XXXXXX:0.SABOTAGE = false [RE]
DPT {b} HmIP-RF.XXXXXX:0.UNREACH = false [RE]
DPT {b} HmIP-RF.XXXXXX:0.UPDATE_PENDING = false [RE]
CHN XXXXXX:3 HmIP-ASIR XXXXXX:3
DPT {b} HmIP-RF.XXXXXX:3.ACOUSTIC_ALARM_ACTIVE = false [RE]
DPT {i} HmIP-RF.XXXXXX:3.ACOUSTIC_ALARM_SELECTION = [W]
DPT {i} HmIP-RF.XXXXXX:3.DURATION_UNIT = [W]
DPT {i} HmIP-RF.XXXXXX:3.DURATION_VALUE = [W]
DPT {b} HmIP-RF.XXXXXX:3.OPTICAL_ALARM_ACTIVE = false [RE]
DPT {i} HmIP-RF.XXXXXX:3.OPTICAL_ALARM_SELECTION = [W]
StateDatapoint = 1.PRESS_SHORT
ControlDatapoint = 1.PRESS_SHORT
Device XXXXXX HM-Sirene-EG-Flur [HmIP-ASIR]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 1.4.2
CHILDREN: XXXXXX:0,XXXXXX:1,XXXXXX:2,XXXXXX:3
DIRECTION: NONE
FIRMWARE: 1.4.2
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 6347262
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG,BURST
SUBTYPE: ASIR
UPDATABLE: 1
Channel XXXXXX:0 HM-Sirene-EG-Flur:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-ASIR
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:1 HmIP-ASIR XXXXXX:1 [KEY_TRANSCEIVER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: ALARM_MODE_CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-ASIR
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:2 HmIP-ASIR XXXXXX:2 [ALARM_COND_SWITCH_RECEIVER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS:
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-ASIR
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel XXXXXX:3 HmIP-ASIR XXXXXX:3 [ALARM_SWITCH_VIRTUAL_RECEIVER]
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: REMOTE_CONTROL,SWITCH,CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: XXXXXX
PARENT_TYPE: HmIP-ASIR
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
OK
Mir fällt noch was auf. Kann es sein, dass
ccucalculate dewpoint:taupunkt:1.ACTUAL_TEMPERATURE,1.HUMIDITY
nicht mehr funktioniert? Habe das an einem HmIP-STH definiert und nach der Umstellung ist das reading dewpoint verschwunden und taucht nicht wieder auf.
Und noch eine Frage, du hast geschrieben "ccureadingname" wird gelöscht. Nur für das Update oder soll das Attribut generell wegfallen?
Für den BDT: Bitte die folgenden Attribute löschen:
controldatapoint, statedatapoint, statevals.
Diese Attribute sind überflüssig, wenn HMCCU den Channel-Typ erkennt.
Der Befehl "set defaults reset" löscht diese derzeit noch nicht. Das war mir zu heikel. Eigentlich dürfte es keinen negativen Effekt haben. In diesem Fall aber schon, weil das alte Attribut controldatapoint=3.LEVEL definitiv falsch ist.
Denn:
CHN XXXXXX:3 HmIP-BDT XXXXXX:3
DPT {a} HmIP-RF.XXXXXX:3.LEVEL = 0.000000 [RE]
D.h. 3.LEVEL hat die Flags Read und Event (RE). Ist also nicht beschreibbar.
Für die Alarmsirene benötige ich auch noch "get paramsetDesc"
ccureadingname gibt es weiterhin. Allerdings ist es für Standards wie "pct" nicht mehr erforderlich.
Ok, hab die beim BDT gelöscht.
on/off fehlen aber immer noch im set.
Ausschnitt vom List:
Internals:
DEF 0008D8A989EFD7
FUUID 5c446461-f33f-8030-32a4-e055e3cfa00dc83b
FVERSION 88_HMCCUDEV.pm:v4.4.34-s18552/2019-02-10
IODev d_ccu
NAME Licht_OG_Badezimmer
NR 219
STATE 0
TYPE HMCCUDEV
ccuaddr 0008D8A989EFD7
ccudevstate active
ccuif HmIP-RF
ccuname HM-Licht-OG-Badezimmer
ccutype HmIP-BDT
readonly no
receiver Licht_OG_Badezimmer,Licht_OG_Badezimmer
sender Licht_OG_Badezimmer,Licht_OG_Badezimmer
OLDREADINGS:
READINGS:
2020-11-11 19:11:51 3.ACTIVITY_STATE UNKNOWN
2020-11-11 19:11:51 3.LEVEL 0
2020-11-11 19:11:51 3.LEVEL_STATUS NORMAL
2020-11-11 19:11:51 4.ACTIVITY_STATE STABLE
2020-11-11 19:11:51 4.LEVEL off
2020-11-11 19:11:51 4.LEVEL_STATUS NORMAL
2020-11-11 19:11:51 5.ACTIVITY_STATE STABLE
2020-11-11 19:11:51 5.LEVEL off
2020-11-11 19:11:51 5.LEVEL_STATUS NORMAL
2020-11-11 19:11:51 6.ACTIVITY_STATE STABLE
2020-11-11 19:11:51 6.LEVEL off
2020-11-11 19:11:51 6.LEVEL_STATUS NORMAL
2020-11-11 19:11:51 activity alive
2020-11-11 19:11:26 control 0
2020-11-11 19:11:51 devstate ok
2020-11-11 19:11:51 hmstate ${STATE}
2020-11-11 19:11:26 state 0
hmccu:
channels 8
devspec 0008D8A989EFD7
nodefaults 1
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:KEY_TRANSCEIVER,3:DIMMER_TRANSMITTER,4:DIMMER_VIRTUAL_RECEIVER,5:DIMMER_VIRTUAL_RECEIVER,6:DIMMER_VIRTUAL_RECEIVER,7:DIMMER_WEEK_PROFILE
semDefaults 0
cmdlist:
get
set toggle:noArg
control:
chn
dpt
Und hier noch die paramsetDesc vom ASIR:
Device
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Channel 0
Paramset MASTER
ARR_TIMEOUT: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=10
CYCLIC_INFO_MSG: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=1
CYCLIC_INFO_MSG_DIS: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
CYCLIC_INFO_MSG_DIS_UNCHANGED: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
CYCLIC_INFO_MSG_OVERDUE_THRESHOLD: INTEGER [R,W] [Visible,Sticky] RANGE=0...2147483647 DFLT=2
DUTYCYCLE_LIMIT: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=180
ENABLE_ROUTING: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=1
LOCAL_RESET_DISABLED: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
LOW_BAT_LIMIT: FLOAT [R,W] [Visible,Sticky] RANGE=0...25.2 DFLT=2.2 UNIT=V
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Paramset VALUES
CONFIG_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
DUTY_CYCLE: BOOL [R,E] [Visible,Sticky] RANGE=0...1 DFLT=0
ERROR_BAD_RECHARGEABLE_BATTERY_HEALTH: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
ERROR_CODE: INTEGER [R,E] [Visible,Sticky,Service] RANGE=0...255 DFLT=0
INSTALL_TEST: BOOL [R,W] [Internal] RANGE=0...1 DFLT=0
LOW_BAT: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
OPERATING_VOLTAGE: FLOAT [R,E] [Visible,Sticky] RANGE=0...25.2 DFLT=0
OPERATING_VOLTAGE_STATUS: ENUM [R,E] [Visible,Sticky] RANGE=NORMAL...EXTERNAL DFLT=NORMAL VALUES=NORMAL,UNKNOWN,OVERFLOW,EXTERNAL
RSSI_DEVICE: INTEGER [R,E] [Visible,Sticky] RANGE=-128...127 DFLT=0
RSSI_PEER: INTEGER [R,E] [Visible,Sticky] RANGE=-128...127 DFLT=0
SABOTAGE: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
UNREACH: BOOL [R,E] [Sticky,Internal] RANGE=0...1 DFLT=0
UPDATE_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
Channel 1
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Channel 2
Paramset MASTER
SD_MULTICAST_ZONE_1: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SD_MULTICAST_ZONE_2: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SD_MULTICAST_ZONE_3: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SD_MULTICAST_ZONE_4: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SD_MULTICAST_ZONE_5: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SD_MULTICAST_ZONE_6: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SD_MULTICAST_ZONE_7: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SILENT_ALARM_ZONE_1: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SILENT_ALARM_ZONE_2: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SILENT_ALARM_ZONE_3: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SILENT_ALARM_ZONE_4: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SILENT_ALARM_ZONE_5: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SILENT_ALARM_ZONE_6: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SILENT_ALARM_ZONE_7: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Channel 3
Paramset LINK
LONG_COND_VALUE_HI: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=150
LONG_COND_VALUE_LO: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=50
LONG_CT_OFF: ENUM [R,W] [Visible,Sticky] RANGE=VALUE_GE_LO...VALUE_L_LO_OR_GE_HI DFLT=VALUE_GE_LO VALUES=VALUE_GE_LO,VALUE_GE_HI,VALUE_L_LO,VALUE_L_HI,VALUE_GE_LO_AND_L_HI,VALUE_L_LO_OR_GE_HI
LONG_CT_OFFDELAY: ENUM [R,W] [Visible,Sticky] RANGE=VALUE_GE_LO...VALUE_L_LO_OR_GE_HI DFLT=VALUE_GE_LO VALUES=VALUE_GE_LO,VALUE_GE_HI,VALUE_L_LO,VALUE_L_HI,VALUE_GE_LO_AND_L_HI,VALUE_L_LO_OR_GE_HI
LONG_CT_ON: ENUM [R,W] [Visible,Sticky] RANGE=VALUE_GE_LO...VALUE_L_LO_OR_GE_HI DFLT=VALUE_GE_LO VALUES=VALUE_GE_LO,VALUE_GE_HI,VALUE_L_LO,VALUE_L_HI,VALUE_GE_LO_AND_L_HI,VALUE_L_LO_OR_GE_HI
LONG_CT_ONDELAY: ENUM [R,W] [Visible,Sticky] RANGE=VALUE_GE_LO...VALUE_L_LO_OR_GE_HI DFLT=VALUE_GE_LO VALUES=VALUE_GE_LO,VALUE_GE_HI,VALUE_L_LO,VALUE_L_HI,VALUE_GE_LO_AND_L_HI,VALUE_L_LO_OR_GE_HI
LONG_JT_OFF: ENUM [R,W] [Visible,Sticky] RANGE=NOP...OFF DFLT=ON VALUES=NOP,ON_DELAY,RAMP_ON,ON,OFF_DELAY,RAMP_OFF,OFF
LONG_JT_OFFDELAY: ENUM [R,W] [Visible,Sticky] RANGE=NOP...OFF DFLT=ON VALUES=NOP,ON_DELAY,RAMP_ON,ON,OFF_DELAY,RAMP_OFF,OFF
LONG_JT_ON: ENUM [R,W] [Visible,Sticky] RANGE=NOP...OFF DFLT=ON VALUES=NOP,ON_DELAY,RAMP_ON,ON,OFF_DELAY,RAMP_OFF,OFF
LONG_JT_ONDELAY: ENUM [R,W] [Visible,Sticky] RANGE=NOP...OFF DFLT=ON VALUES=NOP,ON_DELAY,RAMP_ON,ON,OFF_DELAY,RAMP_OFF,OFF
LONG_MULTIEXECUTE: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
LONG_OFFDELAY_TIME_BASE: ENUM [R,W] [Visible,Sticky] RANGE=BASE_100_MS...BASE_1_H DFLT=BASE_100_MS VALUES=BASE_100_MS,BASE_1_S,BASE_5_S,BASE_10_S,BASE_1_M,BASE_5_M,BASE_10_M,BASE_1_H
LONG_OFFDELAY_TIME_FACTOR: INTEGER [R,W] [Visible,Sticky] RANGE=0...31 DFLT=0
LONG_OFF_TIME_BASE: ENUM [R,W] [Visible,Sticky] RANGE=BASE_100_MS...BASE_1_H DFLT=BASE_1_H VALUES=BASE_100_MS,BASE_1_S,BASE_5_S,BASE_10_S,BASE_1_M,BASE_5_M,BASE_10_M,BASE_1_H
LONG_OFF_TIME_FACTOR: INTEGER [R,W] [Visible,Sticky] RANGE=0...31 DFLT=31
LONG_OFF_TIME_MODE: ENUM [R,W] [Visible,Sticky] RANGE=TIME_IS_ABSOLUTE...TIME_IS_MINIMAL DFLT=TIME_IS_ABSOLUTE VALUES=TIME_IS_ABSOLUTE,TIME_IS_MINIMAL
LONG_ONDELAY_TIME_BASE: ENUM [R,W] [Visible,Sticky] RANGE=BASE_100_MS...BASE_1_H DFLT=BASE_100_MS VALUES=BASE_100_MS,BASE_1_S,BASE_5_S,BASE_10_S,BASE_1_M,BASE_5_M,BASE_10_M,BASE_1_H
LONG_ONDELAY_TIME_FACTOR: INTEGER [R,W] [Visible,Sticky] RANGE=0...31 DFLT=0
LONG_ON_TIME_BASE: ENUM [R,W] [Visible,Sticky] RANGE=BASE_100_MS...BASE_1_H DFLT=BASE_1_M VALUES=BASE_100_MS,BASE_1_S,BASE_5_S,BASE_10_S,BASE_1_M,BASE_5_M,BASE_10_M,BASE_1_H
LONG_ON_TIME_FACTOR: INTEGER [R,W] [Visible,Sticky] RANGE=0...31 DFLT=6
LONG_ON_TIME_MODE: ENUM [R,W] [Visible,Sticky] RANGE=TIME_IS_ABSOLUTE...TIME_IS_MINIMAL DFLT=TIME_IS_ABSOLUTE VALUES=TIME_IS_ABSOLUTE,TIME_IS_MINIMAL
LONG_PROFILE_ACTION_TYPE: ENUM [R,W] [Visible,Sticky] RANGE=PROFILE_ACTION_TYPE_INACTIVE...PROFILE_ACTION_TYPE_TOGGLE_DRIVE_COUNTER DFLT=PROFILE_ACTION_TYPE_JUMP VALUES=PROFILE_ACTION_TYPE_INACTIVE,PROFILE_ACTION_TYPE_JUMP,PROFILE_ACTION_TYPE_TOGGLE,PROFILE_ACTION_TYPE_DRIVE_UP,PROFILE_ACTION_TYPE_DRIVE_DOWN,PROFILE_ACTION_TYPE_TOGGLE_DRIVE_LAST_DIR,PROFILE_ACTION_TYPE_TOGGLE_DRIVE_COUNTER
LONG_SIGNAL_SELECTION_ACOUSTIC: ENUM [R,W] [Visible,Sticky] RANGE=DISABLE_ACOUSTIC_SIGNAL...ERROR DFLT=FREQUENCY_RISING VALUES=DISABLE_ACOUSTIC_SIGNAL,FREQUENCY_RISING,FREQUENCY_FALLING,FREQUENCY_RISING_AND_FALLING,FREQUENCY_ALTERNATING_LOW_HIGH,FREQUENCY_ALTERNATING_LOW_MID_HIGH,FREQUENCY_HIGHON_OFF,FREQUENCY_HIGHON_LONGOFF,FREQUENCY_LOWON_OFF_HIGHON_OFF,FREQUENCY_LOWON_LONGOFF_HIGHON_LONGOFF,LOW_BATTERY,DISARMED,INTERNALLY_ARMED,EXTERNALLY_ARMED,DELAYED_INTERNALLY_ARMED,DELAYED_EXTERNALLY_ARMED,EVENT,ERROR
LONG_SIGNAL_SELECTION_OPTICAL: ENUM [R,W] [Visible,Sticky] RANGE=DISABLE_OPTICAL_SIGNAL...CONFIRMATION_SIGNAL_2 DFLT=BLINKING_ALTERNATELY_REPEATING VALUES=DISABLE_OPTICAL_SIGNAL,BLINKING_ALTERNATELY_REPEATING,BLINKING_BOTH_REPEATING,DOUBLE_FLASHING_REPEATING,FLASHING_BOTH_REPEATING,CONFIRMATION_SIGNAL_0,CONFIRMATION_SIGNAL_1,CONFIRMATION_SIGNAL_2
SHORT_COND_VALUE_HI: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=150
SHORT_COND_VALUE_LO: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=50
SHORT_CT_OFF: ENUM [R,W] [Visible,Sticky] RANGE=VALUE_GE_LO...VALUE_L_LO_OR_GE_HI DFLT=VALUE_GE_LO VALUES=VALUE_GE_LO,VALUE_GE_HI,VALUE_L_LO,VALUE_L_HI,VALUE_GE_LO_AND_L_HI,VALUE_L_LO_OR_GE_HI
SHORT_CT_OFFDELAY: ENUM [R,W] [Visible,Sticky] RANGE=VALUE_GE_LO...VALUE_L_LO_OR_GE_HI DFLT=VALUE_GE_LO VALUES=VALUE_GE_LO,VALUE_GE_HI,VALUE_L_LO,VALUE_L_HI,VALUE_GE_LO_AND_L_HI,VALUE_L_LO_OR_GE_HI
SHORT_CT_ON: ENUM [R,W] [Visible,Sticky] RANGE=VALUE_GE_LO...VALUE_L_LO_OR_GE_HI DFLT=VALUE_GE_LO VALUES=VALUE_GE_LO,VALUE_GE_HI,VALUE_L_LO,VALUE_L_HI,VALUE_GE_LO_AND_L_HI,VALUE_L_LO_OR_GE_HI
SHORT_CT_ONDELAY: ENUM [R,W] [Visible,Sticky] RANGE=VALUE_GE_LO...VALUE_L_LO_OR_GE_HI DFLT=VALUE_GE_LO VALUES=VALUE_GE_LO,VALUE_GE_HI,VALUE_L_LO,VALUE_L_HI,VALUE_GE_LO_AND_L_HI,VALUE_L_LO_OR_GE_HI
SHORT_JT_OFF: ENUM [R,W] [Visible,Sticky] RANGE=NOP...OFF DFLT=ON VALUES=NOP,ON_DELAY,RAMP_ON,ON,OFF_DELAY,RAMP_OFF,OFF
SHORT_JT_OFFDELAY: ENUM [R,W] [Visible,Sticky] RANGE=NOP...OFF DFLT=ON VALUES=NOP,ON_DELAY,RAMP_ON,ON,OFF_DELAY,RAMP_OFF,OFF
SHORT_JT_ON: ENUM [R,W] [Visible,Sticky] RANGE=NOP...OFF DFLT=ON VALUES=NOP,ON_DELAY,RAMP_ON,ON,OFF_DELAY,RAMP_OFF,OFF
SHORT_JT_ONDELAY: ENUM [R,W] [Visible,Sticky] RANGE=NOP...OFF DFLT=ON VALUES=NOP,ON_DELAY,RAMP_ON,ON,OFF_DELAY,RAMP_OFF,OFF
SHORT_MULTIEXECUTE: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
SHORT_OFFDELAY_TIME_BASE: ENUM [R,W] [Visible,Sticky] RANGE=BASE_100_MS...BASE_1_H DFLT=BASE_100_MS VALUES=BASE_100_MS,BASE_1_S,BASE_5_S,BASE_10_S,BASE_1_M,BASE_5_M,BASE_10_M,BASE_1_H
SHORT_OFFDELAY_TIME_FACTOR: INTEGER [R,W] [Visible,Sticky] RANGE=0...31 DFLT=0
SHORT_OFF_TIME_BASE: ENUM [R,W] [Visible,Sticky] RANGE=BASE_100_MS...BASE_1_H DFLT=BASE_1_H VALUES=BASE_100_MS,BASE_1_S,BASE_5_S,BASE_10_S,BASE_1_M,BASE_5_M,BASE_10_M,BASE_1_H
SHORT_OFF_TIME_FACTOR: INTEGER [R,W] [Visible,Sticky] RANGE=0...31 DFLT=31
SHORT_OFF_TIME_MODE: ENUM [R,W] [Visible,Sticky] RANGE=TIME_IS_ABSOLUTE...TIME_IS_MINIMAL DFLT=TIME_IS_ABSOLUTE VALUES=TIME_IS_ABSOLUTE,TIME_IS_MINIMAL
SHORT_ONDELAY_TIME_BASE: ENUM [R,W] [Visible,Sticky] RANGE=BASE_100_MS...BASE_1_H DFLT=BASE_100_MS VALUES=BASE_100_MS,BASE_1_S,BASE_5_S,BASE_10_S,BASE_1_M,BASE_5_M,BASE_10_M,BASE_1_H
SHORT_ONDELAY_TIME_FACTOR: INTEGER [R,W] [Visible,Sticky] RANGE=0...31 DFLT=0
SHORT_ON_TIME_BASE: ENUM [R,W] [Visible,Sticky] RANGE=BASE_100_MS...BASE_1_H DFLT=BASE_1_M VALUES=BASE_100_MS,BASE_1_S,BASE_5_S,BASE_10_S,BASE_1_M,BASE_5_M,BASE_10_M,BASE_1_H
SHORT_ON_TIME_FACTOR: INTEGER [R,W] [Visible,Sticky] RANGE=0...31 DFLT=6
SHORT_ON_TIME_MODE: ENUM [R,W] [Visible,Sticky] RANGE=TIME_IS_ABSOLUTE...TIME_IS_MINIMAL DFLT=TIME_IS_ABSOLUTE VALUES=TIME_IS_ABSOLUTE,TIME_IS_MINIMAL
SHORT_PROFILE_ACTION_TYPE: ENUM [R,W] [Visible,Sticky] RANGE=PROFILE_ACTION_TYPE_INACTIVE...PROFILE_ACTION_TYPE_TOGGLE_DRIVE_COUNTER DFLT=PROFILE_ACTION_TYPE_JUMP VALUES=PROFILE_ACTION_TYPE_INACTIVE,PROFILE_ACTION_TYPE_JUMP,PROFILE_ACTION_TYPE_TOGGLE,PROFILE_ACTION_TYPE_DRIVE_UP,PROFILE_ACTION_TYPE_DRIVE_DOWN,PROFILE_ACTION_TYPE_TOGGLE_DRIVE_LAST_DIR,PROFILE_ACTION_TYPE_TOGGLE_DRIVE_COUNTER
SHORT_SIGNAL_SELECTION_ACOUSTIC: ENUM [R,W] [Visible,Sticky] RANGE=DISABLE_ACOUSTIC_SIGNAL...ERROR DFLT=FREQUENCY_RISING VALUES=DISABLE_ACOUSTIC_SIGNAL,FREQUENCY_RISING,FREQUENCY_FALLING,FREQUENCY_RISING_AND_FALLING,FREQUENCY_ALTERNATING_LOW_HIGH,FREQUENCY_ALTERNATING_LOW_MID_HIGH,FREQUENCY_HIGHON_OFF,FREQUENCY_HIGHON_LONGOFF,FREQUENCY_LOWON_OFF_HIGHON_OFF,FREQUENCY_LOWON_LONGOFF_HIGHON_LONGOFF,LOW_BATTERY,DISARMED,INTERNALLY_ARMED,EXTERNALLY_ARMED,DELAYED_INTERNALLY_ARMED,DELAYED_EXTERNALLY_ARMED,EVENT,ERROR
SHORT_SIGNAL_SELECTION_OPTICAL: ENUM [R,W] [Visible,Sticky] RANGE=DISABLE_OPTICAL_SIGNAL...CONFIRMATION_SIGNAL_2 DFLT=FLASHING_BOTH_REPEATING VALUES=DISABLE_OPTICAL_SIGNAL,BLINKING_ALTERNATELY_REPEATING,BLINKING_BOTH_REPEATING,DOUBLE_FLASHING_REPEATING,FLASHING_BOTH_REPEATING,CONFIRMATION_SIGNAL_0,CONFIRMATION_SIGNAL_1,CONFIRMATION_SIGNAL_2
Paramset MASTER
EVENT_DELAY_UNIT: ENUM [R,W] [Visible,Sticky] RANGE=100MS...H DFLT=S VALUES=100MS,S,M,H
EVENT_DELAY_VALUE: INTEGER [R,W] [Visible,Sticky] RANGE=0...63 DFLT=1
EVENT_RANDOMTIME_UNIT: ENUM [R,W] [Visible,Sticky] RANGE=100MS...H DFLT=S VALUES=100MS,S,M,H
EVENT_RANDOMTIME_VALUE: INTEGER [R,W] [Visible,Sticky] RANGE=0...63 DFLT=1
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Paramset VALUES
ACOUSTIC_ALARM_ACTIVE: BOOL [R,E] [Visible,Sticky] RANGE=0...1 DFLT=0
ACOUSTIC_ALARM_SELECTION: ENUM [W] [Visible,Sticky] RANGE=DISABLE_ACOUSTIC_SIGNAL...ERROR DFLT=DISABLE_ACOUSTIC_SIGNAL VALUES=DISABLE_ACOUSTIC_SIGNAL,FREQUENCY_RISING,FREQUENCY_FALLING,FREQUENCY_RISING_AND_FALLING,FREQUENCY_ALTERNATING_LOW_HIGH,FREQUENCY_ALTERNATING_LOW_MID_HIGH,FREQUENCY_HIGHON_OFF,FREQUENCY_HIGHON_LONGOFF,FREQUENCY_LOWON_OFF_HIGHON_OFF,FREQUENCY_LOWON_LONGOFF_HIGHON_LONGOFF,LOW_BATTERY,DISARMED,INTERNALLY_ARMED,EXTERNALLY_ARMED,DELAYED_INTERNALLY_ARMED,DELAYED_EXTERNALLY_ARMED,EVENT,ERROR
DURATION_UNIT: ENUM [W] [Visible,Sticky] RANGE=S...H DFLT=S VALUES=S,M,H
DURATION_VALUE: INTEGER [W] [Visible,Sticky] RANGE=0...16343 DFLT=0
OPTICAL_ALARM_ACTIVE: BOOL [R,E] [Visible,Sticky] RANGE=0...1 DFLT=0
OPTICAL_ALARM_SELECTION: ENUM [W] [Visible,Sticky] RANGE=DISABLE_OPTICAL_SIGNAL...CONFIRMATION_SIGNAL_2 DFLT=DISABLE_OPTICAL_SIGNAL VALUES=DISABLE_OPTICAL_SIGNAL,BLINKING_ALTERNATELY_REPEATING,BLINKING_BOTH_REPEATING,DOUBLE_FLASHING_REPEATING,FLASHING_BOTH_REPEATING,CONFIRMATION_SIGNAL_0,CONFIRMATION_SIGNAL_1,CONFIRMATION_SIGNAL_2
Hallo,
habe auch mal auf die beta upgedatet. Sofern es reicht update update all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
Übers fhem webinterface zu laden und ein shutdown restart durchzuführen.
Edit: Version Version 4.4.051 ist installiert.
Habe leider im Moment erst nur zwei HmIP-SWDM-B2 zum Testen.
Wennich hier in HMCCUCHN device set HmIP_SWDM_B2 defaults reset eingebe bekomme ich die Meldung:
HMCCUCHN: HmIP_SWDM_B2 No default attributes found.
Hier list vom device:
Internals:
DEF 001559939578A5:1 readonly
FUUID 5fa7d18e-f33f-6571-c933-01c427cb660c02f7
IODev d_ccu
NAME HmIP_SWDM_B2
NR 449
STATE open
TYPE HMCCUCHN
ccuaddr 001559939578A5:1
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-SWDM-B2 001559939578A5:1
ccutype HmIP-SWDM-B2
channels 1
chntype SHUTTER_CONTACT
firmware 1.2.12
statevals readonly
READINGS:
2020-11-11 19:12:35 1.STATE open
2020-11-11 18:56:34 R-1.ALARM_MODE_TYPE 0
2020-11-11 18:56:34 R-1.ALARM_MODE_ZONE_1 0
2020-11-11 18:56:34 R-1.ALARM_MODE_ZONE_2 0
2020-11-11 18:56:34 R-1.ALARM_MODE_ZONE_3 0
2020-11-11 18:56:34 R-1.ALARM_MODE_ZONE_4 0
2020-11-11 18:56:34 R-1.ALARM_MODE_ZONE_5 0
2020-11-11 18:56:34 R-1.ALARM_MODE_ZONE_6 0
2020-11-11 18:56:34 R-1.ALARM_MODE_ZONE_7 0
2020-11-11 18:56:34 R-1.EVENT_DELAY_UNIT 0
2020-11-11 18:56:34 R-1.EVENT_DELAY_VALUE 0
2020-11-11 18:56:34 R-1.MSG_FOR_POS_A 2
2020-11-11 18:56:34 R-1.MSG_FOR_POS_B 1
2020-11-11 18:56:34 R-1.SAMPLE_INTERVAL 0.5
2020-11-11 19:12:35 control open
2020-11-11 19:12:35 hmstate open
2020-11-11 19:12:35 state open
hmccu:
devspec 001559939578A5:1
dp:
0.CONFIG_PENDING:
OVAL 0
VAL 0
0.DUTY_CYCLE:
OVAL 0
VAL 0
0.INSTALL_TEST:
OVAL true
VAL true
0.LOW_BAT:
OVAL 0
VAL 0
0.OPERATING_VOLTAGE:
OVAL 3.0
VAL 3.0
0.OPERATING_VOLTAGE_STATUS:
OVAL 0
VAL 0
0.RSSI_DEVICE:
OVAL -56
VAL -46
0.RSSI_PEER:
OVAL 0
VAL 0
0.UNREACH:
OVAL 0
VAL 0
0.UPDATE_PENDING:
OVAL false
VAL false
1.STATE:
OSVAL open
OVAL 1
SVAL open
VAL 1
Attributes:
IODev d_ccu
ccureadingfilter (ERROR|LOWBAT|STATE)
devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
event-on-change-reading .*
room CCU_HM
substitute STATE!(0|false):closed,(1|true):open;;LOWBAT!(0|false):no,(1|true):yes
Gruß Holger
Noch einer (der letzte für heute).
Bei einem HmIP-SPI werden als Attribute gesetzt:
webCmd control
widgetOverride control:uzsuToggle,off,on
Die funktionieren nicht (sollen wahrscheinlich die Erkennung de-/aktivieren).
Zitat von: The-Holgi am 11 November 2020, 19:27:37
Hallo,
habe auch mal auf die beta upgedatet. Sofern es reicht update update all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
Übers fhem webinterface zu laden und ein shutdown restart durchzuführen.
Edit: Version Version 4.4.051 ist installiert.
Habe leider im Moment erst nur zwei HmIP-SWDM-B2 zum Testen.
Wennich hier in HMCCUCHN device set HmIP_SWDM_B2 defaults reset eingebe bekomme ich die Meldung:
Mach mal bitte folgendes:
get d_ccu deviceInfo "HmIP-SWDM-B2 001559939578A5"
Nach Eingabe bekomme ich:
CHN 001559939578A5:0 HmIP-SWDM-B2 001559939578A5:0
DPT {b} HmIP-RF.001559939578A5:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.001559939578A5:0.DUTY_CYCLE = false [RE]
DPT {b} HmIP-RF.001559939578A5:0.INSTALL_TEST = true [RW]
DPT {b} HmIP-RF.001559939578A5:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.001559939578A5:0.OPERATING_VOLTAGE = 3.000000 [RE]
DPT {i} HmIP-RF.001559939578A5:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.001559939578A5:0.RSSI_DEVICE = 208 [RE]
DPT {n} HmIP-RF.001559939578A5:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.001559939578A5:0.UNREACH = false [RE]
DPT {b} HmIP-RF.001559939578A5:0.UPDATE_PENDING = false [RE]
CHN 001559939578A5:1 HmIP-SWDM-B2 001559939578A5:1
DPT {i} HmIP-RF.001559939578A5:1.STATE = 1 [RE]
<br/>StateDatapoint = ?.?
ControlDatapoint = ?.?
Device 001559939578A5 HmIP-SWDM-B2 001559939578A5 [HmIP-SWDM-B2]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 001559939578A5:0,001559939578A5:1,001559939578A5:2
DIRECTION: NONE
FIRMWARE: 1.2.12
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 4461639
ROAMING: 0
RX_MODE: CONFIG
SUBTYPE: SWDM
UPDATABLE: 1
Channel 001559939578A5:0 HmIP-SWDM-B2 001559939578A5:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 001559939578A5
PARENT_TYPE: HmIP-SWDM-B2
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 001559939578A5:1 HmIP-SWDM-B2 001559939578A5:1 [SHUTTER_CONTACT]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH,WINDOW_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 001559939578A5
PARENT_TYPE: HmIP-SWDM-B2
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 001559939578A5:2 HmIP-SWDM-B2 001559939578A5:2 [ALARM_COND_SWITCH_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS:
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 001559939578A5
PARENT_TYPE: HmIP-SWDM-B2
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Ich habe ein Update eingecheckt (4.4.052). Änderungen:
- Unterstützung der Kanaltypen "WEATHER", "WEATHER_TRANSMIT" und "CLIMATE_TRANSCEIVER"
- Korrektur für Sensoren, SHUTTER_CONTACT
- Korrektur/Ergänzung von cmdIcons für Rollläden und Jalousien
@The-Holgi: Bitte den Fenstersensor mal löschen und neu anlegen (als HMCCUCHN).
@kjmEjfu: ccucalculate mit "dewpoint" funktioniert bei mir. Rollladen bitte nochmal testen.
An den anderen gemeldeten Dingen bin ich dran (Alarmsirene).
Zitat von: zap am 13 November 2020, 16:21:57
@The-Holgi: Bitte den Fenstersensor mal löschen und neu anlegen (als HMCCUCHN).
Habe ich gemacht, das device wird sauber mit allen readings angekegt.
Ubrigens vieken Dank für Deine Arbeit hier.
Internals:
CFGFN
DEF 001559939578A5:1 readonly
FUUID 5faea8f8-f33f-6571-08d2-a9a7d7a3fb3027d3
IODev d_ccu
NAME HmIP_SWDM_B2_1
NR 543
STATE open
TYPE HMCCUCHN
ccuaddr 001559939578A5:1
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-SWDM-B2 001559939578A5:1
ccutype HmIP-SWDM-B2
readonly yes
OLDREADINGS:
READINGS:
2020-11-13 16:50:48 STATE open
2020-11-13 16:50:48 activity alive
2020-11-13 16:50:48 battery ok
2020-11-13 16:50:48 control open
2020-11-13 16:50:48 devstate ok
2020-11-13 16:50:48 hmstate open
2020-11-13 16:50:48 state open
hmccu:
channels 1
devspec 001559939578A5:1
nodefaults 0
role 1:SHUTTER_CONTACT
semDefaults 0
cmdlist:
get
set
control:
chn 1
dpt STATE
dp:
0.ARR_TIMEOUT:
MASTER:
OSVAL 10
OVAL 10
SVAL 10
VAL 10
VALUES:
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.CYCLIC_INFO_MSG:
MASTER:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
0.CYCLIC_INFO_MSG_DIS:
MASTER:
OSVAL 30
OVAL 30
SVAL 30
VAL 30
VALUES:
0.CYCLIC_INFO_MSG_DIS_UNCHANGED:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
0.CYCLIC_INFO_MSG_OVERDUE_THRESHOLD:
MASTER:
OSVAL 2
OVAL 2
SVAL 2
VAL 2
VALUES:
0.DUTYCYCLE_LIMIT:
MASTER:
OSVAL 180
OVAL 180
SVAL 180
VAL 180
VALUES:
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ENABLE_ROUTING:
MASTER:
OSVAL true
OVAL 1
SVAL true
VAL 1
VALUES:
0.LOCAL_RESET_DISABLED:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
0.LOW_BAT:
VALUES:
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.LOW_BAT_LIMIT:
MASTER:
OSVAL 2.2
OVAL 2.2
SVAL 2.2
VAL 2.2
VALUES:
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 3.0
OVAL 3.0
SVAL 3.0
VAL 3.0
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -59
OVAL -59
SVAL -59
VAL -59
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
1.ALARM_MODE_TYPE:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.ALARM_MODE_ZONE_1:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.ALARM_MODE_ZONE_2:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.ALARM_MODE_ZONE_3:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.ALARM_MODE_ZONE_4:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.ALARM_MODE_ZONE_5:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.ALARM_MODE_ZONE_6:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.ALARM_MODE_ZONE_7:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.EVENT_DELAY_UNIT:
MASTER:
OSVAL 100MS
OVAL 0
SVAL 100MS
VAL 0
VALUES:
1.EVENT_DELAY_VALUE:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.MSG_FOR_POS_A:
MASTER:
OSVAL OPEN
OVAL 2
SVAL OPEN
VAL 2
VALUES:
1.MSG_FOR_POS_B:
MASTER:
OSVAL CLOSED
OVAL 1
SVAL CLOSED
VAL 1
VALUES:
1.SAMPLE_INTERVAL:
MASTER:
OSVAL 0.5
OVAL 0.5
SVAL 0.5
VAL 0.5
VALUES:
1.STATE:
VALUES:
OSVAL open
OVAL 1
SVAL open
VAL 1
roleCmds:
get:
set:
state:
chn 1
dpt STATE
Attributes:
IODev d_ccu
room CCU_HMGruß Holger
So, ich habe dann mal geschaut.
- Rollos: sieht gut aus
- dewpoint: funktioniert leider weiterhin nicht.
Internals:
DEF XXX
FUUID 5c65342e-f33f-8030-a570-39f2c93b6316fbcb
FVERSION 88_HMCCUDEV.pm:v4.4.34-s18552/2019-02-10
IODev d_ccu
NAME Sensor_Aussen_Carport_Temperatur
NR 244
STATE T: 9.9°C | H: NORMAL% | D: dewpoint°C
TYPE HMCCUDEV
ccuaddr XXX
ccudevstate active
ccuif HmIP-RF
ccuname HM-Temperatur-Aussen-Carport
ccutype HmIP-STHO
readonly no
Helper:
DBLOG:
humidity:
TE.DbLogMySQL:
TIME 1605285984.62938
VALUE NORMAL
OLDREADINGS:
READINGS:
2020-11-13 17:46:24 1.ACTUAL_TEMPERATURE 9.9
2020-11-13 17:46:24 1.ACTUAL_TEMPERATURE_STATUS NORMAL
2020-11-13 17:46:24 1.HUMIDITY 97
2020-11-13 17:46:24 1.HUMIDITY_STATUS NORMAL
2020-11-13 17:46:24 activity alive
2020-11-13 17:46:24 battery ok
2020-11-13 17:46:24 control 9.9
2020-11-13 17:46:24 devstate ok
2020-11-13 17:46:24 hmstate ok
2020-11-13 17:46:24 humidity NORMAL
2020-11-13 17:46:24 measured-temp 9.9
2020-11-13 17:46:24 statHumidityDay Min: 0 Avg: 98 Max: 97
2020-11-13 17:46:24 statHumidityMonth Min: 0 Avg: 89 Max: 97
2020-11-13 17:46:24 statHumidityYear Min: 0 Avg: 76 Max: 97 (since: )
2020-11-13 17:46:24 state 9.9
2020-11-13 17:46:24 taupunkt 9.4
2020-11-13 17:46:24 temperature.av 0.000
[...]
Attributes:
DbLogInclude temperature,humidity
IODev d_ccu
alexaName Aussentemperatur
alexaRoom Aussen
alias Temperatur Außen
ccucalculate dewpoint:taupunkt:1.ACTUAL_TEMPERATURE,1.HUMIDITY
ccureadingname 1.HUMIDITY:+humidity
event-on-change-reading .*
group Temperatur
icon temp_outside
mqttPublish statTemperatureDay|statTemperatureYear|statTemperatureDayMax|statTemperatureDayMin|statTemperatureDayLast|temperature|humidity|dewpoint:topic={"$base/wetter/temperatur/$name"} *:retain=1 *:resendOnConnect=last
room 05_Datenquellen,Homematic,alexa
stateFormat T: measured-temp°C | H: humidity% | D: dewpoint°C
stripnumber 1
userReadings temperature.av {movingAverage("Sensor_Aussen_Carport_Temperatur","temperature",600)}
Interessant ist auch, dass er mir ins Reading "humidity" den Inhalt von 1.HUMIDITY_STATUS NORMAL statt 1.HUMIDITY schreibt. Liegt aber vermutlich an der RegEx.
Ok, das ging vorher aus irgendeinem Grunde ohne abschließendes $. Funktioniert.
Bei diesem Device
Internals:
DEF XXXX
FUUID 5c44645e-f33f-8030-dc3a-3abbbb20786bf5ed
FVERSION 88_HMCCUDEV.pm:v4.4.34-s18552/2019-02-10
IODev d_ccu
NAME Sensor_OG_Allrum_Temperatur
NR 130
STATE T: 22.6°C | H: 54% | D: dewpoint °C
TYPE HMCCUDEV
ccuaddr XXXX
ccudevstate active
ccuif HmIP-RF
ccuname HM-Temperatur-Wohnzimmer
ccutype HmIP-STH
readonly no
receiver HM_FBH_EG_Gesamt,HM_FBH_OG_Gesamt
Helper:
DBLOG:
humidity:
TE.DbLogMySQL:
TIME 1605285443.58212
VALUE 54
OLDREADINGS:
READINGS:
2020-11-13 17:37:23 1.ACTIVE_PROFILE 1
2020-11-13 17:37:23 1.ACTUAL_TEMPERATURE 22.6
2020-11-13 17:37:23 1.ACTUAL_TEMPERATURE_STATUS NORMAL
2020-11-13 17:37:23 1.BOOST_MODE false
2020-11-13 17:37:23 1.BOOST_TIME 0
2020-11-13 17:37:23 1.FROST_PROTECTION false
2020-11-13 17:37:23 1.HEATING_COOLING HEATING
2020-11-13 17:37:23 1.HUMIDITY 54
2020-11-13 17:37:23 1.HUMIDITY_STATUS NORMAL
2020-11-13 17:37:23 1.PARTY_MODE false
2020-11-13 17:15:04 1.PARTY_SET_POINT_TEMPERATU 0.0
2020-11-13 17:15:04 1.PARTY_TIME_END
2020-11-13 17:15:04 1.PARTY_TIME_START
2020-11-13 17:37:23 1.QUICK_VETO_TIME 0
2020-11-13 17:37:23 1.SET_POINT_MODE 0
2020-11-13 17:37:23 1.SET_POINT_TEMPERATURE 21.0
2020-11-13 17:37:23 1.SWITCH_POINT_OCCURED false
2020-11-13 17:37:23 1.WINDOW_STATE closed
2020-11-13 17:37:23 activity alive
2020-11-13 17:37:23 battery ok
2020-11-13 17:37:23 control 21.0
2020-11-13 17:37:23 desired-temp 21.0
2020-11-13 17:37:23 devstate ok
2020-11-13 17:37:23 hmstate T:
2020-11-13 17:37:23 humidity 54
2020-11-13 17:37:23 lueftenErhoehtLuftfeuchtigkeit ja
2020-11-13 17:37:23 lueftenLuftfeuchtigkeit 641.0
2020-11-13 17:37:23 measured-temp 22.6
2020-11-13 17:37:23 schimmelGefahr ja
2020-11-13 17:37:23 statHumidityDay Min: 0 Avg: 52 Max: 54
2020-11-13 17:37:23 statHumidityMonth Min: 0 Avg: 52 Max: 54
2020-11-13 17:37:23 statHumidityYear Min: 0 Avg: 51 Max: 54 (since: )
2020-11-13 17:37:23 state 22.6
2020-11-13 17:37:23 taupunkt 12.8
helper:
_98_statistics Statistik
hmccu:
channels 8
devspec XXXX
nodefaults 1
role
[...]
Attributes:
DbLogInclude temperature,humidity
IODev d_ccu
alexaName Wohnbereich
alexaRoom Innen
alias Temperatur Oben
ccucalculate dewpoint:taupunkt:1.ACTUAL_TEMPERATURE,1.HUMIDITY
ccureadingname 1.HUMIDITY:+humidity
cmdIcon auto:sani_heating_automatic manu:sani_heating_manual boost:sani_heating_boost on:general_an off:general_aus
event-on-change-reading .*
genericDeviceType thermometer
group Temperatur
hmstatevals (ACTUAL_TEMPERATURE|HUMIDITY)!.*:T: ${ACTUAL_TEMPERATURE}°C H: ${HUMIDITY}%;
icon temp_inside
mqttPublish temperature|humidity|dewpoint:topic={"$base/og/$name"} *:retain=1 *:resendOnConnect=last
room 05_Datenquellen,Homematic,alexa
stateFormat T: measured-temp°C | H: humidity% | D: dewpoint °C
statedatapoint 1.ACTUAL_TEMPERATURE
stripnumber 1
substexcl desired-temp
zieht er, für mich, seltsamerweise den richtigen Wert ins humidity. Den ccucalculate ignoriert er aber trotzdem.
Funktioniert jetzt auch. Irgendwas brauchte da noch einige Minuten um richtig zu laufen.
- FSM ist auch spannend:
Internals:
DEF AAA
FUUID 5c446461-f33f-8030-d95e-43f3a633b3460a8c
FVERSION 88_HMCCUDEV.pm:v4.4.34-s18552/2019-02-10
IODev d_ccu
NAME Licht_EG_Garderobe
NR 222
STATE false
TYPE HMCCUDEV
ccuaddr AAA
ccudevstate active
ccuif HmIP-RF
ccuname HM-Licht-EG-Garderobe
ccutype HmIP-FSM
readonly no
OLDREADINGS:
READINGS:
2020-11-13 17:46:05 1.PROCESS STABLE
2020-11-13 17:46:05 1.SECTION 0
2020-11-13 17:46:05 1.SECTION_STATUS NORMAL
2020-11-13 17:46:05 1.STATE false
2020-11-13 17:46:05 2.PROCESS STABLE
2020-11-13 17:46:05 2.SECTION 0
2020-11-13 17:46:05 2.SECTION_STATUS NORMAL
2020-11-13 17:46:05 2.STATE off
2020-11-13 17:46:05 3.PROCESS STABLE
2020-11-13 17:46:05 3.SECTION 0
2020-11-13 17:46:05 3.SECTION_STATUS NORMAL
2020-11-13 17:46:05 3.STATE off
2020-11-13 17:46:05 4.PROCESS STABLE
2020-11-13 17:46:05 4.SECTION 0
2020-11-13 17:46:05 4.SECTION_STATUS NORMAL
2020-11-13 17:46:05 4.STATE off
2020-11-13 17:46:05 5.CURRENT 0.0
2020-11-13 17:46:05 5.CURRENT_STATUS NORMAL
2020-11-13 17:46:05 5.ENERGY_COUNTER 2116.3
2020-11-13 17:46:05 5.ENERGY_COUNTER_OVERFLOW false
2020-11-13 17:46:05 5.FREQUENCY 50.0
2020-11-13 17:46:05 5.FREQUENCY_STATUS NORMAL
2020-11-13 17:46:05 5.POWER 0.0
2020-11-13 17:46:05 5.POWER_STATUS NORMAL
2020-11-13 17:46:05 5.VOLTAGE 228.8
2020-11-13 17:46:05 5.VOLTAGE_STATUS NORMAL
2020-11-13 17:46:05 7.WEEK_PROGRAM_CHANNEL_LOCKS 0
2020-11-13 17:46:05 activity alive
2020-11-13 17:46:05 control off
2020-11-13 17:46:05 devstate ok
2020-11-13 17:46:05 hmstate ok
2020-11-13 17:46:05 state false
hmccu:
channels 8
devspec AAA
nodefaults 1
role
[...]
Attributes:
IODev d_ccu
alias Licht Garderobe
controldatapoint 2.STATE
event-on-change-reading .*
group Licht
room 0000toFix,Homematic
statedatapoint 1.STATE
statevals on:true,off:false
substitute STATE!(true|1):on,(false|0):off
da ignoriert er mein substitute, wodurch 1.STATE immer auf "false" bleibt. Und dann sieht es aus wie im Anhang. Finde ich nicht so schön, außerdem mag ich es lieber wenn das Lampen-Symbol erscheint. Zusätzlich mag er "on" und "off" nicht. Werden zwar im Setter angezeigt, führen aber zu "Unknown argument on, choose one of clear defaults config datapoint toggle". Erscheint vermutlich, weil im statevals hinterlegt.
- Ich bin mir nicht sicher, ob es generell immer die beste Möglichkeit ist bei DEV den state aus dem 4er Datapoint zu ziehen. So habe ich z.B. BDTs bei denen ich mit Automatismen den 4.LEVEL setze, per Hand (direkt am Schalter) aber 5.LEVEL. In der CCU3 ist definiert, dass 5.LEVEL vor 4.LEVEL geht. Insofern ist der Wert aus 4.LEVEL falsch, der aktuell richtige steht in 3.LEVEL. Aber keine Ahnung, ob das jetzt ein spezifisches "Problem" bei mir ist.
- HmIP-SWSD: da wurde vorher noch gesetzt
substitute
SMOKE_DETECTOR_ALARM_STAT!(1|true):Alarm,(0|false):noAlarm
fand ich ganz sinnvoll. Das Attribut wird jetzt gelöscht. Stattdessen steht halt 0 oder 1 im State.
Noch eine anderer Punkt. Bei den HM-LC-Bl1-FM wurden vor der 4.4 1.DIRECTION und 1.WORKING in die Readings direction und working umgewandelt, jetzt halt nicht mehr. Könnte mir vorstellen, dass dies nach einem Update bei dem einen oder anderen zu Fehlern in der Rollosteuerung kommen könnte.
Und letzter Punkt: löschst du beim "set defaults reset" gleich das ccureadingname mit? In einem Device sind die gerade verschwunden, bin nicht sicher ob es am defaults liegt. Falls doch, wäre es fies ;-)
Zitat von: kjmEjfu am 13 November 2020, 18:21:20
Noch eine anderer Punkt. Bei den HM-LC-Bl1-FM wurden vor der 4.4 1.DIRECTION und 1.WORKING in die Readings direction und working umgewandelt, jetzt halt nicht mehr. Könnte mir vorstellen, dass dies nach einem Update bei dem einen oder anderen zu Fehlern in der Rollosteuerung kommen könnte.
Und letzter Punkt: löschst du beim "set defaults reset" gleich das ccureadingname mit? In einem Device sind die gerade verschwunden, bin nicht sicher ob es am defaults liegt. Falls doch, wäre es fies ;-)
Die Defaults der alten Version 4.3 enthalten keine Readings direction und working.
Die Readings "direction" und "working" kannst Du recht einfach bekommen. Zwei Möglichkeiten:
1. Mit ccureadingname
2. Mit ccureadingformat=datapointlc (bei einem HMCCUCHN Device) oder ccureadingformat=%n
Der Befehl "set defaults reset" löscht folgende Attribute (sofern der Kanaltyp von HMCCU erkannt und unterstützt wird):
'ccureadingname', 'ccuscaleval', 'eventMap', 'cmdIcon', 'substitute', 'webCmd', 'widgetOverride'
ccureadingname wird gelöscht, weil z.B. Datenpunkte wie TEMPERATURE oder ACTUAL_TEMPERATURE nun automatisch in "measured-temp" umgewandelt werden.
Zitat von: zap am 14 November 2020, 18:56:02
Die Defaults der alten Version 4.3 enthalten keine Readings direction und working.
Die Readings "direction" und "working" kannst Du recht einfach bekommen. Zwei Möglichkeiten:
1. Mit ccureadingname
2. Mit ccureadingformat=datapointlc (bei einem HMCCUCHN Device) oder ccureadingformat=%n
Dubios, wo hatte ich die denn dann her?
Vielleicht habe ich irgendeine andere Vorlage für die Rollos genutzt bevor du dazu ein Default hattest und es dann nicht angepasst.
Was macht ccureadingformat=%n ?
Zitat von: zap am 14 November 2020, 18:56:02
Der Befehl "set defaults reset" löscht folgende Attribute (sofern der Kanaltyp von HMCCU erkannt und unterstützt wird):
'ccureadingname', 'ccuscaleval', 'eventMap', 'cmdIcon', 'substitute', 'webCmd', 'widgetOverride'
ccureadingname wird gelöscht, weil z.B. Datenpunkte wie TEMPERATURE oder ACTUAL_TEMPERATURE nun automatisch in "measured-temp" umgewandelt werden.
Vielleicht wäre es eine Variante bei existierendem ccureadingname eher einen Hinweis anzuzeigen, dass für das aktuelle Device automatisch die Readings X, Y, Z erstellt werden und man diese nicht mehr per ccureadingname anlegen muss?
Weil wie gesagt, da kann ja durchaus - aus welchen Gründen auch immer - eine handvoll Readings drin definiert sein, die man hinterher noch braucht. Ist blöd, wenn die plötzlich fehlen, man das eventuell nicht realisiert, auf "save" drückt und hinterher Fehlfunktionen hat.
Aber das ist nur meine gerade aktuelle Meinung ;-)
Zitat von: kjmEjfu am 14 November 2020, 19:30:16
Was macht ccureadingformat=%n ?
Siehe commandref zu HMCCUCHN. Das Attribut erlaubt nun auch eine freie Formatierung der Readingnamen mit Platzhaltern.
Zitat
Vielleicht wäre es eine Variante bei existierendem ccureadingname eher einen Hinweis anzuzeigen, dass für das aktuelle Device automatisch die Readings X, Y, Z erstellt werden und man diese nicht mehr per ccureadingname anlegen muss?
Weil wie gesagt, da kann ja durchaus - aus welchen Gründen auch immer - eine handvoll Readings drin definiert sein, die man hinterher noch braucht. Ist blöd, wenn die plötzlich fehlen, man das eventuell nicht realisiert, auf "save" drückt und hinterher Fehlfunktionen hat.
Aber das ist nur meine gerade aktuelle Meinung ;-)
Ich denke mal darüber nach. Letztlich ist es jedem überlassen, für existierende Devides "set defaults reset" auszuführen. Die bisherigen Attribute werden ja weiter unterstützt und sollten auch funktionieren. Das einzige Attribut, was man ersetzen sollte, ist eventMap. HMCCU baut die Befehle je nach Gerätetyp nun automatisch zusammen. Das kann sich mit eventMap übel ins Gehege kommen.
Zitat von: kjmEjfu am 11 November 2020, 19:15:51
Ok, hab die beim BDT gelöscht.
on/off fehlen aber immer noch im set.
Kannst Du bitte den Dimmer nochmal neu anlegen? Falls auch das neue Device kein on/off hat, gib mal beim Define noch 4 an, also
define xy HMCCUDEV Adresse 4
die BDTs funktionieren mittlerweile einwandfrei.
Bleiben, zumindest bei mir, noch die FSM und halt die Sirene, wobei die keine Prio hat.
Zitat von: zap am 09 November 2020, 08:16:25
Für den Benutzer bedeutet es (hoffentlich), dass die Definition von Geräten einfacher wird. HMCCU erkennt nun anhand der Kanalrolle, wie ein Gerät eingebunden werden muss. Viele der aktuellen Attribute werden dadurch überflüssig, werden aber weiterhin unterstützt. Man kann ein schon existierendes HMCCUDEV oder HMCCUCHN Device auf die neuen Defaults umstellen, indem man den Befehl "set defaults reset" ausführt.
Die gebräuchlichsten Geräte wie Thermostate, Schalter, Rollladen usw werden jetzt schon unterstützt. Da die alten Defaults nach wir vor vorhanden sind, kann eigentlich nichts bzw wenig schiefgehen.
Natürlich bleibt ein Restrisikio. Trotzdem würde ich jedem, der jetzt über den Einstieg mit HMCCU nachdenkt, gleich mit der 4.4 Beta zu starten.
Für alle anderen, die einen existierende HMCCU Umgebung haben, empfehle ich: probiert die Umstellung mal aus. Dabei würde ich so vorgehen:
- fhem.cfg sichern
- RPC Server stoppen (set rpcserver off)
- Autostart der RPC Server deaktivieren (attr rpcserver off)
- Update auf 4.4. Beta durchführen (siehe 1. Post in diesem Thread, am besten die Github Quelle verwenden)
- FHEM neu starten
- Optional: die Defaults bei einigen / allen Geräten zurücksetzen (set defaults reset)
- RPC Server starten
Es wäre für mich sehr hilfreich, wenn das möglichst viele versuchen und Feedback geben.
Falls Ihr zurück auf die alte Version wollt:
- RPC Server stoppen
- Normales FHEM Update ausführen
- FHEM stoppen
- Alte fhem.cfg zurück kopieren
- FHEM starten
Hallo zap,
habe heute auch den ersten produktiven "pi" nach Deiner Anleitung umgesetzt. Zusätzlich habe ich diese Readings gelöscht
controldatapoint, statedatapoint, statevals Dies hatte beim IP-Lichtschalter zur Folge, dass er nicht mehr funktioniert hat. Wie kann ich denn diese INfo überprüfen ?
Diese Attribute sind überflüssig, wenn HMCCU den Channel-Typ erkennt. Viele Grüße
Jürgen
Hallo zap,
hier noch das list:
Internals:
DEF 000858A9ABDF0E
FUUID 5f11db9b-f33f-ca7c-9c19-805ae6025d7e9b4c
IODev HMCCU3
NAME HmIP_BSM_000858A9ABDF0E
NR 329
STATE on
TYPE HMCCUDEV
ccuaddr 000858A9ABDF0E
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-BSM 000858A9ABDF0E
ccutype HmIP-BSM
readonly no
receiver HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E
sender HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E
OLDREADINGS:
READINGS:
2020-11-15 20:16:19 3.STATE on
2020-11-15 20:16:19 4.STATE on
2020-11-15 20:16:19 5.STATE off
2020-11-15 20:16:19 6.STATE off
2020-11-15 20:16:24 activity alive
2020-11-15 20:16:19 control on
2020-11-15 20:16:24 devstate ok
2020-11-15 20:16:24 hmstate on
2020-11-15 20:16:19 state on
hmccu:
channels 10
devspec 000858A9ABDF0E
nodefaults 1
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:KEY_TRANSCEIVER,3:SWITCH_TRANSMITTER,4:SWITCH_VIRTUAL_RECEIVER,5:SWITCH_VIRTUAL_RECEIVER,6:SWITCH_VIRTUAL_RECEIVER,7:ENERGIE_METER_TRANSMITTER,8:COND_SWITCH_TRANSMITTER,9:SWITCH_WEEK_PROFILE
semDefaults 0
cmdlist:
get
set off:noArg on-for-timer on-till on:noArg toggle:noArg
control:
chn 4
dpt STATE
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
OSVAL 26.0
OVAL 26.000000
SVAL 26.0
VAL 26.000000
0.ACTUAL_TEMPERATURE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -56
OVAL -56
SVAL -59
VAL -59
0.RSSI_PEER:
VALUES:
OSVAL -55
OVAL -55
SVAL -50
VAL -50
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
3.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
3.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 2
VAL 2
3.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
3.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL on
VAL 1
4.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
4.SECTION:
VALUES:
OSVAL 2
OVAL 2
SVAL 2
VAL 2
4.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.STATE:
VALUES:
OSVAL on
OVAL 1
SVAL on
VAL 1
5.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
5.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
5.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
6.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
6.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
6.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
7.CURRENT:
VALUES:
OSVAL 0.0
OVAL 0.0
SVAL 115.0
VAL 115.0
7.CURRENT_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.ENERGY_COUNTER:
VALUES:
OSVAL 9511.4
OVAL 9511.4
SVAL 9511.4
VAL 9511.4
7.ENERGY_COUNTER_OVERFLOW:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
7.FREQUENCY:
VALUES:
OSVAL 50.0
OVAL 49.98
SVAL 50.0
VAL 49.98
7.FREQUENCY_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.POWER:
VALUES:
OSVAL 0.0
OVAL 0.0
SVAL 25.5
VAL 25.53
7.POWER_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.VOLTAGE:
VALUES:
OSVAL 225.8
OVAL 225.8
SVAL 226.8
VAL 226.8
7.VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
9.WEEK_PROGRAM_CHANNEL_LOCKS:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
roleCmds:
get:
set:
off:
channel 4
role SWITCH_VIRTUAL_RECEIVER
subcount 1
syntax V:STATE:0
usage off
subcmd:
000:
args 0
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on:
channel 4
role SWITCH_VIRTUAL_RECEIVER
subcount 1
syntax V:STATE:1
usage on
subcmd:
000:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on-for-timer:
channel 4
role SWITCH_VIRTUAL_RECEIVER
subcount 2
syntax V:ON_TIME:?duration V:STATE:1
usage on-for-timer duration
subcmd:
000:
args 0.0
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname duration
partype 2
ps VALUES
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on-till:
channel 4
role SWITCH_VIRTUAL_RECEIVER
subcount 2
syntax V:ON_TIME:?duration V:STATE:1
usage on-till duration
subcmd:
000:
args 0.0
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname duration
partype 2
ps VALUES
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
state:
chn 4
dpt STATE
Attributes:
IODev HMCCU3
alexaName Licht im Büro
alias HM Lichtschalter Büro
assistantName Licht im Büro
ccureadingfilter (STATE|PRESS)
controldatapoint 4.STATE
devStateStyle style="text-align:right"
event-on-change-reading .*
group HM Funkschalter
icon li_wht_dimmer
room Alexa,Büro,GoogleAssistant,Homematic,Schaltzentrale
sortby 09
statedatapoint 4.STATE
statevals on:true,off:false
substitute STATE!(true|1):on,(false|0):off
userattr Schalter Schalter_map structexclude
webCmd :
widgetOverride control:uzsuToggle,off,on
Wenn die Readings controldatapoint, statedatapoint, statevalsvorhanden sind, gibt es keine Probleme.
Viele Grüße
Jürgen
Mir ist gerade noch etwas aufgefallen.
Bei einem HM-LC-Sw4-DR-2 oder HM-LC-Sw4-DR gibt es pro Kanal auch ein INHIBIT.
Beim DR-2 wird der Wert durchgelassen und ein entsprechendes Reading angelegt. Beim DR hingegen nicht. (ich nutze die per CHN, nicht als DEV).
Wenn ich nun INHIBIT auf locked (also true) setze, dann kann ich trotzdem fröhlich ein- und ausschalten. Die CCU scheint das gar nicht zu prüfen.
Frage bzw. Diskussionspunkt: macht es Sinn, wenn das Modul auf locked prüft und dann Schaltbefehle unterbindet? Alternative wäre, dass man selber immer prüfen muss.
inhibit gilt nur für peers.
über zentrale kann immer geschaltet werden.
Und wenn ich jetzt per DOIF aus FHEM schalte, bin ich dann eher als Peer oder als Zentrale unterwegs? Also jetzt nicht vom technischen Standpunkt, da bin ich eindeutig als Zentrale tätig. Ich meine von der Aktion her.
peers sind direkt verbundene/gekoppelte geräte.
bei cul_hm könnte man virtuelle geräte definieren, die mit einer eigenen id funken, und diese mit dem aktor peeren.
dann würde ein inhibit im aktor die trigger des virtuellen devices blocken.
über ccu kenne ich dieses vorgehen nicht.
Zitat von: juemuc am 15 November 2020, 20:27:40
Hallo zap,
habe heute auch den ersten produktiven "pi" nach Deiner Anleitung umgesetzt. Zusätzlich habe ich diese Readings gelöscht
controldatapoint, statedatapoint, statevals Dies hatte beim IP-Lichtschalter zur Folge, dass er nicht mehr funktioniert hat. Wie kann ich denn diese INfo überprüfen ?Diese Attribute sind überflüssig, wenn HMCCU den Channel-Typ erkennt.
Viele Grüße
Jürgen
Führe mal bitte den Befehl "get deviceinfo" aus.
Hallo zap.
anbei die gewünschte Info:
CHN 000858A9ABDF0E:0 HmIP-BSM 000858A9ABDF0E:0
DPT {f} HmIP-RF.000858A9ABDF0E:0.ACTUAL_TEMPERATURE = 25.000000 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:0.ACTUAL_TEMPERATURE_STATUS = 0 [RE]
DPT {b} HmIP-RF.000858A9ABDF0E:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.000858A9ABDF0E:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.000858A9ABDF0E:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.000858A9ABDF0E:0.ERROR_OVERHEAT = false [RE]
DPT {b} HmIP-RF.000858A9ABDF0E:0.INSTALL_TEST = true [RW]
DPT {f} HmIP-RF.000858A9ABDF0E:0.OPERATING_VOLTAGE = 0.000000 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.000858A9ABDF0E:0.RSSI_DEVICE = 200 [RE]
DPT {n} HmIP-RF.000858A9ABDF0E:0.RSSI_PEER = 201 [RE]
DPT {b} HmIP-RF.000858A9ABDF0E:0.UNREACH = false [RE]
DPT {b} HmIP-RF.000858A9ABDF0E:0.UPDATE_PENDING = false [RE]
CHN 000858A9ABDF0E:1 HmIP-BSM 000858A9ABDF0E:1
DPT {b} HmIP-RF.000858A9ABDF0E:1.PRESS_LONG = [E]
DPT {b} HmIP-RF.000858A9ABDF0E:1.PRESS_SHORT = [E]
CHN 000858A9ABDF0E:2 HmIP-BSM 000858A9ABDF0E:2
DPT {b} HmIP-RF.000858A9ABDF0E:2.PRESS_LONG = [E]
DPT {b} HmIP-RF.000858A9ABDF0E:2.PRESS_SHORT = [E]
CHN 000858A9ABDF0E:3 HmIP-BSM 000858A9ABDF0E:3
DPT {i} HmIP-RF.000858A9ABDF0E:3.PROCESS = 0 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:3.SECTION = 2 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:3.SECTION_STATUS = 0 [RE]
DPT {b} HmIP-RF.000858A9ABDF0E:3.STATE = true [RE]
CHN 000858A9ABDF0E:4 Lichtschalter B�ro
DPT {s} HmIP-RF.000858A9ABDF0E:4.COMBINED_PARAMETER = [W]
DPT {f} HmIP-RF.000858A9ABDF0E:4.ON_TIME = [W]
DPT {i} HmIP-RF.000858A9ABDF0E:4.PROCESS = 0 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:4.SECTION = 2 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:4.SECTION_STATUS = 0 [RE]
DPT {b} HmIP-RF.000858A9ABDF0E:4.STATE = true [RWE]
CHN 000858A9ABDF0E:5 HmIP-BSM 000858A9ABDF0E:5
DPT {s} HmIP-RF.000858A9ABDF0E:5.COMBINED_PARAMETER = [W]
DPT {f} HmIP-RF.000858A9ABDF0E:5.ON_TIME = [W]
DPT {i} HmIP-RF.000858A9ABDF0E:5.PROCESS = 0 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:5.SECTION = 0 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:5.SECTION_STATUS = 0 [RE]
DPT {b} HmIP-RF.000858A9ABDF0E:5.STATE = false [RWE]
CHN 000858A9ABDF0E:6 HmIP-BSM 000858A9ABDF0E:6
DPT {s} HmIP-RF.000858A9ABDF0E:6.COMBINED_PARAMETER = [W]
DPT {f} HmIP-RF.000858A9ABDF0E:6.ON_TIME = [W]
DPT {i} HmIP-RF.000858A9ABDF0E:6.PROCESS = 0 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:6.SECTION = 0 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:6.SECTION_STATUS = 0 [RE]
DPT {b} HmIP-RF.000858A9ABDF0E:6.STATE = false [RWE]
CHN 000858A9ABDF0E:7 HmIP-BSM 000858A9ABDF0E:7
DPT {f} HmIP-RF.000858A9ABDF0E:7.CURRENT = 116.000000 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:7.CURRENT_STATUS = 0 [RE]
DPT {f} HmIP-RF.000858A9ABDF0E:7.ENERGY_COUNTER = 9613.200000 [RE]
DPT {b} HmIP-RF.000858A9ABDF0E:7.ENERGY_COUNTER_OVERFLOW = false [RE]
DPT {f} HmIP-RF.000858A9ABDF0E:7.FREQUENCY = 49.980000 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:7.FREQUENCY_STATUS = 0 [RE]
DPT {f} HmIP-RF.000858A9ABDF0E:7.POWER = 25.850000 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:7.POWER_STATUS = 0 [RE]
DPT {f} HmIP-RF.000858A9ABDF0E:7.VOLTAGE = 228.200000 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:7.VOLTAGE_STATUS = 0 [RE]
CHN 000858A9ABDF0E:9 HmIP-BSM 000858A9ABDF0E:9
DPT {i} HmIP-RF.000858A9ABDF0E:9.WEEK_PROGRAM_CHANNEL_LOCKS = 0 [RE]
DPT {i} HmIP-RF.000858A9ABDF0E:9.WEEK_PROGRAM_TARGET_CHANNEL_LOCK = [W]
DPT {i} HmIP-RF.000858A9ABDF0E:9.WEEK_PROGRAM_TARGET_CHANNEL_LOCKS = [W]
StateDatapoint = 4.STATE
ControlDatapoint = 4.STATE
Device 000858A9ABDF0E HmIP-BSM 000858A9ABDF0E [HmIP-BSM]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 1.18.12
CHILDREN: 000858A9ABDF0E:0,000858A9ABDF0E:1,000858A9ABDF0E:2,000858A9ABDF0E:3,000858A9ABDF0E:4,000858A9ABDF0E:5,000858A9ABDF0E:6,000858A9ABDF0E:7,000858A9ABDF0E:8,000858A9ABDF0E:9
DIRECTION: NONE
FIRMWARE: 1.18.12
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 7857971
ROAMING: 0
RX_MODE:
SUBTYPE: BSM
UPDATABLE: 1
Channel 000858A9ABDF0E:0 HmIP-BSM 000858A9ABDF0E:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:1 HmIP-BSM 000858A9ABDF0E:1 [KEY_TRANSCEIVER] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:2 HmIP-BSM 000858A9ABDF0E:2 [KEY_TRANSCEIVER] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:3 HmIP-BSM 000858A9ABDF0E:3 [SWITCH_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:4 Lichtschalter B�ro [SWITCH_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: REMOTE_CONTROL,LEVEL,CONDITIONAL_SWITCH,SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:5 HmIP-BSM 000858A9ABDF0E:5 [SWITCH_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: REMOTE_CONTROL,LEVEL,CONDITIONAL_SWITCH,SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:6 HmIP-BSM 000858A9ABDF0E:6 [SWITCH_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: REMOTE_CONTROL,LEVEL,CONDITIONAL_SWITCH,SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:7 HmIP-BSM 000858A9ABDF0E:7 [ENERGIE_METER_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:8 HmIP-BSM 000858A9ABDF0E:8 [COND_SWITCH_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000858A9ABDF0E:9 HmIP-BSM 000858A9ABDF0E:9 [SWITCH_WEEK_PROFILE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 000858A9ABDF0E
PARENT_TYPE: HmIP-BSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Viele Grüße
Jürgen
Hallo zap,
ich habe bei jeder Statusänderung meiner Tür-/Fensterkontakte diese Logeinträge:
2020.11.16 20:17:11 2: After sleep: Fenster_Buero_auf=16.11.2020 - 20:17:10
Fenster_Buero_zu=15.11.2020 - 20:28:45
2020.11.16 20:17:17 2: After sleep: Fenster_Buero_auf=16.11.2020 - 20:17:10
Fenster_Buero_zu=16.11.2020 - 20:17:16
Hier die Info zum Gerät:
CHN 0000DA498D425C:0 HMIP-SWDO 0000DA498D425C:0
DPT {b} HmIP-RF.0000DA498D425C:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.0000DA498D425C:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.0000DA498D425C:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.0000DA498D425C:0.INSTALL_TEST = true [RW]
DPT {b} HmIP-RF.0000DA498D425C:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.0000DA498D425C:0.OPERATING_VOLTAGE = 1.300000 [RE]
DPT {i} HmIP-RF.0000DA498D425C:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.0000DA498D425C:0.RSSI_DEVICE = 203 [RE]
DPT {n} HmIP-RF.0000DA498D425C:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.0000DA498D425C:0.SABOTAGE = false [RE]
DPT {b} HmIP-RF.0000DA498D425C:0.UNREACH = false [RE]
DPT {b} HmIP-RF.0000DA498D425C:0.UPDATE_PENDING = false [RE]
CHN 0000DA498D425C:1 HMIP-SWDO 0000DA498D425C:1
DPT {i} HmIP-RF.0000DA498D425C:1.STATE = 0 [RE]
StateDatapoint = 1.STATE
ControlDatapoint = 1.STATE
Device 0000DA498D425C HMIP-SWDO 0000DA498D425C [HMIP-SWDO]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 0000DA498D425C:0,0000DA498D425C:1,0000DA498D425C:2
DIRECTION: NONE
FIRMWARE: 1.16.8
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 9047915
ROAMING: 0
RX_MODE: CONFIG
SUBTYPE: SWD
UPDATABLE: 1
Channel 0000DA498D425C:0 HMIP-SWDO 0000DA498D425C:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 0000DA498D425C
PARENT_TYPE: HMIP-SWDO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0000DA498D425C:1 HMIP-SWDO 0000DA498D425C:1 [SHUTTER_CONTACT] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: WINDOW_SWITCH,CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 0000DA498D425C
PARENT_TYPE: HMIP-SWDO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0000DA498D425C:2 HMIP-SWDO 0000DA498D425C:2 [ALARM_COND_SWITCH_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS:
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 0000DA498D425C
PARENT_TYPE: HMIP-SWDO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Die Werte der Userreadings setze ich über ein notify
Internals:
DEF HMIP_SWDO_0000DA498D425C:hmstate:.*
sleep 0.5;
get HMCCU3 vars Fenster_Buero.*;
setreading HMIP_SWDO_0000DA498D425C LastOpen [HMCCU3:Fenster_Buero_auf];
setreading HMIP_SWDO_0000DA498D425C LastClose [HMCCU3:Fenster_Buero_zu]
FUUID 5d90fd65-f33f-ca7c-41bb-5f4631f39870db4f
NAME Buerofenster_notify
NOTIFYDEV HMIP_SWDO_0000DA498D425C
NR 235
NTFY_ORDER 50-Buerofenster_notify
REGEXP HMIP_SWDO_0000DA498D425C:hmstate:.*
STATE 2020-11-16 20:17:16
TRIGGERTIME 1605554236.50075
TYPE notify
READINGS:
2020-11-16 20:07:34 state active
Attributes:
In der alten Version tauchen diese Logeinträge nicht auf
Viele Grüße
Jürgen
Hallo zap,
ein weiteres Mysterium:
Wenn ich einen "IP-Kontaktsensor" auslöse, dann wird ein Reading "1.PRESS_SHORT " mit dem Wert 1 erzeugt.
Internals:
CFGFN
DEF 0000DA498D425C
FUUID 5fb2da86-f33f-ca7c-46be-a5d38776b632626e
IODev HMCCU3
NAME HMIP_SWDO_0000DA498D425C
NR 743
STATE Status: closed / LastOpen: 16.11.2020 - 21:03:02 / LastClose: 16.11.2020 - 21:03:04
TYPE HMCCUDEV
ccuaddr 0000DA498D425C
ccudevstate active
ccuif HmIP-RF
ccuname HMIP-SWDO 0000DA498D425C
ccutype HMIP-SWDO
readonly no
OLDREADINGS:
READINGS:
2020-11-16 21:03:04 1.PRESS_SHORT 1
2020-11-16 21:11:25 1.STATE closed
2020-11-16 21:03:05 LastClose 16.11.2020 - 21:03:04
2020-11-16 21:03:05 LastOpen 16.11.2020 - 21:03:02
2020-11-16 21:11:25 activity alive
2020-11-16 21:11:25 battery ok
2020-11-16 21:11:25 control closed
2020-11-16 21:11:25 devstate ok
2020-11-16 21:11:25 hmstate closed
2020-11-16 21:11:25 state closed
hmccu:
channels 3
devspec 0000DA498D425C
nodefaults 0
role 0:MAINTENANCE,1:SHUTTER_CONTACT,2:ALARM_COND_SWITCH_TRANSMITTER
semDefaults 0
cmdlist:
get
set
control:
chn 1
dpt STATE
dp:
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.LOW_BAT:
VALUES:
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 1.4
OVAL 1.4
SVAL 1.3
VAL 1.3
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -51
OVAL -51
SVAL -53
VAL -53
0.RSSI_PEER:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.SABOTAGE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
1.PRESS_SHORT:
VALUES:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.STATE:
VALUES:
OSVAL closed
OVAL 0
SVAL closed
VAL 0
roleCmds:
get:
set:
state:
chn 1
dpt STATE
Attributes:
IODev HMCCU3
alexaName Bürofenster
alias Bürofenster
assistantName Bürofenster
devStateStyle style="text-align:right"
event-min-interval battery:3600
event-on-change-reading .*
genericDeviceType window
group HM Fenster-/Türkontakte
hmstatevals ERROR!7:sabotage;SABOTAGE!1:sabotage
homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;open:CONTACT_NOT_DETECTED
icon hm-sec-win@black
room Alexa,GoogleAssistant
stateFormat {"Status: ".ReadingsVal($name,"state" ,"")." / LastOpen: ".ReadingsVal("HMCCU3","Fenster_Buero_auf","")." / LastClose: ".ReadingsVal("HMCCU3","Fenster_Buero_zu","")}
userReadings LastOpen:hmstate.* {ReadingsVal("HMCCU3","Fenster_Buero_auf","")},LastClose:hmstate.* {ReadingsVal("HMCCU3","Fenster_Buero_zu","")}
Viele Grüße
Jürgen
Zitat von: juemuc am 16 November 2020, 21:15:45
Hallo zap,
ein weiteres Mysterium:
Wenn ich einen "IP-Kontaktsensor" auslöse, dann wird ein Reading "1.PRESS_SHORT " mit dem Wert 1 erzeugt.
Ich habe 12 von denen ohne Probleme umgestellt. 1.PRESS_SHORT liefert keiner von denen.
Könnte spannend sein zu sehen, was eigentlich der Event Monitor anzeigt, wenn du den Sensor auslöst.
Zitat von: The-Holgi am 13 November 2020, 16:50:24
Habe ich gemacht, das device wird sauber mit allen readings angekegt.
Habe gerade gesehen, das die RSSI Werte nicht mehr angezeigt werden.
Zitat von: juemuc am 15 November 2020, 20:27:40
Hallo zap,
habe heute auch den ersten produktiven "pi" nach Deiner Anleitung umgesetzt. Zusätzlich habe ich diese Readings gelöscht
controldatapoint, statedatapoint, statevals Dies hatte beim IP-Lichtschalter zur Folge, dass er nicht mehr funktioniert hat. Wie kann ich denn diese INfo überprüfen ?Diese Attribute sind überflüssig, wenn HMCCU den Channel-Typ erkennt.
Viele Grüße
Jürgen
Kannst Du bitte ein 2. HMCCUDEV Device für diesen Lichtschalter anlegen und schauen, ob der funktioniert? Von dem hätte ich dann auch bitte ein "list".
Zitat von: The-Holgi am 17 November 2020, 16:07:21
Habe gerade gesehen, das die RSSI Werte nicht mehr angezeigt werden.
Bitte ein "list" vom Device.
Zitat von: zap am 17 November 2020, 18:34:00
Kannst Du bitte ein 2. HMCCUDEV Device für diesen Lichtschalter anlegen und schauen, ob der funktioniert? Von dem hätte ich dann auch bitte ein "list".
Hallo zap,
ich habe das device im Testsystem gelöscht und mit define HmIP_BSM_000858A9ABDF0E HMCCUDEV 000858A9ABDF0E neu angelegt. Es funktioniert so.
Hier das list
Internals:
CFGFN
DEF 000858A9ABDF0E
FUUID 5fb41a8e-f33f-ca7c-283e-2de875acc4fc5d3b
IODev HMCCU3
NAME HmIP_BSM_000858A9ABDF0E
NR 459
STATE on
TYPE HMCCUDEV
ccuaddr 000858A9ABDF0E
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-BSM 000858A9ABDF0E
ccutype HmIP-BSM
readonly no
receiver HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E
sender HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E
READINGS:
2020-11-17 19:46:53 3.STATE on
2020-11-17 19:46:54 4.STATE on
2020-11-17 19:46:54 5.STATE off
2020-11-17 19:46:54 6.STATE off
2020-11-17 19:46:57 activity alive
2020-11-17 19:46:54 control on
2020-11-17 19:46:57 devstate ok
2020-11-17 19:46:57 hmstate on
2020-11-17 19:46:54 state on
hmccu:
channels 10
devspec 000858A9ABDF0E
nodefaults 0
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:KEY_TRANSCEIVER,3:SWITCH_TRANSMITTER,4:SWITCH_VIRTUAL_RECEIVER,5:SWITCH_VIRTUAL_RECEIVER,6:SWITCH_VIRTUAL_RECEIVER,7:ENERGIE_METER_TRANSMITTER,8:COND_SWITCH_TRANSMITTER,9:SWITCH_WEEK_PROFILE
semDefaults 0
cmdlist:
get
set
control:
chn 4
dpt STATE
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
OSVAL 27.0
OVAL 27.000000
SVAL 27.0
VAL 27.000000
0.ACTUAL_TEMPERATURE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -56
OVAL -56
SVAL -58
VAL -58
0.RSSI_PEER:
VALUES:
OSVAL -52
OVAL -52
SVAL -51
VAL -51
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
3.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
3.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 2
VAL 2
3.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
3.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL on
VAL 1
4.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
4.SECTION:
VALUES:
OSVAL 2
OVAL 2
SVAL 2
VAL 2
4.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.STATE:
VALUES:
OSVAL on
OVAL 1
SVAL on
VAL 1
5.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
5.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
5.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
6.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
6.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
6.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
7.CURRENT:
VALUES:
OSVAL 113.0
OVAL 113.000000
SVAL 111.0
VAL 111.0
7.CURRENT_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.ENERGY_COUNTER:
VALUES:
OSVAL 9765.0
OVAL 9765.000000
SVAL 9767.3
VAL 9767.3
7.ENERGY_COUNTER_OVERFLOW:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL 0
7.FREQUENCY:
VALUES:
OSVAL 50.0
OVAL 50.010000
SVAL 50.0
VAL 49.98
7.FREQUENCY_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.POWER:
VALUES:
OSVAL 25.2
OVAL 25.220000
SVAL 25.1
VAL 25.08
7.POWER_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.VOLTAGE:
VALUES:
OSVAL 229.3
OVAL 229.300000
SVAL 229.4
VAL 229.4
7.VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
9.WEEK_PROGRAM_CHANNEL_LOCKS:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
roleCmds:
get:
set:
state:
chn 4
dpt STATE
Attributes:
IODev HMCCU3
ccureadingfilter (STATE|PRESS)
controldatapoint 4.STATE
statedatapoint 4.STATE
statevals on:true,off:false
substitute STATE!(true|1):on,(false|0):off
webCmd control
widgetOverride control:uzsuToggle,off,onmit set defaults reset verschwindet aber vieles :-(
Hier das list nach dem "reset"
nternals:
CFGFN
DEF 000858A9ABDF0E
FUUID 5fb41a8e-f33f-ca7c-283e-2de875acc4fc5d3b
IODev HMCCU3
NAME HmIP_BSM_000858A9ABDF0E
NR 459
STATE true
TYPE HMCCUDEV
ccuaddr 000858A9ABDF0E
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-BSM 000858A9ABDF0E
ccutype HmIP-BSM
readonly no
receiver HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E
sender HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E
OLDREADINGS:
READINGS:
2020-11-17 19:49:51 3.STATE true
2020-11-17 19:49:51 4.STATE true
2020-11-17 19:49:51 5.STATE false
2020-11-17 19:49:51 6.STATE false
2020-11-17 19:49:51 activity alive
2020-11-17 19:49:51 control true
2020-11-17 19:49:51 devstate ok
2020-11-17 19:49:51 hmstate true
2020-11-17 19:49:51 state true
hmccu:
channels 10
devspec 000858A9ABDF0E
nodefaults 0
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:KEY_TRANSCEIVER,3:SWITCH_TRANSMITTER,4:SWITCH_VIRTUAL_RECEIVER,5:SWITCH_VIRTUAL_RECEIVER,6:SWITCH_VIRTUAL_RECEIVER,7:ENERGIE_METER_TRANSMITTER,8:COND_SWITCH_TRANSMITTER,9:SWITCH_WEEK_PROFILE
semDefaults 0
cmdlist:
get
set
control:
chn 4
dpt STATE
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
OSVAL 27.0
OVAL 27.000000
SVAL 27.0
VAL 27.000000
0.ACTUAL_TEMPERATURE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -58
OVAL -58
SVAL -58
VAL -58
0.RSSI_PEER:
VALUES:
OSVAL -51
OVAL -51
SVAL -51
VAL -51
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
3.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
3.SECTION:
VALUES:
OSVAL 2
OVAL 2
SVAL 2
VAL 2
3.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
3.STATE:
VALUES:
OSVAL on
OVAL 1
SVAL true
VAL 1
4.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
4.SECTION:
VALUES:
OSVAL 2
OVAL 2
SVAL 2
VAL 2
4.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.STATE:
VALUES:
OSVAL on
OVAL 1
SVAL true
VAL 1
5.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
5.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
5.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL false
VAL 0
6.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
6.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
6.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL false
VAL 0
7.CURRENT:
VALUES:
OSVAL 111.0
OVAL 111.0
SVAL 111.0
VAL 111.0
7.CURRENT_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.ENERGY_COUNTER:
VALUES:
OSVAL 9767.3
OVAL 9767.3
SVAL 9767.3
VAL 9767.3
7.ENERGY_COUNTER_OVERFLOW:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
7.FREQUENCY:
VALUES:
OSVAL 50.0
OVAL 49.98
SVAL 50.0
VAL 49.98
7.FREQUENCY_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.POWER:
VALUES:
OSVAL 25.1
OVAL 25.08
SVAL 25.1
VAL 25.08
7.POWER_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.VOLTAGE:
VALUES:
OSVAL 229.4
OVAL 229.4
SVAL 229.4
VAL 229.4
7.VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
9.WEEK_PROGRAM_CHANNEL_LOCKS:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
roleCmds:
get:
set:
state:
chn 4
dpt STATE
Attributes:
IODev HMCCU3
ccureadingfilter (STATE|PRESS)
controldatapoint 4.STATE
statedatapoint 4.STATE
statevals on:true,off:falseViele Grüße
Jürgen
Hallo zap,
ich habe jetzt zusätzlich mal das device zusätzlich ein zweites Mal definiert
define HmIP_BSM_000858A9ABDF0E_TEST HMCCUDEV 000858A9ABDF0E
Damit funktioniert es nicht. Ich erhalte die Meldung
HMCCUDEV [HmIP_BSM_000858A9ABDF0E_TEST] Control channel ambiguous. Please specify control channel in device definition or attribute controldatapoint. Das device wird zwar angelegt, ab es lässt sich nicht schalten.
Und hier das list dazu:
Internals:
CFGFN
DEF 000858A9ABDF0E
FUUID 5fb422dd-f33f-ca7c-08e9-bc05f93c4db43827
IODev HMCCU3
NAME HmIP_BSM_000858A9ABDF0E_TEST
NR 7536
STATE ???
TYPE HMCCUDEV
ccuaddr 000858A9ABDF0E
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-BSM 000858A9ABDF0E
ccutype HmIP-BSM
readonly no
receiver HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E_TEST,HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E_TEST,HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E_TEST,HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E_TEST
sender HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E_TEST,HmIP_BSM_000858A9ABDF0E,HmIP_BSM_000858A9ABDF0E_TEST
hmccu:
channels 10
devspec 000858A9ABDF0E
nodefaults 0
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:KEY_TRANSCEIVER,3:SWITCH_TRANSMITTER,4:SWITCH_VIRTUAL_RECEIVER,5:SWITCH_VIRTUAL_RECEIVER,6:SWITCH_VIRTUAL_RECEIVER,7:ENERGIE_METER_TRANSMITTER,8:COND_SWITCH_TRANSMITTER,9:SWITCH_WEEK_PROFILE
semDefaults 0
cmdlist:
control:
chn
dpt
roleCmds:
get:
set:
state:
chn
dpt
Attributes:
IODev HMCCU3
Viele Grüße
Jürgen
Zitat von: zap am 17 November 2020, 18:34:49
Bitte ein "list" vom Device.
Internals:
DEF 001559939578A5:1 readonly
FUUID 5faea8f8-f33f-6571-08d2-a9a7d7a3fb3027d3
IODev d_ccu
NAME HmIP_SWDM_B2_1
NR 443
STATE open
TYPE HMCCUCHN
ccuaddr 001559939578A5:1
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-SWDM-B2 001559939578A5:1
ccutype HmIP-SWDM-B2
readonly yes
READINGS:
2020-11-17 20:38:17 STATE open
2020-11-17 20:38:17 activity alive
2020-11-17 20:38:17 battery ok
2020-11-17 20:38:17 control open
2020-11-17 20:38:17 devstate ok
2020-11-17 20:38:17 hmstate open
2020-11-17 20:38:17 state open
hmccu:
channels 1
devspec 001559939578A5:1
nodefaults 1
role 1:SHUTTER_CONTACT
semDefaults 0
cmdlist:
get
set
control:
chn 1
dpt STATE
dp:
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.LOW_BAT:
VALUES:
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 3.0
OVAL 3.0
SVAL 3.0
VAL 3.0
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -66
OVAL -66
SVAL -66
VAL -66
0.RSSI_PEER:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
1.STATE:
VALUES:
OSVAL open
OVAL 1
SVAL open
VAL 1
roleCmds:
get:
set:
state:
chn 1
dpt STATE
Attributes:
IODev d_ccu
event-on-change-reading .*
room CCU_HM
Hallo
Ich habe auch die Beta installiert.
Wie kann ich ein neues Gerät einbinden ?
Früher ging das mit get d_ccu devicelist create ^H[M|m].* t=dev f=%n defattr save room=CCU_HM
Jetzt finde ich unter get devicelist nicht.
Grüße
André
Hallo Andre,
so mache ich das:
define <name> HMCCUCHN <channel> [defaults] [readonly]
Zitat von: rieders am 18 November 2020, 09:44:53
Hallo
Ich habe auch die Beta installiert.
Wie kann ich ein neues Gerät einbinden ?
Früher ging das mit get d_ccu devicelist create ^H[M|m].* t=dev f=%n defattr save room=CCU_HM
Jetzt finde ich unter get devicelist nicht.
Grüße
André
Ich habe die Befehle getrennt:
get d_ccu ccuConfig: liest die Konfiguration der CCU neu ein
get d_ccu create: Legt neue Devices in FHEM an (also das bisherige get devicelist create)
Die Commandref ist übrigens aktuell, falls Du mal etwas nachschauen willst ;)
Zitat von: The-Holgi am 17 November 2020, 16:07:21
Habe gerade gesehen, das die RSSI Werte nicht mehr angezeigt werden.
Per Default werden nur die Readings des Kanals angezeigt (und allgemeine Werte wie battery).
Um auch die Device-Readings zu bekommen (Kanal 0), musst Du im Attribut ccuFlags das Flag showDeviceReadings setzen.
Da sich das wohl nicht jedem sofort erschließt, könnte ich mir vorstellen, zumindest einige der Werte aus Kanal 0 (wie z.B. die RSSI-Werte) immer als Reading darzustellen (analog zu battery).
Es gibt übrigens noch 2 weitere Flags, um die Links sowie die Config-Parameter als Reading einzublenden.
Hallo zap,
mir ist noch eine Kleinigkeit aufgefallen. Unter 4.3 kann ich bei webCmd "control" durch einen ":" ersetzen, sodass ich direkt über das Symbol der Glühbirne schalten kann. Dies funktioniert unter 4.4 nicht.
Dies gilt für alle Lichtschalter (IP und NON-IP).
attr HmIP_BSM_000858A9ABDF0E webCmd control
attr HmIP_BSM_000858A9ABDF0E widgetOverride control:uzsuToggle,off,on
Viele Grüße
Jürgen
Hallo
Danke für die Antwort.
Leider bekomme ich kein neues Device angelegt weder mit
get d_ccu create ^H[M|m].* t=dev f=%n defattr save room=CCU_HM noch mit
define HmIP_SWDM_B2_0015599394A30B HMCCUCHN 3 [defaults] [readonly].
Kann man das anlegen von Devices nicht einfacher machen ?
Unter IOBroker werden die Geräte gleich angelegt sobald diese angelernt sind.
Aber jeder Vorteil hat auch nachteile.
Grüße
André
Zitat von: rieders am 19 November 2020, 09:21:49
Kann man das anlegen von Devices nicht einfacher machen ?
Unter IOBroker werden die Geräte gleich angelegt sobald diese angelernt sind.
Aber jeder Vorteil hat auch nachteile.
Bitte sowas nicht, oder nur über ein zusätzliches autocreate-Attribut.
Ich will gar keine alle Homematic-Devices in FHEM haben.
Zitat von: rieders am 19 November 2020, 09:21:49
define HmIP_SWDM_B2_0015599394A30B HMCCUCHN 3 [defaults] [readonly].
Das kann nicht funktionieren. Die Syntax lautet:
define <FHEM-Devicename> HMCCUCHN <CCU-Kanalname-oder-Adresse>
In Deinem Beispiel wäre die Kanaladresse = 3. Das mag vielleicht die Kanalnummer sein. Dann fehlt davor aber ein xxxxxxx, also am Ende xxxxxxx:3
Hallo
Ich habe nun die Variante mit dem Kanalname versucht.
Leider bekomme ich diese Fehlermeldung CCU and/or IO device not ready. Please try again later.
Wie kann ich wieder zurück zur " normalen Version" downgraden ?
Irgendwie komme ich mit der Beta nicht zurecht.
Grüße
André
Die normale Version wird es nicht mehr lange geben. Aber wenn Du zurück willst: einfach FHEM per update befehl aktualisieren. Wenn Du bei update keine Quelle angibst, installiert er wieder den Standard.
Hallo,
habe eine HmIP-ASIR-B1 funktioniert soweit auch.
Internals:
CFGFN
DEF 000AD99396C98D
FUUID 5fb7e524-f33f-6571-526d-1edebf7f90a72293
IODev d_ccu
NAME Sirene
NR 88717
STATE ok
TYPE HMCCUDEV
ccuaddr 000AD99396C98D
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-ASIR-B1 000AD99396C98D
ccutype HmIP-ASIR-B1
readonly no
receiver Sirene
sender Sirene
OLDREADINGS:
READINGS:
2020-11-20 17:59:42 0.CONFIG_PENDING false
2020-11-20 17:59:42 0.DUTY_CYCLE false
2020-11-20 17:59:42 0.ERROR_CODE 0
2020-11-20 17:57:55 0.INSTALL_TEST true
2020-11-20 17:59:42 0.LOW_BAT ok
2020-11-20 17:59:42 0.OPERATING_VOLTAGE 4.6
2020-11-20 17:59:42 0.OPERATING_VOLTAGE_STATUS NORMAL
2020-11-20 17:59:42 0.RSSI_DEVICE -69
2020-11-20 17:57:55 0.RSSI_PEER 0
2020-11-20 17:59:42 0.SABOTAGE false
2020-11-20 17:59:42 0.UNREACH alive
2020-11-20 17:57:55 0.UPDATE_PENDING false
2020-11-20 17:59:42 3.ACOUSTIC_ALARM_ACTIVE false
2020-11-20 17:59:42 3.OPTICAL_ALARM_ACTIVE false
2020-11-20 17:57:55 3.ZONE_1_ACTIVE 0
2020-11-20 17:57:55 3.ZONE_1_ALARM 0
2020-11-20 17:57:55 3.ZONE_2_ACTIVE 0
2020-11-20 17:57:55 3.ZONE_2_ALARM 0
2020-11-20 17:57:55 3.ZONE_3_ACTIVE 0
2020-11-20 17:57:55 3.ZONE_3_ALARM 0
2020-11-20 17:57:55 3.ZONE_4_ACTIVE 0
2020-11-20 17:57:55 3.ZONE_4_ALARM 0
2020-11-20 17:57:55 3.ZONE_5_ACTIVE 0
2020-11-20 17:57:55 3.ZONE_5_ALARM 0
2020-11-20 17:57:55 3.ZONE_6_ACTIVE 0
2020-11-20 17:57:55 3.ZONE_6_ALARM 0
2020-11-20 17:57:55 3.ZONE_7_ACTIVE 0
2020-11-20 17:57:55 3.ZONE_7_ALARM 0
2020-11-20 17:59:42 activity alive
2020-11-20 17:59:42 battery ok
2020-11-20 17:59:42 devstate ok
2020-11-20 17:59:42 hmstate false
2020-11-20 17:49:56 state false
hmccu:
channels 4
devspec 000AD99396C98D
nodefaults 0
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:ALARM_COND_SWITCH_RECEIVER,3:ALARM_SWITCH_VIRTUAL_RECEIVER
semDefaults 0
cmdlist:
get
set press:noArg on:noArg off:noArg
control:
chn 1
dpt PRESS_SHORT
dp:
0.ARR_TIMEOUT:
MASTER:
OSVAL 10
OVAL 10
SVAL 10
VAL 10
VALUES:
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.CYCLIC_INFO_MSG:
MASTER:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
0.CYCLIC_INFO_MSG_DIS:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
0.CYCLIC_INFO_MSG_DIS_UNCHANGED:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
0.CYCLIC_INFO_MSG_OVERDUE_THRESHOLD:
MASTER:
OSVAL 2
OVAL 2
SVAL 2
VAL 2
VALUES:
0.DUTYCYCLE_LIMIT:
MASTER:
OSVAL 180
OVAL 180
SVAL 180
VAL 180
VALUES:
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ENABLE_ROUTING:
MASTER:
OSVAL true
OVAL 1
SVAL true
VAL 1
VALUES:
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.LOCAL_RESET_DISABLED:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
0.LOW_BAT:
VALUES:
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.LOW_BAT_LIMIT:
MASTER:
OSVAL 3.3
OVAL 3.3
SVAL 3.3
VAL 3.3
VALUES:
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 4.6
OVAL 4.6
SVAL 4.6
VAL 4.6
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -67
OVAL -67
SVAL -69
VAL -69
0.RSSI_PEER:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.SABOTAGE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
1.ALARM_MODE_TYPE:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.ALARM_MODE_ZONE_1:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.ALARM_MODE_ZONE_2:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.ALARM_MODE_ZONE_3:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.ALARM_MODE_ZONE_4:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.ALARM_MODE_ZONE_5:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.ALARM_MODE_ZONE_6:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.ALARM_MODE_ZONE_7:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
2.SD_MULTICAST_ZONE_1:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.SD_MULTICAST_ZONE_2:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.SD_MULTICAST_ZONE_3:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.SD_MULTICAST_ZONE_4:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.SD_MULTICAST_ZONE_5:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.SD_MULTICAST_ZONE_6:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.SD_MULTICAST_ZONE_7:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.SILENT_ALARM_ZONE_1:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.SILENT_ALARM_ZONE_2:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.SILENT_ALARM_ZONE_3:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.SILENT_ALARM_ZONE_4:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.SILENT_ALARM_ZONE_5:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.SILENT_ALARM_ZONE_6:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.SILENT_ALARM_ZONE_7:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
3.ACOUSTIC_ALARM_ACTIVE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
3.EVENT_DELAY_UNIT:
MASTER:
OSVAL S
OVAL 1
SVAL S
VAL 1
VALUES:
3.EVENT_DELAY_VALUE:
MASTER:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
3.EVENT_RANDOMTIME_UNIT:
MASTER:
OSVAL S
OVAL 1
SVAL S
VAL 1
VALUES:
3.EVENT_RANDOMTIME_VALUE:
MASTER:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
3.OPTICAL_ALARM_ACTIVE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
3.ZONE_1_ACTIVE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_1_ALARM:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_2_ACTIVE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_2_ALARM:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_3_ACTIVE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_3_ALARM:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_4_ACTIVE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_4_ALARM:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_5_ACTIVE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_5_ALARM:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_6_ACTIVE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_6_ALARM:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_7_ACTIVE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_7_ALARM:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
roleCmds:
get:
set:
off:
channel 1
role KEY_TRANSCEIVER
subcount 0
syntax V:PRESS_SHORT:1
usage off
on:
channel 1
role KEY_TRANSCEIVER
subcount 0
syntax V:PRESS_SHORT:1
usage on
subcmd:
press:
channel 1
role KEY_TRANSCEIVER
subcount 0
syntax V:PRESS_SHORT:1
usage press
state:
chn 1
dpt PRESS_SHORT
Attributes:
IODev d_ccu
ccuflags showDeviceReadings
room CCU_HM
stateFormat devstate
Was mich nur stört ist, das im webinterface on und off angezeigt werden. das ist ja so sowieso nicht nutzbar.
Alarm löse ich in der form aus:
set Sirene datapoint 3.ACOUSTIC_ALARM_SELECTION 0 3.OPTICAL_ALARM_SELECTION 1 3.DURATION_UNIT 0 3.DURATION_VALUE
Gruß Holger
Zitat von: The-Holgi am 20 November 2020, 18:06:14
Hallo,
habe eine HmIP-ASIR-B1 funktioniert soweit auch.
Was mich nur stört ist, das im webinterface on und off angezeigt werden. das ist ja so sowieso nicht nutzbar.
Bitte die Alarmsirene erst mal als HMCCUCHN definieren. Bei HMCCUDEV kann sich HMCCU nicht zwischen den zwei Kanälen KEY_TRANCEIVER und ALARM_SWITCH_VIRTUAL_RECEIVER entscheiden. Beide sind gültige Kanaltypen. Daher die on/off Befehle.
Alarm auslösen baue ich noch ein.
Zitat von: zap am 21 November 2020, 16:43:51
Bitte die Alarmsirene erst mal als HMCCUCHN definieren. Bei HMCCUDEV kann sich HMCCU nicht zwischen den zwei Kanälen KEY_TRANCEIVER und ALARM_SWITCH_VIRTUAL_RECEIVER entscheiden. Beide sind gültige Kanaltypen. Daher die on/off Befehle.
Ist das eine Übergangslösung oder wird das für den ASIR/ASIR-O, und eventuell auch andere, eher die Standardlösung werden?
Zitat von: kjmEjfu am 21 November 2020, 17:50:37
Ist das eine Übergangslösung oder wird das für den ASIR/ASIR-O, und eventuell auch andere, eher die Standardlösung werden?
Ziel ist natürlich, dass auch HMCCUDEV mit den ASIRs korrekt funktioniert. Allerdings genügt für diese Geräte ein HMCCUCHN, da sowieso alle relevanten Datenpunkte in einem einzigen Kanal liegen.
HMCCUCHN ist in diesem Fall zu bevorzugen, da nicht die Gefahr besteht, dass HMCCU mehrere Kanäle erkennt, die potenziell nutzbar sind.
Ich glaube, ich habe noch immer nicht ganz verstanden, wie HMCCU funktioniert ;-)
CHN XXXX:0 XXXX:0
DPT {b} HmIP-RF.XXXX:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.XXXX:0.DUTY_CYCLE = false [RE]
DPT {b} HmIP-RF.XXXX:0.ERROR_BAD_RECHARGEABLE_BATTERY_HEALTH = false [RE]
DPT {n} HmIP-RF.XXXX:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.XXXX:0.INSTALL_TEST = true [RW]
DPT {b} HmIP-RF.XXXX:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.XXXX:0.OPERATING_VOLTAGE = 4.300000 [RE]
DPT {i} HmIP-RF.XXXX:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.XXXX:0.RSSI_DEVICE = 185 [RE]
DPT {n} HmIP-RF.XXXX:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.XXXX:0.SABOTAGE = false [RE]
DPT {b} HmIP-RF.XXXX:0.UNREACH = false [RE]
DPT {b} HmIP-RF.XXXX:0.UPDATE_PENDING = false [RE]
CHN XXXX:3 HmIP-ASIR-O XXXX:3
DPT {b} HmIP-RF.XXXX:3.ACOUSTIC_ALARM_ACTIVE = false [RE]
DPT {i} HmIP-RF.XXXX:3.ACOUSTIC_ALARM_SELECTION = [W]
DPT {i} HmIP-RF.XXXX:3.DURATION_UNIT = [W]
DPT {i} HmIP-RF.XXXX:3.DURATION_VALUE = [W]
DPT {b} HmIP-RF.XXXX:3.OPTICAL_ALARM_ACTIVE = false [RE]
DPT {i} HmIP-RF.XXXX:3.OPTICAL_ALARM_SELECTION = [W]
da habe ich doch in :0 jede Menge relevante Datenpunkte und in :3 (weshalb auch immer es :3 ist), dann die ganzen Funktionen.
Zitat von: zap am 21 November 2020, 16:43:51
Bitte die Alarmsirene erst mal als HMCCUCHN definieren. Bei HMCCUDEV kann sich HMCCU nicht zwischen den zwei Kanälen KEY_TRANCEIVER und ALARM_SWITCH_VIRTUAL_RECEIVER entscheiden. Beide sind gültige Kanaltypen. Daher die on/off Befehle.
Alarm auslösen baue ich noch ein.
Hm, wenn ich als HMCCUCHN definiere läßt sich die Sirene nicht mehr mittels:
set Sirene datapoint 3.ACOUSTIC_ALARM_SELECTION 0 3.OPTICAL_ALARM_SELECTION 1 3.DURATION_UNIT 0 3.DURATION_VALUE 3ansprechen. Meldung:
HMCCUCHN: Sirene Invalid datapoint
Ok, mal ein paar erklärende Worte zu HMCCUCHN und HMCCUDEV.
Ein HMCCUCHN Device bezieht sich immer auf einen einzelnen Kanal. Nämlich der Kanal, der beim Define angegeben wurde. Daraus ergeben sich 2 Vorteile:
1. HMCCU weiß automatisch, wie das Gerät (über welchen Kanal) gesteuert werden kann
2. Man kann sich die Kanalnummer bei den Befehlen sparen. @The-Holgi: Du kannst "3." vor den Datenpunkten im set Befehl weglassen.
Trotzdem beinhaltet HMCCUCHN immer den Kanal 0 (@kjmEjfu). Denn das ist gar kein richtiger Kanal sondern beinhaltet Geräte bezogene Datenpunkte. Wenn man ccuflags auf showDeviceReadings setzt, sieht man also auch im HMCCUCHN Device die Readings vom Kanal 0. Einige Werte aus Kanal 0 sind sogar ohne ccuflags sichtbar, da sie HMCCU automatisch anzeigt (battery, activity = LOW_BAT, UNREACH).
Es gibt eigentlich nur noch einen Grund, HMCCUDEV zu verwenden: wenn bei einem Gerät notwendige Datenpunkte über mehrere Kanäle verteilt sind (ohne Kanal 0). Das kann z.B. eine Steckdose mit Energiemessung sein, die über eine Kanal geschaltet wird und über einen anderen Kanal die Messwerte liefert.
Mir ist noch was aufgefallen.
Beim HMIP-SWDO (nur da?) wird SABOTAGE ( DPT {b} HmIP-RF.0000D709953DE4:0.SABOTAGE = false [RE] ) rausgefiltert. Sollte der nicht besser standardmäßig durchgelassen werden?
Internals:
DEF XXXX
FUUID yy
FVERSION 88_HMCCUDEV.pm:v4.4.34-s18552/2019-02-10
IODev d_ccu
NAME Sensor_EG_Gaeste_Sued_Kontakt
NR 162
STATE closed
TYPE HMCCUDEV
ccuaddr XXXX
ccudevstate active
ccuif HmIP-RF
ccuname HM-Kontakt-EG-Gaeste-Sued
ccutype HMIP-SWDO
readonly no
READINGS:
2020-11-26 08:13:43 1.STATE closed
2020-11-26 08:13:43 activity alive
2020-11-26 08:13:43 battery ok
2020-11-26 08:13:43 control closed
2020-11-26 08:13:43 devstate ok
2020-11-26 08:13:43 hmstate sabotage
2020-11-26 08:13:43 state closed
hmccu:
channels 3
devspec XXXX
nodefaults 1
role 0:MAINTENANCE,1:SHUTTER_CONTACT,2:ALARM_COND_SWITCH_TRANSMITTER
semDefaults 0
cmdlist:
get
set
control:
chn 1
dpt STATE
dp:
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 1
VAL 1
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.LOW_BAT:
VALUES:
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 1.1
OVAL 1.1
SVAL 1.2
VAL 1.2
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -69
OVAL -69
SVAL -60
VAL -60
0.RSSI_PEER:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.SABOTAGE:
VALUES:
OSVAL false
OVAL 0
SVAL true
VAL 1
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
1.STATE:
VALUES:
OSVAL closed
OVAL 0
SVAL closed
VAL 0
roleCmds:
get:
set:
state:
chn 1
dpt STATE
Attributes:
HomeContactType window
HomeModeAlarmActive armaway
HomeOpenDontTriggerModes home|gotosleep|asleep
HomeOpenDontTriggerModesResidents xyz
IODev d_ccu
alias Fenster Gästezimmer Süd
devStateIcon closed:fts_window_1w open:fts_window_1w_open@red
event-on-change-reading state,sabotage,control,battery,Activity
group Kontaktsensoren
hmstatevals ERROR!7:sabotage;SABOTAGE!1:sabotage
room Homematic
statedatapoint 1.STATE
subType threeStateSensor
userattr HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes subType
Und noch was ist mir aufgefallen :-)
Bei Schaltern wird ja kein not-pressed geschickt, weshalb man event-on-update-reading setzen muss. Mit HMCCU 4.3 hat das auch funktioniert, mit 4.4 funktioniert es beim HMIP-WRC2 problemlos, aber beim HM-PB-2-WM55-2 nicht. Beide sind als HMCCUDEV angelegt.
Der WM55-2 aktualisiert alle paar Stunden komplett seine Readings und behauptet dann "1.PRESS_SHORT pressed", was natürlich wegen event-on-update-reading entsprechend auslöst.
Attribute sind bei beiden Schaltern gleich gesetzt:
Attributes:
IODev d_ccu
alias Schalter ABC
ccureadingfilter (LOWBAT|UNREACH|PRESS)
event-on-update-reading .*
room Homematic
stateFormat B: battery S: activity
substitute PRESS_SHORT,PRESS_LONG!(1|true):pressed
Readings:
1.PRESS_SHORT pressed 2020-11-26 14:44:53
2.PRESS_SHORT pressed 2020-11-26 14:44:53
activity alive 2020-11-26 14:44:53
battery ok 2020-11-26 14:44:53
devstate sign 2020-11-26 14:44:53
hmstate Initialized 2020-11-26 14:44:53
state Initialized 2020-01-04 11:44:17
Letzter Tastendruck war aber heute morgen um halb sieben ;-)
Das Device-Info vom WM55-2 sieht so aus:
CHN XXXX:0 HM-Schalter-OG-1:0
DPT {b} HmIP-RF.XXXX:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.XXXX:0.DUTY_CYCLE = false [RE]
DPT {b} HmIP-RF.XXXX:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.XXXX:0.OPERATING_VOLTAGE = 2.800000 [RE]
DPT {n} HmIP-RF.XXXX:0.RSSI_DEVICE = 164 [RE]
DPT {n} HmIP-RF.XXXX:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.XXXX:0.UNREACH = false [RE]
DPT {b} HmIP-RF.XXXX:0.UPDATE_PENDING = false [RE]
DPT {b} HmIP-RF.XXXX:0.INSTALL_TEST = true [RW]
DPT {i} HmIP-RF.XXXX:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
CHN XXXX:1 HM-Schalter-OG-1:1
DPT {b} HmIP-RF.XXXX:1.PRESS_LONG = [E]
DPT {b} HmIP-RF.XXXX:1.PRESS_SHORT = false [E]
CHN XXXX:2 HM-Schalter-OG-1:2
DPT {b} HmIP-RF.XXXX:2.PRESS_LONG = [E]
DPT {b} HmIP-RF.XXXX:2.PRESS_SHORT = false [E]
Also es steht auch tatsächlich ein false im PRESS_SHORT.
Zitat von: kjmEjfu am 26 November 2020, 08:21:11
Mir ist noch was aufgefallen.
Beim HMIP-SWDO (nur da?) wird SABOTAGE ( DPT {b} HmIP-RF.0000D709953DE4:0.SABOTAGE = false [RE] ) rausgefiltert. Sollte der nicht besser standardmäßig durchgelassen werden?
Wenn tatsächlich SABOTAGE anspricht, sollte eigentlich hmstate entsprechend gesetzt werden.
Wegen dem PRESSED: bei manchen Devices schickt die CCU die Events nur, wenn die Datenpunkte zB in einem Dummy Programm abgefragt werden
Zitat von: zap am 26 November 2020, 19:35:32
Wenn tatsächlich SABOTAGE anspricht, sollte eigentlich hmstate entsprechend gesetzt werden.
Leider auch nicht passiert.
Wobei ich es gut fände, wenn in dem Fall auch weiterhin das Reading geschrieben wird. Ist z.B. für Homemode ganz hilfreich.
Zitat von: zap am 26 November 2020, 19:35:32
Wegen dem PRESSED: bei manchen Devices schickt die CCU die Events nur, wenn die Datenpunkte zB in einem Dummy Programm abgefragt werden
Nee, nee, falsch verstanden :-) Die CCU schickt die Events schon, das hat ja auch vorher mit HMCCU 4.3 schon einwandfrei geklappt.
Beim WM55-2 kommt aber periodisch (alle 8 Stunden?) ein Update an und beim WM55-2 werden dann alle Readings (inklusive den PRESSED) aktualisiert. Dadurch sprechen die NOTIFYS/DOIFS an.
Beim HMIP-WRC2 (anderer Schalter) passiert dieses Update nicht bzw. es kommt intern(?) irgendwelche Filter zum Tragen, wodurch PRESSED nicht aktualisiert wird - außer natürlich, der Schalter wird tatsächlich gedrückt. Der macht es also so wie er soll.
WM55-2 aktualisiert bei mir periodisch:
hmstate, devstate, battery, activity, 2.PRESS_SHORT, 1.PRESS_SHORT
WRC2 hingegen nur:
hmstate, devstate, battery, activity
Wobei dieses Update inhaltlich auch noch falsch ist, da in dem Fall 1.PRESS_SHORT gar nicht gedrückt ist und sogar das DeviceInfo ein "false" anzeigt.
Hallo, ich möchte gerne auf die Version 4.4 wechseln. Momentan habe ich nur ein paar Geräte
an einer pivccu3 angeschlossen. Die meisten Geräte hängen direkt an fhem
Wie gehe ich am besten vor ?
- löschen aller Geräte und HMCCU aus fhem
- Installation V 4.4 über "update https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt"
- HMCCU und Geräte neu in fhem installieren
Danke und Grüße ...
Warte bitte noch ein paar Tage. Ich lade noch ein Update hoch, das einige Fehler behebt.
So, nun habe ich hoffentich wieder etwas Zeit zu experimentieren. Ich fange wieder mit "get" an:
Ich würde mich freuen, wenn wir eine Begriffsdefinition erstellen könnten. Aus meiner Erfahrung erleichtert dies die Kommunikation und das Verständniss der Kommandos. Bei CUL_HM habe ich das nicht sauber durchgezugen, nur teilweise - was ich bereue.
Bei den aktuellen Kommandos komme ich immer wieder durcheinander - aus genanntem Grund. Hier meine Vorschläge (FHEM hat sich auf littleCamelLetter Nomenklatur festgelegt!)
Ich unterscheide zwischen
- config [Cfg]: remanente Einstellungen, Konfiguration
- control [Ctrl]: Dynamische Einstellungen, also 'ein', 'Aus', Level, desired-temp,...
- states [Cond]: Zustände wie actual-temp, OS-Version, timed-on, Overload,... . States ist schon abgegriffen, so könnte man alternativ "condition" nutzen
- value [Val]: werte, also Inhalte Cfg, Ctrl oder Cond
Wie bekannt arbeite ich auf "Channel" ebene. Aber auch auf Device Ebene kann man die Begriffe sauber nutzen (so man will):
- Channel [Chn]: ein Kanal wie von HM festgelegt (das ist noch einfach)
- Device [DEVall]: Die physikalische Einheit mit allen Kanälen
- Channel0 [Dev]: Der Kommunikations-kanal des Device.
- xxx: Das Device betreffende Parameter. Ich habe keinen guten Namen hierfür
=> ich würde Chn0 und xxx zusammenfassen - für den User macht dies 100% sinn
==> in der Channel Darstellung HMCCUCHN brauche ich dann Entities für [CHN] und [DEV].
???> Es liegt bei dir, die Definitionen abzuändern - allerdings solltest du die Defintionen erstellen und in der Doku verankern.
Begriffsbestimmung gemäß deinen Kommandos
- config: Einstellungen im Device - remanent. Übersetzt zu CUL_HM wären es register Register. Passt gut, finde ich.
- Datapoint: Aktuelle Daten, dynamisch. Typisches Beispiel: Level oder State. Eine Mischung aus Control und State... unschön in der Nutzung
- DeviceInfo: Unklar. Eine wilde Sammlung aus Daten, mit und ohne Werte. Sollte überdacht und klar definiert werden um es einordnen zu können.
- pramDesc: Beschreibung der Parameter. Stellt sich die Frage, was Parameter sind.
- Parameter: Werte welche in "Config" und "datapoint" genutzt werden. Also eigentlich "Werte" oder "Value". Parameter sind semanitsch eher "Einstellungen", also "Config-Values" und "control-Values"
=> "valueDesc" wäre besser oder "valueDef" für Werte definition. Oder kurz [Val]
zu den aktuellen Tests
Version 4.4 - wie kann ich die Stabil bekommen? Beim Update ist auf 4.3 zurückgesprungen
Default parameter: Diese sollten per default gesetzt sein - ohne jede user-aktion. Der User überschreibt ausschliesslich, wenn er non-devault wünscht. An die Usability denken!
get <name> config:
das Dev sollte nicht angedruckt werden. Ich lese 350 Zeilen zu Channel 0 und nur 52 Zeilen interessante Info zu Channel 3. Das ist schlicht nicht anwenderfreundlich
get deviceInfo:
gemäß den namen "device" würde es sich auf alle kanäle beziehen. Es macht sinn, das auch für den Kanal anzubieten, also "ChnInfo"
Inhaltlich ist mir unklar, welche "Info" hier zu suchen sein soll. Es ist nicht sauber abgegrenzt. Config, Condition oder control? Die Liste ist in keiner Richtung komplett. Weiter sind einige Daten mehrfach vorhanden und somit obsolet. Rx-Mode ist nicht kanalspezifisch ebenso wie Roaming, Updatable, Parent. Im rahmen der Usability sollte es unterdrückt werden. Der User hat schon genur zu lernen.
get parasetDesc
auch hier überdeckt channel 0 alles. Das ist schlicht eine Katastrophe bei mir. Ich sehe alles, habe aber Probleme, das zu finden, was interessant ist.
Paramset SERVICE ist doppelt. Es ist nur für channel 0 sinnvoll und wird aktuell doppelt ausgegeben
Allgemein:
Attribute
disable - in FHEM wird "ignore" zum disable genutzt. Man sollte sparsam sein mit zusützlichen Parametern. Dummy ist ein 2. allgemeines Attribut.
IODev: kann ich für jedenKanal setzen Wie soll das gehen?
Update der Daten:
ich haben einen Kanal in der HHCU gepeert und sehe keine Information zu den Settings oder dem peering in den Readings oder per get.
=> wie und wo sollte ich das sehen/updaten können?
Zitat von: martinp876 am 12 Dezember 2020, 12:53:39
So, nun habe ich hoffentich wieder etwas Zeit zu experimentieren.
Oje ... Spaß beiseite: Deine fundierten Kommentare sind jederzeit willkommen :)
Zitat
Ich unterscheide zwischen
- config [Cfg]: remanente Einstellungen, Konfiguration
- control [Ctrl]: Dynamische Einstellungen, also 'ein', 'Aus', Level, desired-temp,...
- states [Cond]: Zustände wie actual-temp, OS-Version, timed-on, Overload,... . States ist schon abgegriffen, so könnte man alternativ "condition" nutzen
- value [Val]: werte, also Inhalte Cfg, Ctrl oder Cond
Schwierig ... das sind mir zu viele Definitionen, die eigentlich das gleiche bedeuten. Anderer Vorschlag: Ich verwende die Begriffe ParameterSet bezogen, also so, wie sie auch in der CCU verwendet werden. Ich unterscheide nicht zwischen control, states und value (in der CCU gibt es da keinen Unterschied):
- config: remanente Einstellungen, Konfiguration (=> ParameterSets "MASTER", "LINK")
- values (states, datapoints, control): Werte, die für die Steuerung der Geräte verwendet werden und/oder den aktuellen Status der Geräte anzeigen. Values kann man lesen und/oder schreiben und sie werden von der CCU per Push aktualisiert (=> ParameterSet "VALUE")
Darauf beziehen sich auch die Befehle, die für alle Gerätetypen identisch sind:
- set config: Einzelne Einstellungen setzen (=> MASTER, LINK)
- get config: Alle Einstellungen lesen (=> MASTER, LINK)
- get values: Alle Werte lesen (=> VALUES)
- set datapoint: Ein oder mehrere Wert(e) schreiben (=> VALUES)
- get datapoint: Einen Wert lesen (=> VALUES)
- get update: Alle Einstellungen und alle Werte lesen, Abkürzung für "get config" + "get values" (=> MASTER, LINK, VALUES)
Je nach Gerätetyp gibt es zusätzliche Befehle, die aber eigentlich nichts anderes als Abkürzungen für "set/get config" und "set/get datapoint" sind. Diese Befehle werden dynamisch in Abhängigkeit von der HM-Rolle eines Kanals in der CCU bereitgestellt (z.B. SHUTTER_CONTACT).
Zitat
Wie bekannt arbeite ich auf "Channel" ebene. Aber auch auf Device Ebene kann man die Begriffe sauber nutzen (so man will):
- Channel [Chn]: ein Kanal wie von HM festgelegt (das ist noch einfach)
- Device [DEVall]: Die physikalische Einheit mit allen Kanälen
- Channel0 [Dev]: Der Kommunikations-kanal des Device.
- xxx: Das Device betreffende Parameter. Ich habe keinen guten Namen hierfür
=> ich würde Chn0 und xxx zusammenfassen - für den User macht dies 100% sinn
==> in der Channel Darstellung HMCCUCHN brauche ich dann Entities für [CHN] und [DEV].
Ok, ist so umgesetzt.
Zitat
- DeviceInfo: Unklar. Eine wilde Sammlung aus Daten, mit und ohne Werte. Sollte überdacht und klar definiert werden um es einordnen zu können.
- pramDesc: Beschreibung der Parameter. Stellt sich die Frage, was Parameter sind.
Ist eigentlich ganz einfach:
DeviceInfo zunächst die Definition der VALUE ParameterSets aus (Datentypen, aktueller Wert). Außerdem die DeviceDescription (CCU Nomenklatur)
paramDesc: Gibt die Definition der Werte aller Parametersets aus. Auch hier wieder CCU Nomenklatur. In der CCU und in der HM-Doku sind alle Werte in diesen ParameterSets "Parameter". Angewendet auf das weiter oben definierte:
- config => Parameter des ParameterSets MASTER
- values / datapoint => Parameter des ParameterSets VALUES
Ist halt ein Spagat zwischen EQ-3/CCU Begriffen und FHEM-Begriffen.
Zitat
Version 4.4 - wie kann ich die Stabil bekommen? Beim Update ist auf 4.3 zurückgesprungen
Siehe erster Beitrag in diesem Thread. Am besten von Github updaten. Das SVN (contrib) aktualisiere ich nur ab und zu.
Zitat
Default parameter: Diese sollten per default gesetzt sein - ohne jede user-aktion. Der User überschreibt ausschliesslich, wenn er non-devault wünscht. An die Usability denken!
Wenn HMCCUDEV oder HMCCUCHN die Kanalrolle erkennt, werden alle Defaults automatisch gesetzt und Befehle, die vom Gerätetyp abhängen, dynamisch ergänzt. Der Befehl "set defaults" ist für die Geräte gedacht, deren Rollen ich noch nicht in HMCCUConf.pm definiert habe. Die verwenden dann erst mal die alten Defaults aus 4.3, sofern vorhanden.
Zitat
get <name> config:
das Dev sollte nicht angedruckt werden. Ich lese 350 Zeilen zu Channel 0 und nur 52 Zeilen interessante Info zu Channel 3. Das ist schlicht nicht anwenderfreundlich
Vermutlich ein Thermostat mit den Wochenprogrammen, oder? Vorschlag? Die Einstellungen von Channel 0 nie anzeigen? Nur als Readings speichern?
Zitat
get deviceInfo:
gemäß den namen "device" würde es sich auf alle kanäle beziehen. Es macht sinn, das auch für den Kanal anzubieten, also "ChnInfo"
Inhaltlich ist mir unklar, welche "Info" hier zu suchen sein soll. Es ist nicht sauber abgegrenzt. Config, Condition oder control? Die Liste ist in keiner Richtung komplett. Weiter sind einige Daten mehrfach vorhanden und somit obsolet. Rx-Mode ist nicht kanalspezifisch ebenso wie Roaming, Updatable, Parent. Im rahmen der Usability sollte es unterdrückt werden. Der User hat schon genur zu lernen.
Mal sehen, ob ich das etwas vereinfachen kann. Vielleicht bietet sich auch ein erweiterter Modus oder Expertenmodus an. Diese Infos sind halt sehr nützlich für mich, wenn ein Benutzer ein neues, noch nicht automatisch erkanntes Gerät nutzt. Dann kann ich mit diesen Infos eine Konfiguration in HMCCUConf.pm ergänzen.
Zitat
get parasetDesc
auch hier überdeckt channel 0 alles. Das ist schlicht eine Katastrophe bei mir. Ich sehe alles, habe aber Probleme, das zu finden, was interessant ist.
Paramset SERVICE ist doppelt. Es ist nur für channel 0 sinnvoll und wird aktuell doppelt ausgegeben
Analog deviceinfo ... mal sehen.
Zitat
disable - in FHEM wird "ignore" zum disable genutzt. Man sollte sparsam sein mit zusützlichen Parametern. Dummy ist ein 2. allgemeines Attribut.
Es gibt - glaube ich - mehr Module, die "disable" nutzen als "ignore". Ich halte mich daran: https://wiki.fhem.de/wiki/DevelopmentModuleAPI#IsDisabled
Zitat
IODev: kann ich für jedenKanal setzen Wie soll das gehen?
Verstehe nicht, was Du meinst. Für jedes Device (HMCCUCHN, HMCCUDEV) kann IODev gesetzt werden. Wieso sollte das ein Problem sein?
Zitat
Update der Daten:
ich haben einen Kanal in der HHCU gepeert und sehe keine Information zu den Settings oder dem peering in den Readings oder per get.
=> wie und wo sollte ich das sehen/updaten können?
attr ccuflags showLinkReadings
Ansonsten: Ich teste gerade die 4.4 intensiv mit allen Gerätetypen, die ich selbst im Einsatz habe. Danach nochmal ein Testlauf mit meiner alten 4.3 fhem.cfg mit 70 Geräten. Wenn das alles läuft, ist die 4.3 Geschichte.
Der Wechsel vom alten auf's neue MacBook kostet jetzt aber erst mal etwas Zeit, bis wieder alles eingerichtet ist ;)
Hallo zap,
Zitat von: zap am 12 Dezember 2020, 15:24:55
- set config: Einzelne Einstellungen setzen (=> MASTER, LINK)
- get config: Alle Einstellungen lesen (=> MASTER, LINK)
- get values: Alle Werte lesen (=> VALUES)
Das Parameterset SERVICE fehlt noch!?
.
Muss ich mir anschauen (im Code). Das Paramset gibt es ja nur bei HmIP und HmIP-Wired. Falls es fehlt. ergänze ich es. Solle relativ einfach sein.
Wäre es möglich SABOTAGE als Standard durchkommen zu lassen? Ich muss das aktuell bei jedem Gerät (HMCCUDEV) in das ccureadingfilter-Attribut packen, was irgendwo unnötig ist, da die Sabotage ja schon eher zu den Standardwerten gehören dürfte.
Wobei ich gerade feststelle, dass weder
ccureadingfilter 0.SABOTAGE
noch
ccureadingfilter SABOTAGE
überhaupt funktionieren. Wodurch könnte das denn unterdrückt werden?
Du musst in ccuflags showDeviceReadings setzen, damit alle Readings vom Kanal 0 angezeigt werden. Die meisten dieser Readings werden allerdings sowieso in battery, activity usw. abgebildet.
SABOTAGE, ERROR und andere Fehlerzustände landen in hmstate.
Zitat von: zap am 31 Dezember 2020, 10:35:39
Du musst in ccuflags showDeviceReadings setzen, damit alle Readings vom Kanal 0 angezeigt werden. Die meisten dieser Readings werden allerdings sowieso in battery, activity usw. abgebildet.
SABOTAGE, ERROR und andere Fehlerzustände landen in hmstate.
Aaaah, das sich ein ccuflags auch in den jeweiligen Devices versteckt ist mir bisher entgangen. Danke.
Ich habe die 4 Flags show(Device|Config|Link|Service)Readings spendiert, um die Anzahl der Readings per Default etwas einzudämmen. Gerade die Config-Readings aus dem Parameterset MASTER ufern doch ziemlich aus. Wer die unbedingt benötigt, muss eben das Flag setzen.
Es gibt übrigens seit heute / gestern eine Update auf github sowie im Contrib (version im I/O Device = 4.4.057). Damit habe ich vor allem die Device-Erkennung verbessert.
Die Beschreibung auf Seite 1 dieses Threads ist nun auch etwas aktueller und ausführlicher.
https://forum.fhem.de/index.php/topic,107077.0.html
Ich habe gerade mal hmstate in Verbindung mit HOMEMODE ausprobiert. Das ist uncool ;-)
Ein eigenes Reading sabotage hilft da schon enorm weiter. Das kann ich mir per ccureadingname aber tatsächlich nur definieren, wenn ich auch showDeviceReadings setze. Womit ich dann aber alle Kanal 0 Readings habe, hmm.
Hallo zap,
leider misslingt das update von 4.4.052 auf 4.4.057.
Ich erhalte diese Info:
2020.12.31 17:27:31 1 : Downloading https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
2020.12.31 17:27:32 1 : UPD FHEM/HMCCUConf.pm
2020.12.31 17:27:32 1 : saving fhem.cfg
2020.12.31 17:27:32 1 : saving ./log/fhem.save
2020.12.31 17:27:32 1 :
2020.12.31 17:27:32 1 : New entries in the CHANGED file:
2020.12.31 17:27:32 1 : 404: Not Found
2020.12.31 17:27:32 1 :
2020.12.31 17:27:32 1 : update finished, "shutdown restart" is needed to activate the changes.
Viele Grüße
Jürgen
Hallo zap,
nach einem downgrade auf die 4.3 war nun ein update auf die 4.4.057 möglich.
Ich habe aktuell folgende "Lücke" gefunden. Für den Klingelsensor fehlen die "default-Attribute".
HMCCUDEV: HM_Sen_DB_PCB_NEQ0956261 No default attributes found
Welche Infos benötigst Du hierfür?
Ein get deviceinfo liefert:
Device channels and datapoints
CHN NEQ0956261:0 HM_Sen_DB_PCB_NEQ0956261:0
DPT {b} BidCos-RF.NEQ0956261:0.UNREACH = false [RE]
DPT {b} BidCos-RF.NEQ0956261:0.STICKY_UNREACH = false [RWE]
DPT {b} BidCos-RF.NEQ0956261:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.NEQ0956261:0.LOWBAT = false [RE]
DPT {n} BidCos-RF.NEQ0956261:0.RSSI_DEVICE = 1 [RE]
DPT {n} BidCos-RF.NEQ0956261:0.RSSI_PEER = 1 [RE]
DPT {b} BidCos-RF.NEQ0956261:0.DEVICE_IN_BOOTLOADER = false [RE]
DPT {b} BidCos-RF.NEQ0956261:0.UPDATE_PENDING = false [RE]
DPT {n} BidCos-RF.NEQ0956261:0.AES_KEY = 0 [R]
CHN NEQ0956261:1 HM_Sen_DB_PCB_NEQ0956261:1
DPT {b} BidCos-RF.NEQ0956261:1.PRESS_SHORT = [WE]
DPT {b} BidCos-RF.NEQ0956261:1.INSTALL_TEST = [E]
DPT {b} BidCos-RF.NEQ0956261:1.PRESS_CONT = [E]
Device detection:
StateDatapoint = 1.PRESS_SHORT KEY
ControlDatapoint = 1.PRESS_SHORT KEY
Recommended module for device definition: HMCCUCHN
Current state datapoint = 1.PRESS_SHORT
Current control datapoint = 1.PRESS_SHORT
Device description
Device NEQ0956261 HM_Sen_DB_PCB_NEQ0956261 [HM-Sen-DB-PCB]
CHILDREN: NEQ0956261:0,NEQ0956261:1
FIRMWARE: 1.0
FLAGS: Visible
INTERFACE: PEQ1950749
PARAMSETS: MASTER
RF_ADDRESS: 5112799
ROAMING: 0
RX_MODE: LAZY_CONFIG,BURST
UPDATABLE: 1
Channel NEQ0956261:0 HM_Sen_DB_PCB_NEQ0956261:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: NEQ0956261
PARENT_TYPE: HM-Sen-DB-PCB
Channel NEQ0956261:1 HM_Sen_DB_PCB_NEQ0956261:1 [KEY] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: KEYMATIC,REMOTECONTROL_RECEIVER,SWITCH,WINMATIC
PARAMSETS: LINK,MASTER,VALUES
PARENT: NEQ0956261
PARENT_TYPE: HM-Sen-DB-PCB
Defaults
Support for role KEY of device type HM-Sen-DB-PCB is built in.
Viele Grüße
Jürgen
Hallo zap,
auch beim Bewegungsmelder gibt es noch ein "Problem". Unter 4.3 konnte man set BWM dedection-on/off setzen. Das geht unter 4.4 (noch) nicht.
Device channels and datapoints
CHN 00091A498F0907:0 BWP Antje:0
DPT {b} HmIP-RF.00091A498F0907:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.00091A498F0907:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.00091A498F0907:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.00091A498F0907:0.INSTALL_TEST = false [RW]
DPT {b} HmIP-RF.00091A498F0907:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.00091A498F0907:0.OPERATING_VOLTAGE = 3.000000 [RE]
DPT {i} HmIP-RF.00091A498F0907:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.00091A498F0907:0.RSSI_DEVICE = 208 [RE]
DPT {n} HmIP-RF.00091A498F0907:0.RSSI_PEER = 211 [RE]
DPT {b} HmIP-RF.00091A498F0907:0.SABOTAGE = false [RE]
DPT {b} HmIP-RF.00091A498F0907:0.UNREACH = false [RE]
DPT {b} HmIP-RF.00091A498F0907:0.UPDATE_PENDING = false [RE]
CHN 00091A498F0907:1 HmIP-SMI 00091A498F0907:1
DPT {f} HmIP-RF.00091A498F0907:1.CURRENT_ILLUMINATION = 0.000000 [RE]
DPT {i} HmIP-RF.00091A498F0907:1.CURRENT_ILLUMINATION_STATUS = 0 [RE]
DPT {f} HmIP-RF.00091A498F0907:1.ILLUMINATION = 31.100000 [RE]
DPT {i} HmIP-RF.00091A498F0907:1.ILLUMINATION_STATUS = 0 [RE]
DPT {b} HmIP-RF.00091A498F0907:1.MOTION = false [RE]
DPT {b} HmIP-RF.00091A498F0907:1.MOTION_DETECTION_ACTIVE = true [RWE]
DPT {b} HmIP-RF.00091A498F0907:1.RESET_MOTION = [W]
Device detection:
StateDatapoint = 1.MOTION MOTIONDETECTOR_TRANSCEIVER
ControlDatapoint = 1.MOTION_DETECTION_ACTIVE MOTIONDETECTOR_TRANSCEIVER
Recommended module for device definition: HMCCUCHN
Current state datapoint = 1.MOTION
Current control datapoint = 1.MOTION_DETECTION_ACTIVE
Device description
Device 00091A498F0907 BWP Antje [HmIP-SMI]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 00091A498F0907:0,00091A498F0907:1,00091A498F0907:2,00091A498F0907:3
DIRECTION: NONE
FIRMWARE: 1.4.8
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 6122220
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG,BURST
SUBTYPE: SMI
UPDATABLE: 1
Channel 00091A498F0907:0 BWP Antje:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 00091A498F0907
PARENT_TYPE: HmIP-SMI
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00091A498F0907:1 HmIP-SMI 00091A498F0907:1 [MOTIONDETECTOR_TRANSCEIVER] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00091A498F0907
PARENT_TYPE: HmIP-SMI
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Defaults
Support for role MOTIONDETECTOR_TRANSCEIVER of device type HmIP-SMI is built in.
Viele Grüße
Jürgen
@juemuc:
Zum Bewegungsmelder: Die Befehle heißen jetzt einfach set on/off statt set detection-on/detection-off. Schau mal, ob Du die beiden Befehle hast.
Zur Klingel: Kommt diese Fehlermeldung mit den fehlenden Defaults beim Starten von FHEM? Kann ich mir nicht erklären, da laut get deviceInfo HMCCU das Gerät erkennt. Kannst Du mal ein List von dem Device machen?
Hallo zap,
beim Klingelsensor kommt die Meldung, wenn ich den Befehl "set SENSOR defaults reset" aufrufe. Das Device wurde ja bereits unter 4.3 definiert. Ich wollte hier auch Deiner Empfehlung nachkommen ;D
Beim Bewegungsmelder sind die Befehle schon da. Es passiert aber nichts. Auch unter 4.3 musste "set BWM dedection-on/off" verwendet werden. Da gab es ja auch schon on/off.
Viele Grüße
Jürgen
Hallo zap,
kleine Korrektur beim Bewegungsmelder:
"off" setzen funktioniert. "on" leider nicht.
Viele Grüße
Jürgen
Machst Du mal bitte ein list für beide Geräte?
Hallo zap,
anbei die gewünschten Infos.
Bewegungsmelder:
Internals:
DEF 000918A9952DE7:1
FUUID 5fef100e-f33f-ca7c-facd-2652ac2b742e1a4e
IODev HMCCU3
NAME HmIP_SMI_000918A9952DE7
NR 343
STATE noMotion
TYPE HMCCUCHN
ccuaddr 000918A9952DE7:1
ccudevstate deleted
ccuif HmIP-RF
ccuname HmIP-SMI 000918A9952DE7:1
ccurolectrl MOTIONDETECTOR_TRANSCEIVER
ccurolestate MOTIONDETECTOR_TRANSCEIVER
ccusubtype SMI
ccutype HmIP-SMI
readonly no
READINGS:
2021-01-01 17:45:49 CURRENT_ILLUMINATION 0.0
2021-01-01 17:45:49 CURRENT_ILLUMINATION_STATUS NORMAL
2021-01-01 17:49:04 ILLUMINATION 127.9
2021-01-01 17:49:04 ILLUMINATION_STATUS NORMAL
2021-01-01 17:49:04 MOTION noMotion
2021-01-01 17:49:04 MOTION_DETECTION_ACTIVE false
2021-01-01 17:49:04 activity alive
2021-01-01 17:49:04 battery ok
2021-01-01 17:49:04 control false
2021-01-01 17:49:04 devstate ok
2021-01-01 17:49:04 hmstate noMotion
2021-01-01 17:49:04 rssidevice -63
2021-01-01 17:49:04 rssipeer -47
2021-01-01 17:49:04 state noMotion
hmccu:
channels 1
devspec 000918A9952DE7:1
nodefaults 1
role 1:MOTIONDETECTOR_TRANSCEIVER
semDefaults 0
cmdlist:
get
set off:noArg on:noArg toggle:noArg
control:
chn 1
dpt MOTION_DETECTION_ACTIVE
dp:
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 1
OVAL 1
SVAL 0
VAL 0
0.INSTALL_TEST:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.LOW_BAT:
VALUES:
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 3.0
OVAL 3.0
SVAL 3.0
VAL 3.0
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -52
OVAL -52
SVAL -63
VAL -63
0.RSSI_PEER:
VALUES:
OSVAL -47
OVAL -47
SVAL -47
VAL -47
0.SABOTAGE:
VALUES:
OSVAL true
OVAL 1
SVAL false
VAL 0
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL 0
1.CURRENT_ILLUMINATION:
VALUES:
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.0
1.CURRENT_ILLUMINATION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.ILLUMINATION:
VALUES:
OSVAL 37.9
OVAL 37.9
SVAL 127.9
VAL 127.9
1.ILLUMINATION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.MOTION:
VALUES:
OSVAL motion
OVAL 1
SVAL noMotion
VAL 0
1.MOTION_DETECTION_ACTIVE:
VALUES:
OSVAL true
OVAL 1
SVAL false
VAL 0
roleCmds:
get:
set:
off:
channel 1
role MOTIONDETECTOR_TRANSCEIVER
subcount 1
syntax V:MOTION_DETECTION_ACTIVE:active=false
usage off
subcmd:
000:
args active=false
dpt MOTION_DETECTION_ACTIVE
fnc
max 1
min 0
parname MOTION_DETECTION_ACTIVE
partype 3
ps VALUES
unit
on:
channel 1
role MOTIONDETECTOR_TRANSCEIVER
subcount 1
syntax V:MOTION_DETECTION_ACTIVE:active=true
usage on
subcmd:
000:
args active=true
dpt MOTION_DETECTION_ACTIVE
fnc
max 1
min 0
parname MOTION_DETECTION_ACTIVE
partype 3
ps VALUES
unit
state:
chn 1
dpt MOTION
Attributes:
IODev HMCCU3
alias BWM Jürgen
event-on-change-reading .*
group Bewegungsmelder
icon hue2019_devicesMotionSensor@black
room Homematic
Klingelsensor:
Internals:
DEF NEQ0956261
FUUID 5c50be57-f33f-ca7c-b65d-293b2c7687ea25d0
IODev HMCCU3
NAME HM_Sen_DB_PCB_NEQ0956261
NR 144
STATE 08.09.2020 - 19:32:30
TYPE HMCCUDEV
ccuaddr NEQ0956261
ccudevstate active
ccuif BidCos-RF
ccuname HM_Sen_DB_PCB_NEQ0956261
ccurolectrl KEY
ccurolestate KEY
ccusubtype HM-Sen-DB-PCB
ccutype HM-Sen-DB-PCB
readonly no
READINGS:
2020-12-31 17:30:41 0.AES_KEY off
2020-12-31 17:30:41 0.CONFIG_PENDING false
2020-12-31 17:30:41 0.DEVICE_IN_BOOTLOADER false
2020-12-31 17:30:41 0.LOWBAT ok
2020-12-31 17:30:41 0.RSSI_DEVICE 1
2020-12-31 17:30:41 0.RSSI_PEER 1
2020-12-31 17:30:41 0.STICKY_UNREACH false
2020-12-31 17:30:41 0.UNREACH alive
2020-12-31 17:30:41 0.UPDATE_PENDING false
2020-09-08 19:32:30 1.INSTALL_TEST 1
2020-09-08 19:32:30 1.PRESS_SHORT 1
2021-01-01 15:22:09 activity alive
2021-01-01 15:22:09 battery ok
2021-01-01 15:22:09 devstate ok
2021-01-01 15:22:09 hmstate Initialized
2021-01-01 15:22:08 klingeln 08.09.2020 - 19:32:30
2021-01-01 15:22:09 rssidevice N/A
2021-01-01 15:22:09 rssipeer N/A
2021-01-01 15:22:09 sign off
2020-01-05 21:12:02 state Initialized
hmccu:
channels 2
devspec NEQ0956261
nodefaults 1
role 0:MAINTENANCE,1:KEY
semDefaults 0
cmdlist:
get
set press:noArg on:noArg off:noArg
control:
chn 1
dpt PRESS_SHORT
dp:
0.AES_KEY:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.LOWBAT:
VALUES:
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
VALUES:
OSVAL N/A
OVAL 1
SVAL N/A
VAL 1
0.RSSI_PEER:
VALUES:
OSVAL N/A
OVAL 1
SVAL N/A
VAL 1
0.STICKY_UNREACH:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.UNREACH:
VALUES:
OSVAL alive
OVAL false
SVAL alive
VAL false
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
roleCmds:
get:
set:
off:
channel 1
role KEY
subcount 1
syntax V:PRESS_SHORT:1
usage off
subcmd:
000:
args 1
dpt PRESS_SHORT
fnc
max 1
min 0
parname PRESS_SHORT
partype 3
ps VALUES
unit
on:
channel 1
role KEY
subcount 1
syntax V:PRESS_SHORT:1
usage on
subcmd:
000:
args 1
dpt PRESS_SHORT
fnc
max 1
min 0
parname PRESS_SHORT
partype 3
ps VALUES
unit
press:
channel 1
role KEY
subcount 1
syntax V:PRESS_SHORT:1
usage press
subcmd:
000:
args 1
dpt PRESS_SHORT
fnc
max 1
min 0
parname PRESS_SHORT
partype 3
ps VALUES
unit
state:
chn 1
dpt PRESS_SHORT
Attributes:
IODev HMCCU3
alias HM Klingelsensor
devStateStyle style="text-align:right"
event-min-interval battery:3600
group Statusinformationen
icon Wecker.Aus
room Flur,Homematic,Statuszentrale
sortby 07
stateFormat klingeln
userReadings klingeln:hmstate.*
webCmd :
Viele Grüße
Jürgen
Bewegungssensor: Hier gibt es wohl noch einen Bug in der internen Befehlsdefinition für on/off. Allerdings scheint auch die CCU Config bei Dir nicht ganz richtig zu sein: ccudevstate=deleted in den Internals des Bewegungsmelders. Da sollte eigentlich ccudevstate=active stehen.
Der Klingelsensor sieht eigentlich gut aus. Du muss auf jeden Fall noch event-on-update-reading auf .* oder PRESS_SHORT setzen. Und Du musst in der CCU ein Dummy Programm definieren, das PRESS_SHORT abfragt. Sonst schickt die CCU keine Events.
Außerdem solltest Du HMCCUCHN verwenden, wenn möglich.
Hallo zap,
ich habe den Bewegungsmelder noch einmal neu definiert. Hier das neue List:
Internals:
CFGFN
DEF 000918A9952DE7:1
FUUID 5ff0d27e-f33f-ca7c-5dd7-00cfe5943e4c142a
IODev HMCCU3
NAME HmIP_SMI_000918A9952DE7
NR 554
STATE noMotion
TYPE HMCCUCHN
ccuaddr 000918A9952DE7:1
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-SMI 000918A9952DE7:1
ccurolectrl MOTIONDETECTOR_TRANSCEIVER
ccurolestate MOTIONDETECTOR_TRANSCEIVER
ccusubtype SMI
ccutype HmIP-SMI
readonly no
READINGS:
2021-01-02 21:07:26 CURRENT_ILLUMINATION 0.0
2021-01-02 21:07:26 CURRENT_ILLUMINATION_STATUS NORMAL
2021-01-02 21:07:26 ILLUMINATION 0.0
2021-01-02 21:07:26 ILLUMINATION_STATUS NORMAL
2021-01-02 21:07:26 MOTION noMotion
2021-01-02 21:07:26 MOTION_DETECTION_ACTIVE true
2021-01-02 21:07:26 activity alive
2021-01-02 21:07:26 battery ok
2021-01-02 21:07:26 control true
2021-01-02 21:07:26 devstate ok
2021-01-02 21:07:26 hmstate noMotion
2021-01-02 21:07:26 rssidevice -67
2021-01-02 21:07:26 rssipeer -63
2021-01-02 21:07:26 state noMotion
hmccu:
channels 1
devspec 000918A9952DE7:1
nodefaults 0
role 1:MOTIONDETECTOR_TRANSCEIVER
semDefaults 0
cmdlist:
get
set on:noArg off:noArg toggle:noArg
control:
chn 1
dpt MOTION_DETECTION_ACTIVE
dp:
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.LOW_BAT:
VALUES:
OSVAL ok
OVAL false
SVAL ok
VAL false
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 3.0
OVAL 3.000000
SVAL 3.0
VAL 3.000000
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -67
OVAL 189
SVAL -67
VAL 189
0.RSSI_PEER:
VALUES:
OSVAL -63
OVAL 193
SVAL -63
VAL 193
0.SABOTAGE:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.UNREACH:
VALUES:
OSVAL alive
OVAL false
SVAL alive
VAL false
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
1.CURRENT_ILLUMINATION:
VALUES:
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
1.CURRENT_ILLUMINATION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.ILLUMINATION:
VALUES:
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
1.ILLUMINATION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.MOTION:
VALUES:
OSVAL noMotion
OVAL false
SVAL noMotion
VAL false
1.MOTION_DETECTION_ACTIVE:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
roleCmds:
get:
set:
off:
channel 1
role MOTIONDETECTOR_TRANSCEIVER
subcount 1
syntax V:MOTION_DETECTION_ACTIVE:active=false
usage off
subcmd:
000:
args active=false
dpt MOTION_DETECTION_ACTIVE
fnc
max 1
min 0
parname MOTION_DETECTION_ACTIVE
partype 3
ps VALUES
unit
on:
channel 1
role MOTIONDETECTOR_TRANSCEIVER
subcount 1
syntax V:MOTION_DETECTION_ACTIVE:active=true
usage on
subcmd:
000:
args active=true
dpt MOTION_DETECTION_ACTIVE
fnc
max 1
min 0
parname MOTION_DETECTION_ACTIVE
partype 3
ps VALUES
unit
state:
chn 1
dpt MOTION
Attributes:
IODev HMCCU3
ccudevstat hat nun auch den richtigen Wert.
Auch den Klingelsensor habe ich neu definiert. Damit sieht es dann besser aus.
Internals:
CFGFN
DEF NEQ0956261:1
FUUID 5ff0d491-f33f-ca7c-5c10-d89e4451d0b254f1
IODev HMCCU3
NAME HM_Sen_DB_PCB_NEQ0956261
NR 630
STATE ???
TYPE HMCCUCHN
ccuaddr NEQ0956261:1
ccudevstate active
ccuif BidCos-RF
ccuname HM_Sen_DB_PCB_NEQ0956261:1
ccurolectrl KEY
ccurolestate KEY
ccusubtype HM-Sen-DB-PCB
ccutype HM-Sen-DB-PCB
readonly no
OLDREADINGS:
READINGS:
2021-01-02 21:18:13 activity alive
2021-01-02 21:18:13 battery ok
2021-01-02 21:18:13 devstate ok
2021-01-02 21:18:13 rssidevice N/A
2021-01-02 21:18:13 rssipeer N/A
2021-01-02 21:18:13 sign off
hmccu:
channels 1
devspec NEQ0956261:1
nodefaults 0
role 1:KEY
semDefaults 0
cmdlist:
get
set on:noArg press:noArg off:noArg
control:
chn 1
dpt PRESS_SHORT
dp:
0.AES_KEY:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.LOWBAT:
VALUES:
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
VALUES:
OSVAL N/A
OVAL 1
SVAL N/A
VAL 1
0.RSSI_PEER:
VALUES:
OSVAL N/A
OVAL 1
SVAL N/A
VAL 1
0.STICKY_UNREACH:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.UNREACH:
VALUES:
OSVAL alive
OVAL false
SVAL alive
VAL false
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
roleCmds:
get:
set:
off:
channel 1
role KEY
subcount 1
syntax V:PRESS_SHORT:1
usage off
subcmd:
000:
args 1
dpt PRESS_SHORT
fnc
max 1
min 0
parname PRESS_SHORT
partype 3
ps VALUES
unit
on:
channel 1
role KEY
subcount 1
syntax V:PRESS_SHORT:1
usage on
subcmd:
000:
args 1
dpt PRESS_SHORT
fnc
max 1
min 0
parname PRESS_SHORT
partype 3
ps VALUES
unit
press:
channel 1
role KEY
subcount 1
syntax V:PRESS_SHORT:1
usage press
subcmd:
000:
args 1
dpt PRESS_SHORT
fnc
max 1
min 0
parname PRESS_SHORT
partype 3
ps VALUES
unit
state:
chn 1
dpt PRESS_SHORT
Attributes:
IODev HMCCU3
cmdIcon press:taster
event-on-update-reading .*
room Homematic
webCmd press
Dies bedeutet aber auch, dass man die Geräte teilweise neu definieren sollte. In der CCU ist schon ein Programm definiert. Der Sensor ist aktuell nur nicht im Einsatz :-)
Viele Grüße
Jürgen
Kurzer Hinweis.
Bei meinen FSM musste ich
substitute STATE!(1|true):on,(0|false):off
setzen. Sonst liefern true bzw. false und dann wird nicht automatisch das Lampensymbol gezogen usw.
kjmEjfu: Machst Du mal bitte ein list.
juemuc: ich habe HMCCUConf.pm aktualisiert. Schau mal, ob damit das Ein-/Ausschalten des Bewegungsmelders funktioniert. Bitte nach dem Update auf jeden Fall FHEM neu starten.
Hallo zap,
es funktioniert leider immer noch nicht. Auch musste ich wieder den Umweg über die 4.3 gehen.
Viele Grüße
Jürgen
Zitat von: zap am 03 Januar 2021, 18:06:51
kjmEjfu: Machst Du mal bitte ein list.
Klar, kriegst du:
Internals:
DEF xxxx
FUUID 5c446461-f33f-8030-d95e-43f3a633b3460a8c
FVERSION 88_HMCCUDEV.pm:v4.4.37-s18552/2019-02-10
IODev d_ccu
NAME Licht_EG_Garderobe
NR 179
STATE off
TYPE HMCCUDEV
ccuaddr xxxx
ccudevstate active
ccuif HmIP-RF
ccuname HM-Licht-EG-Garderobe
ccusubtype FSM
ccutype HmIP-FSM
readonly no
READINGS:
2021-01-03 18:23:05 1.PROCESS STABLE
2021-01-03 18:23:05 1.SECTION 0
2021-01-03 18:23:05 1.SECTION_STATUS NORMAL
2021-01-03 18:23:05 1.STATE off
2021-01-03 18:23:05 2.PROCESS STABLE
2021-01-03 18:23:05 2.SECTION 0
2021-01-03 18:23:05 2.SECTION_STATUS NORMAL
2021-01-03 18:23:05 2.STATE off
2021-01-03 18:23:06 3.PROCESS STABLE
2021-01-03 18:23:06 3.SECTION 0
2021-01-03 18:23:06 3.SECTION_STATUS NORMAL
2021-01-03 18:23:06 3.STATE off
2021-01-03 18:23:06 4.PROCESS STABLE
2021-01-03 18:23:06 4.SECTION 0
2021-01-03 18:23:06 4.SECTION_STATUS NORMAL
2021-01-03 18:23:06 4.STATE off
2021-01-03 18:23:06 5.CURRENT 0.0
2021-01-03 18:23:06 5.CURRENT_STATUS NORMAL
2021-01-03 18:23:06 5.ENERGY_COUNTER 779.8
2021-01-03 18:23:06 5.ENERGY_COUNTER_OVERFLOW false
2021-01-03 18:23:06 5.FREQUENCY 50.0
2021-01-03 18:23:06 5.FREQUENCY_STATUS NORMAL
2021-01-03 18:23:06 5.POWER 0.0
2021-01-03 18:23:06 5.POWER_STATUS NORMAL
2021-01-03 18:23:06 5.VOLTAGE 226.2
2021-01-03 18:23:06 5.VOLTAGE_STATUS NORMAL
2021-01-03 18:23:06 7.WEEK_PROGRAM_CHANNEL_LOCKS 0
2021-01-03 18:23:06 activity alive
2021-01-03 18:23:05 control off
2021-01-03 18:23:06 devstate ok
2021-01-03 18:23:06 hmstate off
2021-01-03 18:23:06 rssidevice -64
2021-01-03 18:23:06 rssipeer -64
2021-01-03 18:23:05 state off
hmccu:
channels 8
devspec xxxx
nodefaults 1
role 0:MAINTENANCE,1:SWITCH_TRANSMITTER,2:SWITCH_VIRTUAL_RECEIVER,3:SWITCH_VIRTUAL_RECEIVER,4:SWITCH_VIRTUAL_RECEIVER,5:ENERGIE_METER_TRANSMITTER,6:COND_SWITCH_TRANSMITTER,7:SWITCH_WEEK_PROFILE
semDefaults 0
cmdlist:
get
set off:noArg on-till on-for-timer on:noArg toggle:noArg
control:
chn 2
dpt STATE
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
0.ACTUAL_TEMPERATURE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -65
OVAL -65
SVAL -64
VAL -64
0.RSSI_PEER:
VALUES:
OSVAL -64
OVAL 192
SVAL -64
VAL 192
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
1.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
1.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
2.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
2.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
2.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
2.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
3.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
3.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
3.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
4.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
4.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
5.CURRENT:
VALUES:
OSVAL 0.0
OVAL 0.0
SVAL 0.0
VAL 0.0
5.CURRENT_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.ENERGY_COUNTER:
VALUES:
OSVAL 779.8
OVAL 779.8
SVAL 779.8
VAL 779.8
5.ENERGY_COUNTER_OVERFLOW:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
5.FREQUENCY:
VALUES:
OSVAL 50.0
OVAL 49.98
SVAL 50.0
VAL 49.99
5.FREQUENCY_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.POWER:
VALUES:
OSVAL 0.0
OVAL 0.0
SVAL 0.0
VAL 0.0
5.POWER_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.VOLTAGE:
VALUES:
OSVAL 226.1
OVAL 226.1
SVAL 226.2
VAL 226.2
5.VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.WEEK_PROGRAM_CHANNEL_LOCKS:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
roleCmds:
get:
set:
off:
channel 2
role SWITCH_VIRTUAL_RECEIVER
subcount 1
syntax V:STATE:0
usage off
subcmd:
000:
args 0
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on:
channel 2
role SWITCH_VIRTUAL_RECEIVER
subcount 1
syntax V:STATE:1
usage on
subcmd:
000:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on-for-timer:
channel 2
role SWITCH_VIRTUAL_RECEIVER
subcount 2
syntax V:ON_TIME:?duration V:STATE:1
usage on-for-timer duration
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname duration
partype 2
ps VALUES
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on-till:
channel 2
role SWITCH_VIRTUAL_RECEIVER
subcount 2
syntax V:ON_TIME:?time V:STATE:1
usage on-till time
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname time
partype 2
ps VALUES
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
state:
chn 1
dpt STATE
Attributes:
IODev d_ccu
alias Licht Garderobe
controldatapoint 2.STATE
event-on-change-reading .*
group Licht
room Homematic
statedatapoint 1.STATE
substitute STATE!(1|true):on,(0|false):off
webCmd toggle
Zitat von: juemuc am 03 Januar 2021, 19:21:40
Hallo zap,
es funktioniert leider immer noch nicht. Auch musste ich wieder den Umweg über die 4.3 gehen.
Viele Grüße
Jürgen
Das Update hat funktioniert, allerdings hat er bemängelt, dass das CHANGED File fehlt. Das habe ich jetzt hinzugefügt. Zukünftige Updates sollten also keinen Fehler mehr bringen.
Steht denn eine Fehlermeldung im Log, wenn Du für den Bewegungsmelder "set on" oder "set off" ausführst?
Wie sieht es aus, wenn Du direkt den Datenpunkt setzt:
set xy datapoint MOTION_DETECTION_ACTIVE 0
set xy datapoint MOTION_DETECTION_ACTIVE 1
Hallo zap,
im Log finde ich diese Info:
2021.01.04 19:04:38 1: PERL WARNING: Argument "active=0" isn't numeric in numeric lt (<) at ./FHEM/88_HMCCU.pm line 8610.
2021.01.04 19:05:08 1: PERL WARNING: Argument "active=1" isn't numeric in numeric lt (<) at ./FHEM/88_HMCCU.pm line 8610.
set xy datapoint MOTION_DETECTION_ACTIVE 0/1 funktioniert.
Viele Grüße
Jürgen
Zitat von: kjmEjfu am 03 Januar 2021, 13:36:01
Kurzer Hinweis.
Bei meinen FSM musste ich
substitute STATE!(1|true):on,(0|false):off
setzen. Sonst liefern true bzw. false und dann wird nicht automatisch das Lampensymbol gezogen usw.
Gefunden. Da fehlt noch die Rollendefinition für Kanal 2 in HMCCUConf.pm. Das werde ich noch ergänzen.
Wenn Du statedatapoint auf 2.STATE setzt (analog controldatapoint), kannst Du auch jetzt schon auf das substitute verzichten, da Kanal 2 eine Rolle hat, die HMCCU schon kennt.
Hallo,
Mir ist aufgefallen das es beim Wochenprogramm vom HM-TC-IT-WM-W-EU Unterschiede zwischen der CCU und Fhem gibt.
Bei (Bild 012) vom Fhem gibt es WEEK PROGRAM 1 in der Ausgabe steht WEEK PROGRAM 0.
Die Zeiten und Temperaturen stimmen auch mit denen in CCU überein (Bild 014).
Bei (Bild 013) vom Fhem gibt es WEEK PROGRAM 2 in der Ausgabe steht WEEK PROGRAM 1.
Die Zeiten und Temperaturen stimmen aber hier nicht denen in CCU überein (Bild 015).
Ich hoffe ich habe mich verständlich ausgedrückt.
Vielen Dank
Mit freundlichen Grüßen
Wolfgang
Das liegt daran, dass die interne Nummerierung bei 0 anfängt, die Benennung aber bei 1.
Mal sehen, ob ich das konsistenter darstellen kann. Problem: HMCCU generiert alle Befehle und Darstellungen aus den internen CCU Daten. Irgendwelche Sonderlocken möchte ich vermeiden
So, nach einem Jahr Entwicklung nähert sich die Version 4.4 der Vollendung. Ich habe ein neues Update eingecheckt (FHEM contrib und Github).
Wieder ein paar Bugs getilgt. Außerdem den Befehl "set readingFilter" für HMCUCCHN und HMCCUDEV ergänzt.
Ich habe den ersten Beitrag in diesem Thread aktualisiert. Da findet man alle Neuerungen. Das werde ich aber noch ins Wiki überführen.
Ich bin vor allem an Hinweisen zu Geräten interessiert, die nicht automatisch erkannt werden, damit ich diese zeitnah ergänzen kann. Dabei helfen mir die Ausgaben von 'get deviceInfo' und 'get paramDesc' sehr.
Hallo zap,
ich habe nun mein ersten produktives System mal umgestellt 8)
Hierbei sind folgende Einträge im Log aufgetaucht:
2021.01.17 14:36:12 1: Including fhem.cfg
2021.01.17 14:36:13 2: eventTypes: loaded 5991 lines from ./log/eventTypes.txt
2021.01.17 14:36:18 1: HMCCU [HMCCU3] CCU port 8181 is reachable
2021.01.17 14:36:18 1: HMCCU [HMCCU3] Initialized version 4.4.058
2021.01.17 14:36:18 1: HMCCU [HMCCU3] Initializing device
2021.01.17 14:36:18 2: HMCCU [HMCCU3] Updating device table
2021.01.17 14:36:18 1: HMCCU [HMCCU3] Read 16 devices with 165 channels from CCU ccu3-webui-3b
2021.01.17 14:36:18 1: HMCCU [HMCCU3] Read 18 programs from CCU ccu3-webui-3b
2021.01.17 14:36:18 1: HMCCU [HMCCU3] Read 0 virtual groups from CCU ccu3-webui-3b
2021.01.17 14:36:19 0: [echodevice] load ECHO Device ECHO_G090LF09701208V5
2021.01.17 14:36:22 1: HMCCURPCPROC [d_rpc070063BidCos_RF] Initialized version 4.4.013 for interface BidCos-RF with I/O device HMCCU3
2021.01.17 14:36:22 1: HMCCURPCPROC [d_rpc070063HmIP_RF] Initialized version 4.4.013 for interface HmIP-RF with I/O device HMCCU3
2021.01.17 14:36:22 1: Including ./log/fhem.save
2021.01.17 14:36:23 1: Messages collected while initializing FHEM:configfile: HMCCU3: unknown attribute ccudef-readingname. Type 'attr HMCCU3 ?' for a detailed list.
HMCCU3: unknown attribute rpcport. Type 'attr HMCCU3 ?' for a detailed list.
HM_Sec_RHS_NEQ1477040: unknown attribute statedatapoint. Type 'attr HM_Sec_RHS_NEQ1477040 ?' for a detailed list.
HM_ES_PMSw1_Pl_DN_R1_NEQ1662710: unknown attribute ccureadings. Type 'attr HM_ES_PMSw1_Pl_DN_R1_NEQ1662710 ?' for a detailed list.
HM_ES_PMSw1_Pl_DN_R1_NEQ1662710: unknown attribute controldatapoint. Type 'attr HM_ES_PMSw1_Pl_DN_R1_NEQ1662710 ?' for a detailed list.
HM_ES_PMSw1_Pl_DN_R1_NEQ1662710: unknown attribute statedatapoint. Type 'attr HM_ES_PMSw1_Pl_DN_R1_NEQ1662710 ?' for a detailed list.
HM_Sec_SCo_OEQ0223456: unknown attribute statedatapoint. Type 'attr HM_Sec_SCo_OEQ0223456 ?' for a detailed list.
HM_Sec_SCo_OEQ0424862: unknown attribute statedatapoint. Type 'attr HM_Sec_SCo_OEQ0424862 ?' for a detailed list.
HM_LC_Sw1PBU_FM_OEQ0625708: unknown attribute controldatapoint. Type 'attr HM_LC_Sw1PBU_FM_OEQ0625708 ?' for a detailed list.
HM_LC_Sw1PBU_FM_OEQ0625708: unknown attribute statedatapoint. Type 'attr HM_LC_Sw1PBU_FM_OEQ0625708 ?' for a detailed list.
HM_MOD_Re_8_OEQ0206895_1: unknown attribute statedatapoint. Type 'attr HM_MOD_Re_8_OEQ0206895_1 ?' for a detailed list.
HM_MOD_Re_8_OEQ0206895_2: unknown attribute statedatapoint. Type 'attr HM_MOD_Re_8_OEQ0206895_2 ?' for a detailed list.
HM_MOD_Re_8_OEQ0206895_3: unknown attribute statedatapoint. Type 'attr HM_MOD_Re_8_OEQ0206895_3 ?' for a detailed list.
HM_MOD_Re_8_OEQ0206895_4: unknown attribute statedatapoint. Type 'attr HM_MOD_Re_8_OEQ0206895_4 ?' for a detailed list.
HM_MOD_Re_8_OEQ0206895_5: unknown attribute statedatapoint. Type 'attr HM_MOD_Re_8_OEQ0206895_5 ?' for a detailed list.
HM_MOD_Re_8_OEQ0206895_6: unknown attribute statedatapoint. Type 'attr HM_MOD_Re_8_OEQ0206895_6 ?' for a detailed list.
HM_MOD_Re_8_OEQ0206895_7: unknown attribute statedatapoint. Type 'attr HM_MOD_Re_8_OEQ0206895_7 ?' for a detailed list.
HM_MOD_Re_8_OEQ0206895_8: unknown attribute statedatapoint. Type 'attr HM_MOD_Re_8_OEQ0206895_8 ?' for a detailed list.
HMIP_SWDO_0000DA498D4303: unknown attribute statedatapoint. Type 'attr HMIP_SWDO_0000DA498D4303 ?' for a detailed list.
HMIP_SWDO_0000DA498D427A: unknown attribute statedatapoint. Type 'attr HMIP_SWDO_0000DA498D427A ?' for a detailed list.
HMIP_SWDO_0000DA498D425C: unknown attribute statedatapoint. Type 'attr HMIP_SWDO_0000DA498D425C ?' for a detailed list.
HmIP_BSM_00085A49A3F759: unknown attribute controldatapoint. Type 'attr HmIP_BSM_00085A49A3F759 ?' for a detailed list.
HmIP_BSM_00085A49A3F759: unknown attribute statedatapoint. Type 'attr HmIP_BSM_00085A49A3F759 ?' for a detailed list.
HmIP_BSM_000858A9ABDF0E: unknown attribute controldatapoint. Type 'attr HmIP_BSM_000858A9ABDF0E ?' for a detailed list.
HmIP_BSM_000858A9ABDF0E: unknown attribute statedatapoint. Type 'attr HmIP_BSM_000858A9ABDF0E ?' for a detailed list.
HmIP_SMI_000918A9952DE7: unknown attribute controldatapoint. Type 'attr HmIP_SMI_000918A9952DE7 ?' for a detailed list.
HmIP_SMI_000918A9952DE7: unknown attribute statedatapoint. Type 'attr HmIP_SMI_000918A9952DE7 ?' for a detailed list.
HmIP_SMI_00091A498F0907: unknown attribute controldatapoint. Type 'attr HmIP_SMI_00091A498F0907 ?' for a detailed list.
HmIP_SMI_00091A498F0907: unknown attribute statedatapoint. Type 'attr HmIP_SMI_00091A498F0907 ?' for a detailed list.
Es läuft aber alles normal (bisher).
Viele Grüße
Jürgen
Hallo zap.
bei einem Neustart von FHEM erhalte ich diese Meldungen:
2021.01.17 15:12:44 1: Messages collected while initializing FHEM:configfile: HmIP_BSM_00085A49A3F759: unknown attribute controldatapoint. Type 'attr HmIP_BSM_00085A49A3F759 ?' for a detailed list.
HmIP_BSM_00085A49A3F759: unknown attribute statedatapoint. Type 'attr HmIP_BSM_00085A49A3F759 ?' for a detailed list.
HmIP_BSM_000858A9ABDF0E: unknown attribute controldatapoint. Type 'attr HmIP_BSM_000858A9ABDF0E ?' for a detailed list.
HmIP_BSM_000858A9ABDF0E: unknown attribute statedatapoint. Type 'attr HmIP_BSM_000858A9ABDF0E ?' for a detailed list.
Das Attribut ist auch weg. Mit set default reset ist es (bis zum nächsten Neustart) wieder da.
Zuätzlich erhlte ich folgende Meldungen:
2021.01.17 15:13:11 2: After sleep: Flurtuer_auf=17.01.2021 - 12:10:01
Flurtuer_zu=17.01.2021 - 12:10:29
Status_Flurtuer=false
2021.01.17 15:13:11 2: After sleep: Fenster_Kueche_auf=17.01.2021 - 12:20:30
Fenster_Kueche_zu=17.01.2021 - 14:03:59
2021.01.17 15:13:11 2: After sleep: Balkontuer_auf=17.01.2021 - 14:22:27
Balkontuer_zu=17.01.2021 - 14:22:38
Status_Balkontuer=false
2021.01.17 15:13:11 2: After sleep: Fenster_Buero_auf=17.01.2021 - 10:48:08
Fenster_Buero_zu=17.01.2021 - 10:48:14
2021.01.17 15:13:11 2: After sleep: Fenster_Wohnzimmer_auf=06.01.2021 - 15:48:38
Fenster_Wohnzimmer_zu=06.01.2021 - 15:49:25
2021.01.17 15:13:11 2: After sleep: Fenster_Schlafzimmer_auf=17.01.2021 - 12:30:53
Fenster_Schlafzimmer_zu=17.01.2021 - 12:44:31
Hier setze ich userreadings per notify.
defmod BWM_Antje_notify notify HmIP_SMI_00091A498F0907:.* \
sleep 0.5;; \
get HMCCU3 vars BWM_Antje;;\
setreading HmIP_SMI_00091A498F0907 LastMove [HMCCU3:BWM_Antje]
Viele Grüße
Jürgen
Hallo zap,
und noch ein paar Meldungen aus dem Logfile:
2021.01.17 15:14:16 2: HMCCUDEV [HmIP_BSM_00085A49A3F759] Cannot detect control channel role of HmIP_BSM_00085A49A3F759
2021.01.17 15:15:36 2: HMCCUDEV [HM_LC_Sw1PBU_FM_OEQ0625708] Cannot detect control channel role of HM_LC_Sw1PBU_FM_OEQ0625708
2021.01.17 15:16:10 2: HMCCUDEV [HmIP_BSM_000858A9ABDF0E] Cannot detect control channel role of HmIP_BSM_000858A9ABDF0E
Viele Grüße
Jürgen
Wenn Du weitere Infos benötigst, dann bitte kurz melden.
Zitat von: juemuc am 17 Januar 2021, 15:26:58
Hallo zap,
und noch ein paar Meldungen aus dem Logfile:
2021.01.17 15:14:16 2: HMCCUDEV [HmIP_BSM_00085A49A3F759] Cannot detect control channel role of HmIP_BSM_00085A49A3F759
2021.01.17 15:15:36 2: HMCCUDEV [HM_LC_Sw1PBU_FM_OEQ0625708] Cannot detect control channel role of HM_LC_Sw1PBU_FM_OEQ0625708
2021.01.17 15:16:10 2: HMCCUDEV [HmIP_BSM_000858A9ABDF0E] Cannot detect control channel role of HmIP_BSM_000858A9ABDF0E
Die Fehlermeldungen mit dem statedatapoint und controldatapoint .... ja , das ist echt blöd. Ich wollte dem User das Leben erleichtern, indem ich diese Attribute mit Wertemengen vorbelege. Das passiert aber erst nach dem Start von FHEM. Daher kennt FHEM die Attribute beim Start noch nicht. Da muss ich mir etwas überlegen.
Für die Geräte oben: bitte schick mir für einen der BSMs und für das HM LC jeweils:
list
Get deviceinfo
Ger paramDesc
Gerne per personal mail
Infos ist raus. Ich hoffe, es passt so.
Viele Grüße
Jürgen
Also ich habe mal das set xyz readingFilter ausprobiert.
Zeigt mir bei einem HMIP-SWDO in der Liste nur STATE an. Was ja bei einem HMCCUCHN vermutlich so gewollt ist, weil der Channel 1 tatsächlich nur STATE hat.
Wenn ich nun setze
ccuflags showDeviceReadings,showServiceReadings
so hätte ich vermutet, dass ich die auch bei set xyz readingFilter zur Auswahl habe.
Wäre übrigens toll, wenn die per ccuflags erzeugten Readings auch in Kleinbuchstaben umgewandelt werden.
Zitat von: kjmEjfu am 18 Januar 2021, 08:07:46
Also ich habe mal das set xyz readingFilter ausprobiert.
Zeigt mir bei einem HMIP-SWDO in der Liste nur STATE an. Was ja bei einem HMCCUCHN vermutlich so gewollt ist, weil der Channel 1 tatsächlich nur STATE hat.
Wenn ich nun setze
ccuflags showDeviceReadings,showServiceReadings
so hätte ich vermutet, dass ich die auch bei set xyz readingFilter zur Auswahl habe.
Wäre übrigens toll, wenn die per ccuflags erzeugten Readings auch in Kleinbuchstaben umgewandelt werden.
Valide Anforderung (set readingFilter). Bis ich das umgesetzt habe, musst Du leider das Attribut ccureadingfilter manuell anpassen.
Für die Kleinbuchstaben:
attr ccureadingformat datapointlc
Zitat von: juemuc am 17 Januar 2021, 19:50:10
Infos ist raus. Ich hoffe, es passt so.
Viele Grüße
Jürgen
Ich habe ein Update eingecheckt. Die Fehler mit statedatapoint und controldatapoint beim Start von FHEM sollten nun weg sein.
Wegen den "Cannot detect control channel role of" Meldungen:
muss ich noch weiter analysieren.=> Dieser Fehler ist nun ebenfalls behoben. Wurde durch "set defaults reset" verursacht. Gerade nochmal ein Update eingecheckt.
Hallo zap.
danke, sieht gut aus.
Ich habe jetzt noch diese Einträge im Log:
2021.01.18 20:22:52 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 1324.
2021.01.18 20:22:52 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 1325.
2021.01.18 20:22:52 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 1321.
Viele Grüße
Jürgen
Ich hätte da noch einen HMIP-PS.
DeviceInfo:
Device channels and datapoints
CHN xxxx:0 HM-Strom-HWR-Umwaelzpumpe:0
DPT {f} HmIP-RF.xxxx:0.ACTUAL_TEMPERATURE = 0.000000 [RE]
DPT {b} HmIP-RF.xxxx:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.xxxx:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.xxxx:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.xxxx:0.ERROR_OVERHEAT = false [RE]
DPT {f} HmIP-RF.xxxx:0.OPERATING_VOLTAGE = 0.000000 [RE]
DPT {n} HmIP-RF.xxxx:0.RSSI_DEVICE = 201 [RE]
DPT {n} HmIP-RF.xxxx:0.RSSI_PEER = 204 [RE]
DPT {b} HmIP-RF.xxxx:0.UNREACH = false [RE]
DPT {b} HmIP-RF.xxxx:0.UPDATE_PENDING = false [RE]
CHN xxxx:1 HMIP-PS xxxx:1
DPT {b} HmIP-RF.xxxx:1.PRESS_LONG = [E]
DPT {b} HmIP-RF.xxxx:1.PRESS_SHORT = [E]
CHN xxxx:2 HMIP-PS xxxx:2
DPT {i} HmIP-RF.xxxx:2.PROCESS = 0 [RE]
DPT {i} HmIP-RF.xxxx:2.SECTION = 0 [RE]
DPT {b} HmIP-RF.xxxx:2.STATE = false [RE]
CHN xxxx:3 HMIP-PS xxxx:3
DPT {f} HmIP-RF.xxxx:3.ON_TIME = [W]
DPT {i} HmIP-RF.xxxx:3.PROCESS = 0 [RE]
DPT {i} HmIP-RF.xxxx:3.SECTION = 0 [RE]
DPT {b} HmIP-RF.xxxx:3.STATE = false [RWE]
CHN xxxx:4 HMIP-PS xxxx:4
DPT {f} HmIP-RF.xxxx:4.ON_TIME = [W]
DPT {i} HmIP-RF.xxxx:4.PROCESS = 0 [RE]
DPT {i} HmIP-RF.xxxx:4.SECTION = 0 [RE]
DPT {b} HmIP-RF.xxxx:4.STATE = false [RWE]
CHN xxxx:5 HMIP-PS xxxx:5
DPT {f} HmIP-RF.xxxx:5.ON_TIME = [W]
DPT {i} HmIP-RF.xxxx:5.PROCESS = 0 [RE]
DPT {i} HmIP-RF.xxxx:5.SECTION = 0 [RE]
DPT {b} HmIP-RF.xxxx:5.STATE = false [RWE]
CHN xxxx:6 HMIP-PS xxxx:6
DPT {i} HmIP-RF.xxxx:6.WEEK_PROGRAM_CHANNEL_LOCKS = 0 [RE]
DPT {i} HmIP-RF.xxxx:6.WEEK_PROGRAM_TARGET_CHANNEL_LOCK = [W]
DPT {i} HmIP-RF.xxxx:6.WEEK_PROGRAM_TARGET_CHANNEL_LOCKS = [W]
Device detection:
StateDatapoint = 3.STATE SWITCH_VIRTUAL_RECEIVER
StateDatapoint = 4.STATE SWITCH_VIRTUAL_RECEIVER
StateDatapoint = 5.STATE SWITCH_VIRTUAL_RECEIVER
ControlDatapoint = 3.STATE SWITCH_VIRTUAL_RECEIVER
ControlDatapoint = 4.STATE SWITCH_VIRTUAL_RECEIVER
ControlDatapoint = 5.STATE SWITCH_VIRTUAL_RECEIVER
Recommended module for device definition: HMCCUDEV
Current state datapoint = 3.STATE
Current control datapoint = 1.PRESS_SHORT
Device description
Device xxxx HM-Strom-HWR-Umwaelzpumpe [HMIP-PS]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: xxxx:0,xxxx:1,xxxx:2,xxxx:3,xxxx:4,xxxx:5,xxxx:6
DIRECTION: NONE
FIRMWARE: 2.6.2
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 6996082
ROAMING: 0
RX_MODE:
SUBTYPE: PS
UPDATABLE: 1
Channel xxxx:0 HM-Strom-HWR-Umwaelzpumpe:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: xxxx
PARENT_TYPE: HMIP-PS
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel xxxx:1 HMIP-PS xxxx:1 [KEY_TRANSCEIVER] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: xxxx
PARENT_TYPE: HMIP-PS
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel xxxx:2 HMIP-PS xxxx:2 [SWITCH_TRANSMITTER] known
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: xxxx
PARENT_TYPE: HMIP-PS
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel xxxx:3 HMIP-PS xxxx:3 [SWITCH_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: xxxx
PARENT_TYPE: HMIP-PS
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel xxxx:4 HMIP-PS xxxx:4 [SWITCH_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: xxxx
PARENT_TYPE: HMIP-PS
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel xxxx:5 HMIP-PS xxxx:5 [SWITCH_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: xxxx
PARENT_TYPE: HMIP-PS
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel xxxx:6 HMIP-PS xxxx:6 [SWITCH_WEEK_PROFILE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: xxxx
PARENT_TYPE: HMIP-PS
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Defaults
Support for role KEY_TRANSCEIVER of device type HMIP-PS is built in.
Da habe ich mit der aktuellen 4.4 kein on-for-timer zur Auswahl.
Hast Du wirklich die aktuellste Version installiert? Kannst Du das Device neu anlegen?
Was wird im I/O Device angezeigt in den folgenden Internals:
config (4.8.017)
version (4.4.060)
Hallo zap,
ich hatte heute Abend folgenden Eintrag im logfile:
2021.01.19 18:22:38 1: HMCCUDEV [HmIP_BSM_000858A9ABDF0E] HMCCUDEV: HmIP_BSM_000858A9ABDF0E Invalid datapoint
Keine Ahnung warum. Ein "set default reset" ändert nichts (ausser das webcmd).
Viele Grüße
Jürgen
Zitat von: zap am 19 Januar 2021, 17:44:26
Hast Du wirklich die aktuellste Version installiert? Kannst Du das Device neu anlegen?
Was wird im I/O Device angezeigt in den folgenden Internals:
config (4.8.017)
version (4.4.060)
Ja, habe ich.
Nach Neuanlage des Geräts habe ich auch wieder "on-for-timer".
Das set default reset hat allerdings auch ein
event-on-update-reading .*gesetzt. Gibt es dafür einen Grund, den ich aktuell nicht sehe?
event-on-update-reading wird immer gesetzt, wenn ein Gerät einen PRESS_xxx Datenpunkt enthält. Der Inhalt dieser Datenpunkte ändert sich nie. Er bleibt immer "true". Ohne das Attribut würde FHEM nur beim 1. Tastendruck ein Event generieren. Das Attribut dürfte nicht erscheinen, wenn Du ein HMCCUCHN definierst (für Kanal 3). Eigentlich sollte ein CHN ausreichen. Das DEV wird für PSMs benötigt, da diese in einem separaten Kanal die Messwerte (Spannung, Leistung usw) liefern.
Aber ja: event-on-update-reading PRESS wäre ausreichend
Moin, Danke, bin verblüfft.
Hab mir einen Wolf gesucht. Bidcos ging, IP nicht. Da kam auch eventmäßig gar nix. Mit #1 geht nun was.
Danke erstmal, ich fuddle weiter.
Hallo Zap, eine Frage die nicht direkt mit dem HMCCU Adapter zu tun hat. Es geht um rpc.
Momentan habe ich fhem so eingerichtat das ich über rpc auf meine CCU3 zugreife.
Nun möchte ich zusätzlich mit ioBroker auf die CCU3 mit rpc zugreifen. Ist dies möglich
oder gibt dies Probleme da beide auf die selben ports der ccu zugreifen.
Danke ...
Kein Problem.
Moin,
Beobachtung, Hinweis und eine Bitte.
Derzeit betreibe ich noch RasPi mit HmUART, der ja nur BidCos kann, das aber ganz gut.
Umstellen will ich auf debmatic CCU mit USB-Stick nach Alex R.
Bisher sieht ein HM_Sec_SD_2 so aus:
Internals:
...
IODev HmUART
LASTInputDev HmUART
NAME RM_Flur
...
TYPE CUL_HM
...
READINGS:
2021-01-19 19:35:34 Activity alive
2019-05-02 15:20:18 CommandAccepted yes
2019-05-02 15:20:10 D-firmware 1.0
...
2021-01-20 14:50:28 alarmTest ok
2021-01-20 14:50:28 battery ok
2021-01-20 14:50:28 commState CMDs_done
2021-01-20 14:50:28 level 0
2021-01-18 15:28:48 powerOn 2021-01-18 15:28:48
2021-01-20 14:50:28 recentStateType info
2019-05-28 11:26:00 sdRepeat off
2021-01-20 14:50:28 smokeChamber ok
2021-01-20 14:50:28 state off
2021-01-18 15:54:08 trigger_cnt 4
Unter Beta 4.4 sieht das bei mir so aus:
Internals:
...
IODev d_ccu
NAME HM_Sec_SD_2_....
NR 118
STATE ???
TYPE HMCCUCHN
ccuaddr ....:1
ccudevstate active
ccuif BidCos-RF
ccuname HM-Sec-SD-2 ....:1
ccurolestate SMOKE_DETECTOR
ccusubtype HM-Sec-SD-2
ccutype HM-Sec-SD-2
readonly no
READINGS:
2021-01-20 15:28:23 ERROR_ALARM_TEST NO_ERROR
2021-01-20 15:28:23 ERROR_SMOKE_CHAMBER NO_ERROR
2021-01-20 15:28:23 LOWBAT ok
2021-01-20 15:28:23 STATE false
2021-01-20 15:28:23 activity alive
2021-01-20 15:28:23 battery ok
2021-01-20 15:28:23 devstate ok
2021-01-20 15:28:23 rssidevice N/A
2021-01-20 15:28:23 rssipeer -43
2021-01-20 15:28:23 sign off
hmccu:
...
Attributes:
IODev d_ccu
...
Was ich mir wünsche und darum bitte:
Dass die Readings von oben, nämlich
2021-01-18 15:28:48 powerOn 2021-01-18 15:28:48
2021-01-20 14:50:28 state off
2021-01-18 15:54:08 trigger_cnt 4
auch in den Readings via HMCCUCHN so erscheinen.
Grund:
in trigger_cnt steckt wann der letzte echte Alarm war / ist und zum wievielten Mal Alarm war
und
an powerOn kann man erkennen, ob wer das Teil mal abgehängt hat(te).
Das hatte ich schon. Melder abgehängt, rumgeflext, Melder wieder angehängt = neues datum.
Beides wird - mindestens bei mir - überwacht.
Ich täte es ja - wenn möglich - selber tun. Wennich denn nur begreifen würde, WIE ?
Bitte sagts mir oder tut es bitte für mich.
@Ralph
Könnte sein, dass HMCCU den Smokedetector nicht richtig zuordnet. Könnte ich bitte die Ausgabe von get deviceInfo und get paramDesc haben?
Ich kann Dir nicht versprechen, dass das alles automatisch gehen wird. Allerdings kann man einiges sicher mit geschickten Attribut-Definitionen hinbiegen.
Zitat von: fredje am 20 Januar 2021, 14:18:52
Hallo Zap, eine Frage die nicht direkt mit dem HMCCU Adapter zu tun hat. Es geht um rpc.
Momentan habe ich fhem so eingerichtat das ich über rpc auf meine CCU3 zugreife.
Nun möchte ich zusätzlich mit ioBroker auf die CCU3 mit rpc zugreifen. Ist dies möglich
oder gibt dies Probleme da beide auf die selben ports der ccu zugreifen.
Danke ...
Nein, dass funktioniert problemlos parallel. Bei mir läuft FHEM, ioBroker und openHab gleichzeitig. Alle 3 sind per RPC an die gleiche CCU angebunden. Eine CCU3 steckt das auch Performance mäßig locker weg.
Hallo zap,
ich habe heute nach einem Neustart wieder diese Meldungen. Eventuell wird etwas zu früh gestartet?
2021.01.20 18:31:25 2: HMCCU [HMCCU3] Get RPC device for interface HmIP-RF
2021.01.20 18:31:25 2: HMCCURPCPROC [d_rpc070063BidCos_RF] RPC server process started for interface BidCos-RF with PID=7115
2021.01.20 18:31:25 2: HMCCURPCPROC [d_rpc070063BidCos_RF] Initializing RPC server CB2001070060070063 for interface BidCos-RF
2021.01.20 18:31:25 1: HMCCURPCPROC [d_rpc070063BidCos_RF] RPC server starting
2021.01.20 18:31:25 2: HMCCURPCPROC [d_rpc070063BidCos_RF] Callback server CB2001070060070063 created. Listening on port 7411
2021.01.20 18:31:25 2: HMCCURPCPROC [d_rpc070063BidCos_RF] CB2001070060070063 accepting connections. PID=7115
2021.01.20 18:31:25 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 1324.
2021.01.20 18:31:25 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 1325.
2021.01.20 18:31:25 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 1321.
2021.01.20 18:31:26 2: HMCCURPCPROC [d_rpc070063HmIP_RF] RPC server process started for interface HmIP-RF with PID=7116
2021.01.20 18:31:26 2: HMCCURPCPROC [d_rpc070063HmIP_RF] Initializing RPC server CB2010070060070063 for interface HmIP-RF
2021.01.20 18:31:26 1: HMCCURPCPROC [d_rpc070063HmIP_RF] RPC server starting
2021.01.20 18:31:26 2: HMCCURPCPROC [d_rpc070063HmIP_RF] Callback server CB2010070060070063 created. Listening on port 7420
2021.01.20 18:31:26 2: HMCCURPCPROC [d_rpc070063HmIP_RF] CB2010070060070063 accepting connections. PID=7116
2021.01.20 18:31:26 2: HMCCURPCPROC [d_rpc070063BidCos_RF] RPC server CB2001070060070063 enters server loop
2021.01.20 18:31:26 2: HMCCURPCPROC [d_rpc070063BidCos_RF] Registering callback http://192.168.70.60:7411/fh2001 of type A with ID CB2001070060070063 at http://192.168.70.63:2001
2021.01.20 18:31:26 1: HMCCURPCPROC [d_rpc070063BidCos_RF] RPC server CB2001070060070063 running
2021.01.20 18:31:26 1: HMCCURPCPROC [d_rpc070063BidCos_RF] Scheduled CCU ping every 300 seconds
Es funktioniert aber noch alles ;D
Viele Grüße
Jürgen
Zitat von: zap am 20 Januar 2021, 17:29:59
Post #316
... Ausgabe von get deviceInfo und get paramDesc ...
Device channels and datapoints
CHN NEQ0441853:0 HM-Sec-SD-2 NEQ0441853:0
DPT {b} BidCos-RF.NEQ0441853:0.UNREACH = false [RE]
DPT {b} BidCos-RF.NEQ0441853:0.STICKY_UNREACH = false [RWE]
DPT {b} BidCos-RF.NEQ0441853:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.NEQ0441853:0.LOWBAT = false [RE]
DPT {b} BidCos-RF.NEQ0441853:0.DUTYCYCLE = false [RE]
DPT {n} BidCos-RF.NEQ0441853:0.RSSI_DEVICE = 1 [RE]
DPT {n} BidCos-RF.NEQ0441853:0.RSSI_PEER = 1 [RE]
DPT {n} BidCos-RF.NEQ0441853:0.AES_KEY = 0 [R]
CHN NEQ0441853:1 HM-Sec-SD-2 NEQ0441853:1
DPT {i} BidCos-RF.NEQ0441853:1.ERROR_ALARM_TEST = 0 [RE]
DPT {i} BidCos-RF.NEQ0441853:1.ERROR_SMOKE_CHAMBER = 0 [RE]
DPT {b} BidCos-RF.NEQ0441853:1.STATE = false [RE]
DPT {b} BidCos-RF.NEQ0441853:1.LOWBAT = false [RE]
DPT {b} BidCos-RF.NEQ0441853:1.INSTALL_TEST = [E]
Device detection:
StateDatapoint = 1.SMOKE_DETECTOR_ALARM_STATUS SMOKE_DETECTOR
No control datapoint detected
Recommended module for device definition: HMCCUCHN
Device description
Device NEQ0441853 HM-Sec-SD-2 NEQ0441853 [HM-Sec-SD-2]
CHILDREN: NEQ0441853:0,NEQ0441853:1
FIRMWARE: 1.0
FLAGS: Visible
INTERFACE: KEQ0583730
PARAMSETS: MASTER
RF_ADDRESS: 4959260
ROAMING: 0
RX_MODE: BURST
UPDATABLE: 0
Channel NEQ0441853:0 HM-Sec-SD-2 NEQ0441853:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: NEQ0441853
PARENT_TYPE: HM-Sec-SD-2
Channel NEQ0441853:1 HM-Sec-SD-2 NEQ0441853:1 [SMOKE_DETECTOR] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
PARAMSETS: MASTER,VALUES
PARENT: NEQ0441853
PARENT_TYPE: HM-Sec-SD-2
TEAM: *NEQ0441853:1
TEAM_TAG: smoke_detector
Device
Paramset MASTER
DEV_RPT_CNT_MAX: INTEGER [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
Channel 0
Paramset VALUES
AES_KEY: INTEGER [R] [] RANGE=0...127 DFLT=0
CONFIG_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
DUTYCYCLE: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
LOWBAT: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
RSSI_DEVICE: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648...2147483647 DFLT=0
RSSI_PEER: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648...2147483647 DFLT=0
STICKY_UNREACH: BOOL [R,W,E] [Sticky,Internal] RANGE=0...1 DFLT=0
UNREACH: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
Channel 1
Paramset VALUES
ERROR_ALARM_TEST: ENUM [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0 VALUES=NO_ERROR,ALARM_TEST_FAILED
ERROR_SMOKE_CHAMBER: ENUM [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0 VALUES=NO_ERROR,DEGRADED_SMOKE_CHAMBER
INSTALL_TEST: ACTION [E] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
LOWBAT: BOOL [R,E] [Visible,Sticky] RANGE=0...1 DFLT=0
STATE: BOOL [R,E] [Visible,Sticky] RANGE=0...1 DFLT=0
@juemuc: Diese Meldungen werden beim Auslesen der CCU Programme verursacht. Entweder ist das ein Fehler in HMCCU oder eines der CCU Programme ist in einem undefinierten Zustand. Ich habe das Logging an der Stelle erweitert. Ich checke heute oder morgen die neue Version ein.
@Ralph Danke für die Infos. Kern des Problems ist, dass HMCCU Deinen Rauchmelder (BidCos) für einen HmIP Rauchmelder hält. Normalerweise hat EQ-3 das von Herstellerseite getrennt, d.h. die internen Bezeichnungen unterscheidet sich.
Beispiel Taster: der BidCos Taster hat die Rolle "KEY" während der HmIP Taster die Rolle "KEY_TRANSCEIVER" hat. Dadurch kann HMCCU bei unterscheiden.
Bei den Rauchmeldern hingegen läuft alles (BidCos und HmIP) unter "SMOKE_DETECTOR".
Folge: HMCCU verwendet den HmIP-Datenpunkt SMOKE_DETECTOR_ALARM_STATUS für Deinen Rauchmelder, obwohl der bei Dir STATE heißt.
Folge für mich: Ich muss diesen Lapsus auf EQ-3 Seite bei mir irgendwie ausbügeln.
Das nur zum Stand der Dinge.
Zitat von: zap am 21 Januar 2021, 09:27:33
Folge für mich: Ich muss diesen Lapsus auf EQ-3 Seite bei mir irgendwie ausbügeln.
Mist. Danke für Mühe. Wäre nett, falls Du dazu kommst.
Ich grüble gerade darüber nach, ob es nicht möglich wäre, den HM-UART-Aufsteck-Chip und (m)einen USB-Stick mit HMCCU parallel laufen zu lassen und mit dem Stick und debmatic dann nur HM-IP zu bedienen und die alten HM-Teile nach wie vor über den HM-UART-Aufsteck-Chip abzuhandeln. Dann könnte man sich die Verbiegerei sparen. Nur so ein Gedanke.
Im Moment habe ich leider ein neues Problem.
Nach kompletter Neuinstallation eines Raspberry 3 B+ mit
HMCCU nach: https://forum.fhem.de/index.php/topic,107077.0.html
und
define myCCU HMCCU IP-Addresse
kommt nun plötzlich im Log
2021.01.21 16:51:03 1: reload: Error:Modul 88_HMCCU deactivated:
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 37.
Can't locate RPC/XML/Client.pm in @INC (you may need to install the RPC::XML::Client module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/arm-linux-gnueabihf/perl5/5.24 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at ./FHEM/88_HMCCU.pm line 37.
Gelesen und verstanden habe ich das wohl, nur
wie ich das (nach) installiere, das weiß ich leider nicht.
Kochrezept erbeten.
https://wiki.fhem.de/wiki/HMCCU#Installation
Zitat von: kjmEjfu am 21 Januar 2021, 17:24:15
https://wiki.fhem.de/wiki/HMCCU#Installation
Danke. Asche auf mein haupt. Sch... , wenn man doof ist.
Zitat von: zap am 21 Januar 2021, 09:27:33
zu #315 , #316 , #319 , #321
Diese DOIF meldet den FeuerAlarm.
defmod di_HM_RM_WoZi DOIF ([HM_RM_WoZi:"^STATE:.true$"]) ({DebianMail('deinemail@spam.it','^ Alarm $DEVICE FEUER',ReadingsTimestamp("$DEVICE","STATE","0"))})
Zum Testen setze in der DOIF den STATE auf false. Und drücke den Taster am Melder.
Das löst das Problem des Counters und des Power On in den oberen Posts leider noch nicht
@Ralph
Da hat CUL_HM wohl einige Sonderlocken eingebaut.
state wird gehen, sobald ich die Device Config aktualisiert habe. Die anderen beiden Readings musst Du Dir mit FHEM Bordmitteln (z.B. Dummy Device oder User Readings ) selbst bauen.
HMCCU verfolgt einen generischen Ansatz.
Zitat von: zap am 22 Januar 2021, 10:58:17
Da hat CUL_HM wohl einige Sonderlocken eingebaut.
Ja, SCHÖNE !
Den "state" hab ich mir mal selbst gebaut:
attr HM_RM_WoZi userReadings state {ReadingsVal("HM_RM_WoZi","devstate",0)}Den braucht man nämlich so und dringend, wenn man eine sub verwendet, die prüft, ob sich die Devices regelmäßig melden.
Dieses Relikt aus FS20-Zeiten verwende ich noch, weil: a) ich solche noch betreibe und b) modernere eingebunden werden.
Wie das mit den anderen gehen soll, das ist mir völlig unklar ?
Bleibt mir wohl nur der Ansatz mit dem Mischbetrieb, debmatic macht dann eben nur Hm-IP, CUL_HM macht HM-alt.
Hier geht es z.B. um einen Zähler, der mit DOIF realisiert wurde:
https://forum.fhem.de/index.php?topic=100614.0
Also ich denke, beide Anforderungen lassen sich mit Bordmitteln lösen. Aber Du kannst natürlich auch zweigleisig fahren.
P.S. Ein Counter zum Zählen der Rauchmelder-Alarme wäre bei mir seit 2 Jahren = 0. Wozu brauchst Du diese Info?
@zap
Danke für den Zähler, wieder was dazugelernt.
@all z. K.
Die Rauchmelder HM_Sec_SD_2 sind unter CUL_HM hervorragend und unter HMCCU so besch... bedient,
dass ich diese aus debmatic mit HMCCU ausgliedere und wieder zurück in CUL_HM eingliedere.
( @ zap: wegen mir brauchst Du Dich deswegen nicht weiter zu bemühen und die Schwächen von eQ-3 verbessern )
Letzlich ausschlaggebender Punkt ist, dass die regelmäßige "alive"-Meldung nicht in der von mir gewünschten Form kommt.
Ich muss also doppelgleisig fahren.
Höchst bedauerlich.
Wer vergleichn möchte: oben sind Auszüge.
Bzgl. "Activity alive": Die Logik bei der CCU ist umgekehrt. Die CCU meldet über den Datenpunkt UNREACH, wenn ein Geräte nicht erreichbar ist und über den Datenpunkt STICKY_UNREACH, wenn es wieder erreichbar ist. Aber beide Datenpunkte werden nur aktualisiert, wenn sich der Status tatsächlich geändert hat. Eine ständige bzw. regelmäßige Benachrichtigung findet nicht statt.
Wenn eine Nachricht UNREACH oder STICKY_UNREACH kommt, aktualisiert HMCCU das Reading "activity" entsprechend.
Das ist - bei der CCU - unabhängig vom Protokoll (BidCos, HmIP, ...)
Hallo zap,
ich habe gestern abend die 4.4.060 Beta von Github eingespielt,
erstmals Chapeau und Danke an Dich! Generell funktioniert (fast) alles,
1) Installation nach Anleitung vom ersten Post
2) Alle Devices geloescht und neu definiert
Hier meine Beobachtungen / feedback:
Ich habe folgende Beobachtungen bei den 1) den Optischen Fenster auf/zu Detektoren, 4) runden HmIP-SPI Präsenzmeldern, und mit den 6) HmIP-SMI55 MotionDetektoren im 55-er Einbaurahmen, evtl kannst Du Dir das mal anschauen?
Bei 6) gehe ich jetzt zurueck von HMCCUCHN auf eine definition HMCCUDEV (also die definition von 4.3), damit funktionieren auch die Taster
Bei 2) funktioniert das "attr event-on-change-reading state" funktioniert, das state event kommt immer 2 mal, siehe code-tag
# Name Model Interface Address Channels Neuer TYPE
1) HMIP-SWDO01 HMIP-SWDO HmIP-RF 01234567890123 3 -> HMCCUCHN, Fehlermeldung Logfile
2) HMIP-PSM01 HMIP-PSM HmIP-RF 01234567890123 9 -> HMCCUDEV, Controlchannel & state channel muss gesetzt werden, aber event-on-change-readings state funktioniert nicht, das state event kommt immer 2 mal
3) HmIP-ASIR HmIP-ASIR-B1 HmIP-RF 01234567890123 4 -> HMCCUCHN, alles OK
4) HmIP-SPI HmIP-SPI HmIP-RF 01234567890123 4 -> HMCCUCHN, (Failed to detect device settings)
5) HmIP-SLO0 HmIP-SLO HmIP-RF 01234567890123 4 -> HMCCUCHN, alles OK
6) HmIP-SMI55 HmIP-SMI55 HmIP-RF 01234567890123 5 -> HMCCUCHN, Taster Press long short sind nicht sichtbar
7) HmIP-SCI2 HmIP-SCI HmIP-RF 01234567890123 3 -> HMCCUCHN, alles OK
Hier die Listings, und die FehlerBeschreibungen:
1)
2021.01.23 15:14:50 1: HMCCURPCPROC [d_rpc000022HmIP_RF] Error in request getParamset 01234567890123 SERVICE:
2021.01.23 15:14:50 2: HMCCUCHN [Briefkasten4] Can't get parameterset SERVICE for address 01234567890123
2021.01.23 15:14:56 1: HMCCURPCPROC [d_rpc000022HmIP_RF] Error in request getParamset 01234567890123:0 SERVICE: Generic error (TRANSACTION_DISCARDED_FOR_UNREACHABLE_DEVICE)
2021.01.23 15:14:56 2: HMCCUCHN [Briefkasten4] Can't get parameterset SERVICE for address 01234567890123:0
2021.01.23 15:14:58 1: HMCCURPCPROC [d_rpc000022HmIP_RF] Error in request getParamset 01234567890123:1 SERVICE: Generic error (UNREACH)
2021.01.23 15:14:58 2: HMCCUCHN [Briefkasten4] Can't get parameterset SERVICE for address 01234567890123:1
defmod Briefkasten4 HMCCUCHN 01234567890123:1
attr Briefkasten4 IODev HMCCU3
attr Briefkasten4 alias Briefkasten4 Mitte
attr Briefkasten4 event-on-change-reading state,battery
attr Briefkasten4 group ALARME
attr Briefkasten4 room Alarme,HomeMaticIP
Device channels and datapoints
CHN 01234567890123:0 HMIP-SWDO04 Mitte:0
DPT {b} HmIP-RF.01234567890123:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.01234567890123:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.01234567890123:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.01234567890123:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.01234567890123:0.OPERATING_VOLTAGE = 1.400000 [RE]
DPT {n} HmIP-RF.01234567890123:0.RSSI_DEVICE = 128 [RE]
DPT {n} HmIP-RF.01234567890123:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.01234567890123:0.SABOTAGE = false [RE]
DPT {b} HmIP-RF.01234567890123:0.UNREACH = true [RE]
DPT {b} HmIP-RF.01234567890123:0.UPDATE_PENDING = false [RE]
DPT {b} HmIP-RF.01234567890123:0.INSTALL_TEST = true [RW]
DPT {i} HmIP-RF.01234567890123:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
CHN 01234567890123:1 HMIP-SWDO4:1
DPT {i} HmIP-RF.01234567890123:1.STATE = 0 [RE]
Device detection:
StateDatapoint = 1.STATE SHUTTER_CONTACT
No control datapoint detected
Recommended module for device definition: HMCCUCHN
Current state datapoint = 1.STATE
Current control datapoint = 1.?
Device description
Device 01234567890123 HMIP-SWDO04 Mitte [HMIP-SWDO]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 01234567890123:0,01234567890123:1,01234567890123:2
DIRECTION: NONE
FIRMWARE: 1.16.8
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 6639898
ROAMING: 0
RX_MODE: CONFIG
SUBTYPE: SWD
UPDATABLE: 1
Channel 01234567890123:0 HMIP-SWDO04 Mitte:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 01234567890123
PARENT_TYPE: HMIP-SWDO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 01234567890123:1 HMIP-SWDO4:1 [SHUTTER_CONTACT] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: WINDOW_SWITCH,CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 01234567890123
PARENT_TYPE: HMIP-SWDO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Defaults
Support for role SHUTTER_CONTACT of device type HMIP-SWDO is built in.
2)
2021-01-23 20:31:08 HMCCUDEV HMIP_PSM2 off
2021-01-23 20:31:09 HMCCUDEV HMIP_PSM2 off
2021-01-23 20:31:14 Global global SAVE
2021-01-23 20:31:20 Pushover pushmsg .......
2021-01-23 20:31:20 HMCCUDEV HMIP_PSM2 on
2021-01-23 20:31:20 HUEDevice MotionSensor1_Schlaf motion
2021-01-23 20:31:21 Pushover pushmsg msg title...
2021-01-23 20:31:21 HMCCUDEV HMIP_PSM2 on
defmod HMIP_PSM2 HMCCUDEV 01234567890123
attr HMIP_PSM2 IODev HMCCU3
attr HMIP_PSM2 alias KlimaPower
attr HMIP_PSM2 ccureadingfilter (STATE|CURRENT|POWER|^ENERGY_COUNTER)
attr HMIP_PSM2 ccureadingname 6.POWER:power;;6.ENERGY_COUNTER:energy
attr HMIP_PSM2 controlchannel 3
attr HMIP_PSM2 controldatapoint 3.STATE
attr HMIP_PSM2 devStateIcon off:ios-off on:ios-on-green .*:noIcon
attr HMIP_PSM2 event-on-change-reading power,state
attr HMIP_PSM2 group SCHALTER
attr HMIP_PSM2 room Energy,HomeMaticIP,Schalter
attr HMIP_PSM2 sortby 221
attr HMIP_PSM2 stateFormat {my $state = ReadingsVal($name,"state","nA");; \
my $power = ReadingsNum($name,"power",-1);;\
my $string = $state . " " . $power . " W";;\
if ($state eq "on") {return '<font color="darkorange"><b>' . $string . '</b></font>';;} \
else {return $state }}
attr HMIP_PSM2 statechannel 3
attr HMIP_PSM2 statedatapoint 3.STATE
attr HMIP_PSM2 statevals on:1,off:0
attr HMIP_PSM2 stripnumber 1
attr HMIP_PSM2 webCmd on:off
Device channels and datapoints
CHN 0001D709903D2D:0 HMIP-PSM02:0
DPT {f} HmIP-RF.0001D709903D2D:0.ACTUAL_TEMPERATURE = 30.000000 [RE]
DPT {b} HmIP-RF.0001D709903D2D:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.0001D709903D2D:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.0001D709903D2D:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.0001D709903D2D:0.ERROR_OVERHEAT = false [RE]
DPT {f} HmIP-RF.0001D709903D2D:0.OPERATING_VOLTAGE = 0.000000 [RE]
DPT {n} HmIP-RF.0001D709903D2D:0.RSSI_DEVICE = 192 [RE]
DPT {n} HmIP-RF.0001D709903D2D:0.RSSI_PEER = 192 [RE]
DPT {b} HmIP-RF.0001D709903D2D:0.UNREACH = false [RE]
DPT {b} HmIP-RF.0001D709903D2D:0.UPDATE_PENDING = false [RE]
DPT {i} HmIP-RF.0001D709903D2D:0.ACTUAL_TEMPERATURE_STATUS = 0 [RE]
DPT {b} HmIP-RF.0001D709903D2D:0.INSTALL_TEST = true [RW]
DPT {i} HmIP-RF.0001D709903D2D:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
CHN 0001D709903D2D:1 HMIP-PSM 0001D709903D2D:1
DPT {b} HmIP-RF.0001D709903D2D:1.PRESS_LONG = [E]
DPT {b} HmIP-RF.0001D709903D2D:1.PRESS_SHORT = [E]
CHN 0001D709903D2D:2 HMIP-PSM 0001D709903D2D:2
DPT {i} HmIP-RF.0001D709903D2D:2.PROCESS = 0 [RE]
DPT {i} HmIP-RF.0001D709903D2D:2.SECTION = 0 [RE]
DPT {b} HmIP-RF.0001D709903D2D:2.STATE = false [RE]
DPT {i} HmIP-RF.0001D709903D2D:2.SECTION_STATUS = 0 [RE]
CHN 0001D709903D2D:3 HMIP-PSM 0001D709903D2D:3
DPT {f} HmIP-RF.0001D709903D2D:3.ON_TIME = [W]
DPT {i} HmIP-RF.0001D709903D2D:3.PROCESS = 0 [RE]
DPT {i} HmIP-RF.0001D709903D2D:3.SECTION = 0 [RE]
DPT {b} HmIP-RF.0001D709903D2D:3.STATE = false [RWE]
DPT {i} HmIP-RF.0001D709903D2D:3.SECTION_STATUS = 0 [RE]
DPT {s} HmIP-RF.0001D709903D2D:3.COMBINED_PARAMETER = [W]
CHN 0001D709903D2D:4 HMIP-PSM 0001D709903D2D:4
DPT {f} HmIP-RF.0001D709903D2D:4.ON_TIME = [W]
DPT {i} HmIP-RF.0001D709903D2D:4.PROCESS = 0 [RE]
DPT {i} HmIP-RF.0001D709903D2D:4.SECTION = 0 [RE]
DPT {b} HmIP-RF.0001D709903D2D:4.STATE = false [RWE]
DPT {i} HmIP-RF.0001D709903D2D:4.SECTION_STATUS = 0 [RE]
DPT {s} HmIP-RF.0001D709903D2D:4.COMBINED_PARAMETER = [W]
CHN 0001D709903D2D:5 HMIP-PSM 0001D709903D2D:5
DPT {f} HmIP-RF.0001D709903D2D:5.ON_TIME = [W]
DPT {i} HmIP-RF.0001D709903D2D:5.PROCESS = 0 [RE]
DPT {i} HmIP-RF.0001D709903D2D:5.SECTION = 0 [RE]
DPT {b} HmIP-RF.0001D709903D2D:5.STATE = false [RWE]
DPT {i} HmIP-RF.0001D709903D2D:5.SECTION_STATUS = 0 [RE]
DPT {s} HmIP-RF.0001D709903D2D:5.COMBINED_PARAMETER = [W]
CHN 0001D709903D2D:6 HMIP-PSM 0001D709903D2D:6
DPT {f} HmIP-RF.0001D709903D2D:6.CURRENT = 0.000000 [RE]
DPT {f} HmIP-RF.0001D709903D2D:6.ENERGY_COUNTER = 0.000000 [RE]
DPT {b} HmIP-RF.0001D709903D2D:6.ENERGY_COUNTER_OVERFLOW = false [RE]
DPT {f} HmIP-RF.0001D709903D2D:6.FREQUENCY = 50.010000 [RE]
DPT {f} HmIP-RF.0001D709903D2D:6.POWER = 0.000000 [RE]
DPT {f} HmIP-RF.0001D709903D2D:6.VOLTAGE = 229.900000 [RE]
DPT {i} HmIP-RF.0001D709903D2D:6.CURRENT_STATUS = 0 [RE]
DPT {i} HmIP-RF.0001D709903D2D:6.FREQUENCY_STATUS = 0 [RE]
DPT {i} HmIP-RF.0001D709903D2D:6.POWER_STATUS = 0 [RE]
DPT {i} HmIP-RF.0001D709903D2D:6.VOLTAGE_STATUS = 0 [RE]
CHN 0001D709903D2D:8 HMIP-PSM 0001D709903D2D:8
DPT {i} HmIP-RF.0001D709903D2D:8.WEEK_PROGRAM_CHANNEL_LOCKS = 0 [RE]
DPT {i} HmIP-RF.0001D709903D2D:8.WEEK_PROGRAM_TARGET_CHANNEL_LOCK = [W]
DPT {i} HmIP-RF.0001D709903D2D:8.WEEK_PROGRAM_TARGET_CHANNEL_LOCKS = [W]
DPT {s} HmIP-RF.0001D709903D2D:8.COMBINED_PARAMETER = [W]
Device detection:
StateDatapoint = 3.STATE SWITCH_VIRTUAL_RECEIVER
StateDatapoint = 4.STATE SWITCH_VIRTUAL_RECEIVER
StateDatapoint = 5.STATE SWITCH_VIRTUAL_RECEIVER
ControlDatapoint = 3.STATE SWITCH_VIRTUAL_RECEIVER
ControlDatapoint = 4.STATE SWITCH_VIRTUAL_RECEIVER
ControlDatapoint = 5.STATE SWITCH_VIRTUAL_RECEIVER
Recommended module for device definition: HMCCUDEV
Current state datapoint = 3.STATE
Current control datapoint = 3.STATE
Device description
Device 0001D709903D2D HMIP-PSM02 [HMIP-PSM]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 0001D709903D2D:0,0001D709903D2D:1,0001D709903D2D:2,0001D709903D2D:3,0001D709903D2D:4,0001D709903D2D:5,0001D709903D2D:6,0001D709903D2D:7,0001D709903D2D:8
DIRECTION: NONE
FIRMWARE: 2.18.14
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 8106331
ROAMING: 0
RX_MODE:
SUBTYPE: PSM
UPDATABLE: 1
Channel 0001D709903D2D:0 HMIP-PSM02:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 0001D709903D2D
PARENT_TYPE: HMIP-PSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0001D709903D2D:1 HMIP-PSM 0001D709903D2D:1 [KEY_TRANSCEIVER] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 0001D709903D2D
PARENT_TYPE: HMIP-PSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0001D709903D2D:2 HMIP-PSM 0001D709903D2D:2 [SWITCH_TRANSMITTER] known
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 0001D709903D2D
PARENT_TYPE: HMIP-PSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0001D709903D2D:3 HMIP-PSM 0001D709903D2D:3 [SWITCH_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: REMOTE_CONTROL,SWITCH,CONDITIONAL_SWITCH,LEVEL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 0001D709903D2D
PARENT_TYPE: HMIP-PSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0001D709903D2D:4 HMIP-PSM 0001D709903D2D:4 [SWITCH_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: REMOTE_CONTROL,SWITCH,CONDITIONAL_SWITCH,LEVEL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 0001D709903D2D
PARENT_TYPE: HMIP-PSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0001D709903D2D:5 HMIP-PSM 0001D709903D2D:5 [SWITCH_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: REMOTE_CONTROL,SWITCH,CONDITIONAL_SWITCH,LEVEL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 0001D709903D2D
PARENT_TYPE: HMIP-PSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0001D709903D2D:6 HMIP-PSM 0001D709903D2D:6 [ENERGIE_METER_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 0001D709903D2D
PARENT_TYPE: HMIP-PSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0001D709903D2D:7 HMIP-PSM 0001D709903D2D:7 [COND_SWITCH_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 0001D709903D2D
PARENT_TYPE: HMIP-PSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0001D709903D2D:8 HMIP-PSM 0001D709903D2D:8 [SWITCH_WEEK_PROFILE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 0001D709903D2D
PARENT_TYPE: HMIP-PSM
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Defaults
Support for role SWITCH_VIRTUAL_RECEIVER of device type HMIP-PSM is built in.
4)
defmod PresenceDetect1_Flur HMCCUCHN 01234567890123:1
attr PresenceDetect1_Flur IODev HMCCU3
attr PresenceDetect1_Flur alias Presence1-Flur
attr PresenceDetect1_Flur ccureadingfilter (^PRESENCE|^ILLUMINATION|^LOW_BAT)
attr PresenceDetect1_Flur ccureadingformat datapoint
attr PresenceDetect1_Flur ccureadingname ILLUMINATION:brightness;;PRESENCE_DETECTION_STATE:presence
attr PresenceDetect1_Flur controldatapoint PRESENCE_DETECTION_ACTIVE
attr PresenceDetect1_Flur event-on-change-reading battery,presence
attr PresenceDetect1_Flur eventMap /datapoint RESET_PRESENCE 1:reset/datapoint PRESENCE_DETECTION_ACTIVE 1:control on/datapoint PRESENCE_DETECTION_ACTIVE 0:control off/
attr PresenceDetect1_Flur genericDeviceType MotionSensor
attr PresenceDetect1_Flur group ALARME
attr PresenceDetect1_Flur icon message_presence
attr PresenceDetect1_Flur room AllRooms->Flur,HomeMaticIP,Presence
attr PresenceDetect1_Flur stateFormat presence, brightness Lx
attr PresenceDetect1_Flur stripnumber 1
attr PresenceDetect1_Flur substitute PRESENCE_DETECTION_STATE!(true|1):presence,(false|0):noPresence;;PRESENCE_DETECTION_ACTIVE!(0|false):off,(1|true):on;;LOW_BAT!(0|false):ok,(1|true):low
attr PresenceDetect1_Flur userReadings BatterieWechsel
attr PresenceDetect1_Flur webCmd control
attr PresenceDetect1_Flur widgetOverride control:uzsuToggle,off,on
Device channels and datapoints
CHN 01234567890123:0 HmIP-SPI-Flur:0
DPT {b} HmIP-RF.01234567890123:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.01234567890123:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.01234567890123:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.01234567890123:0.INSTALL_TEST = true [RW]
DPT {b} HmIP-RF.01234567890123:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.01234567890123:0.OPERATING_VOLTAGE = 2.800000 [RE]
DPT {i} HmIP-RF.01234567890123:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.01234567890123:0.RSSI_DEVICE = 191 [RE]
DPT {n} HmIP-RF.01234567890123:0.RSSI_PEER = 211 [RE]
DPT {b} HmIP-RF.01234567890123:0.SABOTAGE = false [RE]
DPT {b} HmIP-RF.01234567890123:0.UNREACH = false [RE]
DPT {b} HmIP-RF.01234567890123:0.UPDATE_PENDING = false [RE]
CHN 01234567890123:1 HmIP-SPI 01234567890123:1
DPT {f} HmIP-RF.01234567890123:1.CURRENT_ILLUMINATION = 6.100000 [RE]
DPT {i} HmIP-RF.01234567890123:1.CURRENT_ILLUMINATION_STATUS = 0 [RE]
DPT {f} HmIP-RF.01234567890123:1.ILLUMINATION = 18.300000 [RE]
DPT {i} HmIP-RF.01234567890123:1.ILLUMINATION_STATUS = 0 [RE]
DPT {b} HmIP-RF.01234567890123:1.PRESENCE_DETECTION_ACTIVE = true [RWE]
DPT {b} HmIP-RF.01234567890123:1.PRESENCE_DETECTION_STATE = false [RE]
DPT {b} HmIP-RF.01234567890123:1.RESET_PRESENCE = [W]
Device detection:
No state datapoint detected
No control datapoint detected
Failed to detect device settings. Device must be configured manually.
Current state datapoint = 1.PRESENCE_DETECTION_ACTIVE
Current control datapoint = 1.PRESENCE_DETECTION_ACTIVE
Device description
Device 01234567890123 HmIP-SPI-Flur [HmIP-SPI]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 01234567890123:0,01234567890123:1,01234567890123:2,01234567890123:3
DIRECTION: NONE
FIRMWARE: 1.4.0
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 3216161
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG,BURST
SUBTYPE: SPI
UPDATABLE: 1
Channel 01234567890123:0 HmIP-SPI-Flur:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 01234567890123
PARENT_TYPE: HmIP-SPI
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 01234567890123:1 HmIP-SPI 01234567890123:1 [PRESENCEDETECTOR_TRANSCEIVER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 01234567890123
PARENT_TYPE: HmIP-SPI
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Defaults
6)
defmod MotionDetect1_Wohn HMCCUCHN 01234567890123:3
attr MotionDetect1_Wohn IODev HMCCU3
attr MotionDetect1_Wohn ccureadingfilter (^MOTION|^ILLUMINATION|^LOW_BAT|^PRESS.*)
attr MotionDetect1_Wohn ccureadingformat datapoint
attr MotionDetect1_Wohn ccureadingname 0.(LOWBAT|LOW_BAT):battery;;1.PRESS_LONG:long1;;1.PRESS_SHORT:short1;;2.PRESS_LONG:long2;;2.PRESS_SHORT:short2;;ILLUMINATION:brightness;;MOTION:motion
attr MotionDetect1_Wohn event-on-change-reading battery,motion
attr MotionDetect1_Wohn genericDeviceType OccupancySensor
attr MotionDetect1_Wohn icon people_sensor
attr MotionDetect1_Wohn room HomeMaticIP,Schalter,AllRooms->Wohnzimmer
attr MotionDetect1_Wohn stateFormat motion, brightness Lx
attr MotionDetect1_Wohn substitute 0.LOW_BAT!(0|false):ok,(1|true):low;;;;PRESS_LONG,PRESS_SHORT!(1|true):pressed,(0|false):released;;;;MOTION,MOTION_DETECTION_ACTIVE!(0|false):no,(1|true):yes;;;;ILLUMINATION_STATUS!0:normal,1:unknown,2:overflow
Device channels and datapoints
CHN 01234567890123:0 HmIP-SMI55-Wohn:0
DPT {b} HmIP-RF.01234567890123:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.01234567890123:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.01234567890123:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.01234567890123:0.INSTALL_TEST = true [RW]
DPT {b} HmIP-RF.01234567890123:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.01234567890123:0.OPERATING_VOLTAGE = 2.700000 [RE]
DPT {i} HmIP-RF.01234567890123:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.01234567890123:0.RSSI_DEVICE = 203 [RE]
DPT {n} HmIP-RF.01234567890123:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.01234567890123:0.UNREACH = false [RE]
DPT {b} HmIP-RF.01234567890123:0.UPDATE_PENDING = false [RE]
CHN 01234567890123:1 HmIP-SMI55 01234567890123:1
DPT {b} HmIP-RF.01234567890123:1.PRESS_LONG = false [E]
DPT {b} HmIP-RF.01234567890123:1.PRESS_SHORT = false [E]
CHN 01234567890123:2 HmIP-SMI55 01234567890123:2
DPT {b} HmIP-RF.01234567890123:2.PRESS_LONG = false [E]
DPT {b} HmIP-RF.01234567890123:2.PRESS_SHORT = false [E]
CHN 01234567890123:3 HmIP-SMI55 01234567890123:3
DPT {f} HmIP-RF.01234567890123:3.CURRENT_ILLUMINATION = 0.000000 [RE]
DPT {i} HmIP-RF.01234567890123:3.CURRENT_ILLUMINATION_STATUS = 0 [RE]
DPT {f} HmIP-RF.01234567890123:3.ILLUMINATION = 92.600000 [RE]
DPT {i} HmIP-RF.01234567890123:3.ILLUMINATION_STATUS = 0 [RE]
DPT {b} HmIP-RF.01234567890123:3.MOTION = false [RE]
DPT {b} HmIP-RF.01234567890123:3.MOTION_DETECTION_ACTIVE = true [RWE]
DPT {b} HmIP-RF.01234567890123:3.RESET_MOTION = [W]
Device detection:
StateDatapoint = 3.MOTION MOTIONDETECTOR_TRANSCEIVER
ControlDatapoint = 3.MOTION_DETECTION_ACTIVE MOTIONDETECTOR_TRANSCEIVER
Recommended module for device definition: HMCCUCHN
Current state datapoint = 3.MOTION
Current control datapoint = 3.MOTION_DETECTION_ACTIVE
Device description
Device 01234567890123 HmIP-SMI55-Wohn [HmIP-SMI55]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 01234567890123:0,01234567890123:1,01234567890123:2,01234567890123:3,01234567890123:4
DIRECTION: NONE
FIRMWARE: 1.0.12
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 4481850
ROAMING: 0
RX_MODE: CONFIG
SUBTYPE: SMI55
UPDATABLE: 1
Channel 01234567890123:0 HmIP-SMI55-Wohn:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 01234567890123
PARENT_TYPE: HmIP-SMI55
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 01234567890123:3 HmIP-SMI55 01234567890123:3 [MOTIONDETECTOR_TRANSCEIVER] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 01234567890123
PARENT_TYPE: HmIP-SMI55
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Defaults
Support for role MOTIONDETECTOR_TRANSCEIVER of device type HmIP-SMI55 is built in.
@Jamo: Ich werde nach und nach diese Antwort mit meinen Erkenntnissen aktualisieren, also nicht für jeden Punkt separat antworten.
1) HMCCU meckert an, dass es das Device nicht erreichen kann (bzw. die CCU macht das). Ich nehme an, Du hast einen "get config" Befehl ausgeführt, der dann diese Meldungen zur Folge hatte. Ich habe keine HmIP Fenstersensoren. Allerdings funktioniert das Abfragen des Sets "SERVICE" bei mir bei anderen HmIP-Devices. Scheint also kein generelles Problem zu sein. Funktioniert bei dem Sensor ein "get values"? Das nutzt ebenfalls die RPC Schnittstelle.
2) Ist bei mir auch so. Mysteriös. Muss ich genauer analysieren. Warum musstest Du statedatapoint und controldatapoint definieren? Gab es eine entsprechende Fehlermeldung bei der Definition? Ok, kann ich reproduzieren. Scheint noch ein Fehler im Define zu sein. Wenn man sich "get deviceInfo" direkt nach dem Define anschaut, sieht man, dass state- und controldatapoint sehr wohl automatisch erkannt wurden => Bug
4) Diese Device-Rolle kennt HMCCU noch nicht, lernt sie aber jetzt und kenn sie dann beim nächsten Update.
Hallo zap,
danke schonmal, prinzipiell läuft es bei mir, ich werde also nicht mehr auf die 4.3 zurückgehen, also erstmal alles Bene.
1) Nein, ich habe keinen ''get config'' Befehl gemacht, aber ein "get update". Diese optischen FensterSensoren hängen etwas weiter entfernt im Metallbriefkasten und ueber Reflektorfolie weiss ich eben dann ob was im Briefkasten liegt oder nicht, sind aber prizipiell wirklich immer schlecht erreichbar (habe aber im Homematic WebUi keine Service message). Mit einem "get update" kann ich die Logmessage reproduzieren, scheint also wirklich so zu sein das das Device nicht erreichbar ist.
Get values funktioniert und liefert den Device 01234567890123
Channel 0 [VALUES]
CONFIG_PENDING = false
DUTY_CYCLE = false
ERROR_CODE = 0
LOW_BAT = ok
OPERATING_VOLTAGE = 1.3
OPERATING_VOLTAGE_STATUS = NORMAL
RSSI_DEVICE = -128
SABOTAGE = false
UNREACH = alive
UPDATE_PENDING = false
Channel 1 [VALUES]
STATE = closed
Die 6) hast Du auch auf dem Schirm, oder? Den 55-er Motiondetector mit den Tastern oben und unten für long/short press ? Wenn ich Dir da noch was liefern kann sag Bescheid.
Danke, und auch noch ein schönes Wochenende.
Ich steige grade in das Thema ein und habe noch so meine Schwierigkeiten:
Könnte mir bitte jemand helfen mit einer funktionierenden Definition für ein CuXD Intertechno Schalter, der als 16-Kanal Fernbedienung abgebildet wird?
Ich bekomme sowohl als HMCCUdev als auch als HMCCUCHN immer nur Fehlermeldungen
auf attr myDevice controldatapoint 1.STATE zum Beispiel
Invalid value 1.STATE
(obwohl x.STATE die einzigen auswählbaren datapoints sind)
oder auf set myDevice on
clear defaults:reset,update config
Ein Beispiel würde mir sehr helfen...
Hier mein Versuch als (empfohlener Typ) HMCCUDEV:
Internals:
CFGFN
DEF CUX4000001
FUUID 600daf1a-f33f-cee1-0ed9-9768e5b19a42ead6
IODev ccu3
NAME HM_SZ_Licht_Schrank
NR 7392
STATE off
TYPE HMCCUDEV
ccuaddr CUX4000001
ccudevstate active
ccuif CUxD
ccuname SZ_Licht_Schrank
ccurolectrl SWITCH
ccurolestate SWITCH
ccusubtype VIR-LG-ONOFF
ccutype VIR-LG-ONOFF
readonly no
OLDREADINGS:
READINGS:
2021-01-24 19:05:37 1.CONTROL 1
2021-01-24 19:05:37 1.INSTALL_TEST 0
2021-01-24 19:05:37 1.LEVEL 0
2021-01-24 19:05:37 1.MOTION noMotion
2021-01-24 19:05:37 1.RCVL 0
2021-01-24 19:05:37 1.RCVS 0
2021-01-24 19:05:37 1.STATE off
2021-01-24 19:05:37 10.INSTALL_TEST 0
2021-01-24 19:05:37 11.INSTALL_TEST 0
2021-01-24 19:05:37 12.INSTALL_TEST 0
2021-01-24 19:05:37 13.INSTALL_TEST 0
2021-01-24 19:05:37 14.INSTALL_TEST 0
2021-01-24 19:05:37 15.INSTALL_TEST 0
2021-01-24 19:05:37 16.INSTALL_TEST 0
2021-01-24 19:05:37 2.INSTALL_TEST 0
2021-01-24 19:05:37 3.INSTALL_TEST 0
2021-01-24 19:05:37 4.INSTALL_TEST 0
2021-01-24 19:05:37 5.INSTALL_TEST 0
2021-01-24 19:05:37 6.INSTALL_TEST 0
2021-01-24 19:05:37 7.INSTALL_TEST 0
2021-01-24 19:05:37 8.INSTALL_TEST 0
2021-01-24 19:05:37 9.INSTALL_TEST 0
2021-01-24 19:05:37 control off
2021-01-24 19:05:47 devstate ok
2021-01-24 19:05:47 hmstate off
2021-01-24 19:05:37 state off
hmccu:
channels 17
devspec CUX4000001
forcedev 0
nodefaults 0
role 0:MAINTENANCE,1:SWITCH,2:SWITCH,3:SWITCH,4:SWITCH,5:SWITCH,6:SWITCH,7:SWITCH,8:SWITCH,9:SWITCH,10:SWITCH,11:SWITCH,12:SWITCH,13:SWITCH,14:SWITCH,15:SWITCH,16:SWITCH
semDefaults 0
cmdlist:
control:
chn 1
dpt STATE
dp:
1.ACTIVE:
MASTER:
OSVAL true
OVAL 1
SVAL true
VAL 1
VALUES:
1.CMD_EXEC:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
1.CMD_LONG:
MASTER:
OSVAL isFFFFFFFF0FFF
OVAL isFFFFFFFF0FFF
SVAL isFFFFFFFF0FFF
VAL isFFFFFFFF0FFF
VALUES:
1.CMD_SHORT:
MASTER:
OSVAL isFFFFFFFF0FF0
OVAL isFFFFFFFF0FF0
SVAL isFFFFFFFF0FF0
VAL isFFFFFFFF0FF0
VALUES:
1.CONTROL:
VALUES:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.DEVICE:
MASTER:
OSVAL
OVAL
SVAL
VAL
VALUES:
1.INSTALL_TEST:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.LEVEL:
VALUES:
OSVAL 0
OVAL 0.000000
SVAL 0
VAL 0.000000
1.MOTION:
VALUES:
OSVAL noMotion
OVAL false
SVAL noMotion
VAL false
1.RCVL:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.RCVS:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.RCV_LONG:
MASTER:
OSVAL
OVAL
SVAL
VAL
VALUES:
1.RCV_SHORT:
MASTER:
OSVAL
OVAL
SVAL
VAL
VALUES:
1.REG_MATCH:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
1.REPEAT:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
1.STATE:
VALUES:
OSVAL off
OVAL false
SVAL off
VAL false
...
d.CONTROL:
MASTER:
OSVAL SWITCH
OVAL 1
SVAL SWITCH
VAL 1
VALUES:
d.DEVICE:
MASTER:
OSVAL
OVAL
SVAL
VAL
VALUES:
d.SYSLOG:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
roleCmds:
get:
set:
state:
chn 1
dpt STATE
Attributes:
IODev ccu3
room Homematic
statevals on:true,off:false
substitute STATE!1:on,0:off,false:off,true:on
webCmd on:off
Zitat« Antwort #332 am: 24 Januar 2021, 13:53:22 »
@Jamo: Ich werde nach und nach diese Antwort mit meinen Erkenntnissen aktualisieren, also nicht für jeden Punkt separat antworten.
Hallo zap,
ich habe gesehen, das auch bei der Kontaktschnittstelle oben in meiner Antwort unter 7) HmIP-SCI2 HmIP-SCI HmIP-RF 01234567890123 3 -> HMCCUCHN
die state events alle doppelt kommen, auch bei gesetztem event-on-change-reading.
Da ist irgendwo noch der Wurm drin.
Beste Gruesse, Jamo
Hallo!
Ich habe ein Problem mit dem einbinden der HM Geräte ins Fhem...
Habe alles neu aufgesetzt, habe von der 4.3 auf 4.4Beta geupdatet.
Auf der 4.3er konnte ich problemlos meine Channels von den HM Aktoren mit get d_ccu create AquariumLicht t=chn f=%n defattr save room=HOMEMATIC im Fhem einbinden.
Bei der 4.4er bekomme ich en nicht verrnünftig hin...
Das einzige was bis jetzt geklappt hat war
get d_ccu create ^Aquarium.* f=%n room=HOMEMATIC
Nur dann erstellt er mit das Device welches ich nicht benötige... Ich benötige die beiden Channels.
Habe es jetzt so probiert :
define Deckenfluter HMCCUCHN Deckenfluter defaults
Das hat geklappt nur ist dann im Device unter DEF "Deckenfluter defaults" drin. Solldas so?
Entweder habe ich das nicht verstanden mit dem neuen Einfügen der einzelnen Channels oder es klappt nicht. Wie ist es dann erst bei dem 8 Kanal Modul... :-[
Habe ein Bild angehangen um zu Zeigen wie der Aktor aussieht, und diese beiden channels möchte ich gerne im Fhem sehen und bedienen...
Hat jemand einen Tipp für mich?
Möglicherweise noch ein Bug in der neuen "create" Funktion. Ich habe ja den Parameter t= entfern. Bis ich das untersucht habe, sollte das funktionieren:
define Deckenfluter HMCCUCHN Deckenfluter
define AquariumLicht HMCCUCHN AquariumLicht
Jup, das hat funktioniert! Vielen Dank!
Zitat von: misux am 08 Februar 2021, 16:50:14
Jup, das hat funktioniert! Vielen Dank!
Kurzes Feedback noch zu diesem Phänomen: Derzeit unterstützt "get create" Aktoren mit mehreren identischen Schaltkanälen nicht richtig. In diesem Fall wird ein HMCCUDEV Device angelegt. Eigentlich müsste aber für jeden Kanal ein HMCCUCHN Device angelegt werden.
Ich bin dabei, das zu korrigieren.
ABER: Der bei "get create" angegebene reguläre Ausdruck für den CCU Namen bezieht sich ab 4.4 immer(!) auf Geräte, niemals auf Kanäle. HMCCU erkennt (hoffentlich), ob für ein Gerät ein HMCCUDEV oder ein/mehrere HMCCUCHN Devices erstellt werden sollen.
Moin,
muss wieder um Hilfe bitten.
Homematic WebGUI funktioniert, HM-Bidcos, HM-IP und eine HmIP-ASIR sind vorhanden,
alle funktionieren im WebGUI einschließlich Probealarm und Servicemeldung Sabotagekontakt.
Alle wurden nach FHEM importiert und sind da mit drei Fragezeichen im jeweiligen Status.
Wenn ich nun in HM-Bidcos den Taster HM-RCV-50 BidCoS-RF:1 drücke, dann wird das auch nach FHEM übergeben und alles funktioniert.
Wenn ich aber in HM-IP den Taster HmIP-RCV-50 HmIP-RCV-1:1 drücke, dann kommt das in FHEM nicht (auch nicht im Event Monitor) an.
Nämliches gilt auch für die HmIP-ASIR. Wobei mir unklar ist, ob das uberhaupt käme, da die HmIP-ASIR 3 Unterkanäle hat ?
Mag mir bitte wer sagen, was ich falsch mache ?
Was hast Du im IO Device im Attribut rpcInterfaces angehakt?
Zitat von: zap am 10 Februar 2021, 17:27:14
Was hast Du im IO Device im Attribut rpcInterfaces angehakt?
rpcinterfaces BidCos-RF,HmIP-RF
So,
habe nun nach mehreren Re-Installationen ein (noch unbefriedigendes) Ergebnis.
Die Kopplung zwischen "d_ccu" und "WebGui" geht auf HmIP-Ebene bei einem Neustart dieser Art verloren.
FHEM Shutdown, 300 Sekunden warten, Raspberry Shutdown mit -r, 1 Min warten, Ausschalten.
nach einiger Zeit wieder einschalten, alles läuft wieder
außer die Kopplung zwischen "d_ccu" und "WebGui" auf HmIP-Ebene, die kommt nicht wieder.
Kann sein, dass der HmIP-Server auf der CCU ein Problem hat. Das kommt manchmal vor. Da hilft dann nur ein Neustart der CCU. Wenn dann CCU seitig alles da ist, auch FHEM neu starten
Und noch was: Die Firewall auf der CCU muss deaktiviert oder richtig konfiguriert sein, damit FHEM zugreifen kann.
Moin allerseits
und Danke für Eure Mühe und die Ratschläge.
Die Lösung ist so einfach, dass ich mich schon schäme, diese auszuplaudern.
Im Zuge diverser Anläufe und Tests habe ich auch die fhem.cfg mal angefasst und für menschliche Augen lesbar sortiert.
Dabei erschien mir logisch alle CULs und gleichartige oben anzuordnen. Das fand wohl auch das Gesamtsystem richtig, denn jetzt gehts.
Danke soweit, ich hoffe, das bleibt so.
Und schon wieder ein Problem:
ich möchte gern die HmIP-ASIR Sirene von FHEM aus blinken und hupen lassen.
Gefunden habe ich:CHN 000AD99396682B:0 HmIP-ASIR-B1 000AD99396682B:0
DPT {b} HmIP-RF.000AD99396682B:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.000AD99396682B:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.000AD99396682B:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.000AD99396682B:0.INSTALL_TEST = true [RW]
DPT {b} HmIP-RF.000AD99396682B:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.000AD99396682B:0.OPERATING_VOLTAGE = 4.600000 [RE]
DPT {i} HmIP-RF.000AD99396682B:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.000AD99396682B:0.RSSI_DEVICE = 216 [RE]
DPT {n} HmIP-RF.000AD99396682B:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.000AD99396682B:0.SABOTAGE = false [RE]
DPT {b} HmIP-RF.000AD99396682B:0.UNREACH = false [RE]
DPT {b} HmIP-RF.000AD99396682B:0.UPDATE_PENDING = false [RE]
CHN 000AD99396682B:3 HmIP-ASIR-B1 000AD99396682B:3
DPT {b} HmIP-RF.000AD99396682B:3.ACOUSTIC_ALARM_ACTIVE = false [RE]
DPT {i} HmIP-RF.000AD99396682B:3.ACOUSTIC_ALARM_SELECTION = [W]
DPT {i} HmIP-RF.000AD99396682B:3.DURATION_UNIT = [W]
DPT {i} HmIP-RF.000AD99396682B:3.DURATION_VALUE = [W]
DPT {b} HmIP-RF.000AD99396682B:3.OPTICAL_ALARM_ACTIVE = false [RE]
DPT {i} HmIP-RF.000AD99396682B:3.OPTICAL_ALARM_SELECTION = [W]
Ich vermute mal dass das [W] für Write, also beschreibbar / setzbar steht.
Aber wie "beschreibe" ich das von FHEM aus ?
Also ich mache das so:
set Sirene_EG_Flur datapoint 3.DURATION_UNIT 1;
set Sirene_EG_Flur datapoint 3.DURATION_VALUE 10;
set Sirene_EG_Flur datapoint 3.ACOUSTIC_ALARM_SELECTION 3;
set Sirene_EG_Flur datapoint 3.OPTICAL_ALARM_SELECTION 2;
Bei der Reihenfolge muss man aufpassen, sonst passiert nichts.
Du müsstest aber auch im Device ein Setter "acousticAlarm" und "opticalAlarm" haben, damit lässt sich das besser auswählen.
Aber AFAIK musst du auch dann vorher Unit und Value definieren. Für die muss man nichts mehr zusätzlich setzen.
Danke,
funktioniert.
Zum Abstellen des Lärms und des Blinkens dasselbe senden mit hinten "0"
Mit dem "optischen" kann man herumprobieren, 3 ist beide ganz schnell.
Danke,
funktioniert.
ZitatDu müsstest aber auch im Device ein Setter "acousticAlarm" und "opticalAlarm" haben ...
Nee, habe ich nicht. Nur "set <device> datapoint", das nächste feld ist da, aber leer.
Zum Abstellen des Lärms und des Blinkens dasselbe senden mit hinten "0"
Nachtrag Wete für die Einstellungen:
Werte für AKUSTISCH:
0 = Kein akustisches Signal
1 = Frequenz steigend
2 = Frequenz fallend
3 = Frequenz steigend/fallend
4 = Frequenz tief/hoch
5 = Frequenz tief/mittel/hoch
6 = Frequenz hoch ein/aus
7 = Frequenz hoch ein, lang aus
8 = Frequenz tief ein/aus, hoch ein/aus
9 = Frequenz tief ein - lang aus, hoch ein - lang aus
10 = Batterie leer
11 = Unscharf
12 = Intern scharf
13 = Extern scharf
14 = Verzoegert intern scharf
15 = Verzoegert extern scharf
16 = Alarm Ereignis
17 = Fehler
Werte für OPTISCH
0 = Kein optisches Signal
1 = Abwechselndes langsames Blinken
2 = Gleichzeitiges langsames Blinken
3 = Gleichzeitiges schnelles Blinken
4 = Gleichzeitiges kurzes Blinken
5 = Bestaetigungssignal 0 - lang lang
6 = Bestaetigungssignal 1 - lang kurz
7 = Bestaetigungssignal 2 - lang kurz kurzHabe aber nicht alle ausprobiert.
Zitat von: Ralph am 11 Februar 2021, 12:18:33
Nee, habe ich nicht. Nur "set <device> datapoint", das nächste feld ist da, aber leer.
mach mal ein
set DEVICE defaults resetIch habe die beiden Setter sowohl bei der Innen- als auch der Außensirene.
HMCCUDEV: HmIP_ASIR No default attributes found
Welche Version von HMCCU nutzt Du eigentlich? Schau mal bitte in den Internals vom IO Device:
config
version
Übrigens: Das manuelle Sortieren der fhem.cfg ist meistens keine gute Idee
Zitat von: zap am 11 Februar 2021, 17:15:45
Welche Version von HMCCU nutzt Du eigentlich?
Internals:
CCUNum 1
Clients :HMCCUDEV:HMCCUCHN:HMCCURPC:HMCCURPCPROC:
DEF raspb ccudelay=300
FUUID 6024255d-f33f-a76b-ee09-7f0cfb0b5650d46e
NAME d_ccu
NOTIFYDEV global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
NR 25
NTFY_ORDER 50-d_ccu
RPCPID 1674,1675
RPCPRC internal
RPCState running
STATE running/Error
TYPE HMCCU
ccuaddr BidCoS-RF
ccuchannels 106
ccudevices 3
ccuif BidCos-RF
ccuinterfaces HmIP-RF,VirtualDevices,BidCos-RF
ccuip 127.0.1.1
ccuname HM-BidCoS
ccustate active
ccutype CCU2/3
host raspb
prot http
version 4.3.025
Zitat von: Ralph am 11 Februar 2021, 18:23:24
version 4.3.025
Du bist noch auf der 4.3
Wir gehen natürlich im Thread der 4.4 davon aus, dass du auch die 4.4 installiert hast :-)
Dann mal bitte das Update machen: https://forum.fhem.de/index.php/topic,107077.msg1009312.html#msg1009312
Ich wundere mich die ganze Zeit, warum das alles so seltsam ist. Devices werden nicht erkannt usw.
Ja, ich war / bin auch entsetzt und habe das update natürlich sofort gemacht.
ich habe bei der Fehlersuche so viel hin und her gemacht, dass das irgendwie passiert ist.
Ich meine mich aber zu erinnern, dass ich beim update auch mal die Meldung nothing to do bekam.
Ich schaue mal, ob nach dem update noch alles geht und kann nur um Entschuldigung bitten.
So habe nun das mir mögliche getestet, habe halt derzeit nur die HmIP-ASIR zur Verfügung.
Buttons von HmIP und Bidcos werden durchgereicht.
HmIP-ASIR bilnkt und gibt Alarm.
Die früheren Reading sind alle geändert und das 0.SABOTAGE = false [RE] - Reading ist nicht mehr da. Das ist schlecht, das muss wieder her.
Bei "get HmIP_ASIR paramgetDesc" kommt ein rechtsbündiger (wohl 4m) breiter leerer Bildschirm mit "OK".
Meine Tastendruckauswertung funktioniert auch nicht mehr, dazu bräuchte ich 0.UNREACH = false [RE]
Hier mal das Ausgelesene:Device channels and datapoints
CHN 000AD99396682B:0 HmIP-ASIR-B1 000AD99396682B:0
DPT {b} HmIP-RF.000AD99396682B:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.000AD99396682B:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.000AD99396682B:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.000AD99396682B:0.INSTALL_TEST = true [RW]
DPT {b} HmIP-RF.000AD99396682B:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.000AD99396682B:0.OPERATING_VOLTAGE = 4.600000 [RE]
DPT {i} HmIP-RF.000AD99396682B:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.000AD99396682B:0.RSSI_DEVICE = 216 [RE]
DPT {n} HmIP-RF.000AD99396682B:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.000AD99396682B:0.SABOTAGE = false [RE]
DPT {b} HmIP-RF.000AD99396682B:0.UNREACH = false [RE]
DPT {b} HmIP-RF.000AD99396682B:0.UPDATE_PENDING = false [RE]
CHN 000AD99396682B:3 HmIP-ASIR-B1 000AD99396682B:3
DPT {b} HmIP-RF.000AD99396682B:3.ACOUSTIC_ALARM_ACTIVE = false [RE]
DPT {i} HmIP-RF.000AD99396682B:3.ACOUSTIC_ALARM_SELECTION = [W]
DPT {i} HmIP-RF.000AD99396682B:3.DURATION_UNIT = [W]
DPT {i} HmIP-RF.000AD99396682B:3.DURATION_VALUE = [W]
DPT {b} HmIP-RF.000AD99396682B:3.OPTICAL_ALARM_ACTIVE = false [RE]
DPT {i} HmIP-RF.000AD99396682B:3.OPTICAL_ALARM_SELECTION = [W]
Der Versuch
get HmIP_ASIR datapoint 0.SABOTAGE
scheiterte mit
HMCCUCHN: HmIP_ASIR Execution of CCU script or command failed
Regelmößig kommt:Normal:
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR rssipeer: 0
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR rssidevice: -53
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR battery: ok
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR devstate: ok
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR activity: alive
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR hmstate: false
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR OPTICAL_ALARM_ACTIVE: false
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR false
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR ACOUSTIC_ALARM_ACTIVE: false
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR devstate: ok
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR activity: alive
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR rssipeer: 0
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR rssidevice: -53
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR battery: ok
2021-02-11 21:25:58 HMCCUCHN HmIP_ASIR hmstate: false
Sabotage true:
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR rssipeer: 0
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR battery: ok
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR rssidevice: -41
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR activity: alive
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR devstate: ok
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR hmstate: false
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR false
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR ACOUSTIC_ALARM_ACTIVE: false
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR OPTICAL_ALARM_ACTIVE: false
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR activity: alive
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR devstate: ok
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR battery: ok
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR rssidevice: -41
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR rssipeer: 0
2021-02-11 21:25:32 HMCCUCHN HmIP_ASIR hmstate: false
Sabotage false:
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR rssipeer: 0
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR battery: ok
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR rssidevice: -57
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR activity: alive
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR devstate: ok
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR hmstate: false
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR OPTICAL_ALARM_ACTIVE: false
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR false
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR ACOUSTIC_ALARM_ACTIVE: false
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR rssipeer: 0
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR battery: ok
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR rssidevice: -57
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR activity: alive
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR devstate: ok
2021-02-11 21:25:34 HMCCUCHN HmIP_ASIR hmstate: false
Und bei dem mir wichtigen Taster kommt nur:Taster:
2021-02-11 21:30:40 HMCCUCHN HmIP_ASIR activity: alive
2021-02-11 21:30:40 HMCCUCHN HmIP_ASIR devstate: ok
2021-02-11 21:30:40 HMCCUCHN HmIP_ASIR rssipeer: 0
2021-02-11 21:30:40 HMCCUCHN HmIP_ASIR battery: ok
2021-02-11 21:30:40 HMCCUCHN HmIP_ASIR rssidevice: -46
2021-02-11 21:30:40 HMCCUCHN HmIP_ASIR hmstate: false
Um alle Datenpunkte zu aktualisieren, machst Du einfach ein "get values"
Brauchst Du aber eigentlich nicht, da der RPC Server das für Dich übernimmt. Er aktualisiert die Datenpunkte automatisch, wenn er die Info von der cCU bekommt.
Das mit dem Taster verstehe ich nicht. Über welchen Datenpunkt soll der Alarmmelder einen Tastendruck signalisieren?
Der Wert für Sabotage wird schon automatisch berücksichtigt. Hmstate oder so müsste sich dann entsprechend anpassen.
Finde ich aber auch nicht ideal, auch weil z.B. HOMEMODE eine eigenes Reading dafür möchte.
Insofern kannst du folgendes setzen:
ccuflags showDeviceReadings
ccureadingformat datapointlc
und dann sollte Sabotage (mit ein paar anderen) als eigenes Reading da sein.
@zap: ich bin weiterhin dafür, dass Sabotage per default als eigenes Reading dabei ist ;-)
Zitat von: kjmEjfu am 12 Februar 2021, 08:05:21
@zap: ich bin weiterhin dafür, dass Sabotage per default als eigenes Reading dabei ist ;-)
Ich werde das wohlwollend prüfen ;)
Idee war halt, dass all diese Dinge (SABOTAGE, ERROR, usw) in hmstate landen. Hat aber den Nachteil, dass dort natürlich eine Priorisierung stattfindet. Wenn also ERROR und SABOTAGE gleichzeitig kommen, hat ERROR momentan Vorrang. Aber aus Sicherheitsaspekten ist SABOTAGE natürlich ziemlich wichtig. Also ja, es wird ein Reading geben.
OK, lass uns die Themen trennen
Thema: Taster
Zitat von: zap am 12 Februar 2021, 07:06:24
Das mit dem Taster verstehe ich nicht.
Über welchen Datenpunkt soll der Alarmmelder einen Tastendruck signalisieren?
Über keinen Datenpunkt, sondern über eine Logik.
Bei der 4.3xxx funktionierte das, bei der Beta 4.4 nun nicht mehr wegen veränderter Bedingungen.
Es soll mal so funktionieren:
- siehe
https://forum.fhem.de/index.php?topic=107077.msg1131677#msg1131677
Thema: Sabotage
Zitat von: zap am 12 Februar 2021, 07:06:24
Um alle Datenpunkte zu aktualisieren, machst Du einfach ein "get values"
Tat ich, Ergebnis
Device 000AD99396682B
Channel 0 [VALUES]
CONFIG_PENDING = false
DUTY_CYCLE = false
ERROR_CODE = 1
LOW_BAT = ok
OPERATING_VOLTAGE = 4.6
OPERATING_VOLTAGE_STATUS = NORMAL
RSSI_DEVICE = -37
SABOTAGE = true <---------- Kuckuck
UNREACH = alive
UPDATE_PENDING = false
Channel 3 [VALUES]
ACOUSTIC_ALARM_ACTIVE = false
OPTICAL_ALARM_ACTIVE = false
ZONE_1_ACTIVE = 0
ZONE_1_ALARM = 0
ZONE_2_ACTIVE = 0
ZONE_2_ALARM = 0
ZONE_3_ACTIVE = 0
ZONE_3_ALARM = 0
ZONE_4_ACTIVE = 0
ZONE_4_ALARM = 0
ZONE_5_ACTIVE = 0
ZONE_5_ALARM = 0
ZONE_6_ACTIVE = 0
ZONE_6_ALARM = 0
ZONE_7_ACTIVE = 0
ZONE_7_ALARM = 0
Er sieht es, das wäre mal richttig, jedoch findet sich das nicht so in den Readings, sondern
ACOUSTIC_ALARM_ACTIVE
OPTICAL_ALARM_ACTIVE
ZONE_1_ACTIVE
.... bis
ZONE_7_ALARM
Da fehlt was aus Channel 0
Zitat von: kjmEjfu am 12 Februar 2021, 08:05:21
@zap: ich bin weiterhin dafür, dass Sabotage per default als eigenes Reading dabei ist ;-)
Yep, ich auch !
- - - - - - - Ups, da war die zeit schneller, als ich schreiben konnte :-)
Channel 0 wird standardmäßig nicht auf Readings gemappt.
Wenn du die Werte trotzdem haben willst, musst du
ccuflags showDeviceReadings
setzen. Hast du das mal versucht?
Da die Readings dann aber mit dem Channel vorne weg und in Großbuchstaben kommen, und ich das nicht mag, habe ich bei mir noch gesetzt
ccureadingformat datapointlc
Dann kommen sie in Kleinbuchstaben und ohne Channel vorne.
Taster:
Welches Device nutzt du denn für den Tastendruck?
Aber vermutlich würde ich mir da grundsätzlich mit einem DOIF behelfen (s. https://fhem.de/commandref_DE.html#DOIF_waitsame)
Danke für den Zaunpfahl mit DOIF wait ....
Thema: Taster
ist gelöst - manchmal sieht man den wald vor lauter Bäumen nicht *grrr*
In der Sirene:
defmod HmIP_ASIR HMCCUCHN .....
attr HmIP_ASIR userReadings z1 {time_str2num(ReadingsTimestamp("HmIP_ASIR","activity",0))},z2 {time_str2num(ReadingsTimestamp("HmIP_ASIR","state",0))}
In der DOIF für den Taster:
define di_HmIP_ASIR_Taster DOIF ([HmIP_ASIR:"^activity:.*$"]) {if ((ReadingsVal("HmIP_ASIR","z1",0)) gt (ReadingsVal("HmIP_ASIR","z2",0)) ) {fhem "set Anzeige toggle";;}}
attr di_HmIP_ASIR_Taster do always
attr di_HmIP_ASIR_Taster wait 2
Thema: Sabotage
Zitat von: kjmEjfu am 12 Februar 2021, 12:45:59
Channel 0 wird standardmäßig nicht auf Readings gemappt.
Wenn du die Werte trotzdem haben willst, musst du
ccuflags showDeviceReadings
setzen. Hast du das mal versucht?
Da die Readings dann aber mit dem Channel vorne weg und in Großbuchstaben kommen, und ich das nicht mag, habe ich bei mir noch gesetzt
ccureadingformat datapointlc
Dann kommen sie in Kleinbuchstaben und ohne Channel vorne.
*schluchz* Das sagtest Du schon mal. Leider habe ich mal wieder keinen Schimmer von wie und wo ?
Zitat von: Ralph am 12 Februar 2021, 16:00:51
*schluchz* Das sagtest Du schon mal. Leider habe ich mal wieder keinen Schimmer von wie und wo ?
einfach als Attribut beim HmIP_ASIR festlegen.
Alternativ über die Commandline von FHEM:
attr HmIP_ASIR ccuflags showDeviceReadings
attr HmIP_ASIR ccureadingformat datapointlc
Zitat von: kjmEjfu am 12 Februar 2021, 16:18:21
einfach als Attribut beim HmIP_ASIR festlegen.
Sorry, auf "attr" bin ich nicht gekommen.
Danke. *wunderbar*
Welchen Sinn haben denn die "zone_?_...." ?
Hallo zap,
bei meinen Bewegungsmeldern habe ich das Reading PRESS_SHORT, was ja keinen Sinn ergibt. Hatte die Geräte schon komplett gelöscht und neu angelegt. Ohne Erfolg. Nutze die Version 4.4.060.
Hier das list:
Internals:
DEF 00091A498F0907:1
FUUID 60186f39-f33f-4885-fc1d-84249ba15fd8d3f1
IODev HMCCU3
NAME HmIP_SMI_00091A498F0907
NR 318
STATE noMotion
TYPE HMCCUCHN
ccuaddr 00091A498F0907:1
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-SMI 00091A498F0907:1
ccurolectrl MOTIONDETECTOR_TRANSCEIVER
ccurolestate MOTIONDETECTOR_TRANSCEIVER
ccusubtype SMI
ccutype HmIP-SMI
readonly no
READINGS:
2021-02-13 11:30:07 CURRENT_ILLUMINATION 32.1
2021-02-13 11:30:07 CURRENT_ILLUMINATION_STATUS NORMAL
2021-02-13 11:37:44 ILLUMINATION 30.7
2021-02-13 11:37:44 ILLUMINATION_STATUS NORMAL
2021-02-13 11:37:44 LastMove 12.02.2021 - 18:44:39
2021-02-13 11:37:44 MOTION noMotion
2021-02-13 11:37:44 MOTION_DETECTION_ACTIVE true
2021-02-13 10:51:26 PRESS_SHORT 1
2021-02-13 11:37:44 activity alive
2021-02-13 11:37:44 battery ok
2021-02-13 11:37:44 control true
2021-02-13 11:37:44 devstate ok
2021-02-13 11:37:44 hmstate noMotion
2021-02-13 11:37:44 rssidevice -66
2021-02-13 11:37:44 rssipeer -63
2021-02-13 11:37:44 state noMotion
hmccu:
channels 1
devspec 00091A498F0907:1
nodefaults 1
role 1:MOTIONDETECTOR_TRANSCEIVER
semDefaults 0
cmdlist:
get
set on:noArg off:noArg toggle:noArg
control:
chn 1
dpt MOTION_DETECTION_ACTIVE
dp:
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.LOW_BAT:
VALUES:
OSVAL ok
OVAL false
SVAL ok
VAL 0
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 2.9
OVAL 2.900000
SVAL 2.9
VAL 2.9
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -65
OVAL 191
SVAL -66
VAL -66
0.RSSI_PEER:
VALUES:
OSVAL -63
OVAL 193
SVAL -63
VAL 193
0.SABOTAGE:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL 0
0.UNREACH:
VALUES:
OSVAL alive
OVAL false
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
1.CURRENT_ILLUMINATION:
VALUES:
OSVAL 32.1
OVAL 32.100000
SVAL 32.1
VAL 32.100000
1.CURRENT_ILLUMINATION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.ILLUMINATION:
VALUES:
OSVAL 32.1
OVAL 32.100000
SVAL 30.7
VAL 30.7
1.ILLUMINATION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.MOTION:
VALUES:
OSVAL noMotion
OVAL false
SVAL noMotion
VAL 0
1.MOTION_DETECTION_ACTIVE:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL 1
roleCmds:
get:
set:
off:
channel 1
role MOTIONDETECTOR_TRANSCEIVER
subcount 1
syntax V:MOTION_DETECTION_ACTIVE:active=0
usage off
subcmd:
000:
args active=0
dpt MOTION_DETECTION_ACTIVE
fnc
max 1
min 0
parname MOTION_DETECTION_ACTIVE
partype 3
ps VALUES
unit
on:
channel 1
role MOTIONDETECTOR_TRANSCEIVER
subcount 1
syntax V:MOTION_DETECTION_ACTIVE:active=1
usage on
subcmd:
000:
args active=1
dpt MOTION_DETECTION_ACTIVE
fnc
max 1
min 0
parname MOTION_DETECTION_ACTIVE
partype 3
ps VALUES
unit
state:
chn 1
dpt MOTION
Attributes:
IODev HMCCU3
alias BMW Antje
room Homematic
userReadings LastMove:.*MOTION.* {ReadingsVal("HMCCU3","BWM_Antje","")}, \
LastActivity:activity.* {ReadingsTimestamp($name,"activity","") =~ /^(\d+)-(\d+)-(\d+)\s(\d+:\d+:\d+)$/;\
return "$3.$2.$1 - $4";}
Viele Grüße
Jürgen
Hallo Juergen,
wenn Du den define von DEF 00091A498F0907:1 auf DEF 00091A498F0907:3 änderst, stimmts.
Der Bewegungsmelder (motion) liegt auf channel 3, Press long/short auf 1 und 2
Das Problem ist aber dann, das Taster Press long short nicht sichtbar sind und man die Schalter nicht mehr benutzen kann. Siehe Antwort #331 in diesem Thread.
Hallo Jamo,
da meldet er aber (bei mir) keine Bewegung. Somit aktuell für mich unbrauchbar. Da habe ich lieber das Reading 8)
zap ist ja noch am korrigieren ;D
Viele Grüße
Jürgen
Zitat von: juemuc am 13 Februar 2021, 14:14:40
.... Da habe ich lieber das Reading
Probiere doch mal
https://forum.fhem.de/index.php?topic=107077.msg1131677#msg1131677
ab Thema: Sabotage
Mir hats geholfen.
Zitat von: Jamo am 13 Februar 2021, 12:50:58
Hallo Juergen,
wenn Du den define von DEF 00091A498F0907:1 auf DEF 00091A498F0907:3 änderst, stimmts.
Der Bewegungsmelder (motion) liegt auf channel 3, Press long/short auf 1 und 2
Das Problem ist aber dann, das Taster Press long short nicht sichtbar sind und man die Schalter nicht mehr benutzen kann. Siehe Antwort #331 in diesem Thread.
Bei solchen Geräten, die mehrere Kanäle haben, die man nutzen möchte, sollte man entweder HMCCUDEV verwenden oder für jeden benötigten Kanal ein HMCCUCHN anlegen. Die 2. Lösung ist einfacher zu handeln. Wenn man alles über HMCCUDeV macht, muss man sich für einen Masterkanal entscheiden, auf den dann die Attribute statedatapoint und comtroldatapoint zeigen.
Man kann ja die einzelnen HMCCUCHN Devices wieder per readinggrouo zusammenfassen, wenn man alles an einer Stelle haben möchte.
Hallo Jürgen,
Antwort #367
Zitatbei meinen Bewegungsmeldern habe ich das Reading PRESS_SHORT, was ja keinen Sinn ergibt.
falls Du dein Device als HMCCUDEV (anstatt HMCCUCHN) anlegen möchtest, hier der raw define, das alle 3 channel liefert, also motion, und auch für die beiden Schalter.
Man muss im Homematic WebUi aber eine Programm Verknüpfung machen, damit man die Press_long und Press_short sieht, ich denke das muss man aber immer machen also auch für das define mit HMCCUCHN, damit man die Schalter in FHEM sieht.
defmod MotionDetect1_Schlaf HMCCUDEV 0014D8A98A136B 1
attr MotionDetect1_Schlaf IODev HMCCU3
attr MotionDetect1_Schlaf alias Motion1 Schlaf
attr MotionDetect1_Schlaf ccureadingfilter (^MOTION|^ILLUMINATION|^LOW_BAT|^PRESS)
attr MotionDetect1_Schlaf ccureadingformat datapointlc
attr MotionDetect1_Schlaf ccureadingname 0.(LOWBAT|LOW_BAT):battery;;1.PRESS_LONG:long1;;1.PRESS_SHORT:short1;;2.PRESS_LONG:long2;;2.PRESS_SHORT:short2;;3.ILLUMINATION:brightness;;3.MOTION:motion
attr MotionDetect1_Schlaf event-on-change-reading battery,motion
attr MotionDetect1_Schlaf event-on-update-reading long1,short1,long2,short2
attr MotionDetect1_Schlaf eventMap /datapoint 3.MOTION_DETECTION_ACTIVE yes:control on/datapoint 3.MOTION_DETECTION_ACTIVE no:control off/datapoint 3.RESET_MOTION 1:reset/
attr MotionDetect1_Schlaf genericDeviceType OccupancySensor
attr MotionDetect1_Schlaf icon people_sensor
attr MotionDetect1_Schlaf room HomeMaticIP,Schalter,AllRooms->Schlafzimmer
attr MotionDetect1_Schlaf stateFormat motion, brightness Lx
attr MotionDetect1_Schlaf stripnumber ILLUMINATION!%.1f
attr MotionDetect1_Schlaf substitute 0.LOW_BAT!(0|false):ok,(1|true):low;;PRESS_LONG,PRESS_SHORT!(1|true):pressed,(0|false):released;;MOTION,MOTION_DETECTION_ACTIVE!(0|false):no,(1|true):yes;;ILLUMINATION_STATUS!0:normal,1:unknown,2:overflow
Alternativ hier die raw definition für HMCCUCHN, das bei mir nur motion liefert (channel 3)
define MotionDetect1_Schlaf HMCCUCHN 0014D8A98A136B:3
setuuid MotionDetect1_Schlaf 6026c587-f33f-97bf-ccff-2fd801452a08dc57
attr MotionDetect1_Schlaf IODev HMCCU3
attr MotionDetect1_Schlaf alias Motion1 Schlaf
attr MotionDetect1_Schlaf ccureadingfilter (^MOTION|^ILLUMINATION|^LOW_BAT|^PRESS)
attr MotionDetect1_Schlaf ccureadingformat datapoint
attr MotionDetect1_Schlaf ccureadingname 0.(LOWBAT|LOW_BAT):battery;;1.PRESS_LONG:long1;;1.PRESS_SHORT:short1;;2.PRESS_LONG:long2;;2.PRESS_SHORT:short2;;MOTION_DETECTION_ACTIVE:motion_detection_active;;ILLUMINATION_STATUS:brightness_status;;ILLUMINATION:brightness;;MOTION:motion
attr MotionDetect1_Schlaf event-on-change-reading battery,motion
attr MotionDetect1_Schlaf eventMap /datapoint 3.MOTION_DETECTION_ACTIVE yes:control on/datapoint 3.MOTION_DETECTION_ACTIVE no:control off/datapoint 3.RESET_MOTION 1:reset/
attr MotionDetect1_Schlaf genericDeviceType OccupancySensor
attr MotionDetect1_Schlaf icon people_sensor
attr MotionDetect1_Schlaf room HomeMaticIP,Schalter,AllRooms->Schlafzimmer
attr MotionDetect1_Schlaf stateFormat motion, brightness Lx
attr MotionDetect1_Schlaf stripnumber ILLUMINATION!%.1f
attr MotionDetect1_Schlaf substitute 0.LOW_BAT!(0|false):ok,(1|true):low;;PRESS_LONG,PRESS_SHORT!(1|true):pressed,(0|false):released;;MOTION,MOTION_DETECTION_ACTIVE!(0|false):no,(1|true):yes;;ILLUMINATION_STATUS!0:normal,1:unknown,2:overflow
Hallo zusammen,
ich bin in Sachen Homematic IP und HMCCU Neuling - habe vorher MAX-Komponenten eingesetzt.
Nutze momentan die HMCCU 4.4 Beta und bin bis jetzt auch soweit klar gekommen. Was ich aber nicht herausfinden konnte, ist wie das Umschalten zwischen Profilen auf meinen HMIP-eTRV2 Heizungsthermostaten funktionieren soll.
Hat jemand einen Tip für mich, welchen Befehl ich dafür nutzen muss? Gibt es das vielleicht auch in den Dropdowns und ich habs übersehen?
Und noch eine andere Sache: Ich fände ein Reading 'mode' (mit den Werten 'auto', 'boost', 'manu') ganz praktisch - gab es früher bei MAX. Momentan sehe ich eine Unterscheidung nur im Reading SET_POINT_MODE, zumindest zwischen auto und manuell. Könnte sowas ergänzt werden?
Vielen Dank schon mal.
Zitat von: dennisk am 16 Februar 2021, 08:03:01
Und noch eine andere Sache: Ich fände ein Reading 'mode' (mit den Werten 'auto', 'boost', 'manu') ganz praktisch - gab es früher bei MAX. Momentan sehe ich eine Unterscheidung nur im Reading SET_POINT_MODE, zumindest zwischen auto und manuell. Könnte sowas ergänzt werden?
Das Reading existiert schon, soll aber einfach nur anders heißen?
Dann schau mal in der CommandRef für HMCCUCHN, da wird das Attribut ccudef-readingname ganz gut erklärt.
Zitat von: kjmEjfu am 16 Februar 2021, 08:52:38
Das Reading existiert schon, soll aber einfach nur anders heißen?
Dann schau mal in der CommandRef für HMCCUCHN, da wird das Attribut ccudef-readingname ganz gut erklärt.
Danke erstmal für Deine Antwort. Im Endeffekt ist es so, dass die verschiedenen Modi (auto, manuell, boost) auf zwei Readings verteilt sind, die ersten beiden sind über SET_POINT_MODE (0 für auto, 1 für manuell) abgebildet, für boost gibt es das Reading BOOST_MODE (boolean). Um also dann ein Reading mode zu realisieren, welches alle drei Zustände abbildet, müsste ich das dann quasi selber bauen. Hattest Du einen Tip für mich, wo ich da ansetzen kann? Müsste ich das mit Notify machen, oder gäbe es da bessere Möglichkeiten?
https://wiki.fhem.de/wiki/UserReadings :-)
Hallo!
Habe ich das richtig verstanden?
Wenn ich nun eine Fhem Update durchführe ich meine HMCCU 4.4 wech und es ist eine alte drauf? Falls ja, funktioniert denn noch alles oder muss ich alles neu einrichten?
Vielen Dank!
Ja, Du kannst aber "attr global exclude_from_update 88_HMCCURPCPROC.pm 88_HMCCUCHN.pm 88_HMCCUDEV.pm 88_HMCCU.pm 88_HMCCURPC.pm HMCCUConf.pm " setzen, damit verhinderst Du das Du wieder auf die alte 4.3 version wechselst. Damit sind die module vom update ausgenommen.
Sobald zap ein update von 4.4 macht, musst Du das attribut dann aber wieder loeschen, damit Du die neueren Dateien lädts.
okay! vielen Dank! Hab es dann mal hinzugefügt.
Gibt es denn schon eine Vermutung wann das Modul fertig ist?🙈
Das weiss nur der Meister selber :-)
ZitatUnd noch eine andere Sache: Ich fände ein Reading 'mode' (mit den Werten 'auto', 'boost', 'manu') ganz praktisch - gab es früher bei MAX. Momentan sehe ich eine Unterscheidung nur im Reading SET_POINT_MODE, zumindest zwischen auto und manuell. Könnte sowas ergänzt werden?
Ich habe für meine HM-IP-Geräte jeweils ein userReadings erstellt:
controlMode {if(ReadingsVal($name,"BOOST_MODE","") eq "true") {return "boost"}
elsif
(ReadingsVal($name,"SET_POINT_MODE","") eq "0") {return "auto"}
elsif
(ReadingsVal($name,"SET_POINT_MODE","") eq "1") {return "manual"} else {return "error"}}Gruß
eurofinder
Zitat von: eurofinder am 13 März 2021, 09:06:02
Ich habe für meine HM-IP-Geräte jeweils ein userReadings erstellt:
controlMode {if(ReadingsVal($name,"BOOST_MODE","") eq "true") {return "boost"}
elsif
(ReadingsVal($name,"SET_POINT_MODE","") eq "0") {return "auto"}
elsif
(ReadingsVal($name,"SET_POINT_MODE","") eq "1") {return "manual"} else {return "error"}}
Gruß
eurofinder
Super, genau, was ich gesucht habe! Vielen Dank!
Bleibt noch mein anderes Problem mit der Profilumschaltung:
Zitat von: dennisk am 16 Februar 2021, 08:03:01
...Was ich aber nicht herausfinden konnte, ist wie das Umschalten zwischen Profilen auf meinen HMIP-eTRV2 Heizungsthermostaten funktionieren soll.
Hat jemand einen Tip für mich, welchen Befehl ich dafür nutzen muss? Gibt es das vielleicht auch in den Dropdowns und ich habs übersehen?
Ich hab einfach keine Idee, wie das funktionieren soll!? Jemand eine Idee?
Die haben doch auch das "ACTIVE_PROFILE" -Reading, oder?
Einfach überschreiben....denke ich.
Mit der Beta 4.4. und HMIP-eTRV2:
set HMIP-eTRV2-Name ACTIVE_PROFILE Profilnummer
Gruß
eurofinder
Zitat von: eurofinder am 13 März 2021, 09:06:02
Ich habe für meine HM-IP-Geräte jeweils ein userReadings erstellt:
controlMode {if(ReadingsVal($name,"BOOST_MODE","") eq "true") {return "boost"}
elsif
(ReadingsVal($name,"SET_POINT_MODE","") eq "0") {return "auto"}
elsif
(ReadingsVal($name,"SET_POINT_MODE","") eq "1") {return "manual"} else {return "error"}}
Gruß
eurofinder
Versuch mal das:
attr ccureadingname ^(BOOST_MODE|SET_POINT_MODE):+controlMode
Zitat von: Chris8888 am 13 März 2021, 21:55:59
Die haben doch auch das "ACTIVE_PROFILE" -Reading, oder?
Einfach überschreiben....denke ich.
Zitat von: eurofinder am 14 März 2021, 08:28:58
Mit der Beta 4.4. und HMIP-eTRV2:
set HMIP-eTRV2-Name ACTIVE_PROFILE Profilnummer
Gruß
eurofinder
Vielen Dank euch beiden. Damit hat es aber leider nicht funktioniert. Das Reading wird zwar neu gesetzt, die Änderung kommt aber in der RaspberryMatic nicht an und folglich ändert sich auch am Thermostat nichts.
Eure Antwort hat mich aber nochmal zur erneuten Recherche motiviert und ich hab dann folgenden Weg gefunden:
set datapoint ACTIVE_PROFILE <Nr des Wochenprofils>Damit klappt es und die Änderung kommt auch bis zum Thermostaten.
Zitat von: zap am 14 März 2021, 10:27:58
Versuch mal das:
attr ccureadingname ^(BOOST_MODE|SET_POINT_MODE):+controlMode
Vielen Dank auch für die alternative Lösung. Ich finde den Vorschlag von eurofinder "schöner", da dann 0 und 1 durch manual und auto repräsentiert werden. Aber in jedem Fall hab ich mich so mal mit ccureadingname beschäftigt! Danke!
Eventuell kannst Du ja mal drüber nachdenken, die Lösung von eurofinder in die defaults für die Thermostate zu übernehmen?
Beim weiteren Rumspielen stellt sich mir nun die Frage, wie ich die Umstellung des Wochenprofils in das DeviceOverview eines Thermostaten integrieren könnte.
Bis jetzt kam ich auf webCmd und widgetOverride, bin dsnn aber darüber gestolpert, dass beim Thermostaten das Attribut setList gar nicht existiert.
Hat jemand eine Idee, wie ich folgendes realisieren könnte: Auswahl des Wochenprofils über ein Widget (Wunsch: uzsuSelectRadio), am besten im DeviceOverview des Thermostaten. Schön wäre auch noch, wenn man die dann angezeigten Wochenprofilnummern durch etwas Sprechenderes ersetzen könnte, also z.B. 1=HomeOffice, 2=Büro und 3=Frei.
Zitat von: dennisk am 20 Februar 2021, 17:32:52
Danke erstmal für Deine Antwort. Im Endeffekt ist es so, dass die verschiedenen Modi (auto, manuell, boost) auf zwei Readings verteilt sind, die ersten beiden sind über SET_POINT_MODE (0 für auto, 1 für manuell) abgebildet, für boost gibt es das Reading BOOST_MODE (boolean). Um also dann ein Reading mode zu realisieren, welches alle drei Zustände abbildet, müsste ich das dann quasi selber bauen. Hattest Du einen Tip für mich, wo ich da ansetzen kann? Müsste ich das mit Notify machen, oder gäbe es da bessere Möglichkeiten?
Kannst Du für dieses Device bitte mal die Befehle
get deviceInfo
get paramDesc
ausführen?
Die Ausgabe posten oder - falls zu lang - als Attachment anhängen.
@dennisk:
Stimmt, hatte das datapoint vergessen bei
Zitatset datapoint ACTIVE_PROFILE <Nr des Wochenprofils>
Gruß
eurofinder
Zitat von: zap am 15 März 2021, 10:03:08
Kannst Du für dieses Device bitte mal die Befehle
get deviceInfo
get paramDesc
ausführen?
Die Ausgabe posten oder - falls zu lang - als Attachment anhängen.
Gerne:
https://pastebin.com/QUBjKgfN
https://pastebin.com/TmPXRZf9
Also eigentlich müssten boost auch über SET_POINT_MODE signalisiert werden:
0 = Auto
1 = Manual
2 = Boost
3 = Off
@zap:
ZitatAlso eigentlich müssten boost auch über SET_POINT_MODE signalisiert werden:
0 = Auto
1 = Manual
2 = Boost
3 = Off
Bei mir werden nur
0 = Auto
1 = Manual
in SET_POINT_MODE gesetzt. Wenn ich Boost oder OFF auswähle, ändert sich nichts in SET_POINT_MODE.
Daher hatte ich ja ein eigenständiges reading erstellt. Wenn du das natürlich anpassen könntest, dann wäre das nicht mehr nötig:-)
Sofern du irgendwelche LIST benötigst melde dich einfach.
Gruß
eurofinder
Ich habe jetzt begonnen, meine CCU3 mit HMCCU 4.4 einzubinden. Meine HMIP-BROLL konnten via get <ccudev> create <devname> nicht korrekt angelegt werden. Sie wurden mit dem Modul HMCCUDEV als Taster angelegt. Ich habe sie danach manuell als HMCCUCHN angelegt, das klappt, aber die defaults werden nicht wie in der CONF für HMIP-BROLL berücksichtigt angelegt:
"HmIP-BROLL|HmIP-FROLL" => {
_description => "Rollladenaktor",
_channels => "4",
ccureadingfilter => "(ERROR_CODE|ERROR_OVERHEAT|ACTUAL_TEMPERATURE|LEVEL|ACTIVITY_STATE)",
ccureadingname => "LEVEL:+pct",
ccuscaleval => "LEVEL:0:1:0:100",
cmdIcon => "up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down",
controldatapoint => "LEVEL",
hmstatevals => "ACTUAL_TEMPERATURE_STATUS!2:tempOverflow,3:tempUnderflow;ERROR_OVERHEAT!(1|true):overheat",
eventMap => "/datapoint STOP true:stop/datapoint LEVEL 0:down/datapoint LEVEL 100:up/",
statedatapoint => "LEVEL",
stripnumber => 1,
substexcl => "control|pct",
substitute => "LEVEL!#0-0:closed,#100-100:open;ACTIVITY_STATE!0:unknown,1:up,2:down,3:stop;ERROR_OVERHEAT!(0|false):no,(1|true):yes;ACTUAL_TEMPERATURE_STATUS!0:normal,1:unknown,2:overflow,3:underflow",
webCmd => "control:up:stop:down",
widgetOverride => "control:slider,0,10,100"
Nach einem reset der defaults sieht das Gerät wie folgt aus:
Internals:
CFGFN
DEF 00111BE98F9989:4
FUUID 60584d7e-f33f-73b5-2f6c-aa7ee888851a979a
IODev CCU3
NAME HmIP_BROLL_Tims_Buero
NR 694
STATE open
TYPE HMCCUCHN
ccuaddr 00111BE98F9989:4
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-BROLL 00111BE98F9989:4
ccusubtype BROLL
ccutype HmIP-BROLL
readonly no
OLDREADINGS:
READINGS:
2021-03-22 09:01:32 ACTIVITY_STATE STABLE
2021-03-22 09:01:32 LEVEL open
2021-03-22 09:01:32 LEVEL_STATUS NORMAL
2021-03-22 09:01:32 PROCESS STABLE
2021-03-22 09:01:32 SECTION 4
2021-03-22 09:01:32 SECTION_STATUS NORMAL
2021-03-22 09:01:32 activity alive
2021-03-22 09:01:08 control open
2021-03-22 09:01:32 devstate ok
2021-03-22 09:01:32 hmstate open
2021-03-22 09:01:32 rssidevice -66
2021-03-22 09:01:32 rssipeer -72
2021-03-22 09:01:08 state open
hmccu:
channels 1
devspec 00111BE98F9989:4
nodefaults 0
role 4:SHUTTER_VIRTUAL_RECEIVER
semDefaults 0
cmdlist:
get
set stop:noArg open:noArg down close:noArg up pct
control:
chn 4
dpt
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
OSVAL 25.0
OVAL 25.0
SVAL 25.0
VAL 25.0
0.ACTUAL_TEMPERATURE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -66
OVAL -66
SVAL -66
VAL -66
0.RSSI_PEER:
VALUES:
OSVAL -72
OVAL -72
SVAL -72
VAL -72
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
4.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
4.LEVEL:
VALUES:
OSVAL open
OVAL 1.0
SVAL open
VAL 1.0
4.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
4.SECTION:
VALUES:
OSVAL 4
OVAL 4
SVAL 4
VAL 4
4.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
roleCmds:
get:
set:
close:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:0
usage close
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
unit 100%
down:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=-20
usage down [delta]
subcmd:
000:
args -20
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
unit 100%
open:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:100
usage open
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
unit 100%
pct:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?level
usage pct level
subcmd:
000:
args
dpt LEVEL
fnc
max 1.01
min 0.0
parname level
partype 2
ps VALUES
unit 100%
stop:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:STOP:1
usage stop
subcmd:
000:
args 1
dpt STOP
fnc
max 1
min 0
parname STOP
partype 3
ps VALUES
unit
up:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=+20
usage up [delta]
subcmd:
000:
args +20
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
unit 100%
state:
chn 4
dpt
Attributes:
IODev CCU3
cmdIcon open:fts_shutter_up stop:fts_shutter_manual close:fts_shutter_down
substexcl pct
webCmd pct:open:close:stop
widgetOverride pct:slider,0,10,100
Attribute sind nur wenige:
IODev CCU3
cmdIcon open:fts_shutter_up stop:fts_shutter_manual close:fts_shutter_down
substexcl pct
webCmd pct:open:close:stop
widgetOverride pct:slider,0,10,100
Mache ich etwas falsch oder übersehe ich etwas?
Danke,
Tim
Ich habe gerade ein Update auf Github eingecheckt (erst mal nur auf Github). Das würde ich nun mal als ersten Release Candidate bezeichnen.
Die wichtigsten Änderungen:
- Die automatische Geräteerkennung wurde noch einmal deutlich verbessert. Wenn man für die Definition eines Device HMCCUDEV verwendet, obwohl HMCCUCHN besser wäre, weist HMCCU darauf hin. Man muss dann die Option "forceDev" angeben, damit HMCCUDEV verwendet werden kann.
- Im I/O Device gibt es nun neben "get create" den Befehl "get createdev". Dieser Befehl ist eine vereinfachte Variante von "get create".
- Wenn "get create" oder "get createdev" für ein Gerät mit mehreren identischen Kanälen benutzt wird, legt HMCCU nun für jeden Kanal ein HMCCUCHN Device an. Die Kanalnummer wird an den Gerätenamen angehängt. Beispiel: Eine Fernbedienung mit 4 Knöpfen wird nun in 4 HMCCUCHN Devices abgebildet. Falls man trotzdem ein HMCCUDEV haben möchte, muss man das Device manuell definieren.
- Die Attribute "statedatapoint" und "controldatapoint" werden nun mit sinnvollen Datenpunkten vorbelegt. In der FHEM Kommandozeile kann weiterhin jeder Datenpunkt angegeben werden
Hallo zap,
Ich bin über das update wieder irgendwie auf die version 4.3 gerutscht, vergiss was ich geschrieben habe. Sorry!
da geht aber jetzt irgendwas durcheinander:
1) HMIP-PSM als auch HMIP_ASIR zeigen jetzt true/false anstatt on/off (list unten)
die HMIP-PSM lassen sich nicht mehr schalten (Unknown argument true, choose one of clear config defaults:noArg control datapoint rpcparameter devstate:on,off on:noArg off:noArg t...)
2) HMIP-SWDO also auch HmIP-SCI zeigen jetzt 0/1 anstatt open/closed (list unten)
Das lässt sich aber über eventMap korrigieren . . .
Hallo zap.
nach dem update erhalte ich nun permanent diese Meldungen:
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Fenster#Wohnzimmer#zu incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Fenster#Buero#auf incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Fenster#Buero#zu incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Balkontuer#zu incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Fenster#Kueche#auf incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Fenster#Schlafzimmer#zu incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program BWM#Antje incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Balkontuer#auf incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program BWM#J�rgen incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Flurtuer#auf incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Fenster#Kueche#zu incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Flurtuer#zu incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Fenster#Schlafzimmer#auf incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Fenster#Wohnzimmer#auf incomplete
2021.03.23 20:37:15 2: HMCCU [HMCCU3] Information for CCU program Fenster#Wohnzimmer#zu incomplete
2021.03.23 20:37:15 2: HMCCU [HMCCU3] Information for CCU program Fenster#Buero#auf incomplete
2021.03.23 20:37:15 2: HMCCU [HMCCU3] Information for CCU program Fenster#Buero#zu incomplete
2021.03.23 20:37:15 2: HMCCU [HMCCU3] Information for CCU program Balkontuer#zu incomplete
2021.03.23 20:37:15 2: HMCCU [HMCCU3] Information for CCU program Fenster#Kueche#auf incomplete
2021.03.23 20:37:15 2: HMCCU [HMCCU3] Information for CCU program Fenster#Schlafzimmer#zu incomplete
2021.03.23 20:37:15 2: HMCCU [HMCCU3] Information for CCU program BWM#Antje incomplete
2021.03.23 20:37:15 2: HMCCU [HMCCU3] Information for CCU program Balkontuer#auf incomplete
2021.03.23 20:37:15 2: HMCCU [HMCCU3] Information for CCU program BWM#J�rgen incomplete
2021.03.23 20:37:15 2: HMCCU [HMCCU3] Information for CCU program Flurtuer#auf incomplete
2021.03.23 20:37:15 2: HMCCU [HMCCU3] Information for CCU program Fenster#Kueche#zu incomplete
2021.03.23 20:37:15 2: HMCCU [HMCCU3] Information for CCU program Flurtuer#zu incomplete
2021.03.23 20:37:15 2: HMCCU [HMCCU3] Information for CCU program Fenster#Schlafzimmer#auf incomplete
2021.03.23 20:37:15 2: HMCCU [HMCCU3] Information for CCU program Fenster#Wohnzimmer#auf incomplete
Was läuft hier falsch?
Viele Grüße
Jürgen
In welchem Kontext kommt die Meldung: beim Start? Oder wenn Du einen bestimmten Befehl ausführst?
Hallo zap,
immer bei
get CCU3 VARS xyz
Viele Grüße
Jürgen
Heißen die Variablen tatsächlich so (mit # im Namen) ?
Hallo zap,
die Namen lauten:
BWM_Antje
BWM_Juergen
Balkontuer_auf
Balkontuer_zu
Fenster_Buero_auf
Fenster_Buero_zu
Fenster_Kueche_auf
Fenster_Kueche_zu
Fenster_Schlafzimmer_auf
Fenster_Schlafzimmer_zu
Fenster_Wohnzimmer_auf
Fenster_Wohnzimmer_zu
Flurtuer_auf
Flurtuer_zu
Klingeln
Rollo_Buero
Rollos_Ost
Rollos_West
Status_Balkontuer
Status_Buerofenster
Status_Flurtuer
Status_Kuechenfenster
Status_Schlafzimmerfenster
Status_Wohnzimmerfenster
Viele Grüße
Jürgen
Kannst Du bitte die Versionsangaben prüfen (Internals im I/O Device):
version = 4.4.064
config = 4.8.022
Hallo ZAP,
gibt es schon einen Termin wann das Modul das offizielle Modul wird?
@zap:
Ist das jetzt berücksichtigt durch die neuste Aktualisierung?
https://forum.fhem.de/index.php/topic,107077.msg1141932.html#msg1141932 (https://forum.fhem.de/index.php/topic,107077.msg1141932.html#msg1141932)
Gruß
eurofinder
Zitat von: eurofinder am 25 März 2021, 13:14:52
@zap:
Ist das jetzt berücksichtigt durch die neuste Aktualisierung?
https://forum.fhem.de/index.php/topic,107077.msg1141932.html#msg1141932 (https://forum.fhem.de/index.php/topic,107077.msg1141932.html#msg1141932)
Gruß
eurofinder
Nein, noch nicht.
Schwer umzusetzen, da ich kein solches Gerät habe. Blindflug ist schwierig ....
Zitat von: teufelchen am 25 März 2021, 12:08:05
Hallo ZAP,
gibt es schon einen Termin wann das Modul das offizielle Modul wird?
Hängt davon ab, wie viele Fehler mit dem aktuellen Update noch auftauchen. An Ostern habe ich etwas mehr Zeit. Vielleicht direkt nach Ostern.
Hallo Zap,
ZitatHängt davon ab, wie viele Fehler mit dem aktuellen Update noch auftauchen. An Ostern habe ich etwas mehr Zeit. Vielleicht direkt nach Ostern.
Antwort #331:
2) HMIP-PSM01 HMIP-PSM HmIP-RF 01234567890123 event-on-change-readings funktioniert nicht.
Wenn ich "event-on-change-reading power,state" setzte, kommt das state event immer 2 mal.
Wenn ich "event-on-change-reading power" setzte, kommt das state event trotzdem durch, aber nur einmal.
@zap:
ZitatNein, noch nicht.
Schwer umzusetzen, da ich kein solches Gerät habe. Blindflug ist schwierig ....
Und das hilft noch nicht weiter: https://forum.fhem.de/index.php/topic,107077.msg1139248.html#msg1139248 (https://forum.fhem.de/index.php/topic,107077.msg1139248.html#msg1139248)
Ich fasse doch eigentlich nur BOOST_MODE (true oder false) bzw. SET_POINT_MODE (0 oder 1) zusammen. Die Readings werden ja bereits automatisch generiert.
Gruß
eurofinder
andere Frage: Wenn Du den BOOST_MODE einschaltest, ändert sich dann SET_POINT_MODE oder bleibt das z.B. auf AUTO stehen?
Ausgangsbasis:
BOOST_MODE = false
SET_POINT_MODE = 0
Wenn ich Boost aktiviere wird zwar BOOST_MODE = true gesetzt, aber SET_POINT_MODE ändert sich nicht.
Gruß
eurofinder
Zitat von: zap am 25 März 2021, 11:42:18
Kannst Du bitte die Versionsangaben prüfen (Internals im I/O Device):
version = 4.4.064
config = 4.8.022
Hallo zap,
ja diese Versionen habe ich :-)
Viele Grüße
Jürgen
Zitat von: Jamo am 25 März 2021, 15:05:07
Hallo Zap,Antwort #331:
2) HMIP-PSM01 HMIP-PSM HmIP-RF 01234567890123 event-on-change-readings funktioniert nicht.
Wenn ich "event-on-change-reading power,state" setzte, kommt das state event immer 2 mal.
Wenn ich "event-on-change-reading power" setzte, kommt das state event trotzdem durch, aber nur einmal.
Die Readings (und zwar alle) werden doppelt aktualisiert. Ist noch ein Bug.
Zitat von: zap am 25 März 2021, 14:51:30
Hängt davon ab, wie viele Fehler mit dem aktuellen Update noch auftauchen. An Ostern habe ich etwas mehr Zeit. Vielleicht direkt nach Ostern.
Vielen Dank für die Zeit die Du da reinsteckst und Respekt gegenüber den Wissen was dafür nötig ist.
ZitatVielen Dank für die Zeit die Du da reinsteckst und Respekt gegenüber den Wissen was dafür nötig ist.
Ja, auch wenn es nicht rüberkommt: Auch von mir vielen Dank, das kann man gar nicht hoch genug bewerten was hier von vielen Einzelnen an Zeit, Ideen und Energie reingesteckt wird.
Also Hut ab und meinen Dank an zap!
Zitat von: Jamo am 25 März 2021, 15:05:07
Hallo Zap,Antwort #331:
2) HMIP-PSM01 HMIP-PSM HmIP-RF 01234567890123 event-on-change-readings funktioniert nicht.
Wenn ich "event-on-change-reading power,state" setzte, kommt das state event immer 2 mal.
Wenn ich "event-on-change-reading power" setzte, kommt das state event trotzdem durch, aber nur einmal.
Machst Du mal bitte ein list von dem Device? Die CCU schickt zwar STATE 2x, allerdings filtert event-on-change-reading das 2. Event zuverlässig bei mir. Könnte an Deinen Device-Einstellungen liegen.
Hallo zap,
ZitatMachst Du mal bitte ein list von dem Device? Die CCU schickt zwar STATE 2x, allerdings filtert event-on-change-reading das 2. Event zuverlässig bei mir. Könnte an Deinen Device-Einstellungen liegen.
Hier die HMCCU version, das list, und unten noch der eventmonitor mit den events, die nur einmal kommen (wenn event-on-change-reading state nicht gesetzt ist), und den doppelten events nachdem ich das event-on-change-reading state gesetzt habe:
Danke schonmal und Grüsse!
HMCCU:
config 4.8.022
host 127.0.0.1
prot http
version 4.4.064List:
Internals:
DEF 0001D709903D2D
FUUID 5cdadadadadadd
IODev HMCCU3
NAME HMIP_PSM2
NR 2787
STATE off
TYPE HMCCUDEV
ccuaddr 0001ABCDEFD
ccudevstate active
ccuif HmIP-RF
ccuname HMIP-PSM 0001ABCDEFD AirCon
ccusubtype PSM
ccutype HMIP-PSM
readonly no
Helper:
DBLOG:
power:
myDbLog:
TIME 1616799607.00706
VALUE 0.0
READINGS:
2021-03-27 20:48:58 2.STATE off
2021-03-27 20:48:57 3.STATE off
2021-03-27 20:48:58 4.STATE off
2021-03-27 20:48:57 5.STATE off
2021-03-27 20:33:48 6.CURRENT 0.0
2021-03-27 20:33:48 6.CURRENT_STATUS NORMAL
2021-03-27 20:48:58 activity alive
2021-03-27 20:48:57 control off
2021-03-27 20:48:58 devstate ok
2021-03-27 20:33:48 energy 0.2
2021-03-27 20:33:48 energy_OVERFLOW false
2021-03-27 20:48:58 hmstate off
2021-03-27 20:33:48 power 0.0
2021-03-27 20:33:48 power_STATUS NORMAL
2021-03-27 20:48:58 rssidevice -57
2021-03-27 20:48:58 rssipeer -57
2021-03-27 20:48:57 state off
hmccu:
channels 9
devspec 0001D709903D2D
forcedev 0
nodefaults 1
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:SWITCH_TRANSMITTER,3:SWITCH_VIRTUAL_RECEIVER,4:SWITCH_VIRTUAL_RECEIVER,5:SWITCH_VIRTUAL_RECEIVER,6:ENERGIE_METER_TRANSMITTER,7:COND_SWITCH_TRANSMITTER,8:SWITCH_WEEK_PROFILE
semDefaults 0
cmdlist:
get
set on-for-timer on:noArg on-till off:noArg toggle:noArg
control:
chn 3
dpt STATE
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
OSVAL 22.0
OVAL 22.0
SVAL 22.0
VAL 22.0
0.ACTUAL_TEMPERATURE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -57
OVAL -57
SVAL -57
VAL -57
0.RSSI_PEER:
VALUES:
OSVAL -57
OVAL -57
SVAL -57
VAL -57
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
2.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
2.SECTION:
VALUES:
OSVAL 2
OVAL 2
SVAL 0
VAL 0
2.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
2.STATE:
VALUES:
OSVAL on
OVAL 1
SVAL off
VAL 0
3.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
3.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
3.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
4.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
4.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
5.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
5.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
5.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.STATE:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
6.CURRENT:
VALUES:
OSVAL 0.0
OVAL 0.0
SVAL 0.0
VAL 0.0
6.CURRENT_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.ENERGY_COUNTER:
VALUES:
OSVAL 0.2
OVAL 0.2
SVAL 0.2
VAL 0.2
6.ENERGY_COUNTER_OVERFLOW:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
6.FREQUENCY:
VALUES:
OSVAL 50.0
OVAL 49.96
SVAL 50.0
VAL 50.02
6.FREQUENCY_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.POWER:
VALUES:
OSVAL 0.0
OVAL 0.0
SVAL 0.0
VAL 0.0
6.POWER_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.VOLTAGE:
VALUES:
OSVAL 231.2
OVAL 231.2
SVAL 229.5
VAL 229.5
6.VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
8.WEEK_PROGRAM_CHANNEL_LOCKS:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
roleCmds:
get:
set:
off:
channel 3
role SWITCH_VIRTUAL_RECEIVER
subcount 1
syntax V:STATE:0
usage off
subcmd:
000:
args 0
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on:
channel 3
role SWITCH_VIRTUAL_RECEIVER
subcount 1
syntax V:STATE:1
usage on
subcmd:
000:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on-for-timer:
channel 3
role SWITCH_VIRTUAL_RECEIVER
subcount 2
syntax V:ON_TIME:?duration V:STATE:1
usage on-for-timer duration
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname duration
partype 2
ps VALUES
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on-till:
channel 3
role SWITCH_VIRTUAL_RECEIVER
subcount 2
syntax V:ON_TIME:?time V:STATE:1
usage on-till time
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname time
partype 2
ps VALUES
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
state:
chn 3
dpt STATE
Attributes:
IODev HMCCU3
alias KlimaPower
ccureadingfilter (STATE|CURRENT|POWER|^ENERGY_COUNTER)
ccureadingname 6.POWER:power;6.ENERGY_COUNTER:energy
controlchannel 3
controldatapoint 3.STATE
devStateIcon off:ios-off on:ios-on-green .*:noIcon
event-on-change-reading power,state
group SCHALTER
room Energy,HomeMaticIP,Schalter
sortby 221
stateFormat {my $state = ReadingsVal($name,'state','nA');
my $power = ReadingsNum($name,'power',-1);
my $string = $state . ' ' . $power . ' W';
if ($state eq 'on') {return '<font color="darkorange"><b>' . $string . '</b></font>';}
else {return $state }}
statechannel 3
statedatapoint 3.STATE
statevals on:1,off:0
stripnumber 1
webCmd on:offEventmonitor:
2021-03-27 20:47:27 HMCCUDEV HMIP_PSM2 on
2021-03-27 20:47:52 HMCCUDEV HMIP_PSM2 off
2021-03-27 20:47:57 FRITZBOX FritzBox box_dect: on
2021-03-27 20:48:10 FBDECT Schalter_iNUC power: 12.30 W
2021-03-27 20:48:14 Global global ATTR HMIP_PSM2 event-on-change-reading power,state
2021-03-27 20:48:27 HMCCUDEV HMIP_PSM2 on
2021-03-27 20:48:28 HMCCUDEV HMIP_PSM2 on
2021-03-27 20:48:54 HMCCUDEV HMIP_PSM2 off
2021-03-27 20:48:54 HMCCUDEV HMIP_PSM2 off
2021-03-27 20:48:55 HMCCUDEV HMIP_PSM2 off
2021-03-27 20:48:57 FRITZBOX FritzBox box_dect: on
Hallo zap,
mir ist ein kleiner Bug (zumindest nach meinem Verständnis) aufgefallen:
Ich habe heute mal alle meine Taster (HMIP-WRC2) neu angelegt. Dabei wurden diese nun nicht mehr als HMCCUDEV sondern HMCCUCHN angelegt. Soweit so gut, FHEM notifies entsprechend angepasst - ob ich oben oder gedrückt habe, wird nun ja in zwei HMCCUCHN-Devices unterschieden. Allerdings kamen einfach gar keine Events mehr an,laut Event Monitor. Mir ist dann aufgefallen, dass per Default das Attribut auf event-on-update-reading auf PRESS gesetzt war, die Events heißen aber PRESS_SHORT oder PRESS_LONG. Nachdem ich dann event-on-update-reading PRESS.* gesetzt habe, werden auch wieder Events erzeugt und meine notifies funktionieren wieder. Kannst Du das ggf. übernehmen, wenn da nichts gegen spricht?
Und dann habe ich noch eine Frage: Besteht die Möglichkeit, die Firmware eines Gerätes als Reading zu bekommen? Ich weiß, dass ich die Info mittels get deviceinfo bekommen kann, ich würde diese aber gerne in FHEM weiterverarbeiten (FirmwareCheck). Meine Recherche, wie ich ggf. den Output aus get deviceinfo weiterverarbeiten könnte, war bisher erfolglos. Danke schon mal.
@Jamo: Bitte lösche mal testweise das stateFormat Attribut und prüfe, wie es sich dann verhält.
Zitat von: dennisk am 28 März 2021, 14:21:29
Hallo zap,
mir ist ein kleiner Bug (zumindest nach meinem Verständnis) aufgefallen:
Ich habe heute mal alle meine Taster (HMIP-WRC2) neu angelegt. Dabei wurden diese nun nicht mehr als HMCCUDEV sondern HMCCUCHN angelegt. Soweit so gut, FHEM notifies entsprechend angepasst - ob ich oben oder gedrückt habe, wird nun ja in zwei HMCCUCHN-Devices unterschieden. Allerdings kamen einfach gar keine Events mehr an,laut Event Monitor. Mir ist dann aufgefallen, dass per Default das Attribut auf event-on-update-reading auf PRESS gesetzt war, die Events heißen aber PRESS_SHORT oder PRESS_LONG. Nachdem ich dann event-on-update-reading PRESS.* gesetzt habe, werden auch wieder Events erzeugt und meine notifies funktionieren wieder. Kannst Du das ggf. übernehmen, wenn da nichts gegen spricht?
Und dann habe ich noch eine Frage: Besteht die Möglichkeit, die Firmware eines Gerätes als Reading zu bekommen? Ich weiß, dass ich die Info mittels get deviceinfo bekommen kann, ich würde diese aber gerne in FHEM weiterverarbeiten (FirmwareCheck). Meine Recherche, wie ich ggf. den Output aus get deviceinfo weiterverarbeiten könnte, war bisher erfolglos. Danke schon mal.
Eigentlich sollte es bei jedem Device ein Internal "firmware" geben. Das ist leider noch ein Fehler.
Du kannst einen Taster auch wie bisher als HMCCUDEV definieren, allerdings musst Du beim Define dann die Option "forceDev" angeben. m.E. ist aber HMCCUCHN die saubere Lösung.
Bei event-on-update-reading bin ich bisher davon ausgegangen, dass die Angabe als regulärer Ausdruck betrachtet wird. Dann würde PRESS sowohl PRESS_SHORT als auch PRESS_LONG matchen. Wenn das nicht so ist, muss ich tatsächlich die Default-Einstellung korrigieren.
Nutzt jemand hier die Version 4.4 für HMIP-Wired? Ich hätte gerne (zumindest für die Mehrfachaktoren) mal 1-2 Beispiel-Ausgaben von "get deviceinfo" und "get paramsetdesc".
Hintergrund: Diese Geräte werden aktuell von HMCCU 4.4 nicht unbedingt korrekt erkannt.
Zitat von: dennisk am 28 März 2021, 14:21:29
Und dann habe ich noch eine Frage: Besteht die Möglichkeit, die Firmware eines Gerätes als Reading zu bekommen? Ich weiß, dass ich die Info mittels get deviceinfo bekommen kann, ich würde diese aber gerne in FHEM weiterverarbeiten (FirmwareCheck). Meine Recherche, wie ich ggf. den Output aus get deviceinfo weiterverarbeiten könnte, war bisher erfolglos. Danke schon mal.
Es gibt ein Internal mit der Firmware-Version - zumindest finde ich es bei ein paar meiner Geräte, egal ob HM-RF oder HmIP.
Internals:
.FhemMetaInternals 1
.eventMapCmd off:noArg on:noArg
CFGFN ./cfg.d/out/lights/wall/south.cfg
DEF MEQ1828567
FUUID 60592dec-f33f-a67d-5d80-90f5f29de774aa6c
FVERSION 88_HMCCUDEV.pm:v4.3.12-s21452/2020-03-19
IODev general.interfaces.homematic.ccu3
NAME out.lights.wall.south.ambiente
NR 9657
STATE 0
device_alive
rssi_good
TYPE HMCCUDEV
ccuaddr XXXXXXXXX
ccudevstate active
ccuif BidCos-RF
ccuname out.lights.wall.groundfloor.south
ccutype HM-LC-Dim1TPBU-FM
channels 4
firmware 2.9
statevals devstate|on|off
Zitat@Jamo: Bitte lösche mal testweise das stateFormat Attribut und prüfe, wie es sich dann verhält.
Hallo Zap,
kein Unterschied, hier der EventLog. Das attribut "event-on-change-reading power,state" ist gesetzt, 2 Events werden generiert.
2021-03-29 11:24:02 Global global DELETEATTR HMIP_PSM2 HMIP_PSM2 stateFormat
2021-03-29 11:24:03 Global global SAVE
2021-03-29 11:24:07 HMCCUDEV HMIP_PSM2 on
2021-03-29 11:24:07 HMCCUDEV HMIP_PSM2 on
2021-03-29 11:24:15 HMCCUDEV HMIP_PSM2 off
2021-03-29 11:24:15 HMCCUDEV HMIP_PSM2 off
2021-03-29 11:24:16 HMCCUCHN PresenceDetect1_Danke und Grüsse!
@Jamo: Was Du siehst, sind 2 Events: 1x für state und 1x für 3.STATE. Das wird deutlich, wenn du das Attribut änderst in:
event-on-change-reading 6.POWER,3.STATE
Dann kommt folgendes:
2021-03-29 13:53:50 HMCCUDEV HMD_ST_WR_Trockner on
2021-03-29 13:53:50 HMCCUDEV HMD_ST_WR_Trockner 3.STATE: on
Dann kannst Du Dein Notify auf eines der beiden Events ausrichten.
Zitat von: zap am 29 März 2021, 09:57:18
Eigentlich sollte es bei jedem Device ein Internal "firmware" geben. Das ist leider noch ein Fehler.
Du kannst einen Taster auch wie bisher als HMCCUDEV definieren, allerdings musst Du beim Define dann die Option "forceDev" angeben. m.E. ist aber HMCCUCHN die saubere Lösung.
Bei event-on-update-reading bin ich bisher davon ausgegangen, dass die Angabe als regulärer Ausdruck betrachtet wird. Dann würde PRESS sowohl PRESS_SHORT als auch PRESS_LONG matchen. Wenn das nicht so ist, muss ich tatsächlich die Default-Einstellung korrigieren.
Vielen Dank für die Rückmeldung. Das Internal "firmware" gibt es bei mir bei keinem der HmIP-Geräte. Ich habe mit der Beta 4.4 komplett von Vorne angefangen und nur HmIP.
Wäre super, wenn Du den Fehler bei Zeiten fixen könntest.
Die Taster funktionieren so wie gewünscht, wenn ich eben PRESS.* hinterlege, sprich die Änderung der Default-Einstellung klingt für mich richtig.
Zitat von: Christoph Morrison am 29 März 2021, 10:40:36
Es gibt ein Internal mit der Firmware-Version - zumindest finde ich es bei ein paar meiner Geräte, egal ob HM-RF oder HmIP.
Internals:
.FhemMetaInternals 1
.eventMapCmd off:noArg on:noArg
CFGFN ./cfg.d/out/lights/wall/south.cfg
DEF MEQ1828567
FUUID 60592dec-f33f-a67d-5d80-90f5f29de774aa6c
FVERSION 88_HMCCUDEV.pm:v4.3.12-s21452/2020-03-19
IODev general.interfaces.homematic.ccu3
NAME out.lights.wall.south.ambiente
NR 9657
STATE 0
device_alive
rssi_good
TYPE HMCCUDEV
ccuaddr XXXXXXXXX
ccudevstate active
ccuif BidCos-RF
ccuname out.lights.wall.groundfloor.south
ccutype HM-LC-Dim1TPBU-FM
channels 4
firmware 2.9
statevals devstate|on|off
Interessant, bei mir taucht das wie gesagt bei keinem der Geräte auf. Aber danke für den Hinweis.
Zitat von: juemuc am 23 März 2021, 20:40:56
Hallo zap.
nach dem update erhalte ich nun permanent diese Meldungen:
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Fenster#Wohnzimmer#zu incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Fenster#Buero#auf incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Fenster#Buero#zu incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Balkontuer#zu incomplete
2021.03.23 20:37:08 2: HMCCU [HMCCU3] Information for CCU program Fenster#Kueche#auf incomplete
Was läuft hier falsch?
Viele Grüße
Jürgen
Hallo zap,
hast Du schon eine Idee, wo der Fehler liegt? Mit der Version 4.4.060 war noch alles ok.
Viele Grüße
Jürgen
Zitat von: juemuc am 29 März 2021, 22:24:36
Hallo zap,
hast Du schon eine Idee, wo der Fehler liegt? Mit der Version 4.4.060 war noch alles ok.
Viele Grüße
Jürgen
Mach mal bitte ein list vom I/O device und suche in der Ausgabe nach "prg:". Was steht unter prg: ?Hat sich erledigt. Fehler gefunden.
Zitat von: zap am 29 März 2021, 13:57:18
@Jamo: Was Du siehst, sind 2 Events: 1x für state und 1x für 3.STATE. Das wird deutlich, wenn du das Attribut änderst in:
event-on-change-reading 6.POWER,3.STATE
Dann kommt folgendes:
2021-03-29 13:53:50 HMCCUDEV HMD_ST_WR_Trockner on
2021-03-29 13:53:50 HMCCUDEV HMD_ST_WR_Trockner 3.STATE: on
Dann kannst Du Dein Notify auf eines der beiden Events ausrichten.
Hallo Zap,
danke. Du meinst es sind 2 Events, weil ich den ccureadingname 3.STATE auf state gemappt habe? Durch das ccureadingname habe ich dann einmal fuer 3.STATE und das state jeweils einen Event, habe ich das so richtig verstanden?
ccureadingname
3.STATE:state;6.POWER:power;6.ENERGY_COUNTER:energy
Jedes Device hat einen State- und/oder Controldatapoint. Der Statedatapoint wird immer und automatisch auf state gemapt. Daher darf state in ccureadingname nicht vorkommen. Ich werde da noch eine entsprechende Abfrage einbauen, damit eine Fehlermeldung angezeigt wird.
Mit der 4.4.064 ist HMCCU jetzt der Meinung, dass ein BSM ein Taster(?) sei.
Deshalb wird z.B. Current control datapoint = 1.PRESS_SHORT gesetzt. Was aber IMO Quatsch ist, der sollte auf 4.STATE liegen.
Es wird auch gesetzt:
event-on-update-reading PRESS
webCmd press
Hab aber nicht geschaut, ob das auch bei anderen Typen passiert, da ich nur den einen BSM einrichten musste.
Zitat von: kjmEjfu am 01 April 2021, 08:13:44
Mit der 4.4.064 ist HMCCU jetzt der Meinung, dass ein BSM ein Taster(?) sei.
Deshalb wird z.B. Current control datapoint = 1.PRESS_SHORT gesetzt. Was aber IMO Quatsch ist, der sollte auf 4.STATE liegen.
Es wird auch gesetzt:
event-on-update-reading PRESS
webCmd press
Hab aber nicht geschaut, ob das auch bei anderen Typen passiert, da ich nur den einen BSM einrichten musste.
Hm, beim PSM nicht. Bitte einmal "get deviceinfo".Ist ein Bug. Keine weitere Info erforderlich
Da hatte sich noch etwas 4.3 Code reingemogelt ;-)
Hallo zap. Habe HMCCU auf config 4.8.022 version 4.4.064 aktualisiert.
Dort wird im SET_POINT_MODE inzwischen der Status auto (vorher 0) und manual (vorher 1) für ein HmIP-eTRV-2 korrekt gesetzt. Lediglich wenn ich den Boost-Modus aktiviere ist zwar BOOST_MODE = true, aber SET_POINT_MODE bleibt bei auto - korrekt wäre dann boost.
Gruß, danke für die Fortschritte und frohe Ostertage
eurofinder
Zitat von: eurofinder am 03 April 2021, 09:30:24
Hallo zap. Habe HMCCU auf config 4.8.022 version 4.4.064 aktualisiert.
Dort wird im SET_POINT_MODE inzwischen der Status auto (vorher 0) und manual (vorher 1) für ein HmIP-eTRV-2 korrekt gesetzt. Lediglich wenn ich den Boost-Modus aktiviere ist zwar BOOST_MODE = true, aber SET_POINT_MODE bleibt bei auto - korrekt wäre dann boost.
Gruß, danke für die Fortschritte und frohe Ostertage
eurofinder
Hallo zap, ich kann mich eurofinder anschließen, auch bei mir selbiges Verhalten nach Update. Danke auch von mir nochmal und erholsame Ostertage.
Grüße
Zitat von: dennisk am 29 März 2021, 15:36:29
Vielen Dank für die Rückmeldung. Das Internal "firmware" gibt es bei mir bei keinem der HmIP-Geräte. Ich habe mit der Beta 4.4 komplett von Vorne angefangen und nur HmIP.
Wäre super, wenn Du den Fehler bei Zeiten fixen könntest.
Die Taster funktionieren so wie gewünscht, wenn ich eben PRESS.* hinterlege, sprich die Änderung der Default-Einstellung klingt für mich richtig.
Interessant, bei mir taucht das wie gesagt bei keinem der Geräte auf. Aber danke für den Hinweis.
Überraschenderweise taucht das Internal firmware jetzt auf, allerdings nur mit einem Fragezeichen.Vielleicht hilft die Info ja.
Zitat von: eurofinder am 03 April 2021, 09:30:24
Hallo zap. Habe HMCCU auf config 4.8.022 version 4.4.064 aktualisiert.
Dort wird im SET_POINT_MODE inzwischen der Status auto (vorher 0) und manual (vorher 1) für ein HmIP-eTRV-2 korrekt gesetzt. Lediglich wenn ich den Boost-Modus aktiviere ist zwar BOOST_MODE = true, aber SET_POINT_MODE bleibt bei auto - korrekt wäre dann boost.
Gruß, danke für die Fortschritte und frohe Ostertage
eurofinder
Das ist wie vermutet: Boost und Auto sind unterschiedliche Dinge. Auto bleibt aktiv, aber Boost hat Prio. Insofern wäre es falsch, beide Datenpunkte in ein Reading zusammen zu fassen.
@zap:
Dann bleibe ich bei meinem eigenem userreading controlMode in angepasster Form, der alle Stati beinhaltet.
Gruß
eurofinder
Hallo zap,
ich muss zugeben, aktuell habe ich nicht den ganzen Thread durchgelesen zu diesem Punkt.
Ich habe gerade eben die CCU neu angelegt mit der Beta Version.
Mein erstes Devices ist der HM-IP Rauchmelder (siehe auch mein Thread dazu).
Nach get createDev <rauchmelder> wird der HmIP-SWSD im Raum "Unsorted" angelegt.
Mein Vorschlag: Für Anfänger mit HMCCU wäre es nett, neue HMCCU Devices im Raum "HM-CCU" o.ä. anzulegen (ähnlich zu CUL_HM im Raum "HM") oder direkt auf die Seite des neuen Devices zu springen. Dann braucht man nicht suchen.
tnx
Nach Neustart Warning im Log gefunden:
2021.04.05 12:09:50 1: PERL WARNING: Use of uninitialized value $devtype in hash element at ./FHEM/88_HMCCU.pm line 5733.
2021.04.05 12:09:50 1: PERL WARNING: Use of uninitialized value $devtype in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 5734.
HMCCU.pm Version Version 4.4.064
Kommt diese Fehlermeldung, wenn Du einen bestimmten Befehl ausführst?
Nein, einfach nur beim FHEM Start
In der kommenden Version behoben
Moin zusammen,
neue FM im Log gefunden:
2021.04.05 22:11:40 2: HMCCU [CCU3] Information for CCU program Rauchmelder#Buero#Test incomplete
2021.04.05 22:11:40 2: HMCCU [CCU3] Information for CCU program Rauchmelder#Buero#Alarm incomplete
2021.04.05 22:11:40 1: PERL WARNING: Argument "false" isn't numeric in numeric lt (<) at (eval 8388) line 1.
2021.04.06 08:01:32 2: HMCCU [CCU3] Information for CCU program Rauchmelder#Buero#Test incomplete
2021.04.06 08:01:32 2: HMCCU [CCU3] Information for CCU program Rauchmelder#Buero#Alarm incomplete
2021.04.06 08:01:33 1: PERL WARNING: Argument "false" isn't numeric in numeric lt (<) at (eval 14159) line 1.
2021.04.06 08:01:33 2: HMCCU [CCU3] Information for CCU program Rauchmelder#Buero#Test incomplete
2021.04.06 08:01:33 2: HMCCU [CCU3] Information for CCU program Rauchmelder#Buero#Alarm incomplete
2021.04.06 08:01:33 1: PERL WARNING: Argument "false" isn't numeric in numeric lt (<) at (eval 14266) line 1.
Das CCU Programm "Rauchmelder#Buero#Test" (Email Benachrichtigung bei Test) funktioniert, das "Alarm" Programm geht nur auf eine andere Variable und ein 2. Email Template und sollte daher auch funktionieren.
Beide Programme werden in der CCU als fehlerfrei geprüft.
Ich nehme an, die PERL WARNINGs gehören zum HMCCU Modul, aber das ist nur eine Vermutung wegen der zeitlichen Assoziation.
VG Helmut
Hi, ich versuche gerade einen Helligkeitssensor hinzuzufügen.
Eine Fernbedienung HM-RC-Dis-H-x-EU hat funktioniert.
aber bei dem HmIP-SLO bekomme ich in FHEM folgende Meldung:
Results of create command:
Not detected CCU devices:
Helligkeitssensor = 000D5BE9A46818.Helligkeitssensor
ein get d_ccu deviceInfo Helligkeitssensor gibt folgendes:
Device channels and datapoints
DEV Helligkeitssensor 000D5BE9A46818 interface=HmIP-RF type=HmIP-SLO
CHN 000D5BE9A46818:0 Helligkeitssensor:0
DPT {b} HmIP-RF.000D5BE9A46818:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.000D5BE9A46818:0.DUTY_CYCLE = false [RE]
DPT {b} HmIP-RF.000D5BE9A46818:0.INSTALL_TEST = true [RW]
DPT {b} HmIP-RF.000D5BE9A46818:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.000D5BE9A46818:0.OPERATING_VOLTAGE = 3.100000 [RE]
DPT {i} HmIP-RF.000D5BE9A46818:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.000D5BE9A46818:0.RSSI_DEVICE = 220 [RE]
DPT {n} HmIP-RF.000D5BE9A46818:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.000D5BE9A46818:0.UNREACH = false [RE]
DPT {b} HmIP-RF.000D5BE9A46818:0.UPDATE_PENDING = false [RE]
CHN 000D5BE9A46818:1 HmIP-SLO 000D5BE9A46818:1
DPT {f} HmIP-RF.000D5BE9A46818:1.AVERAGE_ILLUMINATION = 188.700000 [RE]
DPT {i} HmIP-RF.000D5BE9A46818:1.AVERAGE_ILLUMINATION_STATUS = 0 [RE]
DPT {f} HmIP-RF.000D5BE9A46818:1.CURRENT_ILLUMINATION = 117.280000 [RE]
DPT {i} HmIP-RF.000D5BE9A46818:1.CURRENT_ILLUMINATION_STATUS = 0 [RE]
DPT {f} HmIP-RF.000D5BE9A46818:1.HIGHEST_ILLUMINATION = 240.400000 [RE]
DPT {i} HmIP-RF.000D5BE9A46818:1.HIGHEST_ILLUMINATION_STATUS = 0 [RE]
DPT {f} HmIP-RF.000D5BE9A46818:1.LOWEST_ILLUMINATION = 117.280000 [RE]
DPT {i} HmIP-RF.000D5BE9A46818:1.LOWEST_ILLUMINATION_STATUS = 0 [RE]
Device detection:
No state datapoint detected
No control datapoint detected
Failed to detect device settings. Device must be configured manually.
Device description
Device 000D5BE9A46818 Helligkeitssensor [HmIP-SLO]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 000D5BE9A46818:0,000D5BE9A46818:1,000D5BE9A46818:2,000D5BE9A46818:3
DIRECTION: NONE
FIRMWARE: 1.0.16
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 6272892
ROAMING: 0
RX_MODE: CONFIG
SUBTYPE: SLO
UPDATABLE: 1
Channel 000D5BE9A46818:0 Helligkeitssensor:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 000D5BE9A46818
PARENT_TYPE: HmIP-SLO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000D5BE9A46818:1 HmIP-SLO 000D5BE9A46818:1 [BRIGHTNESS_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 000D5BE9A46818
PARENT_TYPE: HmIP-SLO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000D5BE9A46818:2 HmIP-SLO 000D5BE9A46818:2 [COND_SWITCH_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000D5BE9A46818
PARENT_TYPE: HmIP-SLO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000D5BE9A46818:3 HmIP-SLO 000D5BE9A46818:3 [COND_SWITCH_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000D5BE9A46818
PARENT_TYPE: HmIP-SLO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
OK
Kann einer weiter helfen??
LG Patrick
EDIT: Habe jetzt erst gesehen: "Failed to detect device settings. Device must be configured manually."
Habe jetzt das gerät Hinzufügen können....
Haben wir eine Übersicht welche HM/HMIP Geräte automatisch erkannt werden und welche aktuell manuall konfiguriert werden müssen ?
HMCCU 4.4 kennt die Rollen von Kanälen von Geräten. Klingt kompliziert, ist es aber nicht. Es gibt nur relativ wenige Rollen (KEY, SWITCH) usw. Bei 4.3 gab es Settings für jeden Gerätetyp. Das war sehr umständlich. Ich mache morgen mal einemListe der Rollen.
Wenn du im IO Device für ein Gerät get deviceinfo ausführst, zeigt die HMCCU die erkannten Rollen / Kanäle an.
O.k. Danke.
Ich möchte nochmals auf das Thema Internals und Attribute aus dem HMCCU Board Diskussion zurückkommen.
Ich hab dort geschrieben.
Internals ccuaddr abcdefghijk:1 nach Attributes serialNr abcdefghijk:1
Die Antwort war
Es ist eben keine Seriennummer sondern tatsächlich eine Adresse und wird auch in der CCU als ADDRESS geführt.
Ich hab mir das nochmals angesehen. Die ccu3-webui spricht in Einstellung | Geräte da aber auch von einer Seriennummer. In der Tat erinnert das Format stark an eine MAC Adresse. Dürfte also auch in der OriginalSW nicht so ganz konsistent sein.
Mir ging's dabei aber um die Zuweisung per Attribute. Ich habe Anwendungsfälle wo ich ein spezifische Gerät innerhalb einer Gruppe besonders behandeln muss.
Per $o = $attr{<Gerätename>}{serialNr}; geht das elegant.
Aktuell wüsste ich nicht wie ich an die Internals Einträge rankomme.
Allgemein sehe ich statische Einträge wie Modell, Seriennummer, Typ und Subtyp in den Attributen bzw. hilfsweise in den Readings und hoffe das ist mit geringen Aufwand machbar.
Zitat von: 1.fhemtester am 06 April 2021, 21:13:14
Mir ging's dabei aber um die Zuweisung per Attribute. Ich habe Anwendungsfälle wo ich ein spezifische Gerät innerhalb einer Gruppe besonders behandeln muss.
Per $o = $attr{<Gerätename>}{serialNr}; geht das elegant.
Aktuell wüsste ich nicht wie ich an die Internals Einträge rankomme.
InternalVal(<devicename>,<internal>, <defaultvalue>)
Gibt den Inhalt der "internal" zurück (den Inhalt der in dem "Internals"-Abschnitt von "list device" angezeigt wird)
Reicht dir nicht?
Zitat von: 1.fhemtester am 06 April 2021, 21:13:14
Allgemein sehe ich statische Einträge wie Modell, Seriennummer, Typ und Subtyp in den Attributen bzw. hilfsweise in den Readings und hoffe das ist mit geringen Aufwand machbar.
in der 4.4? Da habe ich solche Daten weder in Attributen noch in Readings. Bei welchem Gerät findest du die?
Zitat von: kjmEjfu am 07 April 2021, 08:13:06
in der 4.4? Da habe ich solche Daten weder in Attributen noch in Readings. Bei welchem Gerät findest du die?
Er sieht sie ja gerade nicht, sondern will sie dort sehen, anstatt in den Internals (wo sie IMHO auch gut aufgehoben sind).
ZitatPer $o = $attr{<Gerätename>}{serialNr}; geht das elegant.
Neben
InternalVal() geht ja sogar set magic mit Internals (
[i:device:internalname]). Der direkte Zugriff auf die Konfig-Hashes sollte eh unterlassen werden (
AttrVal() existiert). Falls du die Internals nicht in FHEMWEB siehst, kannst du sie mit
attr global showInternalValues 1einblenden.
Hallo zusammen, ich habe eine allgemeine Frage zu den Readings (HmIP-SWSD Rauchmelder) im vorliegenden HMCCU Beta Modul:
a) Beim "Event monitor" wird der Event für den Test angezeigt als
az_HmIP_SWSD:SMOKE_DETECTOR_TEST_RESULT:.SMOKE_TEST_OK
Darauf triggert auch das Notify zwecks Email-Info
Im Reading des SWSD wird jedoch angezeigt:
SMOKE_DETECTOR_TEST_RESULT 0
Frage a) Ist das so erwünscht oder noch ein offener Punkt (Event im Event monitor ungleich Reading)
b) Beim "Log" wird der Event für die Standard Meldung (1* pro Tag ca.) angezeigt als
SMOKE_DETECTOR_ALARM_STATUS: 0
Ich habe das Notify auf den Wert
az_HmIP_SWSD:SMOKE_DETECTOR_ALARM_STATUS:.IDLE_OFF
angelegt wie beim Test, das triggert nicht.
Ich stelle das jetzt mal probeweise auf "0" um.
Muss ich bei a) auch auf auf den Wert "0" umstellen?
Sollten die Events nicht mit den Readings übereinstimmen, da sonst das automatische Anlegen eines Notify/Watchdogs nicht funktioniert?
VG Helmut
Ich habe die Rauchmelder bei mir so ergänzt:
defmod Sensor_OG_Flur_Rauch HMCCUCHN xxx:1
attr Sensor_OG_Flur_Rauch IODev d_ccu
attr Sensor_OG_Flur_Rauch alias Rauchmelder Flur OG
attr Sensor_OG_Flur_Rauch devStateIcon noAlarm:secur_smoke_detector Alarm:secur_smoke_detector@red
attr Sensor_OG_Flur_Rauch event-on-change-reading .*
attr Sensor_OG_Flur_Rauch group Sicherheit
attr Sensor_OG_Flur_Rauch room Homematic
attr Sensor_OG_Flur_Rauch substitute SMOKE_DETECTOR_ALARM_STATUS!(1|true|.*_ALARM):Alarm,(0|false|IDLE_OFF):noAlarm
Zitat von: kjmEjfu am 07 April 2021, 11:42:51
Ich habe die Rauchmelder bei mir so ergänzt:
defmod Sensor_OG_Flur_Rauch HMCCUCHN xxx:1
attr Sensor_OG_Flur_Rauch IODev d_ccu
attr Sensor_OG_Flur_Rauch alias Rauchmelder Flur OG
attr Sensor_OG_Flur_Rauch devStateIcon noAlarm:secur_smoke_detector Alarm:secur_smoke_detector@red
attr Sensor_OG_Flur_Rauch event-on-change-reading .*
attr Sensor_OG_Flur_Rauch group Sicherheit
attr Sensor_OG_Flur_Rauch room Homematic
attr Sensor_OG_Flur_Rauch substitute SMOKE_DETECTOR_ALARM_STATUS!(1|true|.*_ALARM):Alarm,(0|false|IDLE_OFF):noAlarm
TNX, probiere ich mal aus!
@kjmEjfu, Christoph Morrison Danke, wieder was dazugelernt.
Ich hab heute ein Update auf RC1 gemacht und hab im FHEM Log zahlreiche Einträge der Art
2021.04.07 15:34:10 2: HMCCU [pccu] Attr command failed HM_RCV_50_BidCoS_RF_x controldatapoint 3.MOTION_DETECTION_ACTIVE. Invalid value 3.MOTION_DETECTION_ACTIVE
2021.04.07 15:34:10 3: Invalid value 3.MOTION
2021.04.07 15:34:10 2: HMCCU [pccu] Attr command failed HM_RCV_50_BidCoS_RF_x statedatapoint 3.MOTION. Invalid value 3.MOTION
Ich vermute mal, das kann ich ignorieren weil ich keine BidCos Geräte habe ?
Die Frage wäre auch: Kann man in HMCCUCHN die BidCos Einträge komplett ausschalten ?
Zitat von: 1.fhemtester am 07 April 2021, 17:30:01
@kjmEjfu, Christoph Morrison Danke, wieder was dazugelernt.
Ich hab heute ein Update auf RC1 gemacht und hab im FHEM Log zahlreiche Einträge der Art
2021.04.07 15:34:10 2: HMCCU [pccu] Attr command failed HM_RCV_50_BidCoS_RF_x controldatapoint 3.MOTION_DETECTION_ACTIVE. Invalid value 3.MOTION_DETECTION_ACTIVE
2021.04.07 15:34:10 3: Invalid value 3.MOTION
2021.04.07 15:34:10 2: HMCCU [pccu] Attr command failed HM_RCV_50_BidCoS_RF_x statedatapoint 3.MOTION. Invalid value 3.MOTION
Ich vermute mal, das kann ich ignorieren weil ich keine BidCos Geräte habe ?
Die Frage wäre auch: Kann man in HMCCUCHN die BidCos Einträge komplett ausschalten ?
Hast Du den Befehl "get pccu create .*" verwendet?
Die CCU hat je 1 virtuelles Gerät mit 50 Kanälen für BidCos-RF und HmIP-RF (egal, ob Du BidCos Geräte hast oder nicht). Du siehst diese virtuellen Geräte in der CCU Oberfläche unter Einstellungen > Geräte als Typ "HM-RCV-50" und "HMIP-RCV-50".
Ich muss diese Gerätetypen noch aus dem "get create" bzw. "get createdev" Befehl entfernen bzw. rausfiltern. Sonst legt man sich damit schnell 100 überflüssige FHEM Device an.
Danke für den Hinweis (auch wenn das jetzt den Upload des nächsten Updates wieder etwas verzögert, war gerade dabei ;) )
Zitat von: SamNitro am 06 April 2021, 14:35:30
Hi, ich versuche gerade einen Helligkeitssensor hinzuzufügen.
aber bei dem HmIP-SLO bekomme ich in FHEM folgende Meldung:
In der kommenden Version wird der Sensor automatisch erkannt. Danke für die Device-Infos!
Zitat von: zap am 08 April 2021, 09:52:10
In der kommenden Version wird der Sensor automatisch erkannt. Danke für die Device-Infos!
Gerne.
Werde in der nächsten zeit HmIP-Wired Bestellen und wenn ich dann etwas zeit habe, wird mein Eltako Bus dadurch getauscht...
Nein, die Fehlermeldungen kamen nach dem Reboot.
get create zeigt dieses Verhalten nicht.
Zitat von: zap am 08 April 2021, 09:13:16
Hast Du den Befehl "get pccu create .*" verwendet?
Im Log hab ich mehrere Einträge gefunden.
2021.04.07 15:35:52 3: HMCCUDEV [HmIP_SMI55_xxx] get HmIP_SMI55_xxx ?
Es könnte also einen Zusammenhang mit den Invalid value 3.MOTION_DETECTION_ACTIVE Meldungen geben.
BTW: Um unnötigen Aufwand beim Fehler suchen zu vermeiden.
Gibt es empfohlene Aktionen wenn Updates innerhalb 4.4 gemacht werden, also z.B. von RC1 auf RC2 ?
Oder auch nach einem CCU Firmware update ?
Zitat von: 1.fhemtester am 08 April 2021, 17:01:40
Im Log hab ich mehrere Einträge gefunden.
2021.04.07 15:35:52 3: HMCCUDEV [HmIP_SMI55_xxx] get HmIP_SMI55_xxx ?
Es könnte also einen Zusammenhang mit den Invalid value 3.MOTION_DETECTION_ACTIVE Meldungen geben.
BTW: Um unnötigen Aufwand beim Fehler suchen zu vermeiden.
Gibt es empfohlene Aktionen wenn Updates innerhalb 4.4 gemacht werden, also z.B. von RC1 auf RC2 ?
Oder auch nach einem CCU Firmware update ?
Kannst Du bitte mal ein list von HmIP_SMI55... machen?
Ich habe auf Github und FHEM-SVN-Contrib ein weiteres Update bereitgestellt. Das Update adressiert folgende Probleme:
- Unterstützung für HmIP-SLO (für alle Geräte mit einem BRIGHTNESS_TRANSCEIVER Kanal) wurde hinzugefügt
- Interne virtuelle Geräte der CCU (50 BidCos und HmIP Kanäle) werden von den "get create" und "get createDev" Befehlen nicht mehr unterstützt, um das Anlegen von vielen, ungenutzten FHEM Devices zu verhindern
- Fehler im Befehl "set command" für Rauchmelder behoben
- Perl Fehlermeldung beim Start von FHEM wurden behoben
- Die Option "coll" beim Attribut ccuaggregate funktioniert nun korrekt
- Die Priorität verschiedener Kanalrollen bei der automatischen Erkennung von Gerätetypen wurde ignoriert
- Das Attribut event-on-update-reading für Kanäle der Rolle KEY wurde auf PRESS.* geändert
- Ein Fehler bei der Integration von CCU-Programmen in den set Befehl des I/O Device wurde behoben
Installation über:
update all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txtoder
update all https://svn.fhem.de/trac/browser/trunk/fhem/contrib/HMCCU/controls_HMCCU.txtDie offenen und behobenen Fehler können hier eingesehen werden. Ich aktualisiere die Listen regelmäßig. Wer einen Github-Account hat, kann darüber auch selbst Fehler melden oder Wünsche äußern:
https://github.com/zapccu/HMCCU/issues
Hallo zap,
installation lief ohne Probleme. Aktuell erhalte ich diese Meldungen:
2021.04.09 19:40:18 2 : E1Zoom - User "reolink" has no valid session, logout is cancelled
2021.04.09 19:40:47 2 : HMCCU [HMCCU3] Can't get device description for 0000DA498D425C HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:378 HMCCUDEV_Set:3847 CallFn:1927 DoSet:1969 CommandSet:2804 getAllSets:104 CommandJsonList2:1265 AnalyzeCommand:1116 AnalyzeCommandChain:2764 FW_fC:962 FW_answerCall:597 FW_Read:3847 CallFn:773
2021.04.09 19:40:47 2 : HMCCU [HMCCU3] Can't get device description for 0000DA498D427A HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:378 HMCCUDEV_Set:3847 CallFn:1927 DoSet:1969 CommandSet:2804 getAllSets:104 CommandJsonList2:1265 AnalyzeCommand:1116 AnalyzeCommandChain:2764 FW_fC:962 FW_answerCall:597 FW_Read:3847 CallFn:773
2021.04.09 19:40:47 2 : HMCCU [HMCCU3] Can't get device description for 0000DA498D4303 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:378 HMCCUDEV_Set:3847 CallFn:1927 DoSet:1969 CommandSet:2804 getAllSets:104 CommandJsonList2:1265 AnalyzeCommand:1116 AnalyzeCommandChain:2764 FW_fC:962 FW_answerCall:597 FW_Read:3847 CallFn:773
2021.04.09 19:40:47 2 : HMCCU [HMCCU3] Can't get device description for NEQ1477040 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:378 HMCCUDEV_Set:3847 CallFn:1927 DoSet:1969 CommandSet:2804 getAllSets:104 CommandJsonList2:1265 AnalyzeCommand:1116 AnalyzeCommandChain:2764 FW_fC:962 FW_answerCall:597 FW_Read:3847 CallFn:773
2021.04.09 19:40:47 2 : HMCCU [HMCCU3] Can't get device description for OEQ0223456 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:378 HMCCUDEV_Set:3847 CallFn:1927 DoSet:1969 CommandSet:2804 getAllSets:104 CommandJsonList2:1265 AnalyzeCommand:1116 AnalyzeCommandChain:2764 FW_fC:962 FW_answerCall:597 FW_Read:3847 CallFn:773
2021.04.09 19:40:47 2 : HMCCU [HMCCU3] Can't get device description for OEQ0424862 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:378 HMCCUDEV_Set:3847 CallFn:1927 DoSet:1969 CommandSet:2804 getAllSets:104 CommandJsonList2:1265 AnalyzeCommand:1116 AnalyzeCommandChain:2764 FW_fC:962 FW_answerCall:597 FW_Read:3847 CallFn:773
Viele Grüße
Jürgen
Zitat von: zap am 09 April 2021, 13:50:28
Kannst Du bitte mal ein list von HmIP_SMI55... machen?
Siehe unten.
Was mir in diesem Zusammenhang aufgefallen ist: Im DeviceOverview sehe ich noMotion und einen AN und AUS Button.
Ich vermute mal An/Aus meint die Schaltfunktion des SMI55 ?
Es gibt aber auch ein 3.MOTION_DETECTION_ACTIVE Reading. Soweit ich das verstanden habe, kann man die Bewegungserkennung deaktivieren. Sollte da nicht auch im DeviceOverview eine Möglichkeit dazu angeboten werden ?
Der SMI55 hat ja eigentlich 2 Funktionsgruppen, den Bewegungsmelder und die Schaltfunktion, die ja unabhängig von einander genutzt werden können.
Damit braucht's aber eigentlich auch 2 state Einträge.
Dieses Problem haben auch andere Geräte mit Mehrfachfunktion z.B. HmIP-FSM16.
Den HmIP-FSM16 sehe ich in der RC1 aber nicht und kann daher keine Daten liefern.
Internals:
CFGFN
DEF xxx
FUUID yyy
IODev pccu
NAME HmIP_SMI55_xxx
NR 173
STATE noMotion
TYPE HMCCUDEV
ccuaddr xxx
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-SMI55 xxx
ccusubtype SMI55
ccutype HmIP-SMI55
readonly no
READINGS:
2021-04-09 20:17:35 3.ILLUMINATION 0.5
2021-04-09 20:17:35 3.ILLUMINATION_STATUS NORMAL
2021-04-09 20:17:35 3.MOTION noMotion
2021-04-09 20:17:35 3.MOTION_DETECTION_ACTIVE true
2021-04-09 20:17:35 activity alive
2021-04-09 20:17:35 battery ok
2021-04-09 20:17:35 control true
2021-04-09 20:17:35 devstate ok
2021-04-09 20:17:35 hmstate noMotion
2021-04-09 20:17:35 rssidevice -26
2021-04-09 20:17:35 state noMotion
hmccu:
channels 5
devspec xxx
forcedev 0
nodefaults 0
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:KEY_TRANSCEIVER,3:MOTIONDETECTOR_TRANSCEIVER,4:STATE_RESET_RECEIVER
semDefaults 0
cmdlist:
get
set press:noArg off:noArg on:noArg press:noArg off:noArg on:noArg off:noArg on:noArg
control:
chn 3
dpt MOTION_DETECTION_ACTIVE
dp:
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.LOW_BAT:
VALUES:
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 3.0
OVAL 3.0
SVAL 3.0
VAL 3.0
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -24
OVAL -24
SVAL -26
VAL -26
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
3.ILLUMINATION:
VALUES:
OSVAL 0.5
OVAL 0.5
SVAL 0.5
VAL 0.5
3.ILLUMINATION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
3.MOTION:
VALUES:
OSVAL noMotion
OVAL 0
SVAL noMotion
VAL 0
3.MOTION_DETECTION_ACTIVE:
VALUES:
OSVAL true
OVAL 1
SVAL true
VAL 1
roleCmds:
get:
set:
off:
channel ?
role MOTIONDETECTOR_TRANSCEIVER
subcount 1
syntax V:MOTION_DETECTION_ACTIVE:0
usage off
subcmd:
000:
args 0
dpt MOTION_DETECTION_ACTIVE
fnc
max 1
min 0
parname MOTION_DETECTION_ACTIVE
partype 3
ps VALUES
unit
on:
channel ?
role MOTIONDETECTOR_TRANSCEIVER
subcount 1
syntax V:MOTION_DETECTION_ACTIVE:1
usage on
subcmd:
000:
args 1
dpt MOTION_DETECTION_ACTIVE
fnc
max 1
min 0
parname MOTION_DETECTION_ACTIVE
partype 3
ps VALUES
unit
press:
channel ?
role KEY_TRANSCEIVER
subcount 1
syntax V:PRESS_SHORT:1
usage press
subcmd:
000:
args 1
dpt PRESS_SHORT
fnc
max 1
min 0
parname PRESS_SHORT
partype 3
ps VALUES
unit
state:
chn 3
dpt MOTION
Attributes:
IODev pccu
cmdIcon on:general_an off:general_aus
controldatapoint 3.MOTION_DETECTION_ACTIVE
room CCU_HM
statedatapoint 3.MOTION
Erstes Feedback zu RC2:
Ich hab bei der HMCCU ccudelay=180 definiert.
Im Log find ich
2021.04.09 21:11:03 1: HMCCU [pccu] Initialized version 4.4.065
2021.04.09 21:11:03 1: HMCCU [pccu] Scheduling delayed initialization in 180 seconds
und jede Menge
2021.04.09 21:11:03 2: HMCCUCHN [xxx] Cannot detect IO device, maybe CCU not ready. Trying later ...
Einträge
Kann man das irgendwie unterdrücken ? Durch die ccudelay ist doch 3 min Wartezeit definiert.
Nach den 3 min geht's dann weiter mit
2021.04.09 21:14:03 2: HMCCU [pccu] Can't get device description for HmIP-RCV-1:2 HMCCU_DetectDevice:162 HMCCUCHN_InitDevice:3056 HMCCU_UpdateDeviceTable:5344 HMCCU_GetDeviceList:523 HMCCU_InitDevice:3306 HandleTimeout:678
2021.04.09 21:14:03 1: PERL WARNING: Use of uninitialized value $detect in numeric eq (==) at ./FHEM/88_HMCCU.pm line 3455.
2021.04.09 21:14:03 2: HMCCUCHN [HmIP_RCV_50_HmIP_RCV_1_2] Can't get device description for HmIP-RCV-1:2 HMCCU_UpdateDeviceRoles:168 HMCCUCHN_InitDevice:3056 HMCCU_UpdateDeviceTable:5344 HMCCU_GetDeviceList:523 HMCCU_InitDevice:3306 HandleTimeout:678
2021.04.09 21:14:03 2: HMCCU [pccu] Can't get device description for HmIP-RCV-1:6 HMCCU_DetectDevice:162 HMCCUCHN_InitDevice:3056 HMCCU_UpdateDeviceTable:5344 HMCCU_GetDeviceList:523 HMCCU_InitDevice:3306 HandleTimeout:678
2021.04.09 21:14:03 2: HMCCUCHN [HmIP_RCV_50_HmIP_RCV_1_6] Can't get device description for HmIP-RCV-1:6 HMCCU_UpdateDeviceRoles:168 HMCCUCHN_InitDevice:3056 HMCCU_UpdateDeviceTable:5344 HMCCU_GetDeviceList:523 HMCCU_InitDevice:3306 HandleTimeout:678
und jede Menge ähnlicher Meldungen.
Danach ist alles normal.
Den HmIP-FSM16 sehe ich auch in RC2 nach get create nicht.
> Interne virtuelle Geräte der CCU (50 BidCos und HmIP Kanäle) werden von den "get create" und "get createDev" Befehlen nicht mehr unterstützt, um das Anlegen von vielen, ungenutzten FHEM Devices zu verhindern
Gib's einen Trick wie man die internen virtuellen Geräte einfach wieder löschen kann ?
Ich vermute mal die Can't get device description Meldungen hängen damit zusammen.
Hallo Zap,
kurze Rückmeldung zum RC2
Not detected CCU devices:
Keller-Ventil1 = XXXXXXXX [Keller-Ventil1] , ist ein HM-CC-VD
Bewegungsmelder = LTK0096482 [Bewegungsmelder], ist ein HM-SEN-MDIR-O-2
HM- und HMIP-Heizungsgruppen werden nicht angelegt
Failed to define devices:
Flur_INT0000004 = INT0000004 [Flur INT0000004]
Wohnzimmer_INT0000002 = INT0000002 [Wohnzimmer INT0000002]
Kueche_INT0000007 = INT0000007 [Kueche INT0000007]
...
vG Jens
Zitat von: Newbie am 10 April 2021, 10:58:29
Not detected CCU devices:
Keller-Ventil1 = XXXXXXXX [Keller-Ventil1] , ist ein HM-CC-VD
Bewegungsmelder = LTK0096482 [Bewegungsmelder], ist ein HM-SEN-MDIR-O-2
Kannst Du bitte mal (im I/O Device) folgende Befehle ausführen:
get deviceInfo Keller-Ventil1
get paramsetDesc Keller-Ventil1
get deviceInfo Bewegungsmelder
get paramsetDesc Bewegungsmelder
Wenn ich diese Infos habe, kann ich die entsprechenden Rollen hinterlegen.
Zitat von: 1.fhemtester am 09 April 2021, 22:11:31
Gib's einen Trick wie man die internen virtuellen Geräte einfach wieder löschen kann ?
Ich vermute mal die Can't get device description Meldungen hängen damit zusammen.
Versuch mal das:
Für BidCos-RF:
delete i:ccutype=HM-RCV-50Für HmIP:
delete i:ccutype=HmIP-RCV-50
Zitat von: 1.fhemtester am 09 April 2021, 21:00:11
Siehe unten.
Was mir in diesem Zusammenhang aufgefallen ist: Im DeviceOverview sehe ich noMotion und einen AN und AUS Button.
Ich vermute mal An/Aus meint die Schaltfunktion des SMI55 ?
Es gibt aber auch ein 3.MOTION_DETECTION_ACTIVE Reading. Soweit ich das verstanden habe, kann man die Bewegungserkennung deaktivieren. Sollte da nicht auch im DeviceOverview eine Möglichkeit dazu angeboten werden ?
Der SMI55 hat ja eigentlich 2 Funktionsgruppen, den Bewegungsmelder und die Schaltfunktion, die ja unabhängig von einander genutzt werden können.
Damit braucht's aber eigentlich auch 2 state Einträge.
Dieses Problem haben auch andere Geräte mit Mehrfachfunktion z.B. HmIP-FSM16.
Den HmIP-FSM16 sehe ich in der RC1 aber nicht und kann daher keine Daten liefern.
on/off meint in diesem Fall das Ein-/Ausschalten der Bewegungserkennung. Das werde ich ändern in einen "set motionDetection on/off" Befehl, damit klarer ist, was gemeint ist. Danke für den Hinweis (habe selbst keinen Bewegungsmelder).
Für den 1. Schaltkanal gibt es den "press" Befehl. Beim SMI55 ignoriert HMCCU beim Anlegen leider den 2. Schaltkanal. In diesem Fall wäre es tatsächlich besser, 3 HMCCUCHN Device anzulegen. Das kannst Du manuell machen:
define Switch1 HMCCUCHN addr:1
define Switch2 HMCCUCHN addr:2
define Motion HMCCUCHN addr:3Du kannst auch das HMCCUDEV behalten. Dann kannst Du die beiden Schaltkanäle wie folgt nutzen:
Taste Kanal 1 drücken: set Switch datapoint 1.PRESS 1
Taste Kanal 2 drücken: set Switch datapoint 2.PRESS 1So richtig glücklich bin ich mit keiner der beiden Lösungen, weiß aber nicht, wie ich es anders/besser lösen soll. Das Gerät ist ja kein klassischer Ein-/Ausschalter (1 Kanal) sondern hat 2 unabhängige Schaltkanäle.
Möglicherweise gibt es hier auch noch einen Bug, denn die Angabe "channel ?" im List kommt mir seltsam vor.
Zum HmIP-FSM16: Was meinst Du damit, dass Du ihn nicht siehst? Wenn Du im I/O Device den Befehl "get deviceInfo" auswählst, wird dann der HmIP-FSM16 in der Dropdown-Liste angezeigt?
Hallo Zap,
get deviceInfo Keller-Ventil1
Device channels and datapoints
DEV Keller-Ventil1 XXXXXXXXX interface=BidCos-RF type=HM-CC-VD
CHN XXXXXXXXX:0 Keller-Ventil1:0
DPT {b} BidCos-RF.XXXXXXXXX:0.UNREACH = false [RE]
DPT {b} BidCos-RF.XXXXXXXXX:0.STICKY_UNREACH = false [RWE]
DPT {b} BidCos-RF.XXXXXXXXX:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.XXXXXXXXX:0.LOWBAT = false [RE]
DPT {n} BidCos-RF.XXXXXXXXX:0.RSSI_DEVICE = 1 [RE]
DPT {n} BidCos-RF.XXXXXXXXX:0.RSSI_PEER = 184 [RE]
CHN XXXXXXXXX:1 Keller-Ventil1:1
DPT {i} BidCos-RF.XXXXXXXXX:1.VALVE_STATE = 14 [RE]
DPT {i} BidCos-RF.XXXXXXXXX:1.ERROR = 0 [RE]
Device detection:
No state datapoint detected
No control datapoint detected
Failed to detect device settings. Device must be configured manually.
Device description
Device XXXXXXXXX Keller-Ventil1 [HM-CC-VD]
CHILDREN: XXXXXXXXX:0,XXXXXXXXX:1
FIRMWARE: 2.0
FLAGS: Visible
INTERFACE: YYYYYYYYYY
PARAMSETS: MASTER
RF_ADDRESS: 1738077
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG
UPDATABLE: 0
Channel XXXXXXXXX:0 Keller-Ventil1:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: XXXXXXXXX
PARENT_TYPE: HM-CC-VD
Channel XXXXXXXXX:1 Keller-Ventil1:1 [CLIMATECONTROL_VENT_DRIVE]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: CLIMATECONTROL_TC
PARAMSETS: LINK,MASTER,VALUES
PARENT: XXXXXXXXX
PARENT_TYPE: HM-CC-VD
get paramsetDesc Keller-Ventil1
Channel 0
Paramset VALUES
CONFIG_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
LOWBAT: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
RSSI_DEVICE: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648...2147483647 DFLT=0
RSSI_PEER: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648...2147483647 DFLT=0
STICKY_UNREACH: BOOL [R,W,E] [Sticky,Internal] RANGE=0...1 DFLT=0
UNREACH: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
Channel 1
Paramset MASTER
VALVE_ERROR_POSITION: INTEGER [R,W] [Visible,Sticky] RANGE=0...99 DFLT=0 UNIT=%
VALVE_OFFSET_VALUE: INTEGER [R,W] [Visible,Sticky] RANGE=0...25 DFLT=0 UNIT=%
Paramset VALUES
ERROR: ENUM [R,E] [Visible,Sticky,Service] RANGE=0...4 DFLT=0 VALUES=NO_ERROR,VALVE_DRIVE_BLOCKED,VALVE_DRIVE_LOOSE,ADJUSTING_RANGE_TO_SMALL,LOWBAT
VALVE_STATE: INTEGER [R,E] [Visible,Sticky] RANGE=0...99 DFLT=0 UNIT=%
get deviceInfo Bewegungsmelder
Device channels and datapoints
DEV Bewegungsmelder XXXXXXXXX interface=BidCos-RF type=HM-Sen-MDIR-O-2
CHN XXXXXXXXX:0 Bewegungsmelder:0
DPT {b} BidCos-RF.XXXXXXXXX:0.UNREACH = false [RE]
DPT {b} BidCos-RF.XXXXXXXXX:0.STICKY_UNREACH = false [RWE]
DPT {b} BidCos-RF.XXXXXXXXX:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.XXXXXXXXX:0.LOWBAT = false [RE]
DPT {n} BidCos-RF.XXXXXXXXX:0.RSSI_DEVICE = 1 [RE]
DPT {n} BidCos-RF.XXXXXXXXX:0.RSSI_PEER = 160 [RE]
DPT {b} BidCos-RF.XXXXXXXXX:0.DEVICE_IN_BOOTLOADER = false [RE]
DPT {b} BidCos-RF.XXXXXXXXX:0.UPDATE_PENDING = false [RE]
DPT {n} BidCos-RF.XXXXXXXXX:0.AES_KEY = 0 [R]
DPT {b} BidCos-RF.XXXXXXXXX:0.ENTER_BOOTLOADER = [W]
CHN XXXXXXXXX:1 Bewegungsmelder:1
DPT {i} BidCos-RF.XXXXXXXXX:1.BRIGHTNESS = 195 [RE]
DPT {b} BidCos-RF.XXXXXXXXX:1.MOTION = false [RE]
DPT {b} BidCos-RF.XXXXXXXXX:1.INSTALL_TEST = [E]
Device detection:
No state datapoint detected
No control datapoint detected
Failed to detect device settings. Device must be configured manually.
Device description
Device XXXXXXXXX Bewegungsmelder [HM-Sen-MDIR-O-2]
CHILDREN: XXXXXXXXX:0,XXXXXXXXX:1
FIRMWARE: 1.6
FLAGS: Visible
INTERFACE: YYYYYYYYYY
PARAMSETS: MASTER
RF_ADDRESS: 2906099
ROAMING: 0
RX_MODE: LAZY_CONFIG,BURST
UPDATABLE: 1
Channel XXXXXXXXX:0 Bewegungsmelder:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: XXXXXXXXX
PARENT_TYPE: HM-Sen-MDIR-O-2
Channel XXXXXXXXX:1 Bewegungsmelder:1 [MOTION_DETECTOR]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: KEYMATIC,SWITCH,WINMATIC
PARAMSETS: LINK,MASTER,VALUES
PARENT: XXXXXXXXX
PARENT_TYPE: HM-Sen-MDIR-O-2
get paramsetDesc Bewegungsmelder
Channel 0
Paramset VALUES
AES_KEY: INTEGER [R] [] RANGE=0...127 DFLT=0
CONFIG_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
DEVICE_IN_BOOTLOADER: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
ENTER_BOOTLOADER: ACTION [W] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
LOWBAT: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
RSSI_DEVICE: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648...2147483647 DFLT=0
RSSI_PEER: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648...2147483647 DFLT=0
STICKY_UNREACH: BOOL [R,W,E] [Sticky,Internal] RANGE=0...1 DFLT=0
UNREACH: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
UPDATE_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
Channel 1
Paramset LINK
PEER_NEEDS_BURST: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
Paramset MASTER
AES_ACTIVE: BOOL [R,W] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
BRIGHTNESS_FILTER: INTEGER [R,W] [Visible,Sticky] RANGE=0...7 DFLT=7
CAPTURE_WITHIN_INTERVAL: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
EVENT_FILTER_NUMBER: INTEGER [R,W] [Visible,Sticky] RANGE=1...15 DFLT=1
EVENT_FILTER_PERIOD: FLOAT [R,W] [Visible,Sticky] RANGE=0.5...7.5 DFLT=0.5 UNIT=s
LED_ONTIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...1.275 DFLT=0.5 UNIT=s
MIN_INTERVAL: INTEGER [R,W] [Visible,Sticky] RANGE=0...4 DFLT=4
Paramset VALUES
BRIGHTNESS: INTEGER [R,E] [Visible,Sticky] RANGE=0...255 DFLT=0
INSTALL_TEST: ACTION [E] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
MOTION: BOOL [R,E] [Visible,Sticky] RANGE=0...1 DFLT=0
Den SMI55 kann man lokal schalten, wäre da nicht "set SMI55 on" bzw. "set SMI55 off" möglich ?
Die Probleme sehe ich beim state. Da sind eigentlich 2 states nötig, 1x für die Schaltfunktion und 1x für den Bewegungsmelder.
Ein Problem, das u.a. auch beim HmIP-FSM16 und beim HMIP-PSM auftaucht.
In der CCU WebUI werden für unterschiedliche Funktionen eigene Einträge benutzt.
Eine Möglichkeit wäre state für die Hauptfunktion und estate für die Zusatzfunktion.
Zitat von: zap am 10 April 2021, 15:48:41
Zum HmIP-FSM16: Was meinst Du damit, dass Du ihn nicht siehst? Wenn Du im I/O Device den Befehl "get deviceInfo" auswählst, wird dann der HmIP-FSM16 in der Dropdown-Liste angezeigt?
get deviceInfo zeigt den HmIP-FSM16, ist aber weder HMCCUCHN noch in HMCCUDEV sichtbar.
Nochmals zur Verdeutlichung state / estate am Bespiel HMIP-PSM und dem funktionsähnlichen HM-ES-PMSw1-Pl
In CUL_HM wurde das so gelöst:
eState E: 38982 P: 48.65 I: 378 U: 234.4 f: 49.99
Ich hab versucht das für den HMIP-PSM nachzubauen:
substitute eState!.+:E 6.ENERGY_COUNTER P 6.POWER I 6.CURRENT U 6.VOLTAGE f 6.FREQUENCY
stateFormat E: 6.ENERGY_COUNTER P: 6.POWER I: 6.CURRENT U: 6.VOLTAGE f: 6.FREQUENCY
Raus kommt dann
STATE E: 73.6 P: 0.0 I: 0.0 U: 234.7 f: 50.0 in den Internals
eState 73.6
state on in den Readings
Schön wäre wenn eState E: 73.6 P: 0.0 I: 0.0 U: 234.7 f: 50.0 möglich wäre.
Die Internals Einträge möchte ich, wenn möglich nicht angreifen. Nach meinem Verständnis sind die Internals Einträge intern und primär für Modulentwickler.
Ganz generell sehe ich das Problem mit zunehmender Komplexität der HMIP Geräte wird es schwierig eine "flat" Darstellung in HMCCUDEV bzw. HMCCUCHN umzusetzen.
Ich will hier (nicht wieder) eine Designdiskussion lostreten aber wir werden so so eine Art "SubDevice" brauchen.
Eine Frage zu Logeinträgen.
Nach dem FHEM Update (ohne HMCCU Beta Module) und nach jedem shutdown/restart habe ich 194 Zeilen dieser Art im Log:
2021.04.11 12:06:39 1: PERL WARNING: Subroutine HMCCU_Initialize redefined at ./FHEM/88_HMCCU.pm line 359, <$fh> line 4339.
2021.04.11 12:06:39 1: PERL WARNING: Subroutine HMCCU_Define redefined at ./FHEM/88_HMCCU.pm line 392, <$fh> line 4339.
2021.04.11 12:06:39 1: PERL WARNING: Subroutine HMCCU_InitDevice redefined at ./FHEM/88_HMCCU.pm line 510, <$fh> line 4339.
2021.04.11 12:06:39 1: PERL WARNING: Subroutine HMCCU_PostInit redefined at ./FHEM/88_HMCCU.pm line 557, <$fh> line 4339.
2021.04.11 12:06:39 1: PERL WARNING: Subroutine HMCCU_Attr redefined at ./FHEM/88_HMCCU.pm line 581, <$fh> line 4339.
2021.04.11 12:06:39 1: PERL WARNING: Subroutine HMCCU_AggregationRules redefined at ./FHEM/88_HMCCU.pm line 659, <$fh> line 4339.
2021.04.11 12:06:39 1: PERL WARNING: Subroutine HMCCU_ExportDefaults redefined at ./FHEM/88_HMCCU.pm line 756, <$fh> line 4339.
usw. usw.
Aktuelle Version war die 4.4.064 aus GIT.
Hat das noch jemand von euch?
Eben noch ein Update auf RC2 4.4.065 gemacht, die Meldungen bleiben, es kommen neue hinzu:
2021.04.11 12:39:03 1: PERL WARNING: Use of uninitialized value $cc in string ne at ./FHEM/88_HMCCU.pm line 7398.
2021.04.11 12:39:03 2: N/A [HMCCU] HMCCU_SplitChnAddr:7571 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.11 12:39:03 2: HMCCU [CCU3] Address not defined for device
HMCCU_GetDeviceDesc:7573 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.11 12:39:03 1: PERL WARNING: Use of uninitialized value $address in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 7575.
2021.04.11 12:39:03 2: HMCCU [CCU3] Can't get device description for HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.11 12:39:03 2: N/A [HMCCU] HMCCU_SplitChnAddr:7571 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.11 12:39:03 2: HMCCU [CCU3] Address not defined for device
VG Helmut
By the way - diese Meldungen sind geblieben:
2021.04.11 12:26:13 1: PERL WARNING: Use of uninitialized value $devtype in hash element at ./FHEM/88_HMCCU.pm line 5733.
2021.04.11 12:26:13 1: PERL WARNING: Use of uninitialized value $devtype in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 5734.
Zitat von: dl4fbr am 11 April 2021, 12:28:51
By the way - diese Meldungen sind geblieben:
2021.04.11 12:26:13 1: PERL WARNING: Use of uninitialized value $devtype in hash element at ./FHEM/88_HMCCU.pm line 5733.
2021.04.11 12:26:13 1: PERL WARNING: Use of uninitialized value $devtype in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 5734.
Ist das Update tatsächlich korrekt ausgeführt worden? Irgendetwas ist da wohl schief gegangen, denn in Zeile 5733/5734 in der aktuellen Beta in SVN und Github steht folgendes:
HMCCU_Trace ($hash, 2, stacktraceAsString(undef));
return 0;Also kein $devtype weit und breit.
@1.fhemtester
Der SMI55 ist kein einfacher Schalter (an/aus). Ein einfacher Schalter schaltet nur einen Kanal. Er hat einen Kanal mit der Rolle SWITCH und einen Datenpunkt STATE, der die Zustände 0/1 bzw. false/true annehmen kann. Damit lässt sich ein set on/off abbilden.
Der SMI55 hingegen hat 2 getrennte Schaltkanäle mit den Rollen KEY/KEY_TRANSCEIVER und je einem Datenpunkt PRESS_SHORT. Für Kanäle mit dieser Rolle erzeugt HMCCU automatisch einen Befehl set press. Und genau hier liegt das Problem: Auf welchen der beiden KEY-Kanäle soll sich set press beziehen?
Die Lösung ist das, was Du als "SubDevice" bezeichnest. Das gibt es mit HMCCUCHN nämlich schon. Es ist ein Fehler, dass HMCCU für den SMI55 ein einziges HMCCUDEV Device anlegt. Mit diesem kann man das Gerät nur per "set datapoint" Befehl (relativ unkomfortabel) steuern. Beispiel:
set xy datapoint 1.PRESS_SHORT true => 1. Schaltkanal
set xy datapoint 2.PRESS_SHORT true => 2. Schaltkanal
Besser (und das wird im nächsten Update so umgesetzt werden) ist, dass ein "get create" oder "get createDev" in diesem Fall statt 1 HMCCUDEV 3 HMCCUCHN anlegt: Je eines für die beiden Tasten und ein weiteres für den Bewegungssensor.
Diese 3 HMCCUCHN Devices kann man sich dann mit FHEM Bordmitteln gruppieren oder zusammenfassen (z.B. mit readingsgroups).
Nochmal ein kurzer Ausflug in die Nomenklatur der CCU:
- Ein Gerät in der CCU hat mehrere Kanäle. Es kann in FHEM als HMCCUDEV abgebildet werden
- Jeder Kanal hat eine Rolle (z.B. MOTIONDETECTOR_TRANSCEIVER, SWITCH, DIMMER, ...). Er kann in FHEM als HMCCUCHN abgebildet werden.
- Mehrere Kanäle können die gleiche Rolle haben
- Jeder Kanal hat ein oder mehrere Parametersets, von denen wiederum jedes mehrere Datenpunkte enthält.
- Ein Datenpunkt beschreibt einen bestimmten Zustand. Auf Datenpunkte kann lesen und/oder schreibend zugegriffen werden.
HMCCU abstrahiert diese ganze Logik so weit, dass sich der Nutzer eigentlich nur mit Kanälen und Datenpunkten beschäftigen muss.
Ein Gerät hat also normalerweise sehr viele Datenpunkte. Die (wichtigsten) beschreibbaren Datenpunkte werden in HMCCU als set Befehle abgebildet, statt einem "set xy datapoint STATE 1" kann der Nutzer "set xy on" eingeben. Statt "set xy datapoint ON_TIME 10 STATE 1" genügt ein "set xy on-for-timer" usw.
Eine Erweiterung um mehrere state Readings macht m.E. wenig Sinn, da jeder Nutzer auf andere Readings Wert legt (manche Geräte liefern 10-20 Datenpunkte). Hier hilft dann entweder stateformat oder userreading weiter.
Zitat von: zap am 11 April 2021, 16:31:32
Ist das Update tatsächlich korrekt ausgeführt worden? Irgendetwas ist da wohl schief gegangen, denn in Zeile 5733/5734 in der aktuellen Beta in SVN und Github steht folgendes:
HMCCU_Trace ($hash, 2, stacktraceAsString(undef));
return 0;
Also kein $devtype weit und breit.
Hallo, ja ist wahrscheinlich mein Fehler gewesen. Ich habe jetzt das Log nach Neustart nochmal genau durchgesehen.
Hier Auszug vom Reading meiner CCU:
ccuname HM-RCV-50 BidCoS-RF
ccustate active
ccutype CCU2/3
config 4.8.025
host 192.168.178.37
prot http
version 4.4.065Hier Auszug aus der Datei auf meinem System unter /opt/fhem/FHEM/88_HMCCU.pm
# $Id: 88_HMCCU.pm 18745 2019-02-26 17:33:23Z zap $
#
# Version 4.4.065
#
# Module for communication between FHEM and Homematic CCU2/3.
#
# Supports BidCos-RF, BidCos-Wired, HmIP-RF, virtual CCU channels,
# CCU group devices, HomeGear, CUxD, Osram Lightify, Homematic Virtual Layer
# and Philips Hue (not tested)
#
# (c) 2021 by zap (zap01 <at> t-online <dot> de)
#
Nach shutdown/restart kommen folgende Warnings:
2021.04.11 17:32:09 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/88_HMCCU.pm line 6052.
2021.04.11 17:32:29 1: PERL WARNING: Use of uninitialized value $cc in string ne at ./FHEM/88_HMCCU.pm line 7398
2021.04.11 17:32:29 1: PERL WARNING: Use of uninitialized value $address in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 7575.
Etwas anders als vorher.
Hiervon 194 Meldungen
2021.04.11 17:32:09 1: PERL WARNING: Subroutine HMCCU_Initialize redefined at ./FHEM/88_HMCCU.pm line 359, <$fh> line 4339.Immer mit anderen lines in der HMCCU.pm
Hiervon 4 Meldungen:
2021.04.11 17:32:29 2: HMCCU [CCU3] Address not defined for device
HMCCU_GetDeviceDesc:7573 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.11 17:32:29 2: HMCCU [CCU3] Can't get device description for HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.11 17:32:29 2: N/A [HMCCU] HMCCU_SplitChnAddr:7571 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.11 17:32:29 2: HMCCU [CCU3] Address not defined for device
Stoppe mal FHEM, prüfe dann, ob noch irgendwelche fhem.pl Prozesse laufen. Falls ja, kille sie. Danach FHEM wieder starten.
Hast Du die fhem.cfg manuell editiert?
Hallo zap,
FHEM habe ich gestoppt, es war kein weiterer Prozess am Laufen.
KORREKTUR:
pi@fhem:/opt/fhem $ ps -fC perl
UID PID PPID C STIME TTY TIME CMD
fhem 819 1 44 12:40 ? 00:00:17 /usr/bin/perl fhem.pl fhem.cfg
fhem 832 819 3 12:41 ? 00:00:00 /usr/bin/perl fhem.pl fhem.cfg
Es laufen bei mir immer 2 fhem/perl Prozesse. Was ist das denn?
Ja, ich habe die fhem.cfg schon mit dem FHEM eigenen Editor bzw. nano bearbeitet.
Nie mit einem Windows Programm. Es gibt keinen "CR" irgendwo, noch Sonderzeichen <0a oder zw. 0e und 1f, alles größer 7f sind die deut. Sonderzeichen
Aktueller Logauszug, Filter auf "HMCCU"
Die HM_Taster_1 bis 4 sind in FHEM noch definiert, in der CCU gelöscht, da defekt. Ich will bis zum Austausch durch ELV die Definition behalten. Ist das ein Problem?
2021.04.12 12:05:17 2: HMCCUCHN [HM_Taster_2] Cannot detect IO device, maybe CCU not ready. Trying later ...
2021.04.12 12:05:17 2: HMCCUCHN [HM_Taster_3] Cannot detect IO device, maybe CCU not ready. Trying later ...
2021.04.12 12:05:17 2: HMCCUCHN [HM_Taster_4] Cannot detect IO device, maybe CCU not ready. Trying later ...
2021.04.12 12:05:17 2: HMCCUCHN [HM_Taster_1] Cannot detect IO device, maybe CCU not ready. Trying later ...
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_Initialize redefined at ./FHEM/88_HMCCU.pm line 359, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_Define redefined at ./FHEM/88_HMCCU.pm line 392, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_InitDevice redefined at ./FHEM/88_HMCCU.pm line 510, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_PostInit redefined at ./FHEM/88_HMCCU.pm line 557, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_Attr redefined at ./FHEM/88_HMCCU.pm line 581, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_AggregationRules redefined at ./FHEM/88_HMCCU.pm line 659, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_ExportDefaults redefined at ./FHEM/88_HMCCU.pm line 756, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_ImportDefaults redefined at ./FHEM/88_HMCCU.pm line 807, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_FindDefaults redefined at ./FHEM/88_HMCCU.pm line 864, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_SetDefaultsTemplate redefined at ./FHEM/88_HMCCU.pm line 902, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_SetDefaults redefined at ./FHEM/88_HMCCU.pm line 920, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_GetDefaults redefined at ./FHEM/88_HMCCU.pm line 936, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_Notify redefined at ./FHEM/88_HMCCU.pm line 1009, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_Detail redefined at ./FHEM/88_HMCCU.pm line 1087, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_AggregateReadings redefined at ./FHEM/88_HMCCU.pm line 1114, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_Undef redefined at ./FHEM/88_HMCCU.pm line 1214, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_DelayedShutdown redefined at ./FHEM/88_HMCCU.pm line 1238, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_Shutdown redefined at ./FHEM/88_HMCCU.pm line 1262, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_Set redefined at ./FHEM/88_HMCCU.pm line 1285, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_Get redefined at ./FHEM/88_HMCCU.pm line 1634, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_ParseObject redefined at ./FHEM/88_HMCCU.pm line 1991, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_FilterReading redefined at ./FHEM/88_HMCCU.pm line 2130, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_GetReadingName redefined at ./FHEM/88_HMCCU.pm line 2246, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_FormatReadingValue redefined at ./FHEM/88_HMCCU.pm line 2382, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_StripNumber redefined at ./FHEM/88_HMCCU.pm line 2427, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_Trace redefined at ./FHEM/88_HMCCU.pm line 2451, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_LogDisplay redefined at ./FHEM/88_HMCCU.pm line 2475, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_Log redefined at ./FHEM/88_HMCCU.pm line 2496, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_LogError redefined at ./FHEM/88_HMCCU.pm line 2533, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_SetError redefined at ./FHEM/88_HMCCU.pm line 2548, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_SetState redefined at ./FHEM/88_HMCCU.pm line 2595, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_SetRPCState redefined at ./FHEM/88_HMCCU.pm line 2618, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_Substitute redefined at ./FHEM/88_HMCCU.pm line 2698, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_SubstRule redefined at ./FHEM/88_HMCCU.pm line 2799, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_SubstVariables redefined at ./FHEM/88_HMCCU.pm line 2846, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_UpdateClients redefined at ./FHEM/88_HMCCU.pm line 2893, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_UpdateDeviceTable redefined at ./FHEM/88_HMCCU.pm line 2978, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_ResetDeviceTables redefined at ./FHEM/88_HMCCU.pm line 3120, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_CreateDevice redefined at ./FHEM/88_HMCCU.pm line 3161, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_MakeDeviceName redefined at ./FHEM/88_HMCCU.pm line 3206, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_AddDevice redefined at ./FHEM/88_HMCCU.pm line 3226, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_RemoveDevice redefined at ./FHEM/88_HMCCU.pm line 3259, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_UpdateDevice redefined at ./FHEM/88_HMCCU.pm line 3282, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_UpdateDeviceRoles redefined at ./FHEM/88_HMCCU.pm line 3372, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_RenameDevice redefined at ./FHEM/88_HMCCU.pm line 3415, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_SetSCAttributes redefined at ./FHEM/88_HMCCU.pm line 3447, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_GetChannelRole redefined at ./FHEM/88_HMCCU.pm line 3504, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_GetDeviceConfig redefined at ./FHEM/88_HMCCU.pm line 3531, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_AddDeviceDesc redefined at ./FHEM/88_HMCCU.pm line 3620, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_GetDeviceDesc redefined at ./FHEM/88_HMCCU.pm line 3669, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_GetDeviceIdentifier redefined at ./FHEM/88_HMCCU.pm line 3703, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_DeviceDescToStr redefined at ./FHEM/88_HMCCU.pm line 3734, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_ParamsetDescToStr redefined at ./FHEM/88_HMCCU.pm line 3783, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_GetDeviceAddresses redefined at ./FHEM/88_HMCCU.pm line 3849, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_ExistsDeviceModel redefined at ./FHEM/88_HMCCU.pm line 3902, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_CloneDeviceModel redefined at ./FHEM/88_HMCCU.pm line 3917, <$fh> line 4338.
2021.04.12 12:05:19 1: PERL WARNING: Subroutine HMCCU_AddDeviceModel redefined at ./FHEM/88_HMCCU.pm line 3933, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetDeviceModel redefined at ./FHEM/88_HMCCU.pm line 3969, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetClientDeviceModel redefined at ./FHEM/88_HMCCU.pm line 3993, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetParamDef redefined at ./FHEM/88_HMCCU.pm line 4021, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_FindParamDef redefined at ./FHEM/88_HMCCU.pm line 4059, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IsValidParameter redefined at ./FHEM/88_HMCCU.pm line 4092, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetParamValueConversion redefined at ./FHEM/88_HMCCU.pm line 4131, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_AddPeers redefined at ./FHEM/88_HMCCU.pm line 4161, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetReceivers redefined at ./FHEM/88_HMCCU.pm line 4183, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IsValidReceiver redefined at ./FHEM/88_HMCCU.pm line 4199, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_FlagsToStr redefined at ./FHEM/88_HMCCU.pm line 4219, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_UpdateSingleDatapoint redefined at ./FHEM/88_HMCCU.pm line 4274, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_UpdateParamsetReadings redefined at ./FHEM/88_HMCCU.pm line 4299, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_RefreshReadings redefined at ./FHEM/88_HMCCU.pm line 4444, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_UpdateInternalValues redefined at ./FHEM/88_HMCCU.pm line 4479, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_UpdateMultipleDevices redefined at ./FHEM/88_HMCCU.pm line 4526, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetAffectedAddresses redefined at ./FHEM/88_HMCCU.pm line 4564, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_UpdatePeers redefined at ./FHEM/88_HMCCU.pm line 4602, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetRPCInterfaceList redefined at ./FHEM/88_HMCCU.pm line 4656, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_EventsTimedOut redefined at ./FHEM/88_HMCCU.pm line 4692, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetRPCCallbackURL redefined at ./FHEM/88_HMCCU.pm line 4731, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetRPCServerInfo redefined at ./FHEM/88_HMCCU.pm line 4761, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IsRPCType redefined at ./FHEM/88_HMCCU.pm line 4791, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_StartExtRPCServer redefined at ./FHEM/88_HMCCU.pm line 4806, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_StopExtRPCServer redefined at ./FHEM/88_HMCCU.pm line 4873, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IsRPCStateBlocking redefined at ./FHEM/88_HMCCU.pm line 4905, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IsRPCServerRunning redefined at ./FHEM/88_HMCCU.pm line 4921, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetDeviceInfo redefined at ./FHEM/88_HMCCU.pm line 4948, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_FormatDeviceInfo redefined at ./FHEM/88_HMCCU.pm line 4985, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetFirmwareVersions redefined at ./FHEM/88_HMCCU.pm line 5021, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetDevice redefined at ./FHEM/88_HMCCU.pm line 5093, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetInterfaceList redefined at ./FHEM/88_HMCCU.pm line 5155, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetDeviceList redefined at ./FHEM/88_HMCCU.pm line 5194, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetDatapointList redefined at ./FHEM/88_HMCCU.pm line 5389, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IsValidDeviceOrChannel redefined at ./FHEM/88_HMCCU.pm line 5460, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IsValidDevice redefined at ./FHEM/88_HMCCU.pm line 5473, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IsValidChannel redefined at ./FHEM/88_HMCCU.pm line 5516, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetCCUDeviceParam redefined at ./FHEM/88_HMCCU.pm line 5555, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetValidDatapoints redefined at ./FHEM/88_HMCCU.pm line 5602, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetDatapointAttr redefined at ./FHEM/88_HMCCU.pm line 5646, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_FindDatapoint redefined at ./FHEM/88_HMCCU.pm line 5667, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IsValidDatapoint redefined at ./FHEM/88_HMCCU.pm line 5709, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetMatchingDevices redefined at ./FHEM/88_HMCCU.pm line 5763, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetDeviceName redefined at ./FHEM/88_HMCCU.pm line 5785, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetChannelName redefined at ./FHEM/88_HMCCU.pm line 5802, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetDeviceType redefined at ./FHEM/88_HMCCU.pm line 5819, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetDefaultInterface redefined at ./FHEM/88_HMCCU.pm line 5835, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetDeviceInterface redefined at ./FHEM/88_HMCCU.pm line 5858, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetAddress redefined at ./FHEM/88_HMCCU.pm line 5880, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetGroupMembers redefined at ./FHEM/88_HMCCU.pm line 5947, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IsChnAddr redefined at ./FHEM/88_HMCCU.pm line 5960, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IsDevAddr redefined at ./FHEM/88_HMCCU.pm line 5983, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_SplitChnAddr redefined at ./FHEM/88_HMCCU.pm line 6006, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_SplitDatapoint redefined at ./FHEM/88_HMCCU.pm line 6022, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_FindClientDevices redefined at ./FHEM/88_HMCCU.pm line 6041, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_ExistsClientDevice redefined at ./FHEM/88_HMCCU.pm line 6075, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetRPCDevice redefined at ./FHEM/88_HMCCU.pm line 6100, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_CreateRPCDevice redefined at ./FHEM/88_HMCCU.pm line 6146, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_AssignIODevice redefined at ./FHEM/88_HMCCU.pm line 6191, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_FindIODevice redefined at ./FHEM/88_HMCCU.pm line 6218, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IODeviceStates redefined at ./FHEM/88_HMCCU.pm line 6238, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetHash redefined at ./FHEM/88_HMCCU.pm line 6265, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetAttribute redefined at ./FHEM/88_HMCCU.pm line 6293, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_SetDefaultAttributes redefined at ./FHEM/88_HMCCU.pm line 6308, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetStateValues redefined at ./FHEM/88_HMCCU.pm line 6355, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_UpdateRoleCommands redefined at ./FHEM/88_HMCCU.pm line 6425, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_UpdateAdditionalCommands redefined at ./FHEM/88_HMCCU.pm line 6590, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_ExecuteRoleCommand redefined at ./FHEM/88_HMCCU.pm line 6610, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_ExecuteSetClearCommand redefined at ./FHEM/88_HMCCU.pm line 6764, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_ExecuteSetDatapointCommand redefined at ./FHEM/88_HMCCU.pm line 6785, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_ExecuteSetParameterCommand redefined at ./FHEM/88_HMCCU.pm line 6842, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_ExecuteToggleCommand redefined at ./FHEM/88_HMCCU.pm line 6926, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_ExecuteGetDeviceInfoCommand redefined at ./FHEM/88_HMCCU.pm line 6966, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_ExecuteGetParameterCommand redefined at ./FHEM/88_HMCCU.pm line 7021, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_DisplayGetParameterResult redefined at ./FHEM/88_HMCCU.pm line 7065, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_DisplayWeekProgram redefined at ./FHEM/88_HMCCU.pm line 7094, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_CheckParameter redefined at ./FHEM/88_HMCCU.pm line 7135, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_SetSCDatapoints redefined at ./FHEM/88_HMCCU.pm line 7190, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_SetDefaultSCDatapoints redefined at ./FHEM/88_HMCCU.pm line 7241, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetSCDatapoints redefined at ./FHEM/88_HMCCU.pm line 7285, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_DetectSCAttr redefined at ./FHEM/88_HMCCU.pm line 7342, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_DetectSCChn redefined at ./FHEM/88_HMCCU.pm line 7404, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_DetectSCDev redefined at ./FHEM/88_HMCCU.pm line 7430, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_DetectDevice redefined at ./FHEM/88_HMCCU.pm line 7565, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IdentifyRole redefined at ./FHEM/88_HMCCU.pm line 7691, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetSCInfo redefined at ./FHEM/88_HMCCU.pm line 7718, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_DetectSCDatapoint redefined at ./FHEM/88_HMCCU.pm line 7738, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetFlags redefined at ./FHEM/88_HMCCU.pm line 7759, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IsFlag redefined at ./FHEM/88_HMCCU.pm line 7772, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetAttrReadingFormat redefined at ./FHEM/88_HMCCU.pm line 7786, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetAttrStripNumber redefined at ./FHEM/88_HMCCU.pm line 7807, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetAttrSubstitute redefined at ./FHEM/88_HMCCU.pm line 7838, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_HMCommand redefined at ./FHEM/88_HMCCU.pm line 7855, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_HMCommandNB redefined at ./FHEM/88_HMCCU.pm line 7897, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_HMCommandCB redefined at ./FHEM/88_HMCCU.pm line 7926, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_HMScriptExt redefined at ./FHEM/88_HMCCU.pm line 7948, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_BulkUpdate redefined at ./FHEM/88_HMCCU.pm line 8044, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetDatapoint redefined at ./FHEM/88_HMCCU.pm line 8059, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_SetMultipleParameters redefined at ./FHEM/88_HMCCU.pm line 8114, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_SetMultipleDatapoints redefined at ./FHEM/88_HMCCU.pm line 8143, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_ScaleValue redefined at ./FHEM/88_HMCCU.pm line 8243, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetVariables redefined at ./FHEM/88_HMCCU.pm line 8345, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_UpdateVariables redefined at ./FHEM/88_HMCCU.pm line 8375, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_SetVariable redefined at ./FHEM/88_HMCCU.pm line 8393, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetUpdate redefined at ./FHEM/88_HMCCU.pm line 8438, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_UpdateCB redefined at ./FHEM/88_HMCCU.pm line 8505, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_RPCRequest redefined at ./FHEM/88_HMCCU.pm line 8561, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_SetIfDef redefined at ./FHEM/88_HMCCU.pm line 8684, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_SetIfEx redefined at ./FHEM/88_HMCCU.pm line 8685, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_SetVal redefined at ./FHEM/88_HMCCU.pm line 8686, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_DefStr redefined at ./FHEM/88_HMCCU.pm line 8693, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_Unique redefined at ./FHEM/88_HMCCU.pm line 8706, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_ISO2UTF redefined at ./FHEM/88_HMCCU.pm line 8716, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IsFltNum redefined at ./FHEM/88_HMCCU.pm line 8727, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_IsIntNum redefined at ./FHEM/88_HMCCU.pm line 8741, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_UpdateDeviceStates redefined at ./FHEM/88_HMCCU.pm line 8754, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetHMState redefined at ./FHEM/88_HMCCU.pm line 8812, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetTimeSpec redefined at ./FHEM/88_HMCCU.pm line 8864, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_Min redefined at ./FHEM/88_HMCCU.pm line 8886, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_Max redefined at ./FHEM/88_HMCCU.pm line 8897, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_BuildURL redefined at ./FHEM/88_HMCCU.pm line 8911, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_CalculateReading redefined at ./FHEM/88_HMCCU.pm line 8957, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_Encrypt redefined at ./FHEM/88_HMCCU.pm line 9097, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_Decrypt redefined at ./FHEM/88_HMCCU.pm line 9121, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_DeleteReadings redefined at ./FHEM/88_HMCCU.pm line 9147, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_UpdateReadings redefined at ./FHEM/88_HMCCU.pm line 9164, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_EncodeEPDisplay redefined at ./FHEM/88_HMCCU.pm line 9199, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_RefToString redefined at ./FHEM/88_HMCCU.pm line 9290, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_BitsToStr redefined at ./FHEM/88_HMCCU.pm line 9322, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_AdjustValue redefined at ./FHEM/88_HMCCU.pm line 9335, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_ExprMatch redefined at ./FHEM/88_HMCCU.pm line 9350, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_ExprNotMatch redefined at ./FHEM/88_HMCCU.pm line 9358, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetDutyCycle redefined at ./FHEM/88_HMCCU.pm line 9370, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_TCPPing redefined at ./FHEM/88_HMCCU.pm line 9406, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_TCPConnect redefined at ./FHEM/88_HMCCU.pm line 9430, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_GetIdFromIP redefined at ./FHEM/88_HMCCU.pm line 9448, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_ResolveName redefined at ./FHEM/88_HMCCU.pm line 9461, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_CorrectName redefined at ./FHEM/88_HMCCU.pm line 9474, <$fh> line 4338.
2021.04.12 12:05:20 1: PERL WARNING: Subroutine HMCCU_MaxHashEntries redefined at ./FHEM/88_HMCCU.pm line 9490, <$fh> line 4338.
2021.04.12 12:05:20 1: HMCCU [CCU3] CCU port 8181 is reachable
2021.04.12 12:05:20 1: HMCCU [CCU3] Initialized version 4.4.065
2021.04.12 12:05:20 1: HMCCU [CCU3] Initializing device
2021.04.12 12:05:20 2: HMCCU [CCU3] Updating device table
2021.04.12 12:05:20 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/88_HMCCU.pm line 6052.
2021.04.12 12:05:20 1: HMCCU [CCU3] Read 3 devices with 104 channels from CCU 192.168.178.37
2021.04.12 12:05:20 1: HMCCU [CCU3] Read 8 programs from CCU 192.168.178.37
2021.04.12 12:05:20 1: HMCCU [CCU3] Read 0 virtual groups from CCU 192.168.178.37
2021.04.12 12:05:20 1: HMCCURPCPROC [d_rpc178037BidCos_RF] Initialized version 4.4.013 for interface BidCos-RF with I/O device CCU3
2021.04.12 12:05:20 1: HMCCURPCPROC [d_rpc178037HmIP_RF] Initialized version 4.4.013 for interface HmIP-RF with I/O device CCU3
2021.04.12 12:05:26 0: HMCCU [CCU3] Scheduling post FHEM initialization tasks in 12 seconds
2021.04.12 12:05:38 1: HMCCU [CCU3] Reading device config from CCU. This may take a couple of seconds ...
2021.04.12 12:05:38 2: HMCCU [CCU3] Reading Device Descriptions for interface HmIP-RF
2021.04.12 12:05:38 2: HMCCU [CCU3] Read 55 Device Descriptions for interface HmIP-RF
2021.04.12 12:05:38 2: HMCCU [CCU3] Reading Paramset Descriptions for interface HmIP-RF
2021.04.12 12:05:40 2: HMCCU [CCU3] Read 55 Paramset Descriptions for interface HmIP-RF
2021.04.12 12:05:40 2: HMCCU [CCU3] Reading Peer Descriptions for interface HmIP-RF
2021.04.12 12:05:40 2: HMCCU [CCU3] Read 0 Peer Descriptions for interface HmIP-RF
2021.04.12 12:05:40 1: PERL WARNING: Use of uninitialized value $cc in string ne at ./FHEM/88_HMCCU.pm line 7398.
2021.04.12 12:05:40 2: N/A [HMCCU] HMCCU_SplitChnAddr:7571 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.12 12:05:40 2: HMCCU [CCU3] Address not defined for device
HMCCU_GetDeviceDesc:7573 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.12 12:05:40 1: PERL WARNING: Use of uninitialized value $address in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 7575.
2021.04.12 12:05:40 2: HMCCU [CCU3] Can't get device description for HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.12 12:05:40 2: N/A [HMCCU] HMCCU_SplitChnAddr:7571 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.12 12:05:40 2: HMCCU [CCU3] Address not defined for device
HMCCU_GetDeviceDesc:7573 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.12 12:05:40 2: HMCCU [CCU3] Can't get device description for HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.12 12:05:40 2: N/A [HMCCU] HMCCU_SplitChnAddr:7571 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.12 12:05:40 2: HMCCU [CCU3] Address not defined for device
HMCCU_GetDeviceDesc:7573 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.12 12:05:40 2: HMCCU [CCU3] Can't get device description for HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.12 12:05:40 2: N/A [HMCCU] HMCCU_SplitChnAddr:7571 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.12 12:05:40 2: HMCCU [CCU3] Address not defined for device
HMCCU_GetDeviceDesc:7573 HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.12 12:05:40 2: HMCCU [CCU3] Can't get device description for HMCCU_DetectDevice:7244 HMCCU_SetDefaultSCDatapoints:7302 HMCCU_GetSCDatapoints:3598 HMCCU_GetDeviceConfig:566 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.12 12:05:40 2: HMCCU [CCU3] Read device configuration: devices/channels=55 parametersets=55 links=0
2021.04.12 12:05:40 2: HMCCU [CCU3] Get RPC device for interface HmIP-RF
2021.04.12 12:05:40 2: HMCCURPCPROC [d_rpc178037HmIP_RF] RPC server process started for interface HmIP-RF with PID=746
2021.04.12 12:05:40 1: HMCCURPCPROC [d_rpc178037HmIP_RF] RPC server starting
2021.04.12 12:05:40 2: HMCCURPCPROC [d_rpc178037HmIP_RF] Initializing RPC server CB2010178086178037 for interface HmIP-RF
2021.04.12 12:05:40 2: HMCCURPCPROC [d_rpc178037HmIP_RF] Callback server CB2010178086178037 created. Listening on port 7420
2021.04.12 12:05:40 2: HMCCURPCPROC [d_rpc178037HmIP_RF] CB2010178086178037 accepting connections. PID=746
2021.04.12 12:05:40 2: HMCCURPCPROC [d_rpc178037HmIP_RF] RPC server CB2010178086178037 enters server loop
2021.04.12 12:05:40 2: HMCCURPCPROC [d_rpc178037HmIP_RF] Registering callback http://192.168.178.86:7420/fh2010 of type A with ID CB2010178086178037 at http://192.168.178.37:2010
2021.04.12 12:05:40 1: HMCCURPCPROC [d_rpc178037HmIP_RF] RPC server CB2010178086178037 running
2021.04.12 12:05:40 1: HMCCU [CCU3] All RPC servers running
2021.04.12 12:05:40 2: HMCCU [CCU3] Updating 1 of 1 client devices matching devexp=.* filter=ccudevstate=active,ccuif=HmIP-RF
2021.04.12 12:05:40 2: HMCCU [CCU3] Update success=1 failed=0
2021.04.12 12:05:40 2: HMCCURPCPROC [d_rpc178037HmIP_RF] CB2010178086178037 NewDevice received 55 device and channel specifications
Ich könnte die 4 HMCCU Module manuell löschen und neu runterladen aus git?
ZitatJa, ich habe die fhem.cfg schon mit dem FHEM eigenen Editor bzw. nano bearbeitet.
Nie mit einem Windows Programm. Es gibt keinen "CR" irgendwo, noch Sonderzeichen <0a oder zw. 0e und 1f, alles größer 7f sind die deut. Sonderzeichen
je nachdem, was man dort macht, braucht es anschliessend
zusätzlich ein fhem restart.
Ja, das ist klar.
Ich würde mal gerne über Geräte wie z.B. die BDTs diskutieren.
Die sehen derzeit so aus:
DEV HM-Licht-OG-Badezimmer xxxxx interface=HmIP-RF type=HmIP-BDT
CHN xxxxx:0 HM-Licht-OG-Badezimmer:0
DPT {f} HmIP-RF.xxxxx:0.ACTUAL_TEMPERATURE = 0.000000 [RE]
DPT {b} HmIP-RF.xxxxx:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.xxxxx:0.DUTY_CYCLE = false [RE]
DPT {n} HmIP-RF.xxxxx:0.ERROR_CODE = 0 [RE]
DPT {b} HmIP-RF.xxxxx:0.ERROR_OVERHEAT = false [RE]
DPT {b} HmIP-RF.xxxxx:0.ERROR_OVERLOAD = false [RE]
DPT {b} HmIP-RF.xxxxx:0.ERROR_UPDATE = false [RE]
DPT {f} HmIP-RF.xxxxx:0.OPERATING_VOLTAGE = 0.000000 [RE]
DPT {n} HmIP-RF.xxxxx:0.RSSI_DEVICE = 186 [RE]
DPT {n} HmIP-RF.xxxxx:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.xxxxx:0.UNREACH = false [RE]
DPT {b} HmIP-RF.xxxxx:0.UPDATE_PENDING = false [RE]
CHN xxxxx:1 HmIP-BDT xxxxx:1
DPT {b} HmIP-RF.xxxxx:1.PRESS_LONG = [E]
DPT {b} HmIP-RF.xxxxx:1.PRESS_SHORT = [E]
CHN xxxxx:2 HmIP-BDT xxxxx:2
DPT {b} HmIP-RF.xxxxx:2.PRESS_LONG = [E]
DPT {b} HmIP-RF.xxxxx:2.PRESS_SHORT = [E]
CHN xxxxx:3 HmIP-BDT xxxxx:3
DPT {a} HmIP-RF.xxxxx:3.LEVEL = 0.000000 [RE]
DPT {i} HmIP-RF.xxxxx:3.PROCESS = 0 [RE]
DPT {i} HmIP-RF.xxxxx:3.SECTION = 15 [RE]
CHN xxxxx:4 HmIP-BDT xxxxx:4
DPT {a} HmIP-RF.xxxxx:4.LEVEL = 0.000000 [RWE]
DPT {f} HmIP-RF.xxxxx:4.ON_TIME = [W]
DPT {i} HmIP-RF.xxxxx:4.PROCESS = 0 [RE]
DPT {f} HmIP-RF.xxxxx:4.RAMP_TIME = [W]
DPT {i} HmIP-RF.xxxxx:4.SECTION = 0 [RE]
CHN xxxxx:5 HmIP-BDT xxxxx:5
DPT {a} HmIP-RF.xxxxx:5.LEVEL = 0.000000 [RWE]
DPT {f} HmIP-RF.xxxxx:5.ON_TIME = [W]
DPT {i} HmIP-RF.xxxxx:5.PROCESS = 0 [RE]
DPT {f} HmIP-RF.xxxxx:5.RAMP_TIME = [W]
DPT {i} HmIP-RF.xxxxx:5.SECTION = 0 [RE]
CHN xxxxx:6 HmIP-BDT xxxxx:6
DPT {a} HmIP-RF.xxxxx:6.LEVEL = 0.000000 [RWE]
DPT {f} HmIP-RF.xxxxx:6.ON_TIME = [W]
DPT {i} HmIP-RF.xxxxx:6.PROCESS = 0 [RE]
DPT {f} HmIP-RF.xxxxx:6.RAMP_TIME = [W]
DPT {i} HmIP-RF.xxxxx:6.SECTION = 0 [RE]
CHN xxxxx:7 HmIP-BDT xxxxx:7
DPT {i} HmIP-RF.xxxxx:7.WEEK_PROGRAM_CHANNEL_LOCKS = 0 [RE]
DPT {i} HmIP-RF.xxxxx:7.WEEK_PROGRAM_TARGET_CHANNEL_LOCK = [W]
DPT {i} HmIP-RF.xxxxx:7.WEEK_PROGRAM_TARGET_CHANNEL_LOCKS = [W]
Device detection:
StateDatapoint = 1.PRESS_SHORT [KEY_TRANSCEIVER]
StateDatapoint = 4.LEVEL [DIMMER_VIRTUAL_RECEIVER]
StateDatapoint = 5.LEVEL [DIMMER_VIRTUAL_RECEIVER]
StateDatapoint = 6.LEVEL [DIMMER_VIRTUAL_RECEIVER]
StateDatapoint = 2.PRESS_SHORT [KEY_TRANSCEIVER]
ControlDatapoint = 4.LEVEL [DIMMER_VIRTUAL_RECEIVER]
ControlDatapoint = 5.LEVEL [DIMMER_VIRTUAL_RECEIVER]
ControlDatapoint = 6.LEVEL [DIMMER_VIRTUAL_RECEIVER]
Recommended module for device definition: HMCCUDEV
Current state datapoint = 4.LEVEL
Current control datapoint = 4.LEVEL
Macht es Sinn, dass der state datapoint auf 4.LEVEL steht?
So kann ich in diesem Device ja 4.LEVEL, 5.LEVEL und 6.LEVEL ändern. Der daraus kombinierte Level steht dann in 3.LEVEL.
Wenn aber der BDT, so wie im Modul vorgeschlagen, als HMCCUDEV angelegt wird, wird der state halt u.U. nicht richtig dargestellt: 4.LEVEL steht auf 0, 5.LEVEL auf 100, aber als state für das Device wird 4.LEVEL, also 0, angezeigt. Der richtige Wert, in Abhängigkeit von den Einstellungen im Gerät, könnte aber 5.LEVEL, also 100, sein. Der richtige Werte würde in 3.LEVEL angezeigt werden.
Macht es also nicht eigentlich Sinn, wenn der state datapoint per default auf 3.LEVEL gestellt wird?
Oder habe ich einen Denkfehler?
Zitat von: zap am 11 April 2021, 16:58:13
Besser (und das wird im nächsten Update so umgesetzt werden) ist, dass ein "get create" oder "get createDev" in diesem Fall statt 1 HMCCUDEV 3 HMCCUCHN anlegt: Je eines für die beiden Tasten und ein weiteres für den Bewegungssensor.
Diese 3 HMCCUCHN Devices kann man sich dann mit FHEM Bordmitteln gruppieren oder zusammenfassen (z.B. mit readingsgroups).
Nochmal ein kurzer Ausflug in die Nomenklatur der CCU:
- Ein Gerät in der CCU hat mehrere Kanäle. Es kann in FHEM als HMCCUDEV abgebildet werden
- Jeder Kanal hat eine Rolle (z.B. MOTIONDETECTOR_TRANSCEIVER, SWITCH, DIMMER, ...). Er kann in FHEM als HMCCUCHN abgebildet werden.
- Mehrere Kanäle können die gleiche Rolle haben
- Jeder Kanal hat ein oder mehrere Parametersets, von denen wiederum jedes mehrere Datenpunkte enthält.
- Ein Datenpunkt beschreibt einen bestimmten Zustand. Auf Datenpunkte kann lesen und/oder schreibend zugegriffen werden.
HMCCU abstrahiert diese ganze Logik so weit, dass sich der Nutzer eigentlich nur mit Kanälen und Datenpunkten beschäftigen muss.
Ein Gerät hat also normalerweise sehr viele Datenpunkte. Die (wichtigsten) beschreibbaren Datenpunkte werden in HMCCU als set Befehle abgebildet, statt einem "set xy datapoint STATE 1" kann der Nutzer "set xy on" eingeben. Statt "set xy datapoint ON_TIME 10 STATE 1" genügt ein "set xy on-for-timer" usw.
Eine Erweiterung um mehrere state Readings macht m.E. wenig Sinn, da jeder Nutzer auf andere Readings Wert legt (manche Geräte liefern 10-20 Datenpunkte). Hier hilft dann entweder stateformat oder userreading weiter.
3 x HMCCUCHN für SMI55 find ich gut. Das erspart natürlich einen eState.
Soweit ich gesehen habe, wenn man nur einen Kanal verwendet, macht der SMI55 ein toggle, verwendet man beide ein/aus.
Ist da zukünftig eine Unterstützung zur Verbindung SMI55 mit z.B. FSM16 geplant oder bleibt das in der CCU WebUI ?
Machst du mehrere HMCCUCHN auch für HMIP-PSM und verwandte ?
Der zum HmIP-FSM16 funktionsähnliche HMIP-PSM hat ja zusätzlich ein Wochenprogramm aber keine lokale Bedienung per Taste. Beide sind Schaltaktuatoren mit Messfunktion.
Die Umsetzung stell ich mir mit dem generischen Ansatz eher schwierig vor.
Was empfiehlst du zwischenzeitlich für die manuelle Konfiguration des HmIP-FSM16 ?
Ich habe ein Update eingecheckt (SVN Contrib und Github):
Änderungen (s.a. https://github.com/zapccu/HMCCU/issues?q=is%3Aissue+is%3Aclosed+milestone%3A%22RC3+4.4.066%22)
- Die Befehle für die Aktivierung/Deaktivierung der Bewegungserkennung bei Bewegungs- und Präsenzmelder wurden geändert. Statt "set on/off" wird nun "set detection active/inactive" bereitgestellt. Das zugehörige Reading heißt "detection". Hinweis: Nicht alle Bewegungsmelder lassen eine Deaktivierung der Erkennung zu.
- Das Verbose-Level für Warnings bei Nicht-Verfügbarkeit der CCU beim FHEM-Start wurde von 2 auf 3 geändert
- Ein Perl-Fehler in der Funktion HMCCU_SetSCAttributes wurde behoben
- Die automatische Device-Erkennung bei den Befehlen "get create" und "get createDev" unterstützt nun die Gerätetypen HM-SEN-MDIRxxx und HM-CC-VD bzw. die Rollen "MOTION_DETECTOR" und "CLIMATECONTROL_VENT_DRIVE"
- Geräte vom Typ HmIP-SMI55 werden nun von "get create" und "get createDev" als 3 HMCCUCHN Devices in FHEM angelegt @1.fhemtester: Kannst Du das bitte mal testen?
- Im I/O Device gibt es ein neues Attribut "ccudef-attributes". Die hier angegebenen Attribute werden neu definierten HMCCUCHN oder HMCCUDEV Devices automatisch zugewiesen. Default ist "room=Homematic". Beispiel: "room=Homematic,group=Licht" (das Trennzeichen zwischen den Attributen wird in der nächsten Version auf ; geändert)
- Der I/O Device Befehl "get ccuDevices" zeigt nun in der letzten Spalte die Rollen an, die für ein Gerät von den Befehlen "get create" und "get createDev" unterstützt werden
@zap:
Danke für die neue Version.
Habe nochmals eine grundsätzliche Frage. Wenn ich bei FHEM ein shutdown restart durchführe, dann wird mein HMCCU-Device nicht automatisch gestartet. Wo muss ich was einstellen, damit dies automatisch erfolgt?
Gruß und schönes Wochenende
eurofinder
Hallo zap,
ich habe weiterhin diese Meldungen:
2021.04.16 17:02:21 2: HMCCU [HMCCU3] Can't get device description for 0000DA498D425C HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:380 HMCCUDEV_Set:3847 CallFn:1927 DoSet:1969 CommandSet:2804 getAllSets:104 CommandJsonList2:1265 AnalyzeCommand:1116 AnalyzeCommandChain:2764 FW_fC:962 FW_answerCall:597 FW_Read:3847 CallFn:773
2021.04.16 17:02:21 2: HMCCU [HMCCU3] Can't get device description for 0000DA498D427A HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:380 HMCCUDEV_Set:3847 CallFn:1927 DoSet:1969 CommandSet:2804 getAllSets:104 CommandJsonList2:1265 AnalyzeCommand:1116 AnalyzeCommandChain:2764 FW_fC:962 FW_answerCall:597 FW_Read:3847 CallFn:773
2021.04.16 17:02:21 2: HMCCU [HMCCU3] Can't get device description for 0000DA498D4303 HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:380 HMCCUDEV_Set:3847 CallFn:1927 DoSet:1969 CommandSet:2804 getAllSets:104 CommandJsonList2:1265 AnalyzeCommand:1116 AnalyzeCommandChain:2764 FW_fC:962 FW_answerCall:597 FW_Read:3847 CallFn:773
2021.04.16 17:02:21 2: HMCCU [HMCCU3] Can't get device description for NEQ1477040 HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:380 HMCCUDEV_Set:3847 CallFn:1927 DoSet:1969 CommandSet:2804 getAllSets:104 CommandJsonList2:1265 AnalyzeCommand:1116 AnalyzeCommandChain:2764 FW_fC:962 FW_answerCall:597 FW_Read:3847 CallFn:773
2021.04.16 17:02:21 2: HMCCU [HMCCU3] Can't get device description for OEQ0223456 HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:380 HMCCUDEV_Set:3847 CallFn:1927 DoSet:1969 CommandSet:2804 getAllSets:104 CommandJsonList2:1265 AnalyzeCommand:1116 AnalyzeCommandChain:2764 FW_fC:962 FW_answerCall:597 FW_Read:3847 CallFn:773
2021.04.16 17:02:21 2: HMCCU [HMCCU3] Can't get device description for OEQ0424862 HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:380 HMCCUDEV_Set:3847 CallFn:1927 DoSet:1969 CommandSet:2804 getAllSets:104 CommandJsonList2:1265 AnalyzeCommand:1116 AnalyzeCommandChain:2764 FW_fC:962 FW_answerCall:597 FW_Read:3847 CallFn:773
config
4.8.027
firmware 3.57.4
host ccu3-webui-3b
prot http
version 4.4.066
Auch ich habe noch eine Zusatzfrage: Kann man das Protokoll auf "https" umstellen?
Viele Grüße
Jürgen
Folgende FM bei FHEM shutdown restart (Auszug):
2021.04.16 19:24:08 1: PERL WARNING: Subroutine HMCCU_Initialize redefined at ./FHEM/88_HMCCU.pm line 361, <$fh> line 4338 (zig mal)
2021.04.16 19:24:08 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/88_HMCCU.pm line 6092.
2021.04.16 19:24:28 1: PERL WARNING: Use of uninitialized value $cc in string ne at ./FHEM/88_HMCCU.pm line 7469.
2021.04.16 19:24:28 2: N/A [HMCCU] HMCCU_SplitChnAddr:7642 HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:3635 HMCCU_GetDeviceConfig:568 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.16 19:24:28 2: HMCCU [CCU3] Address not defined for device
HMCCU_GetDeviceDesc:7644 HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:3635 HMCCU_GetDeviceConfig:568 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.16 19:24:28 1: PERL WARNING: Use of uninitialized value $address in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 7646.
2021.04.16 19:24:28 2: HMCCU [CCU3] Can't get device description for HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:3635 HMCCU_GetDeviceConfig:568 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.16 19:24:28 2: N/A [HMCCU] HMCCU_SplitChnAddr:7642 HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:3635 HMCCU_GetDeviceConfig:568 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.16 19:24:28 2: HMCCU [CCU3] Address not defined for device
HMCCU_GetDeviceDesc:7644 HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:3635 HMCCU_GetDeviceConfig:568 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.16 19:24:28 2: HMCCU [CCU3] Can't get device description for HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:3635 HMCCU_GetDeviceConfig:568 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.16 19:24:28 2: N/A [HMCCU] HMCCU_SplitChnAddr:7642 HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:3635 HMCCU_GetDeviceConfig:568 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.16 19:24:28 2: HMCCU [CCU3] Address not defined for device
HMCCU_GetDeviceDesc:7644 HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:3635 HMCCU_GetDeviceConfig:568 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.16 19:24:28 2: HMCCU [CCU3] Can't get device description for HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:3635 HMCCU_GetDeviceConfig:568 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.16 19:24:28 2: N/A [HMCCU] HMCCU_SplitChnAddr:7642 HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:3635 HMCCU_GetDeviceConfig:568 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.16 19:24:28 2: HMCCU [CCU3] Address not defined for device
HMCCU_GetDeviceDesc:7644 HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:3635 HMCCU_GetDeviceConfig:568 HMCCU_PostInit:3379 HandleTimeout:695
2021.04.16 19:24:28 2: HMCCU [CCU3] Can't get device description for HMCCU_DetectDevice:7315 HMCCU_SetDefaultSCDatapoints:7373 HMCCU_GetSCDatapoints:3635 HMCCU_GetDeviceConfig:568 HMCCU_PostInit:3379 HandleTimeout:695
@dl4br
Einige Fragen dazu:
- kommen diese Meldungen auch bei einem normalen FHEM Start? Also erst FHEM stoppen, etwas warten bzw. prüfen, dass keine Perl Prozesse mehr laufen, dann starten
- Hast Du die fhem.cfg manuell editiert? Wenn ja, ist der define vom IO Device der erste, d.h. HMCCU kommt vor HMCCUCHN und HMCCDEV?
Die Ausgabe von "grep HMCCU fhem.cfg" wäre ggf. interessant
@juemuc
Sind das alle Geräte, die Du definiert hast oder gibt es weitere, für die diese Meldung nicht kommt?
Kannst du mal bitte prüfen, ob bei "get HMCCU3 ccuDevices" diese Geräte in der Liste auftauchen?
Zum Umstellen auf https den Zugriff in der CCU erlauben und beim define vom IO Device einfach https://ccu-ip angeben
Zitat von: eurofinder am 16 April 2021, 16:46:52
@zap:
Danke für die neue Version.
Habe nochmals eine grundsätzliche Frage. Wenn ich bei FHEM ein shutdown restart durchführe, dann wird mein HMCCU-Device nicht automatisch gestartet. Wo muss ich was einstellen, damit dies automatisch erfolgt?
Gruß und schönes Wochenende
eurofinder
attr rpcserver on
Zitat von: zap am 17 April 2021, 08:46:31
@dl4br
Einige Fragen dazu:
- kommen diese Meldungen auch bei einem normalen FHEM Start? Also erst FHEM stoppen, etwas warten bzw. prüfen, dass keine Perl Prozesse mehr laufen, dann starten
- Hast Du die fhem.cfg manuell editiert? Wenn ja, ist der define vom IO Device der erste, d.h. HMCCU kommt vor HMCCUCHN und HMCCDEV?
Die Ausgabe von "grep HMCCU fhem.cfg" wäre ggf. interessant
@zap,
die FM sind nach einem Server Kaltstart wie in der Anlage. Die Leerzeilen entsprechen anderen Start-Up Meldungen, die nicht zum HMCCU gehören.
Nein, die fhem.cfg habe ich nicht manuell editiert.
Aber dein Hinweis auf die Reihenfolge der Definitionen könnte interessant sein:
1. HMCCU definiert (4.3)
2. HmIP-KRC4 definiert
2a. HmIP-KRC4 nach einigen Wochen defekt, in der CCU gelöscht, in FHEM nicht gelöscht.
3. HMIP-SWSD definiert
--> Der HMIP-SWSD hat nicht richtig funktioniert (siehe unsere Konversation dazu mit deinem Hinweis, auf HMCCU 4.4 Beta umzustellen)
4. HMCCU gelöscht
5. HMIP-SWSD gelöscht
6. HMCCU 4.4 neu definiert
7. HMIP-SWSD neu definiert
--> Die Def. für den HmIP-KRC4 liegt somit
vor der Definition des HMCCU Moduls in der fhem.cfg
--> Die Def. für den HMIP-SWSD liegt
hinter der Def. für HMCCU
Wenn ich noch was testen kann - gerne!
NACHTRAG:
Ich habe jetzt die Def. für den HmIP-KRC4 gelöscht, alle FM sind verschwunden.
--> Vielleicht eine wichtige Information. Ich hätte die Def. für HMCCU 4.3
vor der Einrichtung der Version 4.4 Beta nicht löschen dürfen.
--> Evtl. sollte das als Info beim Umstieg auf die Beta Version aufgenommen werden.
Nachtrag:
Ich habe jetzt noch mal shutdown restart ausgeführt.
--> Keine HMCCU Warnings o.ä.
EDIT: habe den RPC-Server mal neu gestartet schon läuft es ::)
Versuche gerade einen HmIPW-DRS8 einzubinden.
Als HMCCUCHN kann ich schalten aber bekomme kein status.
Wenn ich ein get datapoint STATE ausführe aktualisiert er richtig
Was fehlt da noch?
control datapoint?
state datapoint?
oder ccuSetOnChange?
list Device
Internals:
DEF 00161BE9A39272:2
FUUID 607aefac-f33f-19ae-734b-605edd6193f7e349
IODev d_ccu
NAME test
NR 1409
STATE off
TYPE HMCCUCHN
ccuaddr 00161BE9A39272:2
ccudevstate active
ccuif HmIP-RF
ccuname HmIPW-DRS8 00161BE9A39272:2
ccurolectrl SWITCH_VIRTUAL_RECEIVER
ccurolestate SWITCH_VIRTUAL_RECEIVER
ccusubtype DRS8
ccutype HmIPW-DRS8
readonly no
OLDREADINGS:
READINGS:
2021-04-17 16:56:08 PROCESS STABLE
2021-04-17 16:56:08 SECTION 2
2021-04-17 16:56:08 SECTION_STATUS NORMAL
2021-04-17 16:56:08 STATE off
2021-04-17 17:00:23 activity alive
2021-04-17 16:56:08 control off
2021-04-17 17:00:23 devstate ok
2021-04-17 17:00:23 hmstate off
2021-04-17 16:56:08 state off
hmccu:
channels 1
devspec 00161BE9A39272:2
nodefaults 0
role 2:SWITCH_VIRTUAL_RECEIVER
semDefaults 0
cmdlist:
get
set off:noArg on-till on-for-timer on:noArg
control:
chn 2
dpt STATE
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
OSVAL 19.0
OVAL 19.000000
SVAL 19.0
VAL 19.000000
0.APPLICATION_VERSION:
SERVICE:
OSVAL 1.2.4
OVAL 1.2.4
SVAL 1.2.4
VAL 1.2.4
VALUES:
0.ARR_TIMEOUT:
MASTER:
OSVAL 10
OVAL 10
SVAL 10
VAL 10
VALUES:
0.BOOTLOADER_VERSION:
SERVICE:
OSVAL 1.6.0
OVAL 1.6.0
SVAL 1.6.0
VAL 1.6.0
VALUES:
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.CYCLIC_INFO_MSG:
MASTER:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
0.CYCLIC_INFO_MSG_DIS:
MASTER:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
0.CYCLIC_INFO_MSG_DIS_UNCHANGED:
MASTER:
OSVAL 20
OVAL 20
SVAL 20
VAL 20
VALUES:
0.CYCLIC_INFO_MSG_OVERDUE_THRESHOLD:
MASTER:
OSVAL 2
OVAL 2
SVAL 2
VAL 2
VALUES:
0.DAYLIGHT_SAVINGS_TIME:
MASTER:
OSVAL true
OVAL 1
SVAL true
VAL 1
VALUES:
0.DISABLE_MSG_TO_AC:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
0.DISPLAY_CONTRAST:
MASTER:
OSVAL 31
OVAL 31
SVAL 31
VAL 31
VALUES:
0.DST_END_DAY_OF_WEEK:
MASTER:
OSVAL SUNDAY
OVAL 0
SVAL SUNDAY
VAL 0
VALUES:
0.DST_END_MONTH:
MASTER:
OSVAL 10
OVAL 10
SVAL 10
VAL 10
VALUES:
0.DST_END_TIME:
MASTER:
OSVAL 180
OVAL 180
SVAL 180
VAL 180
VALUES:
0.DST_END_WEEK_OF_MONTH:
MASTER:
OSVAL LAST
OVAL 5
SVAL LAST
VAL 5
VALUES:
0.DST_START_DAY_OF_WEEK:
MASTER:
OSVAL SUNDAY
OVAL 0
SVAL SUNDAY
VAL 0
VALUES:
0.DST_START_MONTH:
MASTER:
OSVAL 3
OVAL 3
SVAL 3
VAL 3
VALUES:
0.DST_START_TIME:
MASTER:
OSVAL 120
OVAL 120
SVAL 120
VAL 120
VALUES:
0.DST_START_WEEK_OF_MONTH:
MASTER:
OSVAL LAST
OVAL 5
SVAL LAST
VAL 5
VALUES:
0.ENABLE_ROUTING:
MASTER:
OSVAL true
OVAL 1
SVAL true
VAL 1
VALUES:
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.ERROR_UNDERVOLTAGE:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.HARDWARE_VERSION:
SERVICE:
OSVAL 3
OVAL 3
SVAL 3
VAL 3
VALUES:
0.INSTALL_TEST:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.LATITUDE:
MASTER:
OSVAL 51.2
OVAL 51.2
SVAL 51.2
VAL 51.2
VALUES:
0.LOCAL_RESET_DISABLED:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
0.LONGITUDE:
MASTER:
OSVAL 6.8
OVAL 6.8
SVAL 6.8
VAL 6.8
VALUES:
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 24.2
OVAL 24.200000
SVAL 24.2
VAL 24.200000
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.OS_VERSION:
SERVICE:
OSVAL 1.34.1
OVAL 1.34.1
SVAL 1.34.1
VAL 1.34.1
VALUES:
0.OVERTEMP_LEVEL:
MASTER:
OSVAL 70
OVAL 70
SVAL 70
VAL 70
VALUES:
0.SUPPORTING_WIRED_OPERATION_MODE:
MASTER:
OSVAL true
OVAL 1
SVAL true
VAL 1
VALUES:
0.TEST_STATUS:
SERVICE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
0.UNREACH:
VALUES:
OSVAL alive
OVAL false
SVAL alive
VAL false
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
0.UTC_DST_OFFSET:
MASTER:
OSVAL 120
OVAL 120
SVAL 120
VAL 120
VALUES:
0.UTC_OFFSET:
MASTER:
OSVAL 60
OVAL 60
SVAL 60
VAL 60
VALUES:
2.APPLICATION_VERSION:
SERVICE:
OSVAL 1.2.4
OVAL 1.2.4
SVAL 1.2.4
VAL 1.2.4
VALUES:
2.BOOTLOADER_VERSION:
SERVICE:
OSVAL 1.6.0
OVAL 1.6.0
SVAL 1.6.0
VAL 1.6.0
VALUES:
2.HARDWARE_VERSION:
SERVICE:
OSVAL 3
OVAL 3
SVAL 3
VAL 3
VALUES:
2.LOGIC_COMBINATION:
MASTER:
OSVAL LOGIC_OR
OVAL 1
SVAL LOGIC_OR
VAL 1
VALUES:
2.OS_VERSION:
SERVICE:
OSVAL 1.34.1
OVAL 1.34.1
SVAL 1.34.1
VAL 1.34.1
VALUES:
2.POWERUP_JUMPTARGET:
MASTER:
OSVAL OFF
OVAL 0
SVAL OFF
VAL 0
VALUES:
2.POWERUP_OFFDELAY_UNIT:
MASTER:
OSVAL 100MS
OVAL 0
SVAL 100MS
VAL 0
VALUES:
2.POWERUP_OFFDELAY_VALUE:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
2.POWERUP_OFFTIME_UNIT:
MASTER:
OSVAL H
OVAL 7
SVAL H
VAL 7
VALUES:
2.POWERUP_OFFTIME_VALUE:
MASTER:
OSVAL 31
OVAL 31
SVAL 31
VAL 31
VALUES:
2.POWERUP_ONDELAY_UNIT:
MASTER:
OSVAL 100MS
OVAL 0
SVAL 100MS
VAL 0
VALUES:
2.POWERUP_ONDELAY_VALUE:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
2.POWERUP_ONTIME_UNIT:
MASTER:
OSVAL H
OVAL 7
SVAL H
VAL 7
VALUES:
2.POWERUP_ONTIME_VALUE:
MASTER:
OSVAL 31
OVAL 31
SVAL 31
VAL 31
VALUES:
2.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
2.SECTION:
VALUES:
OSVAL 2
OVAL 2
SVAL 2
VAL 2
2.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
2.STATE:
VALUES:
OSVAL off
OVAL false
SVAL off
VAL false
2.TEST_STATUS:
SERVICE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
d.APPLICATION_VERSION:
SERVICE:
OSVAL 1.2.4
OVAL 1.2.4
SVAL 1.2.4
VAL 1.2.4
VALUES:
d.BOOTLOADER_VERSION:
SERVICE:
OSVAL 1.6.0
OVAL 1.6.0
SVAL 1.6.0
VAL 1.6.0
VALUES:
d.HARDWARE_VERSION:
SERVICE:
OSVAL 3
OVAL 3
SVAL 3
VAL 3
VALUES:
d.OS_VERSION:
SERVICE:
OSVAL 1.34.1
OVAL 1.34.1
SVAL 1.34.1
VAL 1.34.1
VALUES:
d.TEST_STATUS:
SERVICE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
roleCmds:
get:
set:
off:
channel 2
role SWITCH_VIRTUAL_RECEIVER
subcount 1
syntax V:STATE:0
usage off
subcmd:
000:
args 0
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on:
channel 2
role SWITCH_VIRTUAL_RECEIVER
subcount 1
syntax V:STATE:1
usage on
subcmd:
000:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on-for-timer:
channel 2
role SWITCH_VIRTUAL_RECEIVER
subcount 2
syntax V:ON_TIME:?duration V:STATE:1
usage on-for-timer duration
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname duration
partype 2
ps VALUES
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
on-till:
channel 2
role SWITCH_VIRTUAL_RECEIVER
subcount 2
syntax V:ON_TIME:?time V:STATE:1
usage on-till time
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname time
partype 2
ps VALUES
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
unit
state:
chn 2
dpt STATE
Attributes:
IODev d_ccu
cmdIcon on:general_an off:general_aus
room Homematic
statedatapoint STATE
get deviceInfo
Device channels and datapoints
DEV HmIPW-02-DRS8-Keller 00161BE9A39272 interface=HmIP-RF type=HmIPW-DRS8
CHN 00161BE9A39272:0 HmIPW-02-DRS8-Keller:0
0.ACTUAL_TEMPERATURE = 19.000000 {f} [RE]
0.COMBINED_PARAMETER = {s} [W]
0.CONFIG_PENDING = false {b} [RE]
0.ERROR_CODE = 0 {n} [RE]
0.ERROR_OVERHEAT = false {b} [RE]
0.ERROR_UNDERVOLTAGE = false {b} [RE]
0.IDENTIFICATION_MODE_KEY_VISUAL = {b} [W]
0.IDENTIFICATION_MODE_LCD_BACKLIGHT = {b} [W]
0.IDENTIFY_DURATION = {f} [W]
0.IDENTIFY_TARGET_LEVEL = {f} [W]
0.INSTALL_TEST = false {b} [RW]
0.OPERATING_VOLTAGE = 24.200000 {f} [RE]
0.OPERATING_VOLTAGE_STATUS = 0 {i} [RE]
0.UNREACH = false {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
CHN 00161BE9A39272:1 HmIPW-DRS8 00161BE9A39272:1
1.PROCESS = 0 {i} [RE]
1.SECTION = 0 {i} [RE]
1.SECTION_STATUS = 0 {i} [RE]
1.STATE = false {b} [RE]
CHN 00161BE9A39272:2 HmIPW-DRS8 00161BE9A39272:2
2.COMBINED_PARAMETER = {s} [W]
2.ON_TIME = {f} [W]
2.PROCESS = 0 {i} [RE]
2.SECTION = 0 {i} [RE]
2.SECTION_STATUS = 0 {i} [RE]
2.STATE = false {b} [RWE]
CHN 00161BE9A39272:3 HmIPW-DRS8 00161BE9A39272:3
3.COMBINED_PARAMETER = {s} [W]
3.ON_TIME = {f} [W]
3.PROCESS = 0 {i} [RE]
3.SECTION = 0 {i} [RE]
3.SECTION_STATUS = 0 {i} [RE]
3.STATE = false {b} [RWE]
CHN 00161BE9A39272:4 HmIPW-DRS8 00161BE9A39272:4
4.COMBINED_PARAMETER = {s} [W]
4.ON_TIME = {f} [W]
4.PROCESS = 0 {i} [RE]
4.SECTION = 0 {i} [RE]
4.SECTION_STATUS = 0 {i} [RE]
4.STATE = false {b} [RWE]
CHN 00161BE9A39272:5 HmIPW-DRS8 00161BE9A39272:5
5.PROCESS = 0 {i} [RE]
5.SECTION = 2 {i} [RE]
5.SECTION_STATUS = 0 {i} [RE]
5.STATE = true {b} [RE]
CHN 00161BE9A39272:6 HmIPW-DRS8 00161BE9A39272:6
6.COMBINED_PARAMETER = {s} [W]
6.ON_TIME = {f} [W]
6.PROCESS = 0 {i} [RE]
6.SECTION = 2 {i} [RE]
6.SECTION_STATUS = 0 {i} [RE]
6.STATE = true {b} [RWE]
CHN 00161BE9A39272:7 HmIPW-DRS8 00161BE9A39272:7
7.COMBINED_PARAMETER = {s} [W]
7.ON_TIME = {f} [W]
7.PROCESS = 0 {i} [RE]
7.SECTION = 0 {i} [RE]
7.SECTION_STATUS = 0 {i} [RE]
7.STATE = false {b} [RWE]
CHN 00161BE9A39272:8 HmIPW-DRS8 00161BE9A39272:8
8.COMBINED_PARAMETER = {s} [W]
8.ON_TIME = {f} [W]
8.PROCESS = 0 {i} [RE]
8.SECTION = 0 {i} [RE]
8.SECTION_STATUS = 0 {i} [RE]
8.STATE = false {b} [RWE]
CHN 00161BE9A39272:9 HmIPW-DRS8 00161BE9A39272:9
9.PROCESS = 0 {i} [RE]
9.SECTION = 0 {i} [RE]
9.SECTION_STATUS = 0 {i} [RE]
9.STATE = false {b} [RE]
CHN 00161BE9A39272:10 HmIPW-DRS8 00161BE9A39272:10
10.COMBINED_PARAMETER = {s} [W]
10.ON_TIME = {f} [W]
10.PROCESS = 0 {i} [RE]
10.SECTION = 0 {i} [RE]
10.SECTION_STATUS = 0 {i} [RE]
10.STATE = false {b} [RWE]
CHN 00161BE9A39272:11 HmIPW-DRS8 00161BE9A39272:11
11.COMBINED_PARAMETER = {s} [W]
11.ON_TIME = {f} [W]
11.PROCESS = 0 {i} [RE]
11.SECTION = 0 {i} [RE]
11.SECTION_STATUS = 0 {i} [RE]
11.STATE = false {b} [RWE]
CHN 00161BE9A39272:12 HmIPW-DRS8 00161BE9A39272:12
12.COMBINED_PARAMETER = {s} [W]
12.ON_TIME = {f} [W]
12.PROCESS = 0 {i} [RE]
12.SECTION = 0 {i} [RE]
12.SECTION_STATUS = 0 {i} [RE]
12.STATE = false {b} [RWE]
CHN 00161BE9A39272:13 HmIPW-DRS8 00161BE9A39272:13
13.PROCESS = 0 {i} [RE]
13.SECTION = 0 {i} [RE]
13.SECTION_STATUS = 0 {i} [RE]
13.STATE = false {b} [RE]
CHN 00161BE9A39272:14 HmIPW-DRS8 00161BE9A39272:14
14.COMBINED_PARAMETER = {s} [W]
14.ON_TIME = {f} [W]
14.PROCESS = 0 {i} [RE]
14.SECTION = 0 {i} [RE]
14.SECTION_STATUS = 0 {i} [RE]
14.STATE = false {b} [RWE]
CHN 00161BE9A39272:15 HmIPW-DRS8 00161BE9A39272:15
15.COMBINED_PARAMETER = {s} [W]
15.ON_TIME = {f} [W]
15.PROCESS = 0 {i} [RE]
15.SECTION = 0 {i} [RE]
15.SECTION_STATUS = 0 {i} [RE]
15.STATE = false {b} [RWE]
CHN 00161BE9A39272:16 HmIPW-DRS8 00161BE9A39272:16
16.COMBINED_PARAMETER = {s} [W]
16.ON_TIME = {f} [W]
16.PROCESS = 0 {i} [RE]
16.SECTION = 0 {i} [RE]
16.SECTION_STATUS = 0 {i} [RE]
16.STATE = false {b} [RWE]
CHN 00161BE9A39272:17 HmIPW-DRS8 00161BE9A39272:17
17.PROCESS = 0 {i} [RE]
17.SECTION = 0 {i} [RE]
17.SECTION_STATUS = 0 {i} [RE]
17.STATE = false {b} [RE]
CHN 00161BE9A39272:18 HmIPW-DRS8 00161BE9A39272:18
18.COMBINED_PARAMETER = {s} [W]
18.ON_TIME = {f} [W]
18.PROCESS = 0 {i} [RE]
18.SECTION = 0 {i} [RE]
18.SECTION_STATUS = 0 {i} [RE]
18.STATE = false {b} [RWE]
CHN 00161BE9A39272:19 HmIPW-DRS8 00161BE9A39272:19
19.COMBINED_PARAMETER = {s} [W]
19.ON_TIME = {f} [W]
19.PROCESS = 0 {i} [RE]
19.SECTION = 0 {i} [RE]
19.SECTION_STATUS = 0 {i} [RE]
19.STATE = false {b} [RWE]
CHN 00161BE9A39272:20 HmIPW-DRS8 00161BE9A39272:20
20.COMBINED_PARAMETER = {s} [W]
20.ON_TIME = {f} [W]
20.PROCESS = 0 {i} [RE]
20.SECTION = 0 {i} [RE]
20.SECTION_STATUS = 0 {i} [RE]
20.STATE = false {b} [RWE]
CHN 00161BE9A39272:21 HmIPW-DRS8 00161BE9A39272:21
21.PROCESS = 0 {i} [RE]
21.SECTION = 0 {i} [RE]
21.SECTION_STATUS = 0 {i} [RE]
21.STATE = false {b} [RE]
CHN 00161BE9A39272:22 HmIPW-DRS8 00161BE9A39272:22
22.COMBINED_PARAMETER = {s} [W]
22.ON_TIME = {f} [W]
22.PROCESS = 0 {i} [RE]
22.SECTION = 0 {i} [RE]
22.SECTION_STATUS = 0 {i} [RE]
22.STATE = false {b} [RWE]
CHN 00161BE9A39272:23 HmIPW-DRS8 00161BE9A39272:23
23.COMBINED_PARAMETER = {s} [W]
23.ON_TIME = {f} [W]
23.PROCESS = 0 {i} [RE]
23.SECTION = 0 {i} [RE]
23.SECTION_STATUS = 0 {i} [RE]
23.STATE = false {b} [RWE]
CHN 00161BE9A39272:24 HmIPW-DRS8 00161BE9A39272:24
24.COMBINED_PARAMETER = {s} [W]
24.ON_TIME = {f} [W]
24.PROCESS = 0 {i} [RE]
24.SECTION = 0 {i} [RE]
24.SECTION_STATUS = 0 {i} [RE]
24.STATE = false {b} [RWE]
CHN 00161BE9A39272:25 HmIPW-DRS8 00161BE9A39272:25
25.PROCESS = 0 {i} [RE]
25.SECTION = 0 {i} [RE]
25.SECTION_STATUS = 0 {i} [RE]
25.STATE = false {b} [RE]
CHN 00161BE9A39272:26 HmIPW-DRS8 00161BE9A39272:26
26.COMBINED_PARAMETER = {s} [W]
26.ON_TIME = {f} [W]
26.PROCESS = 0 {i} [RE]
26.SECTION = 0 {i} [RE]
26.SECTION_STATUS = 0 {i} [RE]
26.STATE = false {b} [RWE]
CHN 00161BE9A39272:27 HmIPW-DRS8 00161BE9A39272:27
27.COMBINED_PARAMETER = {s} [W]
27.ON_TIME = {f} [W]
27.PROCESS = 0 {i} [RE]
27.SECTION = 0 {i} [RE]
27.SECTION_STATUS = 0 {i} [RE]
27.STATE = false {b} [RWE]
CHN 00161BE9A39272:28 HmIPW-DRS8 00161BE9A39272:28
28.COMBINED_PARAMETER = {s} [W]
28.ON_TIME = {f} [W]
28.PROCESS = 0 {i} [RE]
28.SECTION = 0 {i} [RE]
28.SECTION_STATUS = 0 {i} [RE]
28.STATE = false {b} [RWE]
CHN 00161BE9A39272:29 HmIPW-DRS8 00161BE9A39272:29
29.PROCESS = 0 {i} [RE]
29.SECTION = 0 {i} [RE]
29.SECTION_STATUS = 0 {i} [RE]
29.STATE = false {b} [RE]
CHN 00161BE9A39272:30 HmIPW-DRS8 00161BE9A39272:30
30.COMBINED_PARAMETER = {s} [W]
30.ON_TIME = {f} [W]
30.PROCESS = 0 {i} [RE]
30.SECTION = 0 {i} [RE]
30.SECTION_STATUS = 0 {i} [RE]
30.STATE = false {b} [RWE]
CHN 00161BE9A39272:31 HmIPW-DRS8 00161BE9A39272:31
31.COMBINED_PARAMETER = {s} [W]
31.ON_TIME = {f} [W]
31.PROCESS = 0 {i} [RE]
31.SECTION = 0 {i} [RE]
31.SECTION_STATUS = 0 {i} [RE]
31.STATE = false {b} [RWE]
CHN 00161BE9A39272:32 HmIPW-DRS8 00161BE9A39272:32
32.COMBINED_PARAMETER = {s} [W]
32.ON_TIME = {f} [W]
32.PROCESS = 0 {i} [RE]
32.SECTION = 0 {i} [RE]
32.SECTION_STATUS = 0 {i} [RE]
32.STATE = false {b} [RWE]
CHN 00161BE9A39272:33 HmIPW-DRS8 00161BE9A39272:33
33.COMBINED_PARAMETER = {s} [W]
33.WEEK_PROGRAM_CHANNEL_LOCKS = 0 {i} [RE]
33.WEEK_PROGRAM_TARGET_CHANNEL_LOCK = {i} [W]
33.WEEK_PROGRAM_TARGET_CHANNEL_LOCKS = {i} [W]
Device detection:
StateDatapoint = 14.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 30.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 8.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 5.STATE [SWITCH_TRANSMITTER]
StateDatapoint = 19.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 24.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 29.STATE [SWITCH_TRANSMITTER]
StateDatapoint = 10.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 18.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 26.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 20.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 28.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 16.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 11.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 22.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 23.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 1.STATE [SWITCH_TRANSMITTER]
StateDatapoint = 12.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 9.STATE [SWITCH_TRANSMITTER]
StateDatapoint = 21.STATE [SWITCH_TRANSMITTER]
StateDatapoint = 4.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 13.STATE [SWITCH_TRANSMITTER]
StateDatapoint = 7.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 2.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 31.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 27.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 3.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 15.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 6.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 32.STATE [SWITCH_VIRTUAL_RECEIVER]
StateDatapoint = 17.STATE [SWITCH_TRANSMITTER]
StateDatapoint = 25.STATE [SWITCH_TRANSMITTER]
ControlDatapoint = 22.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 11.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 23.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 12.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 4.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 2.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 7.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 31.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 3.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 15.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 27.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 6.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 32.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 30.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 14.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 8.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 19.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 24.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 10.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 18.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 26.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 20.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 28.STATE [SWITCH_VIRTUAL_RECEIVER]
ControlDatapoint = 16.STATE [SWITCH_VIRTUAL_RECEIVER]
Recommended module for device definition: HMCCUDEV
Current state datapoint = 2.STATE
Current control datapoint = 2.STATE
Device description
Device 00161BE9A39272 HmIPW-02-DRS8-Keller [HmIPW-DRS8]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 00161BE9A39272:0,00161BE9A39272:1,00161BE9A39272:2,00161BE9A39272:3,00161BE9A39272:4,00161BE9A39272:5,00161BE9A39272:6,00161BE9A39272:7,00161BE9A39272:8,00161BE9A39272:9,00161BE9A39272:10,00161BE9A39272:11,00161BE9A39272:12,00161BE9A39272:13,00161BE9A39272:14,00161BE9A39272:15,00161BE9A39272:16,00161BE9A39272:17,00161BE9A39272:18,00161BE9A39272:19,00161BE9A39272:20,00161BE9A39272:21,00161BE9A39272:22,00161BE9A39272:23,00161BE9A39272:24,00161BE9A39272:25,00161BE9A39272:26,00161BE9A39272:27,00161BE9A39272:28,00161BE9A39272:29,00161BE9A39272:30,00161BE9A39272:31,00161BE9A39272:32,00161BE9A39272:33
DIRECTION: NONE
FIRMWARE: 1.2.4
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 11505165
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG
SUBTYPE: DRS8
UPDATABLE: 1
Channel 00161BE9A39272:0 HmIPW-02-DRS8-Keller:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 00161BE9A39272
PARENT_TYPE: HmIPW-DRS8
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00161BE9A39272:2 HmIPW-DRS8 00161BE9A39272:2 [SWITCH_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: CONDITIONAL_SWITCH,SWITCH,REMOTE_CONTROL,LEVEL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00161BE9A39272
PARENT_TYPE: HmIPW-DRS8
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Defaults
Support for role SWITCH_VIRTUAL_RECEIVER of device type HmIPW-DRS8 is built in.
get config
Device 00161BE9A39272
Channel 0 [MASTER]
ARR_TIMEOUT = 10
CYCLIC_INFO_MSG = 1
CYCLIC_INFO_MSG_DIS = 1
CYCLIC_INFO_MSG_DIS_UNCHANGED = 20
CYCLIC_INFO_MSG_OVERDUE_THRESHOLD = 2
DAYLIGHT_SAVINGS_TIME = true
DISABLE_MSG_TO_AC = false
DISPLAY_CONTRAST = 31
DST_END_DAY_OF_WEEK = SUNDAY
DST_END_MONTH = 10
DST_END_TIME = 180
DST_END_WEEK_OF_MONTH = LAST
DST_START_DAY_OF_WEEK = SUNDAY
DST_START_MONTH = 3
DST_START_TIME = 120
DST_START_WEEK_OF_MONTH = LAST
ENABLE_ROUTING = true
LATITUDE = 51.2
LOCAL_RESET_DISABLED = false
LONGITUDE = 6.8
OVERTEMP_LEVEL = 70
SUPPORTING_WIRED_OPERATION_MODE = true
UTC_DST_OFFSET = 120
UTC_OFFSET = 60
Channel 0 [SERVICE]
APPLICATION_VERSION = 1.2.4
BOOTLOADER_VERSION = 1.6.0
HARDWARE_VERSION = 3
OS_VERSION = 1.34.1
TEST_STATUS = 0
Channel 2 [MASTER]
LOGIC_COMBINATION = LOGIC_OR
POWERUP_JUMPTARGET = OFF
POWERUP_OFFDELAY_UNIT = 100MS
POWERUP_OFFDELAY_VALUE = 0
POWERUP_OFFTIME_UNIT = H
POWERUP_OFFTIME_VALUE = 31
POWERUP_ONDELAY_UNIT = 100MS
POWERUP_ONDELAY_VALUE = 0
POWERUP_ONTIME_UNIT = H
POWERUP_ONTIME_VALUE = 31
Channel 2 [SERVICE]
APPLICATION_VERSION = 1.2.4
BOOTLOADER_VERSION = 1.6.0
HARDWARE_VERSION = 3
OS_VERSION = 1.34.1
TEST_STATUS = 0
Channel d [SERVICE]
APPLICATION_VERSION = 1.2.4
BOOTLOADER_VERSION = 1.6.0
HARDWARE_VERSION = 3
OS_VERSION = 1.34.1
TEST_STATUS = 0
@zap:
Zitatattr rpcserver on
Danke. Irgendwie hatte ich gedacht, dass würde entfallen - habe das wohl was falsch verstanden :-)
Gruß
eurofinder
Zitat von: zap am 17 April 2021, 08:54:39
@juemuc
Sind das alle Geräte, die Du definiert hast oder gibt es weitere, für die diese Meldung nicht kommt?
Kannst du mal bitte prüfen, ob bei "get HMCCU3 ccuDevices" diese Geräte in der Liste auftauchen?
Zum Umstellen auf https den Zugriff in der CCU erlauben und beim define vom IO Device einfach https://ccu-ip angeben
Hallo zap,
ja die Devices sind alle enthalten:
Name Model Interface Address Channels Supported roles
HM-RCV-50 BidCoS-RF HM-RCV-50 BidCos-RF BidCoS-RF 51 VIRTUAL_KEY [50x]
HM_Sen_DB_PCB_NEQ0956261 HM-Sen-DB-PCB BidCos-RF NEQ0956261 2 KEY [1x]
HM_Sec_RHS_NEQ1477040 HM-Sec-RHS BidCos-RF NEQ1477040 2 ROTARY_HANDLE_SENSOR [1x]
HM_ES_PMSw1_Pl_DN_R1_NEQ1662710 HM-ES-PMSw1-Pl-DN-R1 BidCos-RF NEQ1662710 7 POWERMETER [1x]
SWITCH [1x]
HM_MOD_Re_8_OEQ0206895 HM-MOD-Re-8 BidCos-RF OEQ0206895 9 SWITCH [8x]
HM_Sec_SCo_OEQ0223456 HM-Sec-SCo BidCos-RF OEQ0223456 2 SHUTTER_CONTACT [1x]
HM_Sec_SCo_OEQ0424862 HM-Sec-SCo BidCos-RF OEQ0424862 2 SHUTTER_CONTACT [1x]
HM-LC-Sw1PBU-FM OEQ0625708 HM-LC-Sw1PBU-FM BidCos-RF OEQ0625708 2 SWITCH [1x]
HMIP-SWDO 0000DA498D425C HMIP-SWDO HmIP-RF 0000DA498D425C 3 SHUTTER_CONTACT [1x]
HMIP-SWDO 0000DA498D427A HMIP-SWDO HmIP-RF 0000DA498D427A 3 SHUTTER_CONTACT [1x]
HMIP-SWDO 0000DA498D4303 HMIP-SWDO HmIP-RF 0000DA498D4303 3 SHUTTER_CONTACT [1x]
HmIP-BSM 000858A9ABDF0E HmIP-BSM HmIP-RF 000858A9ABDF0E 10 ENERGIE_METER_TRANSMITTER [1x]
KEY_TRANSCEIVER [2x]
SWITCH_TRANSMITTER [1x]
SWITCH_VIRTUAL_RECEIVER [3x]
HmIP-BSM 00085A49A3F759 HmIP-BSM HmIP-RF 00085A49A3F759 10 ENERGIE_METER_TRANSMITTER [1x]
KEY_TRANSCEIVER [2x]
SWITCH_TRANSMITTER [1x]
SWITCH_VIRTUAL_RECEIVER [3x]
HmIP-SMI 000918A9952DE7 HmIP-SMI HmIP-RF 000918A9952DE7 4 MOTIONDETECTOR_TRANSCEIVER [1x]
HmIP-SMI 00091A498F0907 HmIP-SMI HmIP-RF 00091A498F0907 4 MOTIONDETECTOR_TRANSCEIVER [1x]
HmIP-RCV-50 HmIP-RCV-1 HmIP-RCV-50 HmIP-RF HmIP-RCV-1 51 KEY_TRANSCEIVER [50x]
Viele Grüße
Jürgen
Zitat von: zap am 16 April 2021, 12:26:42
- Geräte vom Typ HmIP-SMI55 werden nun von "get create" und "get createDev" als 3 HMCCUCHN Devices in FHEM angelegt @1.fhemtester: Kannst Du das bitte mal testen?
Den HmIP-SMI55 hab ich gelöscht.
Nach "get create" Ich hab weiterhin ein HMCCUDEV.
Neu ist: cmdIcon reset:rc_BACK und eine Dropdown Box beim DeviceOverview.
Weiters hab ich jetzt auch den HmIP-FSM16 als HMCCUDEV. Kopplung mit HmIP-SMI55 manueller Schalterfunktion geht auch, Kopplung mit Bewegungsmelder muss ich noch testen.
In Internals sehe ich receiver HmIP_FSM16.
Sollte ich sehen können welcher HmIP-SMI55 Kanal den HmIP-FSM16 schaltet ?
Ich habe gerade dann mal die aktuelle Version installiert und beim Präsenzmelder geschaut (natürlich erstmal alles alte rausgeworfen).
Sieht soweit gut aus. Aber wolltest du nicht sabotage per default als eigenes Reading ausliefern?
Zumindest jetzt beim HmIP-SPI musste ich dafür wieder ccuflags und ccureadingname definieren.
Zitat von: kjmEjfu am 12 April 2021, 14:48:57
Ich würde mal gerne über Geräte wie z.B. die BDTs diskutieren.
Die sehen derzeit so aus:
Macht es Sinn, dass der state datapoint auf 4.LEVEL steht?
So kann ich in diesem Device ja 4.LEVEL, 5.LEVEL und 6.LEVEL ändern. Der daraus kombinierte Level steht dann in 3.LEVEL.
Wenn aber der BDT, so wie im Modul vorgeschlagen, als HMCCUDEV angelegt wird, wird der state halt u.U. nicht richtig dargestellt: 4.LEVEL steht auf 0, 5.LEVEL auf 100, aber als state für das Device wird 4.LEVEL, also 0, angezeigt. Der richtige Wert, in Abhängigkeit von den Einstellungen im Gerät, könnte aber 5.LEVEL, also 100, sein. Der richtige Werte würde in 3.LEVEL angezeigt werden.
Macht es also nicht eigentlich Sinn, wenn der state datapoint per default auf 3.LEVEL gestellt wird?
Oder habe ich einen Denkfehler?
Nein, Du hast recht. Du weißt nicht zufällig, aus welchem Grund EQ-3 diesem Gerät (und einigen anderen) 3 identische Schaltkanäle spendiert?
Zitat von: eurofinder am 17 April 2021, 17:16:15
@zap:Danke. Irgendwie hatte ich gedacht, dass würde entfallen - habe das wohl was falsch verstanden :-)
Gruß
eurofinder
Ich bin immer noch hin und her gerissen, ob ich den automatischen Start der RPC-Server als Default auf "on" setzen soll. Die Idee dahinter ist, dass jemand, der mit HMCCU beginnt, erst mal seine Geräte definiert, ggf. auch FHEM das eine oder andere Mal neu startet und als Abschluss sozusagen dann die RPC-Server auf Autostart setzt.
Ich lasse mich aber gerne überzeugen, wenn ich mit dieser Meinung alleine bin ;)
Zitat von: SamNitro am 17 April 2021, 17:05:10
EDIT: habe den RPC-Server mal neu gestartet schon läuft es ::)
Versuche gerade einen HmIPW-DRS8 einzubinden.
Als HMCCUCHN kann ich schalten aber bekomme kein status.
Wenn ich ein get datapoint STATE ausführe aktualisiert er richtig
Was fehlt da noch?
control datapoint?
state datapoint?
oder ccuSetOnChange?
Ja, es funktioniert, wenn Du ein HMCCUCHN nimmst und den richtigen Kanal erwischst. Aber eigentlich sind diese Wired Aktoren so aufgebaut (am Beispiel dieses 8-fach Schalters):
8 Kanalgruppen bestehend aus je 4 Kanälen = 32 Kanäle insgesamt
Jede Kanalgruppe fängt mit einem SWITCH_TRANSMITTER Kanal an (readonly) gefolgt von 3 SWITCH_VIRTUAL_RECEIVER Kanälen (read/write). Du hast mit Kanal 2 einen solchen SWITCH_VIRTUAL_RECEIVER verwendet, der Lesen und Schreiben erlaubt. Hättest Du den Kanal 1 verwendet, wäre kein Schalten möglich.
Der SWITCH_TRANSMITTER Kanal einer Gruppe enthält den kombinierten Status der 3 SWITCH_VIRTUAL_RECEIVER Kanäle. Daher wäre es eigentlich richtig, für jede Kanalgruppe ein HMCCUDEV zu definieren. Die Defines wären alle identisch (gleiche Geräteadresse), die state- und controldatapoints jedoch unterschiedlich.
Beispiel:
define Kanalgruppe1 00161BE9A39272
define Kanalgruppe2 00161BE9A39272
define Kanalgruppe3 00161BE9A39272
attr Kanalgruppe1 statedatapoint 1.STATE
attr Kanalgruppe1 controldatapoint 2.STATE (oder 3.STATE oder 4.STATE)
attr Kanalgruppe2 statedatapoint 5.STATE
attr Kanalgruppe2 controldatapoint 6.STATE (oder 7.STATE oder 8.STATE)
attr Kanalgruppe3 statedatapoint 9.STATE
attr Kanalgruppe4 controldatapoint 10.STATE (oder 11.STATE oder 12.STATE)
usw.
Ich muss dem HMCCU Autodetect-Algorithmus noch diese Art von Devices (Kanalgruppen) beibringen. Daher bleibt aktuell nur die manuelle Definition.
Zitat von: juemuc am 17 April 2021, 17:28:09
Hallo zap,
ja die Devices sind alle enthalten:
Kommen die Meldungen nur während dem Start? Lassen sich die Geräte in FHEM normal nutzen?
Zitat von: zap am 18 April 2021, 16:33:05
Nein, Du hast recht. Du weißt nicht zufällig, aus welchem Grund EQ-3 diesem Gerät (und einigen anderen) 3 identische Schaltkanäle spendiert?
Das gibt's auch bei HM Dimmern.
Die 3 Kanäle sollten sich logisch kombinieren lassen. Benutzt wird das für komplexe Lichtszenarien z.B. Bei Start Dämmerung 10%, wenn Bewegungsmelder in der Nacht auslöst 50% für 10 min und dann wieder 10% und wenn manuell geschaltet wird 100% dauerhaft.
Hey, wenn ich meine Rollos mit open/up close/down fahre springt die anzeige direkt auf 100 bzw 0
Internals:
DEF 00165BE99E4952:6
FUUID 607ca0b9-f33f-19ae-f730-c60b44e66baa49bd
IODev d_ccu
NAME HmIPW_Rollo_Wohnzimmer
NR 272
STATE open
TYPE HMCCUCHN
ccuaddr 00165BE99E4952:6
ccudevstate active
ccuif HmIP-RF
ccuname HmIPW-Rollo-Wohnzimmer
ccurolectrl BLIND_VIRTUAL_RECEIVER
ccurolestate BLIND_VIRTUAL_RECEIVER
ccusubtype DRBL4
ccutype HmIPW-DRBL4
readonly no
receiver ccu:HmIPW-06-DRI32-Keller
sender ccu:HmIPW-06-DRI32-Keller
READINGS:
2021-04-19 09:24:57 ACTIVITY_STATE STABLE
2021-04-19 09:24:57 LEVEL open
2021-04-19 09:24:57 LEVEL_2 1.0
2021-04-19 09:24:57 LEVEL_2_STATUS NORMAL
2021-04-19 09:24:57 LEVEL_STATUS NORMAL
2021-04-19 09:24:57 PROCESS STABLE
2021-04-19 09:24:57 SECTION 4
2021-04-19 09:24:57 SECTION_STATUS NORMAL
2021-04-19 09:24:58 activity alive
2021-04-19 09:24:57 control open
2021-04-19 09:24:58 devstate ok
2021-04-19 09:24:58 hmstate open
2021-04-19 09:24:57 pct 100
2021-04-19 09:24:57 state open
hmccu:
channels 1
devspec 00165BE99E4952:6
nodefaults 1
role 6:BLIND_VIRTUAL_RECEIVER
semDefaults 0
cmdlist:
get
set stop:noArg close:noArg down up open:noArg pct toggle:noArg
control:
chn 6
dpt LEVEL
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
OSVAL 22.0
OVAL 22.0
SVAL 22.0
VAL 22.0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_UNDERVOLTAGE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 24.3
OVAL 24.3
SVAL 24.3
VAL 24.3
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL false
SVAL false
VAL false
6.ACTIVITY_STATE:
VALUES:
OSVAL UP
OVAL 1
SVAL STABLE
VAL 3
6.LEVEL:
VALUES:
OSVAL 80
OVAL 0.8
SVAL open
VAL 1.0
6.LEVEL_2:
VALUES:
OSVAL 1.0
OVAL 1.0
SVAL 1.0
VAL 1.0
6.LEVEL_2_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.PROCESS:
VALUES:
OSVAL NOT_STABLE
OVAL 1
SVAL STABLE
VAL 0
6.SECTION:
VALUES:
OSVAL 3
OVAL 3
SVAL 4
VAL 4
6.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
roleCmds:
get:
set:
close:
channel 6
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:0
usage close
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
unit 100%
down:
channel 6
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=-20
usage down [delta]
subcmd:
000:
args -20
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
unit 100%
open:
channel 6
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:100
usage open
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
unit 100%
pct:
channel 6
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?level
usage pct level
subcmd:
000:
args
dpt LEVEL
fnc
max 1.01
min 0.0
parname level
partype 2
ps VALUES
unit 100%
stop:
channel 6
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:STOP:1
usage stop
subcmd:
000:
args 1
dpt STOP
fnc
max 1
min 0
parname STOP
partype 3
ps VALUES
unit
up:
channel 6
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=+20
usage up [delta]
subcmd:
000:
args +20
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
unit 100%
state:
chn 6
dpt LEVEL
Attributes:
IODev d_ccu
cmdIcon open:fts_shutter_up stop:fts_shutter_manual close:fts_shutter_down
room Homematic
substexcl pct
userattr structexclude structure_rollo_unten structure_rollo_unten_map
webCmd pct:open:close:stop
widgetOverride pct:slider,0,10,100
liegt das an der Programmierung oder an mir?
Nachtrag: und ein set Rollo..... up fährt das Rollo weiter runter
Zitat von: SamNitro am 19 April 2021, 09:27:54
Hey, wenn ich meine Rollos mit open/up close/down fahre springt die anzeige direkt auf 100 bzw 0
liegt das an der Programmierung oder an mir?
Nachtrag: und ein set Rollo..... up fährt das Rollo weiter runter
Normalerweise (Werkseinstellung) bedeutet das LEVEL bei einem Rollladen-/Jalousienaktor:
0 = geschlossen / unten
100 = offen / oben
Bei Dir ist es genau anders.
Bei der Schalter-/Tastenzuordnung kann man das in der CCU umstellen (Einstellungen > Geräte). HMCCU kann das momentan nicht.
Die saubere Lösung wäre, die beiden Kabel für Up/Down im Aktor zu vertauschen.
Die Befehle "set up" und "set down" fahren den Rollladen per Default um 20% in die jeweilige Richtung. Die Befehle akzeptieren eine Prozentangabe als Parameter. Der Befehl "set up 30" fährt also um 30% hoch.
100% ist bei mir offen, so zeigt er das in der Homematic an. Also da ist alles richtig. Aber ich bekomme die Prozentanzeige nicht korrekt an FHEM übermittelt.
Da habe ich auch versucht das über einen HMCCUCHN zu machen..
HMCCUDEV meldet "Cannot detect IO device"
Was ich meine ist wenn ich den Rollladen in der Mitte stoppe, zeigt er 0% oder 100% an kommt auf die Richtung an in welche ich vorher gefahren bin.
Zitat von: SamNitro am 20 April 2021, 20:00:39
100% ist bei mir offen, so zeigt er das in der Homematic an. Also da ist alles richtig. Aber ich bekomme die Prozentanzeige nicht korrekt an FHEM übermittelt.
Was ich meine ist wenn ich den Rollladen in der Mitte stoppe, zeigt er 0% oder 100% an kommt auf die Richtung an in welche ich vorher gefahren bin.
Ist ein Bug.
Hi,
ich hab eine Alarmsirne als HMCCUCHN angelegt.
Ich kann Licht und Sirene an machen. Möchte jedoch auch die Dauer des Alarms verändern.
Ich denke es geht über die Einstellung Duration. Ich komme jedoch mit der Syntax nicht klar un dkonnte im Forum und der Commandref dazu nicht finden.
Ich habe verschiedene Einstellungen versucht
set sirene duration duration { 180 } oder
set sirene duration duration {0,180,0 }
, bekomme aber meistens so Fehler wir :
PERL WARNING: Argument "20,20,20" isn't numeric in numeric lt (<) at ./FHEM/88_HMCCU.pm line 8696.
2021.04.23 00:17:33.341 1: HMCCUCHN [HmIP_ASIR_O_00209A49A22D14] HMCCUCHN: HmIP_ASIR_O_00209A49A22D14 Missing parameter unit. Usage: set HmIP_ASIR_O_00209A49A22D14 duration duration {S,M,H}
2021.04.23 00:19:15.348 1: PERL WARNING: Argument "{0,2,0}" isn't numeric in numeric lt (<) at ./FHEM/88_HMCCU.pm line 8696.
2021.04.23 00:19:15.348 1: HMCCUCHN [HmIP_ASIR_O_00209A49A22D14] HMCCUCHN: HmIP_ASIR_O_00209A49A22D14 Missing parameter unit. Usage: set HmIP_ASIR_O_00209A49A22D14 duration duration {S,M,H}
2021.04.23 00:20:32.862 1: HMCCUCHN [HmIP_ASIR_O_00209A49A22D14] HMCCUCHN: HmIP_ASIR_O_00209A49A22D14 Illegal value {180}. Use one of S,M,H
2021.04.23 00:23:30.563 1: PERL WARNING: Argument "duration{0:3:0}" isn't numeric in numeric lt (<) at ./FHEM/88_HMCCU.pm line 8696.
2021.04.23 00:23:30.563 1: HMCCUCHN [HmIP_ASIR_O_00209A49A22D14] HMCCUCHN: HmIP_ASIR_O_00209A49A22D14 Missing parameter unit. Usage: set HmIP_ASIR_O_00209A49A22D14 duration duration {S,M,H}
2021.04.23 00:23:48.706 1: HMCCUCHN [HmIP_ASIR_O_00209A49A22D14] HMCCUCHN: HmIP_ASIR_O_00209A49A22D14 Illegal value {0:3:0}. Use one of S,M,H
2021.04.23 00:24:29.828 1: PERL WARNING: Argument "duration{180s}" isn't numeric in numeric lt (<) at ./FHEM/88_HMCCU.pm line 8696.
2021.04.23 00:24:29.829 1: HMCCUCHN [HmIP_ASIR_O_00209A49A22D14] HMCCUCHN: HmIP_ASIR_O_00209A49A22D14 Missing parameter unit. Usage: set HmIP_ASIR_O_00209A49A22D14 duration duration {S,M,H}
2021.04.23 00:24:55.308 1: HMCCUCHN [HmIP_ASIR_O_00209A49A22D14] HMCCUCHN: HmIP_ASIR_O_00209A49A22D14 Illegal value {180s}. Use one of S,M,H
@ZAP : Kannst du mir sagen wie die richtige Syntax ist - danke ?
VG,
Andreas.
Beispiel:
set GA_Sirene_H datapoint 3.ACOUSTIC_ALARM_SELECTION 1 3.OPTICAL_ALARM_SELECTION 0 3.DURATION_UNIT 0 3.DURATION_VALUE 3
Zitat von: Ralf W. am 23 April 2021, 07:34:37
Beispiel:
set GA_Sirene_H datapoint 3.ACOUSTIC_ALARM_SELECTION 1 3.OPTICAL_ALARM_SELECTION 0 3.DURATION_UNIT 0 3.DURATION_VALUE 3
Hi - ja ich hatte so ein Beispiel auch schon gesehen.
Zap hat aber in der WebOberfläche von FHEM die Möglichkeit bei den HMCCUCHN zur Sirene die Duration einzustellen - doch da fehlt irgendwie die Info zur Syntax. Ich hoffte damit das Zusammenbauen des Befehls vereinfacht nutzen zu können.
Hast du da ein evtl. ein Beispiel zu ?
Danke und Gruss
set sirene duration 180 s
oder
set sirene duration 180s
müsste funktionieren
Habe für die Rollos einen HMCCUDEV angelegt weil ich sonst gar keine Anzeige hatte.
Was leider auch nicht geht ist ein
Zitatset Rollo 100
Es muss unbedingt ein pct mitgegeben werden, bei eltako und duofern ging das. Kann man das mit einbauen?
Internals:
DEF 00165BE99E4952 forceDev
FUUID 608077a4-f33f-19ae-cca6-c6fb76f0cb7f2661
IODev d_ccu
NAME HmIPW_Rollo_Wohnzimmer
NR 14096
STATE 100
TYPE HMCCUDEV
ccuaddr 00165BE99E4952
ccudevstate active
ccuif HmIP-RF
ccuname HmIPW-04-DRBL4-Keller
ccurolectrl BLIND_VIRTUAL_RECEIVER
ccurolestate BLIND_TRANSMITTER
ccusubtype DRBL4
ccutype HmIPW-DRBL4
readonly no
receiver ccu:HmIPW-06-DRI32-Keller
sender ccu:HmIPW-06-DRI32-Keller
Helper:
DBLOG:
state:
DBLogging:
TIME 1619201171.96544
VALUE 100
READINGS:
2021-04-23 21:31:07 1.ACTIVITY_STATE STABLE
2021-04-23 21:31:07 1.LEVEL 100
2021-04-23 21:31:07 1.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:07 1.LEVEL_STATUS NORMAL
2021-04-23 21:31:07 1.PROCESS STABLE
2021-04-23 21:31:07 1.SECTION_STATUS UNKNOWN
2021-04-23 21:31:07 10.ACTIVITY_STATE STABLE
2021-04-23 21:31:07 10.LEVEL open
2021-04-23 21:31:07 10.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:07 10.LEVEL_STATUS NORMAL
2021-04-23 21:31:07 10.PROCESS STABLE
2021-04-23 21:31:07 10.SECTION 4
2021-04-23 21:31:07 10.SECTION_STATUS NORMAL
2021-04-23 21:31:09 11.ACTIVITY_STATE STABLE
2021-04-23 21:31:09 11.LEVEL closed
2021-04-23 21:31:09 11.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:09 11.LEVEL_STATUS NORMAL
2021-04-23 21:31:09 11.PROCESS STABLE
2021-04-23 21:31:09 11.SECTION 0
2021-04-23 21:31:09 11.SECTION_STATUS NORMAL
2021-04-23 21:31:08 12.ACTIVITY_STATE STABLE
2021-04-23 21:31:08 12.LEVEL closed
2021-04-23 21:31:08 12.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:08 12.LEVEL_STATUS NORMAL
2021-04-23 21:31:08 12.PROCESS STABLE
2021-04-23 21:31:08 12.SECTION 0
2021-04-23 21:31:08 12.SECTION_STATUS NORMAL
2021-04-23 21:31:08 13.ACTIVITY_STATE STABLE
2021-04-23 21:31:08 13.LEVEL 100
2021-04-23 21:31:08 13.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:08 13.LEVEL_STATUS NORMAL
2021-04-23 21:31:08 13.PROCESS STABLE
2021-04-23 21:31:08 13.SECTION_STATUS UNKNOWN
2021-04-23 21:31:08 14.ACTIVITY_STATE STABLE
2021-04-23 21:31:08 14.LEVEL open
2021-04-23 21:31:08 14.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:08 14.LEVEL_STATUS NORMAL
2021-04-23 21:31:08 14.PROCESS STABLE
2021-04-23 21:31:08 14.SECTION 4
2021-04-23 21:31:08 14.SECTION_STATUS NORMAL
2021-04-23 21:31:09 15.ACTIVITY_STATE STABLE
2021-04-23 21:31:09 15.LEVEL closed
2021-04-23 21:31:09 15.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:09 15.LEVEL_STATUS NORMAL
2021-04-23 21:31:09 15.PROCESS STABLE
2021-04-23 21:31:09 15.SECTION 0
2021-04-23 21:31:09 15.SECTION_STATUS NORMAL
2021-04-23 21:31:08 16.ACTIVITY_STATE STABLE
2021-04-23 21:31:08 16.LEVEL closed
2021-04-23 21:31:08 16.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:08 16.LEVEL_STATUS NORMAL
2021-04-23 21:31:08 16.PROCESS STABLE
2021-04-23 21:31:08 16.SECTION 0
2021-04-23 21:31:08 16.SECTION_STATUS NORMAL
2021-04-23 21:31:07 17.WEEK_PROGRAM_CHANNEL_LOCKS 0
2021-04-23 21:31:07 2.ACTIVITY_STATE STABLE
2021-04-23 21:31:07 2.LEVEL open
2021-04-23 21:31:07 2.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:07 2.LEVEL_STATUS NORMAL
2021-04-23 21:31:07 2.PROCESS STABLE
2021-04-23 21:31:07 2.SECTION 4
2021-04-23 21:31:07 2.SECTION_STATUS NORMAL
2021-04-23 21:31:09 3.ACTIVITY_STATE STABLE
2021-04-23 21:31:09 3.LEVEL closed
2021-04-23 21:31:09 3.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:09 3.LEVEL_STATUS NORMAL
2021-04-23 21:31:09 3.PROCESS STABLE
2021-04-23 21:31:09 3.SECTION 0
2021-04-23 21:31:09 3.SECTION_STATUS NORMAL
2021-04-23 21:31:07 4.ACTIVITY_STATE STABLE
2021-04-23 21:31:07 4.LEVEL closed
2021-04-23 21:31:07 4.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:07 4.LEVEL_STATUS NORMAL
2021-04-23 21:31:07 4.PROCESS STABLE
2021-04-23 21:31:07 4.SECTION 0
2021-04-23 21:31:07 4.SECTION_STATUS NORMAL
2021-04-23 21:31:07 5.ACTIVITY_STATE STABLE
2021-04-23 21:31:07 5.LEVEL 100
2021-04-23 21:31:07 5.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:07 5.LEVEL_STATUS NORMAL
2021-04-23 21:31:07 5.PROCESS STABLE
2021-04-23 21:31:07 5.SECTION_STATUS UNKNOWN
2021-04-23 21:31:07 6.ACTIVITY_STATE STABLE
2021-04-23 21:31:07 6.LEVEL open
2021-04-23 21:31:07 6.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:07 6.LEVEL_STATUS NORMAL
2021-04-23 21:31:07 6.PROCESS STABLE
2021-04-23 21:31:07 6.SECTION 4
2021-04-23 21:31:07 6.SECTION_STATUS NORMAL
2021-04-23 21:31:09 7.ACTIVITY_STATE STABLE
2021-04-23 21:31:09 7.LEVEL closed
2021-04-23 21:31:09 7.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:09 7.LEVEL_STATUS NORMAL
2021-04-23 21:31:09 7.PROCESS STABLE
2021-04-23 21:31:09 7.SECTION 0
2021-04-23 21:31:09 7.SECTION_STATUS NORMAL
2021-04-23 21:31:07 8.ACTIVITY_STATE STABLE
2021-04-23 21:31:07 8.LEVEL closed
2021-04-23 21:31:07 8.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:07 8.LEVEL_STATUS NORMAL
2021-04-23 21:31:07 8.PROCESS STABLE
2021-04-23 21:31:07 8.SECTION 0
2021-04-23 21:31:07 8.SECTION_STATUS NORMAL
2021-04-23 21:31:08 9.ACTIVITY_STATE STABLE
2021-04-23 21:31:08 9.LEVEL 100
2021-04-23 21:31:08 9.LEVEL_2_STATUS UNKNOWN
2021-04-23 21:31:08 9.LEVEL_STATUS NORMAL
2021-04-23 21:31:08 9.PROCESS STABLE
2021-04-23 21:31:08 9.SECTION_STATUS UNKNOWN
2021-04-23 21:31:09 activity alive
2021-04-23 21:31:07 control open
2021-04-23 21:31:09 devstate ok
2021-04-23 21:31:09 hmstate 100
2021-04-23 21:31:07 pct 100
2021-04-23 21:31:07 state 100
hmccu:
channels 18
devspec 00165BE99E4952
forcedev 1
nodefaults 0
role 0:MAINTENANCE,1:BLIND_TRANSMITTER,2:BLIND_VIRTUAL_RECEIVER,3:BLIND_VIRTUAL_RECEIVER,4:BLIND_VIRTUAL_RECEIVER,5:BLIND_TRANSMITTER,6:BLIND_VIRTUAL_RECEIVER,7:BLIND_VIRTUAL_RECEIVER,8:BLIND_VIRTUAL_RECEIVER,9:BLIND_TRANSMITTER,10:BLIND_VIRTUAL_RECEIVER,11:BLIND_VIRTUAL_RECEIVER,12:BLIND_VIRTUAL_RECEIVER,13:BLIND_TRANSMITTER,14:BLIND_VIRTUAL_RECEIVER,15:BLIND_VIRTUAL_RECEIVER,16:BLIND_VIRTUAL_RECEIVER,17:BLIND_WEEK_PROFILE
semDefaults 0
cmdlist:
get
set down up close:noArg stop:noArg open:noArg pct down up close:noArg stop:noArg open:noArg pct down up close:noArg stop:noArg open:noArg pct down up close:noArg stop:noArg open:noArg pct down up close:noArg stop:noArg open:noArg pct down up close:noArg stop:noArg open:noArg pct down up close:noArg stop:noArg open:noArg pct down up close:noArg stop:noArg open:noArg pct down up close:noArg stop:noArg open:noArg pct down up close:noArg stop:noArg open:noArg pct down up close:noArg stop:noArg open:noArg pct down up close:noArg stop:noArg open:noArg pct
control:
chn 6
dpt LEVEL
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
OSVAL 23.0
OVAL 23.0
SVAL 23.0
VAL 23.0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_UNDERVOLTAGE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 24.2
OVAL 24.2
SVAL 24.2
VAL 24.2
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
1.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
1.LEVEL:
VALUES:
OSVAL 100
OVAL 1.0
SVAL 100
VAL 1.0
1.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
1.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
1.SECTION_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
10.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
10.LEVEL:
VALUES:
OSVAL open
OVAL 1.0
SVAL open
VAL 1.0
10.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
10.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
10.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
10.SECTION:
VALUES:
OSVAL 4
OVAL 4
SVAL 4
VAL 4
10.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
11.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
11.LEVEL:
VALUES:
OSVAL closed
OVAL 0.0
SVAL closed
VAL 0.0
11.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
11.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
11.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
11.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
11.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
12.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
12.LEVEL:
VALUES:
OSVAL closed
OVAL 0.0
SVAL closed
VAL 0.0
12.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
12.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
12.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
12.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
12.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
13.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
13.LEVEL:
VALUES:
OSVAL 100
OVAL 1.0
SVAL 100
VAL 1.0
13.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
13.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
13.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
13.SECTION_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
14.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
14.LEVEL:
VALUES:
OSVAL open
OVAL 1.0
SVAL open
VAL 1.0
14.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
14.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
14.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
14.SECTION:
VALUES:
OSVAL 4
OVAL 4
SVAL 4
VAL 4
14.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
15.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
15.LEVEL:
VALUES:
OSVAL closed
OVAL 0.0
SVAL closed
VAL 0.0
15.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
15.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
15.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
15.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
15.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
16.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
16.LEVEL:
VALUES:
OSVAL closed
OVAL 0.0
SVAL closed
VAL 0.0
16.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
16.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
16.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
16.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
16.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
17.WEEK_PROGRAM_CHANNEL_LOCKS:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
2.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
2.LEVEL:
VALUES:
OSVAL open
OVAL 1.0
SVAL open
VAL 1.0
2.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
2.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
2.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
2.SECTION:
VALUES:
OSVAL 4
OVAL 4
SVAL 4
VAL 4
2.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
3.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
3.LEVEL:
VALUES:
OSVAL closed
OVAL 0.0
SVAL closed
VAL 0.0
3.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
3.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
3.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
3.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
4.LEVEL:
VALUES:
OSVAL closed
OVAL 0.0
SVAL closed
VAL 0.0
4.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
4.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
4.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
5.LEVEL:
VALUES:
OSVAL 100
OVAL 1.0
SVAL 100
VAL 1.0
5.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
5.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
5.SECTION_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
6.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
6.LEVEL:
VALUES:
OSVAL open
OVAL 1.0
SVAL open
VAL 1.0
6.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
6.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
6.SECTION:
VALUES:
OSVAL 4
OVAL 4
SVAL 4
VAL 4
6.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
7.LEVEL:
VALUES:
OSVAL closed
OVAL 0.0
SVAL closed
VAL 0.0
7.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
7.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
7.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
7.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
8.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
8.LEVEL:
VALUES:
OSVAL closed
OVAL 0.0
SVAL closed
VAL 0.0
8.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
8.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
8.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
8.SECTION:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
8.SECTION_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
9.ACTIVITY_STATE:
VALUES:
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
9.LEVEL:
VALUES:
OSVAL 100
OVAL 1.0
SVAL 100
VAL 1.0
9.LEVEL_2_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
9.LEVEL_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
9.PROCESS:
VALUES:
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
9.SECTION_STATUS:
VALUES:
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
roleCmds:
get:
set:
close:
channel ?
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:0
usage close
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
unit 100%
down:
channel ?
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=-20
usage down [delta]
subcmd:
000:
args -20
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
unit 100%
open:
channel ?
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:100
usage open
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
unit 100%
pct:
channel ?
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?level
usage pct level
subcmd:
000:
args
dpt LEVEL
fnc
max 1.01
min 0.0
parname level
partype 2
ps VALUES
unit 100%
stop:
channel ?
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:STOP:1
usage stop
subcmd:
000:
args 1
dpt STOP
fnc
max 1
min 0
parname STOP
partype 3
ps VALUES
unit
up:
channel ?
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=+20
usage up [delta]
subcmd:
000:
args +20
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
unit 100%
state:
chn 5
dpt LEVEL
Attributes:
DbLogInclude state
IODev d_ccu
cmdIcon open:fts_shutter_up stop:fts_shutter_manual close:fts_shutter_down
controlchannel 6
event-on-change-reading .*
room Homematic
statechannel 5
substexcl pct
userattr structexclude structure_rollo_unten structure_rollo_unten_map
webCmd pct:open:close:stop
widgetOverride pct:slider,0,10,100
Zitat von: kjmEjfu am 23 April 2021, 13:13:24
set sirene duration 180 s
oder
set sirene duration 180s
müsste funktionieren
Ich habe es jetzt mal durchprobiert.
Also es muss heißen
set sirene duration 59 S ( S für sekunden - 180 geht nicht - logisch es gibt ja dafür die Minuten 3 M)
set sirene duration 2 M funktioniert ( Dauer dann 2 Minuten )
set sirene 30 S 2 M ( Dauer dann 2 Minuten 30 Sekunden)
Danke für den Denkanstoss !
Hi,
ich habe mit der Homematic-IP Sirene ein PRoblem mit der Aktualisierung des Sabotage Schalters in Fhem.
Wenn der Sabotage Schalter gedrückt wird bekommt das Fhem mit und einige Readings aktualisieren sich ( d.h. das System reagiert auf das drücken / loslassen des Schalters ) nur aktualisiert sich das Sabotage Reading leider nicht in Fhem.
Ich habe mal das Listing der CCU Beschreibung hier:
listing der Sirene
Internals:
DEF 00209A49A22D14:3
FUUID 6054bd35-f33f-fb0e-c296-f9c580b8e579cc4a
IODev myCCU
NAME HmIP_ASIR_O_00209A49A22D14
NR 392
STATE false
TYPE HMCCUCHN
ccuaddr 00209A49A22D14:3
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-ASIR-O 00209A49A22D14:3
ccurolectrl ALARM_SWITCH_VIRTUAL_RECEIVER
ccurolestate ALARM_SWITCH_VIRTUAL_RECEIVER
ccusubtype ASIR-O
ccutype HmIP-ASIR-O
chntype ?
firmware ?
readonly no
READINGS:
2021-03-21 19:16:35 0.CONFIG_PENDING false
2021-03-21 19:16:35 0.DUTY_CYCLE false
2021-03-21 19:16:35 0.ERROR_BAD_RECHARGEABLE_BATTERY_HEALTH false
2021-03-21 19:16:35 0.ERROR_CODE 0
2021-03-21 19:16:35 0.INSTALL_TEST true
2021-03-21 19:16:35 0.LOW_BAT false
2021-03-21 19:16:35 0.OPERATING_VOLTAGE 4.000000
2021-03-21 19:16:35 0.OPERATING_VOLTAGE_STATUS 0
2021-03-21 19:16:35 0.RSSI_DEVICE 194
2021-03-21 19:16:35 0.RSSI_PEER 0
2021-03-21 19:16:35 0.SABOTAGE false
2021-03-21 19:16:35 0.UNREACH false
2021-03-21 19:16:35 0.UPDATE_PENDING false
2021-03-21 19:16:35 3.ACOUSTIC_ALARM_ACTIVE false
2021-03-21 19:16:35 3.OPTICAL_ALARM_ACTIVE false
2021-04-25 00:38:19 ACOUSTIC_ALARM_ACTIVE false
2021-04-25 00:38:19 OPTICAL_ALARM_ACTIVE false
2021-04-25 00:28:14 ZONE_1_ACTIVE 0
2021-04-25 00:28:14 ZONE_1_ALARM 0
2021-04-25 00:28:14 ZONE_2_ACTIVE 0
2021-04-25 00:28:14 ZONE_2_ALARM 0
2021-04-25 00:28:14 ZONE_3_ACTIVE 0
2021-04-25 00:28:14 ZONE_3_ALARM 0
2021-04-25 00:28:14 ZONE_4_ACTIVE 0
2021-04-25 00:28:14 ZONE_4_ALARM 0
2021-04-25 00:28:14 ZONE_5_ACTIVE 0
2021-04-25 00:28:14 ZONE_5_ALARM 0
2021-04-25 00:28:14 ZONE_6_ACTIVE 0
2021-04-25 00:28:14 ZONE_6_ALARM 0
2021-04-25 00:28:14 ZONE_7_ACTIVE 0
2021-04-25 00:28:14 ZONE_7_ALARM 0
2021-04-25 00:38:19 activity alive
2021-04-25 00:38:19 battery ok
2021-04-25 00:38:19 devstate ok
2021-04-25 00:38:19 hmstate false
2021-04-25 00:38:19 rssidevice -69
2021-04-25 00:38:19 rssipeer 0
2021-04-25 00:38:19 state false
hmccu:
channels 1
devspec 00209A49A22D14:3
nodefaults 1
role 3:ALARM_SWITCH_VIRTUAL_RECEIVER
semDefaults 0
cmdlist:
get
set duration acousticAlarm:DISABLE_ACOUSTIC_SIGNAL,FREQUENCY_RISING,FREQUENCY_FALLING,FREQUENCY_RISING_AND_FALLING,FREQUENCY_ALTERNATING_LOW_HIGH,FREQUENCY_ALTERNATING_LOW_MID_HIGH,FREQUENCY_HIGHON_OFF,FREQUENCY_HIGHON_LONGOFF,FREQUENCY_LOWON_OFF_HIGHON_OFF,FREQUENCY_LOWON_LONGOFF_HIGHON_LONGOFF,LOW_BATTERY,DISARMED,INTERNALLY_ARMED,EXTERNALLY_ARMED,DELAYED_INTERNALLY_ARMED,DELAYED_EXTERNALLY_ARMED,EVENT,ERROR opticalAlarm:DISABLE_OPTICAL_SIGNAL,BLINKING_ALTERNATELY_REPEATING,BLINKING_BOTH_REPEATING,DOUBLE_FLASHING_REPEATING,FLASHING_BOTH_REPEATING,CONFIRMATION_SIGNAL_0,CONFIRMATION_SIGNAL_1,CONFIRMATION_SIGNAL_2
control:
chn 3
dpt ACOUSTIC_ALARM_SELECTION
dp:
0.APPLICATION_VERSION:
SERVICE:
OSVAL 1.0.6
OVAL 1.0.6
SVAL 1.0.6
VAL 1.0.6
VALUES:
0.ARR_TIMEOUT:
MASTER:
OSVAL 10
OVAL 10
SVAL 10
VAL 10
VALUES:
0.BOOTLOADER_VERSION:
SERVICE:
OSVAL 1.8.0
OVAL 1.8.0
SVAL 1.8.0
VAL 1.8.0
VALUES:
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.CYCLIC_INFO_MSG:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
0.CYCLIC_INFO_MSG_DIS:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
0.CYCLIC_INFO_MSG_DIS_UNCHANGED:
MASTER:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
0.CYCLIC_INFO_MSG_OVERDUE_THRESHOLD:
MASTER:
OSVAL 2
OVAL 2
SVAL 2
VAL 2
VALUES:
0.DUTYCYCLE_LIMIT:
MASTER:
OSVAL 180
OVAL 180
SVAL 180
VAL 180
VALUES:
0.DUTY_CYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ENABLE_ROUTING:
MASTER:
OSVAL true
OVAL 1
SVAL true
VAL 1
VALUES:
0.ERROR_BAD_RECHARGEABLE_BATTERY_HEALTH:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
OSVAL 0
OVAL 0
SVAL 1
VAL 1
0.HARDWARE_VERSION:
SERVICE:
OSVAL 4
OVAL 4
SVAL 4
VAL 4
VALUES:
0.INSTALL_TEST:
VALUES:
OSVAL true
OVAL true
SVAL true
VAL true
0.LOCAL_RESET_DISABLED:
MASTER:
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
0.LOW_BAT:
VALUES:
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.LOW_BAT_LIMIT:
MASTER:
OSVAL 2.2
OVAL 2.2
SVAL 2.2
VAL 2.2
VALUES:
0.OPERATING_VOLTAGE:
VALUES:
OSVAL 4.0
OVAL 4.0
SVAL 4.0
VAL 4.0
0.OPERATING_VOLTAGE_STATUS:
VALUES:
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.OS_VERSION:
SERVICE:
OSVAL 1.42.2
OVAL 1.42.2
SVAL 1.42.2
VAL 1.42.2
VALUES:
0.RSSI_DEVICE:
VALUES:
OSVAL -71
OVAL -71
SVAL -69
VAL -69
0.RSSI_PEER:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.SABOTAGE:
VALUES:
OSVAL false
OVAL 0
SVAL true
VAL 1
0.TEST_STATUS:
SERVICE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
3.ACOUSTIC_ALARM_ACTIVE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
3.APPLICATION_VERSION:
SERVICE:
OSVAL 1.0.6
OVAL 1.0.6
SVAL 1.0.6
VAL 1.0.6
VALUES:
3.BOOTLOADER_VERSION:
SERVICE:
OSVAL 1.8.0
OVAL 1.8.0
SVAL 1.8.0
VAL 1.8.0
VALUES:
3.EVENT_DELAY_UNIT:
MASTER:
OSVAL S
OVAL 1
SVAL S
VAL 1
VALUES:
3.EVENT_DELAY_VALUE:
MASTER:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
3.EVENT_RANDOMTIME_UNIT:
MASTER:
OSVAL S
OVAL 1
SVAL S
VAL 1
VALUES:
3.EVENT_RANDOMTIME_VALUE:
MASTER:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
3.HARDWARE_VERSION:
SERVICE:
OSVAL 4
OVAL 4
SVAL 4
VAL 4
VALUES:
3.OPTICAL_ALARM_ACTIVE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
3.OS_VERSION:
SERVICE:
OSVAL 1.42.2
OVAL 1.42.2
SVAL 1.42.2
VAL 1.42.2
VALUES:
3.TEST_STATUS:
SERVICE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
3.ZONE_1_ACTIVE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_1_ALARM:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_2_ACTIVE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_2_ALARM:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_3_ACTIVE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_3_ALARM:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_4_ACTIVE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_4_ALARM:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_5_ACTIVE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_5_ALARM:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_6_ACTIVE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_6_ALARM:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_7_ACTIVE:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ZONE_7_ALARM:
VALUES:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
d.APPLICATION_VERSION:
SERVICE:
OSVAL 1.0.6
OVAL 1.0.6
SVAL 1.0.6
VAL 1.0.6
VALUES:
d.BOOTLOADER_VERSION:
SERVICE:
OSVAL 1.8.0
OVAL 1.8.0
SVAL 1.8.0
VAL 1.8.0
VALUES:
d.HARDWARE_VERSION:
SERVICE:
OSVAL 4
OVAL 4
SVAL 4
VAL 4
VALUES:
d.OS_VERSION:
SERVICE:
OSVAL 1.42.2
OVAL 1.42.2
SVAL 1.42.2
VAL 1.42.2
VALUES:
d.TEST_STATUS:
SERVICE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
intvalues:
duration 3
unit 1
roleCmds:
get:
set:
acousticAlarm:
channel 3
role ALARM_SWITCH_VIRTUAL_RECEIVER
subcount 4
syntax V:ACOUSTIC_ALARM_SELECTION:#alarmMode V:OPTICAL_ALARM_SELECTION:0 V:DURATION_UNIT:0 V:DURATION_VALUE:10
usage acousticAlarm {DISABLE_ACOUSTIC_SIGNAL,FREQUENCY_RISING,FREQUENCY_FALLING,FREQUENCY_RISING_AND_FALLING,FREQUENCY_ALTERNATING_LOW_HIGH,FREQUENCY_ALTERNATING_LOW_MID_HIGH,FREQUENCY_HIGHON_OFF,FREQUENCY_HIGHON_LONGOFF,FREQUENCY_LOWON_OFF_HIGHON_OFF,FREQUENCY_LOWON_LONGOFF_HIGHON_LONGOFF,LOW_BATTERY,DISARMED,INTERNALLY_ARMED,EXTERNALLY_ARMED,DELAYED_INTERNALLY_ARMED,DELAYED_EXTERNALLY_ARMED,EVENT,ERROR}
subcmd:
000:
args DISABLE_ACOUSTIC_SIGNAL,FREQUENCY_RISING,FREQUENCY_FALLING,FREQUENCY_RISING_AND_FALLING,FREQUENCY_ALTERNATING_LOW_HIGH,FREQUENCY_ALTERNATING_LOW_MID_HIGH,FREQUENCY_HIGHON_OFF,FREQUENCY_HIGHON_LONGOFF,FREQUENCY_LOWON_OFF_HIGHON_OFF,FREQUENCY_LOWON_LONGOFF_HIGHON_LONGOFF,LOW_BATTERY,DISARMED,INTERNALLY_ARMED,EXTERNALLY_ARMED,DELAYED_INTERNALLY_ARMED,DELAYED_EXTERNALLY_ARMED,EVENT,ERROR
dpt ACOUSTIC_ALARM_SELECTION
fnc
max 17
min 0
parname alarmMode
partype 1
ps VALUES
unit
look:
DELAYED_EXTERNALLY_ARMED 15
DELAYED_INTERNALLY_ARMED 14
DISABLE_ACOUSTIC_SIGNAL 0
DISARMED 11
ERROR 17
EVENT 16
EXTERNALLY_ARMED 13
FREQUENCY_ALTERNATING_LOW_HIGH 4
FREQUENCY_ALTERNATING_LOW_MID_HIGH 5
FREQUENCY_FALLING 2
FREQUENCY_HIGHON_LONGOFF 7
FREQUENCY_HIGHON_OFF 6
FREQUENCY_LOWON_LONGOFF_HIGHON_LONGOFF 9
FREQUENCY_LOWON_OFF_HIGHON_OFF 8
FREQUENCY_RISING 1
FREQUENCY_RISING_AND_FALLING 3
INTERNALLY_ARMED 12
LOW_BATTERY 10
001:
args 0
dpt OPTICAL_ALARM_SELECTION
fnc
max 7
min 0
parname OPTICAL_ALARM_SELECTION
partype 3
ps VALUES
unit
look:
BLINKING_ALTERNATELY_REPEATING 1
BLINKING_BOTH_REPEATING 2
CONFIRMATION_SIGNAL_0 5
CONFIRMATION_SIGNAL_1 6
CONFIRMATION_SIGNAL_2 7
DISABLE_OPTICAL_SIGNAL 0
DOUBLE_FLASHING_REPEATING 3
FLASHING_BOTH_REPEATING 4
002:
args 0
dpt DURATION_UNIT
fnc
max 2
min 0
parname DURATION_UNIT
partype 3
ps VALUES
unit
look:
H 2
M 1
S 0
003:
args 10
dpt DURATION_VALUE
fnc
max 16343
min 0
parname DURATION_VALUE
partype 3
ps VALUES
unit
duration:
channel 3
role ALARM_SWITCH_VIRTUAL_RECEIVER
subcount 2
syntax I:DURATION_VALUE:?duration I:DURATION_UNIT:#unit
usage duration duration {S,M,H}
subcmd:
000:
args
dpt DURATION_VALUE
fnc
max 16343
min 0
parname duration
partype 2
ps INTERNAL
unit
001:
args S,M,H
dpt DURATION_UNIT
fnc
max 2
min 0
parname unit
partype 1
ps INTERNAL
unit
look:
H 2
M 1
S 0
opticalAlarm:
channel 3
role ALARM_SWITCH_VIRTUAL_RECEIVER
subcount 4
syntax V:OPTICAL_ALARM_SELECTION:#alarmMode V:ACOUSTIC_ALARM_SELECTION:0 V:DURATION_UNIT:*unit=0 V:DURATION_VALUE:*duration=10
usage opticalAlarm {DISABLE_OPTICAL_SIGNAL,BLINKING_ALTERNATELY_REPEATING,BLINKING_BOTH_REPEATING,DOUBLE_FLASHING_REPEATING,FLASHING_BOTH_REPEATING,CONFIRMATION_SIGNAL_0,CONFIRMATION_SIGNAL_1,CONFIRMATION_SIGNAL_2}
subcmd:
000:
args DISABLE_OPTICAL_SIGNAL,BLINKING_ALTERNATELY_REPEATING,BLINKING_BOTH_REPEATING,DOUBLE_FLASHING_REPEATING,FLASHING_BOTH_REPEATING,CONFIRMATION_SIGNAL_0,CONFIRMATION_SIGNAL_1,CONFIRMATION_SIGNAL_2
dpt OPTICAL_ALARM_SELECTION
fnc
max 7
min 0
parname alarmMode
partype 1
ps VALUES
unit
look:
BLINKING_ALTERNATELY_REPEATING 1
BLINKING_BOTH_REPEATING 2
CONFIRMATION_SIGNAL_0 5
CONFIRMATION_SIGNAL_1 6
CONFIRMATION_SIGNAL_2 7
DISABLE_OPTICAL_SIGNAL 0
DOUBLE_FLASHING_REPEATING 3
FLASHING_BOTH_REPEATING 4
001:
args 0
dpt ACOUSTIC_ALARM_SELECTION
fnc
max 17
min 0
parname ACOUSTIC_ALARM_SELECTION
partype 3
ps VALUES
unit
look:
DELAYED_EXTERNALLY_ARMED 15
DELAYED_INTERNALLY_ARMED 14
DISABLE_ACOUSTIC_SIGNAL 0
DISARMED 11
ERROR 17
EVENT 16
EXTERNALLY_ARMED 13
FREQUENCY_ALTERNATING_LOW_HIGH 4
FREQUENCY_ALTERNATING_LOW_MID_HIGH 5
FREQUENCY_FALLING 2
FREQUENCY_HIGHON_LONGOFF 7
FREQUENCY_HIGHON_OFF 6
FREQUENCY_LOWON_LONGOFF_HIGHON_LONGOFF 9
FREQUENCY_LOWON_OFF_HIGHON_OFF 8
FREQUENCY_RISING 1
FREQUENCY_RISING_AND_FALLING 3
INTERNALLY_ARMED 12
LOW_BATTERY 10
002:
args 0
dpt DURATION_UNIT
fnc
max 2
min 0
parname unit
partype 4
ps VALUES
unit
look:
H 2
M 1
S 0
003:
args 10
dpt DURATION_VALUE
fnc
max 16343
min 0
parname duration
partype 4
ps VALUES
unit
state:
chn 3
dpt ACOUSTIC_ALARM_ACTIVE
Attributes:
IODev myCCU
room HMCCU
Und ein Teillisting von myCCU (das ganze Listing habe ich gekürzt weil es über viele Seiten geht...
Internals:
CCUNum 1
Clients :HMCCUDEV:HMCCUCHN:HMCCURPCPROC:
DEF 192.168.178.22
FUUID 6031b82c-f33f-fb0e-e7d2-cb6a20bba1ceae12
NAME myCCU
NOTIFYDEV global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
NR 379
NTFY_ORDER 50-myCCU
RPCState running
STATE running/OK
TYPE HMCCU
ccuaddr BidCoS-RF
ccuchannels 115
ccudevices 6
ccuif BidCos-RF
ccuinterfaces HmIP-RF,BidCos-RF,VirtualDevices
ccuip 192.168.178.22
ccuname HM-RCV-50 BidCoS-RF
ccustate active
ccutype CCU2/3
config 4.8.017
firmware 3.57.4.20210320
host 192.168.178.22
prot http
version 4.4.060
READINGS:
2021-04-05 15:31:21 count_channels 115
2021-04-05 15:31:21 count_devices 6
2021-04-05 15:31:21 count_groups 0
2021-04-05 15:31:21 count_interfaces 3
2021-04-05 15:31:21 count_programs 2
2021-02-26 01:02:01 iface_addr_1 3014F711A0001F5A4993D776
2021-02-26 01:02:01 iface_addr_2 QEQ0683894
2021-02-26 01:02:01 iface_conn_1 1
2021-02-26 01:02:01 iface_conn_2 1
2021-02-26 01:02:01 iface_ducy_1 1
2021-02-26 01:02:01 iface_ducy_2 1
2021-02-26 01:02:01 iface_type_1 HMIP_CCU2
2021-02-26 01:02:01 iface_type_2 CCU2
2021-04-05 15:34:05 rpcstate running
2021-04-05 15:34:05 state OK
hmccu:
ccuDevList "HM-RC-4-3#NEQ1707423","HM-RCV-50#BidCoS-RF","HmIP-ASIR-O#00209A49A22D14","HmIP-RCV-50#HmIP-RCV-1","HmIP-SWDM#00155D898A8946","RPI-RF-MOD#001F5A4993D776"
defaults 0
evtime 0
evtimeout 0
rpccount 0
rpcports 9292,2010,2001
updatetime 1617629478.09258
adr:
HmIP-ASIR-O 00209A49A22D14:
address 00209A49A22D14
addtype dev
valid 1
HmIP-ASIR-O 00209A49A22D14:0:
address 00209A49A22D14:0
addtype chn
valid 1
HmIP-ASIR-O 00209A49A22D14:1:
address 00209A49A22D14:1
addtype chn
valid 1
HmIP-ASIR-O 00209A49A22D14:2:
address 00209A49A22D14:2
addtype chn
valid 1
HmIP-ASIR-O 00209A49A22D14:3:
address 00209A49A22D14:3
addtype chn
valid 1
Ist das möglicherweise ein Bug ?
Kann ich ausser nochmaliger Neuanlage (was ich schon gemacht habe ) etwas machen was das evtl. beseitigt ?
VG
Zitat von: essera am 23 April 2021, 23:50:56
set sirene 30 S 2 M ( Dauer dann 2 Minuten 30 Sekunden)
Ich kann mir nicht vorstellen, dass das funktioniert. "set duration" akzeptiert eigentlich nur eine Zahl gefolgt von einer Einheit.
Grundsätzlich: Diese speziellen, nur auf einen Typ bezogenen Befehle sind nicht alle in der Commandref dokumentiert. Im Zweifel einfach den Befehl ohne Parameter aufrufen, dann wird die Syntax angezeigt.
Zitat von: SamNitro am 23 April 2021, 21:49:24
Habe für die Rollos einen HMCCUDEV angelegt weil ich sonst gar keine Anzeige hatte.
Was leider auch nicht geht ist ein Es muss unbedingt ein pct mitgegeben werden, bei eltako und duofern ging das. Kann man das mit einbauen?
Ich denke mal darüber nach. Wenn ich eine Lösung finde, die zum generischen Ansatz von HMCCU passt, lässt sich das machen. Vielleicht eine Art "Default-Befehl", der ausgeführt wird, wenn kein Befehl angegeben wird.
Momentan hat allerdings die Fehlerbehebung oberste Priorität, damit die Beta endlich zur Standardversion werden kann.
Viele HmIP-Wired Aktoren müssen zwingend als HMCCUDEV angelegt werden, da die Steuerung über mehr als einen Kanal erfolgt und außerdem mit einem Aktor meist mehrere unabhängige Rollläden, Lichter usw. gesteuert werden.
Das empfohlene Vorgehen:
Lege für jedes mit einem Aktor zu steuernde Gerät ein HMCCUDEV an. Wenn Du also mit Deinem HmIPW-DRBL4 vier Rollläden steuern möchtest, legst Du 4 HMCCUDEV in FHEM an. In jedem der Devices setzt Du andere controldatapoint / statedatapoint Attribute (eben passend für jeden Steuerungskanal).
Das geht am besten per manueller Definition. get create und get createdev unterstützen diese Art der Aktoren derzeit noch nicht richtig.
Zitat von: zap am 27 April 2021, 07:56:33
controldatapoint / statedatapoint Attribute
Habe es am laufen allerdings nicht über die angebende Attribute sondern über statechannel/controlchannel.
Glaube zu meinen das die anderen angaben nicht funktioniert haben, werde aber nochmal testen.
Zitat von: SamNitro am 27 April 2021, 09:49:37
Habe es am laufen allerdings nicht über die angebende Attribute sondern über statechannel/controlchannel.
Glaube zu meinen das die anderen angaben nicht funktioniert haben, werde aber nochmal testen.
Beides sollte funktionieren, jedoch nur, wenn HMCCU den Kanaltyp "kennt". Die Attribute statechannel und controlchannel sind eigentlich veraltet, da man in controldatapoint und statedatapoint die Kanalnummer mit angeben kann (HMCCUDEV). Bei HMCCUCHN spielt die Kanalnummer keine Rolle, da es sowieso nur einen Kanal gibt.
Wenn Du statedatapoint und controldatapoint probierst, solltest Du die beiden anderen Attribute löschen. Die xxxdatapoint Attribute sehen dann z.B so aus:
3.LEVEL
Beim eingeben von statedatapoint fehlen in der dropdown liste ein paar Kanäle. Aber selbst wenn ich den von hand eingebe funktioniert es nicht.
Wenn ich die die Attribute statechannel und controlchannel lösche steuert er mir den 1. Kanal des Aktors an, was aber der falsche kanal ist und zeigt auch keine infos an.
Ich hänge mal die Raw infos an, wenn du ein list brauchst sag Bescheid
Funktioniert nicht:
defmod HmIPW_Rollo_Test HMCCUDEV 00165BE99E4952 forceDev
attr HmIPW_Rollo_Test userattr structexclude structure_rollo_unten structure_rollo_unten_map
attr HmIPW_Rollo_Test DbLogInclude state
attr HmIPW_Rollo_Test IODev d_ccu
attr HmIPW_Rollo_Test cmdIcon open:fts_shutter_up stop:fts_shutter_manual close:fts_shutter_down
attr HmIPW_Rollo_Test controldatapoint 6.LEVEL
attr HmIPW_Rollo_Test event-on-change-reading .*
attr HmIPW_Rollo_Test room Homematic
attr HmIPW_Rollo_Test statedatapoint 5.LEVEL
attr HmIPW_Rollo_Test substexcl pct
attr HmIPW_Rollo_Test webCmd pct:open:close:stop
attr HmIPW_Rollo_Test widgetOverride pct:slider,0,10,100
Funktioniert aber NUR der slider zeigt falsch an:
defmod HmIPW_Rollo_Wohnzimmer HMCCUDEV 00165BE99E4952 forceDev
attr HmIPW_Rollo_Wohnzimmer userattr structexclude structure_rollo_unten structure_rollo_unten_map
attr HmIPW_Rollo_Wohnzimmer DbLogInclude state
attr HmIPW_Rollo_Wohnzimmer IODev d_ccu
attr HmIPW_Rollo_Wohnzimmer cmdIcon open:fts_shutter_up stop:fts_shutter_manual close:fts_shutter_down
attr HmIPW_Rollo_Wohnzimmer controlchannel 6
attr HmIPW_Rollo_Wohnzimmer event-on-change-reading .*
attr HmIPW_Rollo_Wohnzimmer room Homematic
attr HmIPW_Rollo_Wohnzimmer statechannel 5
attr HmIPW_Rollo_Wohnzimmer substexcl pct
attr HmIPW_Rollo_Wohnzimmer webCmd pct:open:close:stop
attr HmIPW_Rollo_Wohnzimmer widgetOverride pct:slider,0,10,100
hier zu sehen ist pct falsch:
setstate HmIPW_Rollo_Wohnzimmer 2021-04-27 11:49:28 hmstate 88.5
setstate HmIPW_Rollo_Wohnzimmer 2021-04-27 11:49:27 pct 0
setstate HmIPW_Rollo_Wohnzimmer 2021-04-27 11:49:27 state 88.5
Was heißt, es fehlen ein paar Kanäle? Für diesen Typ müsste statedatapoint anbieten: 5-16.LEVEL
controldatapoint müsste 6-8,10-12.14-16.LEVEL anbieten.
Die Attribute sind korrekt gesetzt.Könntest Du mal ein list vom Device machen (mit state/controldatapoint, ohne state/controlchannel)?
Der kürzt mir den post und die tags... muss ich neu machen als Datei!!!
Kurze Verständnisfrage zu ccuGetVars: Intervall und Regex müssen mit einem Doppelpunkt getrennt sein (L616), richtig?
Falls ja: Ich hab's in der Wiki-Doku ergänzt, da stand es ohne. Hab es nach einem Warning beim Reboot gesehen:
2021.04.27 17:32:52.715 1: PERL WARNING: Argument "5 homebridge.*" isn't numeric in numeric gt (>) at ./FHEM/88_HMCCU.pm line 606, <$fh> line 14.
(Da hatte ich noch HMCCU4.3 benutzt)
Was mir noch aufgefallen ist, jeden Samstag macht mein Proxmox ein Update und startet somit FHEM neu! Danach steuern meine Rollos immer erst nur den ersten Kanal vom 4Fach Aktor. erst ein get ccuconfig löst das problem.
Hallo,
Diese Meldung steht bei mir im Log
Es funktioniert, sollte auch auch nur als Info dienen.
HMCCU [d_ccu] Can't get definition of MEQ0630891:1.STATE. Ignoring command on-for-timer for device HM_Wohnzimmer_Licht
HMCCU [d_ccu] Can't get definition of MEQ0630891:1.STATE. Ignoring command on-till for device HM_Wohnzimmer_Licht
Internals:
.AttrList IODev ccucalculate ccuflags:multiple-strict,ackState,logCommand,noReadings,trace,showMasterReadings,showLinkReadings,showDeviceReadings,showServiceReadings ccureadingfilter:textField-long ccureadingformat:name,namelc,address,addresslc ccureadingname:textField-long ccuSetOnChange ccuReadingPrefix ccuscaleval ccuverify:0,1,2 ccuget:State,Value disable:0,1 hmstatevals:textField-long statevals substitute:textField-long substexcl stripnumber peer:textField-long traceFilter event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading statedatapoint:select,LEVEL controldatapoint:select,LEVEL
DEF HM_Wohnzimmer_Licht:1
FUUID 5fbfa84b-f33f-1bf6-7119-618e0d0f94ae756c
IODev d_ccu
NAME HM_Wohnzimmer_Licht
NR 462
STATE off
TYPE HMCCUCHN
ccuaddr MEQ0630891:1
ccudevstate active
ccuif BidCos-RF
ccuname HM_Wohnzimmer_Licht:1
ccurolestate DIMMER
ccusubtype HM-LC-Dim1T-FM-LF
ccutype HM-LC-Dim1T-FM-LF
chntype ?
firmware ?
readonly no
sender HM_Fernbedinung_DEV_4,ccu:HM-RCV-50 BidCoS-RF,HM_Fernbedinung_DEV_3
.attraggr:
.attreocr:
LEVEL
.attrminint:
OLDREADINGS:
READINGS:
2021-05-01 13:18:33 .AES_KEY off
2021-05-01 13:18:33 .CONFIG_PENDING false
2021-05-01 13:18:33 .DEVICE_IN_BOOTLOADER false
2021-05-01 13:18:33 .DUTYCYCLE false
2021-05-01 13:18:33 .RSSI_DEVICE -128
2021-05-01 13:18:33 .RSSI_PEER -60
2021-05-01 13:18:33 .STICKY_UNREACH false
2021-05-01 13:18:33 .UNREACH alive
2021-05-01 13:18:33 .UPDATE_PENDING false
2021-05-01 13:18:33 DIRECTION stop
2021-05-01 13:18:33 ERROR_OVERHEAT false
2021-05-01 13:18:33 ERROR_OVERLOAD false
2021-05-01 13:18:33 ERROR_REDUCED false
2021-05-01 13:18:33 INHIBIT unlocked
2021-05-01 13:18:33 LEVEL off
2021-05-01 13:18:33 WORKING false
2021-05-01 13:18:33 activity alive
2021-05-01 13:18:33 control 0
2021-05-01 13:18:33 devstate ok
2021-05-01 13:18:33 hmstate off
2021-05-01 13:18:33 rssidevice -128
2021-05-01 13:18:33 rssipeer -60
2021-05-01 13:18:33 sign off
2021-05-01 13:18:33 state off
hmccu:
channels 1
devspec HM_Wohnzimmer_Licht:1
nodefaults 1
role 1:DIMMER
semDefaults 0
cmdlist:
get
set pct off:noArg stop:noArg on:noArg toggle:noArg
control:
dpt LEVEL
dp:
0.AES_KEY:
VALUES:
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DEVICE_IN_BOOTLOADER:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTYCYCLE:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.RSSI_DEVICE:
VALUES:
OSVAL -128
OVAL -128
SVAL -128
VAL -128
0.RSSI_PEER:
VALUES:
OSVAL -60
OVAL -60
SVAL -60
VAL -60
0.STICKY_UNREACH:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
0.UNREACH:
VALUES:
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
1.DIRECTION:
VALUES:
OSVAL stop
OVAL 0
SVAL stop
VAL 0
1.ERROR_OVERHEAT:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
1.ERROR_OVERLOAD:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
1.ERROR_REDUCED:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
1.INHIBIT:
VALUES:
OSVAL unlocked
OVAL 0
SVAL unlocked
VAL 0
1.LEVEL:
VALUES:
OSVAL off
OVAL 0.000000
SVAL off
VAL 0.000000
1.WORKING:
VALUES:
OSVAL false
OVAL 0
SVAL false
VAL 0
roleCmds:
get:
set:
off:
channel 1
role DIMMER
subcount 1
syntax V:LEVEL:0
usage off
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
unit 100%
on:
channel 1
role DIMMER
subcount 1
syntax V:LEVEL:100
usage on
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
unit 100%
on-for-timer:
role DIMMER
syntax V:ON_TIME:?duration V:STATE:1
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname duration
partype 2
ps VALUES
unit s
on-till:
role DIMMER
syntax V:ON_TIME:?time V:STATE:1
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname time
partype 2
ps VALUES
unit s
pct:
channel 1
role DIMMER
subcount 3
syntax V:LEVEL:?level V:ON_TIME:?time=0.0 V:RAMP_TIME:?ramp=0.5
usage pct level [time] [ramp]
subcmd:
000:
args
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname level
partype 2
ps VALUES
unit 100%
001:
args 0.0
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname time
partype 2
ps VALUES
unit s
002:
args 0.5
dpt RAMP_TIME
fnc
max 85825945.600000
min 0.000000
parname ramp
partype 2
ps VALUES
unit s
stop:
channel 1
role DIMMER
subcount 1
syntax V:RAMP_STOP:1
usage stop
subcmd:
000:
args 1
dpt RAMP_STOP
fnc
max 1
min 0
parname RAMP_STOP
partype 3
ps VALUES
unit
state:
dpt LEVEL
Attributes:
IODev d_ccu
cmdIcon on:general_an off:general_aus
controldatapoint LEVEL
event-on-change-reading LEVEL
group Licht
room Wohnzimmer
statedatapoint LEVEL
statevals on:100,off:0
substexcl control
webCmd control
widgetOverride control:slider,0,10,100
Die Info zum Gerät.
Device channels and datapoints
DEV HM_Wohnzimmer_Licht_DEV MEQ0630891 interface=BidCos-RF type=HM-LC-Dim1T-FM-LF
CHN MEQ0630891:0 HM_Wohnzimmer_Licht_DEV:0
0.UNREACH = false {b} [RE]
0.STICKY_UNREACH = false {b} [RWE]
0.CONFIG_PENDING = false {b} [RE]
0.DUTYCYCLE = false {b} [RE]
0.RSSI_DEVICE = 1 {n} [RE]
0.RSSI_PEER = 54 {n} [RE]
0.DEVICE_IN_BOOTLOADER = false {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
0.AES_KEY = 0 {n} [R]
CHN MEQ0630891:1 HM_Wohnzimmer_Licht:1
1.LEVEL = 0.000000 {a} [RWE]
1.OLD_LEVEL = {b} [W]
1.RAMP_TIME = {f} [W]
1.ON_TIME = {f} [W]
1.RAMP_STOP = {b} [W]
1.INHIBIT = false {b} [RWE]
1.ERROR_REDUCED = false {b} [RE]
1.ERROR_OVERLOAD = false {b} [RE]
1.ERROR_OVERHEAT = false {b} [RE]
1.DIRECTION = 0 {i} [RE]
1.INSTALL_TEST = {b} [W]
1.WORKING = false {b} [RE]
Device detection:
StateDatapoint = 1.LEVEL [DIMMER]
ControlDatapoint = 1.LEVEL [DIMMER]
Recommended module for device definition: HMCCUCHN
Current state datapoint = 1.LEVEL
Current control datapoint = 1.LEVEL
Device description
Device MEQ0630891 HM_Wohnzimmer_Licht_DEV [HM-LC-Dim1T-FM-LF]
CHILDREN: MEQ0630891:0,MEQ0630891:1
FIRMWARE: 2.9
FLAGS: Visible
INTERFACE: QEQ0684974
PARAMSETS: MASTER
RF_ADDRESS: 3776739
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG
UPDATABLE: 0
Channel MEQ0630891:0 HM_Wohnzimmer_Licht_DEV:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: MEQ0630891
PARENT_TYPE: HM-LC-Dim1T-FM-LF
Channel MEQ0630891:1 HM_Wohnzimmer_Licht:1 [DIMMER] known
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: MEQ0630891
PARENT_TYPE: HM-LC-Dim1T-FM-LF
Defaults
Support for role DIMMER of device type HM-LC-Dim1T-FM-LF is built in.
Vielen Dank
Hallo,
Nach einem get ccuConfig bekommen ich diese Meldungen ins Log
Da ich nicht weiß was es bedeutet gebe ich die Info weiter.
HMCCU [d_ccu] Read 79 Device Descriptions for interface CUxD
HMCCU [d_ccu] Reading Paramset Descriptions for interface CUxD
HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX9002006:3
HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX2800001:9
HMCCURPCPROC [d_rpc178040CUxD] Error while decoding binary response
HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX2800001:12
HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX2800001:15
HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset MASTER for address CUX2801001:2
HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX2801001:4
Vielen Dank
Habe noch ein weiteres kleines problem. Ich benutze Alexa FHEM Connector, viele Geräte haben vom alten System die Namen behalten, aber einige haben einen neuen Namen bekommen. Die werden aber leider nicht mehr erkannt.
Kann das einer Bestätigen?
Zitat von: Benjamin50 am 01 Mai 2021, 13:48:55
Hallo,
Nach einem get ccuConfig bekommen ich diese Meldungen ins Log
Da ich nicht weiß was es bedeutet gebe ich die Info weiter.
HMCCU [d_ccu] Read 79 Device Descriptions for interface CUxD
HMCCU [d_ccu] Reading Paramset Descriptions for interface CUxD
HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX9002006:3
HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX2800001:9
HMCCURPCPROC [d_rpc178040CUxD] Error while decoding binary response
HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX2800001:12
HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX2800001:15
HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset MASTER for address CUX2801001:2
HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX2801001:4
Vielen Dank
Gibt es denn diese CUxD Geräte noch in der CCU?
Zitat von: zap am 02 Mai 2021, 14:18:55
Gibt es denn diese CUxD Geräte noch in der CCU?
Als ich den Log erstellt habe gab es sie die CUX2800001 noch.
den habe ich danach gelöscht das war ein Timer den ich nicht mehr benötige.
Den CUX9002006 gibt es noch das ist ein Temp und Feuchtigkeit Messgerät.
Vielen Dank
Keiner eine Idee mit Alexa FHEM Connector. (Erkennt keine neuen Geräte)
Läuft bei euch noch alles?
In Github (und demnächst auch per SVN Contrib) steht ein neues Update zur Verfügung.
Änderungen (siehe auch https://github.com/zapccu/HMCCU/issues?q=is%3Aissue+milestone%3A%22RC4+4.4.067%22+is%3Aclosed):
- Die Berechnung der RSSI Werte wurde für bestimmte Fälle korrigiert
- Die Befehle set up/down bei Rollläden und Jalousien sollten nun korrekt funktionieren
- Die Verarbeitung der set und get Befehle in den Modulen HMCCUDEV und HMCCUCHN wurde optimiert
- Die Logging Informationen bei HMCCURPCPROC Devices wurde erweitert
- Die Verfügbarkeit eines gültigen I/O Device bei der Definition von HMCCURPCPROC Devices wird nun in jedem Fall geprüft
- Ein Fehler, der zur Meldung "Can't get device description" beim Starten von FHEM führte, wurde behoben (Forum: https://forum.fhem.de/index.php/topic,107077.msg1149732.html#msg1149732)
- Das Internal "firmware" sollte nun für alle Devices verfügbar sein
Installation siehe erster Beitrag dieses Threads.
Zitat von: Benjamin50 am 03 Mai 2021, 17:32:15
Als ich den Log erstellt habe gab es sie die CUX2800001 noch.
den habe ich danach gelöscht das war ein Timer den ich nicht mehr benötige.
Den CUX9002006 gibt es noch das ist ein Temp und Feuchtigkeit Messgerät.
Vielen Dank
Welcher CUxD Gerätetyp ist das? Ich brauche die Nummer, die in der CUxD Oberfläche unter "Geräte" in der Liste "CUxD Gerätetyp" angezeigt wird. Beispiel: (03) Sensor => 03
Habe das Update vorhin eingespielt, aber leider zeigen meine Rollo's diesmal als HMCCUCHN keinen pct Wert an.
Internals:
DEF 00165BE99E4952:14
FUUID 60942bbc-f33f-19ae-b909-655c8bc868ac4c0d
IODev d_ccu
NAME HmIPW_Rollo_Esszimmer_Tuer
NR 402
STATE closed
TYPE HMCCUCHN
ccuaddr 00165BE99E4952:14
ccudevstate active
ccuif HmIP-RF
ccuname HmIPW-Rollo-Esszimmer-T�r
ccurolectrl BLIND_VIRTUAL_RECEIVER
ccurolestate BLIND_VIRTUAL_RECEIVER
ccusubtype DRBL4
ccutype HmIPW-DRBL4
chntype ?
firmware 1.6.0
readonly no
receiver ccu:HmIPW-06-DRI32-Keller
sender ccu:HmIPW-06-DRI32-Keller
READINGS:
2021-05-06 20:09:09 ACTIVITY_STATE STABLE
2021-05-06 19:47:40 IODev d_ccu
2021-05-06 20:09:09 LEVEL closed
2021-05-06 19:47:40 LEVEL_2 0
2021-05-06 20:09:09 LEVEL_2_STATUS UNKNOWN
2021-05-06 20:09:09 LEVEL_STATUS NORMAL
2021-05-06 20:09:09 PROCESS STABLE
2021-05-06 20:09:09 SECTION 4
2021-05-06 20:09:09 SECTION_STATUS NORMAL
2021-05-06 20:09:09 activity alive
2021-05-06 20:09:09 control closed
2021-05-06 20:09:09 devstate ok
2021-05-06 20:09:09 hmstate closed
2021-05-06 20:09:09 pct 0
2021-05-06 20:09:09 state closed
hmccu:
channels 1
devspec 00165BE99E4952:14
nodefaults 0
role 14:BLIND_VIRTUAL_RECEIVER
semDefaults 0
cmdlist:
get
set open:noArg up pct stop:noArg close:noArg down toggle:noArg
control:
chn 14
dpt LEVEL
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
NVAL 28.000000
ONVAL 28.000000
OSVAL 28.0
OVAL 28.000000
SVAL 28.0
VAL 28.000000
0.CONFIG_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.ERROR_UNDERVOLTAGE:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.INSTALL_TEST:
VALUES:
NVAL true
ONVAL true
OSVAL true
OVAL true
SVAL true
VAL true
0.OPERATING_VOLTAGE:
VALUES:
NVAL 24.200000
ONVAL 24.200000
OSVAL 24.2
OVAL 24.200000
SVAL 24.2
VAL 24.200000
0.OPERATING_VOLTAGE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
14.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
14.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL closed
OVAL 0.0
SVAL closed
VAL 0.0
14.LEVEL_2:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0.000000
SVAL 0
VAL 0.000000
14.LEVEL_2_STATUS:
VALUES:
NVAL 1
ONVAL 1
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
14.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
14.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
14.SECTION:
VALUES:
NVAL 4
ONVAL 4
OSVAL 4
OVAL 4
SVAL 4
VAL 4
14.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
roleCmds:
get:
set:
close:
channel 14
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:0
usage close
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
unit 100%
down:
channel 14
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=-20
usage down [delta]
subcmd:
000:
args -20
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
unit 100%
open:
channel 14
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:100
usage open
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
unit 100%
pct:
channel 14
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?level
usage pct level
subcmd:
000:
args
dpt LEVEL
fnc
max 1.01
min 0.0
parname level
partype 2
ps VALUES
unit 100%
stop:
channel 14
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:STOP:1
usage stop
subcmd:
000:
args 1
dpt STOP
fnc
max 1
min 0
parname STOP
partype 3
ps VALUES
unit
up:
channel 14
role BLIND_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=+20
usage up [delta]
subcmd:
000:
args +20
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
unit 100%
state:
chn 14
dpt LEVEL
Attributes:
cmdIcon open:fts_shutter_up stop:fts_shutter_manual close:fts_shutter_down
room Homematic
substexcl pct
webCmd pct:open:close:stop
widgetOverride pct:slider,0,10,100
Zitat von: zap am 06 Mai 2021, 19:09:00
In Github (und demnächst auch per SVN Contrib) steht ein neues Update zur Verfügung.
Test läuft. Bisher keine Auffälligkeiten.
Viele Grüße
Jürgen
Habe nun doch die ersten Probleme.
Beim Fensterkontakt erhalte ich beim get DEVICE update folgende Logeinträge:
2021.05.06 20:55:20 1: HMCCURPCPROC [d_rpc160090HmIP_RF] Error in request getParamset 0000DA498D425C SERVICE: Generic error (UNREACH)
2021.05.06 20:55:20 2: HMCCUDEV [HMIP_SWDO_0000DA498D425C] Can't get parameterset SERVICE for address 0000DA498D425C
2021.05.06 20:55:21 1: HMCCURPCPROC [d_rpc160090HmIP_RF] Error in request getParamset 0000DA498D425C:0 SERVICE: Generic error (UNREACH)
2021.05.06 20:55:21 2: HMCCUDEV [HMIP_SWDO_0000DA498D425C] Can't get parameterset SERVICE for address 0000DA498D425C:0
2021.05.06 20:55:22 1: HMCCURPCPROC [d_rpc160090HmIP_RF] Error in request getParamset 0000DA498D425C:1 SERVICE: Generic error (UNREACH)
2021.05.06 20:55:22 2: HMCCUDEV [HMIP_SWDO_0000DA498D425C] Can't get parameterset SERVICE for address 0000DA498D425C:1
2021.05.06 20:55:24 1: HMCCURPCPROC [d_rpc160090HmIP_RF] Error in request getParamset 0000DA498D425C:2 SERVICE: Generic error (UNREACH)
2021.05.06 20:55:24 2: HMCCUDEV [HMIP_SWDO_0000DA498D425C] Can't get parameterset SERVICE for address 0000DA498D425C:2
Hier das get deviceinfo:
device channels and datapoints
DEV HMIP-SWDO 0000DA498D425C 0000DA498D425C interface=HmIP-RF type=HMIP-SWDO
CHN 0000DA498D425C:0 HMIP-SWDO 0000DA498D425C:0
0.CONFIG_PENDING = false {b} [RE]
0.DUTY_CYCLE = false {b} [RE]
0.ERROR_CODE = 0 {n} [RE]
0.INSTALL_TEST = true {b} [RW]
0.LOW_BAT = false {b} [RE]
0.OPERATING_VOLTAGE = 1.200000 {f} [RE]
0.OPERATING_VOLTAGE_STATUS = 0 {i} [RE]
0.RSSI_DEVICE = 205 {n} [RE]
0.RSSI_PEER = 0 {n} [RE]
0.SABOTAGE = false {b} [RE]
0.UNREACH = true {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
CHN 0000DA498D425C:1 HMIP-SWDO 0000DA498D425C:1
1.STATE = 0 {i} [RE]
Device detection:
StateDatapoint = 1.STATE [SHUTTER_CONTACT]
No control datapoint detected
Recommended module for device definition: HMCCUCHN
Current state datapoint = 1.STATE
Current control datapoint = .
Device description
Device 0000DA498D425C HMIP-SWDO 0000DA498D425C [HMIP-SWDO]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 0000DA498D425C:0,0000DA498D425C:1,0000DA498D425C:2
DIRECTION: NONE
FIRMWARE: 1.16.8
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 9047915
ROAMING: 0
RX_MODE: CONFIG
SUBTYPE: SWD
UPDATABLE: 1
Channel 0000DA498D425C:0 HMIP-SWDO 0000DA498D425C:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 0000DA498D425C
PARENT_TYPE: HMIP-SWDO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0000DA498D425C:1 HMIP-SWDO 0000DA498D425C:1 [SHUTTER_CONTACT] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH,WINDOW_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 0000DA498D425C
PARENT_TYPE: HMIP-SWDO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0000DA498D425C:2 HMIP-SWDO 0000DA498D425C:2 [ALARM_COND_SWITCH_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS:
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 0000DA498D425C
PARENT_TYPE: HMIP-SWDO
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Defaults
Support for role SHUTTER_CONTACT of device type HMIP-SWDO is built in.
Ich kann dies auch schon in der Version 4.4.066 reproduzieren. Der Kontakt funktioniert sonst aber.
Viele Grüße
Jürgen
Jetzt hats funktioniert.
Manchmal braucht man Räucherstäbchen.
Moin zusammen,
sagt mal, was kann das sein?
Ich versuche gerade, die neue Beta zu laden. "Nothing to do". Komisch. Gleiche Reaktion bei svn.
Shutdown/restart bringt auch keine Änderung.
2021.05.07 09:32:41 1 : Downloading https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
2021.05.07 09:32:41 1 : nothing to do...
Aktuelle Version:
version 4.4.066
Eine Idee?
Gruß Helmut
Zitat von: juemuc am 06 Mai 2021, 20:59:48
Habe nun doch die ersten Probleme.
Beim Fensterkontakt erhalte ich beim get DEVICE update folgende Logeinträge:
2021.05.06 20:55:20 1: HMCCURPCPROC [d_rpc160090HmIP_RF] Error in request getParamset 0000DA498D425C SERVICE: Generic error (UNREACH)
2021.05.06 20:55:20 2: HMCCUDEV [HMIP_SWDO_0000DA498D425C] Can't get parameterset SERVICE for address 0000DA498D425C
2021.05.06 20:55:21 1: HMCCURPCPROC [d_rpc160090HmIP_RF] Error in request getParamset 0000DA498D425C:0 SERVICE: Generic error (UNREACH)
2021.05.06 20:55:21 2: HMCCUDEV [HMIP_SWDO_0000DA498D425C] Can't get parameterset SERVICE for address 0000DA498D425C:0
2021.05.06 20:55:22 1: HMCCURPCPROC [d_rpc160090HmIP_RF] Error in request getParamset 0000DA498D425C:1 SERVICE: Generic error (UNREACH)
2021.05.06 20:55:22 2: HMCCUDEV [HMIP_SWDO_0000DA498D425C] Can't get parameterset SERVICE for address 0000DA498D425C:1
2021.05.06 20:55:24 1: HMCCURPCPROC [d_rpc160090HmIP_RF] Error in request getParamset 0000DA498D425C:2 SERVICE: Generic error (UNREACH)
2021.05.06 20:55:24 2: HMCCUDEV [HMIP_SWDO_0000DA498D425C] Can't get parameterset SERVICE for address 0000DA498D425C:2
Kommen die Meldungen beim Start von FHEM?
Funktioniert der Befehl "get paramsetDesc" ?
Zitat von: zap am 06 Mai 2021, 19:22:01
Welcher CUxD Gerätetyp ist das? Ich brauche die Nummer, die in der CUxD Oberfläche unter "Geräte" in der Liste "CUxD Gerätetyp" angezeigt wird. Beispiel: (03) Sensor => 03
Das ist der Log eintrag nach einem Update und neustart
2021.05.07 14:46:51.579 1: Downloading https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
2021.05.07 14:46:52.313 1: UPD FHEM/88_HMCCURPCPROC.pm
2021.05.07 14:46:52.520 1: UPD FHEM/HMCCUConf.pm
2021.05.07 14:46:52.754 1: UPD FHEM/88_HMCCUCHN.pm
2021.05.07 14:46:52.960 1: UPD FHEM/88_HMCCU.pm
2021.05.07 14:46:53.205 1: UPD FHEM/88_HMCCUDEV.pm
2021.05.07 14:46:53.393 1: saving fhem.cfg
2021.05.07 14:46:53.395 1: saving ./log/fhem.save
2021.05.07 14:46:53.397 1:
2021.05.07 14:46:53.398 1: New entries in the CHANGED file:
2021.05.07 14:46:53.399 1: - bugfix: 88_HMCCU.pm: Release candidate 4
2021.05.07 14:46:53.400 1: - bugfix: 88_HMCCU.pm: Release candidate 3
2021.05.07 14:46:53.401 1: - bugfix: 88_HMCCU.pm: Release candidate 2
2021.05.07 14:46:53.401 1: - bugfix: 88_HMCCU.pm: Fixed bug in set defaults command
2021.05.07 14:46:53.403 1: - bugfix: 88_HMCCU.pm: Fixed statedatapoint/controldatapoint bug during FHEM start
2021.05.07 14:46:53.403 1: - bugfix: 88_HMCCU.pm: Fixed some bugs. New command set readingFilter
2021.05.07 14:46:53.404 1: - bugfix: 88_HMCCU.pm: Fixed device detection bugs
2021.05.07 14:46:53.405 1: Calling /usr/bin/perl ./contrib/commandref_join.pl -noWarnings, this may take a while
2021.05.07 14:47:01.481 1:
2021.05.07 14:47:01.482 1: update finished, "shutdown restart" is needed to activate the changes.
2021.05.07 14:47:01.483 1:
2021.05.07 14:47:02.171 1: fheminfo Statistics data sent to server. See Logfile (level 4) for details.
2021.05.07 14:47:08.680 1: HMCCU [d_ccu] Graceful shutdown in 8 seconds
2021.05.07 14:47:08.685 1: HMCCURPCPROC [d_rpc178040CUxD] Stopping RPC server CB8701178100178040
2021.05.07 14:47:08.688 1: HMCCURPCPROC [d_rpc178040CUxD] Deregistering RPC server xmlrpc_bin://192.168.178.100:14111/fh8701 with ID CB8701178100178040 at xmlrpc_bin://192.168.178.40:8701
2021.05.07 14:47:08.705 1: HMCCURPCPROC [d_rpc178040CUxD] Callback for RPC server CB8701178100178040 deregistered
2021.05.07 14:47:08.709 2: HMCCURPCPROC [d_rpc178040CUxD] Sending signal INT to RPC server process CB8701178100178040 with PID=682528
2021.05.07 14:47:08.709 2: HMCCURPCPROC [d_rpc178040CUxD] Cleaning up immediately
2021.05.07 14:47:08.709 1: HMCCURPCPROC [d_rpc178040CUxD] Housekeeping called. Cleaning up RPC environment
2021.05.07 14:47:08.710 2: HMCCURPCPROC [d_rpc178040CUxD] CB8701178100178040 received signal INT
2021.05.07 14:47:08.711 2: HMCCURPCPROC [d_rpc178040CUxD] CB8701178100178040 received signal INT
2021.05.07 14:47:08.711 1: HMCCURPCPROC [d_rpc178040CUxD] RPC server CB8701178100178040 stopped handling connections. PID=682528
2021.05.07 14:47:08.712 2: HMCCURPCPROC [d_rpc178040CUxD] Number of I/O errors = 0
2021.05.07 14:47:10.713 2: HMCCURPCPROC [d_rpc178040CUxD] RPC server process CB8701178100178040 deleted
2021.05.07 14:47:10.717 1: HMCCU [d_ccu] All RPC servers inactive
2021.05.07 14:47:10.723 2: HMCCURPCPROC [d_rpc178040CUxD] Stop I/O handling
2021.05.07 14:47:10.729 2: HMCCURPCPROC [d_rpc178040CUxD] RPC server stopped. Cancel delayed shutdown.
2021.05.07 14:47:11.730 1: HMCCURPCPROC [d_rpc178040BidCos_RF] Stopping RPC server CB2001178100178040
2021.05.07 14:47:11.734 1: HMCCURPCPROC [d_rpc178040BidCos_RF] Deregistering RPC server http://192.168.178.100:7411/fh2001 with ID CB2001178100178040 at http://192.168.178.40:2001
2021.05.07 14:47:11.769 1: HMCCURPCPROC [d_rpc178040BidCos_RF] Callback for RPC server CB2001178100178040 deregistered
2021.05.07 14:47:11.776 2: HMCCURPCPROC [d_rpc178040BidCos_RF] Sending signal INT to RPC server process CB2001178100178040 with PID=682527
2021.05.07 14:47:11.777 2: HMCCURPCPROC [d_rpc178040BidCos_RF] Cleaning up immediately
2021.05.07 14:47:11.777 2: HMCCURPCPROC [d_rpc178040BidCos_RF] CB2001178100178040 received signal INT
2021.05.07 14:47:11.777 1: HMCCURPCPROC [d_rpc178040BidCos_RF] Housekeeping called. Cleaning up RPC environment
2021.05.07 14:47:11.777 2: HMCCURPCPROC [d_rpc178040BidCos_RF] CB2001178100178040 received signal INT
2021.05.07 14:47:11.777 1: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server CB2001178100178040 stopped handling connections. PID=682527
2021.05.07 14:47:11.778 2: HMCCURPCPROC [d_rpc178040BidCos_RF] Number of I/O errors = 0
2021.05.07 14:47:13.781 2: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server process CB2001178100178040 deleted
2021.05.07 14:47:13.784 2: HMCCURPCPROC [d_rpc178040BidCos_RF] Stop I/O handling
2021.05.07 14:47:13.791 2: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server stopped. Cancel delayed shutdown.
2021.05.07 14:47:14.792 1: HMCCURPCPROC [d_rpc178040VirtualDevices] Stopping RPC server CB9292178100178040
2021.05.07 14:47:14.795 1: HMCCURPCPROC [d_rpc178040VirtualDevices] Deregistering RPC server http://192.168.178.100:14702/fh9292 with ID CB9292178100178040 at http://192.168.178.40:9292/groups
2021.05.07 14:47:14.825 1: HMCCURPCPROC [d_rpc178040VirtualDevices] Callback for RPC server CB9292178100178040 deregistered
2021.05.07 14:47:14.832 2: HMCCURPCPROC [d_rpc178040VirtualDevices] Sending signal INT to RPC server process CB9292178100178040 with PID=682526
2021.05.07 14:47:14.832 2: HMCCURPCPROC [d_rpc178040VirtualDevices] Cleaning up immediately
2021.05.07 14:47:14.833 1: HMCCURPCPROC [d_rpc178040VirtualDevices] Housekeeping called. Cleaning up RPC environment
2021.05.07 14:47:14.833 2: HMCCURPCPROC [d_rpc178040VirtualDevices] CB9292178100178040 received signal INT
2021.05.07 14:47:14.833 2: HMCCURPCPROC [d_rpc178040VirtualDevices] CB9292178100178040 received signal INT
2021.05.07 14:47:14.834 1: HMCCURPCPROC [d_rpc178040VirtualDevices] RPC server CB9292178100178040 stopped handling connections. PID=682526
2021.05.07 14:47:14.835 2: HMCCURPCPROC [d_rpc178040VirtualDevices] Number of I/O errors = 0
2021.05.07 14:47:16.836 2: HMCCURPCPROC [d_rpc178040VirtualDevices] RPC server process CB9292178100178040 deleted
2021.05.07 14:47:16.840 2: HMCCURPCPROC [d_rpc178040VirtualDevices] Stop I/O handling
2021.05.07 14:47:16.847 2: HMCCURPCPROC [d_rpc178040VirtualDevices] RPC server stopped. Cancel delayed shutdown.
2021.05.07 14:47:17.848 2: DbLog logdb - Last database write cycle due to shutdown ...
2021.05.07 14:47:17.867 1: Server shutdown delayed due to d_rpc178040BidCos_RF,logdb,d_ccu,d_rpc178040CUxD,d_rpc178040HmIP_RF,d_rpc178040VirtualDevices for max 10 sec
2021.05.07 14:47:18.009 2: DbLog logdb - Last database write cycle done
2021.05.07 14:47:27.911 0: Server shutdown
2021.05.07 14:47:27.913 1: HMCCU [d_ccu] Graceful shutdown
2021.05.07 14:47:37.118 1: HMCCU [d_ccu] CCU port 8181 is reachable
2021.05.07 14:47:37.119 1: HMCCU [d_ccu] Initialized version 4.4.067
2021.05.07 14:47:37.119 1: HMCCU [d_ccu] Initializing device
2021.05.07 14:47:37.276 2: HMCCU [d_ccu] Updating device table
2021.05.07 14:47:37.442 1: HMCCU [d_ccu] Read 61 devices with 364 channels from CCU 192.168.178.40
2021.05.07 14:47:37.442 1: HMCCU [d_ccu] Read 43 programs from CCU 192.168.178.40
2021.05.07 14:47:37.442 1: HMCCU [d_ccu] Read 5 virtual groups from CCU 192.168.178.40
2021.05.07 14:47:37.509 1: HMCCURPCPROC [d_rpc178040HmIP_RF] Initialized version 4.4.014 for interface HmIP-RF with I/O device d_ccu
2021.05.07 14:47:37.516 1: HMCCURPCPROC [d_rpc178040CUxD] Initialized version 4.4.014 for interface CUxD with I/O device d_ccu
2021.05.07 14:47:37.529 1: HMCCURPCPROC [d_rpc178040VirtualDevices] Initialized version 4.4.014 for interface VirtualDevices with I/O device d_ccu
2021.05.07 14:47:37.536 1: HMCCURPCPROC [d_rpc178040BidCos_RF] Initialized version 4.4.014 for interface BidCos-RF with I/O device d_ccu
2021.05.07 14:47:50.445 1: HMCCU [d_ccu] Reading device config from CCU. This may take a couple of seconds ...
2021.05.07 14:47:50.446 2: HMCCU [d_ccu] Reading Device Descriptions for interface CUxD
2021.05.07 14:47:50.500 2: HMCCU [d_ccu] Read 61 Device Descriptions for interface CUxD
2021.05.07 14:47:50.500 2: HMCCU [d_ccu] Reading Paramset Descriptions for interface CUxD
2021.05.07 14:47:50.511 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:50.511 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset MASTER for address CUX9002006
2021.05.07 14:47:50.649 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:50.650 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset MASTER for address CUX9002003
2021.05.07 14:47:50.721 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:50.722 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset MASTER for address CUX9002003:2
2021.05.07 14:47:50.765 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:50.766 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX9002003:3
2021.05.07 14:47:50.829 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:50.829 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset MASTER for address CUX9100001:1
2021.05.07 14:47:50.839 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:50.839 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX9100001:1
2021.05.07 14:47:50.849 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:50.849 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset MASTER for address CUX2801001
2021.05.07 14:47:50.859 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:50.859 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset MASTER for address CUX2801001:0
2021.05.07 14:47:50.869 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:50.869 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX2801001:0
2021.05.07 14:47:50.878 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:50.878 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset MASTER for address CUX2801001:1
2021.05.07 14:47:50.911 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:50.912 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset MASTER for address CUX2801001:2
2021.05.07 14:47:50.952 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:50.952 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset MASTER for address CUX2801001:3
2021.05.07 14:47:51.173 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:51.174 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset MASTER for address CUX2801001:5
2021.05.07 14:47:51.211 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:51.212 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX2801001:5
2021.05.07 14:47:51.322 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:51.323 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX2801001:8
2021.05.07 14:47:51.427 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:51.428 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset MASTER for address CUX2801001:11
2021.05.07 14:47:51.444 2: HMCCURPCPROC [d_rpc178040CUxD] Error while decoding binary response
2021.05.07 14:47:51.444 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX2801001:11
2021.05.07 14:47:51.592 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command getParamsetDescription:
2021.05.07 14:47:51.593 2: HMCCURPCPROC [d_rpc178040CUxD] Can't get description of paramset VALUES for address CUX2801001:15
2021.05.07 14:47:51.638 2: HMCCU [d_ccu] Read 32 Paramset Descriptions for interface CUxD
2021.05.07 14:47:51.639 2: HMCCU [d_ccu] Reading Peer Descriptions for interface CUxD
2021.05.07 14:47:51.652 2: HMCCU [d_ccu] Read 0 Peer Descriptions for interface CUxD
2021.05.07 14:47:51.652 2: HMCCU [d_ccu] Reading Device Descriptions for interface BidCos-RF
2021.05.07 14:47:52.195 2: HMCCU [d_ccu] Read 284 Device Descriptions for interface BidCos-RF
2021.05.07 14:47:52.196 2: HMCCU [d_ccu] Reading Paramset Descriptions for interface BidCos-RF
2021.05.07 14:48:02.440 2: HMCCU [d_ccu] Read 166 Paramset Descriptions for interface BidCos-RF
2021.05.07 14:48:02.440 2: HMCCU [d_ccu] Reading Peer Descriptions for interface BidCos-RF
2021.05.07 14:48:02.501 2: HMCCU [d_ccu] Read 49 Peer Descriptions for interface BidCos-RF
2021.05.07 14:48:02.502 2: HMCCU [d_ccu] Reading Device Descriptions for interface VirtualDevices
2021.05.07 14:48:02.599 2: HMCCU [d_ccu] Read 20 Device Descriptions for interface VirtualDevices
2021.05.07 14:48:02.600 2: HMCCU [d_ccu] Reading Paramset Descriptions for interface VirtualDevices
2021.05.07 14:48:03.332 2: HMCCU [d_ccu] Read 4 Paramset Descriptions for interface VirtualDevices
2021.05.07 14:48:03.333 2: HMCCU [d_ccu] Reading Peer Descriptions for interface VirtualDevices
2021.05.07 14:48:03.357 2: HMCCU [d_ccu] Read 0 Peer Descriptions for interface VirtualDevices
2021.05.07 14:48:03.379 2: HMCCU [d_ccu] Can't get definition of MEQ0630891:1.STATE. Ignoring command on-for-timer for device HM_Wohnzimmer_Licht
2021.05.07 14:48:03.379 2: HMCCU [d_ccu] Can't get definition of MEQ0630891:1.STATE. Ignoring command on-till for device HM_Wohnzimmer_Licht
2021.05.07 14:48:03.435 2: HMCCU [d_ccu] Read device configuration: devices/channels=365 parametersets=202 links=49
2021.05.07 14:48:03.435 2: HMCCU [d_ccu] Get RPC device for interface VirtualDevices
2021.05.07 14:48:03.435 2: HMCCU [d_ccu] Get RPC device for interface BidCos-RF
2021.05.07 14:48:03.435 2: HMCCU [d_ccu] Get RPC device for interface CUxD
2021.05.07 14:48:03.443 2: HMCCURPCPROC [d_rpc178040VirtualDevices] RPC server process started for interface VirtualDevices with PID=1077584
2021.05.07 14:48:03.452 1: HMCCURPCPROC [d_rpc178040VirtualDevices] RPC server starting
2021.05.07 14:48:03.452 2: HMCCURPCPROC [d_rpc178040VirtualDevices] Initializing RPC server CB9292178100178040 for interface VirtualDevices
2021.05.07 14:48:03.465 2: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server process started for interface BidCos-RF with PID=1077585
2021.05.07 14:48:03.471 2: HMCCURPCPROC [d_rpc178040BidCos_RF] Initializing RPC server CB2001178100178040 for interface BidCos-RF
2021.05.07 14:48:03.474 1: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server starting
2021.05.07 14:48:03.486 2: HMCCURPCPROC [d_rpc178040CUxD] RPC server process started for interface CUxD with PID=1077586
2021.05.07 14:48:03.491 2: HMCCURPCPROC [d_rpc178040CUxD] Initializing RPC server CB8701178100178040 for interface CUxD
2021.05.07 14:48:03.493 2: HMCCURPCPROC [d_rpc178040CUxD] CB8701178100178040 accepting connections. PID=1077586
2021.05.07 14:48:03.495 1: HMCCURPCPROC [d_rpc178040CUxD] RPC server starting
2021.05.07 14:48:03.510 2: HMCCURPCPROC [d_rpc178040VirtualDevices] Callback server CB9292178100178040 created. Listening on port 14702
2021.05.07 14:48:03.511 2: HMCCURPCPROC [d_rpc178040VirtualDevices] CB9292178100178040 accepting connections. PID=1077584
2021.05.07 14:48:03.526 2: HMCCURPCPROC [d_rpc178040CUxD] RPC server CB8701178100178040 enters server loop
2021.05.07 14:48:03.527 2: HMCCURPCPROC [d_rpc178040BidCos_RF] Callback server CB2001178100178040 created. Listening on port 7411
2021.05.07 14:48:03.528 2: HMCCURPCPROC [d_rpc178040CUxD] Registering callback xmlrpc_bin://192.168.178.100:14111/fh8701 of type B with ID CB8701178100178040 at xmlrpc_bin://192.168.178.40:8701
2021.05.07 14:48:03.528 2: HMCCURPCPROC [d_rpc178040BidCos_RF] CB2001178100178040 accepting connections. PID=1077585
2021.05.07 14:48:03.538 2: HMCCURPCPROC [d_rpc178040CUxD] Error while reading response for command init:
2021.05.07 14:48:03.540 1: HMCCURPCPROC [d_rpc178040CUxD] RPC server CB8701178100178040 running
2021.05.07 14:48:03.639 2: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server CB2001178100178040 enters server loop
2021.05.07 14:48:03.641 2: HMCCURPCPROC [d_rpc178040BidCos_RF] Registering callback http://192.168.178.100:7411/fh2001 of type A with ID CB2001178100178040 at http://192.168.178.40:2001
2021.05.07 14:48:03.721 1: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server CB2001178100178040 running
2021.05.07 14:48:03.724 1: HMCCURPCPROC [d_rpc178040BidCos_RF] Scheduled CCU ping every 300 seconds
2021.05.07 14:48:03.730 2: HMCCURPCPROC [d_rpc178040VirtualDevices] RPC server CB9292178100178040 enters server loop
2021.05.07 14:48:03.731 2: HMCCURPCPROC [d_rpc178040VirtualDevices] Registering callback http://192.168.178.100:14702/fh9292 of type A with ID CB9292178100178040 at http://192.168.178.40:9292/groups
2021.05.07 14:48:03.910 2: HMCCURPCPROC [d_rpc178040VirtualDevices] CB9292178100178040 NewDevice received 20 device and channel specifications
2021.05.07 14:48:04.117 2: HMCCURPCPROC [d_rpc178040BidCos_RF] CB2001178100178040 NewDevice received 284 device and channel specifications
2021.05.07 14:48:13.772 1: HMCCURPCPROC [d_rpc178040VirtualDevices] RPC server CB9292178100178040 running
2021.05.07 14:48:13.775 1: HMCCU [d_ccu] All RPC servers running
2021.05.07 14:48:13.795 2: HMCCU [d_ccu] Updating 59 of 59 client devices matching devexp=.* filter=ccudevstate=active,ccuif=CUxD|VirtualDevices|BidCos-RF
2021.05.07 14:48:15.300 2: HMCCU [d_ccu] Update success=59 failed=0
Und die CUxD Gerätetyp
Aktuelle Geräteeinstellungen - 10 Gerät(e), 41 Channel(s):
CUX2801001:1 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:2 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT(ifconfig eth0 | awk '/inet addr/ && match ($0, /[0-9\.]+/) { printf substr ($0, RSTART, RLENGTH); }')
KEY-LONG CMD_LONG()
CUX2801001:3 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:4 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:5 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:6 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:7 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:8 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:9 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:10 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:11 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:12 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:13 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:14 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:15 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:16 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX9002001: mode(1) aH h(0.40)
CUX9002001:1 CCU(WEATHER,'JPTH10I599:1')
CUX9002001:2 SET
CUX9002002: mode(1) aH h(0.40)
CUX9002002:1 CCU(WEATHER,'JPTH10I996:1') CHECK
CUX9002002:2 SET
CUX9002003: mode(1) aH h(0.40)
CUX9002003:1 CCU(WEATHER,'MEQ1600285:1') STAT
CUX9002003:2 SET
CUX9002004: mode(1) T h(0.40)
CUX9002004:1 CCU(WEATHER,'MEQ1651281:1')
CUX9002004:2 SET
CUX9002005: mode(1) T h(0.40)
CUX9002005:1 CCU(WEATHER,'OEQ0159701:1')
CUX9002005:2 SET
CUX9002006: mode(1) aH h(0.40)
CUX9002006:1 CCU(WEATHER,'JPTH10I799:1')
CUX9002006:2 SET
CUX9002007: mode(1) aH h(0.40)
CUX9002007:1 CCU(WEATHER,'JPTH10I699:1')
CUX9002007:2 SET
CUX9002008: mode(1) aH h(0.40)
CUX9002008:1 CCU(WEATHER,'JPTH10I299:1')
CUX9002008:2 SET
CUX9100001:
Vielen Dank
1 Warning nach Update auf Beta4 im Log:
PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/88_HMCCU.pm line 8458.
Zitat von: zap am 07 Mai 2021, 10:38:24
Kommen die Meldungen beim Start von FHEM?
Funktioniert der Befehl "get paramsetDesc" ?
Ja der Befehl funktioniert.
Device
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Channel 0
Paramset MASTER
ARR_TIMEOUT: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=10
CYCLIC_INFO_MSG: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=1
CYCLIC_INFO_MSG_DIS: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=20
CYCLIC_INFO_MSG_DIS_UNCHANGED: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
CYCLIC_INFO_MSG_OVERDUE_THRESHOLD: INTEGER [R,W] [Visible,Sticky] RANGE=0...2147483647 DFLT=2
DISABLE_MSG_TO_AC: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
DUTYCYCLE_LIMIT: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=180
ENABLE_ROUTING: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=1
LOCAL_RESET_DISABLED: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
LOW_BAT_LIMIT: FLOAT [R,W] [Visible,Sticky] RANGE=0...25.2 DFLT=1.1 UNIT=V
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Paramset VALUES
CONFIG_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
DUTY_CYCLE: BOOL [R,E] [Visible,Sticky] RANGE=0...1 DFLT=0
ERROR_CODE: INTEGER [R,E] [Visible,Sticky,Service] RANGE=0...255 DFLT=0
INSTALL_TEST: BOOL [R,W] [Internal] RANGE=0...1 DFLT=0
LOW_BAT: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
OPERATING_VOLTAGE: FLOAT [R,E] [Visible,Sticky] RANGE=0...25.2 DFLT=0
OPERATING_VOLTAGE_STATUS: ENUM [R,E] [Visible,Sticky] RANGE=NORMAL...EXTERNAL DFLT=NORMAL VALUES=NORMAL,UNKNOWN,OVERFLOW,EXTERNAL
RSSI_DEVICE: INTEGER [R,E] [Visible,Sticky] RANGE=-128...127 DFLT=0
RSSI_PEER: INTEGER [R,E] [Visible,Sticky] RANGE=-128...127 DFLT=0
SABOTAGE: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
UNREACH: BOOL [R,E] [Sticky,Internal] RANGE=0...1 DFLT=0
UPDATE_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
Channel 1
Paramset MASTER
EVENT_DELAY_UNIT: ENUM [R,W] [Visible,Sticky] RANGE=100MS...H DFLT=100MS VALUES=100MS,S,M,H
EVENT_DELAY_VALUE: INTEGER [R,W] [Visible,Sticky] RANGE=0...63 DFLT=0
MSG_FOR_POS_A: ENUM [R,W] [Visible,Sticky] RANGE=NO_MSG...OPEN DFLT=OPEN VALUES=NO_MSG,CLOSED,OPEN
MSG_FOR_POS_B: ENUM [R,W] [Visible,Sticky] RANGE=NO_MSG...OPEN DFLT=CLOSED VALUES=NO_MSG,CLOSED,OPEN
SAMPLE_INTERVAL: FLOAT [R,W] [Visible,Sticky] RANGE=0.1...25.5 DFLT=0.5
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Paramset VALUES
STATE: ENUM [R,E] [Visible,Sticky] RANGE=CLOSED...OPEN DFLT=CLOSED UNIT="" VALUES=CLOSED,OPEN
Channel 2
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Durch get update wird das Device auch in der pivccu auf unreachable gesetzt.
Viele Grüße
Jürgen
So, habe meine Rollo's jetzt auch halbwegs am laufen, aber etwas umständlich.
Erst muss ich die auf einem Schalbaren Kanal in FHEM hinzufügen damit alle Schaltbefehle vorhanden sind. Danach kann ich die DEF auf den Status Kanal wechseln.
Danach bekomme ich unter LEVEL die richtige Position angezeigt. Jetzt nur noch substexcl auf LEVEL ändern dann läuft alles so wie ich es brauche. Zumindest solange bis ich die CCU neu starte.
Hoffe das es bald eine schönere Lösung gibt.
EDIT:
Leider zu früh gefreut, bei irgendwelchen Aktivitäten nimmt er die Steuerbefehle raus..... funktioniert HMCCU 4.3?
Brauche eine funktionierende Sache da alles produktiv ist....
Zitat von: SamNitro am 13 Mai 2021, 21:54:39
So, habe meine Rollo's jetzt auch halbwegs am laufen, aber etwas umständlich.
Erst muss ich die auf einem Schalbaren Kanal in FHEM hinzufügen damit alle Schaltbefehle vorhanden sind. Danach kann ich die DEF auf den Status Kanal wechseln.
Danach bekomme ich unter LEVEL die richtige Position angezeigt. Jetzt nur noch substexcl auf LEVEL ändern dann läuft alles so wie ich es brauche. Zumindest solange bis ich die CCU neu starte.
Hoffe das es bald eine schönere Lösung gibt.
EDIT:
Leider zu früh gefreut, bei irgendwelchen Aktivitäten nimmt er die Steuerbefehle raus..... funktioniert HMCCU 4.3?
Brauche eine funktionierende Sache da alles produktiv ist....
Kannst Du das Vorgehen nochmal genauer beschreiben? Kannst Du für die einzelnen Schritte jeweils ein list vom Device machen?
Sorry für den Aufwand.
Downgrade auf 4.3 ist nur möglich, wenn Du die Config gesichert hast. Sonst wird es sehr mühsam.
defmod HmIPW_Rollo_Wohnzimmer HMCCUCHN 00165BE99E4952:6
1.txt
defmod HmIPW_Rollo_Wohnzimmer HMCCUCHN 00165BE99E4952:5
2.txt
get HmIPW_Rollo_Wohnzimmer update
setstate HmIPW_Rollo_Wohnzimmer 2021-05-14 13:14:59 LEVEL 92.5
Sorry das forum kürzt mir den Beitrag.
Im grunde eigentlich das selbe wie hier:
https://github.com/zapccu/HMCCU/issues/31 (https://github.com/zapccu/HMCCU/issues/31)
4 Kanal Rollo
1.LEVEL = State
2.LEVEL = 1.Virtueller Kanal
3.LEVEL = 2.Virtueller Kanal
4.LEVEL = 3.Virtueller Kanal
5.LEVEL = State
6.LEVEL = 1.Virtueller Kanal
7.LEVEL = 2.Virtueller Kanal
8.LEVEL = 3.Virtueller Kanal
9.LEVEL = State
10.LEVEL = 1.Virtueller Kanal
11.LEVEL = 2.Virtueller Kanal
12.LEVEL = 3.Virtueller Kanal
13.LEVEL = State
14.LEVEL = 1.Virtueller Kanal
15.LEVEL = 2.Virtueller Kanal
16.LEVEL = 3.Virtueller Kanal
@SamNitro: Ich glaube, das nachträgliche Ändern der Kanaladresse ist keine gute Idee, da die beiden Kanäle unterschiedliche Rollen haben.
Hast Du schon mal ein "get deviceInfo" gemacht? Wenn ja, reicht mir der Link auf den Forumbeitrag. Wenn nein, bitte mal:
get d_ccu deviceInfo 00165BE99E4952
Ich bin noch optimistisch, dass wir das ans Laufen bekommen
Nein hatte ich noch nicht.
<html>Device channels and datapoints
DEV HmIPW-04-DRBL4-Keller 00165BE99E4952 interface=HmIP-RF type=HmIPW-DRBL4
CHN 00165BE99E4952:0 HmIPW-04-DRBL4-Keller:0
0.ACTUAL_TEMPERATURE = 29.000000 {f} [RE]
0.COMBINED_PARAMETER = {s} [W]
0.CONFIG_PENDING = false {b} [RE]
0.ERROR_CODE = 0 {n} [RE]
0.ERROR_OVERHEAT = false {b} [RE]
0.ERROR_UNDERVOLTAGE = false {b} [RE]
0.IDENTIFICATION_MODE_KEY_VISUAL = {b} [W]
0.IDENTIFICATION_MODE_LCD_BACKLIGHT = {b} [W]
0.IDENTIFY_DURATION = {f} [W]
0.IDENTIFY_TARGET_LEVEL = {f} [W]
0.INSTALL_TEST = true {b} [RW]
0.OPERATING_VOLTAGE = 24.200000 {f} [RE]
0.OPERATING_VOLTAGE_STATUS = 0 {i} [RE]
0.UNREACH = false {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
CHN 00165BE99E4952:1 HmIPW-DRBL4 00165BE99E4952:1
1.ACTIVITY_STATE = 3 {i} [RE]
1.LEVEL = 1.000000 {f} [RE]
1.LEVEL_2 = 0.000000 {f} [RE]
1.LEVEL_2_STATUS = 1 {i} [RE]
1.LEVEL_STATUS = 0 {i} [RE]
1.PROCESS = 0 {i} [RE]
1.SECTION = 0 {i} [RE]
1.SECTION_STATUS = 1 {i} [RE]
CHN 00165BE99E4952:2 HmIPW-Rollo-K�che
2.ACTIVITY_STATE = 3 {i} [RE]
2.COMBINED_PARAMETER = {s} [W]
2.LEVEL = 1.000000 {f} [RWE]
2.LEVEL_2 = 0.000000 {f} [RWE]
2.LEVEL_2_STATUS = 1 {i} [RE]
2.LEVEL_STATUS = 0 {i} [RE]
2.PROCESS = 0 {i} [RE]
2.SECTION = 4 {i} [RE]
2.SECTION_STATUS = 0 {i} [RE]
2.STOP = {b} [W]
CHN 00165BE99E4952:3 HmIPW-DRBL4 00165BE99E4952:3
3.ACTIVITY_STATE = 3 {i} [RE]
3.COMBINED_PARAMETER = {s} [W]
3.LEVEL = 0.000000 {f} [RWE]
3.LEVEL_2 = 0.000000 {f} [RWE]
3.LEVEL_2_STATUS = 1 {i} [RE]
3.LEVEL_STATUS = 0 {i} [RE]
3.PROCESS = 0 {i} [RE]
3.SECTION = 0 {i} [RE]
3.SECTION_STATUS = 0 {i} [RE]
3.STOP = {b} [W]
CHN 00165BE99E4952:4 HmIPW-DRBL4 00165BE99E4952:4
4.ACTIVITY_STATE = 3 {i} [RE]
4.COMBINED_PARAMETER = {s} [W]
4.LEVEL = 0.000000 {f} [RWE]
4.LEVEL_2 = 0.000000 {f} [RWE]
4.LEVEL_2_STATUS = 1 {i} [RE]
4.LEVEL_STATUS = 0 {i} [RE]
4.PROCESS = 0 {i} [RE]
4.SECTION = 0 {i} [RE]
4.SECTION_STATUS = 0 {i} [RE]
4.STOP = {b} [W]
CHN 00165BE99E4952:5 HmIPW-DRBL4 00165BE99E4952:5
5.ACTIVITY_STATE = 3 {i} [RE]
5.LEVEL = 1.000000 {f} [RE]
5.LEVEL_2 = 0.000000 {f} [RE]
5.LEVEL_2_STATUS = 1 {i} [RE]
5.LEVEL_STATUS = 0 {i} [RE]
5.PROCESS = 0 {i} [RE]
5.SECTION = 0 {i} [RE]
5.SECTION_STATUS = 1 {i} [RE]
CHN 00165BE99E4952:6 HmIPW-Rollo-Wohnzimmer
6.ACTIVITY_STATE = 3 {i} [RE]
6.COMBINED_PARAMETER = {s} [W]
6.LEVEL = 1.000000 {f} [RWE]
6.LEVEL_2 = 0.000000 {f} [RWE]
6.LEVEL_2_STATUS = 1 {i} [RE]
6.LEVEL_STATUS = 0 {i} [RE]
6.PROCESS = 0 {i} [RE]
6.SECTION = 4 {i} [RE]
6.SECTION_STATUS = 0 {i} [RE]
6.STOP = {b} [W]
CHN 00165BE99E4952:7 HmIPW-DRBL4 00165BE99E4952:7
7.ACTIVITY_STATE = 3 {i} [RE]
7.COMBINED_PARAMETER = {s} [W]
7.LEVEL = 0.000000 {f} [RWE]
7.LEVEL_2 = 0.000000 {f} [RWE]
7.LEVEL_2_STATUS = 1 {i} [RE]
7.LEVEL_STATUS = 0 {i} [RE]
7.PROCESS = 0 {i} [RE]
7.SECTION = 0 {i} [RE]
7.SECTION_STATUS = 0 {i} [RE]
7.STOP = {b} [W]
CHN 00165BE99E4952:8 HmIPW-DRBL4 00165BE99E4952:8
8.ACTIVITY_STATE = 3 {i} [RE]
8.COMBINED_PARAMETER = {s} [W]
8.LEVEL = 0.000000 {f} [RWE]
8.LEVEL_2 = 0.000000 {f} [RWE]
8.LEVEL_2_STATUS = 1 {i} [RE]
8.LEVEL_STATUS = 0 {i} [RE]
8.PROCESS = 0 {i} [RE]
8.SECTION = 0 {i} [RE]
8.SECTION_STATUS = 0 {i} [RE]
8.STOP = {b} [W]
CHN 00165BE99E4952:9 HmIPW-DRBL4 00165BE99E4952:9
9.ACTIVITY_STATE = 3 {i} [RE]
9.LEVEL = 1.000000 {f} [RE]
9.LEVEL_2 = 0.000000 {f} [RE]
9.LEVEL_2_STATUS = 1 {i} [RE]
9.LEVEL_STATUS = 0 {i} [RE]
9.PROCESS = 0 {i} [RE]
9.SECTION = 0 {i} [RE]
9.SECTION_STATUS = 1 {i} [RE]
CHN 00165BE99E4952:10 HmIPW-Rollo-Esszimmer-Fenster
10.ACTIVITY_STATE = 3 {i} [RE]
10.COMBINED_PARAMETER = {s} [W]
10.LEVEL = 1.000000 {f} [RWE]
10.LEVEL_2 = 0.000000 {f} [RWE]
10.LEVEL_2_STATUS = 1 {i} [RE]
10.LEVEL_STATUS = 0 {i} [RE]
10.PROCESS = 0 {i} [RE]
10.SECTION = 4 {i} [RE]
10.SECTION_STATUS = 0 {i} [RE]
10.STOP = {b} [W]
CHN 00165BE99E4952:11 HmIPW-DRBL4 00165BE99E4952:11
11.ACTIVITY_STATE = 3 {i} [RE]
11.COMBINED_PARAMETER = {s} [W]
11.LEVEL = 0.000000 {f} [RWE]
11.LEVEL_2 = 0.000000 {f} [RWE]
11.LEVEL_2_STATUS = 1 {i} [RE]
11.LEVEL_STATUS = 0 {i} [RE]
11.PROCESS = 0 {i} [RE]
11.SECTION = 0 {i} [RE]
11.SECTION_STATUS = 0 {i} [RE]
11.STOP = {b} [W]
CHN 00165BE99E4952:12 HmIPW-DRBL4 00165BE99E4952:12
12.ACTIVITY_STATE = 3 {i} [RE]
12.COMBINED_PARAMETER = {s} [W]
12.LEVEL = 0.000000 {f} [RWE]
12.LEVEL_2 = 0.000000 {f} [RWE]
12.LEVEL_2_STATUS = 1 {i} [RE]
12.LEVEL_STATUS = 0 {i} [RE]
12.PROCESS = 0 {i} [RE]
12.SECTION = 0 {i} [RE]
12.SECTION_STATUS = 0 {i} [RE]
12.STOP = {b} [W]
CHN 00165BE99E4952:13 HmIPW-DRBL4 00165BE99E4952:13
13.ACTIVITY_STATE = 3 {i} [RE]
13.LEVEL = 1.000000 {f} [RE]
13.LEVEL_2 = 0.000000 {f} [RE]
13.LEVEL_2_STATUS = 1 {i} [RE]
13.LEVEL_STATUS = 0 {i} [RE]
13.PROCESS = 0 {i} [RE]
13.SECTION = 0 {i} [RE]
13.SECTION_STATUS = 1 {i} [RE]
CHN 00165BE99E4952:14 HmIPW-Rollo-Esszimmer-T�r
14.ACTIVITY_STATE = 3 {i} [RE]
14.COMBINED_PARAMETER = {s} [W]
14.LEVEL = 1.000000 {f} [RWE]
14.LEVEL_2 = 0.000000 {f} [RWE]
14.LEVEL_2_STATUS = 1 {i} [RE]
14.LEVEL_STATUS = 0 {i} [RE]
14.PROCESS = 0 {i} [RE]
14.SECTION = 4 {i} [RE]
14.SECTION_STATUS = 0 {i} [RE]
14.STOP = {b} [W]
CHN 00165BE99E4952:15 HmIPW-DRBL4 00165BE99E4952:15
15.ACTIVITY_STATE = 3 {i} [RE]
15.COMBINED_PARAMETER = {s} [W]
15.LEVEL = 0.000000 {f} [RWE]
15.LEVEL_2 = 0.000000 {f} [RWE]
15.LEVEL_2_STATUS = 1 {i} [RE]
15.LEVEL_STATUS = 0 {i} [RE]
15.PROCESS = 0 {i} [RE]
15.SECTION = 0 {i} [RE]
15.SECTION_STATUS = 0 {i} [RE]
15.STOP = {b} [W]
CHN 00165BE99E4952:16 HmIPW-DRBL4 00165BE99E4952:16
16.ACTIVITY_STATE = 3 {i} [RE]
16.COMBINED_PARAMETER = {s} [W]
16.LEVEL = 0.000000 {f} [RWE]
16.LEVEL_2 = 0.000000 {f} [RWE]
16.LEVEL_2_STATUS = 1 {i} [RE]
16.LEVEL_STATUS = 0 {i} [RE]
16.PROCESS = 0 {i} [RE]
16.SECTION = 0 {i} [RE]
16.SECTION_STATUS = 0 {i} [RE]
16.STOP = {b} [W]
CHN 00165BE99E4952:17 HmIPW-DRBL4 00165BE99E4952:17
17.COMBINED_PARAMETER = {s} [W]
17.WEEK_PROGRAM_CHANNEL_LOCKS = 0 {i} [RE]
17.WEEK_PROGRAM_TARGET_CHANNEL_LOCK = {i} [W]
17.WEEK_PROGRAM_TARGET_CHANNEL_LOCKS = {i} [W]
Device detection:
StateDatapoint = 2.LEVEL [BLIND_VIRTUAL_RECEIVER]
StateDatapoint = 7.LEVEL [BLIND_VIRTUAL_RECEIVER]
StateDatapoint = 12.LEVEL [BLIND_VIRTUAL_RECEIVER]
StateDatapoint = 8.LEVEL [BLIND_VIRTUAL_RECEIVER]
StateDatapoint = 3.LEVEL [BLIND_VIRTUAL_RECEIVER]
StateDatapoint = 10.LEVEL [BLIND_VIRTUAL_RECEIVER]
StateDatapoint = 11.LEVEL [BLIND_VIRTUAL_RECEIVER]
StateDatapoint = 4.LEVEL [BLIND_VIRTUAL_RECEIVER]
StateDatapoint = 14.LEVEL [BLIND_VIRTUAL_RECEIVER]
StateDatapoint = 6.LEVEL [BLIND_VIRTUAL_RECEIVER]
StateDatapoint = 16.LEVEL [BLIND_VIRTUAL_RECEIVER]
StateDatapoint = 15.LEVEL [BLIND_VIRTUAL_RECEIVER]
ControlDatapoint = 4.LEVEL [BLIND_VIRTUAL_RECEIVER]
ControlDatapoint = 16.LEVEL [BLIND_VIRTUAL_RECEIVER]
ControlDatapoint = 6.LEVEL [BLIND_VIRTUAL_RECEIVER]
ControlDatapoint = 14.LEVEL [BLIND_VIRTUAL_RECEIVER]
ControlDatapoint = 15.LEVEL [BLIND_VIRTUAL_RECEIVER]
ControlDatapoint = 2.LEVEL [BLIND_VIRTUAL_RECEIVER]
ControlDatapoint = 8.LEVEL [BLIND_VIRTUAL_RECEIVER]
ControlDatapoint = 3.LEVEL [BLIND_VIRTUAL_RECEIVER]
ControlDatapoint = 12.LEVEL [BLIND_VIRTUAL_RECEIVER]
ControlDatapoint = 7.LEVEL [BLIND_VIRTUAL_RECEIVER]
ControlDatapoint = 10.LEVEL [BLIND_VIRTUAL_RECEIVER]
ControlDatapoint = 11.LEVEL [BLIND_VIRTUAL_RECEIVER]
Recommended module for device definition: HMCCUCHN
Current state datapoint = .
Current control datapoint = .
Device description
Device 00165BE99E4952 HmIPW-04-DRBL4-Keller [HmIPW-DRBL4]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 1.6.0
CHILDREN: 00165BE99E4952:0,00165BE99E4952:1,00165BE99E4952:2,00165BE99E4952:3,00165BE99E4952:4,00165BE99E4952:5,00165BE99E4952:6,00165BE99E4952:7,00165BE99E4952:8,00165BE99E4952:9,00165BE99E4952:10,00165BE99E4952:11,00165BE99E4952:12,00165BE99E4952:13,00165BE99E4952:14,00165BE99E4952:15,00165BE99E4952:16,00165BE99E4952:17
DIRECTION: NONE
FIRMWARE: 1.6.0
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 11520847
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG
SUBTYPE: DRBL4
UPDATABLE: 1
Channel 00165BE99E4952:0 HmIPW-04-DRBL4-Keller:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:1 HmIPW-DRBL4 00165BE99E4952:1 [BLIND_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:2 HmIPW-Rollo-K�che [BLIND_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:3 HmIPW-DRBL4 00165BE99E4952:3 [BLIND_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:4 HmIPW-DRBL4 00165BE99E4952:4 [BLIND_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:5 HmIPW-DRBL4 00165BE99E4952:5 [BLIND_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:6 HmIPW-Rollo-Wohnzimmer [BLIND_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:7 HmIPW-DRBL4 00165BE99E4952:7 [BLIND_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:8 HmIPW-DRBL4 00165BE99E4952:8 [BLIND_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:9 HmIPW-DRBL4 00165BE99E4952:9 [BLIND_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:10 HmIPW-Rollo-Esszimmer-Fenster [BLIND_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:11 HmIPW-DRBL4 00165BE99E4952:11 [BLIND_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:12 HmIPW-DRBL4 00165BE99E4952:12 [BLIND_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:13 HmIPW-DRBL4 00165BE99E4952:13 [BLIND_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:14 HmIPW-Rollo-Esszimmer-T�r [BLIND_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:15 HmIPW-DRBL4 00165BE99E4952:15 [BLIND_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:16 HmIPW-DRBL4 00165BE99E4952:16 [BLIND_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,CONDITIONAL_SWITCH,LEVEL,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00165BE99E4952:17 HmIPW-DRBL4 00165BE99E4952:17 [BLIND_WEEK_PROFILE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 00165BE99E4952
PARENT_TYPE: HmIPW-DRBL4
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Danke vorab :)
@SamNitro:
Das Geräte besteht ja aus 4 Kanalgruppen mit je 4 Kanälen, die für die Steuerung verwendet werden. Jede dieser Kanalgruppen setzt sich so zusammen:
1 x Readonly Kanal mit der Rolle BLIND_TRANSMITTER
3 x ReadWrite Kanal mit der Rolle BLIND_VIRTUAL_RECEIVER
Leider erkennt HMCCU die Rolle BLIND_TRANSMITTER nicht (die habe ich jetzt für die nächste Version bereits hinzugefügt). Trotzdem kann der Kanal natürlich benutzt werden, um den Status abzufragen (weil Readonly).
Die Integration kann sowohl mit HMCCUCHN als auch mit HMCCUDEV erfolgen. Momentan würde ich HMCCUCHN empfehlen, bis BLIND_TRANSMITTER erkannt wird. Dazu definierst Du ein HMCCUCHN Device für die Adresse des ersten BLIND_VIRTUAL_RECEIVER Kanals einer Kanalgruppe. Das sind bei Deinem Gerät die Kanäle 2, 6, 10 und 14.
Also z.B.
define Rollo-Kueche HMCCUCHN 00165BE99E4952:2
Die Verwendung des Gerätenamens statte der Adresse im define ist leider nicht möglich, da Du hier einen Umlaut verwendest ("Küche"). Mit diesem Define sollte sich das Rollo steuern lassen. Die naträgliche Änderung der vorhandenen Defines solltest Du wenn möglich vermeiden und lieber die Geräte löschen und neu definieren.
Auch HMCCUDEV sollte funktionieren. Allerdings kann es aufgrund der fehlenden Unterstützung von BLIND_TRANSMITTER vielleicht doch Seiteneffekte geben. In dem Fall musst Du allerdings statedatapoint und controldatapoint setzen, also:
define Rollo-Kueche HMCCUDEV 00165BE99E4952
attr Rollo-Kueche controldatapoint 2.LEVEL
attr Rollo-Kueche statedatapoint 1.LEVEL
Bei statedatapoint müsste auch 2.LEVEL funktionieren. 1.LEVEL enthält jedoch den kombinierten Status der Schaltkanäle 2,3,4.
Für die weiteren Kanalgruppen sieht das define genauso aus. Die Unterscheidung erfolgt lediglich über statedatapoint und controldatapoint, also:
define Rollo-Wohnzimmer HMCCUDEV 00165BE99E4952
attr Rollo-Kueche controldatapoint 6.LEVEL
attr Rollo-Kueche statedatapoint 5.LEVEL
Wenn Du den kombinierten Status nich brauchst, nimm HMCCUCHN für die Kanäle 2,6,10,14. Das ist einfacher.
Hey, ja als HMCCUCHN wäre mir auch lieber und ist auch von den readings her übersichtlicher. Momentan habe ich das auch so wie du beschrieben hast um sie wenigstens zu steuern.
define Rollo-Kueche HMCCUCHN 00165BE99E4952:2
Kannst du schon sagen wann das update kommt?
Und was funktioniert damit nicht? Ich habe meine Rollläden genauso definiert. Das funktioniert.
Wenn ich am örtlichen Taster rauf oder runter fahre oder wenn ich per Open Close den Rollo fahre zeigt er mir entweder Position 0 oder 100 bzw. Open Close direkt an auch wenn ich ihn in der Mitte stoppe.
Wenn Du per set pct auf 50 oder 60 % fährst, zeigt er danach 50 oder 60 an?
Ja dann schon.
Ein neues Update steht in Github sowie im SVN (Contrib) bereit.
Behobene Fehler:
- Bei HMCCUDEV Devices mit einem Datenpunkt LEVEL (z.B. Rollläden) wurde der Wert nicht in Prozent umgerechnet
- HMCCU unterstützt nun Gerätekanäle mit der Rolle BLIND_TRANSMITTER (z.B. HmIPW-04-DRBL4)
- Die Skalierung eines Readings konnte fehlschlagen, wenn in der CCU für einen Datenpunkt kein Element UNIT definiert war
Installation und Konfigurationupdate all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txtoder
update all https://svn.fhem.de/trac/browser/trunk/fhem/contrib/HMCCU/controls_HMCCU.txt
Hey leider habe ich genau das selbe verhalten wie vorher.
defmod HmIPW_Rollo_Wohnzimmer HMCCUCHN 00165BE99E4952:5
Nur Anzeige keine Steuerung
defmod HmIPW_Rollo_Wohnzimmer HMCCUCHN 00165BE99E4952:6
Kann steuern aber keine Anzeige
Und mit Kanal 7 oder 8?
Bei Kanal 6 werden keine Readings aktualisiert?
Ja er holt da nicht den korrekten pct wert.
Bzw. in der CCU kennt er bei den Kanälen auch nur 0% oder 100%
Auch leider nicht bei Kanal 7-8
Das mit der CCU ist interessant. Dann kennen wir jetzt zumindest die Ursache, denn HMCCU stellt ja nur die Werte der CCU dar. Gibt es ein Firmware Update für CCU und/oder das Gerät?
Kannst Du nochmal einen Versuch mit HMCCUDEV machen? Das Device bitte mal einfach in FHEM mit define neu definieren:
define xy HMCCUDEV 00165BE99E4952
attr xy statedatapoint 5.LEVEL
attr xy controldatapoint 6.LEVEL
Weitere Attribute (substexcl) sollten automatisch gesetzt werden.
Zitat von: isy am 07 Mai 2021, 15:45:49
1 Warning nach Update auf Beta4 im Log:
PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/88_HMCCU.pm line 8458.
FM ist weg mit der aktuellen Beta5 (4.4.068)
Zitat von: zap am 18 Mai 2021, 11:02:19
Das mit der CCU ist interessant. Dann kennen wir jetzt zumindest die Ursache, denn HMCCU stellt ja nur die Werte der CCU dar. Gibt es ein Firmware Update für CCU und/oder das Gerät?
Darum wollte ich ja den Status von 5.Level und die Steuerbefehle von 6.Level.
Nein Firmware ist alles auf dem neuesten stand.
Als HMCCUDEV Scheint jetzt alles zu funktionieren.
substexcl muss ich aber auf state oder hmstate setzen pct wäre auch der falsche wert.
hmstate 93.5 2021-05-18 11:23:46
pct closed 2021-05-18 11:23:46
state 93.5 2021-05-18 11:23:44
Edit: nach einen "get update" und "set default reset" wird auch pct korrekt angezeigt.
pct sollte auf jeden Fall in substexcl enthalten sein, sonst funktioniert der set pct Befehl bzw. das Slider Widget nicht richtig. Irgendwie passen die Werte auch nicht. pct müsste statt "closed" auch 93.5 anzeigen. Nur 100 wäre closed.
Alles etwas komisch. Habe substexcl auf hmstate und der slider funktioniert.
Für mich reicht es so erstmal.
Wenn du trotzdem noch Infos brauchst sag Bescheid.
Ein weiteres Update steht in Github und SVN zur Verfügung mit folgendem Inhalt:
- Beim automatischen Erstellen von mehreren HMCCUCHN Devices zu einem CCU Device (z.B. bei Fernbedienungen) werden die erzeugten FHEM Devices nun nicht mehr durchnummeriert sondern übernehmen die Namen der zugehörigen CCU Kanäle
- Die state und control Datenpunkte beim Befehl 'get deviceInfo' werden nun nach Kanalnummer sortiert ausgegeben
- Automatische Erkennung der Kanalrollen DIMMER_TRANSMITTER und SHUTTER_TRANSMITTER hinzugefügt
- Die Befehle 'get create' und 'get createDev' unterstützen nun Geräte mit 4er Kanalgruppen (1 kombinierter Statuskanal, 3 virtuelle Schaltkanäle)
- Die Liste der Devices in einigen I/O Device get Befehlen wurde nicht aktualisiert
- FHEM Devices für virtuelle Heizungsgruppen können nun auch angelegt werden, wenn die Konfiguration der Gruppen nicht ermittelt werden kann
Weiter Details: https://github.com/zapccu/HMCCU/issues?q=is%3Aissue+is%3Aclosed+milestone%3A%22RC5+4.4.069%22
Installation siehe 1. Beitrag in diesem Thread.
Ich werde diese Woche noch einmal die Migration meiner alten 4.3er Konfiguration (ca. 80 Homematic Devices) auf die Version 4.4 testen. Wenn das gut funktioniert, geht die 4.4 nächstes Wochenende live.
Beta war jetzt lange genug. Die 4.4 ist praktisch eine Neuentwicklung, vielleicht nenne ich sie dann 5.0 ;)
Hallo zap
Auf diesem Wege schon mal ein großes Dankeschön für deine unermüdliche und unbezahlbare Arbeit!
Dann warte ich weiterhin noch etwas bis die "4.4" offiziell wird.
Ich muss dann auch noch alles von der CCU2 auf Raspimatic umziehen.
;D
Gruß Gerd
Update verlief ohne Probleme.
Auch ich freue mich auf das "Release 5.0" ;D
Viele Grüße
Jürgen
Beta zuende und Version 5.0 da - hört sich gut an.
Freue mich schon drauf.
Danke für die unermüdliche Arbeit ZAP !!!!
Das klingt klasse!
Ich habe die ganze HMCCU 4.4Beta geschichte von FHEM Update ausgeschlossen... wenn ich das nun rückgängig mache, wird dann alles schön geupdatet und funktioniert schick?
Vielen Dank!!
Kurzes Update: Die HMCCU Version 4.4 konnte ich mit meiner 4.3 All-In Config mit >80 Geräten starten. Jetzt muss ich mal (stichprobenartig) testen, ob alles funktioniert. Bin optimistisch :)
Zitat von: zap am 31 Mai 2020, 17:44:40
Danke für's Feedback. Das Attribut ccudef-readingname habe ich entsorgt. Kann also ignoriert werden. HMCCU sucht sich seine Standard Readingnames jetzt anhand der erkannten Kanalrollen selbst zusammen.
Das Attribut ccureadingname in den einzelnen Devices gibt es natürlich weiterhin.
hmm, wieso? bei mir funktioniert einiges nicht mehr mit der aktuellen Version.
Ich hatte/habe:
attr CCU3 ccudef-readingname ^(.+\.)?LOW_?BAT$:battery;;^(.+\.)?UNREACH$:activity;;^[1-8].PRESS_(SHORT|LONG)$:PRESSED
Lowbat: erstmal egal, unreach: nicht so egal aber erstmal schon, aber die Press Geschichte nicht wirklich. Nun muss ich das auf jeder Fernbedienung und Klingel and whatnot eintragen? :-( ... vorher gefiel mir das eindeutig besser :)
Ich mag Option-VerXfachung eigentlich nicht, aber so wie ich das aktuell sehe muss ich o.g. nun auf jedem einzelnen Device eintragen?
Die Readings battery und activity gibt es nun in jedem Device (automatisch). Pressed nehme ich noch auf.
Nur zur Info für dich Zap:
"Missing parameter time. Usage: set HM_DA_Esstisch pct level time ramp"
Es handelt sich um einen HmIP-BDT. Die Werte time und ramp kennt der Aktor nicht einmal, die kann ich nur über die Tasten eingeben. Und da fehlt mir ehrlich gesagt noch immer der Durchblick was wofür gemeint ist. Wenn ich level = 40% angebe und dazu eine time = 5s, habe ich eine "Ramp". Würde mich wundern, wenn die Jungs von eQ-3 wissen was "ramp" beeinflusst. Zumindest haben sie da nichts dokumentiert.
Gruß Reinhard
Sorry, ganz vergessen. Für "pct" hätte ich tatsächlich nur "level" erwartet. Wohin gehen die anderen Werte?
Machst Du mal bitte ein list von dem Device und noch ein get deviceinfo?
Die Rolle DIMMER_VIRTUAL_RECEIVER hat alle notwendigen Datenpunkte
level => LEVEL
time => ON_TIME
ramp => RAMP_TIME
Zitat von: zap am 24 Juni 2021, 18:43:29
Die Readings battery und activity gibt es nun in jedem Device (automatisch). Pressed nehme ich noch auf.
Ok überredet ;-) ... das wäre top. Danke!
Magst du mir Bescheid geben wenn das drin ist?
Dann gehe ich wieder auf die 4.4 und teste mein Setup damit mal durch. Evtl. finden wir ja noch paar Bugs die vor dem Release noch behoben werden können :)
Zitat von: zap am 24 Juni 2021, 21:01:32
Machst Du mal bitte ein list von dem Device und noch ein get deviceinfo?
Die Rolle DIMMER_VIRTUAL_RECEIVER hat alle notwendigen Datenpunkte
level => LEVEL
time => ON_TIME
ramp => RAMP_TIME
Hallo Zap,
hier die beiden Listings:
DEV HM_DA_Esstisch Dev 0008DBE99F04CA interface=HmIP-RF type=HmIP-BDT
CHN 0008DBE99F04CA:0 HM_DA_Esstisch Dev:0
0.ACTUAL_TEMPERATURE = 0.000000 {f} [RE]
0.ACTUAL_TEMPERATURE_STATUS = 0 {i} [RE]
0.CONFIG_PENDING = false {b} [RE]
0.DUTY_CYCLE = false {b} [RE]
0.ERROR_CODE = 0 {n} [RE]
0.ERROR_OVERHEAT = false {b} [RE]
0.ERROR_OVERLOAD = false {b} [RE]
0.ERROR_UPDATE = false {b} [RE]
0.INSTALL_TEST = true {b} [RW]
0.OPERATING_VOLTAGE = 0.000000 {f} [RE]
0.OPERATING_VOLTAGE_STATUS = 0 {i} [RE]
0.RSSI_DEVICE = 196 {n} [RE]
0.RSSI_PEER = 186 {n} [RE]
0.UNREACH = false {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
CHN 0008DBE99F04CA:1 HM_DA_Esstisch Taster unten
1.PRESS_LONG = {b} [E]
1.PRESS_SHORT = false {b} [E]
CHN 0008DBE99F04CA:2 HM_DA_Esstisch Taster oben
2.PRESS_LONG = {b} [E]
2.PRESS_SHORT = false {b} [E]
CHN 0008DBE99F04CA:3 HM_DA_Esstisch Status
3.ACTIVITY_STATE = 0 {i} [RE]
3.LEVEL = 0.000000 {a} [RE]
3.LEVEL_STATUS = 0 {i} [RE]
3.PROCESS = 0 {i} [RE]
3.SECTION = 15 {i} [RE]
3.SECTION_STATUS = 0 {i} [RE]
CHN 0008DBE99F04CA:4 HM_DA_Esstisch Aktor
4.ACTIVITY_STATE = 3 {i} [RE]
4.COMBINED_PARAMETER = {s} [W]
4.LEVEL = 0.000000 {a} [RWE]
4.LEVEL_STATUS = 0 {i} [RE]
4.ON_TIME = {f} [W]
4.PROCESS = 0 {i} [RE]
4.RAMP_TIME = {f} [W]
4.SECTION = 0 {i} [RE]
4.SECTION_STATUS = 0 {i} [RE]
CHN 0008DBE99F04CA:5 HmIP-BDT 0008DBE99F04CA:5
5.ACTIVITY_STATE = 3 {i} [RE]
5.COMBINED_PARAMETER = {s} [W]
5.LEVEL = 0.000000 {a} [RWE]
5.LEVEL_STATUS = 0 {i} [RE]
5.ON_TIME = {f} [W]
5.PROCESS = 0 {i} [RE]
5.RAMP_TIME = {f} [W]
5.SECTION = 0 {i} [RE]
5.SECTION_STATUS = 0 {i} [RE]
CHN 0008DBE99F04CA:6 HmIP-BDT 0008DBE99F04CA:6
6.ACTIVITY_STATE = 3 {i} [RE]
6.COMBINED_PARAMETER = {s} [W]
6.LEVEL = 0.000000 {a} [RWE]
6.LEVEL_STATUS = 0 {i} [RE]
6.ON_TIME = {f} [W]
6.PROCESS = 0 {i} [RE]
6.RAMP_TIME = {f} [W]
6.SECTION = 0 {i} [RE]
6.SECTION_STATUS = 0 {i} [RE]
CHN 0008DBE99F04CA:7 HM_DA_Esstisch Pgm
7.COMBINED_PARAMETER = {s} [W]
7.WEEK_PROGRAM_CHANNEL_LOCKS = 0 {i} [RE]
7.WEEK_PROGRAM_TARGET_CHANNEL_LOCK = {i} [W]
7.WEEK_PROGRAM_TARGET_CHANNEL_LOCKS = {i} [W]
Device detection:
StateDatapoint = 1.PRESS_SHORT [KEY_TRANSCEIVER]
StateDatapoint = 2.PRESS_SHORT [KEY_TRANSCEIVER]
StateDatapoint = 3.LEVEL [DIMMER_TRANSMITTER]
StateDatapoint = 4.LEVEL [DIMMER_VIRTUAL_RECEIVER]
StateDatapoint = 5.LEVEL [DIMMER_VIRTUAL_RECEIVER]
StateDatapoint = 6.LEVEL [DIMMER_VIRTUAL_RECEIVER]
ControlDatapoint = 4.LEVEL [DIMMER_VIRTUAL_RECEIVER]
ControlDatapoint = 5.LEVEL [DIMMER_VIRTUAL_RECEIVER]
ControlDatapoint = 6.LEVEL [DIMMER_VIRTUAL_RECEIVER]
Recommended module for device definition: HMCCUDEV
Current state datapoint = 4.LEVEL
Current control datapoint = 4.LEVEL
Device description
Device 0008DBE99F04CA HM_DA_Esstisch Dev [HmIP-BDT]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 0008DBE99F04CA:0,0008DBE99F04CA:1,0008DBE99F04CA:2,0008DBE99F04CA:3,0008DBE99F04CA:4,0008DBE99F04CA:5,0008DBE99F04CA:6,0008DBE99F04CA:7
DIRECTION: NONE
FIRMWARE: 1.4.8
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 5787785
ROAMING: 0
RX_MODE:
SUBTYPE: BDT
UPDATABLE: 1
Channel 0008DBE99F04CA:0 HM_DA_Esstisch Dev:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 0008DBE99F04CA
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0008DBE99F04CA:1 HM_DA_Esstisch Taster unten [KEY_TRANSCEIVER] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 0008DBE99F04CA
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0008DBE99F04CA:2 HM_DA_Esstisch Taster oben [KEY_TRANSCEIVER] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 0008DBE99F04CA
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0008DBE99F04CA:3 HM_DA_Esstisch Status [DIMMER_TRANSMITTER] known
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 0008DBE99F04CA
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0008DBE99F04CA:4 HM_DA_Esstisch Aktor [DIMMER_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: LEVEL,SWITCH,CONDITIONAL_SWITCH,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 0008DBE99F04CA
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0008DBE99F04CA:5 HmIP-BDT 0008DBE99F04CA:5 [DIMMER_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: LEVEL,SWITCH,CONDITIONAL_SWITCH,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 0008DBE99F04CA
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0008DBE99F04CA:6 HmIP-BDT 0008DBE99F04CA:6 [DIMMER_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: LEVEL,SWITCH,CONDITIONAL_SWITCH,REMOTE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 0008DBE99F04CA
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 0008DBE99F04CA:7 HM_DA_Esstisch Pgm [DIMMER_WEEK_PROFILE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 0008DBE99F04CA
PARENT_TYPE: HmIP-BDT
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Defaults
Support for role(s) KEY_TRANSCEIVER,KEY_TRANSCEIVER,DIMMER_TRANSMITTER,DIMMER_VIRTUAL_RECEIVER,DIMMER_VIRTUAL_RECEIVER,DIMMER_VIRTUAL_RECEIVER of device type HmIP-BDT is built in.
Internals:
DEF 0008DBE99F04CA
FUUID 60d22d9f-f33f-dca3-2f93-fce7c94780c3e98e
IODev myccu
NAME HM_DA_Esstisch
NR 247
STATE off
TYPE HMCCUDEV
ccuaddr 0008DBE99F04CA
ccudevstate active
ccuif HmIP-RF
ccuname HM_DA_Esstisch Dev
ccusubtype BDT
ccutype HmIP-BDT
firmware 1.4.8
readonly no
OLDREADINGS:
2021-06-24 21:44:07 control 35
READINGS:
2021-06-25 17:17:57 4.ACTIVITY_STATE STABLE
2021-06-25 17:17:57 4.LEVEL off
2021-06-25 17:17:57 4.LEVEL_STATUS NORMAL
2021-06-23 20:46:36 IODev myccu
2021-06-25 17:17:58 IconColor FFA600
2021-06-25 17:17:58 activity alive
2021-06-25 17:17:57 control 0
2021-06-25 17:17:58 control_old 35
2021-06-25 17:17:58 devstate ok
2021-06-25 17:17:58 hmstate off
2021-06-25 17:17:57 pct 0
2021-06-25 17:17:58 rssidevice -60
2021-06-25 17:17:58 rssipeer -70
2021-06-25 17:17:57 state off
hmccu:
channels 8
devspec 0008DBE99F04CA
forcedev 0
nodefaults 1
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:KEY_TRANSCEIVER,3:DIMMER_TRANSMITTER,4:DIMMER_VIRTUAL_RECEIVER,5:DIMMER_VIRTUAL_RECEIVER,6:DIMMER_VIRTUAL_RECEIVER,7:DIMMER_WEEK_PROFILE
semDefaults 0
cmdlist:
get
set pct on:noArg off:noArg toggle:noArg
control:
chn 4
dpt LEVEL
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
NVAL 0.000000
ONVAL 0.000000
OSVAL 0
OVAL 0.000000
SVAL 0
VAL 0.000000
0.ACTUAL_TEMPERATURE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_OVERLOAD:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_UPDATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.INSTALL_TEST:
VALUES:
NVAL true
ONVAL true
OSVAL true
OVAL true
SVAL true
VAL true
0.OPERATING_VOLTAGE:
VALUES:
NVAL 0.000000
ONVAL 0.000000
OSVAL 0
OVAL 0.000000
SVAL 0
VAL 0.000000
0.OPERATING_VOLTAGE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL -60
ONVAL -60
OSVAL -60
OVAL -60
SVAL -60
VAL -60
0.RSSI_PEER:
VALUES:
NVAL -70
ONVAL -71
OSVAL -71
OVAL -71
SVAL -70
VAL -70
0.UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
3.ACTIVITY_STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL UNKNOWN
OVAL 0
SVAL UNKNOWN
VAL 0
3.LEVEL:
VALUES:
NVAL 0.0
ONVAL 0.0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
3.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
3.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
3.SECTION:
VALUES:
NVAL 15
ONVAL 15
OSVAL 15
OVAL 15
SVAL 15
VAL 15
3.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
4.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
4.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
4.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
5.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
5.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
5.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
5.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
6.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
6.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
6.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
6.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.WEEK_PROGRAM_CHANNEL_LOCKS:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
roleCmds:
get:
set:
off:
channel 4
role DIMMER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:0
usage off
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
unit 100%
on:
channel 4
role DIMMER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:100
usage on
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
unit 100%
on-for-timer:
role DIMMER_VIRTUAL_RECEIVER
syntax V:ON_TIME:?duration V:STATE:1
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname duration
partype 2
ps VALUES
unit s
on-till:
role DIMMER_VIRTUAL_RECEIVER
syntax V:ON_TIME:?time V:STATE:1
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname time
partype 2
ps VALUES
unit s
pct:
channel 4
role DIMMER_VIRTUAL_RECEIVER
subcount 3
syntax V:LEVEL:?level V:ON_TIME:?time V:RAMP_TIME:?ramp
usage pct level time ramp
subcmd:
000:
args
dpt LEVEL
fnc
max 1.01
min 0.0
parname level
partype 2
ps VALUES
unit 100%
001:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname time
partype 2
ps VALUES
unit s
002:
args
dpt RAMP_TIME
fnc
max 8580000.0
min 0.0
parname ramp
partype 2
ps VALUES
unit s
state:
chn 4
dpt LEVEL
Attributes:
IODev myccu
alias Esstisch
ccureadingfilter (ERROR|ACTUAL_TEMPERATURE);4.(ACTIVITY|STATE|LEVEL)
controldatapoint 4.LEVEL
devStateIcon { Color::devStateIcon($name,"rgb","IconColor","pct","state") }
gassistantName Tisch
genericDeviceType light
group Essecke
homebridgeMapping {
"Brightness": {
"reading": "control",
"cmd": "control"
}
}
oldreadings control
realRoom Essecke
room Beleuchtung,GoogleAssistant,Homematic
sortby 10
statedatapoint 4.LEVEL
statevals on:100,off:0
stripnumber 0
substexcl control|pct
substitute LEVEL!#0-0:off,#1-100:on
userReadings IconColor {"FFA600"},
control_old {OldReadingsVal($NAME,"control",0)}
userattr structexclude switch switch_map
webCmd control:control 25:control 50:control 75:control 100
webCmdLabel Dimmer :25:50:75:100
widgetOverride control:colorpicker,BRI,0,1,100Gruß Reinhard
Zur Info: nach einem Update von 4.3 auf 4.4 Beta kommt bei mir noch folgender Fehler nach Systemstart
"unknown attribute rpcport"
hier noch ein paar Perl-Fehler:
2021.06.30 20:07:35 1: PERL WARNING: Use of uninitialized value $sc in string ne at ./FHEM/88_HMCCU.pm line 7620.
2021.06.30 20:07:35 1: PERL WARNING: Use of uninitialized value $cc in string ne at ./FHEM/88_HMCCU.pm line 7621.
2021.06.30 20:07:35 1: PERL WARNING: Use of uninitialized value $address in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 7799.
dazu noch Fehlermeldungen in der folgenden Art:
HMCCU [Debmatic] Can't get device description for BidCoS-RF ....
Aber es scheint alles zu laufen
@StephanFHEM: Die Perl Fehler schaue ich mir an. Das Attribut rpcport gibt es nicht mehr. Sollte aber trotzdem funktionieren. Um einzelne Interfaces auszuwählen (BidCos, HmIP, ...), bitte das Attribut rpcinterfaces verwenden.
Du könntest mal ein list vom I/O Device machen und schauen, was unter hmccu:rpcports eingetragen ist. Beispiel (bei mir):
hmccu:
... (andere Einträge)
rpcports 2001,2010,8701,9292
Danke für deine Antwort. Ich hab das Attribut nicht mehr gefunden im Device... die Fehlermeldung kommt jetzt auch nicht mehr. Wenns beim nächsten Start wieder da ist mach ich mal ein list und setzte das ggf. neu. Vielleicht hat es sich irgendwo verhaspelt.
Ansonsten läuft es super und zwei neue Fensterkontakte wurden auch gut erkannt und mit allen Readings angelegt.
Zitat von: zap am 05 Januar 2020, 19:49:52
Die Version 4.4 von HMCCU steht nun als Beta im SVN zur Verfügung. Die Beta-Phase wird bald enden (Stand Ende 2020). Da aber noch nicht alles getestet ist und stabil läuft, habe ich die 4 Module zunächst unter
contrib/HMCCU/FHEM
sowie auf Github abgelegt.
Installation und Konfiguration
update all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
oder
update all https://svn.fhem.de/trac/browser/trunk/fhem/contrib/HMCCU/controls_HMCCU.txt
Zurück zur alten Version 4.3
......
Hallo zap,
ich habe heute mein neuen RPi4 mit RaspberryMatic angeworfen und wollte diesen nun mit dem ebenfalls neuen FHEM auf einem RPi4 über HMCCU anbinden.
Was mich jetzt erst mal zur Verzweiflung getrieben hat, war die Tatsache, das ich keine Ahnung mehr hatte wie ich das damals mit der CCU2/HMCCU 4.3 eingerichtet hatte.
Mit viel dann wieder ein, das ich doch irgendwo Berechtigungen etc. in der CCU2 setzen musste.
Dies steht auch im Wiki so drin, nur war mit das nach so langer Zeit nicht mehr bewusst :-\
Ich war mir auch nicht mehr sicher in wie weit man den dem Wiki zur V4.3 folgen sollte....
Vielleicht kannst Du ja hier für alle Neueinsteiger (oder Neuinstallierer) noch mal den Hinweis geben das die Infos im Wiki https://wiki.fhem.de/wiki/HMCCU (https://wiki.fhem.de/wiki/HMCCU), was den Zugriff auf die CCU2/3 angeht, zu beachten sind!
Ich habe mir nach dem letzten Hagelschaden an meiner Wetterstation und ringen mit dem Geldbeutel nun doch noch die große Wetterstation von HM (HmIP-SWO-PR) gegönnt.
Diese werde ich jetzt versuchen zu integrieren.
Danach folgen dann die 16 Türsensoren und 11 Ventile :=)
Danke noch mal für deine Zeit :)
Gruss Gerd
Hallo zap,
ich habe hier via HMCCU V4.4 versucht die HmIP-SWO-PR automatisch über das Menü mittels "get d_ccu createDev" anzulegen.
Wenn ich dann das Device auswähle und auf OK klicke kommt die Meldung :
ZitatResults of create command:
Not detected CCU devices:
HmIP-SWO-PR 00185BE9A57631 = 00185BE9A57631 [HmIP-SWO-PR 00185BE9A57631]
Manuell konnte ich das HMCCUDEV aber anlegen und es kommen auch die Daten.
Auch die diversen Informationen kann ich über HMCCU anzeigen lassen.
Beim angelernten "HM-PB-2-WM55-2" kann ebenfalls kein Device automatisch angelegt werden.
Gibt es den sowas wie Templates für die verschiedenen Geräte von HM?
Gerade bei der Wetterstation wäre das einfach um das Rad nicht immer wieder neu erfinden zu müssen.
Gruss Gerd
Die Templates wurden in 4.4 durch die Rollen ersetzt. Jeder Kanal eines Gerätes hat genau eine Rolle (zB SWITCH). HMCCU unterstützt diese Rollen (leider noch nicht alle). Ich schaue mir Deine Geräte mal an.
Du kannst mir helfen, indem Du für beide mal ein get deviceinfo ausführst.
Update: Für die Wetterstation habe ich den Fehler vermutlich schon gefunden. HMCCU kennt zwar die Kanalrolle WEATHER_TRANSMIT, allerdings habe ich den falschen Datenpunkt für die Temperatur verwendet.
Ich brauche das get deviceinfo also nur noch für das andere Gerät
OK.
Dazu muss ich an den PC. Dauert noch ein paar Minuten.
Das HF-Modul taucht ebenfalls in der Liste auf.
Aber keine Ahnung ob es dazu sinnvolle Daten zum Anzeigen gibt.
Ich musste dann unterbrechen.
Sind dann Irish Pub essen gegangen ;)
Danke und Gruß
Gerd
Wetterstation zum Abgleich:
DEV HmIP-SWO-PR 00185BE9A57631 00185BE9A57631 interface=HmIP-RF type=HmIP-SWO-PR
CHN 00185BE9A57631:0 HmIP-SWO-PR 00185BE9A57631:0
0.CONFIG_PENDING = false {b} [RE]
0.DUTY_CYCLE = false {b} [RE]
0.ERROR_CODE = 192 {n} [RE]
0.ERROR_WIND_COMMUNICATION = true {b} [RE]
0.ERROR_WIND_NORTH = true {b} [RE]
0.INSTALL_TEST = true {b} [RW]
0.LOW_BAT = false {b} [RE]
0.RSSI_DEVICE = 202 {n} [RE]
0.RSSI_PEER = 0 {n} [RE]
0.TEMPERATURE_OUT_OF_RANGE = false {b} [RE]
0.UNREACH = false {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
CHN 00185BE9A57631:1 HmIP-SWO-PR 00185BE9A57631:1
1.ACTUAL_TEMPERATURE = 21.800000 {f} [RE]
1.ACTUAL_TEMPERATURE_STATUS = 0 {i} [RE]
1.HUMIDITY = 55 {i} [RE]
1.HUMIDITY_STATUS = 0 {i} [RE]
1.ILLUMINATION = 197.300000 {f} [RE]
1.ILLUMINATION_STATUS = 0 {i} [RE]
1.RAINING = false {b} [RE]
1.RAIN_COUNTER = 2.400000 {f} [RE]
1.RAIN_COUNTER_OVERFLOW = false {b} [RE]
1.RAIN_COUNTER_STATUS = 0 {i} [RE]
1.SUNSHINEDURATION = 6 {i} [RE]
1.SUNSHINEDURATION_OVERFLOW = false {b} [RE]
1.SUNSHINE_THRESHOLD_OVERRUN = false {b} [RE]
1.WIND_DIR = {f} [RE]
1.WIND_DIR_RANGE = {f} [RE]
1.WIND_DIR_RANGE_STATUS = 1 {i} [RE]
1.WIND_DIR_STATUS = 1 {i} [RE]
1.WIND_SPEED = 0.000000 {f} [RE]
1.WIND_SPEED_STATUS = 0 {i} [RE]
1.WIND_THRESHOLD_OVERRUN = false {b} [RE]
svHmIPSunshineCounterYesterday_1609 = 0.000000 {f} [RWE]
svHmIPSunshineCounterToday_1609 = 6.000000 {f} [RWE]
svHmIPRainCounterYesterday_1609 = 1.200000 {f} [RWE]
svHmIPRainCounterToday_1609 = 1.200000 {f} [RWE]
Device detection:
No state datapoint detected
No control datapoint detected
Failed to detect device settings. Device must be configured manually.
Current state datapoint = .
Current control datapoint = .
Device description
Device 00185BE9A57631 HmIP-SWO-PR 00185BE9A57631 [HmIP-SWO-PR]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 00185BE9A57631:0,00185BE9A57631:1,00185BE9A57631:2,00185BE9A57631:3,00185BE9A57631:4,00185BE9A57631:5,00185BE9A57631:6,00185BE9A57631:7,00185BE9A57631:8
DIRECTION: NONE
FIRMWARE: 1.0.18
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 3622484
ROAMING: 0
RX_MODE: CONFIG
SUBTYPE: SWO-PR
UPDATABLE: 1
Channel 00185BE9A57631:0 HmIP-SWO-PR 00185BE9A57631:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 00185BE9A57631
PARENT_TYPE: HmIP-SWO-PR
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00185BE9A57631:1 HmIP-SWO-PR 00185BE9A57631:1 [WEATHER_TRANSMIT] known
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 00185BE9A57631
PARENT_TYPE: HmIP-SWO-PR
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00185BE9A57631:2 HmIP-SWO-PR 00185BE9A57631:2 [COND_SWITCH_TRANSMITTER_WIND_SPEED]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00185BE9A57631
PARENT_TYPE: HmIP-SWO-PR
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00185BE9A57631:3 HmIP-SWO-PR 00185BE9A57631:3 [COND_SWITCH_TRANSMITTER_TEMPERATURE]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00185BE9A57631
PARENT_TYPE: HmIP-SWO-PR
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00185BE9A57631:4 HmIP-SWO-PR 00185BE9A57631:4 [COND_SWITCH_TRANSMITTER_HUMIDITY]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00185BE9A57631
PARENT_TYPE: HmIP-SWO-PR
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00185BE9A57631:5 HmIP-SWO-PR 00185BE9A57631:5 [COND_SWITCH_TRANSMITTER_BRIGHTNESS]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00185BE9A57631
PARENT_TYPE: HmIP-SWO-PR
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00185BE9A57631:6 HmIP-SWO-PR 00185BE9A57631:6 [COND_SWITCH_TRANSMITTER_RAIN_QUANTITY]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00185BE9A57631
PARENT_TYPE: HmIP-SWO-PR
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00185BE9A57631:7 HmIP-SWO-PR 00185BE9A57631:7 [COND_SWITCH_TRANSMITTER_RAIN_DROP]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00185BE9A57631
PARENT_TYPE: HmIP-SWO-PR
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00185BE9A57631:8 HmIP-SWO-PR 00185BE9A57631:8 [COND_SWITCH_TRANSMITTER_WIND_DIRECTION]
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00185BE9A57631
PARENT_TYPE: HmIP-SWO-PR
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Defaults
Support for role(s) WEATHER_TRANSMIT of device type HmIP-SWO-PR is built in.
Der Windrichtungszeiger ist noch nicht kalibriert und aufgesetzt.
Taster HM-PB-2-WM55-2:
DEV HM-PB-2-WM55-2 LTK0043889 LTK0043889 interface=BidCos-RF type=HM-PB-2-WM55-2
CHN LTK0043889:0 HM-PB-2-WM55-2 LTK0043889:0
0.UNREACH = false {b} [RE]
0.STICKY_UNREACH = false {b} [RWE]
0.CONFIG_PENDING = false {b} [RE]
0.LOWBAT = false {b} [RE]
0.RSSI_DEVICE = 1 {n} [RE]
0.RSSI_PEER = 203 {n} [RE]
0.AES_KEY = 0 {n} [R]
CHN LTK0043889:1 HM-PB-2-WM55-2 LTK0043889:1
1.PRESS_SHORT = false {b} [WE]
1.PRESS_LONG = false {b} [WE]
1.INSTALL_TEST = false {b} [E]
1.PRESS_CONT = {b} [E]
1.PRESS_LONG_RELEASE = false {b} [E]
CHN LTK0043889:2 HM-PB-2-WM55-2 LTK0043889:2
2.PRESS_SHORT = false {b} [WE]
2.PRESS_LONG = {b} [WE]
2.INSTALL_TEST = false {b} [E]
2.PRESS_CONT = {b} [E]
2.PRESS_LONG_RELEASE = {b} [E]
Device detection:
StateDatapoint = 1.PRESS_SHORT [KEY]
StateDatapoint = 2.PRESS_SHORT [KEY]
ControlDatapoint = 1.PRESS_SHORT [KEY]
ControlDatapoint = 2.PRESS_SHORT [KEY]
Recommended module for device definition: HMCCUCHN
Current state datapoint = 1.PRESS_SHORT
Current control datapoint = 1.PRESS_SHORT
Device description
Device LTK0043889 HM-PB-2-WM55-2 LTK0043889 [HM-PB-2-WM55-2]
CHILDREN: LTK0043889:0,LTK0043889:1,LTK0043889:2
FIRMWARE: 1.4
FLAGS: Visible
INTERFACE: QEQ0683445
PARAMSETS: MASTER
RF_ADDRESS: 2940399
ROAMING: 0
RX_MODE: LAZY_CONFIG,BURST
UPDATABLE: 0
Channel LTK0043889:0 HM-PB-2-WM55-2 LTK0043889:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: LTK0043889
PARENT_TYPE: HM-PB-2-WM55-2
Channel LTK0043889:1 HM-PB-2-WM55-2 LTK0043889:1 [KEY] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
GROUP: LTK0043889:2
LINK_SOURCE_ROLES: KEYMATIC,REMOTECONTROL_RECEIVER,SWITCH,WINMATIC
PARAMSETS: LINK,MASTER,VALUES
PARENT: LTK0043889
PARENT_TYPE: HM-PB-2-WM55-2
Channel LTK0043889:2 HM-PB-2-WM55-2 LTK0043889:2 [KEY] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
GROUP: LTK0043889:1
LINK_SOURCE_ROLES: KEYMATIC,REMOTECONTROL_RECEIVER,SWITCH,WINMATIC
PARAMSETS: LINK,MASTER,VALUES
PARENT: LTK0043889
PARENT_TYPE: HM-PB-2-WM55-2
Defaults
Support for role KEY of device type HM-PB-2-WM55-2 is built in.
HF-Modul RPI-RF-MOD:
DEV RPI-RF-MOD 001F5A4993D5B5 001F5A4993D5B5 interface=HmIP-RF type=RPI-RF-MOD
CHN 001F5A4993D5B5:0 RPI-RF-MOD 001F5A4993D5B5:0
0.CARRIER_SENSE_LEVEL = 0.000000 {f} [RE]
0.DUTY_CYCLE_LEVEL = 1.000000 {f} [RE]
0.INCLUSION_UNSUPPORTED_DEVICE = {s} [RE]
Device detection:
No state datapoint detected
No control datapoint detected
Failed to detect device settings. Device must be configured manually.
Current state datapoint = .
Current control datapoint = .
Device description
Device 001F5A4993D5B5 RPI-RF-MOD 001F5A4993D5B5 [RPI-RF-MOD]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 001F5A4993D5B5:0
DIRECTION: NONE
FIRMWARE: 4.2.14
FLAGS: Visible,DontDelete
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 12114978
ROAMING: 0
RX_MODE:
SUBTYPE: CCU
UPDATABLE: 1
Channel 001F5A4993D5B5:0 RPI-RF-MOD 001F5A4993D5B5:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 001F5A4993D5B5
PARENT_TYPE: RPI-RF-MOD
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Defaults
Hier wird es wohl nichts verwertbares geben ?!
Danke und
Schönes Wochenende
Gerd
@Maista:
Wetterstation sollte nach dem nächsten Update automatisch erkannt werden.
Warum der HM-PB-2-WM55-2 nicht funktioniert, ist mir ein Rätsel. Laut der Ausgabe von get deviceinfo erkennt HMCCU das Gerät bzw. die Rolle "KEY". Der Befehl "get createDev" müsste eigentlich 2 HMCCUCHN Devices (je 1 für die beiden Schaltkanäle) anlegen.
Gibt es im fhem log Fehlermeldungen, wenn Du get createDev für dieses Gerät ausführst?
Hallo zap,
Teil1.
die Versuche mit dem Update und erzeugen mache ich gleich.
Mir ist jetzt aber aufgefallen das sich mein LOG füllt!
Zitat2021.07.05 20:47:37 4: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server CB2001178049178040 accepting connections
2021.07.05 20:47:37 4: HMCCURPCPROC [d_rpc178040HmIP_RF] RPC server CB2010178049178040 accepting connections
2021.07.05 20:47:38 4: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server CB2001178049178040 accepting connections
2021.07.05 20:47:38 4: HMCCURPCPROC [d_rpc178040HmIP_RF] RPC server CB2010178049178040 accepting connections
2021.07.05 20:47:39 4: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server CB2001178049178040 accepting connections
2021.07.05 20:47:39 4: HMCCURPCPROC [d_rpc178040HmIP_RF] RPC server CB2010178049178040 accepting connections
2021.07.05 20:47:40 4: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server CB2001178049178040 accepting connections
2021.07.05 20:47:40 4: HMCCURPCPROC [d_rpc178040HmIP_RF] RPC server CB2010178049178040 accepting connections
2021.07.05 20:47:41 4: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server CB2001178049178040 accepting connections
2021.07.05 20:47:41 4: HMCCURPCPROC [d_rpc178040HmIP_RF] RPC server CB2010178049178040 accepting connections
2021.07.05 20:47:42 4: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server CB2001178049178040 accepting connections
2021.07.05 20:47:42 4: HMCCURPCPROC [d_rpc178040HmIP_RF] RPC server CB2010178049178040 accepting connections
2021.07.05 20:47:43 4: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server CB2001178049178040 accepting connections
2021.07.05 20:47:43 4: HMCCURPCPROC [d_rpc178040HmIP_RF] RPC server CB2010178049178040 accepting connections
2021.07.05 20:47:44 4: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server CB2001178049178040 accepting connections
2021.07.05 20:47:44 4: HMCCURPCPROC [d_rpc178040HmIP_RF] RPC server CB2010178049178040 accepting connections
2021.07.05 20:47:45 4: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server CB2001178049178040 accepting connections
2021.07.05 20:47:45 4: HMCCURPCPROC [d_rpc178040HmIP_RF] RPC server CB2010178049178040 accepting connections
2021.07.05 20:47:46 4: HMCCURPCPROC [d_rpc178040BidCos_RF] RPC server CB2001178049178040 accepting connections
2021.07.05 20:47:46 4: HMCCURPCPROC [d_rpc178040HmIP_RF] RPC server CB2010178049178040 accepting connections
Ich habe aber jetzt schon bei HMCCU und beiden HMCCURPCPROC Devices das Verbose auf 0 gesetzt. Das wird aber weiter erzeugt.
Ist das noch ein Rest Log den Du vergessen hast zu deaktivieren?
Gruss Gerd
Bei verbose=4 ist das normal. Du musst die RPC Server stoppen und wieder starten. Das sind separate Prozesse. Die "erben" die Einstellungen vom FHEM Hauptprozess beim Start. Eine spätere Änderung von Attributen wird erst beim erneuten Start der RPC Server aktiv.
Für die HMCCURPCPROC Devices ist verbose = 2 vollkommen ausreichend.
Ok...
das Update liegt auf dem SVN?
Im Kopf des Moduls wurde das Datum aber nicht geändert.
Kann das sein?
Mit update all https://svn.fhem.de/trac/browser/trunk/fhem/contrib/HMCCU/controls_HMCCU.txt wird nichts geladen :o
Zitat von: zap am 05 Juli 2021, 20:58:05
Bei verbose=4 ist das normal. Du musst die RPC Server stoppen und wieder starten. Das sind separate Prozesse. Die "erben" die Einstellungen vom FHEM Hauptprozess beim Start. Eine spätere Änderung von Attributen wird erst beim erneuten Start der RPC Server aktiv.
Für die HMCCURPCPROC Devices ist verbose = 2 vollkommen ausreichend.
Okay, hat geklappt. Das Log war zwischenzeitlich 39MB gross ;)
Jetzt versuch ich mich am Update.
Das 88_HMCCUDEV.pm von heute habe ich runter geladen und spiele das jetzt ein.
Kam ja nix per Update.
Dann schaue ich ob er die Wetterstation erzeugt und was für eine Meldung beim erstellen des Taster kommt.
Mit der alten Version (wie gestern installiert) kommt folgendes beim Anlegen des Tasters:
Zitat2021.07.05 21:11:29 2: HMCCU [d_ccu] Define command failed HM_PB_2_WM55_2 LTK0043889_2 HMCCUCHN LTK0043889:2. Unknown module LTK0043889_2
2021.07.05 21:11:29 2: HMCCU [d_ccu] Define command failed HM_PB_2_WM55_2 LTK0043889_1 HMCCUCHN LTK0043889:1. Unknown module LTK0043889_1
HMCCU auf Verbose 5 , die zwei PROC auf Verbose 2.
@zap,
wo steht die Aktualisierte Version?
Die Daten auf dem SVN sind gleich. Da hat sich nichts geändert?!
Hab die Dateien aus "trunk/fhem/contrib/HMCCU/FHEM@24703"
2021.07.05 21:23:34 1 : Downloading https://svn.fhem.de/trac/browser/trunk/fhem/contrib/HMCCU/controls_HMCCU.txt
2021.07.05 21:23:48 1 : backup tar: Entferne führende ,,/" von Elementnamen tar: Entferne führende ,,/" von Zielen harter Verknüpfungen
2021.07.05 21:23:48 1 : backup done: FHEM-20210705_212334.tar.gz (37018101 Bytes)
2021.07.05 21:23:48 1 : nothing to do...
Im GIT steht auch nichts neues.
@zap
HMCCU-Version ist immer noch die 4.4.069.
Nur der Taster "HM_PB_2_WM55_2" erzeugt ein Logeintrag.
2021.07.05 21:44:42 2: HMCCU [d_ccu] Define command failed HM_PB_2_WM55_2 LTK0043889_1 HMCCUCHN LTK0043889:1. Unknown module LTK0043889_1
2021.07.05 21:44:42 2: HMCCU [d_ccu] Define command failed HM_PB_2_WM55_2 LTK0043889_2 HMCCUCHN LTK0043889:2. Unknown module LTK0043889_2
Die "HmIP-SWO-PR" erzeugt kein Logeintrag ?!
Bin dann morgen Abend erst wieder am PC.
Zap schrieb, dass es mit dem nächsten Update komme, du musst dich halt gedulden und auf das nächste Update warten. Wenn du nicht warten willst, zieh dir den aktuellen Stand doch einfach aus github und dann nicht aus dem Master branch sondern dem rc7 branch.
update all https://raw.githubusercontent.com/zapccu/HMCCU/RC7/controls_HMCCU.txt
Eher nicht. RC7 hat einen üblen Bug.
Zitat von: Maista am 05 Juli 2021, 21:46:53
@zap
HMCCU-Version ist immer noch die 4.4.069.
Nur der Taster "HM_PB_2_WM55_2" erzeugt ein Logeintrag.
2021.07.05 21:44:42 2: HMCCU [d_ccu] Define command failed HM_PB_2_WM55_2 LTK0043889_1 HMCCUCHN LTK0043889:1. Unknown module LTK0043889_1
2021.07.05 21:44:42 2: HMCCU [d_ccu] Define command failed HM_PB_2_WM55_2 LTK0043889_2 HMCCUCHN LTK0043889:2. Unknown module LTK0043889_2
Du hast noch einen Bug gefunden. Problem ist das Leerzeichen im Kanalnamen.
Zitat von: Jamo am 04 März 2021, 07:40:00
Ja, Du kannst aber "attr global exclude_from_update 88_HMCCURPCPROC.pm 88_HMCCUCHN.pm 88_HMCCUDEV.pm 88_HMCCU.pm 88_HMCCURPC.pm HMCCUConf.pm " setzen, damit verhinderst Du das Du wieder auf die alte 4.3 version wechselst. Damit sind die module vom update ausgenommen.
Sobald zap ein update von 4.4 macht, musst Du das attribut dann aber wieder loeschen, damit Du die neueren Dateien lädts.
Hallo Leute! Genau das hatte ich seit Langer Zeit drin bis heute... Habe es raus gelöscht weil ich irgendwo gelesen habe das es ein Update auf 4.4 schon gibt... Naja, irgendwie nicht so wirklich... Weil seit dem Update das ich heute gemacht habe steht wieder die Version 4.3 bei mir drin und alle meine Devices sind false...
hilfeeeeee :'( habe echt ne menge Devices konfiguriert gehabt.. Wie bekomme ich das wieder hin?
Die Installation der 4.4 aus dem ersten Post funktioniert irgendwie nicht...
Wenn ich
update all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt durchführen, sagt fhem nothing to Do und bleibt bei 4.3...
Und das schlimmste ist das nun Nix mehr funktioniert bei mir! HIIILFEEE! :'(
Danke!
Hat niemand eine Idee woran es liegen kann warum ich die 4.4 Beta nicht mehr installiert bekomme? Oder wie ich die aktuellste installieren muss...
Mit der 4.3er kann ich nicht Arbeiten weil alle Devices sen Status false bekommen haben und ich sie mit Fhem nicht ansprechen kann...
Hoffe jemand kann helfen.. .
Habe es nun selbst herausgefunden.. Oh mann... Hab mich selbst ausgetrickst...
Nachdem ich die Attribute rausgelöscht hatte und 4.3 installiert habe habe ich ja einen Neustart gemacht.. Da ich aber nach dem Löschen der Attribute nicht gespeichert habe waren diese wieder drin... Deshalb konnte ich nicht wieder updaten oder installieren...
Ajajajaj... Hat n bisschen gedauert bis ich auf die Idee gekommen bin da mal zu schauen..
Naja... Nun geht wieder alles und ich habe die 4.4.069
Puh... Nochmal gut gegangen..
Hast du das global exclude herausgenommen während des manuellen Updates auf 4.4?
Sonst geht das nicht, denke ich.
VG Helmut
Kurzer Hinweis zu IO::File: Ist seit Perl 5.07 ein Kernmodul und muss nicht extra installiert werden (so wie es in der CRef steht).
Aber mal davon abgesehen... Stand nicht schon irgendwo das es keine Beta mehr ist und eigentlich 5.0 heissen sollte.. War da nicht irgendwas?
Zitat von: misux am 12 Juli 2021, 16:44:58
Aber mal davon abgesehen... Stand nicht schon irgendwo das es keine Beta mehr ist und eigentlich 5.0 heissen sollte.. War da nicht irgendwas?
Nein, sondern:
Zitat von: zap am 07 Juni 2021, 19:24:49
Ich werde diese Woche noch einmal die Migration meiner alten 4.3er Konfiguration (ca. 80 Homematic Devices) auf die Version 4.4 testen. Wenn das gut funktioniert, geht die 4.4 nächstes Wochenende live.
Beta war jetzt lange genug. Die 4.4 ist praktisch eine Neuentwicklung, vielleicht nenne ich sie dann 5.0 ;)
und zap schrieb die Tage, dass er aktuell noch einen fiesen Bug gefunden hat.
Ich habe heute einen zusätzlichen HmIP-SWSD angelegt, per "get d_ccu createDev xyz".
Das neu angelegte Device hat aber keinen state.
Im DeviceInfo steht:
Device detection:
StateDatapoint = 1.SMOKE_DETECTOR_ALARM_STATUS [SMOKE_DETECTOR]
ControlDatapoint = 1.SMOKE_DETECTOR_COMMAND [SMOKE_DETECTOR]
Recommended module for device definition: HMCCUCHN
Current control datapoint = 1.SMOKE_DETECTOR_COMMAND
Allerdings steht der StateDatapoint nicht zu wollen. Ich habe ihn manuell so wie oben vorgeschlagen gesetzt, danach war auch state da.
Ich dachte, wenn ich über createDev gehe, werden die Empfehlungen automatisch vorausgewählt bzw. intern berücksichtigt.
@kjmEjfu: Mit der Version aus dem RC7 Branch funktioniert es. Die würde ich im Moment aber noch nicht empfehlen. Jedenfalls ist dieser Bug behoben.
Zitat von: Christoph Morrison am 12 Juli 2021, 12:34:35
Kurzer Hinweis zu IO::File: Ist seit Perl 5.07 ein Kernmodul und muss nicht extra installiert werden (so wie es in der CRef steht).
Ich nehme es raus.
Zitat von: misux am 12 Juli 2021, 16:44:58
Aber mal davon abgesehen... Stand nicht schon irgendwo das es keine Beta mehr ist und eigentlich 5.0 heissen sollte.. War da nicht irgendwas?
Ich habe noch Fehler gefunden, die bei der Übernahme meiner recht umfangreichen 4.3 Konfiguration in 4.4 aufgetreten sind. Ich kämpfe immer noch mit dem Attribut statevals ;)
@zap
Moin,
heute mal wieder etwas Zeit für FHEM.
Ich richte gerade wieder die HmIP-SWO-PR mit HMCCU 4.4 ein.
Wenn ich zu ATTR stateFormat gehe, wird mir die Hilfe angezeigt.
Klicke ich auf den markierten Link zu "set magic" wird auf die Seite "http://rpi00.fritz.box:8083/fhem?detail=Wetterstation&fw_id=#set" verwiesen aber nichts neues aufgerufen.
Ist das die Aufgabe von HMCCU oder FHEM?
Gruss Gerd
n' Abend,
bin seit vorgestern in der HMIP Welt (Wechselaktion von Max ausgenutzt) und bin ehrlich gesagt, schwer verwundert... Da die !MAX Anbindung richtig cool und einfach seitens der Geräte her war, ist das doch eine Wissenschaft. Die 4.4 hat mir zumindest einige Steine aus dem Weg geräumt. Allerdings reagiert mein FHEM manchmal ein wenig verschnupft - offenbar hatte ich schon 2 "unbemerkte" Reboots während der Konfig der HMIP Geräte.
Langer Rede - kurzer Sinn - der 6-fach Taster hmip-wrc6 hat mich jetzt einige Stunden gekostet, bis das Teil endlich im FHEM ansprech- und auswertbar wurde.
Für alle Anfänger und sonstigen Verzweifelten hier das kurze how-to:
-
- Schalter wie gewohnt in der CCU anlernen und benennen
- dann in der HMCCU den Schalter mittels HMCCUCHN als "einzelne" Devices (6 Kanäle) anlegen (lassen).
- in der CCU ein "Leerprogramm" pro Tastendruck schreiben (eines für kurzen/langen reicht) - das Programm muss nichts tun, ausser "Gerät" - Tastenendruck kurz/lang - keine weitern Aktionen - siehe Anhang.
- Danach ein paar Attribute im HMCCUCHN Device setzen:
Attributes:
ccuflags showDeviceReadings
controldatapoint .
event-on-update-reading PRESS.
- Zum guten Schluß noch die gewünschte Taste einmal lang und einmal kurz drücken - und Voila! - in den Readings taucht auf einmal:
PRESS_LONG
pressed
2021-07-19 23:20:48
PRESS_SHORT
pressed
2021-07-19 23:20:48 auf - und auch der state und hmstate passen auf einmal.
Stunden um Stunden...
Vielleicht hilft es ja jemanden - oder jemand kennt einen schnelleren Weg..
lg aus Wien,
Shamal2008
Zitat von: Maista am 17 Juli 2021, 14:50:23
@zap
Moin,
heute mal wieder etwas Zeit für FHEM.
Ich richte gerade wieder die HmIP-SWO-PR mit HMCCU 4.4 ein.
Wenn ich zu ATTR stateFormat gehe, wird mir die Hilfe angezeigt.
Klicke ich auf den markierten Link zu "set magic" wird auf die Seite "http://rpi00.fritz.box:8083/fhem?detail=Wetterstation&fw_id=#set" verwiesen aber nichts neues aufgerufen.
Ist das die Aufgabe von HMCCU oder FHEM?
Gruss Gerd
FHEM. Das ist ein Standardattribut von FHEM.
@shamal2008: In der 4.4 steckt aktuell noch ein Fehler, der die automatische Definition von mehreren HMCCUCHN Devices bei einem Mehrfachschalter verhindert. Ohne diesen Fehler würde ein "get createDev" eben diese 6 Devices anlegen. Weitere Attribute sind nicht erforderlich, um das Dummy Programm in der CCU kommst Du allerdings nicht herum. Ohne dieses Programm schickt die CCU keine Events an FHEM bei einem Tastendruck.
Hi zap,
wann glaubst du RC7 zu veröffentlichen? Wenn ich dich direkt verstanden habe, ist der üble Bug aber in dem RC7-branch bereits behoben, oder?
Beste Grüße,
Timmäää
Das ist der aktuelle Status / offene Probleme:
https://github.com/zapccu/HMCCU/milestones/RC7%204.4.070
Wobei einiges von der Liste schon umgesetzt ist, aber noch getestet werden muss.
Danke, das hatte ich mir nicht angesehen. Ich würde RC7 abwarten und dann meine Umgebung ausführlich testen.
Gerade festgestellt, dass bei der 4.4 der Befehl "set pct" (bei einem Dimmer) zwar funktioniert, eventuell angegebene Parameter on-time und ramp-time aber ignoriert werden. Als Workaround kann man "set datapoint" verwenden. Beispiel:
set xy datapoint ON_TIME=60 RAMP_TIME=10 LEVEL=50
Ich habe mal die 4.4 beta installiert, Da ich nur einen Sensor habe, war es einfach den zu loeschen, Aber ich bekomme beim get create folgende Fehlermeldung:
Results of create command:
Not supported by create command:
HmIP-RCV-50 HmIP-RCV-1 = HmIP-RCV-1 [HmIP-RCV-50 HmIP-RCV-1]
HM-RCV-50 BidCoS-RF = BidCoS-RF [HM-RCV-50 BidCoS-RF]
Failed to define devices:
HM_HmIP_SWDO_I 00109D898C2DF3 = 00109D898C2DF3:1 [HmIP-SWDO-I 00109D898C2DF3]
Ich hatte den HmIP_SWDO_I ueber FHEM einfach geloescht.
Muss noch etwas anderes gemacht werden ?
Was wird denn bei
get d_ccu ccuDevices
angezeigt?
Das ergebnis:
Name Model Interface Address Channels Supported roles
HM-RCV-50 BidCoS-RF HM-RCV-50 BidCos-RF BidCoS-RF 51 VIRTUAL_KEY [50x]
HmIP-SWDO-I 00109D898C2DF3 HmIP-SWDO-I HmIP-RF 00109D898C2DF3 3 SHUTTER_CONTACT [1x]
HmIP-RCV-50 HmIP-RCV-1 HmIP-RCV-50 HmIP-RF HmIP-RCV-1 51 KEY_TRANSCEIVER [50x]
Es tut sich was bei github, milestone RC7 erreicht, aber noch nicht im Master branch.
Ich hatte gestern keine Lust mehr, das zu mergen
Version RC7 ist nun auf Github verfügbar. Morgen stelle ich die neue Version auch im SVN bereit.
Installation wie immer mit:
update all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
Änderungen/Neuerungen kann man hier nachlesen:
https://github.com/zapccu/HMCCU/issues?q=is%3Aclosed+milestone%3A%22RC7+4.4.070%22
Es wurden vor allem Fehler behoben.
Es werden nun folgende Geräte automatisch erkannt
- HmIP-DLD - Türschloss
- HmIP-SWO-PR - Wetterstation
- HmIP-Wired Mehrfachaktoren
Da ich keines der o.g. Geräte selbst besitze, wäre es schön, wenn das jemand testen könnte.
Bei der Migration von HMCCU 4.3 ist es grundsätzlich nicht verkehrt, für jedes HMCCUDEV und HMCCUCHN Device einmal den Befehl
set
devName defaults reset
auszuführen. Dabei ist zu beachten, dass HMCCU folgende Attribute löscht, sofern das Gerät erkannt wurde:
eventMap, statedatapoint, controldatapoint, statevals, substitute, substexcl, ccureadingname, ccuscaleval, cmdIcon, webCmd, widgetOverride
Die Attribute sind nicht mehr erforderlich, sofern HMCCU einen Gerätetyp erkennt.
Hallo zap,
Danke schön.
Vielleicht komme ich am Wochenende dazu.
Gruß Gerd
Läuft bei mir seit gestern problemlos.
Viele Grüße
Jürgen
Die 4.4.070 läuft bei mir auch seit vorgestern problemlos.
Viele Grüße und Danke!
Bin auch gerade auf den RC7 umgestiegen. Beim defaults reset gab es einige Fehlermeldungen:
2021.08.14 11:16:36 2: HMCCUDEV [HmIP_SPDR_000C5709AE67D0] Device type HmIP-SPDR not known by HMCCU
2021.08.14 11:16:36 2: HMCCUDEV [HmIP_SPDR_000C5709AE67D0] Cannot detect role of HmIP_SPDR_000C5709AE67D0
2021.08.14 11:16:36 1: HMCCUDEV [HmIP_SPDR_000C5709AE67D0] HMCCUDEV: HmIP_SPDR_000C5709AE67D0 No default attributes found
2021.08.14 11:17:27 3: netatmo_Wetter: poll (ACCOUNT)
2021.08.14 11:17:44 2: HMCCU [CCU3] Can't get device description for CUX2803001 HMCCU_DetectDevice:6531 HMCCU_SetDefaultAttributes:434 HMCCUDEV_Set:3889 CallFn:1938 DoSet:1970 CommandSet:1265 AnalyzeCommand:2777 FW_fC:1006 FW_answerCall:598 FW_Read:3894 CallFn:773
2021.08.14 11:17:44 2: HMCCUDEV [HM_Sen_EP_CUX2803001] Device type CUX-HM-Sen-EP not known by HMCCU
2021.08.14 11:17:44 2: HMCCUDEV [HM_Sen_EP_CUX2803001] Cannot detect role of HM_Sen_EP_CUX2803001
2021.08.14 11:17:44 1: HMCCUDEV [HM_Sen_EP_CUX2803001] HMCCUDEV: HM_Sen_EP_CUX2803001 No default attributes found
2021.08.14 11:18:42 2: HMCCUDEV [HmIP_FCI1_001] Device type HmIP-FCI1 not known by HMCCU
2021.08.14 11:18:42 2: HMCCUDEV [HmIP_FCI1_001] Cannot detect role of HmIP_FCI1_001
2021.08.14 11:18:42 1: HMCCUDEV [HmIP_FCI1_001] HMCCUDEV: HmIP_FCI1_001 No default attributes found
2021.08.14 11:18:58 3: HMCCU [CCU3] Can't get definition of datapoint 00151BE99E21B8:6.ON_TIME. Ignoring command on-for-timer for device HmIP_MP3P_00151BE99E21B8
2021.08.14 11:18:58 3: HMCCU [CCU3] Can't get definition of datapoint 00151BE99E21B8:6.ON_TIME. Ignoring command on-till for device HmIP_MP3P_00151BE99E21B8
2021.08.14 11:18:58 3: HMCCU [CCU3] Can't get definition of datapoint 00151BE99E21B8:6.ON_TIME. Ignoring command pct for device HmIP_MP3P_00151BE99E21B8
2021.08.14 11:18:58 3: HMCCU [CCU3] Can't get definition of datapoint 00151BE99E21B8:6.ON_TIME. Ignoring command on-for-timer for device HmIP_MP3P_00151BE99E21B8
2021.08.14 11:18:58 3: HMCCU [CCU3] Can't get definition of datapoint 00151BE99E21B8:6.ON_TIME. Ignoring command on-till for device HmIP_MP3P_00151BE99E21B8
2021.08.14 11:18:58 3: HMCCU [CCU3] Can't get definition of datapoint 00151BE99E21B8:6.ON_TIME. Ignoring command pct for device HmIP_MP3P_00151BE99E21B8
2021.08.14 11:20:05 2: HMCCUDEV [HmIP_RCV_50_001F58A992FA6C] Device type RPI-RF-MOD not known by HMCCU
2021.08.14 11:20:05 2: HMCCUDEV [HmIP_RCV_50_001F58A992FA6C] Cannot detect role of HmIP_RCV_50_001F58A992FA6C
2021.08.14 11:20:05 1: HMCCUDEV [HmIP_RCV_50_001F58A992FA6C] HMCCUDEV: HmIP_RCV_50_001F58A992FA6C No default attributes found
2021.08.14 11:20:37 2: HMCCUDEV [HmIP_RCV_50_HmIP_RCV_1] Cannot detect role of HmIP_RCV_50_HmIP_RCV_1
2021.08.14 11:20:37 1: HMCCUDEV [HmIP_RCV_50_HmIP_RCV_1] HMCCUDEV: HmIP_RCV_50_HmIP_RCV_1 No default attributes found
2021.08.14 11:20:52 2: HMCCUDEV [HmIP_SCI_001E1BE9941986] Cannot detect role of HmIP_SCI_001E1BE9941986
2021.08.14 11:20:52 1: HMCCUDEV [HmIP_SCI_001E1BE9941986] HMCCUDEV: HmIP_SCI_001E1BE9941986 No default attributes found
room wird mit Homematic überschrieben, sonst keine weiteren Auffälligkeiten.
Gruß
Arthur
wieder zurück auf 4.3. Wenn das Licht im Bad nicht funktioniert leidet nicht nur der WAF. >:(
HmIP_SPDR und liefern plötzlich andere oder keine Readings Werte. z.B. ist aus presence = presence oder nopresence yes und no geworden, 2.CURRENT_PASSAGE_DIRECTION und 3.CURRENT_PASSAGE_DIRECTION erzeugen keine events mehr. Liegt aber vermutlich nicht an HMCCU sondern am aktuellem RaspberryMatic release 3.59.6.20210807. Kann das jemand bestätigen?
Gruß
Arthur
HmIP-MP3P ist ein sehr interessantes Gerät. Das hat zwar die Rollen DIMMER_TRANSMITTER und DIMMER_VIRTUAL_RECEIVER, allerdings unterscheiden sich die Datenpunkte komplett von dem, was EQ3 bisher für diese Rollen verwendet hat. Mal sehen, wie ich das abgebildet bekomme.
Jedenfalls kommen daher die Fehler mit dem ON_TIME.
Der HmIP-SCI müsste eigentlich funktionieren ...
Zitat von: zap am 15 August 2021, 12:41:59
Der HmIP-SCI müsste eigentlich funktionieren ...
Ja, der funktioniert, hat aber keine defaults. Ebenso der HmIP_FCI1, der HmIP-MP3P und der HmIP-SPDR. Die ersten 3 sollen meine bisherige Haustürklingellösung mit IT ersetzen. Fhem soll das ganze dann weiterhin steuern. Ich will mich nämlich nicht auch noch mit der Programmierung der CCU3 beschäftigen ;)
Gruß
Arthur
Hi Zap,
der RC7 funktioniert bei mir wunderbar.
Beim Resetten meiner Devices ist mir aufgefallen, dass die beiden Devices noch nicht komplett hinterlegt sind.
HmIP-SWD Wassersensor >>"HMCCUDEV: HmIP_SWD_Keller_Wassersensor No default attributes found"
HmIP-SAM Neigungssensor >> kein reset aber auch keine Fehlermeldung
Wie kann ich Dir helfen, die Geräte einzubinden ?
Gruß
Christoph
Hallo zusammen,
Ich habe den Umstieg gewagt, und es hat auch alles funktioniert. Ich habe aus jeder Menge HMCCUDEV jetzt HMCCUCHN gemacht. Dabei ist mir eine "Inkonsistenz" aufgefallen.
kurzer Ausflug in meinen Use-Case:
Ich nutze Heizkörper-Thermostate als dumme Stellglieder, indem ich sie voll-aufdrehe, und den Öfflungsgrad über die config "VALVE_MAXIMUM_POSITION" regle.
Um hier den aktuellen Stand im Reading zu haben, muss ich nach einem
set MyDevice config VALVE_MAXIMUM_POSITION=0.33:DOUBLE
ein
get MyDevice config VALVE_MAXIMUM_POSITION
ausführen, und hier steckt der Teufel:
Das HMCCUDEV hat beim get config noch einen Filter, ("get <name> config [<filter-expr>]" das HMCCUCHN kennt diese Option ("get <name> config") nicht.
das führt dazu, dass immer alle (!) configs abgeholt werden und bei einem programmatischen Aufruf (notify) im logfile landen. Was das mit den RF credits macht, weis ich nicht.
Frage: kann man an der Stelle die Funktionalität angleichen?
Dek
PS: Ich nutze die Version aus dem git repository
@Dek: In beiden Fällen (bei HMCCUDEV und bei HMCCUCHN) wird jeweils das komplette Paramterset gelesen (also alle Parameter eines Kanals). Das ist lediglich ein Befehl in Richtung CCU und Gerät. Man spart also nichts beim Duty Cycle, wenn man nur einen Parameter abfragt (was möglich wäre).
Aber ich verstehe den Hintergrund und werde das bei HMCCUCHN entsprechend abpassen.
Zitat von: cjung am 15 August 2021, 14:51:08
Hi Zap,
der RC7 funktioniert bei mir wunderbar.
Beim Resetten meiner Devices ist mir aufgefallen, dass die beiden Devices noch nicht komplett hinterlegt sind.
HmIP-SWD Wassersensor >>"HMCCUDEV: HmIP_SWD_Keller_Wassersensor No default attributes found"
HmIP-SAM Neigungssensor >> kein reset aber auch keine Fehlermeldung
Wie kann ich Dir helfen, die Geräte einzubinden ?
Gruß
Christoph
Die Typbezeichnungen genügen mir. Aber: HmIP-SWD ist ein "SensorWindowDoor" = SWD, also kein Wassersensor (?)
Zitat von: zap am 16 August 2021, 13:55:01
Die Typbezeichnungen genügen mir. Aber: HmIP-SWD ist ein "SensorWindowDoor" = SWD, also kein Wassersensor (?)
Wassersensor: https://de.elv.com/homematic-ip-wassersensor-hmip-swd-ip44-151694 :-)
Zitat von: kjmEjfu am 16 August 2021, 13:59:57
Wassersensor: https://de.elv.com/homematic-ip-wassersensor-hmip-swd-ip44-151694 :-)
Und wieder einmal ist es Zeit, Danke zu sagen. Danke EQ-3 für verwirrende / falsche / geänderte oder auch nicht geänderte Gerätebezeichnungen.
In der Homematic IP Device Doku steht der Wasser-Sensor als "HmIP-SW" drin. Man beachte das nicht vorhandene "D" ;)
Im ELV-Webshop sind entsprechend die Fenstersensoren als "SWDO" (Optisch) und "SWDM" (Magnetisch) aufgeführt.
Da hat wohl jemand vergessen, die Device Doku zu aktualisieren.
Zitat von: zap am 16 August 2021, 13:13:37
@Dek: In beiden Fällen (bei HMCCUDEV und bei HMCCUCHN) wird jeweils das komplette Paramterset gelesen (also alle Parameter eines Kanals). Das ist lediglich ein Befehl in Richtung CCU und Gerät. Man spart also nichts beim Duty Cycle, wenn man nur einen Parameter abfragt (was möglich wäre).
Habe ich das richtig verstanden: eine Einzel-Wert Abfrage wäre möglich, ist aber aktuell nicht implementiert? Auch wenn das den duty-cycle nix kostet, ist immerhin für die Antwort das shared-Medium Funk belegt. Ich kenne aber das Protokoll nicht/zu wenig, um hier mögliche Kollisionen zu erkennen. In der Heiz-Saison wird der Befehl im Schnitt (über alle Aktoren hinweg summiert) bei mir durchaus 1/Minute geschickt. Da kommt was zusammen.
Zitat von: zap am 16 August 2021, 13:13:37
Aber ich verstehe den Hintergrund und werde das bei HMCCUCHN entsprechend abpassen.
Das klingt gut. Dann auch die Ausgabe ins Log unterbinden, solange muss ich auf verbose 2 stellen.
Dek
Wobei ich gerade merke, dass ich gar nicht weiß, welches verbose ich runterdrehen müsste, da das ja eine umgeleitete GUI-Ausgabe ist....
Zitat von: Dek am 16 August 2021, 17:02:10
Wobei ich gerade merke, dass ich gar nicht weiß, welches verbose ich runterdrehen müsste, da das ja eine umgeleitete GUI-Ausgabe ist....
In der 4.4 dürfte auch bei HMCCUDEV "get config" keinen Filter erlauben. Das habe ich wohl "wegoptimiert". Kommt wieder ... oder vielleicht ein eigener get Befehl.
Zitat von: Dek am 16 August 2021, 17:02:10
Wobei ich gerade merke, dass ich gar nicht weiß, welches verbose ich runterdrehen müsste, da das ja eine umgeleitete GUI-Ausgabe ist....
Problem gelöst:
Ich hatte den Befehl in einem Perl-Block über
fhem("get MyDevice config VALVE_MAXIMUM_POSITION");
ausgeführt, habe dann aber inzwischen gelesen, dass der fhem() Befehl noch ein Argument (=1) kennt, um die Ausgabe zu unterdrücken:
fhem("get MyDevice config VALVE_MAXIMUM_POSITION",1);
Damit läuft alles wie gewünscht, es dauert (gefühlt) länger als mit der alten Lösung. Aber das ist nur eine Randnotiz ohne Relevanz
Dek
Hi,
Nachdem mein HMLAN langsam am sterben war, habe Ich auf ccu3 und auf die 4.4 Beta umgestellt.
Soweit funktioniert alles gut, folgendes aber aufgefallen:
- Schaltvorgang über FHEM und events dauert gefühlt 1 Sekunde, mit dem HMLAN war die Verzögerung deutlich kleiner, aber Ich nehme an es ist halt so.
- Wenn ccu3 rebootet wird, dann wird die Verbindung nicht automatisch wieder aufgebaut vom Modul. Im GUI steht verbunden/OK, aber es funktioniert nichts, erst nach "set off"/"set on" geht es.
lg
@Rosti: Setze mal im I/O Device im Attribut "ccuflags" das Flag "reconnect".
Nicht unterstützte HM-Geräte
Man kann mit HMCCU 4.4 natürlich auch Geräte steuern / nutzen, die von "get create" und "get createDev" nicht erkannt werden. Dazu geht man wie folgt vor:
- Man definiert für jeden Kanal des Gerätes, den man nutzen möchte, ein HMCCUCHN Device oder für das Gerät insgesamt ein HMCCUDEV Device
- Man legt mit dem Attribut statedatapoint den Datenpunkt fest, der in STATE erscheinen soll
- Wenn man Werte in den Readings ersetzen möchte (z.B. false oder 0 durch "closed"), verwendet man das Attribut substitute
Lässt sich das Gerät auch steuern, setzt man zusätzlich das Attribut controldatapoint auf den Datenpunkt, mit dem sich das Gerät steuern lässt (z.B. LEVEL bzw. x.LEVEL für HMCCUDEV).
Nun kann man noch zusätzlich mit dem Attribut statevals Befehle definieren, die sich auf den controldatapoint beziehen.
Ein Beispiel für einen BidCos-RF Dimmer, Status und Steuerung über Kanal 1 => HMCCUCHN:
define myDimmer HMCCUCHN abcdefgh:1
attr myDimmer statedatapoint LEVEL
attr myDimmer controldatapoint LEVEL
attr statevals on:100,off:0
Danach stehen die Befehle "set myDimmer on" und "set myDimmer off" zur Verfügung. Sie setzten den controldatapoint 1.LEVEL auf 100 oder 0.
Bei einem HmIP-Dimmer liegen statedatapoint und controldatapoint gerne in unterschiedlichen Kanälen => HMCCUDEV:
define myDimmer HMCCUDEV abcdefgh
attr myDimmer statedatapoint 3.LEVEL
attr myDimmer controldatapoint 4.LEVEL
attr statevals on:100,off:0
Grundsätzlich werden die Readings eines Gerätes auch dann ausgelesen und aktualisiert, wenn HMCCU die Geräte nicht "kennt".
Jedes steuerbare Gerät kann mit "set datapoint" gesteuert werden. Man muss natürlich Namen, Funktion und Werte der Datenpunkte kennen.
@zap
Moin,
heute endlich mal wieder Zeit gehabt....
Das anlegen der Wetterstation HmIP-SWO-PR hat soweit funktioniert!
Wurden die
"1." bei den Readings-Namen wegoptimiert?
Zitatget HM.OG.bk.WE.Sensor config
erzeugt im Event Monitor Fehlermeldungen.
2021.08.22 19:42:27 1 : HMCCURPCPROC [d_rpc178040HmIP_RF] Error in request getParamset 00185BE9A57631 SERVICE: Generic error (UNREACH)
2021.08.22 19:42:28 1 : HMCCURPCPROC [d_rpc178040HmIP_RF] Error in request getParamset 00185BE9A57631:0 SERVICE: Generic error (UNREACH)
2021.08.22 19:42:29 1 : HMCCURPCPROC [d_rpc178040HmIP_RF] Error in request getParamset 00185BE9A57631:1 SERVICE: Generic error (UNREACH)Ist das ok?
Im Fenster des Devices bekomme ich aber eine Ausgabe angezeigt:
Device 00185BE9A57631
Channel 0 [MASTER]
ARR_TIMEOUT = 10
CYCLIC_INFO_MSG = 1
CYCLIC_INFO_MSG_DIS = 0
CYCLIC_INFO_MSG_DIS_UNCHANGED = 0
CYCLIC_INFO_MSG_OVERDUE_THRESHOLD = 2
DUTYCYCLE_LIMIT = 180
ENABLE_ROUTING = false
LOCAL_RESET_DISABLED = false
LOW_BAT_LIMIT = 3.2
Zitatget HM.OG.bk.WE.Sensor datapoint svHmIPRainCounterToday_1609
zeigt das im Web an :
HMCCUCHN: HM.OG.bk.WE.Sensor Execution of CCU script or command failedund erzeugt im Event Monitor diese Fehlermeldung:
2021.08.22 19:45:39 1 : HMCCUCHN [HM.OG.bk.WE.Sensor] Error CMD = Write((datapoints.Get("HmIP-RF.00185BE9A57631:1.svHmIPRainCounterToday_1609")).Value())
2021.08.22 19:45:39 1 : HMCCUCHN [HM.OG.bk.WE.Sensor] HMCCUCHN: HM.OG.bk.WE.Sensor Execution of CCU script or command failedWann diese ".svHmIP"-Variablen automatisch aktualisiert werden habe ich noch nicht verstanden.
Danke und noch schönen Sonntag
Gerd
Die Kanalnummer im Reading gibt es nur bei HMCCUDEV. Ändern kann man die Darstellung mit dem Attribut "ccureadingformat".
Die Fehler "Error in request getParamset 00185BE9A57631 SERVICE: Generic error (UNREACH)" lässt sich leider nicht vermeiden. Ursache: Die CCU liefert für einige Geräte eine falsche Parameterbeschreibung. Diese Beschreibung gibt fälschlicherweise an, dass es ein Parameterset SERVICE gibt, das tatsächlich jedoch nicht existiert. Daher der Fehler. Also ignorieren.
Die verknüpften Systemvariablen sind ein Problem. Die CCU aktualisiert diese nicht automatisch. Wie verhält es sich bei "get values"? Werden die Readings dann aktualisiert.
ZitatDie Kanalnummer im Reading gibt es nur bei HMCCUDEV. Ändern kann man die Darstellung mit dem Attribut "ccureadingformat".
Ah, das war mir bisher nicht bewusst, komme immer nur sporadisch dazu etwas zu machen :=(
ZitatDie verknüpften Systemvariablen sind ein Problem. Die CCU aktualisiert diese nicht automatisch. Wie verhält es sich bei "get values"? Werden die Readings dann aktualisiert.
Das Funktioniert, gibt ein Fenster mit den Daten. Im Event-Monitor sehe ich auch keine Fehlermeldung.
Ich habe mal eine Frage zum HmIP-eTRV-2.
Das Reading LEVEL wird hier (Version 4.4.069) mit Werten von 0.0 bis 1.0 angezeigt.
Waren das nicht mal Werte von 0.0 bis 100 - also Prozentwerte, das macht einiges in der Darstellung einfacher:-)?
Gruß
eurofinder
@eurofinder: Bitte aktualisiere auf die 4.4.070. Da habe ich jede Menge Bugs behoben, auch was die automatische Skalierung von Werten anbelangt. Die Version gibt es nur auf Github. Heute oder morgen werde ich die 5.0 als Beta im SVN und auf Github bereitstellen.
@zap:
OK, danke. Bin bisher zeitlich noch nicht zum Aktualisieren gekommen:-)
Gruß
eurofinder
Also nach Aktualisierung auf 4.4.070 bleibt es bei Werten von 0.0 bis 1.0 in LEVEL.
Ich fände es praktischer hier den Prozentwert zu haben. Ich teste aber gerne in Kürze die 5.0.
Gruß
eurofinder
Kannst Du bitte ein "list" vom Thermostat-Device machen?
Na klar:-) hier mal ein Regler:
Internals:
DEF 000A1709B23BE3:1
FUUID 602bf6ad-f33f-49d8-2745-c08f85493f6bf825
IODev CCU3
NAME Regler_Bad
NR 38
STATE Raumtemperatur: 22.6 °C<br/>Soll: 23.0 °C<br/>Fenster: <b>closed</b>
TYPE HMCCUCHN
ccuaddr 000A1709B23BE3:1
ccudevstate active
ccuif HmIP-RF
ccuname Regler_Bad:1
ccurolectrl HEATING_CLIMATECONTROL_TRANSCEIVER
ccurolestate HEATING_CLIMATECONTROL_TRANSCEIVER
ccusubtype TRV
ccutype HmIP-eTRV-2
firmware 2.2.8
readonly no
receiver ccu:Sensor_Bad
sender ccu:Sensor_Bad,Fenster_OG_Bad,Sensor_Bad
OLDREADINGS:
READINGS:
2021-08-30 12:10:56 ACTIVE_PROFILE 1
2021-08-30 12:10:56 ACTUAL_TEMPERATURE 22.6
2021-08-30 12:10:56 ACTUAL_TEMPERATURE_STATUS NORMAL
2021-08-30 12:10:56 BOOST_MODE false
2021-08-30 12:10:56 BOOST_TIME 0
2021-08-30 12:10:56 FROST_PROTECTION false
2021-08-30 12:10:56 LEVEL 0.8
2021-08-30 12:10:56 LEVEL_STATUS NORMAL
2021-08-30 12:10:56 PARTY_MODE false
2021-08-30 12:10:56 QUICK_VETO_TIME 0
2021-08-30 12:10:56 SET_POINT_MODE auto
2021-08-30 12:10:56 SET_POINT_TEMPERATURE 23.0
2021-08-30 12:10:56 SWITCH_POINT_OCCURED false
2021-08-30 12:10:56 VALVE_STATE ADAPTION_DONE
2021-08-30 12:10:56 WINDOW_STATE closed
2021-08-30 12:10:56 activity alive
2021-08-30 12:10:56 battery ok
2021-08-30 12:10:56 control 23.0
2021-08-30 12:10:56 controlMode auto
2021-08-30 12:10:56 desired-temp 23.0
2021-08-30 12:10:56 devstate ok
2021-08-30 12:10:56 hmstate 22.6
2021-08-30 12:10:56 measured-temp 22.6
2021-08-30 12:10:56 rssidevice -72
2021-08-30 12:10:56 rssipeer -69
2021-08-30 12:10:56 state 22.6
hmccu:
channels 1
detect 1
devspec 000A1709B23BE3:1
nodefaults 1
role 1:HEATING_CLIMATECONTROL_TRANSCEIVER
semDefaults 0
cmdlist:
get
set holiday:noArg auto:noArg desired-temp manu:noArg boost:noArg off:noArg on:noArg toggle:noArg
control:
chn 1
dpt SET_POINT_TEMPERATURE
dp:
0.CONFIG_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.LOW_BAT:
VALUES:
NVAL 0
ONVAL 0
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.OPERATING_VOLTAGE:
VALUES:
NVAL 2.3
ONVAL 2.3
OSVAL 2.3
OVAL 2.3
SVAL 2.3
VAL 2.3
0.OPERATING_VOLTAGE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL -72
ONVAL -71
OSVAL -71
OVAL -71
SVAL -72
VAL -72
0.RSSI_PEER:
VALUES:
NVAL -69
ONVAL -69
OSVAL -69
OVAL -69
SVAL -69
VAL -69
0.UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL alive
OVAL 0
SVAL alive
VAL 0
1.ACTIVE_PROFILE:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.ACTUAL_TEMPERATURE:
VALUES:
NVAL 22.6
ONVAL 22.4
OSVAL 22.4
OVAL 22.4
SVAL 22.6
VAL 22.6
1.ACTUAL_TEMPERATURE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.BOOST_MODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.BOOST_TIME:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.FROST_PROTECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.LEVEL:
VALUES:
NVAL 0.78
ONVAL 0.88
OSVAL 0.9
OVAL 0.88
SVAL 0.8
VAL 0.78
1.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.PARTY_MODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.QUICK_VETO_TIME:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.SET_POINT_MODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL auto
OVAL 0
SVAL auto
VAL 0
1.SET_POINT_TEMPERATURE:
VALUES:
NVAL 23.0
ONVAL 21.5
OSVAL 21.5
OVAL 21.5
SVAL 23.0
VAL 23.0
1.SWITCH_POINT_OCCURED:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.VALVE_STATE:
VALUES:
NVAL 4
ONVAL 4
OSVAL ADAPTION_DONE
OVAL 4
SVAL ADAPTION_DONE
VAL 4
1.WINDOW_STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL closed
OVAL 0
SVAL closed
VAL 0
roleCmds:
get:
set:
auto:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:CONTROL_MODE:0
usage auto
subcmd:
000:
args 0
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
boost:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:BOOST_MODE:1
usage boost
subcmd:
000:
args 1
dpt BOOST_MODE
fnc
max 1
min 0
parname BOOST_MODE
partype 3
ps VALUES
scn 000
unit
desired-temp:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:SET_POINT_TEMPERATURE:?temperature
usage desired-temp temperature
subcmd:
000:
args
dpt SET_POINT_TEMPERATURE
fnc
max 30.5
min 4.5
parname temperature
partype 2
ps VALUES
scn 000
unit �C
holiday:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:CONTROL_MODE:2
usage holiday
subcmd:
000:
args 2
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
manu:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:CONTROL_MODE:1
usage manu
subcmd:
000:
args 1
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
off:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 2
syntax V:CONTROL_MODE:1 V:SET_POINT_TEMPERATURE:4.5
usage off
subcmd:
000:
args 1
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
001:
args 4.5
dpt SET_POINT_TEMPERATURE
fnc
max 30.5
min 4.5
parname SET_POINT_TEMPERATURE
partype 3
ps VALUES
scn 001
unit �C
on:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 2
syntax V:CONTROL_MODE:1 V:SET_POINT_TEMPERATURE:30.5
usage on
subcmd:
000:
args 1
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
001:
args 30.5
dpt SET_POINT_TEMPERATURE
fnc
max 30.5
min 4.5
parname SET_POINT_TEMPERATURE
partype 3
ps VALUES
scn 001
unit �C
state:
chn 1
dpt ACTUAL_TEMPERATURE
Attributes:
IODev CCU3
alias Bad
cmdIcon auto:sani_heating_automatic manu:sani_heating_manual boost:sani_heating_boost on:general_an off:general_aus
event-on-change-reading .*
group Regler
icon hc_wht_regler
room Homematic
stateFormat Raumtemperatur: ACTUAL_TEMPERATURE °C<br/>Soll: SET_POINT_TEMPERATURE °C<br/>Fenster: <b>WINDOW_STATE</b>
substexcl desired-temp
userReadings controlMode {if(ReadingsVal($name,"BOOST_MODE","") eq "true") {return "boost"}
elsif
(ReadingsVal($name,"SET_POINT_MODE","") eq "auto") {return "auto"}
elsif
(ReadingsVal($name,"SET_POINT_MODE","") eq "manual") {return "manual"} else {return "error"}}
webCmd desired-temp:auto:manu:boost:on:off
widgetOverride desired-temp:slider,4.5,0.5,30.5,1
Gruß
eurofinder
@zap:
Könntest du dir das bitte nochmal anschauen - HMCCU ist 4.4.070.
Im Log erhalte ich folgende Meldungen:
2021.08.31 10:30:34 2: HMCCUDEV [Anzeige_Buero] Cannot set default state- and/or control datapoints
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:8.ON_TIME. Ignoring command on-till for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:8.ON_TIME. Ignoring command pct for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:8.ON_TIME. Ignoring command on-for-timer for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:9.ON_TIME. Ignoring command on-till for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:9.ON_TIME. Ignoring command pct for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:9.ON_TIME. Ignoring command on-for-timer for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:10.ON_TIME. Ignoring command on-till for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:10.ON_TIME. Ignoring command pct for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:10.ON_TIME. Ignoring command on-for-timer for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:12.ON_TIME. Ignoring command on-till for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:12.ON_TIME. Ignoring command pct for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:12.ON_TIME. Ignoring command on-for-timer for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:13.ON_TIME. Ignoring command on-till for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:13.ON_TIME. Ignoring command pct for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:13.ON_TIME. Ignoring command on-for-timer for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:14.ON_TIME. Ignoring command on-till for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:14.ON_TIME. Ignoring command pct for device Anzeige_Buero
2021.08.31 10:30:34 3: HMCCU [CCU3] Can't get definition of datapoint 001A5A498DECB9:14.ON_TIME. Ignoring command on-for-timer for device Anzeige_Buero
2021.08.31 10:30:34 2: HMCCUDEV [Anzeige_Buero] Cannot detect role of Anzeige_Buero
2021.08.31 10:30:34 3: Attribute statevals ignored. Device type is known by HMCCU
Und hier das entsprechende Device:
Internals:
DEF 001A5A498DECB9
FUUID 602c3209-f33f-49d8-da31-97db54ea825a7db2
IODev CCU3
NAME Anzeige_Buero
NR 50
STATE off
TYPE HMCCUDEV
ccuaddr 001A5A498DECB9
ccudevstate active
ccuif HmIP-RF
ccuname Anzeige_Buero
ccurolestate SWITCH_VIRTUAL_RECEIVER
ccusubtype BSL
ccutype HmIP-BSL
firmware 1.0.2
readonly no
OLDREADINGS:
READINGS:
2021-08-31 10:30:34 10.ACTIVITY_STATE STABLE
2021-08-31 10:30:34 10.COLOR black
2021-08-31 10:30:34 10.COLOR_STATUS NORMAL
2021-08-31 10:30:34 10.LEVEL off
2021-08-31 10:30:34 10.LEVEL_STATUS NORMAL
2021-08-31 10:30:34 11.ACTIVITY_STATE UNKNOWN
2021-08-31 10:30:34 11.COLOR red
2021-08-31 10:30:34 11.COLOR_STATUS NORMAL
2021-08-31 10:30:34 11.LEVEL 100
2021-08-31 10:30:34 11.LEVEL_STATUS NORMAL
2021-08-31 10:30:34 12.ACTIVITY_STATE STABLE
2021-08-31 10:30:34 12.COLOR red
2021-08-31 10:30:34 12.COLOR_STATUS NORMAL
2021-08-31 10:30:34 12.LEVEL on
2021-08-31 10:30:34 12.LEVEL_STATUS NORMAL
2021-08-31 10:30:34 13.ACTIVITY_STATE STABLE
2021-08-31 10:30:34 13.COLOR black
2021-08-31 10:30:34 13.COLOR_STATUS NORMAL
2021-08-31 10:30:34 13.LEVEL off
2021-08-31 10:30:34 13.LEVEL_STATUS NORMAL
2021-08-31 10:30:34 14.ACTIVITY_STATE STABLE
2021-08-31 10:30:34 14.COLOR black
2021-08-31 10:30:34 14.COLOR_STATUS NORMAL
2021-08-31 10:30:34 14.LEVEL off
2021-08-31 10:30:34 14.LEVEL_STATUS NORMAL
2021-08-31 10:30:34 3.STATE off
2021-08-31 10:30:34 4.STATE off
2021-08-31 10:30:34 5.STATE off
2021-08-31 10:30:34 6.STATE off
2021-08-31 10:30:34 7.ACTIVITY_STATE UNKNOWN
2021-08-31 10:30:34 7.COLOR red
2021-08-31 10:30:34 7.COLOR_STATUS NORMAL
2021-08-31 10:30:34 7.LEVEL 0
2021-08-31 10:30:34 7.LEVEL_STATUS NORMAL
2021-08-31 10:30:34 8.ACTIVITY_STATE STABLE
2021-08-31 10:30:34 8.COLOR red
2021-08-31 10:30:34 8.COLOR_STATUS NORMAL
2021-08-31 10:30:34 8.LEVEL off
2021-08-31 10:30:34 8.LEVEL_STATUS NORMAL
2021-08-31 10:30:34 9.ACTIVITY_STATE STABLE
2021-08-31 10:30:34 9.COLOR black
2021-08-31 10:30:34 9.COLOR_STATUS NORMAL
2021-08-31 10:30:34 9.LEVEL off
2021-08-31 10:30:34 9.LEVEL_STATUS NORMAL
2021-08-31 10:30:34 activity alive
2021-08-31 10:30:34 control off
2021-08-31 10:30:34 devstate ok
2021-08-31 10:30:34 hmstate off
2021-08-31 10:30:34 rssidevice -54
2021-08-31 10:30:34 state off
hmccu:
channels 16
detect 2
devspec 001A5A498DECB9
forcedev 0
nodefaults 1
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:KEY_TRANSCEIVER,3:SWITCH_TRANSMITTER,4:SWITCH_VIRTUAL_RECEIVER,5:SWITCH_VIRTUAL_RECEIVER,6:SWITCH_VIRTUAL_RECEIVER,7:DIMMER_TRANSMITTER,8:DIMMER_VIRTUAL_RECEIVER,9:DIMMER_VIRTUAL_RECEIVER,10:DIMMER_VIRTUAL_RECEIVER,11:DIMMER_TRANSMITTER,12:DIMMER_VIRTUAL_RECEIVER,13:DIMMER_VIRTUAL_RECEIVER,14:DIMMER_VIRTUAL_RECEIVER,15:DIMMER_WEEK_PROFILE
semDefaults 0
cmdlist:
get
set on:noArg off:noArg on-for-timer on-till on:noArg off:noArg on-for-timer on-till on:noArg off:noArg on-for-timer on-till up down on:noArg off:noArg up down on:noArg off:noArg up down on:noArg off:noArg up down on:noArg off:noArg up down on:noArg off:noArg up down on:noArg off:noArg
control:
chn 4
dpt STATE
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
NVAL 28.0
ONVAL 28.0
OSVAL 28.0
OVAL 28.0
SVAL 28.0
VAL 28.0
0.CONFIG_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL -54
ONVAL -54
OSVAL -54
OVAL -54
SVAL -54
VAL -54
0.UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL alive
OVAL 0
SVAL alive
VAL 0
10.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
10.COLOR:
VALUES:
NVAL 0
ONVAL 0
OSVAL BLACK
OVAL 0
SVAL black
VAL 0
10.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
10.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
10.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
10.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
10.SECTION:
VALUES:
NVAL 4
ONVAL 4
OSVAL 4
OVAL 4
SVAL 4
VAL 4
10.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
11.ACTIVITY_STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL UNKNOWN
OVAL 0
SVAL UNKNOWN
VAL 0
11.COLOR:
VALUES:
NVAL 4
ONVAL 4
OSVAL RED
OVAL 4
SVAL red
VAL 4
11.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
11.LEVEL:
VALUES:
NVAL 100
ONVAL 1.0
OSVAL 1.0
OVAL 1.0
SVAL 100
VAL 1.0
11.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
11.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
11.SECTION_STATUS:
VALUES:
NVAL 1
ONVAL 1
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
12.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
12.COLOR:
VALUES:
NVAL 4
ONVAL 4
OSVAL RED
OVAL 4
SVAL red
VAL 4
12.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
12.LEVEL:
VALUES:
NVAL 100
ONVAL 100
OSVAL on
OVAL 1.0
SVAL on
VAL 1.0
12.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
12.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
12.SECTION:
VALUES:
NVAL 3
ONVAL 3
OSVAL 3
OVAL 3
SVAL 3
VAL 3
12.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
13.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
13.COLOR:
VALUES:
NVAL 0
ONVAL 0
OSVAL BLACK
OVAL 0
SVAL black
VAL 0
13.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
13.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
13.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
13.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
13.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
13.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
14.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
14.COLOR:
VALUES:
NVAL 0
ONVAL 0
OSVAL BLACK
OVAL 0
SVAL black
VAL 0
14.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
14.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
14.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
14.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
14.SECTION:
VALUES:
NVAL 4
ONVAL 4
OSVAL 4
OVAL 4
SVAL 4
VAL 4
14.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
15.WEEK_PROGRAM_CHANNEL_LOCKS:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
3.SECTION_STATUS:
VALUES:
NVAL 1
ONVAL 1
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
3.STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
4.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
4.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
5.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
5.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
5.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
6.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
6.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
6.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
7.ACTIVITY_STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL UNKNOWN
OVAL 0
SVAL UNKNOWN
VAL 0
7.COLOR:
VALUES:
NVAL 4
ONVAL 4
OSVAL RED
OVAL 4
SVAL red
VAL 4
7.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.LEVEL:
VALUES:
NVAL 0
ONVAL 0.0
OSVAL 0.0
OVAL 0.0
SVAL 0
VAL 0.0
7.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
7.SECTION_STATUS:
VALUES:
NVAL 1
ONVAL 1
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
8.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
8.COLOR:
VALUES:
NVAL 4
ONVAL 4
OSVAL RED
OVAL 4
SVAL red
VAL 4
8.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
8.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
8.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
8.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
8.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
8.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
9.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
9.COLOR:
VALUES:
NVAL 0
ONVAL 0
OSVAL BLACK
OVAL 0
SVAL black
VAL 0
9.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
9.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
9.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
9.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
9.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
9.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
roleCmds:
get:
set:
down:
channel ?
role DIMMER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=-10
usage down [delta]
subcmd:
000:
args -10
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
scn 000
unit 100%
off:
channel ?
role DIMMER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:0
usage off
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
on:
channel ?
role DIMMER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:100
usage on
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
on-for-timer:
channel ?
role DIMMER_VIRTUAL_RECEIVER
subcount 2
syntax V:ON_TIME:?duration V:LEVEL:100
usage on-for-timer duration
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname duration
partype 2
ps VALUES
scn 000
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 001
unit
on-till:
channel ?
role DIMMER_VIRTUAL_RECEIVER
subcount 2
syntax V:ON_TIME:?time V:LEVEL:100
usage on-till time
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname time
partype 2
ps VALUES
scn 000
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 001
unit
pct:
role DIMMER_VIRTUAL_RECEIVER
syntax 3:V:LEVEL:?level 1:V:ON_TIME:?time=0.0 2:V:RAMP_TIME:?ramp=0.5
subcmd:
000:
args
dpt LEVEL
fnc
max 1.01
min 0.0
parname level
partype 2
ps VALUES
scn 003
unit 100%
up:
channel ?
role DIMMER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=+10
usage up [delta]
subcmd:
000:
args +10
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
scn 000
unit 100%
state:
chn 4
dpt STATE
Attributes:
IODev CCU3
ccureadingfilter (LEVEL|STATE|COLOR|PRESS)
ccuscaleval LEVEL:0:1:0:100
event-on-change-reading .*
event-on-update-reading ^[1-2]\.PRESS.*
room Homematic
statedatapoint 4.STATE
substitute STATE!(0|false):off,(1|true):on;COLOR!0:black,1:blue,2:green,3:turquoise,4:red,5:purple,6:yellow,7:white
Danke und Gruß
eurofinder
Für den Regler bräuchte ich noch die Ausgabe von get paramsetDesc. Ich nehme an, die CCU liefert bei LEVEL nicht die korrekte Einheit.
Für den BSL: Hast Du das Device mit "get createDev" automatisch anlegen lassen?
Das Problem ist: Die Rolle DIMMER_VIRTUAL_RECEIVER hat normalerweise einen Datenpunkt ON_TIME. Der fehlt bei diesem Gerät jedoch. Daher kann HMCCU die Timer-Kommandos nicht bereitstellen, also z.B. set on-for-timer. Das ist jedoch nur eine Warning. Kannst Du ignorieren.
@zap:
Hier vom Device noch die Ausgabe von "get createDev":
Hinweis: Jetzt als Dateianhang
Gruß
eurofinder
@zap:
Irgendwie will das Forum die Ausgabe nicht mit der Code-Funktion akzeptieren, obwohl es im Preview korrekt aussah.
Daher hier noch der Rest meines Eintrages:
Ja, sollte automatisch angelegt worden sein.
Gruß
eurofinder
@eurofinder
Zur Not den Text als Datei anhängen.
Gruß Gerd
@zap:
Ich habe die Ausgabe jetzt als Dateianhang beigefügt - sihe etwas weiter oben.
Gruß
eurofinder
Zitat von: eurofinder am 01 September 2021, 07:59:16
@zap:
Ich habe die Ausgabe jetzt als Dateianhang beigefügt - sihe etwas weiter oben.
Gruß
eurofinder
Die Ausgabe in der Datei passt nicht zu Deinem Devicetype HmIP-TRV-2. Bitte folgenden Befehl ausführen:
get Regler_Bad paramsetDescIch glaube, Du hast den Output für das andere Device hochgeladen, das die Warnings im Log verursacht. Den Grund für die Meldungen habe ich schon beschrieben. Ggf. nehme ich die Meldungen raus oder erhöhe das Verbose Level (wobei das schon 3 ist).
@zap:
Upps, sorry. Ich habe die Datei oben berichtigt.
Gruß
eurofinder
Die Version 5.0 steht in Github zur Verfügung. Installation siehe erster Beitrag in diesem Thread.
Neben Bugfixes gibt es folgende neuen Funktionen:
Neuer Befehl "get detectDev" in HMCCU. Sollte ein Gerät nicht korrekt angelegt werden oder funktionieren, kann die Ausgabe dieses Befehls mir helfen, den Fehler zu finden.
Neues Attribut "createDeviceGroup". Wenn dieses Attribut gesetzt ist, werden FHEM Devices, die alle zum gleichen CCU Gerät gehören, beim Anlegen mit "get create" oder "get createDev" automatisch der gleichen Gruppe zugewiesen. Der Name dieser Gruppe wird mit diesem Attribut definiert.
Wenn man z.B. eine Fernbedienung mit 6 Tasten hat und diese mit "get create" anlegt, erzeugt HMCCU 6 HMCCUCHN Devices (1 je Taste). Mit createDeviceGroup = "%t %n" werden alle 6 Devices einer Gruppe zugeordnet, deren Name aus "DeviceType DeviceName" zusammengesetzt wird (die Platzhalter werden ersetzt, siehe auch Commandref).
Nachtrag: Folgende Geräte sollten jetzt beim Anlegen automatisch erkannt werden: HmIP-SAM, HmIP-SPDR, HmIP-FCI1
Zitat von: eurofinder am 02 September 2021, 13:21:59
@zap:
Upps, sorry. Ich habe die Datei oben berichtigt.
Gruß
eurofinder
Wie vermutet (befürchtet). Die CCU meldet LEVEL so:
LEVEL: FLOAT [R,W,E] [Visible,Sticky] RANGE=0...1.01 DFLT=0
Und so sollte es aussehen:
LEVEL: FLOAT [R,W,E] [Visible,Sticky] RANGE=0...1.01 DFLT=0 UNIT=100%
In dem Fall muss Du Dir mit dem Attribut ccuscaleval behelfen:
ccuscaleval LEVEL:0:1:0:100
@zap:
Danke.
Gruß
eurofinder
Zitat von: zap am 02 September 2021, 19:58:20
Die Version 5.0 steht in Github zur Verfügung. Installation siehe erster Beitrag in diesem Thread.
Neben Bugfixes gibt es folgende neuen Funktionen:
Neuer Befehl "get detectDev" in HMCCU. Sollte ein Gerät nicht korrekt angelegt werden oder funktionieren, kann die Ausgabe dieses Befehls mir helfen, den Fehler zu finden.
Neues Attribut "createDeviceGroup". Wenn dieses Attribut gesetzt ist, werden FHEM Devices, die alle zum gleichen CCU Gerät gehören, beim Anlegen mit "get create" oder "get createDev" automatisch der gleichen Gruppe zugewiesen. Der Name dieser Gruppe wird mit diesem Attribut definiert.
Wenn man z.B. eine Fernbedienung mit 6 Tasten hat und diese mit "get create" anlegt, erzeugt HMCCU 6 HMCCUCHN Devices (1 je Taste). Mit createDeviceGroup = "%t %n" werden alle 6 Devices einer Gruppe zugeordnet, deren Name aus "DeviceType DeviceName" zusammengesetzt wird (die Platzhalter werden ersetzt, siehe auch Commandref).
Nachtrag: Folgende Geräte sollten jetzt beim Anlegen automatisch erkannt werden: HmIP-SAM, HmIP-SPDR, HmIP-FCI1
Hallo Zap,
die version 5.0 läuft bei mir unauffällig, bei mir funktioniert alles - danke!
Ich nutze einen HmIP-SPI mit der aktuellen (beta)-Version 5.0. Dabei gibt es das Problem, dass sich der Präsenzmelder über FHEM zwar inaktiv setzen lässt aber nicht mehr auf aktiv. Scheint das gleiche Problem wie hier (https://forum.fhem.de/index.php/topic,107077.msg1150150.html#msg1150150) zu sein. Wenn ich stattdessen mit "set Melder datapoint 1.PRESENCE_DETECTION_ACTIVE true" arbeite funktioniert es. Die hier (https://forum.fhem.de/index.php/topic,107115.0/all.html) gefundene Lösung funktioniert nicht (vermutlich, da ich die aktuellere Beta nutze).
Der Rest läuft problemlos.
Ja, das ist ein Bug. Ist bei meinem Bewegungsmelder auch so.
Neues Update für 5.0 im GitHub Rep. sowie FHEM contrib SVN.
Ja, ich hatte gestern keine Zeit mehr, es hier anzukündigen.
- Der Bug bei der Aktivierung/Deaktivierung von Bewegungs-/Präsenzmeldern ist behoben
- RPC-Server und I/O Devices können nun ohne Nebenwirkungen umbenannt werden
- Wenn ein I/O Device gelöscht wird, werden auch die zugehörigen RPC-Devices gelöscht
- Wenn ein Attribut eines laufenden RPC Device geändert/gesetzt wird, erscheint ein Hinweis, dass die Änderung erst nach einem Neustart des RPC-Servers wirksam wird
@zap Moin
Ich habe die HMCCU 5.0 installiert und probiert was die Wetterstation nun so treibt.
Die svHmIP-Variablen werden bei "get values" weiterhin nicht mit ausgegeben.
Nur sporadisch werden diese aufgefrischt (Systemstart?).
Als ccureadingfilter ist .* gesetzt.
Wenn ich jetzt als Versuch in den ccureadingfilter nur ein "svHmIPRainCounterToday_1609" eintrage und dann bestätige, sehe ich im
Event Monitor das scheinbar die Anfrage an die CCU3 funktioniert?
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor svHmIPRainCounterToday_1609: 0.0
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor 17.1
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor rssipeer: N/A
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor devstate: ok
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor activity: alive
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor battery: ok
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor rssidevice: -73
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor hmstate: 17.1
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor Regen: NEIN
2021-09-10 23:04:06 Global global ATTR HM.OG.bk.WE.Sensor ccureadingfilter svHmIPRainCounterToday_1609
Die Variablen welche groß geschrieben werden nicht ausgegeben.
Nur die klein geschriebenen.
Kann das sein obwohl nur "svHmIPRainCounterToday_1609" im ccureadingfilter steht?
Falls das mit HMCCU nicht machbar ist abzufragen muss ich mal schauen ob man das in der CCU als Systemvariable setzen kann.
Dann könnte ich das von der d_ccu aus per AT abholen. Klappt schon mal mit der CPU-Temperatur :=)
Danke für deine Arbeit.
Gruß
Gerd
Das svm... ist eine (verknüpfte) Systemvariable. Ich habe leider kein Gerät, das sowas verwendet. Daher ist das Blind-Entwicklung.
@zap
Betreffend HmIP-SWO-PR und Variablen svHmIPRainCounterToday_xxxx, svHmIPRainCounterYesterday_xxx, svHmIPSunshineCounterToday_xxxx und svHmIPSunshineCounterYesterday_xxx.
Ich hab im iobroker Forum https://forum.iobroker.net/post/197178 (https://forum.iobroker.net/post/197178) etwas gefunden mit dem man sich das zusammenbasteln kann.
Hierzu muss man in der CCU vier neue Variablen erzeugen lassen. Diese können dann per get ausgelesen werden.
Nun kann man mit einem Notify, wenn die WX-Station abgefragt wird (trigger auf z.B. rssidevice), die angelegten vier neuen Systemvariablen abfragen.
defmod HM.OG.bk.WE.Sensor_notify_1 notify HM.OG.bk.WE.Sensor rssidevice:.* get d_ccu vars Var_Regenmenge_heute;;\
get d_ccu vars Var_Regenmenge_gestern;;\
get d_ccu vars Var_Sonne_heute;;\
get d_ccu vars Var_Sonne_gestern;;
Das Problem dieser internen Variablen scheint ja unabhängig von der Home-Automationssoftware zu sein :o
Bei io-Broker hat man das wohl hinzubekommen indem man die Versteckten Variablen frei gibt.
Soweit funktioniert bei mir die Wetterstation. Mehr ist allerdings auch noch nicht angemeldet.
Danke und Gruss
Gerd
Es gibt ein Update in Git/SVN: Der Befehl "get vars" liest nun auch versteckte Variablen.
Übrigens: Ein AT zum regelmäßigen Lesen der Variablen ist nicht erforderlich. Stattdessen das Attribut "ccuGetVars" verwenden. Beispiel: Alle 60 Sekunden die Variablen lesen, die mit "sv" anfangen:
attr ccuGetVars 60:^sv
Hallo @zap,
das scheint an mir vorbei gegangen zu sein. Ich hab alles mögliche gelesen das die Leute eben nicht drauf zugreifen konnten.
Aber das dies nun doch geht war mir neu.
Sporadisch wurden diese "sv_Variablen" ja angezeigt aber nicht immer aktualisiert.
Wenn die Versteckten Variablen aber erst nach dem jetzigen Update funktionieren ist es auch klar das es mit meiner Aktuellen nicht funktioniert.
Diese "sv_Variablen" werden dann im jeweiligen zugehörigen Device angezeigt?
Zitatattr ccuGetVars 60:^sv
In der HMCCU anzugeben und auch mehrere (RegEx) möglich?
Oder im jeweiligen Device?
Danke , Gerd
PS: Kannst Du das Betreff auf "HMCCU 5.x" abändern ;)?
@zap
Manuell aus dem SVN die beiden aktuellen PMs geladen.
Die "sv-Variablen" werden nun in HMCCU angezeigt (siehe Bild)!
Zitatattr d_ccu 60:^sv|^Temperatur_CCU3
funktioniert scheinbar auch.
Zumindest wird mir die CPU-Temperatur als Reading aktualisiert :D. Sonne oder Regen gibt es derzeit nicht.
Update: Die sv-Variablen werden ebenfalls aktualisiert :)
In HMCCU kann ich
Zitatget d_ccu vars sv.*
eingeben. Es wird dann ein Fenster mit den Werten angezeigt.
In HMCCUCHN funktioniert z.B.
Zitatget HM.OG.bk.WE.Sensor datapiont svHmIPRainCounterToday_1609
nicht.
2021.09.12 00:22:44 1 : HMCCUCHN [HM.OG.bk.WE.Sensor] Error CMD = Write((datapoints.Get("HmIP-RF.00185BE9A57631:1.svHmIPRainCounterToday_1609")).Value())
2021.09.12 00:22:44 1 : HMCCUCHN [HM.OG.bk.WE.Sensor] HMCCUCHN: HM.OG.bk.WE.Sensor Execution of CCU script or command failedAuch wenn die "sv-Variablen" Interne sind, sollten diese doch aber im jeweiligen Device angezeigt/abgerufen werden können!?
Du meintest ja das funktioniert nicht, wie man aber bei HMCCU sieht scheint das ja doch möglich zu sein?
Wenn das nicht klappt, macht es aber doch kein Sinn diese im Device anzuzeigen.
Will ich die jeweiligen Readings beisammen haben muss ich nun erst mit einem "setreading" die Werte aus dem Device d_ccu (HMCCU) in das Device der Wetterstation übertragen.
Ich weis das es immer einfach geredet ist wenn man es nicht machen muss, aber deine Module sollten ja Userfreundlicher werden ;)
Gruss Gerd
Anscheinend zeigt ioBroker die Werte auch nicht am Gerät an, sondern nur als Variable im Rega-Adapter.
Siehst Du die Variablen, wenn du für das Device "get deviceinfo" ausführst?
Mein Problem: Irgendwie muss ich herausfinden, welche Variable welchem Gerät zugeordnet ist.
@zap
Ja im Wetterstations-Device sehe ich die sv-Variablen und auch die selbst angelegten in der ccu3.
Siehe Bild (derzeit Mobil)
Der Befehl "get deviceinfo" zeigt die Variablen an, da hier die Rega-Schnittstelle der CCU verwendet wird.
Die Befehle "get config", "get values" und "get update" verwenden aus Performance-Gründen (und wegen einiger anderer "Kleinigkeiten") die RPC-Schnittstelle der CCU. Dieser Schnittstelle sind Systemvariablen unbekannt, daher werden sie nicht übertragen. Das dürfte auch der Grund sein, weshalb die Variablen auch beim IOBroker nicht am zugehörigen Gerät angezeigt werden (der IOBroker nutzt fast nur RPC).
Momentan habe ich kein (kurzfristige) Lösung für dieses Problem.
Zur Info:
Die Schichten der CPU:
3. WebUI
2. Rega HSS (+ u.a. Systemvariablen), Schnittstelle = HM-Script
1. Kommunikationsprozesse, Schnittstelle = RPC
2: get deviceinfo
1: get config, values, update
Hallo @zap,
Alles klar. Also kein Bug und kein Feature ;D
Hast du mir ein Vorschlag wie ich am einfachsten die Daten von der d_ccu/HMCCU welche nur dort vorhandenen sind, einfach in das jeweilige Device bekomme?
Hatte das mit einem notify auf ein Event von d_ccu laufen und schreiben mit setreading. Das lief aber irgend wie in eine böse Schleife :-\
Rufe nun mit einem AT eine SUB auf welches mir die sv-Variablen in das Wetterstations-Device schreiben.
Danke für deine Infos und Arbeit!
Gruß Gerd
Hallo!
HAbe ein kleines Problemchen.. Im Logfile steht bei mir ein Eintrag den ich nicht so ganz verstehe.. denn ich habe kein on-till oder on-for-timer für dieses Gerät definiert... Jedenfalls nicht das ich wüsste...
Hat einer eine Idee wo das Problem ist?
Log Eintrag
2021.09.15 19:26:08 2: HMCCU [d_ccu] Can't get definition of MEQ0714863:1.STATE. Ignoring command on-till for device FhemTabletSwitch
2021.09.15 19:26:08 2: HMCCU [d_ccu] Can't get definition of MEQ0714863:1.STATE. Ignoring command on-for-timer for device FhemTabletSwitch
HM Device "list"
Internals:
CFGFN
DEF MEQ0714863:1
FUUID 61422cb0-f33f-e7ed-a9b6-a53f5e99fb36b4a3
IODev d_ccu
NAME FhemTabletSwitch
NR 1509
STATE off
TYPE HMCCUCHN
ccuaddr MEQ0714863:1
ccudevstate active
ccuif BidCos-RF
ccuname HM-LC-Dim1T-Pl-3
ccurolectrl DIMMER
ccurolestate DIMMER
ccusubtype HM-LC-Dim1T-Pl-3
ccutype HM-LC-Dim1T-Pl-3
firmware 2.9
readonly no
READINGS:
2021-09-15 21:08:20 DIRECTION none
2021-09-15 21:08:20 ERROR_OVERHEAT false
2021-09-15 21:08:20 ERROR_OVERLOAD false
2021-09-15 21:08:20 ERROR_REDUCED false
2021-09-15 19:26:08 INHIBIT false
2021-09-15 19:26:08 IODev d_ccu
2021-09-15 21:08:20 LEVEL off
2021-09-15 19:36:59 LEVEL_REAL 0
2021-09-15 21:08:20 WORKING no
2021-09-15 21:08:21 activity alive
2021-09-15 21:08:20 control off
2021-09-15 21:08:21 devstate ok
2021-09-15 21:08:21 hmstate off
2021-09-15 21:08:20 pct 0
2021-09-15 21:08:21 rssidevice -255
2021-09-15 21:08:21 rssipeer -255
2021-09-15 21:08:21 sign off
2021-09-15 21:08:20 state off
hmccu:
channels 1
devspec MEQ0714863:1
nodefaults 0
role 1:DIMMER
semDefaults 0
cmdlist:
get
set off:noArg on:noArg stop:noArg pct toggle:noArg
control:
chn 1
dpt LEVEL
dp:
0.AES_KEY:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.DUTYCYCLE:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.RSSI_DEVICE:
VALUES:
NVAL -255
ONVAL -255
OSVAL -255
OVAL 1
SVAL -255
VAL 1
0.RSSI_PEER:
VALUES:
NVAL -255
ONVAL -255
OSVAL -255
OVAL 1
SVAL -255
VAL 1
0.STICKY_UNREACH:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.UNREACH:
VALUES:
NVAL false
ONVAL false
OSVAL alive
OVAL false
SVAL alive
VAL false
0.UPDATE_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
1.DIRECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL none
OVAL 0
SVAL none
VAL 0
1.ERROR_OVERHEAT:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.ERROR_OVERLOAD:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.ERROR_REDUCED:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.INHIBIT:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
1.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.000000
SVAL off
VAL 0.000000
1.LEVEL_REAL:
VALUES:
NVAL 0
ONVAL 100
OSVAL 100
OVAL 1.000000
SVAL 0
VAL 0.000000
1.WORKING:
VALUES:
NVAL 0
ONVAL 0
OSVAL no
OVAL 0
SVAL no
VAL 0
roleCmds:
get:
set:
off:
channel 1
role DIMMER
subcount 1
syntax V:LEVEL:0
usage off
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
unit 100%
on:
channel 1
role DIMMER
subcount 1
syntax V:LEVEL:100
usage on
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
unit 100%
on-for-timer:
role DIMMER
syntax V:ON_TIME:?duration V:STATE:1
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname duration
partype 2
ps VALUES
unit s
on-till:
role DIMMER
syntax V:ON_TIME:?time V:STATE:1
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname time
partype 2
ps VALUES
unit s
pct:
channel 1
role DIMMER
subcount 3
syntax V:LEVEL:?level V:ON_TIME:?time=0.0 V:RAMP_TIME:?ramp=0.5
usage pct level [time] [ramp]
subcmd:
000:
args
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname level
partype 2
ps VALUES
unit 100%
001:
args 0.0
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname time
partype 2
ps VALUES
unit s
002:
args 0.5
dpt RAMP_TIME
fnc
max 85825945.600000
min 0.000000
parname ramp
partype 2
ps VALUES
unit s
stop:
channel 1
role DIMMER
subcount 1
syntax V:RAMP_STOP:1
usage stop
subcmd:
000:
args 1
dpt RAMP_STOP
fnc
max 1
min 0
parname RAMP_STOP
partype 3
ps VALUES
unit
state:
chn 1
dpt LEVEL
Attributes:
cmdIcon on:general_an off:general_aus
room HOMEMATIC
substexcl pct
webCmd pct
widgetOverride pct:slider,0,10,100
Und das einzige DOIF wo das Device eingebunden ist:
Internals:
DEF ([FHEMTablet:batterylevel] < 20 and [?FhemTabletSwitch] eq "off")
(set FhemTabletSwitch on)
DOELSEIF
([FHEMTablet:batterylevel] > 80 and [?FhemTabletSwitch] eq "on")
(set FhemTabletSwitch off)
FUUID 613681a2-f33f-e7ed-8d36-fdf6893b6c504220
MODEL FHEM
NAME DOIFFHEMTabletPower
NOTIFYDEV global,FHEMTablet
NR 206
NTFY_ORDER 50-DOIFFHEMTabletPower
STATE cmd_2
TYPE DOIF
VERSION 24643 2021-06-16 07:26:15
READINGS:
2021-09-15 21:12:56 Device FHEMTablet
2021-09-15 19:36:56 cmd 2
2021-09-15 19:36:56 cmd_event FHEMTablet
2021-09-15 19:36:56 cmd_nr 2
2021-09-15 21:12:56 e_FHEMTablet_batterylevel 85
2021-09-15 19:27:48 mode enabled
2021-09-15 19:36:56 state cmd_2
Regex:
accu:
collect:
cond:
FHEMTablet:
0:
batterylevel ^FHEMTablet$:^batterylevel:
1:
batterylevel ^FHEMTablet$:^batterylevel:
attr:
cmdState:
wait:
waitdel:
condition:
0 ::ReadingValDoIf($hash,'FHEMTablet','batterylevel') < 20 and ::InternalDoIf($hash,'FhemTabletSwitch','STATE') eq "off"
1 ::ReadingValDoIf($hash,'FHEMTablet','batterylevel') > 80 and ::InternalDoIf($hash,'FhemTabletSwitch','STATE') eq "on"
do:
0:
0 set FhemTabletSwitch on
1:
0 set FhemTabletSwitch off
2:
helper:
DEVFILTER ^global$|^FHEMTablet$
NOTIFYDEV global|FHEMTablet
event locale: de_DE,internalstoragetotalspace: 27014008832,androidsdk: 27,devicemodel: TFMTKAW01232,isplugged: no,apptotalmemory: 134217728,screenon: yes,topfragmenttag: ,ramfreememory: 1057292288,serial: 38581ZQI6000145,ismenuopen: no,appversionname: 1.43.1,screenorientation: 270,appusedmemory: 6330016,kiosklocked: no,hostname4: FHEMTablet.fritz.box,devicename: TFMTKAW01232,hostname6: f%p2p0,deviceid: 94f,lastappstart: 06.09.21 22:38:51,screenlocked: no,isdeviceowner: no,islicensed: yes,displayheightpixels: 1920,motiondetectorstatus: no,foregroundapp: de.ozerov.fully,isinforcedsleep: no,statustext: N/A,isinscreensaver: no,ssid: "MyCastle",currenttabindex: 0,wifisignallevel: 7,status: OK,androidversion: 8.1.0,ramtotalmemory: 2058424320,ip4: 192.168.1.20,isrooted: no,isdeviceadmin: yes,screenbrightness: 40,appfreememory: 127887712,execstate: OK N/A,mac: F,maintenancemode: no,batterytemperature: 25,build: TFMTKAW01232_20180911_V1.1.12,plugged: no,batterylevel: 85,keyguardlocked: no,currentpage: http://192.168.1.80:8083/fhem/tablet/indexWohnzimmer.html,ismobiledataenabled: no,ramusedmemory: 1001132032,devicemanufacturer: EMDOOR,ip6: FEF,starturl: http://192.168.1.80:8083/fhem/tablet/indexWohnzimmer.html,kioskmode: no,displaywidthpixels: 1080,isindaydream: no,appversioncode: 902,internalstoragefreespace: 25463992320,on
globalinit 1
last_timer 0
sleeptimer -1
timerdev FHEMTablet
timerevent currentpage: http://192.168.1.80:8083/fhem/tablet/indexWohnzimmer.html,ismobiledataenabled: no,plugged: yes,build: TFMTKAW01232_20180911_V1.1.12,batterylevel: 81,keyguardlocked: no,starturl: http://192.168.1.80:8083/fhem/tablet/indexWohnzimmer.html,kioskmode: no,ip6: FE1F,devicemanufacturer: EMDOOR,ramusedmemory: 992120832,isindaydream: no,displaywidthpixels: 1080,internalstoragefreespace: 25463963648,appversioncode: 902,androidversion: 8.1.0,ramtotalmemory: 2058424320,isdeviceadmin: yes,screenbrightness: 40,isrooted: no,ip4: 192.168.1.20,execstate: OK N/A,mac: A1F,maintenancemode: no,appfreememory: 127924296,batterytemperature: 25,devicename: TFMTKAW01232,hostname4: FHEMTablet.fritz.box,hostname6: fe80::aca%p2p0,deviceid: 94f7ef,appusedmemory: 6293432,kiosklocked: no,motiondetectorstatus: no,displayheightpixels: 1920,lastappstart: 06.09.21 22:38:51,screenlocked: no,islicensed: yes,isdeviceowner: no,statustext: N/A,foregroundapp: de.ozerov.fully,isinforcedsleep: no,status: OK,wifisignallevel: 6,isinscreensaver: no,ssid: "MyCastle",currenttabindex: 0,locale: de_DE,internalstoragetotalspace: 27014008832,devicemodel: TFMTKAW01232,isplugged: yes,apptotalmemory: 134217728,androidsdk: 27,topfragmenttag: ,screenon: yes,ismenuopen: no,appversionname: 1.43.1,screenorientation: 270,ramfreememory: 1066303488,serial: 38581ZQI6000145,on
triggerDev FHEMTablet
timerevents:
currentpage: http://192.168.1.80:8083/fhem/tablet/indexWohnzimmer.html
ismobiledataenabled: no
plugged: yes
build: TFMTKAW01232_20180911_V1.1.12
batterylevel: 81
keyguardlocked: no
starturl: http://192.168.1.80:8083/fhem/tablet/indexWohnzimmer.html
kioskmode: no
ip6: FE:81F
devicemanufacturer: EMDOOR
ramusedmemory: 992120832
isindaydream: no
displaywidthpixels: 1080
internalstoragefreespace: 25463963648
appversioncode: 902
androidversion: 8.1.0
ramtotalmemory: 2058424320
isdeviceadmin: yes
screenbrightness: 40
isrooted: no
ip4: 192.168.1.20
execstate: OK N/A
mac: AC:F
maintenancemode: no
appfreememory: 127924296
batterytemperature: 25
devicename: TFMTKAW01232
hostname4: FHEMTablet.fritz.box
hostname6: fe82p0
deviceid: 94f7ef
appusedmemory: 6293432
kiosklocked: no
motiondetectorstatus: no
displayheightpixels: 1920
lastappstart: 06.09.21 22:38:51
screenlocked: no
islicensed: yes
isdeviceowner: no
statustext: N/A
foregroundapp: de.ozerov.fully
isinforcedsleep: no
status: OK
wifisignallevel: 6
isinscreensaver: no
ssid: "MyCastle"
currenttabindex: 0
locale: de_DE
internalstoragetotalspace: 27014008832
devicemodel: TFMTKAW01232
isplugged: yes
apptotalmemory: 134217728
androidsdk: 27
topfragmenttag:
screenon: yes
ismenuopen: no
appversionname: 1.43.1
screenorientation: 270
ramfreememory: 1066303488
serial: 38581ZQI6000145
on
timereventsState:
currentpage: http://192.168.1.80:8083/fhem/tablet/indexWohnzimmer.html
ismobiledataenabled: no
plugged: yes
build: TFMTKAW01232_20180911_V1.1.12
batterylevel: 81
keyguardlocked: no
starturl: http://192.168.1.80:8083/fhem/tablet/indexWohnzimmer.html
kioskmode: no
ip6: FE804:81F
devicemanufacturer: EMDOOR
ramusedmemory: 992120832
isindaydream: no
displaywidthpixels: 1080
internalstoragefreespace: 25463963648
appversioncode: 902
androidversion: 8.1.0
ramtotalmemory: 2058424320
isdeviceadmin: yes
screenbrightness: 40
isrooted: no
ip4: 192.168.1.20
execstate: OK N/A
mac: AC:8:1F
maintenancemode: no
appfreememory: 127924296
batterytemperature: 25
devicename: TFMTKAW01232
hostname4: FHEMTablet.fritz.box
hostname6: f0
deviceid: 94dfc7ef
appusedmemory: 6293432
kiosklocked: no
motiondetectorstatus: no
displayheightpixels: 1920
lastappstart: 06.09.21 22:38:51
screenlocked: no
islicensed: yes
isdeviceowner: no
statustext: N/A
foregroundapp: de.ozerov.fully
isinforcedsleep: no
status: OK
wifisignallevel: 6
isinscreensaver: no
ssid: "MyCastle"
currenttabindex: 0
locale: de_DE
internalstoragetotalspace: 27014008832
devicemodel: TFMTKAW01232
isplugged: yes
apptotalmemory: 134217728
androidsdk: 27
topfragmenttag:
screenon: yes
ismenuopen: no
appversionname: 1.43.1
screenorientation: 270
ramfreememory: 1066303488
serial: 38581ZQI6000145
state: on
triggerEvents:
locale: de_DE
internalstoragetotalspace: 27014008832
androidsdk: 27
devicemodel: TFMTKAW01232
isplugged: no
apptotalmemory: 134217728
screenon: yes
topfragmenttag:
ramfreememory: 1057292288
serial: 38581ZQI6000145
ismenuopen: no
appversionname: 1.43.1
screenorientation: 270
appusedmemory: 6330016
kiosklocked: no
hostname4: FHEMTablet.fritz.box
devicename: TFMTKAW01232
hostname6: de50::eea9:33dd:fe14:44f%p2p0
deviceid: 23d79dd8-c6dfc7ef
lastappstart: 06.09.21 22:38:51
screenlocked: no
isdeviceowner: no
islicensed: yes
displayheightpixels: 1920
motiondetectorstatus: no
foregroundapp: de.ozerov.fully
isinforcedsleep: no
statustext: N/A
isinscreensaver: no
ssid: "MyCastle"
currenttabindex: 0
wifisignallevel: 7
status: OK
androidversion: 8.1.0
ramtotalmemory: 2058424320
ip4: 192.168.1.20
isrooted: no
isdeviceadmin: yes
screenbrightness: 40
appfreememory: 127887712
execstate: OK N/A
mac: SS:A3:33:WW:08:1F
maintenancemode: no
batterytemperature: 25
build: TFMTKAW01232_20180911_V1.1.12
plugged: no
batterylevel: 85
keyguardlocked: no
currentpage: http://192.168.1.80:8083/fhem/tablet/indexWohnzimmer.html
ismobiledataenabled: no
ramusedmemory: 1001132032
devicemanufacturer: EMDOOR
ip6: FE33::EDE9:33EE:RE14:33F
starturl: http://192.168.1.80:8083/fhem/tablet/indexWohnzimmer.html
kioskmode: no
displaywidthpixels: 1080
isindaydream: no
appversioncode: 902
internalstoragefreespace: 25463992320
on
triggerEventsState:
locale: de_DE
internalstoragetotalspace: 27014008832
androidsdk: 27
devicemodel: TFMTKAW01232
isplugged: no
apptotalmemory: 134217728
screenon: yes
topfragmenttag:
ramfreememory: 1057292288
serial: 38581ZQI6000145
ismenuopen: no
appversionname: 1.43.1
screenorientation: 270
appusedmemory: 6330016
kiosklocked: no
hostname4: FHEMTablet.fritz.box
devicename: TFMTKAW01232
hostname6: ed80::dsa9:22rr:fe14:81f%p2p0
deviceid: 23f74sd8-c3dfc1ef
lastappstart: 06.09.21 22:38:51
screenlocked: no
isdeviceowner: no
islicensed: yes
displayheightpixels: 1920
motiondetectorstatus: no
foregroundapp: de.ozerov.fully
isinforcedsleep: no
statustext: N/A
isinscreensaver: no
ssid: "MyCastle"
currenttabindex: 0
wifisignallevel: 7
status: OK
androidversion: 8.1.0
ramtotalmemory: 2058424320
ip4: 192.168.1.20
isrooted: no
isdeviceadmin: yes
screenbrightness: 40
appfreememory: 127887712
execstate: OK N/A
mac: AC:B9:14:12:03:2F
maintenancemode: no
batterytemperature: 25
build: TFMTKAW01232_20180911_V1.1.12
plugged: no
batterylevel: 85
keyguardlocked: no
currentpage: http://192.168.1.80:8083/fhem/tablet/indexWohnzimmer.html
ismobiledataenabled: no
ramusedmemory: 1001132032
devicemanufacturer: EMDOOR
ip6: FE70::AAA4:13EE:FE22:82F
starturl: http://192.168.1.80:8083/fhem/tablet/indexWohnzimmer.html
kioskmode: no
displaywidthpixels: 1080
isindaydream: no
appversioncode: 902
internalstoragefreespace: 25463992320
state: on
internals:
all FhemTabletSwitch:STATE
readings:
all FHEMTablet:batterylevel
trigger:
uiState:
uiTable:
Attributes:
do always
room DOIF
Nutzt Du die letzte Version von HMCCU? Bzw. prüfe wenn möglich mal die Datei HMCCUConf.pm. Da sollte ab Zeile 356 das stehen:
'DIMMER' => {
'pct' => '3:V:LEVEL:?level 1:V:ON_TIME:?time=0.0 2:V:RAMP_TIME:?ramp=0.5',
'on' => 'V:LEVEL:100',
'off' => 'V:LEVEL:0',
'on-for-timer' => 'V:ON_TIME:?duration V:LEVEL:100',
'on-till' => 'V:ON_TIME:?time V:LEVEL:100',
'up' => 'V:LEVEL:?delta=+10',
'down' => 'V:LEVEL:?delta=-10',
'stop' => 'V:RAMP_STOP:1'
},
Wichtig sind die Einträge bei on-for-timer und on-till. Da muss eben statt V:STATE V:LEVEL stehen. Der Dimmer hat kein STATE. Die Befehle werden automatisch anhand der Rolle (hier "DIMMER") definiert.
Falls das nicht so aussieht bitte ein Update machen wie auf Seite 1 beschrieben.
::) Ja da haben wir es wieder... Selbstgemachte Probleme... Hatte natürlich noch eine alte Version... Jetzt ist es die 5er
Wann wird denn die offiziell in den Updateprozess eingebunden? Habe mir durch einfaches Update natürlich erste die 3er installiert... :-X
Vielen Dank!
Scheinen ja keine größeren Bugs mehr drin zu sein. Ich bin jetzt mal ne Woche in Urlaub ... danach. Möchte es ungern freigeben, wenn ich nicht da bin und helfend eingreifen kann.
@zap:
Danke für das Modul und schöne Urlaubstage
eurofinder
Guten Morgen Zusammen,
ich finde es super, dass am Modul HMCCU so gut weiter gearbeitet wird.
Da ich meinen Fhem mal wieder aktualisiert hatte musste ich ja wie gewohnt mittels:
update all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
auch HMCCU updaten.
Und verwundert war ich, dass nun Version 5.0 zur Verfügung steht.
Leider haben meine HM-Geräte dann nicht mehr richtig funktioniert.
Jetzt habe ich herausgefunden, dass mittels
set "Gerätename" defaults resetdie Geräte einzeln zurückgesetzt werden können.
Hierbei wird aber auch der Raum auf "Homematic" geändert.
Ist natürlich dann eine Fleißaufgabe ...
Daher nun meine Fragen:
- Gibt es einen Befehl, der alle HM-Geräte zurücksetzt oder auf Version 5.0 anpasst?
- Gibt es auch die Möglichkeit, dass die Räume nicht auf "Homematic" geändert werden
sondern die "gesetzte"Zuordnung erhalten bleibt oder abgefragt wird soll auch der Raum verändert werden?
Kleiner Wunsch: können wir für die HMCCU Version 5.x nicht einen neuen Kanal (oder wie die genaue
Bezeichnung ist) eröffnen? So muss keiner wissen oder suchen, dass auf Seite 43 von ... steht, es gibt eine Version 5.x.
Dankeschön
Zitat von: aherby am 18 September 2021, 09:40:29
Gibt es einen Befehl, der alle HM-Geräte zurücksetzt oder auf Version 5.0 anpasst?
naja, wenn deine HM-Geräte alle einem bestimmten Namensschema folgen, kannst du doch
set Gerätename defaults resetfür "Gerätename" eine RegExp nutzen.
Oder hängst einen Filter dran: https://fhem.de/commandref_DE.html#devspec
Die Devspec von FHEM sind sehr mächtig. Mit TYPE=HMCCUCHN könnte man z.B. alle HMCCUCHN Devices gleichzeitig ansprechen.
Wenn nicht allzu viele Devices vorhanden sind, könnte man sie mit der 5.0 auch neu anlegen, was allerdings auch zur Fleißaufgabe werden kann.
also ich habe gerade mal versucht auf die aktuelle version umzustellen leider habe ich danach fast keine hmccu devices mehr.
2021.09.19 12:06:39 1: Messages collected while initializing FHEM:configfile: raspberrymatic: unknown attribute rpcport. Type 'attr raspberrymatic ?' for a detailed list.
Usage: define sc_wz_g HMCCUDEV device [control-channel] ['readonly'] ['noDefaults'|'defaults'] [forceDev] [iodev={iodev-name}]
setuuid: Please define sc_wz_g first
Usage: define HeizungWohnzimmer HMCCUDEV device [control-channel] ['readonly'] ['noDefaults'|'defaults'] [forceDev] [iodev={iodev-name}]
setuuid: Please define HeizungWohnzimmer first
Usage: define ThermostatBadezimmer HMCCUDEV device [control-channel] ['readonly'] ['noDefaults'|'defaults'] [forceDev] [iodev={iodev-name}]
setuuid: Please define ThermostatBadezimmer first
Usage: define ThermostatSchlafzimmer HMCCUDEV device [control-channel] ['readonly'] ['noDefaults'|'defaults'] [forceDev] [iodev={iodev-name}]
setuuid: Please define ThermostatSchlafzimmer first
Usage: define HeizungKinderzimmer HMCCUDEV device [control-channel] ['readonly'] ['noDefaults'|'defaults'] [forceDev] [iodev={iodev-name}]
setuuid: Please define HeizungKinderzimmer first
Usage: define rpimod HMCCUDEV device [control-channel] ['readonly'] ['noDefaults'|'defaults'] [forceDev] [iodev={iodev-name}]
setuuid: Please define rpimod first
Usage: define hmipHAP HMCCUDEV device [control-channel] ['readonly'] ['noDefaults'|'defaults'] [forceDev] [iodev={iodev-name}]
setuuid: Please define hmipHAP first
Usage: define HeizungBad HMCCUDEV device [control-channel] ['readonly'] ['noDefaults'|'defaults'] [forceDev] [iodev={iodev-name}]
setuuid: Please define HeizungBad first
Usage: define HeizungSchlafzimmer HMCCUDEV device [control-channel] ['readonly'] ['noDefaults'|'defaults'] [forceDev] [iodev={iodev-name}]
setuuid: Please define HeizungSchlafzimmer first
Usage: define ThermostatWohnzimmer HMCCUDEV device [control-channel] ['readonly'] ['noDefaults'|'defaults'] [forceDev] [iodev={iodev-name}]
setuuid: Please define ThermostatWohnzimmer first
selbst wenn ich in der fhem config hinter die define befehle ein forceDev setze legt er mir diese beim starten nicht an führe ich den selben befehl über FhemWeb aus dann wird das device angelegt.
ich möchte jedoch nicht alle devices neu definieren müssen.
Servus Zusammen,
bei folgenden HM-Geräten ist eigentlich kein Batteriedatenpunkt vorhanden oder wird nicht benötigt, da es sich um HM-Geräte mit Netzspannung handelt:
- HM-LC-Sw1-FM
- HM-LC-Sw2-FM
- HM-LC-Sw4-DR
- HM-LC-Sw1-Pl-CT-R1
- HM-LC-RGBW-WM
Beispiel von HM-LC-Sw1-FM
Zitat
0.UNREACH = false {b} [RE]
0.STICKY_UNREACH = false {b} [RWE]
0.CONFIG_PENDING = false {b} [RE]
0.LOWBAT = false {b} [RE]
0.DUTYCYCLE = false {b} [RE]
0.RSSI_DEVICE = 1 {n} [RE]
0.RSSI_PEER = 57 {n} [RE]
0.AES_KEY = 0 {n} [R]
Kann man die Meldung Oder Reading irgendwie komplett löschen?
Dankeschön
Gruß aherby
Zitat von: aherby am 18 September 2021, 09:40:29
Kleiner Wunsch: können wir für die HMCCU Version 5.x nicht einen neuen Kanal (oder wie die genaue
Bezeichnung ist) eröffnen? So muss keiner wissen oder suchen, dass auf Seite 43 von ... steht, es gibt eine Version 5.x.
Dankeschön
Das fände ich auch schön! ;D
Was ändert das? Ob es jetzt 4.4 oder 5.0 heißt ist in diesem Thread doch nahezu egal. Die Anweisungen im ersten Beitrag haben weiterhin Gültigkeit.
Ich freue mich schon, wenn zap die Version offiziell eincheckt und danke ihm für die viele Arbeit an 4.4 bzw. 5.0.
Servus Zusammen,
natürlich stelle ich ZAP deine Arbeit hier nicht in Frage.Im Gegenteil ich bin sehr sehr dankbar über das Modul
und deine Leistung.
Jedoch scheinen sich von der vorletzten Version 4.4x zu 5.0 ein paar Veränderungen gegeben zu haben.
Beispielsweise:
ZitatHM-PB-2-WM55, HM-PB-6-WM55
hier ist das Attribute :
event-on-update-reading PRESS.*als Standart gesetzt.
Dadurch werden bei mir keine Readings verändert.
Verändere ich es erstmal in
event-on-update-reading .*Funktionieren meine Schaltanweisungen wieder.
Aber ich glaube grundsätzlich sind Fehler gerade bei dem Typ(en) vorhanden.
Auch mein
ZitatHM-LC-Sw2-FM
fehlt wohl der Befehl
set "Gerätename" toggleEin
ZitatHmIP-SWDO-I
kann nur mit
define FK_Test1 HMCCUCHN 0010xxxxxxxxxx:1angelernt bzw. definiert werden.
Per
define FK_TEST HMCCUDEVkommt die Meldung
Zitat
Specify option 'forceDev' for HMCCUDEV or use HMCCUCHN instead (recommended). Command: define FK_Test1 HMCCUCHN ....
Kann nur ein Fehler bei mir sein oder ein allgemeines Problem / Veränderung.
Ist hier wer, der diese Fehler bestätigen kann?
Dankeschön
Gruß aherby
@aherby
PRESS: Hast Du denn ein Reading PRESS? Ein List vom Device wäre hilfreich.
HM-LC-SW2-FM, fehlender Toggle: Ebenfalls ein List bitte
HMIP-SWDO: Nun, die Fehlermeldung sagt doch, was Du machen muss, wenn Du unbedingt HMCCUDEV verwenden willst: Die Option "forcedev" beim defined mitgeben.
Ich empfehle aber, in diesem Fall dem Rat von HMCCU zu folgen und HMCCUCHN zu verwenden. Ein HMCCUDEV hat bei diesem Gerät keinerlei zusätzlichen Nutzen.
@benkler
Kannst Du mal prüfen, ob in der fhem.cfg irendwelche Sonderzeichen drin stehen? Das ist schon seltsam, dass die Define Befehle alle fehlschlagen. Beim Define während dem FHEM-Start ist ein forceDev nicht erforderlich. Das ist nur bei der interaktiven Definition über die Weboberfläche notwendig (eben um ein Update von 4.3 möglichst geräuscharm zu ermöglichen)
Zeig mal bitte einen der define Befehle, die nicht funktionieren.
konnte jetzt keine auffälligkeiten in meiner Config finden.
hier mal ein beispiel device aus der Config:
define sc_wz_g HMCCUDEV 00109D898C3878 defaults
setuuid sc_wz_g 6112b7a3-f33f-5212-2465-14947ab1e358ad71
attr sc_wz_g ccureadingfilter STATE
attr sc_wz_g event-on-change-reading .*
attr sc_wz_g hmstatevals SABOTAGE!1:sabotage
attr sc_wz_g room Geräte->HMiP
attr sc_wz_g statedatapoint 1.STATE
attr sc_wz_g substitute STATE!(0|false):closed,(1|true):open
attr sc_wz_g timestamp-on-change-reading 0.*,1.*
Das ist ein Bug. Ich checke spätestens morgen ein Update ein. Ich bin zwar eigentlich nicht für manuelle Änderungen der fhem.cfg. Du kannst das Problem jedoch selbst beheben, indem Du die fhem.cfg mit einem geeigneten Editor öffnest und per Suchen/Ersetzen das "defaults" in den defines entfernst (und auch "nodefaults", wenn Du das verwendet hast).
vielen dank für die Rückmeldung, hat funktioniert
Das Update mit dem behobenen "defaults" Bug ist nun im SVN und auf Github eingecheckt.
Servus Zap,
anbei das List vom HM-LC-Sw1-FM, wo denke ich das "toggle" fehlt:
Internals:
DEF LEQ0xxxxx1:1
FUUID 5f08d5fa-
IODev d_ccu
NAME AK_Flur_Licht
NR 754
STATE on
TYPE HMCCUCHN
ccuaddr LEQ0xxxxx1:1
ccudevstate active
ccuif BidCos-RF
ccuname Flurlicht
ccusubtype HM-LC-Sw1-FM
ccutype HM-LC-Sw1-FM
firmware 1.12
readonly no
READINGS:
2021-09-28 22:27:10 IODev d_ccu
2021-09-28 22:27:35 STATE on
2021-09-28 22:27:35 activity alive
2021-09-28 22:27:35 battery ok
2021-09-21 06:52:45 control on
2021-09-28 22:27:35 devstate stickyUnreach
2021-09-28 22:27:35 hmstate on
2021-09-28 22:27:35 rssidevice -255
2021-09-28 22:27:35 rssipeer -199
2021-09-28 22:27:35 sign off
2021-09-28 22:27:35 state on
hmccu:
channels 1
detect 1
devspec LEQ0xxxxx1:1
nodefaults 1
role 1:SWITCH
semDefaults 0
cmdlist:
get
set on:noArg on-till on-for-timer off:noArg
control:
dp:
0.AES_KEY:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.DUTYCYCLE:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.LOWBAT:
VALUES:
NVAL false
ONVAL false
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
VALUES:
NVAL -255
ONVAL -255
OSVAL -255
OVAL 1
SVAL -255
VAL 1
0.RSSI_PEER:
VALUES:
NVAL -199
ONVAL -199
OSVAL -199
OVAL 57
SVAL -199
VAL 57
0.STICKY_UNREACH:
VALUES:
NVAL true
ONVAL true
OSVAL true
OVAL true
SVAL true
VAL true
0.UNREACH:
VALUES:
NVAL false
ONVAL false
OSVAL alive
OVAL false
SVAL alive
VAL false
1.:
VALUES:
1.INHIBIT:
VALUES:
NVAL false
ONVAL false
OSVAL unlocked
OVAL false
SVAL unlocked
VAL false
1.STATE:
VALUES:
NVAL true
ONVAL true
OSVAL on
OVAL true
SVAL on
VAL true
1.WORKING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
roleCmds:
get:
set:
off:
channel 1
role SWITCH
subcount 1
syntax V:STATE:0
usage off
subcmd:
000:
args 0
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 000
unit
on:
channel 1
role SWITCH
subcount 1
syntax V:STATE:1
usage on
subcmd:
000:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 000
unit
on-for-timer:
channel 1
role SWITCH
subcount 2
syntax V:ON_TIME:?duration V:STATE:1
usage on-for-timer duration
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname duration
partype 2
ps VALUES
scn 000
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 001
unit
on-till:
channel 1
role SWITCH
subcount 2
syntax V:ON_TIME:?time V:STATE:1
usage on-till time
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname time
partype 2
ps VALUES
scn 000
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 001
unit
state:
dpt STATE
Attributes:
IODev d_ccu
alias Flurlicht
ccureadingfilter STATE
group Beleuchtung
room Flur
statedatapoint STATE
statevals on:true,off:false
substitute STATE!(1|true):on,(0|false):off
userattr room_map structexclude
Das List vom HM-LC-Sw2-FM, wo denke ich das "toggle" fehlt:
Internals:
DEF LEQ0xxxxx9:1
FUUID 5ee29153
IODev d_ccu
NAME AK_Wz_UP1_1
NR 237
STATE off
TYPE HMCCUCHN
ccuaddr LEQ0xxxxx9:1
ccudevstate active
ccuif BidCos-RF
ccuname Wurzellicht
ccusubtype HM-LC-Sw2-FM
ccutype HM-LC-Sw2-FM
firmware 1.12
readonly no
READINGS:
2021-09-28 22:27:10 IODev d_ccu
2021-09-28 22:27:36 STATE off
2021-09-28 22:27:36 activity alive
2021-09-28 22:27:36 battery ok
2021-09-21 06:52:45 control off
2021-09-28 22:27:36 devstate stickyUnreach
2021-09-28 22:27:36 hmstate off
2021-09-28 22:27:36 rssidevice -255
2021-09-28 22:27:36 rssipeer -173
2021-09-28 22:27:36 sign off
2021-09-28 22:27:36 state off
hmccu:
channels 1
detect 1
devspec LEQ0xxxxx9:1
nodefaults 1
role 1:SWITCH
semDefaults 0
cmdlist:
get
set on:noArg on-till on-for-timer off:noArg
control:
dp:
0.AES_KEY:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.DUTYCYCLE:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.LOWBAT:
VALUES:
NVAL false
ONVAL false
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
VALUES:
NVAL -255
ONVAL -255
OSVAL -255
OVAL 1
SVAL -255
VAL 1
0.RSSI_PEER:
VALUES:
NVAL -173
ONVAL -173
OSVAL -173
OVAL 83
SVAL -173
VAL 83
0.STICKY_UNREACH:
VALUES:
NVAL true
ONVAL true
OSVAL true
OVAL true
SVAL true
VAL true
0.UNREACH:
VALUES:
NVAL false
ONVAL false
OSVAL alive
OVAL false
SVAL alive
VAL false
1.INHIBIT:
VALUES:
NVAL false
ONVAL false
OSVAL unlocked
OVAL false
SVAL unlocked
VAL false
1.STATE:
VALUES:
NVAL false
ONVAL false
OSVAL off
OVAL false
SVAL off
VAL false
1.WORKING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
roleCmds:
get:
set:
off:
channel 1
role SWITCH
subcount 1
syntax V:STATE:0
usage off
subcmd:
000:
args 0
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 000
unit
on:
channel 1
role SWITCH
subcount 1
syntax V:STATE:1
usage on
subcmd:
000:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 000
unit
on-for-timer:
channel 1
role SWITCH
subcount 2
syntax V:ON_TIME:?duration V:STATE:1
usage on-for-timer duration
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname duration
partype 2
ps VALUES
scn 000
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 001
unit
on-till:
channel 1
role SWITCH
subcount 2
syntax V:ON_TIME:?time V:STATE:1
usage on-till time
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname time
partype 2
ps VALUES
scn 000
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 001
unit
state:
dpt STATE
Attributes:
IODev d_ccu
alias Wurzellicht
ccureadingfilter STATE
fp_Grundriss 125,905,0,Wurzellicht,
group Beleuchtung
room Homekit,Wohnzimmer
statedatapoint STATE
statevals on:true,off:false
substitute STATE!(1|true):on,(0|false):off
userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 room_map structexclude
widgetOverride control:uzsuSelectRadio,off,onKönnen hier auch die Batterie-Readings bei:
- HM-LC-Sw1-FM
- HM-LC-Sw2-FM
- HM-LC-Sw4-DR
- HM-LC-Sw1-Pl-CT-R1
- HM-LC-RGBW-WM
entfernt werden?
Das List vom HM-PB-6-WM55 ist:
Internals:
DEF LEQ0xxxxx2
FUUID 5eefcd15-f33f
IODev d_ccu
NAME WzTaster1
NR 608
STATE pressed
TYPE HMCCUDEV
ccuaddr LEQ0xxxxx2
ccudevstate active
ccuif BidCos-RF
ccuname WzTaster1_HM_LEQ0xxxxx2
ccurolectrl KEY
ccurolestate KEY
ccusubtype HM-PB-6-WM55
ccutype HM-PB-6-WM55
firmware 1.2
readonly no
OLDREADINGS:
READINGS:
2021-09-28 22:48:44 3.INSTALL_TEST 1
2021-09-28 22:48:44 3.PRESS_SHORT pressed
2021-09-28 22:48:44 activity alive
2021-09-28 22:48:44 battery ok
2021-09-25 08:25:44 control pressed
2021-09-28 22:48:44 devstate ok
2021-09-28 22:48:44 hmstate pressed
2021-09-28 22:48:44 rssidevice -255
2021-09-28 22:48:44 rssipeer -255
2021-09-28 22:48:44 sign off
2021-09-25 08:25:44 state pressed
hmccu:
channels 7
detect 2
devspec LEQ0xxxxx2
forcedev 0
nodefaults 1
role 0:MAINTENANCE,1:KEY,2:KEY,3:KEY,4:KEY,5:KEY,6:KEY
semDefaults 0
cmdlist:
get
set off:noArg on:noArg press:noArg
control:
chn 1
dpt PRESS_SHORT
dp:
0.AES_KEY:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.LOWBAT:
VALUES:
NVAL false
ONVAL false
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
VALUES:
NVAL -255
ONVAL -255
OSVAL -255
OVAL 1
SVAL -255
VAL 1
0.RSSI_PEER:
VALUES:
NVAL -255
ONVAL -255
OSVAL -255
OVAL 1
SVAL -255
VAL 1
0.STICKY_UNREACH:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.UNREACH:
VALUES:
NVAL false
ONVAL false
OSVAL alive
OVAL false
SVAL alive
VAL false
0.UPDATE_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
3.INSTALL_TEST:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
3.PRESS_SHORT:
VALUES:
NVAL 1
ONVAL 1
OSVAL pressed
OVAL 1
SVAL pressed
VAL 1
roleCmds:
get:
set:
off:
channel 1
role KEY
subcount 1
syntax V:PRESS_SHORT:1
usage off
subcmd:
000:
args 1
dpt PRESS_SHORT
fnc
max 1
min 0
parname PRESS_SHORT
partype 3
ps VALUES
scn 000
unit
on:
channel 1
role KEY
subcount 1
syntax V:PRESS_SHORT:1
usage on
subcmd:
000:
args 1
dpt PRESS_SHORT
fnc
max 1
min 0
parname PRESS_SHORT
partype 3
ps VALUES
scn 000
unit
press:
channel 1
role KEY
subcount 1
syntax V:PRESS_SHORT:1
usage press
subcmd:
000:
args 1
dpt PRESS_SHORT
fnc
max 1
min 0
parname PRESS_SHORT
partype 3
ps VALUES
scn 000
unit
state:
chn 1
dpt PRESS_SHORT
Attributes:
IODev d_ccu
cmdIcon press:taster
event-on-update-reading PRESS.*
group Schalter
room X_HARDWARE
webCmd press
Beim "HMIP-SWDO"
war ich irgendwie durch die Homematic-Anleitung der Meinung,
den Sabotage-Status als Kanal zu bekommen.
Letzter Punkt:
Beim z. B. HM-LC-Sw1-FM,HM-LC-Sw2-FM, HM-ES-PMSw1-Pl und HM-MOD-Re-8
muss
webCmd state
widgetOverride state:uzsuSelectRadio,off,on
verwendet werden.
webCmd control
widgetOverride control:uzsuSelectRadio,off,on
funktioniert nicht. Ist das richtig?
Dankeschön
@aherby: Deine Lists sehen irgendwie seltsam aus. Hier ein Teil eines Lists von einem HM-LC-Sw1PBU-FM (sollte ähnlich sein):
Internals:
CFGFN
DEF NEQ1737176:1
FUUID 6154906b-f33f-3955-afc6-70bcb739188cfe14
IODev ccu1
NAME LI_WZ_Fenster
NR 56
STATE ???
TYPE HMCCUCHN
ccuaddr NEQ1737176:1
ccudevstate active
ccuif BidCos-RF
ccuname LI-WZ-Fenster:1
ccurolectrl SWITCH
ccurolestate SWITCH
Die fett markierten Internals fehlen bei Dir. Außerdem:
control:
chn 1
dpt STATE
Da steht bei Dir "control" alleine.
Nutzt Du die aktuellste Version? Hast Du fhem nach der Installation neu gestartet?
Übrigens: Für Geräte, die automatisch erkannt werden, kannst Du die Attribute statevals und substitute löschen.
@zap:
Kannst du mir mal bitte mit dem HmIP-BSL helfen, da ich es nicht hinbekomme eine Funktion zu schalten über FHEM, in der CCU3 klappt es.
Die Definition vom Device findest du im Dateianhang von https://forum.fhem.de/index.php/topic,107077.msg1172651.html#msg1172651 (https://forum.fhem.de/index.php/topic,107077.msg1172651.html#msg1172651)
Wenn ich in der CCU3 einen kurzen Tastendruck auf den Schaltaktor Anzeige_Buero:4 ausführe, dann lässt sich eine daran angeschlossenen Beleuchtung an/abschalten. Im Event-Monitor erhalte ich für das Anschlaten:
2021-09-30 17:49:28 HMCCUDEV Anzeige_Buero on
2021-09-30 17:49:28 HMCCUDEV Anzeige_Buero 4.STATE: on
2021-09-30 17:49:28 HMCCUDEV Anzeige_Buero rssidevice: -55
2021-09-30 17:49:28 HMCCUDEV Anzeige_Buero rssipeer: -55
2021-09-30 17:49:28 HMCCUDEV Anzeige_Buero hmstate: on
2021-09-30 17:49:29 HMCCUDEV Anzeige_Buero 3.STATE: on
Versuche ich im FHEM über "set Anzeige_Buero on" über das Device das Licht anzuschalten, erhalte ich folgende Meldung:
MCCUDEV: Anzeige_Buero No control channel defined
Ein Ereignis vom Schalter wird in FHEM generiert:
2021-09-30 17:56:31 HMCCUDEV Anzeige_Buero 2.PRESS_SHORT: pressed
Irgendwie komme ich da nicht weiter. Ich verwende HMCCU in der Version 5.0 212691835
Gruß
eurofinder
@eurofinder: Bitte mach ein list von dem Device.
@zap:
Hier das List vom Device:
Internals:
DEF 001A5A498DECB9
FUUID 602c3209-f33f-49d8-da31-97db54ea825a7db2
IODev CCU3
NAME Anzeige_Buero
NR 50
STATE off
TYPE HMCCUDEV
ccuaddr 001A5A498DECB9
ccudevstate active
ccuif HmIP-RF
ccuname Anzeige_Buero
ccusubtype BSL
ccutype HmIP-BSL
firmware 1.0.2
readonly no
READINGS:
2021-09-30 17:28:24 1.PRESS_LONG pressed
2021-09-30 17:33:09 1.PRESS_SHORT pressed
2021-10-01 17:14:51 10.ACTIVITY_STATE STABLE
2021-10-01 17:14:51 10.COLOR black
2021-10-01 17:14:51 10.COLOR_STATUS NORMAL
2021-10-01 17:14:51 10.LEVEL off
2021-10-01 17:14:51 10.LEVEL_STATUS NORMAL
2021-10-01 17:14:51 11.ACTIVITY_STATE UNKNOWN
2021-10-01 17:14:51 11.COLOR red
2021-10-01 17:14:51 11.COLOR_STATUS NORMAL
2021-10-01 17:14:51 11.LEVEL 0
2021-10-01 17:14:51 11.LEVEL_STATUS NORMAL
2021-10-01 17:14:51 12.ACTIVITY_STATE STABLE
2021-10-01 17:14:51 12.COLOR red
2021-10-01 17:14:51 12.COLOR_STATUS NORMAL
2021-10-01 17:14:51 12.LEVEL off
2021-10-01 17:14:51 12.LEVEL_STATUS NORMAL
2021-10-01 17:14:51 13.ACTIVITY_STATE STABLE
2021-10-01 17:14:51 13.COLOR black
2021-10-01 17:14:51 13.COLOR_STATUS NORMAL
2021-10-01 17:14:51 13.LEVEL off
2021-10-01 17:14:51 13.LEVEL_STATUS NORMAL
2021-10-01 17:14:51 14.ACTIVITY_STATE STABLE
2021-10-01 17:14:51 14.COLOR black
2021-10-01 17:14:51 14.COLOR_STATUS NORMAL
2021-10-01 17:14:51 14.LEVEL off
2021-10-01 17:14:51 14.LEVEL_STATUS NORMAL
2021-09-30 17:28:24 2.PRESS_LONG pressed
2021-09-30 17:56:31 2.PRESS_SHORT pressed
2021-10-01 17:14:41 3.STATE off
2021-10-01 17:14:41 4.STATE off
2021-10-01 17:14:41 5.STATE off
2021-10-01 17:14:41 6.STATE off
2021-10-01 17:14:51 7.ACTIVITY_STATE UNKNOWN
2021-10-01 17:14:51 7.COLOR red
2021-10-01 17:14:51 7.COLOR_STATUS NORMAL
2021-10-01 17:14:51 7.LEVEL 0
2021-10-01 17:14:51 7.LEVEL_STATUS NORMAL
2021-10-01 17:14:51 8.ACTIVITY_STATE STABLE
2021-10-01 17:14:51 8.COLOR red
2021-10-01 17:14:51 8.COLOR_STATUS NORMAL
2021-10-01 17:14:51 8.LEVEL off
2021-10-01 17:14:51 8.LEVEL_STATUS NORMAL
2021-10-01 17:14:51 9.ACTIVITY_STATE STABLE
2021-10-01 17:14:51 9.COLOR black
2021-10-01 17:14:51 9.COLOR_STATUS NORMAL
2021-10-01 17:14:51 9.LEVEL off
2021-10-01 17:14:51 9.LEVEL_STATUS NORMAL
2021-09-30 17:08:35 IODev CCU3
2021-10-01 17:15:01 activity alive
2021-09-01 07:31:04 control off
2021-10-01 17:15:01 devstate ok
2021-10-01 17:15:01 hmstate off
2021-10-01 17:15:01 rssidevice -75
2021-10-01 17:15:01 rssipeer -80
2021-10-01 17:14:41 state off
hmccu:
channels 16
detect 2
devspec 001A5A498DECB9
forcedev 0
nodefaults 1
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:KEY_TRANSCEIVER,3:SWITCH_TRANSMITTER,4:SWITCH_VIRTUAL_RECEIVER,5:SWITCH_VIRTUAL_RECEIVER,6:SWITCH_VIRTUAL_RECEIVER,7:DIMMER_TRANSMITTER,8:DIMMER_VIRTUAL_RECEIVER,9:DIMMER_VIRTUAL_RECEIVER,10:DIMMER_VIRTUAL_RECEIVER,11:DIMMER_TRANSMITTER,12:DIMMER_VIRTUAL_RECEIVER,13:DIMMER_VIRTUAL_RECEIVER,14:DIMMER_VIRTUAL_RECEIVER,15:DIMMER_WEEK_PROFILE
semDefaults 0
cmdlist:
get
set on-for-timer on:noArg on-till off:noArg on-for-timer on:noArg on-till off:noArg on-for-timer on:noArg on-till off:noArg up off:noArg on:noArg down up off:noArg on:noArg down up off:noArg on:noArg down up off:noArg on:noArg down up off:noArg on:noArg down up off:noArg on:noArg down
control:
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
NVAL 27.0
ONVAL 27.0
OSVAL 27.0
OVAL 27.0
SVAL 27.0
VAL 27.0
0.CONFIG_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL -75
ONVAL -74
OSVAL -74
OVAL -74
SVAL -75
VAL -75
0.RSSI_PEER:
VALUES:
NVAL -80
ONVAL -64
OSVAL -64
OVAL -64
SVAL -80
VAL -80
0.UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL alive
OVAL 0
SVAL alive
VAL 0
1.PRESS_LONG:
VALUES:
NVAL 1
ONVAL 1
OSVAL pressed
OVAL 1
SVAL pressed
VAL 1
1.PRESS_SHORT:
VALUES:
NVAL 1
ONVAL 1
OSVAL pressed
OVAL 1
SVAL pressed
VAL 1
10.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
10.COLOR:
VALUES:
NVAL 0
ONVAL 0
OSVAL black
OVAL 0
SVAL black
VAL 0
10.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
10.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
10.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
10.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
10.SECTION:
VALUES:
NVAL 4
ONVAL 0
OSVAL 0
OVAL 0
SVAL 4
VAL 4
10.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
11.ACTIVITY_STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL UNKNOWN
OVAL 0
SVAL UNKNOWN
VAL 0
11.COLOR:
VALUES:
NVAL 4
ONVAL 4
OSVAL red
OVAL 4
SVAL red
VAL 4
11.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
11.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0.0
SVAL 0
VAL 0.0
11.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
11.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
11.SECTION_STATUS:
VALUES:
NVAL 1
ONVAL 1
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
12.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
12.COLOR:
VALUES:
NVAL 4
ONVAL 4
OSVAL red
OVAL 4
SVAL red
VAL 4
12.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
12.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
12.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
12.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
12.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
12.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
13.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
13.COLOR:
VALUES:
NVAL 0
ONVAL 0
OSVAL black
OVAL 0
SVAL black
VAL 0
13.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
13.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
13.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
13.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
13.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
13.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
14.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
14.COLOR:
VALUES:
NVAL 0
ONVAL 0
OSVAL black
OVAL 0
SVAL black
VAL 0
14.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
14.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
14.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
14.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
14.SECTION:
VALUES:
NVAL 4
ONVAL 0
OSVAL 0
OVAL 0
SVAL 4
VAL 4
14.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
15.WEEK_PROGRAM_CHANNEL_LOCKS:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
2.PRESS_LONG:
VALUES:
NVAL 1
ONVAL 1
OSVAL pressed
OVAL 1
SVAL pressed
VAL 1
2.PRESS_SHORT:
VALUES:
NVAL 1
ONVAL 1
OSVAL pressed
OVAL 1
SVAL pressed
VAL 1
3.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
3.SECTION_STATUS:
VALUES:
NVAL 1
ONVAL 1
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
3.STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
4.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
4.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
5.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
5.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
5.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
6.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
6.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
6.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
7.ACTIVITY_STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL UNKNOWN
OVAL 0
SVAL UNKNOWN
VAL 0
7.COLOR:
VALUES:
NVAL 4
ONVAL 4
OSVAL red
OVAL 4
SVAL red
VAL 4
7.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0.0
SVAL 0
VAL 0.0
7.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
7.SECTION_STATUS:
VALUES:
NVAL 1
ONVAL 1
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
8.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
8.COLOR:
VALUES:
NVAL 4
ONVAL 4
OSVAL red
OVAL 4
SVAL red
VAL 4
8.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
8.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
8.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
8.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
8.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
8.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
9.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
9.COLOR:
VALUES:
NVAL 0
ONVAL 0
OSVAL black
OVAL 0
SVAL black
VAL 0
9.COLOR_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
9.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
9.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
9.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
9.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
9.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
roleCmds:
get:
set:
down:
channel ?
role DIMMER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=-10
usage down [delta]
subcmd:
000:
args -10
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
scn 000
unit 100%
off:
channel ?
role DIMMER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:0
usage off
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
on:
channel ?
role DIMMER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:100
usage on
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
on-for-timer:
channel ?
role DIMMER_VIRTUAL_RECEIVER
subcount 2
syntax V:ON_TIME:?duration V:LEVEL:100
usage on-for-timer duration
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname duration
partype 2
ps VALUES
scn 000
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 001
unit
on-till:
channel ?
role DIMMER_VIRTUAL_RECEIVER
subcount 2
syntax V:ON_TIME:?time V:LEVEL:100
usage on-till time
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname time
partype 2
ps VALUES
scn 000
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 001
unit
pct:
role DIMMER_VIRTUAL_RECEIVER
syntax 3:V:LEVEL:?level 1:V:ON_TIME:?time=0.0 2:V:RAMP_TIME:?ramp=0.5
subcmd:
000:
args
dpt LEVEL
fnc
max 1.01
min 0.0
parname level
partype 2
ps VALUES
scn 003
unit 100%
up:
channel ?
role DIMMER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=+10
usage up [delta]
subcmd:
000:
args +10
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
scn 000
unit 100%
state:
chn 4
dpt STATE
Attributes:
IODev CCU3
ccureadingfilter (LEVEL|STATE|COLOR|PRESS)
ccuscaleval LEVEL:0:1:0:100
event-on-change-reading .*
event-on-update-reading ^[1-2]\.PRESS.*
room Homematic
statedatapoint 4.STATE
substitute STATE!(0|false):off,(1|true):on;COLOR!0:black,1:blue,2:green,3:turquoise,4:red,5:purple,6:yellow,7:white
Gruß
eurofinder
Hallo zap,
bin jetzt auch schon mal dabei mich vorzubereiten und einzuarbeiten was den Umstieg auf HMCCU 5.0 angeht.
Ich teste in einem parallelem System und bin jetzt bei meinem mp3-Funk-Gong HM-OU-CFM-TW angekommen.
Das create liefert:
Results of create command:
Not detected CCU devices:
HM-OU-CFM-TW = OEQ0143105 [HM-OU-CFM-TW]
Im meinem Haupt-System unter der Version 4.3.025 läuft der mp3-Funk-Gong HM-OU-CFM-TW seit langem einwandfrei!
Was mach ich falsch? Oder wird das Teil nicht unterstützt? (Was sehr schade wäre!)
Internals:
.FhemMetaInternals 1
.eventMapCmd led-on:noArg led-off:noArg sound-on:noArg sound-off:noArg
DEF OEQ0143105
FUUID 5e11c041-f33f-17d1-0cd0-7aa89e95eeef3206
FVERSION 88_HMCCUDEV.pm:v4.3.12-s21452/2020-03-19
IODev d_ccu
NAME HM_OU_CFM_TW
NR 510
STATE ledOff
TYPE HMCCUDEV
ccuaddr OEQ0143105
ccudevstate active
ccuif BidCos-RF
ccuname HM-OU-CFM-TW
ccutype HM-OU-CFM-TW
channels 3
firmware 1.3
statevals devstate|on|off
.attraggr:
.attrminint:
READINGS:
2021-10-01 06:22:43 1.STATE ledOff
2021-09-30 18:30:39 2.STATE ledOff
2021-09-24 06:36:16 IODev d_ccu
2021-09-25 17:53:55 activity 0
2021-09-24 06:36:34 battery false
2021-10-01 06:22:43 control ledOff
2021-10-01 06:22:43 hmstate ledOff
2021-10-01 06:22:43 state ledOff
hmccu:
devspec OEQ0143105
dp:
0.AES_KEY:
OVAL 0
VAL 0
0.CONFIG_PENDING:
OVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
OVAL false
VAL false
0.DUTYCYCLE:
OVAL false
VAL false
0.LOWBAT:
OSVAL false
OVAL false
SVAL false
VAL false
0.RSSI_DEVICE:
OVAL 1
VAL 1
0.RSSI_PEER:
OVAL 1
VAL 1
0.STICKY_UNREACH:
OVAL 1
VAL 1
0.UNREACH:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.UPDATE_PENDING:
OVAL false
VAL false
1.INHIBIT:
OVAL false
VAL false
1.STATE:
OSVAL ledOn
OVAL 1
SVAL ledOff
VAL 0
1.WORKING:
OVAL 1
VAL 0
2.INHIBIT:
OVAL false
VAL false
2.STATE:
OSVAL ledOn
OVAL 1
SVAL ledOff
VAL 0
2.WORKING:
OVAL 1
VAL 0
Attributes:
DbLogExclude .*
IODev d_ccu
alias MP3-Funk-Gong
ccureadingfilter STATE
eventMap /datapoint 1.STATE 1:led-on/datapoint 1.STATE 0:led-off/datapoint 2.STATE 1:sound-on/datapoint 2.STATE 0:sound-off
room Haus->Homematic,Schlafzimmer
statedatapoint 1.STATE
statevals on:true,off:false
substitute STATE!(0|false):ledOff,(1|true):ledOn;2.STATE!(0|false):soundOff,(1|true):soundOn
Vielleicht hast du ja einen Tip für mich!
Viele Grüße
@eurofinder: der HmIP-BSL ist echt ein spannendes Gerät. Das "Problem" ist: Es gibt 3 Rollen, die alle von HMCCU unterstützt werden: KEY, SWITCH und DIMMER.
Da DIMMER HMCCU-intern die höchste Prio hat, erkennt HMCCU das Gerät als Dimmer und legt entsprechend Befehle wie pct, up und down an. Und eben auch on und off, die jedoch einfach das Level vom Dimmer (vermutlich die Tastenbeleuchtung?) auf 0 bzw. 100 Prozent setzen.
Du musst HMCCU sagen, welchen Kanal es zur Steuerung verwenden soll. Wenn Du das Gerät als Schalter nutzen möchtest:
attr controldatapoint 4.STATE
Mit diesem Attribut sollte HMCCU automatisch die set Befehle umbauen und dann auch auf set on und set off korrekt reagieren.
Du könntest mal noch folgenden Befehl ausführen. Das würde mir helfen, solche multifunktionalen Geräte besser zu unterstützen:
get CCU3 detectDev Anzeige_Buero
@Reinschki: bitte für in Deiner 5.0er Umgebung mal folgenden Befehl aus:
get <iodev> deviceInfo HM-OU-CFM-TW
Möglicherweise wird die Rolle dieses Gerätes tatsächlich noch nicht von "get createDev" unterstützt. Grundsätzlich sollte in diesem Fall die Übernahme der manuellen Konfiguration von der Version 4.3 (also wie in Deinem list) funktionieren.
Zitat von: zap am 01 Oktober 2021, 19:07:10
@Reinschki: bitte für in Deiner 5.0er Umgebung mal folgenden Befehl aus:
get <iodev> deviceInfo HM-OU-CFM-TW
Möglicherweise wird die Rolle dieses Gerätes tatsächlich noch nicht von "get createDev" unterstützt. Grundsätzlich sollte in diesem Fall die Übernahme der manuellen Konfiguration von der Version 4.3 (also wie in Deinem list) funktionieren.
Danach wurde per create auch kein Device angelegt!
Dann habe ich per "Raw definition" manuell übertragen und dabei diesen Hinweis erhalten:
HMCCUDEV [HM_OU_CFM_TW] Device type not known by HMCCU. Please set control and/or state channel with attributes controldatapoint and statedatapointDas Teil funktioniert aber!
Besten Dank!
Gemeint war, dass Du mir die Ausgabe von get deviceinfo schickst oder hier postest ;)
@zap:
Ok, danke für die Klarstellung. Werde ich probieren.
Hier ergänzend noch die Ausgabe von get CCU3 detectDev Anzeige_Buero
{
level=2,
uniqueStateRoleCount=5,
stateRoleCount=14,
defMod=HMCCUCHN,
defAdd=001A5A498DECB9,
defCDP=,
defSCh=-1,
controlRoleCount=9,
defCCh=-1,
uniqueControlRoleCount=2,
defSDP=,
controlRole={
8={
role=DIMMER_VIRTUAL_RECEIVER,
datapoint=LEVEL,
priority=2
},
5={
datapoint=STATE,
role=SWITCH_VIRTUAL_RECEIVER,
priority=2
},
6={
priority=2,
role=SWITCH_VIRTUAL_RECEIVER,
datapoint=STATE
},
12={
datapoint=LEVEL,
role=DIMMER_VIRTUAL_RECEIVER,
priority=2
},
4={
priority=2,
datapoint=STATE,
role=SWITCH_VIRTUAL_RECEIVER
},
14={
datapoint=LEVEL,
role=DIMMER_VIRTUAL_RECEIVER,
priority=2
},
13={
priority=2,
role=DIMMER_VIRTUAL_RECEIVER,
datapoint=LEVEL
},
10={
priority=2,
datapoint=LEVEL,
role=DIMMER_VIRTUAL_RECEIVER
},
9={
role=DIMMER_VIRTUAL_RECEIVER,
datapoint=LEVEL,
priority=2
}
},
stateRole={
6={
priority=2,
datapoint=STATE,
role=SWITCH_VIRTUAL_RECEIVER
},
3={
datapoint=STATE,
role=SWITCH_TRANSMITTER,
priority=1
},
5={
role=SWITCH_VIRTUAL_RECEIVER,
datapoint=STATE,
priority=2
},
8={
priority=2,
datapoint=LEVEL,
role=DIMMER_VIRTUAL_RECEIVER
},
4={
role=SWITCH_VIRTUAL_RECEIVER,
datapoint=STATE,
priority=2
},
1={
role=KEY_TRANSCEIVER,
datapoint=PRESS_SHORT,
priority=1
},
14={
priority=2,
role=DIMMER_VIRTUAL_RECEIVER,
datapoint=LEVEL
},
13={
datapoint=LEVEL,
role=DIMMER_VIRTUAL_RECEIVER,
priority=2
},
11={
role=DIMMER_TRANSMITTER,
datapoint=LEVEL,
priority=1
},
12={
role=DIMMER_VIRTUAL_RECEIVER,
datapoint=LEVEL,
priority=2
},
9={
priority=2,
role=DIMMER_VIRTUAL_RECEIVER,
datapoint=LEVEL
},
7={
priority=1,
role=DIMMER_TRANSMITTER,
datapoint=LEVEL
},
2={
priority=1,
datapoint=PRESS_SHORT,
role=KEY_TRANSCEIVER
},
10={
priority=2,
datapoint=LEVEL,
role=DIMMER_VIRTUAL_RECEIVER
}
}
}
Gruß
eurofinder
Zitat von: zap am 29 September 2021, 18:23:52
@aherby: Deine Lists sehen irgendwie seltsam aus. Hier ein Teil eines Lists von einem HM-LC-Sw1PBU-FM (sollte ähnlich sein):
Internals:
...
ccuname LI-WZ-Fenster:1
ccurolectrl SWITCH
ccurolestate SWITCH
Die fett markierten Internals fehlen bei Dir. Außerdem:
Nutzt Du die aktuellste Version? Hast Du fhem nach der Installation neu gestartet?
Übrigens: Für Geräte, die automatisch erkannt werden, kannst Du die Attribute statevals und substitute löschen.
Guten Morgen / Tag Zap,
ich weiß auch nicht warum meine Lists komisch aussehen.
Aber Ja nutze die neuste Version
von HMCCU
Zitatversion 5.0 212691835
und auch mehrfach neu gestartet!
Daher habe ich folgende Geräte mal gelöscht:
Nun ist
set "Gerätename" togglewieder möglich.
Bedeutet dies ich muss alle x Schalter vom Typ
HM-PB-6-WM55auch löschen oder liegt hier der Fehler an einer anderen Stelle?
Dankeschön
Zitat von: zap am 01 Oktober 2021, 21:14:01
Gemeint war, dass Du mir die Ausgabe von get deviceinfo schickst oder hier postest ;)
Ach so...
Device channels and datapoints
DEV HM-OU-CFM-TW OEQ0143105 interface=BidCos-RF type=HM-OU-CFM-TW
CHN OEQ0143105:0 HM-OU-CFM-TW:0
0.UNREACH = false {b} [RE]
0.STICKY_UNREACH = true {b} [RWE]
0.CONFIG_PENDING = false {b} [RE]
0.LOWBAT = false {b} [RE]
0.DUTYCYCLE = false {b} [RE]
0.RSSI_DEVICE = 1 {n} [RE]
0.RSSI_PEER = 1 {n} [RE]
0.DEVICE_IN_BOOTLOADER = false {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
0.AES_KEY = 0 {n} [R]
CHN OEQ0143105:1 HM-OU-CFM-TW:1
1.STATE = false {b} [RWE]
1.ON_TIME = {f} [W]
1.INHIBIT = false {b} [RWE]
1.SUBMIT = {s} [W]
1.INSTALL_TEST = {b} [W]
1.WORKING = false {b} [RE]
CHN OEQ0143105:2 HM-OU-CFM-TW:2
2.STATE = false {b} [RWE]
2.ON_TIME = {f} [W]
2.INHIBIT = false {b} [RWE]
2.SUBMIT = {s} [W]
2.INSTALL_TEST = {b} [W]
2.WORKING = false {b} [RE]
Device detection:
No state datapoint detected
No control datapoint detected
Failed to detect device settings. Device must be configured manually.
Current state datapoint = .
Current control datapoint = .
Device description
Device OEQ0143105 HM-OU-CFM-TW [HM-OU-CFM-TW]
CHILDREN: OEQ0143105:0,OEQ0143105:1,OEQ0143105:2
FIRMWARE: 1.3
FLAGS: Visible
INTERFACE: QEQ1288421
PARAMSETS: MASTER
RF_ADDRESS: 5592637
ROAMING: 1
RX_MODE: BURST
UPDATABLE: 1
Channel OEQ0143105:0 HM-OU-CFM-TW:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: OEQ0143105
PARENT_TYPE: HM-OU-CFM-TW
Channel OEQ0143105:1 HM-OU-CFM-TW:1 [SIGNAL_LED]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: OEQ0143105
PARENT_TYPE: HM-OU-CFM-TW
Channel OEQ0143105:2 HM-OU-CFM-TW:2 [SIGNAL_CHIME]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: OEQ0143105
PARENT_TYPE: HM-OU-CFM-TW
Nabend zusammen,
so nun habe ich es endlich geschafft mein
HM-LC-RGBW-WMeinzubauen.
leider kann man dieses HM-Gerät nur mittels HMCCUCHN definieren.
Besteht noch die Chance dies auch bei HMCUUDEV ?
Aus meiner Sicht ist die getrennte Steuerung von
ungünstig.
Internals:
DEF REQ1xxxxx7:1
FUUID 6158979d-
IODev d_ccu
NAME RGB_Flur
NR 857
STATE 40
TYPE HMCCUCHN
ccuaddr REQ1xxxxx7:1
ccudevstate active
ccuif BidCos-RF
ccuname HM-LC-RGBW-WM REQ1xxxxx7:1
ccurolectrl DIMMER
ccurolestate DIMMER
ccusubtype HM-LC-RGBW-WM
ccutype HM-LC-RGBW-WM
firmware 1.0
readonly no
READINGS:
2021-10-02 20:14:32 DIRECTION stop
2021-10-02 19:35:45 INHIBIT unlocked
2021-10-02 19:35:17 IODev d_ccu
2021-10-02 20:14:32 LEVEL 40
2021-10-02 20:14:32 WORKING false
2021-10-02 20:14:32 activity alive
2021-10-02 20:14:32 battery ok
2021-10-02 20:14:32 control 40
2021-10-02 20:14:32 devstate stickyUnreach
2021-10-02 20:14:32 hmstate 40
2021-10-02 20:14:32 pct 40
2021-10-02 20:14:32 rssidevice -255
2021-10-02 20:14:32 rssipeer -255
2021-10-02 20:14:32 sign off
2021-10-02 20:14:32 state 40
hmccu:
channels 1
detect 1
devspec REQ1xxxxx7:1
nodefaults 1
role 1:DIMMER
semDefaults 0
cmdlist:
get
set down on-for-timer pct up on-till stop:noArg off:noArg on:noArg toggle:noArg
control:
chn 1
dpt LEVEL
dp:
0.AES_KEY:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.DUTYCYCLE:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.LOWBAT:
VALUES:
NVAL false
ONVAL false
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
VALUES:
NVAL -255
ONVAL -255
OSVAL -255
OVAL 1
SVAL -255
VAL 1
0.RSSI_PEER:
VALUES:
NVAL -255
ONVAL -255
OSVAL -255
OVAL 1
SVAL -255
VAL 1
0.STICKY_UNREACH:
VALUES:
NVAL true
ONVAL true
OSVAL true
OVAL true
SVAL true
VAL true
0.UNREACH:
VALUES:
NVAL false
ONVAL false
OSVAL alive
OVAL false
SVAL alive
VAL false
0.UPDATE_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
1.DIRECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL stop
OVAL 0
SVAL stop
VAL 0
1.INHIBIT:
VALUES:
NVAL false
ONVAL false
OSVAL unlocked
OVAL false
SVAL unlocked
VAL false
1.LEVEL:
VALUES:
NVAL 40
ONVAL 30.5
OSVAL 30
OVAL 0.305000
SVAL 40
VAL 0.400000
1.WORKING:
VALUES:
NVAL 0
ONVAL 1
OSVAL true
OVAL 1
SVAL false
VAL 0
roleCmds:
get:
set:
down:
channel 1
role DIMMER
subcount 1
syntax V:LEVEL:?delta=-10
usage down [delta]
subcmd:
000:
args -10
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname delta
partype 2
ps VALUES
scn 000
unit 100%
off:
channel 1
role DIMMER
subcount 1
syntax V:LEVEL:0
usage off
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
on:
channel 1
role DIMMER
subcount 1
syntax V:LEVEL:100
usage on
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
on-for-timer:
channel 1
role DIMMER
subcount 2
syntax V:ON_TIME:?duration V:LEVEL:100
usage on-for-timer duration
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname duration
partype 2
ps VALUES
scn 000
unit s
001:
args 100
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
scn 001
unit 100%
on-till:
channel 1
role DIMMER
subcount 2
syntax V:ON_TIME:?time V:LEVEL:100
usage on-till time
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname time
partype 2
ps VALUES
scn 000
unit s
001:
args 100
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
scn 001
unit 100%
pct:
channel 1
role DIMMER
subcount 3
syntax 3:V:LEVEL:?level 1:V:ON_TIME:?time=0.0 2:V:RAMP_TIME:?ramp=0.5
usage pct level [time] [ramp]
subcmd:
000:
args
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname level
partype 2
ps VALUES
scn 003
unit 100%
001:
args 0.0
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname time
partype 2
ps VALUES
scn 001
unit s
002:
args 0.5
dpt RAMP_TIME
fnc
max 85825945.600000
min 0.000000
parname ramp
partype 2
ps VALUES
scn 002
unit s
stop:
channel 1
role DIMMER
subcount 1
syntax V:RAMP_STOP:1
usage stop
subcmd:
000:
args 1
dpt RAMP_STOP
fnc
max 1
min 0
parname RAMP_STOP
partype 3
ps VALUES
scn 000
unit
up:
channel 1
role DIMMER
subcount 1
syntax V:LEVEL:?delta=+10
usage up [delta]
subcmd:
000:
args +10
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname delta
partype 2
ps VALUES
scn 000
unit 100%
state:
chn 1
dpt LEVEL
Attributes:
cmdIcon on:general_an off:general_aus
group Beleuchtung
room Flur,Homematic
substexcl pct
userattr room_map structexclude
webCmd pct
widgetOverride pct:slider,0,10,100
Internals:
CFGFN
DEF REQ1xxxxx7:2
FUUID 61589898-
IODev d_ccu
NAME RGB_Flur_Farbe
NR 875
STATE ???
TYPE HMCCUCHN
ccuaddr REQ1xxxxx7:2
ccudevstate active
ccuif BidCos-RF
ccuname HM-LC-RGBW-WM REQ1xxxxx7:2
ccusubtype HM-LC-RGBW-WM
ccutype HM-LC-RGBW-WM
firmware 1.0
readonly no
READINGS:
2021-10-02 19:40:06 COLOR 95
2021-10-02 19:37:57 INHIBIT unlocked
2021-10-02 19:36:24 IODev d_ccu
2021-10-02 20:14:32 activity alive
2021-10-02 20:14:32 battery ok
2021-10-02 20:14:32 devstate ok
2021-10-02 20:14:32 rssidevice N/A
2021-10-02 20:14:32 rssipeer -54
2021-10-02 20:14:32 sign off
hmccu:
channels 1
detect 0
devspec REQ1xxxxx7:2
nodefaults 0
role 2:RGBW_COLOR
semDefaults 0
cmdlist:
control:
dp:
0.AES_KEY:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DEVICE_IN_BOOTLOADER:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTYCYCLE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.LOWBAT:
VALUES:
NVAL 0
ONVAL 0
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL N/A
ONVAL N/A
OSVAL N/A
OVAL -65535
SVAL N/A
VAL -65535
0.RSSI_PEER:
VALUES:
NVAL -54
ONVAL -54
OSVAL -54
OVAL -54
SVAL -54
VAL -54
0.STICKY_UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
2.AES_ACTIVE:
MASTER:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.COLOR:
VALUES:
NVAL 95
ONVAL 30
OSVAL 30
OVAL 30
SVAL 95
VAL 95
2.INHIBIT:
VALUES:
NVAL 0
ONVAL 0
OSVAL unlocked
OVAL 0
SVAL unlocked
VAL 0
2.LONG_ACT_HSV_COLOR_VALUE:
LINK.REQ1xxxxx7:2:
NVAL 254
ONVAL 254
OSVAL 254
OVAL 254
SVAL 254
VAL 254
VALUES:
2.SHORT_ACT_HSV_COLOR_VALUE:
LINK.REQ1xxxxx7:2:
NVAL 253
ONVAL 253
OSVAL 253
OVAL 253
SVAL 253
VAL 253
VALUES:
2.WHITE_ADJUSTMENT_VALUE_BLUE:
MASTER:
NVAL 100
ONVAL 100
OSVAL 100
OVAL 100
SVAL 100
VAL 100
VALUES:
2.WHITE_ADJUSTMENT_VALUE_GREEN:
MASTER:
NVAL 100
ONVAL 100
OSVAL 100
OVAL 100
SVAL 100
VAL 100
VALUES:
2.WHITE_ADJUSTMENT_VALUE_RED:
MASTER:
NVAL 100
ONVAL 100
OSVAL 100
OVAL 100
SVAL 100
VAL 100
VALUES:
d.INTERNAL_KEYS_VISIBLE:
MASTER:
NVAL 1
ONVAL 1
OSVAL true
OVAL 1
SVAL true
VAL 1
VALUES:
d.LOCAL_RESET_DISABLE:
MASTER:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
roleCmds:
get:
set:
state:
Attributes:
group Beleuchtung
room FlurOder wie stelle ich hier die Farbe ein da es keinen
STATE ???gibt
@aherby:
Bitte führe mal folgende Befehle aus und poste die Ausgabe. Damit kann ich dann die Unterstützung der Rolle vom 2. Kanal einbauen. Dann wird ein "get createDev" ein HMCCUDEV anlegen:
get d_ccu deviceInfo REQxxxx
get d_ccu paramsetDesc REQxxxx
Inzwischen kannst Du einfach ein "define" mit der Option forceDev verwenden, um ein HMCCUDEV anzulegen:
define myDev HMCCUDEV REQxxxx forceDev
Servus,
der
HM-LC-RGBW-WMhat 3 Kanäle
- dimmen / Helligkeit
- RGB / Farbwert
- Programm
get d_ccu deviceInfo REQxx bringt:
<html>Device channels and datapoints
DEV Flur_RGB_HM_REQ1xxxxx7 REQ1xxxxx7 interface=BidCos-RF type=HM-LC-RGBW-WM
CHN REQ1xxxxx7:0 Flur_RGB_HM_REQ1xxxxx7:0
0.UNREACH = false {b} [RE]
0.STICKY_UNREACH = true {b} [RWE]
0.CONFIG_PENDING = false {b} [RE]
0.LOWBAT = false {b} [RE]
0.DUTYCYCLE = false {b} [RE]
0.RSSI_DEVICE = 1 {n} [RE]
0.RSSI_PEER = 1 {n} [RE]
0.DEVICE_IN_BOOTLOADER = false {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
0.AES_KEY = 0 {n} [R]
CHN REQ1xxxxx7:1 HM-LC-RGBW-WM REQ1xxxxx7:1
1.LEVEL = 0.000000 {a} [RWE]
1.OLD_LEVEL = {b} [W]
1.RAMP_TIME = {f} [W]
1.ON_TIME = {f} [W]
1.RAMP_STOP = {b} [W]
1.INHIBIT = false {b} [RWE]
1.DIRECTION = 0 {i} [RE]
1.INSTALL_TEST = {b} [W]
1.WORKING = false {b} [RE]
CHN REQ1xxxxx7:2 HM-LC-RGBW-WM REQ1xxxxx7:2
2.COLOR = 200 {i} [RWE]
2.USER_COLOR = {s} [W]
2.ON_TIME = {f} [W]
2.RAMP_TIME = {f} [W]
2.INHIBIT = false {b} [RWE]
2.ACT_BRIGHTNESS = {i} [W]
2.ACT_BRIGHTNESS_STORE = {i} [W]
2.ACT_HSV_COLOR_VALUE = {i} [W]
2.ACT_HSV_COLOR_VALUE_STORE = {i} [W]
2.ON_TIME_STORE = {f} [W]
2.RAMP_TIME_STORE = {f} [W]
CHN REQ1xxxxx7:3 HM-LC-RGBW-WM REQ1xxxxx7:3
3.PROGRAM = 0 {i} [RWE]
3.USER_PROGRAM = {s} [W]
3.ON_TIME = 0.000000 {f} [RW]
3.RAMP_TIME = 0.500000 {f} [RW]
3.INHIBIT = false {b} [RWE]
3.ACT_BRIGHTNESS = 0 {i} [RW]
3.ACT_BRIGHTNESS_STORE = {i} [W]
3.ACT_COLOR_PROGRAM_STORE = {i} [W]
3.ACT_MAX_BOARDER = 0 {i} [RW]
3.ACT_MAX_BORDER_STORE = {i} [W]
3.ACT_MIN_BOARDER = 0 {i} [RW]
3.ACT_MIN_BORDER_STORE = {i} [W]
3.ON_TIME_STORE = {f} [W]
3.RAMP_TIME_STORE = {f} [W]
Device detection:
StateDatapoint = 1.LEVEL [DIMMER]
ControlDatapoint = 1.LEVEL [DIMMER]
Recommended module for device definition: HMCCUCHN
Current state datapoint = .
Current control datapoint = .
Device description
Device REQ1xxxxx7 Flur_RGB_HM_REQ1xxxxx7 [HM-LC-RGBW-WM]
CHILDREN: REQ1xxxxx7:0,REQ1xxxxx7:1,REQ1xxxxx7:2,REQ1xxxxx7:3
FIRMWARE: 1.0
FLAGS: Visible
INTERFACE: PEQ1946433
PARAMSETS: MASTER
RF_ADDRESS: 7498929
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG
UPDATABLE: 1
Channel REQ1xxxxx7:0 Flur_RGB_HM_REQ1xxxxx7:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: REQ1xxxxx7
PARENT_TYPE: HM-LC-RGBW-WM
Channel REQ1xxxxx7:1 HM-LC-RGBW-WM REQ1xxxxx7:1 [DIMMER] known
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: REQ1xxxxx7
PARENT_TYPE: HM-LC-RGBW-WM
Channel REQ1xxxxx7:2 HM-LC-RGBW-WM REQ1xxxxx7:2 [RGBW_COLOR]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: REQ1xxxxx7
PARENT_TYPE: HM-LC-RGBW-WM
Channel REQ1xxxxx7:3 HM-LC-RGBW-WM REQ1xxxxx7:3 [RGBW_AUTOMATIC]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: REQ1xxxxx7
PARENT_TYPE: HM-LC-RGBW-WM
get d_ccu paramsetDesc REQxxxdieses:
Device
Paramset MASTER
INTERNAL_KEYS_VISIBLE: BOOL [R,W] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
LOCAL_RESET_DISABLE: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
Channel 0
Paramset VALUES
AES_KEY: INTEGER [R] [] RANGE=0...127 DFLT=0
CONFIG_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
DEVICE_IN_BOOTLOADER: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
DUTYCYCLE: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
LOWBAT: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
RSSI_DEVICE: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648...2147483647 DFLT=0
RSSI_PEER: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648...2147483647 DFLT=0
STICKY_UNREACH: BOOL [R,W,E] [Sticky,Internal] RANGE=0...1 DFLT=0
UNREACH: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
UPDATE_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
Channel 1
Paramset LINK
LONG_ACTION_TYPE: ENUM [R,W] [Visible,Sticky] RANGE=0...8 DFLT=0 VALUES=INACTIVE,JUMP_TO_TARGET,TOGGLE_TO_COUNTER,TOGGLE_INVERS_TO_COUNTER,UPDIM,DOWNDIM,TOGGLEDIM,TOGGLEDIM_TO_COUNTER,TOGGLEDIM_INVERS_TO_COUNTER
LONG_COND_VALUE_HI: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=100
LONG_COND_VALUE_LO: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=50
LONG_CT_OFF: ENUM [R,W] [Visible,Sticky] RANGE=0...5 DFLT=0 VALUES=X GE COND_VALUE_LO,X GE COND_VALUE_HI,X LT COND_VALUE_LO,X LT COND_VALUE_HI,COND_VALUE_LO LE X LT COND_VALUE_HI,X LT COND_VALUE_LO OR X GE COND_VALUE_HI
LONG_CT_OFFDELAY: ENUM [R,W] [Visible,Sticky] RANGE=0...5 DFLT=0 VALUES=X GE COND_VALUE_LO,X GE COND_VALUE_HI,X LT COND_VALUE_LO,X LT COND_VALUE_HI,COND_VALUE_LO LE X LT COND_VALUE_HI,X LT COND_VALUE_LO OR X GE COND_VALUE_HI
LONG_CT_ON: ENUM [R,W] [Visible,Sticky] RANGE=0...5 DFLT=0 VALUES=X GE COND_VALUE_LO,X GE COND_VALUE_HI,X LT COND_VALUE_LO,X LT COND_VALUE_HI,COND_VALUE_LO LE X LT COND_VALUE_HI,X LT COND_VALUE_LO OR X GE COND_VALUE_HI
LONG_CT_ONDELAY: ENUM [R,W] [Visible,Sticky] RANGE=0...5 DFLT=0 VALUES=X GE COND_VALUE_LO,X GE COND_VALUE_HI,X LT COND_VALUE_LO,X LT COND_VALUE_HI,COND_VALUE_LO LE X LT COND_VALUE_HI,X LT COND_VALUE_LO OR X GE COND_VALUE_HI
LONG_CT_RAMPOFF: ENUM [R,W] [Visible,Sticky] RANGE=0...5 DFLT=0 VALUES=X GE COND_VALUE_LO,X GE COND_VALUE_HI,X LT COND_VALUE_LO,X LT COND_VALUE_HI,COND_VALUE_LO LE X LT COND_VALUE_HI,X LT COND_VALUE_LO OR X GE COND_VALUE_HI
LONG_CT_RAMPON: ENUM [R,W] [Visible,Sticky] RANGE=0...5 DFLT=0 VALUES=X GE COND_VALUE_LO,X GE COND_VALUE_HI,X LT COND_VALUE_LO,X LT COND_VALUE_HI,COND_VALUE_LO LE X LT COND_VALUE_HI,X LT COND_VALUE_LO OR X GE COND_VALUE_HI
LONG_DIM_MAX_LEVEL: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=1 UNIT=100%
LONG_DIM_MIN_LEVEL: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 UNIT=100%
LONG_DIM_STEP: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 UNIT=100%
LONG_JT_OFF: ENUM [R,W] [Visible,Sticky] RANGE=0...6 DFLT=1 VALUES=NO_JUMP_IGNORE_COMMAND,ONDELAY,RAMPON,ON,OFFDELAY,RAMPOFF,OFF
LONG_JT_OFFDELAY: ENUM [R,W] [Visible,Sticky] RANGE=0...6 DFLT=1 VALUES=NO_JUMP_IGNORE_COMMAND,ONDELAY,RAMPON,ON,OFFDELAY,RAMPOFF,OFF
LONG_JT_ON: ENUM [R,W] [Visible,Sticky] RANGE=0...6 DFLT=1 VALUES=NO_JUMP_IGNORE_COMMAND,ONDELAY,RAMPON,ON,OFFDELAY,RAMPOFF,OFF
LONG_JT_ONDELAY: ENUM [R,W] [Visible,Sticky] RANGE=0...6 DFLT=1 VALUES=NO_JUMP_IGNORE_COMMAND,ONDELAY,RAMPON,ON,OFFDELAY,RAMPOFF,OFF
LONG_JT_RAMPOFF: ENUM [R,W] [Visible,Sticky] RANGE=0...6 DFLT=1 VALUES=NO_JUMP_IGNORE_COMMAND,ONDELAY,RAMPON,ON,OFFDELAY,RAMPOFF,OFF
LONG_JT_RAMPON: ENUM [R,W] [Visible,Sticky] RANGE=0...6 DFLT=1 VALUES=NO_JUMP_IGNORE_COMMAND,ONDELAY,RAMPON,ON,OFFDELAY,RAMPOFF,OFF
LONG_MULTIEXECUTE: ENUM [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 VALUES=OFF,ON
LONG_OFFDELAY_BLINK: ENUM [R,W] [Visible,Sticky] RANGE=0...1 DFLT=1 VALUES=OFF,ON
LONG_OFFDELAY_NEWTIME: FLOAT [R,W] [Visible,Sticky] RANGE=0.1...25.6 DFLT=0.5 UNIT=s
LONG_OFFDELAY_OLDTIME: FLOAT [R,W] [Visible,Sticky] RANGE=0.1...25.6 DFLT=0.5 UNIT=s
LONG_OFFDELAY_STEP: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0.05 UNIT=100%
LONG_OFFDELAY_TIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...111600 DFLT=0 UNIT=s
LONG_OFF_LEVEL: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 UNIT=100%
LONG_OFF_TIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...108000 DFLT=111600 UNIT=s
LONG_OFF_TIME_MODE: ENUM [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 VALUES=ABSOLUTE,MINIMAL
LONG_ONDELAY_MODE: ENUM [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 VALUES=SET_TO_OFF,NO_CHANGE
LONG_ONDELAY_TIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...111600 DFLT=0 UNIT=s
LONG_ON_LEVEL: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=1 UNIT=100%
LONG_ON_LEVEL_PRIO: ENUM [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 VALUES=HIGH,LOW
LONG_ON_MIN_LEVEL: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0.1 UNIT=100%
LONG_ON_TIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...108000 DFLT=111600 UNIT=s
LONG_ON_TIME_MODE: ENUM [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 VALUES=ABSOLUTE,MINIMAL
LONG_RAMPOFF_TIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...111600 DFLT=0 UNIT=s
LONG_RAMPON_TIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...111600 DFLT=0 UNIT=s
LONG_RAMP_START_STEP: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0.05 UNIT=100%
SHORT_ACTION_TYPE: ENUM [R,W] [Visible,Sticky] RANGE=0...8 DFLT=0 VALUES=INACTIVE,JUMP_TO_TARGET,TOGGLE_TO_COUNTER,TOGGLE_INVERS_TO_COUNTER,UPDIM,DOWNDIM,TOGGLEDIM,TOGGLEDIM_TO_COUNTER,TOGGLEDIM_INVERS_TO_COUNTER
SHORT_COND_VALUE_HI: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=100
SHORT_COND_VALUE_LO: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=50
SHORT_CT_OFF: ENUM [R,W] [Visible,Sticky] RANGE=0...5 DFLT=0 VALUES=X GE COND_VALUE_LO,X GE COND_VALUE_HI,X LT COND_VALUE_LO,X LT COND_VALUE_HI,COND_VALUE_LO LE X LT COND_VALUE_HI,X LT COND_VALUE_LO OR X GE COND_VALUE_HI
SHORT_CT_OFFDELAY: ENUM [R,W] [Visible,Sticky] RANGE=0...5 DFLT=0 VALUES=X GE COND_VALUE_LO,X GE COND_VALUE_HI,X LT COND_VALUE_LO,X LT COND_VALUE_HI,COND_VALUE_LO LE X LT COND_VALUE_HI,X LT COND_VALUE_LO OR X GE COND_VALUE_HI
SHORT_CT_ON: ENUM [R,W] [Visible,Sticky] RANGE=0...5 DFLT=0 VALUES=X GE COND_VALUE_LO,X GE COND_VALUE_HI,X LT COND_VALUE_LO,X LT COND_VALUE_HI,COND_VALUE_LO LE X LT COND_VALUE_HI,X LT COND_VALUE_LO OR X GE COND_VALUE_HI
SHORT_CT_ONDELAY: ENUM [R,W] [Visible,Sticky] RANGE=0...5 DFLT=0 VALUES=X GE COND_VALUE_LO,X GE COND_VALUE_HI,X LT COND_VALUE_LO,X LT COND_VALUE_HI,COND_VALUE_LO LE X LT COND_VALUE_HI,X LT COND_VALUE_LO OR X GE COND_VALUE_HI
SHORT_CT_RAMPOFF: ENUM [R,W] [Visible,Sticky] RANGE=0...5 DFLT=0 VALUES=X GE COND_VALUE_LO,X GE COND_VALUE_HI,X LT COND_VALUE_LO,X LT COND_VALUE_HI,COND_VALUE_LO LE X LT COND_VALUE_HI,X LT COND_VALUE_LO OR X GE COND_VALUE_HI
SHORT_CT_RAMPON: ENUM [R,W] [Visible,Sticky] RANGE=0...5 DFLT=0 VALUES=X GE COND_VALUE_LO,X GE COND_VALUE_HI,X LT COND_VALUE_LO,X LT COND_VALUE_HI,COND_VALUE_LO LE X LT COND_VALUE_HI,X LT COND_VALUE_LO OR X GE COND_VALUE_HI
SHORT_DIM_MAX_LEVEL: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=1 UNIT=100%
SHORT_DIM_MIN_LEVEL: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 UNIT=100%
SHORT_DIM_STEP: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 UNIT=100%
SHORT_JT_OFF: ENUM [R,W] [Visible,Sticky] RANGE=0...6 DFLT=1 VALUES=NO_JUMP_IGNORE_COMMAND,ONDELAY,RAMPON,ON,OFFDELAY,RAMPOFF,OFF
SHORT_JT_OFFDELAY: ENUM [R,W] [Visible,Sticky] RANGE=0...6 DFLT=1 VALUES=NO_JUMP_IGNORE_COMMAND,ONDELAY,RAMPON,ON,OFFDELAY,RAMPOFF,OFF
SHORT_JT_ON: ENUM [R,W] [Visible,Sticky] RANGE=0...6 DFLT=1 VALUES=NO_JUMP_IGNORE_COMMAND,ONDELAY,RAMPON,ON,OFFDELAY,RAMPOFF,OFF
SHORT_JT_ONDELAY: ENUM [R,W] [Visible,Sticky] RANGE=0...6 DFLT=1 VALUES=NO_JUMP_IGNORE_COMMAND,ONDELAY,RAMPON,ON,OFFDELAY,RAMPOFF,OFF
SHORT_JT_RAMPOFF: ENUM [R,W] [Visible,Sticky] RANGE=0...6 DFLT=1 VALUES=NO_JUMP_IGNORE_COMMAND,ONDELAY,RAMPON,ON,OFFDELAY,RAMPOFF,OFF
SHORT_JT_RAMPON: ENUM [R,W] [Visible,Sticky] RANGE=0...6 DFLT=1 VALUES=NO_JUMP_IGNORE_COMMAND,ONDELAY,RAMPON,ON,OFFDELAY,RAMPOFF,OFF
SHORT_OFFDELAY_BLINK: ENUM [R,W] [Visible,Sticky] RANGE=0...1 DFLT=1 VALUES=OFF,ON
SHORT_OFFDELAY_NEWTIME: FLOAT [R,W] [Visible,Sticky] RANGE=0.1...25.6 DFLT=0.5 UNIT=s
SHORT_OFFDELAY_OLDTIME: FLOAT [R,W] [Visible,Sticky] RANGE=0.1...25.6 DFLT=0.5 UNIT=s
SHORT_OFFDELAY_STEP: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0.05 UNIT=100%
SHORT_OFFDELAY_TIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...111600 DFLT=0 UNIT=s
SHORT_OFF_LEVEL: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 UNIT=100%
SHORT_OFF_TIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...108000 DFLT=111600 UNIT=s
SHORT_OFF_TIME_MODE: ENUM [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 VALUES=ABSOLUTE,MINIMAL
SHORT_ONDELAY_MODE: ENUM [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 VALUES=SET_TO_OFF,NO_CHANGE
SHORT_ONDELAY_TIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...111600 DFLT=0 UNIT=s
SHORT_ON_LEVEL: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=1 UNIT=100%
SHORT_ON_LEVEL_PRIO: ENUM [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 VALUES=HIGH,LOW
SHORT_ON_MIN_LEVEL: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0.1 UNIT=100%
SHORT_ON_TIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...108000 DFLT=111600 UNIT=s
SHORT_ON_TIME_MODE: ENUM [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 VALUES=ABSOLUTE,MINIMAL
SHORT_RAMPOFF_TIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...111600 DFLT=0 UNIT=s
SHORT_RAMPON_TIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...111600 DFLT=0 UNIT=s
SHORT_RAMP_START_STEP: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0.05 UNIT=100%
UI_HINT: STRING [R,W] [Visible,Sticky] RANGE=... DFLT=
Paramset MASTER
AES_ACTIVE: BOOL [R,W] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
Paramset VALUES
DIRECTION: ENUM [R,E] [Visible,Sticky,Internal] RANGE=0...3 DFLT=0 VALUES=NONE,UP,DOWN,UNDEFINED
INHIBIT: BOOL [R,W,E] [Visible,Sticky] RANGE=0...1 DFLT=0
INSTALL_TEST: ACTION [W] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
LEVEL: FLOAT [R,W,E] [Visible,Sticky] RANGE=0...1 DFLT=0 UNIT=100%
OLD_LEVEL: ACTION [W] [Visible,Sticky] RANGE=0...1 DFLT=0
ON_TIME: FLOAT [W] [Visible,Sticky] RANGE=0...8.58259e+07 DFLT=0 UNIT=s
RAMP_STOP: ACTION [W] [Visible,Sticky] RANGE=0...1 DFLT=0
RAMP_TIME: FLOAT [W] [Visible,Sticky] RANGE=0...8.58259e+07 DFLT=0.5 UNIT=s
WORKING: BOOL [R,E] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
Channel 2
Paramset LINK
LONG_ACT_HSV_COLOR_VALUE: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
SHORT_ACT_HSV_COLOR_VALUE: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
Paramset MASTER
AES_ACTIVE: BOOL [R,W] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
WHITE_ADJUSTMENT_VALUE_BLUE: INTEGER [R,W] [Visible,Sticky] RANGE=0...100 DFLT=100 UNIT=%
WHITE_ADJUSTMENT_VALUE_GREEN: INTEGER [R,W] [Visible,Sticky] RANGE=0...100 DFLT=100 UNIT=%
WHITE_ADJUSTMENT_VALUE_RED: INTEGER [R,W] [Visible,Sticky] RANGE=0...100 DFLT=100 UNIT=%
Paramset VALUES
ACT_BRIGHTNESS: INTEGER [W] [Visible,Sticky,Internal] RANGE=0...255 DFLT=0
ACT_BRIGHTNESS_STORE: INTEGER [W] [Visible,Sticky,Internal] RANGE=0...255 DFLT=0
ACT_HSV_COLOR_VALUE: INTEGER [W] [Visible,Sticky,Internal] RANGE=0...255 DFLT=0
ACT_HSV_COLOR_VALUE_STORE: INTEGER [W] [Visible,Sticky,Internal] RANGE=0...255 DFLT=0
COLOR: INTEGER [R,W,E] [Visible,Sticky] RANGE=0...255 DFLT=0
INHIBIT: BOOL [R,W,E] [Visible,Sticky] RANGE=0...1 DFLT=0
ON_TIME: FLOAT [W] [Visible,Sticky] RANGE=0...8.58259e+07 DFLT=0 UNIT=s
ON_TIME_STORE: FLOAT [W] [Visible,Sticky,Internal] RANGE=0...8.58259e+07 DFLT=0 UNIT=s
RAMP_TIME: FLOAT [W] [Visible,Sticky] RANGE=0...8.58259e+07 DFLT=0.5 UNIT=s
RAMP_TIME_STORE: FLOAT [W] [Visible,Sticky,Internal] RANGE=0...8.58259e+07 DFLT=0.5 UNIT=s
USER_COLOR: STRING [W] [Visible,Sticky] RANGE=... DFLT=
Channel 3
Paramset LINK
LONG_ACT_COLOR_PROGRAM: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
LONG_ACT_MAX_BOARDER: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
LONG_ACT_MIN_BOARDER: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
SHORT_ACT_COLOR_PROGRAM: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
SHORT_ACT_MAX_BOARDER: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
SHORT_ACT_MIN_BOARDER: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
Paramset MASTER
AES_ACTIVE: BOOL [R,W] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
COLOR_CHANGE_SPEED: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=10 UNIT=s/U
Paramset VALUES
ACT_BRIGHTNESS: INTEGER [R,W] [Visible,Sticky,Internal] RANGE=0...255 DFLT=0
ACT_BRIGHTNESS_STORE: INTEGER [W] [Visible,Sticky,Internal] RANGE=0...255 DFLT=0
ACT_COLOR_PROGRAM_STORE: INTEGER [W] [Visible,Sticky,Internal] RANGE=0...255 DFLT=0
ACT_MAX_BOARDER: INTEGER [R,W] [Visible,Sticky,Internal] RANGE=0...255 DFLT=0
ACT_MAX_BORDER_STORE: INTEGER [W] [Visible,Sticky,Internal] RANGE=0...255 DFLT=0
ACT_MIN_BOARDER: INTEGER [R,W] [Visible,Sticky,Internal] RANGE=0...255 DFLT=0
ACT_MIN_BORDER_STORE: INTEGER [W] [Visible,Sticky,Internal] RANGE=0...255 DFLT=0
INHIBIT: BOOL [R,W,E] [Visible,Sticky] RANGE=0...1 DFLT=0
ON_TIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...8.58259e+07 DFLT=0 UNIT=s
ON_TIME_STORE: FLOAT [W] [Visible,Sticky,Internal] RANGE=0...8.58259e+07 DFLT=0 UNIT=s
PROGRAM: INTEGER [R,W,E] [Visible,Sticky] RANGE=0...255 DFLT=0
RAMP_TIME: FLOAT [R,W] [Visible,Sticky] RANGE=0...8.58259e+07 DFLT=0.5 UNIT=s
RAMP_TIME_STORE: FLOAT [W] [Visible,Sticky,Internal] RANGE=0...8.58259e+07 DFLT=0.5 UNIT=s
USER_PROGRAM: STRING [W] [Visible,Sticky] RANGE=... DFLT=
Wurde beim
HM-CC-RT-DNauch was verändert oder das HMCCUDEV entfernt?
Funktioniert bei mir nur mit
define "Gerätename" HMCCU HM-ID forceDevDankeschön
Gruß aherby
Wenn das define für ein HM-CC-RT-DN als HMCCUDEV bereits in der fhem.cfg steht, wird das beim Starten von FHEM auch akzeptiert.
ABER: Bei einer interaktiven neuen Definition per define oder per Befehl "get createDev" wird ein HMCCUCHN angelegt, da es keinen Grund für ein HMCCUDEV an dieser Stelle gibt. Im Zweifel verwendet HMCCU bei der automatischen Erkennung immer HMCCUCHN, wenn dies zur Steuerung des Gerätes ausreicht. Wenn Du das anders haben möchtest, musst Du forceDev verwenden. Aber wie gesagt: macht keinen Sinn.
Hallo Zap,
Zitat von: aherby am 28 September 2021, 23:24:09
...
Können hier auch die Batterie-Readings bei:
- HM-LC-Sw1-FM
- HM-LC-Sw2-FM
- HM-LC-Sw4-DR
- HM-LC-Sw1-Pl-CT-R1
- HM-LC-RGBW-WM
entfernt werden?
...
mein HM-LC-Sw1-Pl-2 hat auch ein Battery-Reading das entfernt werden kann.
Danke Jens
Das Problem mit den battery Readings ist: das sind valide Datenpunkte, die von der CCU an FHEM geschickt werden. Woher soll HMCCU wissen, dass bei bestimmten Gerätetypen diese Readings unterdrückt werden müssen? Ich werde jedenfalls keine Typenabfrage in HMCCU einbauen. Da würde ein enormer Pflegeaufwand entstehen.
Wenn also jemand eine Idee für eine generische Lösung hat, nehme ich die gerne. Leider kann man nicht abfragen, ob ein Gerät Batterien nutzt oder direkt versorgt wird.
Zitat von: zap am 11 Oktober 2021, 18:35:37
Das Problem mit den battery Readings ist: das sind valide Datenpunkte, die von der CCU an FHEM geschickt werden. Woher soll HMCCU wissen, dass bei bestimmten Gerätetypen diese Readings unterdrückt werden müssen? Ich werde jedenfalls keine Typenabfrage in HMCCU einbauen. Da würde ein enormer Pflegeaufwand entstehen.
Wenn also jemand eine Idee für eine generische Lösung hat, nehme ich die gerne. Leider kann man nicht abfragen, ob ein Gerät Batterien nutzt oder direkt versorgt wird.
ich weiss nicht, ob die infos in hmccu zur verfügung stehen, aber battery devices verfügen immer über spezielle rx_modes zum aufwachen. im eq3 xml file steht zb: => rx_modes="CONFIG,WAKEUP"
ohne battery => keine rx_modes.
@frank
Danke für den Hinweis. An die Infos kommt man dran. In der Doku steht das:
RX_MODE (nur bei Geräten, nur bei BidCos-RF)
Datentyp Integer. Oder-Verknüpfung von Flags die den Empfangsmodes des Gerätes repräsentieren. Folgende Werte haben eine Bedeutung:
0x01 = RX_ALWAYS; Das Gerät ist dauerhaft auf Empfang
0x02 = RX_BURST; Das Gerät arbeitet im wake on radio Modus
0x04 = RX_CONFIG; Das Gerät kann nach drücken der Konfigurationstaste erreicht werden
0x08 = RX_WAKEUP; Das Gerät kann nach einer direkter Kommunikation mit der Zentrale geweckt werden
0x10 = RX_LAZY_CONFIG; Das Gerät unterstützt LazyConfig. Das Gerät kann nach einer normalen Bedienung (z.B. Tastendruck einer Fernbedienung) konfiguriert werden.
Ich muss mal prüfen, wie das bei HmIP und bei Wired aussieht. Hier steht halt erst mal nur bei BidCos
RX_ALWAYS sollte dann komplett ohne battery sein.
gibt es bei wired überhaupt battery?
zumindestens die letzten "angemeckerten" devices waren alle bidcos. ;)
Hallo Zap,
beim HMIP-PSM & HM-ES-PMSw1-Pl werden in der CCU die Zahlenwerte im Messwertkanal mit zwei Stellen hinterm Komma angezeigt, in HMCCU aber nur mit 1 Stelle.
Kannst du das anpassen, oder kann ich das beeinflussen?
mfg Jens
Hallo Jens,
hast du schon "stripnumber" ausprobiert?
Gruß Reinhard
Hallo Reinhard,
Zitat... hast du schon "stripnumber" ausprobiert? ...
danke dir, das war es natürlich. Oh wie peinlich, zumal ich das früher schon benutzt habe.
mfG Jens
Hallo zap,
wie lange ist denn die Beta Phase von HMCCU 5 geplant?
Ich habe von ELV bei dem aktuellen MAX Austauschprogramm HmIP-eTRV-B Thermostate bekommen. Diese werden mit der stabilen HMCCU Version nicht als Thermostate erkannt. Kann ich hier mit einer Datenlieferung unterstützen?
Ich würde aufgrund der grundsätzlichen Reife von Version 5.0 und den vielen Verbesserungen nicht mehr auf die alte Version setzen und direkt die 5.0 nutzen, egal ob offiziell eingecheckt oder nicht. Du tust dir mit 4.3 keinen Gefallen, insbesondere wenn bald 5.0 erscheint und du migrieren musst.
Aktualisierte 5.0 bei github und im contrib.
Unter anderem wird nun der HmIP-BSL unterstützt. Das Gerät sollte mit get createDev angelegt werden. Dabei werden 3 HMCCUDEVs (2 für die beiden Dimmerkanäle und 1 für den Schalter) angelegt.
Hallo Zap,
ich habe ein Problem mit einem HMIP-PSM. Das 'state' event kommt immer 2 mal, wenn ich die Steckdose über das webCmd ''on'' oder ''off ''schalte, obwohl ich "attr event-on-change-reading state" gesetzt habe. Damit sollte das event aber nur einmal kommen.
Habe ich die Definition falsch, oder was muss ich machen damit das event immer nur 1 x kommt?
Hier das list vom device und der log vom Eventmonitor nach einem einmaligen Schaltvorgang über das webCmd, einmal auf 'on', danach auf 'off'.
Ich benutze HMCCU version 5.0 212921914 von gerade, aber das Verhalten war mit den vorherigen Versionen gleich.
2021-10-19 22:47:04.996 HMCCUDEV HMIP_PSM2 on
2021-10-19 22:47:08.732 HMCCUDEV HMIP_PSM2 on
2021-10-19 22:47:22 anderes event vom anderen device
2021-10-19 22:47:24.710 HMCCUDEV HMIP_PSM2 off
2021-10-19 22:47:27.971 HMCCUDEV HMIP_PSM2 off
Internals:
DEF 0001D709903D2D
FUUID 5c42ee94-f33f-97bf-655b-c4d780499b9787dd
IODev HMCCU3
NAME HMIP_PSM2
NR 2430
STATE off
TYPE HMCCUDEV
ccuaddr 0001D709903D2D
ccudevstate active
ccuif HmIP-RF
ccuname HMIP-PSM 0001D709903D2D HMIP-PSM2
ccurolectrl SWITCH_VIRTUAL_RECEIVER
ccurolestate SWITCH_TRANSMITTER
ccusubtype PSM
ccutype HMIP-PSM
firmware 2.18.22
readonly no
Helper:
DBLOG:
power:
myDbLog:
TIME 1634675772.8982
VALUE 0.0
OLDREADINGS:
READINGS:
2021-10-19 22:41:27 activity alive
2021-10-19 22:41:27 control off
2021-10-19 22:41:27 devstate ok
2021-10-19 22:36:12 energy 0.6
2021-10-19 22:36:12 energy_OVERFLOW false
2021-10-19 22:41:27 hmstate off
2021-10-19 22:36:12 power 0.0
2021-10-19 22:36:12 power_STATUS NORMAL
2021-10-19 22:41:27 rssidevice -41
2021-10-19 22:41:27 rssipeer -42
2021-10-19 22:41:27 state off
hmccu:
channels 9
detect 5
devspec 0001D709903D2D
forcedev 0
nodefaults 1
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:SWITCH_TRANSMITTER,3:SWITCH_VIRTUAL_RECEIVER,4:SWITCH_VIRTUAL_RECEIVER,5:SWITCH_VIRTUAL_RECEIVER,6:ENERGIE_METER_TRANSMITTER,7:COND_SWITCH_TRANSMITTER,8:SWITCH_WEEK_PROFILE
semDefaults 0
cmdlist:
get
set off:noArg on-till on:noArg on-for-timer off:noArg on-till on:noArg on-for-timer off:noArg on-till on:noArg on-for-timer toggle:noArg
control:
chn 3
dpt STATE
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
NVAL 24.000000
ONVAL 24.000000
OSVAL 24.0
OVAL 24.000000
SVAL 24.0
VAL 24.000000
0.ACTUAL_TEMPERATURE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.INSTALL_TEST:
VALUES:
NVAL true
ONVAL true
OSVAL true
OVAL true
SVAL true
VAL true
0.OPERATING_VOLTAGE:
VALUES:
NVAL 0.000000
ONVAL 0.000000
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
0.OPERATING_VOLTAGE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL -41
ONVAL -40
OSVAL -40
OVAL -40
SVAL -41
VAL -41
0.RSSI_PEER:
VALUES:
NVAL -42
ONVAL -38
OSVAL -38
OVAL -38
SVAL -42
VAL -42
0.UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
2.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
2.SECTION:
VALUES:
NVAL 0
ONVAL 2
OSVAL 2
OVAL 2
SVAL 0
VAL 0
2.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
2.STATE:
VALUES:
NVAL 0
ONVAL 1
OSVAL on
OVAL 1
SVAL off
VAL 0
3.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
3.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
3.STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
4.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
4.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
5.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
5.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
5.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
6.CURRENT:
VALUES:
NVAL 0.000000
ONVAL 0.000000
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
6.CURRENT_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.ENERGY_COUNTER:
VALUES:
NVAL 0.600000
ONVAL 0.600000
OSVAL 0.6
OVAL 0.600000
SVAL 0.6
VAL 0.600000
6.ENERGY_COUNTER_OVERFLOW:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
6.FREQUENCY:
VALUES:
NVAL 50.010000
ONVAL 50.010000
OSVAL 50.0
OVAL 50.010000
SVAL 50.0
VAL 50.010000
6.FREQUENCY_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.POWER:
VALUES:
NVAL 0.000000
ONVAL 0.000000
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
6.POWER_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.VOLTAGE:
VALUES:
NVAL 229.100000
ONVAL 229.100000
OSVAL 229.1
OVAL 229.100000
SVAL 229.1
VAL 229.100000
6.VOLTAGE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
8.WEEK_PROGRAM_CHANNEL_LOCKS:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
roleCmds:
get:
set:
off:
channel ?
role SWITCH_VIRTUAL_RECEIVER
subcount 1
syntax V:STATE:0
usage off
subcmd:
000:
args 0
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 000
unit
on:
channel ?
role SWITCH_VIRTUAL_RECEIVER
subcount 1
syntax V:STATE:1
usage on
subcmd:
000:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 000
unit
on-for-timer:
channel ?
role SWITCH_VIRTUAL_RECEIVER
subcount 2
syntax V:ON_TIME:?duration V:STATE:1
usage on-for-timer duration
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname duration
partype 2
ps VALUES
scn 000
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 001
unit
on-till:
channel ?
role SWITCH_VIRTUAL_RECEIVER
subcount 2
syntax V:ON_TIME:?time V:STATE:1
usage on-till time
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname time
partype 2
ps VALUES
scn 000
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 001
unit
state:
chn 2
dpt STATE
Attributes:
IODev HMCCU3
ccureadingfilter (POWER|^ENERGY_COUNTER)
ccureadingname 6.POWER:power;6.ENERGY_COUNTER:energy
comment DeLonghi PAC EL92 SILENT
devStateIcon off:ios-off on:ios-on-green .*:noIcon
event-on-change-reading power,state
group SCHALTER
room Energy,HomeMaticIP,Schalter
sortby 221
stateFormat {myHMIP_PSM2StateFormat ($name)}
webCmd on:off
Ich glaube, ich habe mir das schon einmal angeschaut und festgestellt, dass die CCU in diesem Fall tatsächlich 2 Events schickt. Klar, man könnte ggf. Events filtern. Aber nach welchen Kriterien? Das Risiko, Events zu verlieren, ist hier zu groß.
Ich schaue gerne nochmal nach, ob das tatsächlich so ist wie vermutet.
Die CCU schickt die Events 2x:
2021.10.20 14:46:56 2: HMCCURPCPROC [d_rpcHmIP_RF] CCUEvent = EV|CB2010001013001021|1634734016|0001D3C990BC3C:3|STATE|1
2021.10.20 14:46:59 2: HMCCURPCPROC [d_rpcHmIP_RF] CCUEvent = EV|CB2010001013001021|1634734019|0001D3C990BC3C:3|STATE|1
2021.10.20 14:47:24 2: HMCCURPCPROC [d_rpcHmIP_RF] CCUEvent = EV|CB2010001013001021|1634734044|0001D3C990BC3C:3|STATE|0
2021.10.20 14:47:26 2: HMCCURPCPROC [d_rpcHmIP_RF] CCUEvent = EV|CB2010001013001021|1634734046|0001D3C990BC3C:3|STATE|0
Zum Verständnis: aber wenn durch das erste CCU-"Event" das state-Reading vom FHEM-Device durch das HMCCU-Modul bspw. auf "on" gesetzt wird, dürfte beim korrekt gesetzt event-on-change-reading-Attribut doch der zweite CCU-"Event", über den das state-Reading wieder mit "on" gesetzt wird, nicht noch einmal einen FHEM-Event auslösen?!
Hallo Zap,
danke das Du Dir das nochmal angeschaut hast.
Das komische ist ja, wenn ich "attr HMIP_PSM2 event-on-change-reading state" weglasse, kommt das event im Event Monitor nur genau 1 mal.
D.h ich habe jetzt überall bei meinen Schaltsteckdosen mit Leistungsmessung "attr HMIP_PSM2 event-on-change-reading power" anstatt "attr HMIP_PSM2 event-on-change-reading power,state" gesetzt, damit nicht immer 2 events kommen.
Der FHEM-Wiki Artikel für HMCCU wurde nun auf Version 5.0 angepasst. Ist noch ausbaufähig, sollte aber erst mal für das kommende Update ausreichen.
Zitat von: Jamo am 20 Oktober 2021, 17:31:31
Das komische ist ja, wenn ich "attr HMIP_PSM2 event-on-change-reading state" weglasse, kommt das event im Event Monitor nur genau 1 mal.
D.h ich habe jetzt überall bei meinen Schaltsteckdosen mit Leistungsmessung "attr HMIP_PSM2 event-on-change-reading power" anstatt "attr HMIP_PSM2 event-on-change-reading power,state" gesetzt, damit nicht immer 2 events kommen.
Und du hast nicht zufälligerweise auch das Attribut event-on-update-reading auch so gesetzt?
Zitat von: Ralli am 20 Oktober 2021, 19:34:28
Und du hast nicht zufälligerweise auch das Attribut event-on-update-reading auch so gesetzt?
Nein, ich habe ja oben das listing mit in den codetags, da siehst Du das ich nur event-on-change benutzt habe.
Dann ist das nach meinem Verständnis ein Bug in der Event-Generierung.
Hallo Zap,
mit dem letzten Update der 5.0 hat sich anscheinend etwas geändert. Der HmIP-BDT Dimmer lässt sich jetzt nicht mehr über 'pct' steuern. Bei dem Versuch die Helligkeit darüber einzustellen erhalte ich die Fehlermeldung "Invalid datapoint. VALUES.LEVEL". Vorher ließ sich über pct Helligkeit, Dauer und Ramp einstellen. Irgendeinen Verdacht?
@Reinhard.M. : Mach mal bitte ein list vom Device
Und vielleicht noch get detectDev im IO Device
Zitat von: zap am 20 Oktober 2021, 20:30:36
@Reinhard.M. : Mach mal bitte ein list vom Device
Und vielleicht noch get detectDev im IO Device
@Zap: Das Listing sprengt wohl hier den maximalen Code Bereich. Habe beides als File angehängt.
Kurze Frage am Rande: Wie finde ich die Bedeutung von "set <device> progMode XXXXX" heraus? Konnte leider bislang weder in der Commandref noch im Wiki etwas finden.
Gruß Reinhard
@Reinhard.M
set progMode habe ich "versehentlich" eingebaut. Das hängt mit dem Management der Wochenprofile zusammen, ist aber noch nicht ganz fertig. Also erst mal ignorieren.
Den Fehler bei "set pct" kann ich mir nicht erklären. Die Befehle "set on-for-timer" und "on-till" werden auch nicht funktionieren.
Zwei Dinge:
1. Bitte führe für Dein Device den Befehl "get paramsetDesc" aus und poste die Ausgabe.
2. Leg das Device noch einmal an mit "get createDev" (ohne weitere Attribute zu setzen, insbesondere nicht substitute und eventMap). Schau mal, ob set pct dann funktioniert und mach nochmal ein list vom neu angelegten Device.
Erst mal nichts machen. Ich glaube, das ist ein Bug.
Zitat von: zap am 21 Oktober 2021, 09:34:34
Erst mal nichts machen. Ich glaube, das ist ein Bug.
Kann ich bestätigen, habe gerade alles gemacht (ganz kurz vor deiner Meldung :) )
Als ich das Device entsprechend 2. neu angelegt hatte funktionierte pct trotzdem nicht. Das paramsetDesc habe ich schon, ist im Anhang.
@Reinhard.M Bitte mach mal ein Update und versuche es nochmal mit set pct.
@Zap, passt! Läuft wieder mit pct :)
Hallo zap,
zuerst mal ein Riesen-Danke für das Modul. Es hat bis vor 1h (vor dem Update) hervorragend geklappt. Allerdings habe ich jetzt den Effekt, dass nach einem Update von FHEM zwar die RPC-laufen, allerdings alle devices gelöscht sind.
Über die RPC-Server kann ich zwar die Geräte "sehen", d.h. er liest sie ein, allerdings bekomme ich keine Liste und meine fhem.cfg ist nach dem Update von 365 auf 3085k "geschrumpft".
Sollte er nicht die Geräte wieder selber anlegen?
Weiters ist mir aufgefallen, dass bei Aktionen mit dem CCU Device diese von FHEM mit einem Restart quittiert werden. Ein sudo systemctl am Server erklärt:
"fhem.service: main process exited, code=exited, status=255/EXCEPTION"
Hier das Log, nach dem Update:
2021.10.22 19:45:42 1: HMCCURPCPROC: [d_rpc188244CUxD : 24942] Initialized version 5.0 for interface CUxD with I/O device MalaCCU3
2021.10.22 19:45:42 3: sen.lux.bad: I/O device is gw.deconz
2021.10.22 19:45:43 1: PERL WARNING: Subroutine HMCCUCHN_Initialize redefined at ./FHEM/88_HMCCUCHN.pm line 38, <$fh> line 6595.
2021.10.22 19:45:43 1: PERL WARNING: Subroutine HMCCUCHN_Define redefined at ./FHEM/88_HMCCUCHN.pm line 64, <$fh> line 6595.
2021.10.22 19:45:43 1: reload: Error:Modul 88_HMCCUCHN deactivated:
Not enough arguments for main::HMCCU_AssignIODevice at ./FHEM/88_HMCCUCHN.pm line 172, near "})"
Not enough arguments for main::HMCCU_GetValidDatapoints at ./FHEM/88_HMCCUCHN.pm line 318, near "2)"
2021.10.22 19:45:43 0: Not enough arguments for main::HMCCU_AssignIODevice at ./FHEM/88_HMCCUCHN.pm line 172, near "})"
Not enough arguments for main::HMCCU_GetValidDatapoints at ./FHEM/88_HMCCUCHN.pm line 318, near "2)"
2021.10.22 19:45:43 1: Including ./log/fhem.save
2021.10.22 19:46:36 1: Messages collected while initializing FHEM:configfile: Cannot load module HMCCUCHN
setuuid: Please define hm.hz.wt.wz first
Cannot load module HMCCUCHN
setuuid: Please define hm.hz.wt.fx first
Cannot load module HMCCUCHN
setuuid: Please define hm.hz.wt.bad first
Ich erspare euch die restlichen Geräte...
any ideas? - ich bin jetzt am rücksichern der fhem.cfg :)
lg Shamal
Ich würde sagen, dass da beim Update etwas schief gegangen ist. Du hast hoffentlich contrib oder github als Quelle angegeben?
Die Module werden nicht geladen, daher werden Deine Devices nicht definiert.
Hi, danke für die schnelle Antwort...
ja hatte ich, aber das er mir gleich meine Devices killt :) - nicht lieb von ihm. Mittlerweile habe die fhem.cfg restored und wieder alles gut.
lg shamal
Hey habe einen kleinen Umrechnungsfehler in meinem Heizungsregler gefunden:
Zitat1.LEVEL = 0.070000 {f} [RWE]
zeigt in FHEM:
ZitatLEVEL 0.1
Device channels and datapoints
DEV HmIP-eTRV-2-Badezimmer 000A1D8997E13E interface=HmIP-RF type=HmIP-eTRV-2
CHN 000A1D8997E13E:0 HmIP-eTRV-2-Badezimmer:0
0.CONFIG_PENDING = false {b} [RE]
0.DUTY_CYCLE = false {b} [RE]
0.INSTALL_TEST = true {b} [RW]
0.LOW_BAT = false {b} [RE]
0.OPERATING_VOLTAGE = 3.100000 {f} [RE]
0.OPERATING_VOLTAGE_STATUS = 0 {i} [RE]
0.RSSI_DEVICE = 194 {n} [RE]
0.RSSI_PEER = 198 {n} [RE]
0.UNREACH = false {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
CHN 000A1D8997E13E:1 HmIP-eTRV-2 000A1D8997E13E:1
1.ACTIVE_PROFILE = 1 {i} [RWE]
1.ACTUAL_TEMPERATURE = 21.100000 {f} [RE]
1.ACTUAL_TEMPERATURE_STATUS = 0 {i} [RE]
1.BOOST_MODE = false {b} [WE]
1.BOOST_TIME = 0 {i} [RE]
1.CONTROL_DIFFERENTIAL_TEMPERATURE = {f} [W]
1.CONTROL_MODE = {i} [W]
1.DURATION_UNIT = {i} [W]
1.DURATION_VALUE = {i} [W]
1.FROST_PROTECTION = false {b} [RE]
1.LEVEL = 0.070000 {f} [RWE]
1.LEVEL_STATUS = 0 {i} [RE]
1.PARTY_MODE = false {b} [RE]
1.PARTY_SET_POINT_TEMPERATURE = 0.000000 {f} [RE]
1.PARTY_TIME_END = {s} [RWE]
1.PARTY_TIME_START = {s} [RWE]
1.QUICK_VETO_TIME = 0 {i} [RE]
1.SET_POINT_MODE = 0 {i} [RWE]
1.SET_POINT_TEMPERATURE = 20.000000 {f} [RWE]
1.SWITCH_POINT_OCCURED = false {b} [RE]
1.VALVE_ADAPTION = false {b} [RWE]
1.VALVE_STATE = 4 {i} [RE]
1.WINDOW_STATE = 0 {i} [RWE]
Device detection:
StateDatapoint = 1.ACTUAL_TEMPERATURE [HEATING_CLIMATECONTROL_TRANSCEIVER]
ControlDatapoint = 1.SET_POINT_TEMPERATURE [HEATING_CLIMATECONTROL_TRANSCEIVER]
Recommended module for device definition: HMCCUCHN
Current state datapoint = 1.ACTUAL_TEMPERATURE
Current control datapoint = 1.SET_POINT_TEMPERATURE
Device description
Device 000A1D8997E13E HmIP-eTRV-2-Badezimmer [HmIP-eTRV-2]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 000A1D8997E13E:0,000A1D8997E13E:1,000A1D8997E13E:2,000A1D8997E13E:3,000A1D8997E13E:4,000A1D8997E13E:5,000A1D8997E13E:6,000A1D8997E13E:7
DIRECTION: NONE
FIRMWARE: 2.2.8
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 8170256
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG
SUBTYPE: TRV
UPDATABLE: 1
Channel 000A1D8997E13E:0 HmIP-eTRV-2-Badezimmer:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 000A1D8997E13E
PARENT_TYPE: HmIP-eTRV-2
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000A1D8997E13E:1 HmIP-eTRV-2 000A1D8997E13E:1 [HEATING_CLIMATECONTROL_TRANSCEIVER] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CLIMATE_CONTROL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000A1D8997E13E
PARENT_TYPE: HmIP-eTRV-2
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Defaults
Support for role HEATING_CLIMATECONTROL_TRANSCEIVER of device type HmIP-eTRV-2 is built in.
LG Patrick
Hallo Patrick,
Ich würde sagen, kein Umrechnungsfehler. Hast du schon "stripnumber" ausprobiert? Ist ein Attribut und steht meines Wissens per Default auf 1.
Gruß Reinhard
Eigentlich müsste 7 angezeigt werden. Bitte ein list vom Device.
Hier das list vom Device:
Internals:
DEF 000A1D8997E153:1
FUUID 61734aee-f33f-19ae-8a9f-69719451db9cb847
IODev d_ccu
NAME HmIP_eTRV_2_Kueche
NR 357
STATE 21.3
TYPE HMCCUCHN
ccuaddr 000A1D8997E153:1
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-eTRV-2 000A1D8997E153:1
ccurolectrl HEATING_CLIMATECONTROL_TRANSCEIVER
ccurolestate HEATING_CLIMATECONTROL_TRANSCEIVER
ccusubtype TRV
ccutype HmIP-eTRV-2
chntype ?
firmware 2.2.8
readonly no
READINGS:
2021-10-23 10:10:24 ACTIVE_PROFILE 1
2021-10-23 10:10:24 ACTUAL_TEMPERATURE 21.3
2021-10-23 10:10:24 ACTUAL_TEMPERATURE_STATUS NORMAL
2021-10-23 10:10:24 BOOST_MODE false
2021-10-23 10:10:24 BOOST_TIME 0
2021-10-23 10:10:24 FROST_PROTECTION false
2021-10-23 01:36:14 IODev d_ccu
2021-10-23 10:10:24 LEVEL 0.1
2021-10-23 10:10:24 LEVEL_STATUS NORMAL
2021-10-23 10:10:24 PARTY_MODE false
2021-10-23 02:22:43 PARTY_SET_POINT_TEMPERATURE 0.0
2021-10-23 02:22:43 PARTY_TIME_END
2021-10-23 02:22:43 PARTY_TIME_START
2021-10-23 10:10:24 QUICK_VETO_TIME 0
2021-10-23 10:10:24 SET_POINT_MODE auto
2021-10-23 10:10:24 SET_POINT_TEMPERATURE 20.0
2021-10-23 10:10:24 SWITCH_POINT_OCCURED false
2021-10-23 02:22:43 VALVE_ADAPTION false
2021-10-23 10:10:24 VALVE_STATE ADAPTION_DONE
2021-10-23 10:10:24 WINDOW_STATE closed
2021-10-23 10:10:24 activity alive
2021-10-23 10:10:24 battery ok
2021-10-23 10:10:24 control 20.0
2021-10-23 10:10:24 desired-temp 20.0
2021-10-23 10:10:24 devstate ok
2021-10-23 10:10:24 hmstate 21.3
2021-10-23 10:10:24 measured-temp 21.3
2021-10-23 10:10:24 rssidevice -49
2021-10-23 10:10:24 rssipeer -45
2021-10-23 10:10:24 state 21.3
hmccu:
channels 1
detect 1
devspec 000A1D8997E153:1
nodefaults 0
role 1:HEATING_CLIMATECONTROL_TRANSCEIVER
semDefaults 0
cmdlist:
get
set on:noArg off:noArg desired-temp auto:noArg holiday:noArg manu:noArg boost:noArg toggle:noArg
control:
chn 1
dpt SET_POINT_TEMPERATURE
dp:
0.CONFIG_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.INSTALL_TEST:
VALUES:
NVAL true
ONVAL true
OSVAL true
OVAL true
SVAL true
VAL true
0.LOW_BAT:
VALUES:
NVAL 0
ONVAL 0
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.OPERATING_VOLTAGE:
VALUES:
NVAL 3.1
ONVAL 3.1
OSVAL 3.1
OVAL 3.1
SVAL 3.1
VAL 3.1
0.OPERATING_VOLTAGE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL -49
ONVAL -50
OSVAL -50
OVAL -50
SVAL -49
VAL -49
0.RSSI_PEER:
VALUES:
NVAL -45
ONVAL -45
OSVAL -45
OVAL -45
SVAL -45
VAL -45
0.UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
1.ACTIVE_PROFILE:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.ACTUAL_TEMPERATURE:
VALUES:
NVAL 21.3
ONVAL 21.3
OSVAL 21.3
OVAL 21.3
SVAL 21.3
VAL 21.3
1.ACTUAL_TEMPERATURE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.BOOST_MODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.BOOST_TIME:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.FROST_PROTECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.LEVEL:
VALUES:
NVAL 0.07
ONVAL 0.09
OSVAL 0.1
OVAL 0.09
SVAL 0.1
VAL 0.07
1.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.PARTY_MODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.PARTY_SET_POINT_TEMPERATURE:
VALUES:
NVAL 0.000000
ONVAL 0.000000
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
1.PARTY_TIME_END:
VALUES:
NVAL
ONVAL
OSVAL
OVAL
SVAL
VAL
1.PARTY_TIME_START:
VALUES:
NVAL
ONVAL
OSVAL
OVAL
SVAL
VAL
1.QUICK_VETO_TIME:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.SET_POINT_MODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL auto
OVAL 0
SVAL auto
VAL 0
1.SET_POINT_TEMPERATURE:
VALUES:
NVAL 20.0
ONVAL 20.0
OSVAL 20.0
OVAL 20.0
SVAL 20.0
VAL 20.0
1.SWITCH_POINT_OCCURED:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.VALVE_ADAPTION:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
1.VALVE_STATE:
VALUES:
NVAL 4
ONVAL 4
OSVAL ADAPTION_DONE
OVAL 4
SVAL ADAPTION_DONE
VAL 4
1.WINDOW_STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL closed
OVAL 0
SVAL closed
VAL 0
roleCmds:
get:
set:
auto:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:CONTROL_MODE:0
usage auto
subcmd:
000:
args 0
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
boost:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:BOOST_MODE:1
usage boost
subcmd:
000:
args 1
dpt BOOST_MODE
fnc
max 1
min 0
parname BOOST_MODE
partype 3
ps VALUES
scn 000
unit
desired-temp:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:SET_POINT_TEMPERATURE:?temperature
usage desired-temp temperature
subcmd:
000:
args
dpt SET_POINT_TEMPERATURE
fnc
max 30.5
min 4.5
parname temperature
partype 2
ps VALUES
scn 000
unit �C
holiday:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:CONTROL_MODE:2
usage holiday
subcmd:
000:
args 2
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
manu:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:CONTROL_MODE:1
usage manu
subcmd:
000:
args 1
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
off:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 2
syntax V:CONTROL_MODE:1 V:SET_POINT_TEMPERATURE:4.5
usage off
subcmd:
000:
args 1
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
001:
args 4.5
dpt SET_POINT_TEMPERATURE
fnc
max 30.5
min 4.5
parname SET_POINT_TEMPERATURE
partype 3
ps VALUES
scn 001
unit �C
on:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 2
syntax V:CONTROL_MODE:1 V:SET_POINT_TEMPERATURE:30.5
usage on
subcmd:
000:
args 1
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
001:
args 30.5
dpt SET_POINT_TEMPERATURE
fnc
max 30.5
min 4.5
parname SET_POINT_TEMPERATURE
partype 3
ps VALUES
scn 001
unit �C
state:
chn 1
dpt ACTUAL_TEMPERATURE
Attributes:
cmdIcon auto:sani_heating_automatic manu:sani_heating_manual boost:sani_heating_boost on:general_an off:general_aus
room Homematic
substexcl desired-temp
userattr structexclude structure_heizung_unten structure_heizung_unten_map
webCmd desired-temp:auto:manu:boost:on:off
widgetOverride desired-temp:slider,4.5,0.5,30.5,1
Stripnumber habe ich nichts ausprobiert. Hatte das Device nur per autocreate angelegt.
@SamNitro
bitte noch die Ausgabe von "get paramsetDesc" (es genügt die Zeile mit LEVEL)
Hey habe diese beiden gefunden:
IDENTIFY_TARGET_LEVEL: FLOAT [W] [Visible,Sticky] RANGE=0...1 DFLT=0 UNIT=100%
OVERTEMP_LEVEL: INTEGER [R,W] [Visible,Sticky] RANGE=-128...127 DFLT=70 UNIT=°C
Es muss ein LEVEL dabei sein. Ansonsten halt die komplette Ausgabe
@Zap
Bin gerade am testen der Version 5.0 mit u.a. einem Heizkörperthermostat.
Wäre es möglich im HMCCUDEV Modul ein Mapping vom Internal "ccutype" auf ein Attribut "model" einzubauen?
Homematic Komponenten, wie z.B.: HM-CC-RT-DN stellen dieses Attribut zur Verfügung.
Beispielsweise
Internals
ccutype HmIP-eTRV-C-2
auf
Attributes
model HmIP-eTRV-C-2
Damit könnten Module, die das Attribut "model" abfragen (z.B. bei mir 59_HCS.pm) auch für HomeMatic IP Geräte aktiviert werden.
servus
Ulrich
Hallo,
habe gerade gesehen das es nun eine beta 5.0 gibt. Wird die alte Beta 4.4 nun ganz normal mit fhem update verteilt?
Gruß Holger
@The-Holgi: ich habe lediglich die Versionsnummer geändert. Verteilung (noch) über git und svn contrib
@ulbr2000: Ich denke mal darüber nach. Ich verstehe allerdings den Sinn von HCS im Zeitalter elektronisch geregelter Heizkreispumpen nicht. Meine Pumpen regeln ihre Leistung automatisch je nach Widerstand und Rücklauftemperatur (und Außentemperatur) bzw. schalten sich komplett ab.
Ich meine das war beim ersten Mal nicht dabei:
LEVEL: FLOAT [R,W,E] [Visible,Sticky] RANGE=0...1.01 DFLT=0
Hatte aber auch nur über Handy gesucht sorry...
@SamNitro: ok, da fehlt UNIT=100%. Daher wurde bis zur vorherigen Version dieser Wert nicht automatisch skaliert. Das habe ich im letzen Update jedoch behoben, d.h. HMCCU ergänzt das eigenständig. Benutzt Du die Version
5.0 212941907 ?
Jetzt erst. Hatte noch eine wo nur 5.0 stand.
Jetzt passt auch die Anzeige.
@Zap
ich steuere damit nicht meine Heizpumpen sondern den Status der Heizung (Fernwärme)
wenn Heizbedarf: Fernwärme an (Hauptventil auf)
wenn kein Heizbedarf: Fernwärme aus (Hauptventil zu)
Es muß kein automatisches Mapping sein, für meine dzt. Steuerung wäre es wichtig, diese Attribut zu vergeben
servus
Ulrich
Zitat von: ulbr2000 am 24 Oktober 2021, 15:13:38
@Zap
ich steuere damit nicht meine Heizpumpen sondern den Status der Heizung (Fernwärme)
wenn Heizbedarf: Fernwärme an (Hauptventil auf)
wenn kein Heizbedarf: Fernwärme aus (Hauptventil zu)
Es muß kein automatisches Mapping sein, für meine dzt. Steuerung wäre es wichtig, diese Attribut zu vergeben
servus
Ulrich
Das kannst Du mit FHEM Bordmitteln lösen. Angenommen, Dein HmIP Thermostat Device heißt "HeizungBad", dann:
attr HeizungBad userattr model
attr HeizungBad model HmIP-eTRV
wann wird 5.xxx die bisherige Version ersetzen? Hab mir bei einem Update schon zweimal die alte Version wieder draufgebügelt weil ich nicht dran gedacht habe;-)
Zitat von: zap am 24 Oktober 2021, 19:44:08
Das kannst Du mit FHEM Bordmitteln lösen. Angenommen, Dein HmIP Thermostat Device heißt "HeizungBad", dann:
attr HeizungBad userattr model
attr HeizungBad model HmIP-eTRV
Hi Zap
danke, das klappt einwandfrei
servus
Ulrich
Hi,
ein Problem habe ich mit der Beta:
Ich habe in der CCU einige EnOcean-Geräte definiert (per CuxD). Im speziellen handelt es sich um einen Eltako-FUD14-Dimmaktor. Er lässt sich im CCU-WebUI problemlos bedienen und ist dort als HM-LC-Dim1L-CV in der Geräteliste aufgeführt. In Fhem habe ich das Gerät per get hmccu get createDev ... angelernt.
Auf zwei Datapoints erfolgen Rückmeldungen, wenn ich den Dimmwert in der CCu ändere, auf LEVEL und auf WORKING. Leider kann ich keine neuen Dimwerte über das eingerichtete Gerät vorgeben, es kommt immer die Rückmeldung "HMCCUCHN: CCU.Salon.FUD14_25.Rohrlampe_Bild Invalid datapoint" wenn ich z.B. über den PCT_Slider einen Wert vorgebe. Ich habe bereits den controldatapoint auf LEVEL gesetzt. Leider kommt die o.g. Fehlermeldung wieder.
Wäre dankbar für Tips, angehängt noch die Devicedefinition
define CCU.Salon.FUD14_25.Rohrlampe_Bild HMCCUCHN CUX3601001:1
setuuid CCU.Salon.FUD14_25.Rohrlampe_Bild 6175acff-f33f-187c-a6fb-b32dbfd87bb321dd
attr CCU.Salon.FUD14_25.Rohrlampe_Bild cmdIcon on:general_an off:general_aus
attr CCU.Salon.FUD14_25.Rohrlampe_Bild controldatapoint LEVEL
attr CCU.Salon.FUD14_25.Rohrlampe_Bild room Homematic
attr CCU.Salon.FUD14_25.Rohrlampe_Bild statedatapoint LEVEL
attr CCU.Salon.FUD14_25.Rohrlampe_Bild substexcl pct
attr CCU.Salon.FUD14_25.Rohrlampe_Bild webCmd pct:on:off
attr CCU.Salon.FUD14_25.Rohrlampe_Bild widgetOverride pct:slider,0,10,100
@silvkat: Da hast Du einen wirklich uralten Bug gefunden. Das dürfte auch in der 4.3 nicht funktionieren.
@StephanFHEM: Ich behebe noch den Fehler für CUxD Devices.
@zap
Richtig, das ging auch schon mit der 4.3 nicht (haben meine Tests ergeben), aber ich habe eigentlich gleich mit der 5.0 Beta angefangen und auch wie StephanFhem schon die 4.3 beim Update wieder drüber gebügelt und mich gewundert, warum jetzt alles wieder anders ist ;-)
Wann kannst du diesen Bug denn beseitigen? Ich wollte nämlich meine EnOcea Devices aus Fhem rausnehmen und in die CCU überführen, weil mir ständig das EnOcean in Fhem abschmiert.
Silvio
@silvkat: Bitte mach mal ein Update für die 5.0. Ich denke, es funktioniert jetzt.
@zap
Es geht, ich bin absolut begeistert!!! Falls mir nochwas auffällt mit CuxD melde ich mich wieder.
Danke
CUxD kann manchmal schwierig sein. Speziell auf einer CCU2, da die etwas langsam ist. Da kann es hin und wieder zu Timeouts kommen. Auf einer CCU3 sollte es deutlich besser laufen
Zitat von: zap am 20 Oktober 2021, 14:52:55
Die CCU schickt die Events 2x:
2021.10.20 14:46:56 2: HMCCURPCPROC [d_rpcHmIP_RF] CCUEvent = EV|CB2010001013001021|1634734016|0001D3C990BC3C:3|STATE|1
2021.10.20 14:46:59 2: HMCCURPCPROC [d_rpcHmIP_RF] CCUEvent = EV|CB2010001013001021|1634734019|0001D3C990BC3C:3|STATE|1
2021.10.20 14:47:24 2: HMCCURPCPROC [d_rpcHmIP_RF] CCUEvent = EV|CB2010001013001021|1634734044|0001D3C990BC3C:3|STATE|0
2021.10.20 14:47:26 2: HMCCURPCPROC [d_rpcHmIP_RF] CCUEvent = EV|CB2010001013001021|1634734046|0001D3C990BC3C:3|STATE|0
ZitatZum Verständnis: aber wenn durch das erste CCU-"Event" das state-Reading vom FHEM-Device durch das HMCCU-Modul bspw. auf "on" gesetzt wird, dürfte beim korrekt gesetzt event-on-change-reading-Attribut doch der zweite CCU-"Event", über den das state-Reading wieder mit "on" gesetzt wird, nicht noch einmal einen FHEM-Event auslösen?!
Gruß,
Ralli
Hallo zap,
kannst Du das denn nochmal beantworten? Warum das zweite, gleiche event, bei korrekt gesetztem event-on-change-reading-Attribut trotzdem im FHEM modul durchgelassen wird? Ich verstehe es einfach nicht.
Danke!
HMCCU aktualisiert für jedes Event, das die CCU schickt, das zugehörige Reading. Dazu wird eine interne FHEM Funktion verwendet, die entsprechend die Attribute event-on-xxx berücksichtigt. Das ist alles FHEM Standard. HMCCU filtert nichts.
Update: Also bei meinem HmIP-PSM sieht es so aus:
2.STATE wird nur 1x aktualisiert
3.STATE wird 2x aktualisiert
Hallo zap,
Vielleicht kommt es daher: IMMER wenn ich im Web Frontend auf 'on' (webcmd ''on'') klicke, wird ein event generiert.
Also wenn der Schalter 'on' ist, und ich klicke im FHEMWEB 5 mal auf 'on', wird pro klick ein event generiert, egal wie schnell ich klicke.
Das gleiche bei 'off'.
defmod HMIP_PSM2 HMCCUDEV 0001D709903D2D
attr HMIP_PSM2 IODev HMCCU3
attr HMIP_PSM2 ccureadingfilter (POWER|^ENERGY_COUNTER)
attr HMIP_PSM2 ccureadingname 6.POWER:power;;6.ENERGY_COUNTER:energy
attr HMIP_PSM2 comment DeLonghi PAC EL92 SILENT
attr HMIP_PSM2 devStateIcon off:ios-off on:ios-on-green .*:noIcon
attr HMIP_PSM2 event-on-change-reading power,state
attr HMIP_PSM2 group SCHALTER
attr HMIP_PSM2 room Energy,HomeMaticIP,Schalter
attr HMIP_PSM2 sortby 221
attr HMIP_PSM2 webCmd on:off
2021-10-26 06:49:14.312 HMCCUDEV HMIP_PSM2 off
2021-10-26 06:49:14.993 HMCCUDEV HMIP_PSM2 off
2021-10-26 06:49:15.142 HMCCUDEV HMIP_PSM2 off
2021-10-26 06:49:16.379 HMCCUDEV HMIP_PSM2 off
2021-10-26 06:49:16.961 HMCCUDEV HMIP_PSM2 off
2021-10-26 06:49:17.801 HMCCUDEV HMIP_PSM2 off
2021-10-26 06:49:18.009 HMCCUDEV HMIP_PSM2 off
2021-10-26 06:49:18.183 HMCCUDEV HMIP_PSM2 off
Klar. Aber ich drücke nur 1x auf ON (Schalter ist OFF). Trotzdem schickt die CCU 2 Events. Ich versuche nochmal etwas, damit zumindest das event-on-... funktioniert.
Hallo Zap,
ja danke, ich verstehe es jetzt, mein erstes event kommt einfach beim klicken auf webcmd, das 2-te kommt dann von der CCU.
Ist anders als bei anderen Schaltern mit Rückkanal, aber ich weiss jetzt was passiert.
Danke nochmal
Das Event bei webCmd kann ich bestätigen. Ich denke, das ist das Thema hier: https://forum.fhem.de/index.php?topic=104214.0
Wenn man für den HmIP-PSM event-on-change-reading auf .* setzt, werden zumindest die Readings 2.STATE / 3.STATE nur bei Änderung aktualisiert. Das hat aber keine Auswirkung auf die doppelten on/off Events.
Scheint aktuell also keine Lösung dafür zu geben. Du könntest aber in einem Notify auf 2.STATE triggern.
HMCCU 5.0 ist jetzt offiziell eingecheckt und kann im Standardverfahren des FHEM-Updates bezogen werden.
Hier geht's für die offizielle Version weiter: https://forum.fhem.de/index.php/topic,123686.0.html
Danke zap!
Zitat von: Timmäää am 27 Oktober 2021, 08:07:32
HMCCU 5.0 ist jetzt offiziell eingecheckt und kann im Standardverfahren des FHEM-Updates bezogen werden.
Ja, siehe auch: https://forum.fhem.de/index.php/topic,123686.0.html
Bitte Fragen / Anmerkungen zur 5.0 im oben verlinkten Thread posten. Dieser Thread hier soll für die nächsten Testversionen verwendet werden. Ich beabsichtige, das aktuelle Konstrukt (Testversion in contrib und Github) beizubehalten.
Ihr werdet also in contrib und Github immer den aktuellsten Build (natürlich nicht/wenig getestet) finden.
Hallo Zusammen bin neu in HM-Welt.
Gab ein CCU2 und ein Stromzähler in ccu2 (Aktuelle Firmwareversion:2.59.7) angelernt.
Wenn ich den in fhem anlernen möchte bekomme ich folgende Meldung:
Results of create command:
Not detected CCU devices:
HM-ES-TX-WM NEQ0864302 = NEQ0864302 [HM-ES-TX-WM NEQ0864302]
Ist das bekannte Fehlermeldung ?
Gruß
Zitat von: aperoap am 06 November 2021, 14:25:31
Hallo Zusammen bin neu in HM-Welt.
Gab ein CCU2 und ein Stromzähler in ccu2 (Aktuelle Firmwareversion:2.59.7) angelernt.
Wenn ich den in fhem anlernen möchte bekomme ich folgende Meldung:
Results of create command:
Not detected CCU devices:
HM-ES-TX-WM NEQ0864302 = NEQ0864302 [HM-ES-TX-WM NEQ0864302]
Ist das bekannte Fehlermeldung ?
Gruß
Da bist Du hier im falschen Thread, das hier ist der Homematic-IP thread, dein HM-ES-TX-WM ist aber Homematic OHNE IP.
Am besten mal einen komplett neuen Thread aufmachen, und auch mit schreiben, wie, also mit welchem command Du den HM-ES-TX-WM anlernen wolltest.
Ob das hier hin in den Thread gehört, sei mal dahingestellt (da ich nicht weiß, ob sein Problem an 5.0 liegt), aber ein reiner Homematic-IP Thread ist das hier nicht. Warum auch? Das ist Quatsch,
Im Übrigen hat er sich einfach nur falsch ausgedrückt. In der CCU2 hat er das Teil schon. Er will es nun offenbar nach FHEM bekommen.
Hallo zusammen, ja in CCU2 ist HM-ES-TX-WM schon angelernt. Der CCU2 ist auch mit mein fhem dich hmccu Verbunden. (Durch define d_ccu HMCCU xxxx) und rpcserver ist gestartet. Soweit funktioniert alles. Bei get createDev wird das HM-ES-TX-WM auch angezeigt. Sobald ich den auswegle und auf get klicke, kommt die genannte Fehlermeldung.
Hallo, falls jemand das gleiche Problem hat, bei mir hat das wie folgt funktioniert :
define HM_PM3 HMCCUDEV ccu2.NEQ0864302 1
attr HM_PM3 IODev ccu2
attr HM_PM3 ccureadingfilter .*
attr HM_PM3 controlchannel 1
attr HM_PM3 event-on-update-reading .*
attr HM_PM3 room Homematic
attr HM_PM3 statedatapoint 1.ENERGY_COUNTER
NEQ0864302 1 = der Name in ccu2 chanal 1
Gruß
Juri
@aperoap
Der Befehl "get createDev" unterstützt leider noch nicht alle Gerätetypen. In dem Fall musst Du Dir mit der manuellen Definition behelfen (wie Du es auch gemacht hast).
Bitte poste mal die Ausgabe von "get ccu2 deviceInfo <Name>" und "get ccu2 paramsetDesc <Name>" (die Befehle zeigen eine Auswahlliste mit CCU Geräten an).
Dann nehme ich die Rolle mit auf und get createDev wird dann funktionieren.
Leider gibt es für die alten BidCos Geräte keine richtige Doku. Daher kann ich nur die aufnehmen, die ich selbst besitze oder für die eine DeviceInfo vorliegt.
Hi, folglich die Daten.
"get ccu2 deviceInfo <Name>"
Device channels and datapoints
DEV NEQ0864302 NEQ0864302 interface=BidCos-RF type=HM-ES-TX-WM
CHN NEQ0864302:0 NEQ0864302:0
0.UNREACH = false {b} [RE]
0.STICKY_UNREACH = false {b} [RWE]
0.CONFIG_PENDING = false {b} [RE]
0.LOWBAT = false {b} [RE]
0.RSSI_DEVICE = 1 {n} [RE]
0.RSSI_PEER = 206 {n} [RE]
0.DEVICE_IN_BOOTLOADER = false {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
0.AES_KEY = 0 {n} [R]
CHN NEQ0864302:1 Stromzaehler
1.GAS_ENERGY_COUNTER = 0.000000 {f} [RE]
1.GAS_POWER = 0.000000 {f} [RE]
1.ENERGY_COUNTER = 38799.899963 {f} [RE]
1.POWER = 458.000000 {f} [RE]
1.IEC_ENERGY_COUNTER = 0.000000 {f} [RE]
1.IEC_POWER = 0.000000 {f} [RE]
1.BOOT = false {b} [RE]
CHN NEQ0864302:2 HM-ES-TX-WM NEQ0864302:2
2.IEC_ENERGY_COUNTER = 0.000000 {f} [RE]
2.IEC_POWER = 0.000000 {f} [RE]
Device detection:
No state datapoint detected
No control datapoint detected
Failed to detect device settings. Device must be configured manually.
Current state datapoint = .
Current control datapoint = .
Device description
Device NEQ0864302 NEQ0864302 [HM-ES-TX-WM]
CHILDREN: NEQ0864302:0,NEQ0864302:1,NEQ0864302:2
FIRMWARE: 1.2
FLAGS: Visible
INTERFACE: MEQ1491904
PARAMSETS: MASTER
RF_ADDRESS: 5052486
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG
UPDATABLE: 1
Channel NEQ0864302:0 NEQ0864302:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: NEQ0864302
PARENT_TYPE: HM-ES-TX-WM
Channel NEQ0864302:1 Stromzaehler [POWERMETER_IEC1]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES
PARENT: NEQ0864302
PARENT_TYPE: HM-ES-TX-WM
Channel NEQ0864302:2 HM-ES-TX-WM NEQ0864302:2 [POWERMETER_IEC2]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES
PARENT: NEQ0864302
PARENT_TYPE: HM-ES-TX-WM
get ccu2 paramsetDesc <Name>
Device
Paramset MASTER
BAUDRATE: ENUM [R,W] [Visible,Sticky] RANGE=0...6 DFLT=5 VALUES=300 Bd,600 Bd,1200 Bd,2400 Bd,4800 Bd,9600 Bd,19200 Bd
LOCAL_RESET_DISABLE: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
METER_POWERMODE: ENUM [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0 VALUES=MAINS_POWERED,BATTERY_POWERED
METER_PROTOCOLMODE: ENUM [R,W] [Visible,Sticky] RANGE=0...3 DFLT=3 VALUES=PROTOKOLL_MODE_A,PROTOKOLL_MODE_B,PROTOKOLL_MODE_C,PROTOKOLL_MODE_D
SAMPLES_PER_CYCLE: INTEGER [R,W] [Visible,Sticky] RANGE=1...10 DFLT=4
SERIAL_FORMAT: ENUM [R,W] [Visible,Sticky] RANGE=0...3 DFLT=0 VALUES=1_7D_1P_E_1S,1_7D_1P_E_2S,1_8D_0P_N_1S,1_8D_1P_E_1S
Channel 0
Paramset VALUES
AES_KEY: INTEGER [R] [] RANGE=0...127 DFLT=0
CONFIG_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
DEVICE_IN_BOOTLOADER: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
LOWBAT: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
RSSI_DEVICE: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648...2147483647 DFLT=0
RSSI_PEER: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648...2147483647 DFLT=0
STICKY_UNREACH: BOOL [R,W,E] [Sticky,Internal] RANGE=0...1 DFLT=0
UNREACH: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
UPDATE_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
Channel 1
Paramset MASTER
AES_ACTIVE: BOOL [R,W] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
ENERGY_COUNTER_STRING: STRING [R,W] [Visible,Sticky] RANGE=... DFLT=
METER_CONSTANT_GAS: FLOAT [R,W] [Visible,Sticky] RANGE=0.001...65.536 DFLT=0.01 UNIT=m3/Imp.
METER_CONSTANT_IR: INTEGER [R,W] [Visible,Sticky] RANGE=1...65536 DFLT=100 UNIT=U./kWh
METER_CONSTANT_LED: INTEGER [R,W] [Visible,Sticky] RANGE=1...65536 DFLT=10000 UNIT=Imp./kWh
METER_SENSIBILITY_IR: INTEGER [R,W] [Visible,Sticky] RANGE=-99...99 DFLT=0 UNIT=%
METER_TYPE: ENUM [R,W] [Visible,Sticky] RANGE=0...4 DFLT=4 VALUES=GAS-SENSOR,IR-SENSOR,LED-SENSOR,IEC-SENSOR,UNKOWN
POWER_STRING: STRING [R,W] [Visible,Sticky] RANGE=... DFLT=
TX_THRESHOLD_POWER: FLOAT [R,W] [Visible,Sticky] RANGE=0.01...160000 DFLT=100 UNIT=W
Paramset VALUES
BOOT: BOOL [R,E] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
ENERGY_COUNTER: FLOAT [R,E] [Visible,Sticky] RANGE=0...838861 DFLT=0 UNIT=Wh
GAS_ENERGY_COUNTER: FLOAT [R,E] [Visible,Sticky] RANGE=0...2.14748e+06 DFLT=0 UNIT=m3
GAS_POWER: FLOAT [R,E] [Visible,Sticky] RANGE=0...16777.2 DFLT=0 UNIT=m3
IEC_ENERGY_COUNTER: FLOAT [R,E] [Visible,Sticky] RANGE=0...1.09951e+08 DFLT=0 UNIT=kWh
IEC_POWER: FLOAT [R,E] [Visible,Sticky] RANGE=0...4.29497e+07 DFLT=0 UNIT=W
POWER: FLOAT [R,E] [Visible,Sticky] RANGE=0...167772 DFLT=0 UNIT=W
Channel 2
Paramset MASTER
AES_ACTIVE: BOOL [R,W] [Visible,Sticky,Internal] RANGE=0...1 DFLT=0
ENERGY_COUNTER_STRING: STRING [R,W] [Visible,Sticky] RANGE=... DFLT=
METER_TYPE: ENUM [R,W] [Visible,Sticky] RANGE=0...4 DFLT=4 VALUES=GAS-SENSOR,IR-SENSOR,LED-SENSOR,IEC-SENSOR,UNKOWN
POWER_STRING: STRING [R,W] [Visible,Sticky] RANGE=... DFLT=
TX_THRESHOLD_POWER: FLOAT [R,W] [Visible,Sticky] RANGE=0.01...160000 DFLT=100 UNIT=W
Paramset VALUES
IEC_ENERGY_COUNTER: FLOAT [R,E] [Visible,Sticky] RANGE=0...1.09951e+08 DFLT=0 UNIT=kWh
IEC_POWER: FLOAT [R,E] [Visible,Sticky] RANGE=0...4.29497e+07 DFLT=0 UNIT=W
Danke LG Juri
Hi,
hiernoch die Werte für ip hub
"get ccu2 deviceInfo <Name>"
Device channels and datapoints
DEV HmIP-HAP 0003DBE98D317C 0003DBE98D317C interface=HmIP-RF type=HmIP-HAP
CHN 0003DBE98D317C:0 HmIP-HAP 0003DBE98D317C:0
0.CARRIER_SENSE_LEVEL = 0.000000 {f} [RE]
0.CONFIG_PENDING = false {b} [RE]
0.DUTY_CYCLE = false {b} [RE]
0.DUTY_CYCLE_LEVEL = 0.500000 {f} [RE]
0.INSTALL_TEST = true {b} [RW]
0.IP_ADDRESS = 192.168.XXX.XXX {s} [RE]
0.UNREACH = false {b} [RE]
Device detection:
No state datapoint detected
No control datapoint detected
Failed to detect device settings. Device must be configured manually.
Current state datapoint = 1.PRESS_SHORT
Current control datapoint = 1.PRESS_SHORT
Device description
Device 0003DBE98D317C HmIP-HAP 0003DBE98D317C [HmIP-HAP]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 2.2.18
CHILDREN: 0003DBE98D317C:0
DIRECTION: NONE
FIRMWARE: 2.2.18
FIRMWARE_UPDATE_STATE: LIVE_UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 11500463
ROAMING: 0
RX_MODE:
SUBTYPE: HAP
UPDATABLE: 1
Channel 0003DBE98D317C:0 HmIP-HAP 0003DBE98D317C:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 0003DBE98D317C
PARENT_TYPE: HmIP-HAP
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
get ccu2 paramsetDesc <Name>
Device
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Channel 0
Paramset MASTER
ACCESSPOINT_PRIOR: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
ARR_TIMEOUT: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=10 UNIT=s
BACKBONE_MULTICAST_ADDRESS: STRING [R,W] [Visible,Sticky] RANGE=...^(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$ DFLT=239.255.0.1
CYCLIC_INFO_MSG: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=1
CYCLIC_INFO_MSG_DIS: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=1
CYCLIC_INFO_MSG_DIS_UNCHANGED: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
CYCLIC_INFO_MSG_OVERDUE_THRESHOLD: INTEGER [R,W] [Visible,Sticky] RANGE=0...2147483647 DFLT=2
DISABLE_MSG_TO_AC: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
ENABLE_ROUTING: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=1
LOCAL_RESET_DISABLED: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
ROUTER_MODULE_ENABLED: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
ROUTER_OPTIONS: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=0
SIGNAL_BRIGHTNESS: FLOAT [R,W] [Visible,Sticky] RANGE=0...1 DFLT=1
UPDATE_SERVER_REQUEST_INTERVAL: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=12
UPDATE_SERVER_URL: STRING [R,W] [Visible,Sticky] RANGE=...[0x00-0x7E]{127} DFLT=
WEB_SOCKET_CONNECTION_DELAY_FACTOR_UNIT: ENUM [R,W] [Visible,Sticky] RANGE=100MS...H DFLT=S VALUES=100MS,S,M,H
WEB_SOCKET_CONNECTION_DELAY_FACTOR_VALUE: INTEGER [R,W] [Visible,Sticky] RANGE=0...63 DFLT=30
WEB_SOCKET_CONNECTION_DELAY_UNIT: ENUM [R,W] [Visible,Sticky] RANGE=100MS...H DFLT=S VALUES=100MS,S,M,H
WEB_SOCKET_CONNECTION_DELAY_VALUE: INTEGER [R,W] [Visible,Sticky] RANGE=0...63 DFLT=10
Paramset SERVICE
APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
Paramset VALUES
CARRIER_SENSE_LEVEL: FLOAT [R,E] [Visible,Sticky] RANGE=0...100 DFLT=0 UNIT=%
CONFIG_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
DUTY_CYCLE: BOOL [R,E] [Visible,Sticky] RANGE=0...1 DFLT=0
DUTY_CYCLE_LEVEL: FLOAT [R,E] [Visible,Sticky] RANGE=0...100 DFLT=0 UNIT=%
INSTALL_TEST: BOOL [R,W] [Internal] RANGE=0...1 DFLT=0
IP_ADDRESS: STRING [R,E] [Visible,Sticky] RANGE=... DFLT=
UNREACH: BOOL [R,E] [Sticky,Internal] RANGE=0...1 DFLT=0
LG
Juri
Hallo,
vielen Dank für die Arbeit und Zeit, die du da investierst.
Hier noch die Daten von einen
Funk-Controller für Dual-White-LEDs
get ccu2 deviceInfo HM-LC-DW-WM
Device channels and datapoints
DEV HM_Dual_White_DEV PEQ0549147 interface=BidCos-RF type=HM-LC-DW-WM
CHN PEQ0549147:0 HM_Dual_White_DEV:0
0.UNREACH = false {b} [RE]
0.STICKY_UNREACH = false {b} [RWE]
0.CONFIG_PENDING = false {b} [RE]
0.DUTYCYCLE = false {b} [RE]
0.RSSI_DEVICE = 1 {n} [RE]
0.RSSI_PEER = 1 {n} [RE]
0.DEVICE_IN_BOOTLOADER = false {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
0.AES_KEY = 0 {n} [R]
CHN PEQ0549147:1 HM_Dual_White:1
1.LEVEL_REAL = 0.000000 {f} [RE]
1.LEVEL = 0.000000 {f} [RWE]
1.OLD_LEVEL = {b} [W]
1.RAMP_TIME = {f} [W]
1.ON_TIME = {f} [W]
1.RAMP_STOP = {b} [W]
1.INHIBIT = false {b} [RWE]
1.ERROR_REDUCED = false {b} [RE]
1.ERROR_OVERHEAT = false {b} [RE]
1.DIRECTION = 0 {i} [RE]
1.INSTALL_TEST = {b} [W]
1.WORKING = false {b} [RE]
CHN PEQ0549147:2 HM_Dual_White:2
2.LEVEL_REAL = 0.500000 {f} [RE]
2.LEVEL = 0.500000 {f} [RWE]
2.OLD_LEVEL = {b} [W]
2.RAMP_TIME = {f} [W]
2.ON_TIME = {f} [W]
2.RAMP_STOP = {b} [W]
2.INHIBIT = false {b} [RWE]
2.DIRECTION = 0 {i} [RE]
2.INSTALL_TEST = {b} [W]
2.WORKING = false {b} [RE]
CHN PEQ0549147:3 HM-LC-DW-WM PEQ0549147:3
3.LEVEL_REAL = 0.000000 {f} [RE]
3.LEVEL = 1.000000 {f} [RWE]
3.OLD_LEVEL = {b} [W]
3.RAMP_TIME = {f} [W]
3.ON_TIME = {f} [W]
3.RAMP_STOP = {b} [W]
3.INHIBIT = false {b} [RWE]
3.ERROR_REDUCED = false {b} [RE]
3.ERROR_OVERHEAT = false {b} [RE]
3.DIRECTION = 0 {i} [RE]
3.INSTALL_TEST = {b} [W]
3.WORKING = false {b} [RE]
CHN PEQ0549147:4 HM-LC-DW-WM PEQ0549147:4
4.LEVEL_REAL = 0.500000 {f} [RE]
4.LEVEL = 1.000000 {f} [RWE]
4.OLD_LEVEL = {b} [W]
4.RAMP_TIME = {f} [W]
4.ON_TIME = {f} [W]
4.RAMP_STOP = {b} [W]
4.INHIBIT = false {b} [RWE]
4.DIRECTION = 0 {i} [RE]
4.INSTALL_TEST = {b} [W]
4.WORKING = false {b} [RE]
CHN PEQ0549147:5 HM-LC-DW-WM PEQ0549147:5
5.LEVEL_REAL = 0.000000 {f} [RE]
5.LEVEL = 1.000000 {f} [RWE]
5.OLD_LEVEL = {b} [W]
5.RAMP_TIME = {f} [W]
5.ON_TIME = {f} [W]
5.RAMP_STOP = {b} [W]
5.INHIBIT = false {b} [RWE]
5.ERROR_REDUCED = false {b} [RE]
5.ERROR_OVERHEAT = false {b} [RE]
5.DIRECTION = 0 {i} [RE]
5.INSTALL_TEST = {b} [W]
5.WORKING = false {b} [RE]
CHN PEQ0549147:6 HM-LC-DW-WM PEQ0549147:6
6.LEVEL_REAL = 0.500000 {f} [RE]
6.LEVEL = 1.000000 {f} [RWE]
6.OLD_LEVEL = {b} [W]
6.RAMP_TIME = {f} [W]
6.ON_TIME = {f} [W]
6.RAMP_STOP = {b} [W]
6.INHIBIT = false {b} [RWE]
6.DIRECTION = 0 {i} [RE]
6.INSTALL_TEST = {b} [W]
6.WORKING = false {b} [RE]
Device detection:
No state datapoint detected
No control datapoint detected
Failed to detect device settings. Device must be configured manually.
Current state datapoint = 1.PRESS_SHORT
Current control datapoint = 1.PRESS_SHORT
Device description
Device PEQ0549147 HM_Dual_White_DEV [HM-LC-DW-WM]
CHILDREN: PEQ0549147:0,PEQ0549147:1,PEQ0549147:2,PEQ0549147:3,PEQ0549147:4,PEQ0549147:5,PEQ0549147:6
FIRMWARE: 2.12
FLAGS: Visible
INTERFACE: QEQ0684974
PARAMSETS: MASTER
RF_ADDRESS: 6915118
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG
UPDATABLE: 1
Channel PEQ0549147:0 HM_Dual_White_DEV:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: PEQ0549147
PARENT_TYPE: HM-LC-DW-WM
Channel PEQ0549147:1 HM_Dual_White:1 [DUAL_WHITE_BRIGHTNESS]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: PEQ0549147
PARENT_TYPE: HM-LC-DW-WM
Channel PEQ0549147:2 HM_Dual_White:2 [DUAL_WHITE_COLOR]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: PEQ0549147
PARENT_TYPE: HM-LC-DW-WM
Channel PEQ0549147:3 HM-LC-DW-WM PEQ0549147:3 [VIRTUAL_DUAL_WHITE_BRIGHTNESS]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: PEQ0549147
PARENT_TYPE: HM-LC-DW-WM
Channel PEQ0549147:4 HM-LC-DW-WM PEQ0549147:4 [VIRTUAL_DUAL_WHITE_COLOR]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: PEQ0549147
PARENT_TYPE: HM-LC-DW-WM
Channel PEQ0549147:5 HM-LC-DW-WM PEQ0549147:5 [VIRTUAL_DUAL_WHITE_BRIGHTNESS]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: PEQ0549147
PARENT_TYPE: HM-LC-DW-WM
Channel PEQ0549147:6 HM-LC-DW-WM PEQ0549147:6 [VIRTUAL_DUAL_WHITE_COLOR]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: PEQ0549147
PARENT_TYPE: HM-LC-DW-WM
Die Daten von paramsetDesc HM-LC-DW-WM habe ich als Datei angehängt da sie vorher nicht komplett waren
@Benjamin50
Die Liste wäre als Textdatei eventl. weniger Bildschirmfüllend :D
Gruß Gerd
hier noch eine Kleinigkeit aus dem Log... ist mir gerade bei Neustart aufgefallen mit der neusten Version. Keine Ahnung obs vorher schon drin war:
PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 4824
ich hab da auch noch was:
2021.11.13 04:00:00 3: reboot: -1
2021.11.13 04:00:00 1: HMCCU [CCU3] Graceful shutdown in 8 seconds
2021.11.13 04:00:00 1: HMCCURPCPROC [d_rpc002177BidCos_RF] Stopping RPC server CB2001002133002177
2021.11.13 04:00:00 1: HMCCURPCPROC [d_rpc002177BidCos_RF] Deregistering RPC server http://192.168.2.133:7411/fh2001 with ID CB2001002133002177 at http://fhem:01967@192.168.2.177:2001
2021.11.13 04:00:00 1: HMCCURPCPROC [d_rpc002177BidCos_RF] Callback for RPC server CB2001002133002177 deregistered
2021.11.13 04:00:00 2: HMCCURPCPROC [d_rpc002177BidCos_RF] Sending signal INT to RPC server process CB2001002133002177 with PID=1796
2021.11.13 04:00:00 2: HMCCURPCPROC [d_rpc002177BidCos_RF] CB2001002133002177 received signal INT
2021.11.13 04:00:00 1: HMCCURPCPROC [d_rpc002177BidCos_RF] RPC server CB2001002133002177 stopped handling connections. PID=1796
2021.11.13 04:00:00 2: HMCCURPCPROC [d_rpc002177BidCos_RF] Number of I/O errors = 0
2021.11.13 04:00:00 2: HMCCURPCPROC [d_rpc002177BidCos_RF] Cleaning up immediately
2021.11.13 04:00:00 1: HMCCURPCPROC [d_rpc002177BidCos_RF] Housekeeping called. Cleaning up RPC environment
2021.11.13 04:00:02 2: HMCCURPCPROC [d_rpc002177BidCos_RF] RPC server process CB2001002133002177 deleted
2021.11.13 04:00:02 2: HMCCURPCPROC [d_rpc002177BidCos_RF] Stop I/O handling
2021.11.13 04:00:02 2: HMCCURPCPROC [d_rpc002177BidCos_RF] RPC server stopped. Cancel delayed shutdown.
2021.11.13 04:00:03 1: HMCCURPCPROC [d_rpc002177HmIP_RF] Stopping RPC server CB2010002133002177
2021.11.13 04:00:03 1: HMCCURPCPROC [d_rpc002177HmIP_RF] Deregistering RPC server http://192.168.2.133:7420/fh2010 with ID CB2010002133002177 at http://fhem:01967@192.168.2.177:2010
2021.11.13 04:00:03 1: HMCCURPCPROC [d_rpc002177HmIP_RF] Callback for RPC server CB2010002133002177 deregistered
2021.11.13 04:00:03 2: HMCCURPCPROC [d_rpc002177HmIP_RF] Sending signal INT to RPC server process CB2010002133002177 with PID=1797
2021.11.13 04:00:03 2: HMCCURPCPROC [d_rpc002177HmIP_RF] Cleaning up immediately
2021.11.13 04:00:03 2: HMCCURPCPROC [d_rpc002177HmIP_RF] CB2010002133002177 received signal INT
2021.11.13 04:00:03 1: HMCCURPCPROC [d_rpc002177HmIP_RF] Housekeeping called. Cleaning up RPC environment
2021.11.13 04:00:03 2: HMCCURPCPROC [d_rpc002177HmIP_RF] CB2010002133002177 received signal INT
2021.11.13 04:00:03 1: HMCCURPCPROC [d_rpc002177HmIP_RF] RPC server CB2010002133002177 stopped handling connections. PID=1797
2021.11.13 04:00:03 2: HMCCURPCPROC [d_rpc002177HmIP_RF] Number of I/O errors = 0
2021.11.13 04:00:05 2: HMCCURPCPROC [d_rpc002177HmIP_RF] RPC server process CB2010002133002177 deleted
2021.11.13 04:00:05 1: HMCCU [CCU3] All RPC servers inactive
2021.11.13 04:00:05 2: HMCCURPCPROC [d_rpc002177HmIP_RF] Stop I/O handling
2021.11.13 04:00:05 2: HMCCURPCPROC [d_rpc002177HmIP_RF] RPC server stopped. Cancel delayed shutdown.
2021.11.13 04:00:06 2: DbLog fhemlogDB - Last database write cycle due to shutdown ...
2021.11.13 04:00:06 1: Server shutdown delayed due to CCU3,d_rpc002177BidCos_RF,d_rpc002177HmIP_RF,fhemlogDB for max 10 sec
2021.11.13 04:00:06 1: ERROR: Select error -1 (3), error count= 0
Select error -1 (3)
Im Hintergrund arbeitet systemd und fährt bereits alles runter. FHEM ist dann ziemlich einsam auf dem System greift sich alles an resourcen die zu kriegen sind, CPU und RAM, einschlieslich swap.
Im Journal findet man dann so was:
Nov 12 21:34:05 raspi4 kernel: systemd-journal invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=0
Nov 12 21:34:05 raspi4 kernel: CPU: 1 PID: 133 Comm: systemd-journal Tainted: G D C 5.10.63-v7l+ #1459
Nov 12 21:34:05 raspi4 kernel: Hardware name: BCM2711
Nov 12 21:34:05 raspi4 kernel: Backtrace:
Nov 12 21:34:05 raspi4 kernel: [<c0b83534>] (dump_backtrace) from [<c0b838c8>] (show_stack+0x20/0x24)
Nov 12 21:34:05 raspi4 kernel: r7:ffffffff r6:00000000 r5:60000013 r4:c12e6b3c
Nov 12 21:34:05 raspi4 kernel: [<c0b838a8>] (show_stack) from [<c0b87cb4>] (dump_stack+0xcc/0xf8)
Nov 12 21:34:05 raspi4 kernel: [<c0b87be8>] (dump_stack) from [<c0b85f44>] (dump_header+0x64/0x208)
Nov 12 21:34:05 raspi4 kernel: r10:c12051cc r9:00000cc0 r8:00000000 r7:c0e3bb74 r6:c2e07900 r5:c638ec80
Nov 12 21:34:05 raspi4 kernel: r4:c33a5e70 r3:88164867
Nov 12 21:34:05 raspi4 kernel: [<c0b85ee0>] (dump_header) from [<c03b9070>] (oom_kill_process+0x1b4/0x1c0)
Nov 12 21:34:05 raspi4 kernel: r7:c0e3bb74 r6:c33a5e70 r5:c638f200 r4:c638ec80
Nov 12 21:34:05 raspi4 kernel: [<c03b8ebc>] (oom_kill_process) from [<c03b9be8>] (out_of_memory+0x2b8/0x390)
Nov 12 21:34:05 raspi4 kernel: r7:c12085c0 r6:c1205048 r5:c638ec80 r4:c33a5e70
Nov 12 21:34:05 raspi4 kernel: [<c03b9930>] (out_of_memory) from [<c040d260>] (__alloc_pages_nodemask+0x7ec/0x1184)
Nov 12 21:34:05 raspi4 kernel: r7:c1337ed0 r6:00001400 r5:0001468c r4:00000000
Nov 12 21:34:05 raspi4 kernel: [<c040ca74>] (__alloc_pages_nodemask) from [<c040dc1c>] (__get_free_pages+0x24/0x3c)
Nov 12 21:34:05 raspi4 kernel: r10:00001000 r9:00000000 r8:023e8568 r7:00001000 r6:c1205048 r5:c252e568
Nov 12 21:34:05 raspi4 kernel: r4:00000000
Nov 12 21:34:05 raspi4 kernel: [<c040dbf8>] (__get_free_pages) from [<c04e3d48>] (proc_pid_readlink+0x88/0x170)
Nov 12 21:34:05 raspi4 kernel: [<c04e3cc0>] (proc_pid_readlink) from [<c044b824>] (vfs_readlink+0x128/0x13c)
Nov 12 21:34:05 raspi4 kernel: r8:00001000 r7:023e8568 r6:c3b2e330 r5:c1205048 r4:c252e568
Nov 12 21:34:05 raspi4 kernel: [<c044b6fc>] (vfs_readlink) from [<c0444650>] (do_readlinkat+0x108/0x128)
Nov 12 21:34:05 raspi4 kernel: r8:c1205048 r7:00000002 r6:bed49270 r5:ffffff9c r4:c33a5f58
Nov 12 21:34:05 raspi4 kernel: [<c0444548>] (do_readlinkat) from [<c0444cc8>] (sys_readlinkat+0x18/0x1c)
Nov 12 21:34:05 raspi4 kernel: r10:0000014c r9:c33a4000 r8:c0200204 r7:0000014c r6:00001000 r5:023e8568
Nov 12 21:34:05 raspi4 kernel: r4:00001001
Nov 12 21:34:05 raspi4 kernel: [<c0444cb0>] (sys_readlinkat) from [<c02001e4>] (__sys_trace_return+0x0/0x1c)
Nov 12 21:34:05 raspi4 kernel: Exception stack(0xc33a5fa8 to 0xc33a5ff0)
Nov 12 21:34:05 raspi4 kernel: 5fa0: 00001001 023e8568 ffffff9c bed49270 023e8568 00001000
Nov 12 21:34:05 raspi4 kernel: 5fc0: 00001001 023e8568 00001000 0000014c ffffff9c bed492b8 00000000 bed492ac
Nov 12 21:34:05 raspi4 kernel: 5fe0: b6e1cc48 bed4922c b6c6c5bc b6ee7b6c
Nov 12 21:34:05 raspi4 kernel: Mem-Info:
Nov 12 21:34:05 raspi4 kernel: active_anon:245 inactive_anon:177774 isolated_anon:0
active_file:14429 inactive_file:71363 isolated_file:0
unevictable:31028 dirty:6 writeback:0
slab_reclaimable:4892 slab_unreclaimable:60457
mapped:58014 shmem:4703 pagetables:2678 bounce:0
free:1648070 free_pcp:247 free_cma:79279
Nov 12 21:34:05 raspi4 kernel: Node 0 active_anon:980kB inactive_anon:711096kB active_file:57716kB inactive_file:285452kB unevictable:124112kB isolated(anon):0kB isolated(file):0kB mapped:232056kB dirty:24kB writ
Nov 12 21:34:05 raspi4 kernel: DMA free:333668kB min:20480kB low:24576kB high:28672kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:180kB inactive_file:504kB unevictable:0kB writepending:0
Nov 12 21:34:05 raspi4 kernel: lowmem_reserve[]: 0 0 7284 7284
Nov 12 21:34:05 raspi4 kernel: HighMem free:6258612kB min:512kB low:49044kB high:97576kB reserved_highatomic:0KB active_anon:980kB inactive_anon:711096kB active_file:57716kB inactive_file:284592kB unevictable:124
Nov 12 21:34:05 raspi4 kernel: lowmem_reserve[]: 0 0 0 0
Nov 12 21:34:05 raspi4 kernel: DMA: 430*4kB (UEC) 731*8kB (UEC) 246*16kB (EC) 89*32kB (EC) 22*64kB (EC) 8*128kB (UEC) 5*256kB (C) 4*512kB (UC) 4*1024kB (C) 3*2048kB (C) 74*4096kB (C) = 333456kB
Nov 12 21:34:05 raspi4 kernel: HighMem: 1*4kB (M) 9794*8kB (UM) 6384*16kB (UM) 2971*32kB (UM) 1343*64kB (UM) 519*128kB (UM) 136*256kB (UM) 38*512kB (UM) 19*1024kB (UM) 13*2048kB (UM) 1399*4096kB (M) = 6258612kB
Nov 12 21:34:05 raspi4 kernel: 108409 total pagecache pages
Nov 12 21:34:05 raspi4 kernel: 0 pages in swap cache
Nov 12 21:34:05 raspi4 kernel: Swap cache stats: add 0, delete 0, find 0/0
Nov 12 21:34:05 raspi4 kernel: Free swap = 17550372kB
Nov 12 21:34:05 raspi4 kernel: Total swap = 17550372kB
Nov 12 21:34:05 raspi4 kernel: 2061312 pages RAM
Nov 12 21:34:05 raspi4 kernel: 1864704 pages HighMem/MovableOnly
Nov 12 21:34:05 raspi4 kernel: 39237 pages reserved
Nov 12 21:34:05 raspi4 kernel: 81920 pages cma reserved
Nov 12 21:34:05 raspi4 kernel: Tasks state (memory values in pages):
Nov 12 21:34:05 raspi4 kernel: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
Nov 12 21:34:05 raspi4 kernel: [ 133] 0 133 11499 4114 225280 0 0 systemd-journal
Nov 12 21:34:05 raspi4 kernel: [ 155] 0 155 4648 1032 53248 0 -1000 systemd-udevd
Nov 12 21:34:05 raspi4 kernel: [ 458] 0 458 6378 686 49152 0 0 rsyslogd
Nov 12 21:34:05 raspi4 kernel: [ 462] 0 462 1987 580 40960 0 0 cron
Nov 12 21:34:05 raspi4 kernel: [ 468] 0 468 15858 2585 94208 0 0 udisksd
Nov 12 21:34:05 raspi4 kernel: [ 472] 1000 472 44444 22961 909312 0 0 node
Nov 12 21:34:05 raspi4 kernel: [ 480] 0 480 3283 1412 53248 0 0 systemd-logind
Nov 12 21:34:05 raspi4 kernel: [ 481] 104 481 1739 979 40960 0 -900 dbus-daemon
Nov 12 21:34:05 raspi4 kernel: [ 483] 0 483 2677 1151 45056 0 0 wpa_supplicant
Nov 12 21:34:05 raspi4 kernel: [ 494] 0 494 726 472 32768 0 0 dhcpcd
Nov 12 21:34:05 raspi4 kernel: [ 505] 108 505 1474 736 40960 0 0 avahi-daemon
Nov 12 21:34:05 raspi4 kernel: [ 512] 0 512 6978 1729 73728 0 0 cupsd
Nov 12 21:34:05 raspi4 kernel: [ 514] 65534 514 1080 548 36864 0 0 thd
Nov 12 21:34:05 raspi4 kernel: [ 519] 108 519 1442 63 32768 0 0 avahi-daemon
Nov 12 21:34:05 raspi4 kernel: [ 522] 0 522 2946 1155 49152 0 0 alsactl
Nov 12 21:34:05 raspi4 kernel: [ 534] 0 534 6914 20 40960 0 0 rngd
Nov 12 21:34:05 raspi4 kernel: [ 541] 0 541 836 438 28672 0 0 atd
Nov 12 21:34:05 raspi4 kernel: [ 544] 0 544 2484 1221 45056 0 0 bluetoothd
Nov 12 21:34:05 raspi4 kernel: [ 556] 0 556 9682 1749 65536 0 0 polkitd
Nov 12 21:34:05 raspi4 kernel: [ 564] 0 564 10084 2162 73728 0 0 cups-browsed
Nov 12 21:34:05 raspi4 kernel: [ 572] 0 572 94209 16977 348160 0 0 collectord1
Nov 12 21:34:05 raspi4 kernel: [ 581] 7 581 3458 1203 49152 0 0 dbus
Nov 12 21:34:05 raspi4 kernel: [ 582] 0 582 7995 2414 90112 0 0 nmbd
Nov 12 21:34:05 raspi4 kernel: [ 583] 0 583 1961 90 32768 0 0 xrdp-sesman
Nov 12 21:34:05 raspi4 kernel: [ 588] 118 588 2194 1233 45056 0 0 mosquitto
Nov 12 21:34:05 raspi4 kernel: [ 591] 0 591 1272 667 36864 0 0 inetd
Nov 12 21:34:05 raspi4 kernel: [ 594] 0 594 94235 17018 348160 0 0 collectord
Nov 12 21:34:05 raspi4 kernel: [ 618] 114 618 46905 8014 258048 0 0 mpd
Nov 12 21:34:05 raspi4 kernel: [ 622] 0 622 2774 1060 45056 0 0 wpa_supplicant
Nov 12 21:34:05 raspi4 kernel: [ 630] 126 630 24371 21176 217088 0 0 squeezeboxserve
Nov 12 21:34:05 raspi4 kernel: [ 638] 113 638 1986 702 36864 0 0 ntpd
Nov 12 21:34:05 raspi4 kernel: [ 641] 0 641 1395 490 36864 0 0 vsftpd
Nov 12 21:34:05 raspi4 kernel: [ 646] 0 646 15260 1009 73728 0 0 automount
Nov 12 21:34:05 raspi4 kernel: [ 647] 125 647 8890 2726 94208 0 0 snmpd
Nov 12 21:34:05 raspi4 kernel: [ 651] 0 651 2673 1398 49152 0 -1000 sshd
Nov 12 21:34:05 raspi4 kernel: [ 680] 0 680 29589 27234 262144 0 0 squeezelite
Nov 12 21:34:05 raspi4 kernel: [ 694] 0 694 614 39 28672 0 0 ser2net
Nov 12 21:34:05 raspi4 kernel: [ 714] 0 714 11681 1503 61440 0 0 lightdm
Nov 12 21:34:05 raspi4 kernel: [ 747] 111 747 1945 413 36864 0 0 xrdp
Nov 12 21:34:05 raspi4 kernel: [ 764] 0 764 33066 12517 258048 0 0 Xorg
Nov 12 21:34:05 raspi4 kernel: [ 765] 0 765 1405 630 40960 0 0 login
Nov 12 21:34:05 raspi4 kernel: [ 973] 119 973 3592 546 53248 0 0 exim4
Nov 12 21:34:05 raspi4 kernel: [ 990] 0 990 7477 1556 65536 0 0 lightdm
Nov 12 21:34:05 raspi4 kernel: [ 1001] 1000 1001 3702 1835 57344 0 0 systemd
Nov 12 21:34:05 raspi4 kernel: [ 472] 1000 472 44444 22961 909312 0 0 node
Nov 12 21:34:05 raspi4 kernel: [ 480] 0 480 3283 1412 53248 0 0 systemd-logind
Nov 12 21:34:05 raspi4 kernel: [ 481] 104 481 1739 979 40960 0 -900 dbus-daemon
Nov 12 21:34:05 raspi4 kernel: [ 483] 0 483 2677 1151 45056 0 0 wpa_supplicant
Nov 12 21:34:05 raspi4 kernel: [ 494] 0 494 726 472 32768 0 0 dhcpcd
Nov 12 21:34:05 raspi4 kernel: [ 505] 108 505 1474 736 40960 0 0 avahi-daemon
Nov 12 21:34:05 raspi4 kernel: [ 512] 0 512 6978 1729 73728 0 0 cupsd
Nov 12 21:34:05 raspi4 kernel: [ 514] 65534 514 1080 548 36864 0 0 thd
Nov 12 21:34:05 raspi4 kernel: [ 519] 108 519 1442 63 32768 0 0 avahi-daemon
Nov 12 21:34:05 raspi4 kernel: [ 522] 0 522 2946 1155 49152 0 0 alsactl
Nov 12 21:34:05 raspi4 kernel: [ 534] 0 534 6914 20 40960 0 0 rngd
Nov 12 21:34:05 raspi4 kernel: [ 541] 0 541 836 438 28672 0 0 atd
Nov 12 21:34:05 raspi4 kernel: [ 544] 0 544 2484 1221 45056 0 0 bluetoothd
Nov 12 21:34:05 raspi4 kernel: [ 556] 0 556 9682 1749 65536 0 0 polkitd
Nov 12 21:34:05 raspi4 kernel: [ 564] 0 564 10084 2162 73728 0 0 cups-browsed
Nov 12 21:34:05 raspi4 kernel: [ 572] 0 572 94209 16977 348160 0 0 collectord1
Nov 12 21:34:05 raspi4 kernel: [ 581] 7 581 3458 1203 49152 0 0 dbus
Nov 12 21:34:05 raspi4 kernel: [ 582] 0 582 7995 2414 90112 0 0 nmbd
Nov 12 21:34:05 raspi4 kernel: [ 583] 0 583 1961 90 32768 0 0 xrdp-sesman
Nov 12 21:34:05 raspi4 kernel: [ 588] 118 588 2194 1233 45056 0 0 mosquitto
Nov 12 21:34:05 raspi4 kernel: [ 591] 0 591 1272 667 36864 0 0 inetd
Nov 12 21:34:05 raspi4 kernel: [ 594] 0 594 94235 17018 348160 0 0 collectord
Nov 12 21:34:05 raspi4 kernel: [ 618] 114 618 46905 8014 258048 0 0 mpd
Nov 12 21:34:05 raspi4 kernel: [ 622] 0 622 2774 1060 45056 0 0 wpa_supplicant
Nov 12 21:34:05 raspi4 kernel: [ 630] 126 630 24371 21176 217088 0 0 squeezeboxserve
Nov 12 21:34:05 raspi4 kernel: [ 638] 113 638 1986 702 36864 0 0 ntpd
Nov 12 21:34:05 raspi4 kernel: [ 641] 0 641 1395 490 36864 0 0 vsftpd
Nov 12 21:34:05 raspi4 kernel: [ 646] 0 646 15260 1009 73728 0 0 automount
Nov 12 21:34:05 raspi4 kernel: [ 647] 125 647 8890 2726 94208 0 0 snmpd
Nov 12 21:34:05 raspi4 kernel: [ 651] 0 651 2673 1398 49152 0 -1000 sshd
Nov 12 21:34:05 raspi4 kernel: [ 680] 0 680 29589 27234 262144 0 0 squeezelite
Nov 12 21:34:05 raspi4 kernel: [ 694] 0 694 614 39 28672 0 0 ser2net
Nov 12 21:34:05 raspi4 kernel: [ 714] 0 714 11681 1503 61440 0 0 lightdm
Nov 12 21:34:05 raspi4 kernel: [ 747] 111 747 1945 413 36864 0 0 xrdp
Nov 12 21:34:05 raspi4 kernel: [ 764] 0 764 33066 12517 258048 0 0 Xorg
Nov 12 21:34:05 raspi4 kernel: [ 765] 0 765 1405 630 40960 0 0 login
Nov 12 21:34:05 raspi4 kernel: [ 973] 119 973 3592 546 53248 0 0 exim4
Nov 12 21:34:05 raspi4 kernel: [ 990] 0 990 7477 1556 65536 0 0 lightdm
Nov 12 21:34:05 raspi4 kernel: [ 1001] 1000 1001 3702 1835 57344 0 0 systemd
Nov 12 21:34:05 raspi4 kernel: [ 1002] 1000 1002 4289 977 53248 0 0 (sd-pam)
Nov 12 21:34:05 raspi4 kernel: [ 1014] 1000 1014 13782 3065 98304 0 0 lxsession
Nov 12 21:34:05 raspi4 kernel: [ 1022] 1000 1022 1635 864 36864 0 0 dbus-daemon
Nov 12 21:34:05 raspi4 kernel: [ 1047] 1000 1047 1121 72 32768 0 0 ssh-agent
Nov 12 21:34:05 raspi4 kernel: [ 1059] 1000 1059 10903 1635 73728 0 0 gvfsd
Nov 12 21:34:05 raspi4 kernel: [ 1064] 1000 1064 13628 1305 77824 0 0 gvfsd-fuse
Nov 12 21:34:05 raspi4 kernel: [ 1075] 1000 1075 15649 3789 102400 0 0 openbox
Nov 12 21:34:05 raspi4 kernel: [ 1077] 1000 1077 11923 2836 94208 0 0 lxpolkit
Nov 12 21:34:05 raspi4 kernel: [ 1081] 1000 1081 41530 8542 212992 0 0 lxpanel
Nov 12 21:34:05 raspi4 kernel: [ 1083] 1000 1083 21362 5435 126976 0 0 pcmanfm
Nov 12 21:34:05 raspi4 kernel: [ 1085] 1000 1085 2833 1162 45056 0 0 xscreensaver
Nov 12 21:34:05 raspi4 kernel: [ 1091] 1000 1091 11360 4835 106496 0 0 jivelite
Nov 12 21:34:05 raspi4 kernel: [ 1103] 1000 1103 13256 7775 135168 0 0 applet.py
Nov 12 21:34:05 raspi4 kernel: [ 1114] 1000 1114 1121 72 32768 0 0 ssh-agent
Nov 12 21:34:05 raspi4 kernel: [ 1116] 1000 1116 48606 16458 327680 0 0 blueman-applet
Nov 12 21:34:05 raspi4 kernel: [ 1125] 1000 1125 1218 260 32768 0 0 xcompmgr
Nov 12 21:34:05 raspi4 kernel: [ 1136] 1000 1136 19936 2589 98304 0 0 gvfs-udisks2-vo
Nov 12 21:34:05 raspi4 kernel: [ 1137] 1000 1137 52667 5595 208896 0 0 pulseaudio
Nov 12 21:34:05 raspi4 kernel: [ 1153] 121 1153 5797 556 49152 0 0 rtkit-daemon
Nov 12 21:34:05 raspi4 kernel: [ 1174] 1000 1174 2124 953 40960 0 0 bash
Nov 12 21:34:05 raspi4 kernel: [ 1197] 1000 1197 10075 1169 61440 0 0 gvfs-mtp-volume
Nov 12 21:34:05 raspi4 kernel: [ 1212] 1000 1212 10500 1451 73728 0 0 gvfs-gphoto2-vo
Nov 12 21:34:05 raspi4 kernel: [ 1221] 1000 1221 10076 1104 69632 0 0 gvfs-goa-volume
Nov 12 21:34:05 raspi4 kernel: [ 1228] 1000 1228 6611 1301 49152 0 0 menu-cached
Nov 12 21:34:05 raspi4 kernel: [ 1235] 1000 1235 14057 1860 90112 0 0 gvfs-afc-volume
Nov 12 21:34:05 raspi4 kernel: [ 1289] 1000 1289 13302 1699 77824 0 0 gvfsd-trash
Nov 12 21:34:05 raspi4 kernel: [ 1460] 1000 1460 10346 1500 57344 0 0 obexd
Nov 12 21:34:05 raspi4 kernel: [ 1478] 0 1478 12088 4197 118784 0 0 smbd
Nov 12 21:34:05 raspi4 kernel: [ 1480] 0 1480 11357 1360 106496 0 0 smbd-notifyd
Nov 12 21:34:05 raspi4 kernel: [ 1481] 0 1481 11355 1001 102400 0 0 cleanupd
Nov 12 21:34:05 raspi4 kernel: [ 1482] 0 1482 12115 1628 106496 0 0 lpqd
Nov 12 21:34:05 raspi4 kernel: [ 1516] 0 1516 9771 3440 73728 0 0 lepresenced
Nov 12 21:34:05 raspi4 kernel: [ 1547] 0 1547 624 151 32768 0 0 hcitool
Nov 12 21:34:05 raspi4 kernel: [ 1549] 0 1549 592 110 32768 0 0 hcidump
Nov 12 21:34:05 raspi4 kernel: [ 1699] 999 1699 57543 46990 438272 0 0 perl
Nov 12 21:34:05 raspi4 kernel: [ 1805] 999 1805 55391 42681 413696 0 0 perl
Nov 12 21:34:05 raspi4 kernel: [ 1806] 999 1806 55360 42624 413696 0 0 perl
Nov 12 21:34:05 raspi4 kernel: [ 2266] 112 2266 724 416 32768 0 0 in.telnetd
Nov 12 21:34:05 raspi4 kernel: [ 2267] 0 2267 1519 675 36864 0 0 login
Nov 12 21:34:05 raspi4 kernel: [ 2386] 1000 2386 2117 920 40960 0 0 bash
Nov 12 21:34:05 raspi4 kernel: [ 8897] 999 8897 57543 44344 434176 0 0 perl
Nov 12 21:34:05 raspi4 kernel: [ 8898] 999 8898 2344 194 40960 0 0 ping
Nov 12 21:34:05 raspi4 kernel: [ 8899] 999 8899 57543 44344 434176 0 0 perl
Nov 12 21:34:05 raspi4 kernel: [ 8900] 999 8900 2344 187 40960 0 0 ping
Nov 12 21:34:05 raspi4 kernel: [ 8901] 999 8901 57543 44344 434176 0 0 perl
Nov 12 21:34:05 raspi4 kernel: [ 8902] 999 8902 1 1 8192 0 0 perl
Nov 12 21:34:05 raspi4 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=perl,pid=1699,uid=999
Nov 12 21:34:05 raspi4 kernel: Out of memory: Killed process 1699 (perl) total-vm:230172kB, anon-rss:175228kB, file-rss:12732kB, shmem-rss:0kB, UID:999 pgtables:428kB oom_score_adj:0
Nov 12 21:34:05 raspi4 kernel: oom_reaper: reaped process 1699 (perl), now anon-rss:0kB, file-rss:32kB, shmem-rss:0kB
Nov 12 21:34:05 raspi4 kernel: systemd-journal invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=0
Nov 12 21:34:05 raspi4 kernel: CPU: 1 PID: 133 Comm: systemd-journal Tainted: G D C 5.10.63-v7l+ #1459
Nov 12 21:34:05 raspi4 kernel: Hardware name: BCM2711
das geht dann munter so weiter.
Da bleibt dann nur noch Stecker ziehen :(
@artur_dent_2015
HMCCU verwendet für die RPC Server das "delayed shutdown" feature von FHEM. Damit wartet FHEM, bis bestimmte Dienste (wie in diesem Fall die RPC Server) sauber beendet wurden.
Ohne diese Funktion würden die RPC Prozesse einfach abgeschossen werden, ohne Chance, sich bei der CCU abzumelden. Dann würde auf CCU Seite das Log volllaufen mit Meldungen, dass die RPC Server nicht mehr erreichbar sind.
Laut ps laufen 7 Perl Prozesse. Das ist eine ganze Menge. Du nutzt 2 RPC Interfaces, d.h. 2 dieser 7 Prozesse gehören zu HMCCU. Wo die anderen herkommen, weiß ich nicht.
Eine Möglichkeit wäre, dass Dein System versucht Prozesse, die beendet werden, automatisch neu zu starten (z.B. FHEM). Das könnte zu so einem Effekt führen.
@aperoap
Der HmIP-HAP hat keinerlei "Nutz-Rollen", nur den MAINTENANCE channel.
In dem Fall einfach klassisch mit define definieren und fertig.
Hallo,
habe heute morgen auch das Update von HMCCU gezogen (Version 5.0 213171649), aber einige Meldungen (Control datapoint....) im Log, die ich bisher nie hatte.
2021.11.15 09:40:22.385 1: HMCCU [myHMCCU3] Reading device config from CCU. This may take a couple of seconds ...
2021.11.15 09:40:22.386 2: HMCCU [myHMCCU3] Reading Device Descriptions for interface BidCos-RF
2021.11.15 09:40:22.637 2: HMCCU [myHMCCU3] Read 52 Device Descriptions for interface BidCos-RF
2021.11.15 09:40:22.637 2: HMCCU [myHMCCU3] Reading Paramset Descriptions for interface BidCos-RF
2021.11.15 09:40:24.983 2: HMCCU [myHMCCU3] Read 52 Paramset Descriptions for interface BidCos-RF
2021.11.15 09:40:24.983 2: HMCCU [myHMCCU3] Reading Peer Descriptions for interface BidCos-RF
2021.11.15 09:40:24.995 2: HMCCU [myHMCCU3] Read 0 Peer Descriptions for interface BidCos-RF
2021.11.15 09:40:24.996 2: HMCCU [myHMCCU3] Reading Device Descriptions for interface HmIP-RF
2021.11.15 09:40:25.737 2: HMCCU [myHMCCU3] Read 148 Device Descriptions for interface HmIP-RF
2021.11.15 09:40:25.738 2: HMCCU [myHMCCU3] Reading Paramset Descriptions for interface HmIP-RF
2021.11.15 09:40:37.343 2: HMCCU [myHMCCU3] Read 88 Paramset Descriptions for interface HmIP-RF
2021.11.15 09:40:37.344 2: HMCCU [myHMCCU3] Reading Peer Descriptions for interface HmIP-RF
2021.11.15 09:40:37.392 2: HMCCU [myHMCCU3] Read 12 Peer Descriptions for interface HmIP-RF
2021.11.15 09:40:37.412 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.414 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.417 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.419 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.422 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.437 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.439 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 3660.
2021.11.15 09:40:37.443 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.493 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.496 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.505 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.509 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.518 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.522 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.530 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.534 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:37.541 2: HMCCU [myHMCCU3] Read device configuration: devices/channels=200 parametersets=140 links=12
2021.11.15 09:40:37.542 2: HMCCU [myHMCCU3] RPC device for interface HmIP-RF: d_rpc178026HmIP_RF
2021.11.15 09:40:37.542 2: HMCCU [myHMCCU3] RPC device for interface BidCos-RF: d_rpc178026BidCos_RF
2021.11.15 09:40:37.560 2: HMCCURPCPROC [d_rpc178026HmIP_RF] RPC server process started for interface HmIP-RF with PID=9752
2021.11.15 09:40:37.583 2: HMCCURPCPROC [d_rpc178026HmIP_RF] Initializing RPC server CB2010178092178026 for interface HmIP-RF
2021.11.15 09:40:37.688 2: HMCCURPCPROC [d_rpc178026HmIP_RF] Callback server CB2010178092178026 created. Listening on port 7420
2021.11.15 09:40:37.691 2: HMCCURPCPROC [d_rpc178026HmIP_RF] CB2010178092178026 accepting connections. PID=9752
2021.11.15 09:40:37.856 1: HMCCURPCPROC [d_rpc178026HmIP_RF] RPC server starting
2021.11.15 09:40:38.124 2: HMCCURPCPROC [d_rpc178026BidCos_RF] RPC server process started for interface BidCos-RF with PID=9753
2021.11.15 09:40:38.147 2: HMCCURPCPROC [d_rpc178026BidCos_RF] Initializing RPC server CB2001178092178026 for interface BidCos-RF
2021.11.15 09:40:38.235 2: HMCCURPCPROC [d_rpc178026BidCos_RF] Callback server CB2001178092178026 created. Listening on port 7411
2021.11.15 09:40:38.237 2: HMCCURPCPROC [d_rpc178026BidCos_RF] CB2001178092178026 accepting connections. PID=9753
2021.11.15 09:40:38.403 1: HMCCURPCPROC [d_rpc178026BidCos_RF] RPC server starting
2021.11.15 09:40:40.998 2: HMCCURPCPROC [d_rpc178026BidCos_RF] RPC server CB2001178092178026 enters server loop
2021.11.15 09:40:41.000 2: HMCCURPCPROC [d_rpc178026BidCos_RF] Registering callback http://192.168.178.92:7411/fh2001 of type A with ID CB2001178092178026 at http://192.168.178.26:2001
2021.11.15 09:40:41.220 1: HMCCURPCPROC [d_rpc178026BidCos_RF] RPC server CB2001178092178026 running
2021.11.15 09:40:41.220 2: HMCCURPCPROC [d_rpc178026BidCos_RF] CB2001178092178026 NewDevice received 52 device and channel specifications
2021.11.15 09:40:41.342 1: HMCCURPCPROC [d_rpc178026BidCos_RF] Scheduled CCU ping every 300 seconds
2021.11.15 09:40:42.984 2: HMCCURPCPROC [d_rpc178026HmIP_RF] RPC server CB2010178092178026 enters server loop
2021.11.15 09:40:42.985 2: HMCCURPCPROC [d_rpc178026HmIP_RF] Registering callback http://192.168.178.92:7420/fh2010 of type A with ID CB2010178092178026 at http://192.168.178.26:2010
2021.11.15 09:40:43.151 1: HMCCURPCPROC [d_rpc178026HmIP_RF] RPC server CB2010178092178026 running
2021.11.15 09:40:43.282 1: HMCCU [myHMCCU3] All RPC servers running
2021.11.15 09:40:43.424 2: HMCCU [myHMCCU3] Updating 10 of 10 client devices matching devexp=.* filter=ccudevstate=active,ccuif=HmIP-RF|BidCos-RF
2021.11.15 09:40:43.852 2: HMCCURPCPROC [d_rpc178026HmIP_RF] CB2010178092178026 NewDevice received 148 device and channel specifications
2021.11.15 09:40:55.470 3: CUL_HM set Gara_Re_8_Sw_05 statusRequest noArg
2021.11.15 09:40:59.207 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:59.293 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:59.376 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:59.461 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:59.757 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:40:59.828 2: HMCCU [myHMCCU3] Update success=9 failed=1
2021.11.15 09:41:00.150 3: HM485_LAN: Initialisierung von Modul 00010AA7
2021.11.15 09:42:05.508 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:05.929 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:06.907 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:08.069 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:10.992 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:11.838 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:15.530 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:23.064 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:24.055 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:24.529 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:24.994 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:25.598 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:31.260 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:32.247 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:32.804 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:33.728 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:42:34.203 3: CUL_HM set EG_UniSen_06 statusRequest noArg
2021.11.15 09:42:34.210 3: CUL_HM set EG_UniSen_06 getConfig noArg
2021.11.15 09:42:55.689 3: CUL_HM set Gara_UniSen_12 statusRequest noArg
2021.11.15 09:42:55.693 3: CUL_HM set Gara_UniSen_12 getConfig noArg
2021.11.15 09:43:00.883 2: AttrTemplates: got 259 entries
2021.11.15 09:43:10.717 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:43:11.608 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:43:11.656 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:43:12.172 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:43:13.097 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:43:13.831 3: CUL_HM set OG_UniSen_03 statusRequest noArg
2021.11.15 09:43:23.501 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:43:24.209 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:43:25.437 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:43:25.896 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:43:37.247 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:44:53.632 3: CUL_HM set Gart_UniSen_25 statusRequest noArg
Das setzt sich munter so fort.
2021.11.15 09:50:08.329 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:50:10.522 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:51:41.065 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:52:07.515 3: UWZ Unwetterzentrale: UWZ.1811 Done fetching data
2021.11.15 09:52:15.710 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:52:16.489 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:52:17.155 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:52:18.013 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:52:18.823 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:52:19.012 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:52:19.029 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:53:07.488 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:53:08.402 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:53:08.926 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:53:09.850 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:53:42.951 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:53:43.604 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:53:43.989 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
2021.11.15 09:53:44.611 2: HMCCU [myHMCCU3] Control datapoint not defined for channel 10, role
Ich habe einige DOIF, bei denen ich im set-Befehl einen datapoint anspreche (so im Forum gefunden). Kann es sein, dass dies mit der V5 nicht mehr zulässig ist und wenn ja, wie lautet der Befehl dann?
(([06:00|1234] and !$we) or [07:30|57]) (set HmIP_BWTH_000C9A49A7E499_9 datapoint 1.SET_POINT_TEMPERATURE 21) ##
DOELSEIF (([13:35|12345] and !$we) or [([10:00]+int(rand(60)))|7]) (set HmIP_BWTH_000C9A49A7E499_9 datapoint 1.SET_POINT_TEMPERATURE 22) ## Solltemperatur später wieder auf 22 °C (Versuche) stellen.
DOELSEIF (([17:30|12345] and !$we) or [([18:50]+int(rand(60)))|7]) (set HmIP_BWTH_000C9A49A7E499_9 datapoint 1.SET_POINT_TEMPERATURE 21) ## Solltemperatur Nachts auf 21 °C stellen.
DOELSEIF ([02:00]+int(rand(300))) (set HmIP_BWTH_000C9A49A7E499_9 datapoint 1.SET_POINT_TEMPERATURE 22) ## Zur Einschaltzeit Sollwert wieder auf 22° stellen
Gruß Jürgen
@bmwfan
Die Fehlermeldungen deuten darauf hin, dass eines oder mehrere Deiner Geräte nicht richtig erkannt werden. Ich habe sie extra eingebaut, um das Phänomen einkreisen zu können. Leider sind die Information noch nicht ausreichend. Da muss ich nochmal nachbessern.
Mit den set datapoint Befehlen hat das nichts zu tun. Die sind korrekt und werden nach wie vor unterstützt.
Aber mal ne andere Frage: Warum stellst Du die Temperaturen bei DOIF ein? Du kannst doch einfach in der CCU ein Wochenprogramm (oder sogar 3 Wochenprogramme) anlegen. Die werden dann direkt dem Thermostat zugewiesen. Das ist viel effizienter, da keinerlei Kommunikation erforderlich ist.
@zap:
jetzt bekomme ich beim restart auch einen Fehler, obwohl am DOIF nichts verändert. Timingproblem?
2021.11.15 14:26:09.330 2: di_Bad_OG_Licht_Spiegel: set HmIP_BDT_0008DA49929255_3 off: Unknown argument off choose one of clear defaults:reset,update,old,forceReset readingFilter:multiple-strict,0.ACTUAL_TEMPERATURE,0.ACTUAL_TEMPERATURE_STATUS,0.CONFIG_PENDING,0.DUTY_CYCLE,0.ERROR_CODE,0.ERROR_OVERHEAT,0.ERROR_OVERLOAD,0.ERROR_UPDATE,0.INSTALL_TEST,0.OPERATING_VOLTAGE,0.OPERATING_VOLTAGE_STATUS,0.RSSI_DEVICE,0.RSSI_PEER,0.UNREACH,0.UPDATE_PENDING,1.PRESS_LONG,1.PRESS_SHORT,2.PRESS_LONG,2.PRESS_SHORT,3.ACTIVITY_STATE,3.LEVEL,3.LEVEL_STATUS,3.PROCESS,3.SECTION,3.SECTION_STATUS,4.ACTIVITY_STATE,4.LEVEL,4.LEVEL_STATUS,4.PROCESS,4.SECTION,4.SECTION_STATUS,5.ACTIVITY_STATE,5.LEVEL,5.LEVEL_STATUS,5.PROCESS,5.SECTION,5.SECTION_STATUS,6.ACTIVITY_STATE,6.LEVEL,6.LEVEL_STATUS,6.PROCESS,6.SECTION,6.SECTION_STATUS,7.WEEK_PROGRAM_CHANNEL_LOCKS config datapoint
2021.11.15 14:26:09.331 3: di_Bad_OG_Licht_Spiegel: error in startup: set HmIP_BDT_0008DA49929255_3 off: Unknown argument off choose one of clear defaults:reset,update,old,forceReset readingFilter:multiple-strict,0.ACTUAL_TEMPERATURE,0.ACTUAL_TEMPERATURE_STATUS,0.CONFIG_PENDING,0.DUTY_CYCLE,0.ERROR_CODE,0.ERROR_OVERHEAT,0.ERROR_OVERLOAD,0.ERROR_UPDATE,0.INSTALL_TEST,0.OPERATING_VOLTAGE,0.OPERATING_VOLTAGE_STATUS,0.RSSI_DEVICE,0.RSSI_PEER,0.UNREACH,0.UPDATE_PENDING,1.PRESS_LONG,1.PRESS_SHORT,2.PRESS_LONG,2.PRESS_SHORT,3.ACTIVITY_STATE,3.LEVEL,3.LEVEL_STATUS,3.PROCESS,3.SECTION,3.SECTION_STATUS,4.ACTIVITY_STATE,4.LEVEL,4.LEVEL_STATUS,4.PROCESS,4.SECTION,4.SECTION_STATUS,5.ACTIVITY_STATE,5.LEVEL,5.LEVEL_STATUS,5.PROCESS,5.SECTION,5.SECTION_STATUS,6.ACTIVITY_STATE,6.LEVEL,6.LEVEL_STATUS,6.PROCESS,6.SECTION,6.SECTION_STATUS,7.WEEK_PROGRAM_CHANNEL_LOCKS config datapoint
Das DOIF:
([de_Bew_OG_Bad_Motion:state] eq "motion" and [?23:50-05:00])
(set HmIP_BDT_0008DA49929255_3 pct 40 0 15) (set HmIP_BDT_0008DA49929255_3 off)
DOELSEIF ([de_Bew_OG_Bad_Motion:state] eq "motion" and [?de_Bew_OG_Bad_Motion:brightness] < 100 and [?05:01-23:49] and [?HmIP_BDT_0008DA49929255_3] eq "off")
(set HmIP_BDT_0008DA49929255_3 pct 100 0 8) (set HmIP_BDT_0008DA49929255_3 off)
DOELSEIF ([HmIP_BDT_0008DA49929255_3:"off"] and $cmd eq "2.1") (set HmIP_BDT_0008DA49929255_3 pct 0 0 10)
DOIF für Temperaturen:
Dachte so flexibler zu sein und binde bei manchen Räumen weitere Argumente (Wettervorhersage des nächsten Tages...) ein. Dadurch kann ich südseitig ausgerichtete Räume, die erst am Nachmittag benutzt werden, vom Aufheizen morgens herausnehmen. Die Sonne sorgt dann schon dafür, dass nachmittags warm ist und ich spare auf den Winter gerechnet Heizkosten. Dann habe ich gleich alle Räume über DOIF angesteuert, was bisher auch keine Probleme machte. Vielleicht stelle ich die Räume, die nur über den Thermostat angesteuert werden, um.
Kannst Du was zu dem Startfehler sagen?
Grüße Jürgen
mach mal bitte ein
list HmIP_BDT_0008DA49929255_3
Voila:
Internals:
DEF 0008DA49929255 sd=3.LEVEL cd=4.LEVEL
FUUID 6188ec14-f33f-3228-1dc0-93ab73c3b58448da
IODev myHMCCU3
NAME HmIP_BDT_0008DA49929255_3
NR 1853
STATE off
TYPE HMCCUDEV
ccuaddr 0008DA49929255
ccudevstate active
ccuif HmIP-RF
ccuname Licht-BadOG-Spiegel-HmIP
ccurolectrl DIMMER_VIRTUAL_RECEIVER
ccurolestate DIMMER_TRANSMITTER
ccusubtype BDT
ccutype HmIP-BDT
firmware 1.4.8
readonly no
READINGS:
2021-11-15 14:47:30 3.ACTIVITY_STATE UNKNOWN
2021-11-15 14:47:30 3.LEVEL off
2021-11-15 14:47:30 3.LEVEL_STATUS NORMAL
2021-11-15 14:47:30 3.PROCESS STABLE
2021-11-15 14:47:30 3.SECTION 15
2021-11-15 14:26:53 3.SECTION_STATUS NORMAL
2021-11-15 14:47:30 4.ACTIVITY_STATE STABLE
2021-11-15 14:47:30 4.LEVEL off
2021-11-15 14:47:30 4.LEVEL_STATUS NORMAL
2021-11-15 14:47:30 4.PROCESS STABLE
2021-11-15 14:47:30 4.SECTION 0
2021-11-15 14:26:53 4.SECTION_STATUS NORMAL
2021-11-15 14:26:53 7.WEEK_PROGRAM_CHANNEL_LOCKS 0
2021-11-15 14:26:05 IODev myHMCCU3
2021-11-15 14:47:31 activity alive
2021-11-15 14:47:30 control off
2021-11-15 14:47:31 devstate ok
2021-11-15 14:47:31 hmstate off
2021-11-15 14:47:30 pct 0
2021-11-15 14:47:31 rssidevice -76
2021-11-15 14:47:31 rssipeer -74
2021-11-15 14:47:30 state off
hmccu:
channels 8
defCDP 4.LEVEL
defSDP 3.LEVEL
detect 5
devspec 0008DA49929255
forcedev 0
nodefaults 1
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:KEY_TRANSCEIVER,3:DIMMER_TRANSMITTER,4:DIMMER_VIRTUAL_RECEIVER,5:DIMMER_VIRTUAL_RECEIVER,6:DIMMER_VIRTUAL_RECEIVER,7:DIMMER_WEEK_PROFILE
setDefaults 0
cmdlist:
get
set pct down up on:noArg on-till on-for-timer off:noArg toggle:noArg
control:
chn 4
dpt LEVEL
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
NVAL 0.000000
ONVAL 0.000000
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
0.ACTUAL_TEMPERATURE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_OVERLOAD:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_UPDATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.INSTALL_TEST:
VALUES:
NVAL true
ONVAL true
OSVAL true
OVAL true
SVAL true
VAL true
0.OPERATING_VOLTAGE:
VALUES:
NVAL 0.000000
ONVAL 0.000000
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
0.OPERATING_VOLTAGE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL -76
ONVAL -75
OSVAL -75
OVAL -75
SVAL -76
VAL -76
0.RSSI_PEER:
VALUES:
NVAL -74
ONVAL -74
OSVAL -74
OVAL 182
SVAL -74
VAL 182
0.UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
3.ACTIVITY_STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL UNKNOWN
OVAL 0
SVAL UNKNOWN
VAL 0
3.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
3.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
3.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
3.SECTION:
VALUES:
NVAL 15
ONVAL 15
OSVAL 15
OVAL 15
SVAL 15
VAL 15
3.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
4.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
4.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
4.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
5.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
5.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
5.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
5.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
6.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0.0
SVAL off
VAL 0.0
6.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
6.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
6.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.WEEK_PROGRAM_CHANNEL_LOCKS:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
roleCmds:
set:
down:
channel 4
role DIMMER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=-10
usage down [delta]
subcmd:
000:
args -10
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
scn 000
unit 100%
off:
channel 4
role DIMMER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:0
usage off
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
on:
channel 4
role DIMMER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:100
usage on
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
on-for-timer:
channel 4
role DIMMER_VIRTUAL_RECEIVER
subcount 2
syntax 1:V:DURATION_UNIT:0 2:V:ON_TIME,DURATION_VALUE:?duration 3:V:LEVEL:100
usage on-for-timer duration
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname duration
partype 2
ps VALUES
scn 002
unit s
001:
args 100
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
scn 003
unit 100%
on-till:
channel 4
role DIMMER_VIRTUAL_RECEIVER
subcount 2
syntax 1:V:DURATION_UNIT:0 2:V:ON_TIME,DURATION_VALUE:?time 3:V:LEVEL:100
usage on-till time
subcmd:
000:
args
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname time
partype 2
ps VALUES
scn 002
unit s
001:
args 100
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
scn 003
unit 100%
pct:
channel 4
role DIMMER_VIRTUAL_RECEIVER
subcount 3
syntax 5:V:LEVEL:?level 1:V:DURATION_UNIT:0 2:V:ON_TIME,DURATION_VALUE:?time=0.0 3:V:RAMP_TIME_UNIT:0 4:V:RAMP_TIME,RAMP_TIME_VALUE:?ramp=0.5
usage pct level [time] [ramp]
subcmd:
000:
args
dpt LEVEL
fnc
max 1.01
min 0.0
parname level
partype 2
ps VALUES
scn 005
unit 100%
001:
args 0.0
dpt ON_TIME
fnc
max 8580000.0
min 0.0
parname time
partype 2
ps VALUES
scn 002
unit s
002:
args 0.5
dpt RAMP_TIME
fnc
max 8580000.0
min 0.0
parname ramp
partype 2
ps VALUES
scn 004
unit s
up:
channel 4
role DIMMER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=+10
usage up [delta]
subcmd:
000:
args +10
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
scn 000
unit 100%
state:
chn 3
dpt LEVEL
Attributes:
alias Licht_BOG_Spiegel_HmIP
ccureadingfilter 1,2,3,4,7..*
cmdIcon on:general_an off:general_aus
devStateIcon on:black_FS20.on off:black_FS20.off Initialized:edit_settings@orange
event-on-change-reading .*
icon light_ceiling_light
room 2.1_OG_Bad,9.6.0_System
substexcl pct
webCmd pct:on:off
widgetOverride pct:slider,0,10,100
Ich habe gerade einen HmIP-SPI gelöscht (weil DEV) und neu angelegt (als CHN).
Was mir auffällt:
- früher (tm) wurde mal auch "devStateIcon noPresence:motion_detector presence:motion_detector@red" gesetzt. Jetzt steht nur noch der Text "noPresence" im state. Ist nicht schlimm, war aber anders schöner.
- das Reading für sabotage kommt nicht automatisch mit. Ich müsste jetzt wieder ccuflags und ccureadingname anlegen. Hatten wir nicht mal überlegt, dass sabotage automatisch als Reading angelegt wird, weil sinnvoll?
Das "devStateIcon" kommt nicht von HMCCU.
Ok, ist ja auch kein Problem, das kann ich selber anpassen.
Aber sabotage per default als Reading?
Habe mein FHEM auf HTTPS umgestellt, aber gesehen dass die Def aller HMCCURPCPROG (BidCos-RF, HmIP, Virtual Devices) immer noch auf http stehen. Müssen die nicht auch auf https umgestellt werden?
Als Beispiel ein List.
Internals:
CCUNum 1
DEF http://192.168.178.26 BidCos-RF
FD 112
FUUID 60edbab0-f33f-6b6f-b7d4-2c1a3e6394cd6bba
IODev myHMCCU3
NAME d_rpc178026BidCos_RF
NR 1812
RPCPID 4912
RPCState running
STATE running/OK
TYPE HMCCURPCPROC
ccuip 192.168.178.26
ccustate active
ccutype CCU2/3
host 192.168.178.26
prot http
rpcid 178092178026
rpcinterface BidCos-RF
rpcip 192.168.178.26
rpcport 2001
version 5.0 213171649
READINGS:
2021-11-16 08:24:25 rpcstate running
2021-11-16 08:24:25 state OK
hmccu:
defaultaddr 192.168.178.92
devspec BidCos-RF
evtime 0
localaddr 192.168.178.92
rpcstarttime 1637047465.55389
rpc:
avgdelay 0.00258457660675049
cbport 7411
cburl http://192.168.178.92:7411/fh2001
clkey CB2001178092178026
clurl http://192.168.178.26:2001
evtime 1637048065.98954
pid 4912
port 2001
state running
sumdelay 0.00516915321350098
rec:
DD 0
EV 2
EX 0
IN 0
ND 52
RA 0
RD 0
SL 1
TO 0
UD 0
snd:
DD 0
EV 0
EX 0
IN 0
ND 0
RA 0
RD 0
SL 0
TO 0
UD 0
Attributes:
alias CCU RPC BidCos-RF
eventMap /rpcserver on:on/rpcserver off:off/
room 9.6.0_System
stateFormat rpcstate/state
verbose 2
@ZAP: Hast Du zu meinem Post 776 eine Idee? Der Fehler ist bei jedem restart wieder da und ich such gerade eine Lösung, da mir der Raspi unmotiviert abstürzt. Irgendetwas an meiner Konfiguration scheint ihn zu blockieren, sodass er in ein TimeOut läuft.
Gruß Jürgen
Du schreibst hier in mehreren Threads, ich habe da ehrlich gesagt den Überblick verloren
Dachte das gehört hier hinein. Dann verwende ich nur noch den anderen Thread.
Hallo Zap,
konntest du bereits den HM-LC-RGBW-WM als HMCCUDEV Device integrieren?
Ich habe versucht den HM-LC-RGBW-WM als HMCCUDEV anzulegen.
Leider kann ich nur on,off und dimmen.
Farbwechsel und Programmauswahl sind nicht möglich.
Hast du einen Tipp?
Beste Grüße
Internals:
.AttrList IODev ccuaggregate:textField-long ccucalculate:textField-long ccuflags:multiple-strict,ackState,logCommand,noReadings,trace,showMasterReadings,showLinkReadings,showDeviceReadings,showServiceReadings ccureadingfilter:textField-long ccureadingformat:name,namelc,address,addresslc,datapoint,datapointlc ccureadingname:textField-long ccuSetOnChange ccuReadingPrefix ccuget:State,Value ccuscaleval ccuverify:0,1,2 disable:0,1 hmstatevals:textField-long statevals substexcl substitute:textField-long statechannel controlchannel stripnumber peer:textField-long traceFilter event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading statedatapoint:select,1.LEVEL controldatapoint:select,1.LEVEL
.triggerUsed 0
CFGFN
DEF NEQ0184738 forceDev
FUUID 61954660-f33f-3b5c-8320-cfab7f594002eb97
IODev d_ccu
NAME Strip_Rueckseite
NR 19775
STATE on
TYPE HMCCUDEV
ccuaddr NEQ0184738
ccudevstate active
ccuif BidCos-RF
ccuname Strip-Rueckseite
ccurolectrl DIMMER
ccurolestate DIMMER
ccusubtype HM-LC-RGBW-WM
ccutype HM-LC-RGBW-WM
firmware 1.0
readonly no
.attraggr:
.attreocr:
.*
.attrminint:
OLDREADINGS:
READINGS:
2021-11-17 19:26:44 .0.AES_KEY off
2021-11-17 19:26:44 .0.CONFIG_PENDING false
2021-11-17 19:26:44 .0.DEVICE_IN_BOOTLOADER false
2021-11-17 19:26:44 .0.DUTYCYCLE false
2021-11-17 19:26:44 .0.LOWBAT ok
2021-11-17 19:26:44 .0.RSSI_DEVICE -65535
2021-11-17 19:26:44 .0.RSSI_PEER -55
2021-11-17 19:26:44 .0.STICKY_UNREACH false
2021-11-17 19:26:44 .0.UNREACH alive
2021-11-17 19:26:44 .0.UPDATE_PENDING false
2021-11-17 19:29:00 .1.DIRECTION stop
2021-11-17 19:26:44 .1.INHIBIT unlocked
2021-11-17 19:29:00 .1.WORKING false
2021-11-17 19:26:44 .2.INHIBIT unlocked
2021-11-17 19:26:44 .3.ACT_BRIGHTNESS 0
2021-11-17 19:26:44 .3.ACT_MAX_BOARDER 0
2021-11-17 19:26:44 .3.ACT_MIN_BOARDER 0
2021-11-17 19:26:44 .3.INHIBIT unlocked
2021-11-17 19:26:44 .3.ON_TIME 0
2021-11-17 19:26:44 .3.RAMP_TIME 0.5
2021-11-17 19:26:44 .R-1.AES_ACTIVE false
2021-11-17 19:26:44 .R-2.AES_ACTIVE false
2021-11-17 19:26:44 .R-2.WHITE_ADJUSTMENT_VALUE_BLUE 98
2021-11-17 19:26:44 .R-2.WHITE_ADJUSTMENT_VALUE_GREEN 98
2021-11-17 19:26:44 .R-2.WHITE_ADJUSTMENT_VALUE_RED 75
2021-11-17 19:26:44 .R-3.AES_ACTIVE false
2021-11-17 19:26:44 .R-3.COLOR_CHANGE_SPEED 10
2021-11-17 19:26:44 .R-INTERNAL_KEYS_VISIBLE true
2021-11-17 19:26:44 .R-LOCAL_RESET_DISABLE false
2021-11-17 19:29:00 1.LEVEL on
2021-11-17 19:26:44 2.COLOR 0
2021-11-17 19:26:44 3.PROGRAM 0
2021-11-17 19:29:00 activity alive
2021-11-17 19:29:00 battery ok
2021-11-17 19:26:44 color 0
2021-11-17 19:29:00 control 100
2021-11-17 19:29:00 devstate ok
2021-11-17 19:29:00 hmstate on
2021-11-17 19:29:00 pct on
2021-11-17 19:26:44 prog 0
2021-11-17 19:29:00 rssidevice -65535
2021-11-17 19:29:00 rssipeer -55
2021-11-17 19:29:00 sign off
2021-11-17 19:29:00 state on
hmccu:
channels 4
detect 1
devspec NEQ0184738
forcedev 1
nodefaults 0
role 0:MAINTENANCE,1:DIMMER,2:RGBW_COLOR,3:RGBW_AUTOMATIC
setDefaults 0
cmdlist:
get
set on-for-timer stop:noArg pct up on:noArg down off:noArg on-till toggle:noArg
control:
chn 1
dpt LEVEL
dp:
0.AES_KEY:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DEVICE_IN_BOOTLOADER:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTYCYCLE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.LOWBAT:
VALUES:
NVAL 0
ONVAL 0
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL -65535
ONVAL -65535
OSVAL -65535
OVAL -65535
SVAL -65535
VAL -65535
0.RSSI_PEER:
VALUES:
NVAL -55
ONVAL -55
OSVAL -55
OVAL -55
SVAL -55
VAL -55
0.STICKY_UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.AES_ACTIVE:
MASTER:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
1.DIRECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL stop
OVAL 0
SVAL stop
VAL 0
1.INHIBIT:
VALUES:
NVAL 0
ONVAL 0
OSVAL unlocked
OVAL 0
SVAL unlocked
VAL 0
1.LEVEL:
VALUES:
NVAL 100
ONVAL 20.5
OSVAL on
OVAL 0.205000
SVAL on
VAL 1.000000
1.WORKING:
VALUES:
NVAL 0
ONVAL 1
OSVAL true
OVAL 1
SVAL false
VAL 0
2.AES_ACTIVE:
MASTER:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
2.COLOR:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
2.INHIBIT:
VALUES:
NVAL 0
ONVAL 0
OSVAL unlocked
OVAL 0
SVAL unlocked
VAL 0
2.WHITE_ADJUSTMENT_VALUE_BLUE:
MASTER:
NVAL 98
ONVAL 98
OSVAL 98
OVAL 98
SVAL 98
VAL 98
VALUES:
2.WHITE_ADJUSTMENT_VALUE_GREEN:
MASTER:
NVAL 98
ONVAL 98
OSVAL 98
OVAL 98
SVAL 98
VAL 98
VALUES:
2.WHITE_ADJUSTMENT_VALUE_RED:
MASTER:
NVAL 75
ONVAL 75
OSVAL 75
OVAL 75
SVAL 75
VAL 75
VALUES:
3.ACT_BRIGHTNESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ACT_MAX_BOARDER:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.ACT_MIN_BOARDER:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.AES_ACTIVE:
MASTER:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
3.COLOR_CHANGE_SPEED:
MASTER:
NVAL 10
ONVAL 10
OSVAL 10
OVAL 10
SVAL 10
VAL 10
VALUES:
3.INHIBIT:
VALUES:
NVAL 0
ONVAL 0
OSVAL unlocked
OVAL 0
SVAL unlocked
VAL 0
3.ON_TIME:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0.000000
SVAL 0
VAL 0.000000
3.PROGRAM:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.RAMP_TIME:
VALUES:
NVAL 0.500000
ONVAL 0.500000
OSVAL 0.5
OVAL 0.500000
SVAL 0.5
VAL 0.500000
d.INTERNAL_KEYS_VISIBLE:
MASTER:
NVAL 1
ONVAL 1
OSVAL true
OVAL 1
SVAL true
VAL 1
VALUES:
d.LOCAL_RESET_DISABLE:
MASTER:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
VALUES:
roleCmds:
get:
set:
down:
channel 1
role DIMMER
subcount 1
syntax V:LEVEL:?delta=-10
usage down [delta]
subcmd:
000:
args -10
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname delta
partype 2
ps VALUES
scn 000
unit 100%
off:
channel 1
role DIMMER
subcount 1
syntax V:LEVEL:0
usage off
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
on:
channel 1
role DIMMER
subcount 1
syntax V:LEVEL:100
usage on
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
on-for-timer:
channel 1
role DIMMER
subcount 2
syntax V:ON_TIME:?duration V:LEVEL:100
usage on-for-timer duration
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname duration
partype 2
ps VALUES
scn 000
unit s
001:
args 100
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
scn 001
unit 100%
on-till:
channel 1
role DIMMER
subcount 2
syntax V:ON_TIME:?time V:LEVEL:100
usage on-till time
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname time
partype 2
ps VALUES
scn 000
unit s
001:
args 100
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
scn 001
unit 100%
pct:
channel 1
role DIMMER
subcount 3
syntax 3:V:LEVEL:?level 1:V:ON_TIME:?time=0.0 2:V:RAMP_TIME:?ramp=0.5
usage pct level [time] [ramp]
subcmd:
000:
args
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname level
partype 2
ps VALUES
scn 003
unit 100%
001:
args 0.0
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname time
partype 2
ps VALUES
scn 001
unit s
002:
args 0.5
dpt RAMP_TIME
fnc
max 85825945.600000
min 0.000000
parname ramp
partype 2
ps VALUES
scn 002
unit s
stop:
channel 1
role DIMMER
subcount 1
syntax V:RAMP_STOP:1
usage stop
subcmd:
000:
args 1
dpt RAMP_STOP
fnc
max 1
min 0
parname RAMP_STOP
partype 3
ps VALUES
scn 000
unit
up:
channel 1
role DIMMER
subcount 1
syntax V:LEVEL:?delta=+10
usage up [delta]
subcmd:
000:
args +10
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname delta
partype 2
ps VALUES
scn 000
unit 100%
state:
chn 1
dpt LEVEL
Attributes:
ccureadingfilter COLOR|PROGRAM|LEVEL
ccureadingname 2.COLOR:+color;;3.PROGRAM:+prog
ccuscaleval LEVEL:0:1:0:100
cmdIcon on:general_an off:general_aus
controldatapoint 1.LEVEL
event-on-change-reading .*
statedatapoint 1.LEVEL
stripnumber 1
substexcl control
substitute LEVEL!#0-0:off,#1-100:on
webCmd control:color:prog:on:off
widgetOverride control:slider,0,1,100 prog:0,1,2,3,4,5,6 color:colorpicker,HUE,0,1,100
@Sommerfeld
Grundsätzlich kann jedes Gerät in HMCCU genutzt werden. Eine Integration meinerseits erleichtert das nur etwas.
Mit dem Befehl "set datapoint" können alle Funktionen eines Gerätes angesprochen werden. Beispiel:
Statt eine Befehl "set on " bei einem Schalter geht auch ein "set datapoint STATE true"
Der Befehl on macht im Hintergrund nichts anderes, als ein set datapoint auszuführen.
Jetzt musst Du nur noch die Doku der Devices von EQ3 herunterladen. Da steht drin, welche Datenpunkte welche Funktion haben.
Für BidCos Geräte: https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HM-Script_4-Datenpunkte.pdf
Für HmIP Geräte: https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HmIP_Device_Documentation.pdf
Danke, schaue ich mir an.
Hallo,
ich habe das gleiche Phänomen wie bmwfan (siehe Post « Antwort #774 am: 15 November 2021, 09:58:35 »)
nach dem Update müllt sich das Logfile mit dieser Fehlermeldung voll! :'(
2021.11.20 10:04:28 2 : HMCCU [d_ccu] Control datapoint not defined for channel 10, role
2021.11.20 10:04:29 2 : HMCCU [d_ccu] Control datapoint not defined for channel 10, role
2021.11.20 10:04:29 2 : HMCCU [d_ccu] Control datapoint not defined for channel 10, role
2021.11.20 10:04:29 2 : HMCCU [d_ccu] Control datapoint not defined for channel 10, role
2021.11.20 10:04:30 2 : HMCCU [d_ccu] Control datapoint not defined for channel 10, role
2021.11.20 10:04:30 2 : HMCCU [d_ccu] Control datapoint not defined for channel 10, role
Diese Einträge kommen alle 5-10 Minuten !!!
Ich bin schon alle 56 Geräte mehrfach durch gegangen und habe auch bei allen ein "set defaults reset" gemacht und alle bei denen es empfohlen wurde neu angelegt.
Wie kann ich herausfinden wer oder was hier das Problem ist?
Danke für die Unterstützung.
Hallo miteinander,
falls für den HB-OU-MP3-LED (https://github.com/jp112sdl/HB-OU-MP3-LED (https://github.com/jp112sdl/HB-OU-MP3-LED)) noch das deviceInfo benötigt wird:
Device channels and datapoints
DEV MP3-LED_50 JPMP300050 interface=BidCos-RF type=HB-OU-MP3-LED
CHN JPMP300050:0 MP3-LED_50:0
0.UNREACH = false {b} [RE]
0.STICKY_UNREACH = false {b} [RWE]
0.CONFIG_PENDING = false {b} [RE]
0.LOWBAT = false {b} [RE]
0.DUTYCYCLE = false {b} [RE]
0.RSSI_DEVICE = 206 {n} [RE]
0.RSSI_PEER = 215 {n} [RE]
0.DEVICE_IN_BOOTLOADER = false {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
0.AES_KEY = 0 {n} [R]
CHN JPMP300050:1 HB-OU-MP3-LED JPMP300050:1
1.STATE = false {b} [RWE]
1.ON_TIME = {f} [W]
1.INHIBIT = false {b} [RWE]
1.SUBMIT = {s} [W]
1.INSTALL_TEST = {b} [W]
1.WORKING = false {b} [RE]
CHN JPMP300050:2 HB-OU-MP3-LED JPMP300050:2
2.STATE = false {b} [RWE]
2.ON_TIME = {f} [W]
2.INHIBIT = false {b} [RWE]
2.SUBMIT = {s} [W]
2.INSTALL_TEST = {b} [W]
2.WORKING = false {b} [RE]
Device detection:
No state datapoint detected
No control datapoint detected
Failed to detect device settings. Device must be configured manually.
Current state datapoint = .
Current control datapoint = .
Device description
Device JPMP300050 MP3-LED_50 [HB-OU-MP3-LED]
CHILDREN: JPMP300050:0,JPMP300050:1,JPMP300050:2
FIRMWARE: 1.0
FLAGS: Visible
INTERFACE: NEQ0605931
PARAMSETS: MASTER
RF_ADDRESS: 15942736
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG
UPDATABLE: 1
Channel JPMP300050:0 MP3-LED_50:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: JPMP300050
PARENT_TYPE: HB-OU-MP3-LED
Channel JPMP300050:1 HB-OU-MP3-LED JPMP300050:1 [SIGNAL_LED]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: JPMP300050
PARENT_TYPE: HB-OU-MP3-LED
Defaults
Ich habe es gerade manuell installiert, Test dann demnächst (erst noch Gehäuse fertigstellen...)
Hallo zusammen,
ich versuche gerade neue HMiP Wired Geräte in die HMCCU einzubinden das funktioniert aber seit 5.0 nicht mehr als "HMCCUCHN" !?
Laut Anleitung gibt es scheinbar nur noch die Möglichkeit über "get d_ccu createDev" Geräte anzulegen?
Beispiel: ein "HmIPW-DRS4" is ein Gerät und hat 4 Schaltaktoren die natürlich in FHEM als einzelnes Gerät angelegt werden muss.
Vor Version 5.0 konnte man zwischen DEV und HMCCUCHN Anlagen wählen.
Somit wurde für alle Aktoren/Kanäle des "HmIPW-DRS4" ein einzelnes Gerät (HMCCUCHN) angelegt.
Die bereits vor Vers. 5.0 angelegten "HMCCUCHN" funktionieren auch weiterhin.
Nur kann ich nun weitere Aktoren nur noch über ein DEV anlegen. Somit nicht für jeden Aktor ein eigenes FHEM Device.
bei einem "get deviceInfo" des besagten CCU Gerätes A1_4fach_Aktor_1_HmIPW-DRS4(HmIPW-DRS4) mit 4 Aktoren werden alle CHN richtig aufgelistet
Dieser CHN soll eingebunden werden:
CHN 0015D8A99C846F:14 Hausflur_Steckdose_am_Fenster
Wenn ich nun ein get d_ccu createDev A1_4fach_Aktor_1_HmIPW-DRS4.* eingebe wird mir dieser CHN aber nicht angezeigt?
Mache ich etwas falsch oder ist dies ein Bug?
Alles, was die offiziell via update verteilte HMCCU 5.0 betrifft gehört in den Thread: https://forum.fhem.de/index.php/topic,123686.0.html
Hallo @zap,
vielleicht hast Du es nicht gesehen, ich habe vor mehreren Tagen in github ein Ticket aufgemacht, weil meine CuXD Geräte nicht mehr funktionieren:
https://github.com/zapccu/HMCCU/issues/167
Ich finde auch nirgendwo was dazu, was das Problem lösen könnte.
Hier das Beispiel:
define FritzDECT1 HMCCUCHN CUX2801005:1
setuuid FritzDECT1 5c4afdb8-f33f-2248-361a-5cf984e924436f21
attr FritzDECT1 IODev ccu2
attr FritzDECT1 alias MusikEcke
attr FritzDECT1 ccureadingfilter (STATE|ON_TIME)
attr FritzDECT1 devStateIcon on:message_socket_enabled@green off:message_socket_disabled@black Initialized:message_socket_unknown@red
attr FritzDECT1 event-on-change-reading .*
attr FritzDECT1 fp_Home3D 523,360,0,FritzDECT1
attr FritzDECT1 genericDeviceType switch
attr FritzDECT1 homebridgeMapping On=state,valueOn=on,valueOff=off Brightness=clear
attr FritzDECT1 room Büro,HomekitActors
attr FritzDECT1 siriName MusikEcke
attr FritzDECT1 statedatapoint STATE
attr FritzDECT1 statevals on:true,off:false
attr FritzDECT1 substitute STATE!true:on,false:off,1:on,0:off
Kannst Du helfen?
default reset oder forcereset bringt nichts:
Device type HM-LC-Sw1-Pl not known by HMCCU Cannot detect role of MusikEcke No version 4.3 default attributes found
Wie kriege ich das wieder zum Laufen?
Hallo
Falls es benötigt wird habe ich hier noch die Daten für HmIP-MP3P
Device channels and datapoints
DEV HM_Kombisignalgeber_DEV 00151D89A00000 interface=HmIP-RF type=HmIP-MP3P
CHN 00151D89A00000:0 HM_Kombisignalgeber:0
0.CONFIG_PENDING = false {b} [RE]
0.DUTY_CYCLE = false {b} [RE]
0.ERROR_CODE_STATUS = 0 {i} [RE]
0.INSTALL_TEST = true {b} [RW]
0.LOW_BAT = false {b} [RE]
0.OPERATING_VOLTAGE = 0.000000 {f} [RE]
0.OPERATING_VOLTAGE_STATUS = 0 {i} [RE]
0.RSSI_DEVICE = 220 {n} [RE]
0.RSSI_PEER = 219 {n} [RE]
0.STATUS_FLAG_ERROR = false {b} [RE]
0.STATUS_FLAG_LOW_BAT = false {b} [RE]
0.STATUS_FLAG_PLAYING_FILE_ACTIVE = false {b} [RE]
0.STATUS_FLAG_PLAYLIST_ACTIVE = false {b} [RE]
0.UNREACH = false {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
CHN 00151D89A00000:1 HM_MP3-Player:1
1.ACTIVITY_STATE = 0 {i} [RE]
1.LEVEL = 0.000000 {f} [RE]
1.LEVEL_STATUS = 0 {i} [RE]
1.PROCESS = 0 {i} [RE]
1.SECTION = {i} [RE]
1.SECTION_STATUS = 1 {i} [RE]
1.SOUNDFILE = 0 {i} [RE]
CHN 00151D89A00000:2 HM_MP3-Player:2
2.ACTIVITY_STATE = 3 {i} [RE]
2.COMBINED_PARAMETER = {s} [W]
2.DURATION_UNIT = {i} [W]
2.DURATION_VALUE = {i} [W]
2.LEVEL = 0.000000 {f} [RWE]
2.LEVEL_STATUS = 0 {i} [RE]
2.OUTPUT_SELECT_SIZE = {i} [W]
2.PROCESS = 0 {i} [RE]
2.RAMP_TIME_UNIT = {i} [W]
2.RAMP_TIME_VALUE = {i} [W]
2.REPETITIONS = {i} [W]
2.SECTION = 0 {i} [RE]
2.SECTION_STATUS = 0 {i} [RE]
2.SOUNDFILE = 0 {i} [RWE]
2.SOUNDFILE_LIST_1 = {i} [W]
2.SOUNDFILE_LIST_10 = {i} [W]
2.SOUNDFILE_LIST_11 = {i} [W]
2.SOUNDFILE_LIST_12 = {i} [W]
2.SOUNDFILE_LIST_2 = {i} [W]
2.SOUNDFILE_LIST_3 = {i} [W]
2.SOUNDFILE_LIST_4 = {i} [W]
2.SOUNDFILE_LIST_5 = {i} [W]
2.SOUNDFILE_LIST_6 = {i} [W]
2.SOUNDFILE_LIST_7 = {i} [W]
2.SOUNDFILE_LIST_8 = {i} [W]
2.SOUNDFILE_LIST_9 = {i} [W]
2.STOP = {b} [W]
CHN 00151D89A00000:3 HM_MP3-Player:3
3.ACTIVITY_STATE = 3 {i} [RE]
3.DURATION_UNIT = {i} [W]
3.DURATION_VALUE = {i} [W]
3.LEVEL = 0.000000 {f} [RWE]
3.LEVEL_STATUS = 0 {i} [RE]
3.PROCESS = 0 {i} [RE]
3.RAMP_TIME_UNIT = {i} [W]
3.RAMP_TIME_VALUE = {i} [W]
3.SECTION = 0 {i} [RE]
3.SECTION_STATUS = 0 {i} [RE]
3.STOP = {b} [W]
CHN 00151D89A00000:4 HM_MP3-Player:4
4.ACTIVITY_STATE = 3 {i} [RE]
4.DURATION_UNIT = {i} [W]
4.DURATION_VALUE = {i} [W]
4.LEVEL = 0.000000 {f} [RWE]
4.LEVEL_STATUS = 0 {i} [RE]
4.PROCESS = 0 {i} [RE]
4.RAMP_TIME_UNIT = {i} [W]
4.RAMP_TIME_VALUE = {i} [W]
4.SECTION = 0 {i} [RE]
4.SECTION_STATUS = 0 {i} [RE]
4.STOP = {b} [W]
CHN 00151D89A00000:5 HM_Dimmaktor:5
5.ACTIVITY_STATE = 0 {i} [RE]
5.COLOR = 7 {i} [RE]
5.COLOR_STATUS = 0 {i} [RE]
5.LEVEL = 0.000000 {a} [RE]
5.LEVEL_STATUS = 0 {i} [RE]
5.PROCESS = 0 {i} [RE]
5.SECTION = {i} [RE]
5.SECTION_STATUS = 1 {i} [RE]
CHN 00151D89A00000:6 HM_Dimmaktor:6
6.ACTIVITY_STATE = 3 {i} [RE]
6.COLOR = 2 {i} [RWE]
6.COLOR_LIST_1 = {i} [W]
6.COLOR_LIST_10 = {i} [W]
6.COLOR_LIST_11 = {i} [W]
6.COLOR_LIST_12 = {i} [W]
6.COLOR_LIST_2 = {i} [W]
6.COLOR_LIST_3 = {i} [W]
6.COLOR_LIST_4 = {i} [W]
6.COLOR_LIST_5 = {i} [W]
6.COLOR_LIST_6 = {i} [W]
6.COLOR_LIST_7 = {i} [W]
6.COLOR_LIST_8 = {i} [W]
6.COLOR_LIST_9 = {i} [W]
6.COLOR_STATUS = 0 {i} [RE]
6.COMBINED_PARAMETER = {s} [W]
6.DURATION_UNIT = {i} [W]
6.DURATION_VALUE = {i} [W]
6.LEVEL = 0.000000 {a} [RWE]
6.LEVEL_STATUS = 0 {i} [RE]
6.ON_TIME_LIST_1 = {i} [W]
6.ON_TIME_LIST_10 = {i} [W]
6.ON_TIME_LIST_11 = {i} [W]
6.ON_TIME_LIST_12 = {i} [W]
6.ON_TIME_LIST_2 = {i} [W]
6.ON_TIME_LIST_3 = {i} [W]
6.ON_TIME_LIST_4 = {i} [W]
6.ON_TIME_LIST_5 = {i} [W]
6.ON_TIME_LIST_6 = {i} [W]
6.ON_TIME_LIST_7 = {i} [W]
6.ON_TIME_LIST_8 = {i} [W]
6.ON_TIME_LIST_9 = {i} [W]
6.OUTPUT_SELECT_SIZE = {i} [W]
6.PROCESS = 0 {i} [RE]
6.RAMP_TIME_UNIT = {i} [W]
6.RAMP_TIME_VALUE = {i} [W]
6.REPETITIONS = {i} [W]
6.SECTION = 0 {i} [RE]
6.SECTION_STATUS = 0 {i} [RE]
CHN 00151D89A00000:7 HM_Dimmaktor:7
7.ACTIVITY_STATE = 3 {i} [RE]
7.COLOR = 7 {i} [RWE]
7.COLOR_LIST_1 = {i} [W]
7.COLOR_LIST_10 = {i} [W]
7.COLOR_LIST_11 = {i} [W]
7.COLOR_LIST_12 = {i} [W]
7.COLOR_LIST_2 = {i} [W]
7.COLOR_LIST_3 = {i} [W]
7.COLOR_LIST_4 = {i} [W]
7.COLOR_LIST_5 = {i} [W]
7.COLOR_LIST_6 = {i} [W]
7.COLOR_LIST_7 = {i} [W]
7.COLOR_LIST_8 = {i} [W]
7.COLOR_LIST_9 = {i} [W]
7.COLOR_STATUS = 0 {i} [RE]
7.COMBINED_PARAMETER = {s} [W]
7.DURATION_UNIT = {i} [W]
7.DURATION_VALUE = {i} [W]
7.LEVEL = 0.000000 {a} [RWE]
7.LEVEL_STATUS = 0 {i} [RE]
7.ON_TIME_LIST_1 = {i} [W]
7.ON_TIME_LIST_10 = {i} [W]
7.ON_TIME_LIST_11 = {i} [W]
7.ON_TIME_LIST_12 = {i} [W]
7.ON_TIME_LIST_2 = {i} [W]
7.ON_TIME_LIST_3 = {i} [W]
7.ON_TIME_LIST_4 = {i} [W]
7.ON_TIME_LIST_5 = {i} [W]
7.ON_TIME_LIST_6 = {i} [W]
7.ON_TIME_LIST_7 = {i} [W]
7.ON_TIME_LIST_8 = {i} [W]
7.ON_TIME_LIST_9 = {i} [W]
7.OUTPUT_SELECT_SIZE = {i} [W]
7.PROCESS = 0 {i} [RE]
7.RAMP_TIME_UNIT = {i} [W]
7.RAMP_TIME_VALUE = {i} [W]
7.REPETITIONS = {i} [W]
7.SECTION = 0 {i} [RE]
7.SECTION_STATUS = 0 {i} [RE]
CHN 00151D89A00000:8 HM_Dimmaktor:8
8.ACTIVITY_STATE = 3 {i} [RE]
8.COLOR = 0 {i} [RWE]
8.COLOR_LIST_1 = {i} [W]
8.COLOR_LIST_10 = {i} [W]
8.COLOR_LIST_11 = {i} [W]
8.COLOR_LIST_12 = {i} [W]
8.COLOR_LIST_2 = {i} [W]
8.COLOR_LIST_3 = {i} [W]
8.COLOR_LIST_4 = {i} [W]
8.COLOR_LIST_5 = {i} [W]
8.COLOR_LIST_6 = {i} [W]
8.COLOR_LIST_7 = {i} [W]
8.COLOR_LIST_8 = {i} [W]
8.COLOR_LIST_9 = {i} [W]
8.COLOR_STATUS = 0 {i} [RE]
8.COMBINED_PARAMETER = {s} [W]
8.DURATION_UNIT = {i} [W]
8.DURATION_VALUE = {i} [W]
8.LEVEL = 0.000000 {a} [RWE]
8.LEVEL_STATUS = 0 {i} [RE]
8.ON_TIME_LIST_1 = {i} [W]
8.ON_TIME_LIST_10 = {i} [W]
8.ON_TIME_LIST_11 = {i} [W]
8.ON_TIME_LIST_12 = {i} [W]
8.ON_TIME_LIST_2 = {i} [W]
8.ON_TIME_LIST_3 = {i} [W]
8.ON_TIME_LIST_4 = {i} [W]
8.ON_TIME_LIST_5 = {i} [W]
8.ON_TIME_LIST_6 = {i} [W]
8.ON_TIME_LIST_7 = {i} [W]
8.ON_TIME_LIST_8 = {i} [W]
8.ON_TIME_LIST_9 = {i} [W]
8.OUTPUT_SELECT_SIZE = {i} [W]
8.PROCESS = 0 {i} [RE]
8.RAMP_TIME_UNIT = {i} [W]
8.RAMP_TIME_VALUE = {i} [W]
8.REPETITIONS = {i} [W]
8.SECTION = 7 {i} [RE]
8.SECTION_STATUS = 0 {i} [RE]
CHN 00151D89A00000:9 HmIP-MP3P 00151D89A00000:9
9.COMBINED_PARAMETER = {s} [W]
9.WEEK_PROGRAM_CHANNEL_LOCKS = 0 {i} [RE]
9.WEEK_PROGRAM_TARGET_CHANNEL_LOCK = {i} [W]
9.WEEK_PROGRAM_TARGET_CHANNEL_LOCKS = {i} [W]
Device detection:
StateDatapoint = 5.LEVEL [DIMMER_TRANSMITTER]
StateDatapoint = 6.LEVEL [DIMMER_VIRTUAL_RECEIVER]
StateDatapoint = 7.LEVEL [DIMMER_VIRTUAL_RECEIVER]
StateDatapoint = 8.LEVEL [DIMMER_VIRTUAL_RECEIVER]
ControlDatapoint = 6.LEVEL [DIMMER_VIRTUAL_RECEIVER]
ControlDatapoint = 7.LEVEL [DIMMER_VIRTUAL_RECEIVER]
ControlDatapoint = 8.LEVEL [DIMMER_VIRTUAL_RECEIVER]
Recommended module for device definition: HMCCUDEV
Current state datapoint = 5.LEVEL
Current control datapoint = 6.LEVEL
Device description
Device 00151D89A00000 HM_Kombisignalgeber_DEV [HmIP-MP3P]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 00151D89A00000:0,00151D89A00000:1,00151D89A00000:2,00151D89A00000:3,00151D89A00000:4,00151D89A00000:5,00151D89A00000:6,00151D89A00000:7,00151D89A00000:8,00151D89A00000:9
DIRECTION: NONE
FIRMWARE: 1.0.26
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 7306960
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG,BURST
SUBTYPE: MP3P
UPDATABLE: 1
Channel 00151D89A00000:0 HM_Kombisignalgeber:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 00151D89A00000
PARENT_TYPE: HmIP-MP3P
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00151D89A00000:1 HmIP-MP3P 00151D89A00000:1 [ACOUSTIC_SIGNAL_TRANSMITTER]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 00151D89A00000
PARENT_TYPE: HmIP-MP3P
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00151D89A00000:2 HM_MP3-Player:2 [ACOUSTIC_SIGNAL_VIRTUAL_RECEIVER]
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: CONDITIONAL_SWITCH,REMOTE_CONTROL,SWITCH,LEVEL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00151D89A00000
PARENT_TYPE: HmIP-MP3P
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00151D89A00000:3 HM_MP3-Player:3 [ACOUSTIC_SIGNAL_VIRTUAL_RECEIVER]
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: CONDITIONAL_SWITCH,REMOTE_CONTROL,SWITCH,LEVEL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00151D89A00000
PARENT_TYPE: HmIP-MP3P
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00151D89A00000:4 HM_MP3-Player:4 [ACOUSTIC_SIGNAL_VIRTUAL_RECEIVER]
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: CONDITIONAL_SWITCH,REMOTE_CONTROL,SWITCH,LEVEL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00151D89A00000
PARENT_TYPE: HmIP-MP3P
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00151D89A00000:5 HmIP-MP3P 00151D89A00000:5 [DIMMER_TRANSMITTER] known
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 00151D89A00000
PARENT_TYPE: HmIP-MP3P
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00151D89A00000:6 HM_Dimmaktor:6 [DIMMER_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: CONDITIONAL_SWITCH,REMOTE_CONTROL,SWITCH,LEVEL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00151D89A00000
PARENT_TYPE: HmIP-MP3P
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00151D89A00000:7 HM_Dimmaktor:7 [DIMMER_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: CONDITIONAL_SWITCH,REMOTE_CONTROL,SWITCH,LEVEL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00151D89A00000
PARENT_TYPE: HmIP-MP3P
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00151D89A00000:8 HM_Dimmaktor:8 [DIMMER_VIRTUAL_RECEIVER] known
AES_ACTIVE: 1
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: CONDITIONAL_SWITCH,REMOTE_CONTROL,SWITCH,LEVEL
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 00151D89A00000
PARENT_TYPE: HmIP-MP3P
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 00151D89A00000:9 HmIP-MP3P 00151D89A00000:9 [DIMMER_OUTPUT_BEHAVIOUR_WEEK_PROFILE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 00151D89A00000
PARENT_TYPE: HmIP-MP3P
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Defaults
Support for role DIMMER_VIRTUAL_RECEIVER of device type HmIP-MP3P is built in.
Die Date für die paramsetDesc HmIP-MP3P habe als Datei Angehängt.
Vielen Dank
mfg wolfgang
Hallo,
Ich habe jetzt auch diese HmIP-STH bei mir im Einsatz.
Sie habe sich auch ohne Probleme über createDEV installieren lassen.
Es gibt aber Unterschiede zwischen diesen und den HM-TC-IT-WM-W-EU.
z.B. gibt es beim HM-TC-IT-WM-W-EU das Week-Program
und beim HmIP-STH heißt es ACTIVE_PROFILE wo man bis zu 6 Profile auswählen kann.
Diese Funktion gibt es nicht.
Device channels and datapoints
DEV HM_Wandthermostat_Eingang_DEV 000E5BE9A77E1B interface=HmIP-RF type=HmIP-STH
CHN 000E5BE9A77E1B:0 HM_Wandthermostat_Eingang_DEV:0
0.CONFIG_PENDING = false {b} [RE]
0.DUTY_CYCLE = false {b} [RE]
0.INSTALL_TEST = true {b} [RW]
0.LOW_BAT = false {b} [RE]
0.OPERATING_VOLTAGE = 2.900000 {f} [RE]
0.OPERATING_VOLTAGE_STATUS = 0 {i} [RE]
0.RSSI_DEVICE = 173 {n} [RE]
0.RSSI_PEER = 167 {n} [RE]
0.UNREACH = false {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
CHN 000E5BE9A77E1B:1 HM_Wandthermostat_Eingang:1
1.ACTIVE_PROFILE = 1 {i} [RWE]
1.ACTUAL_TEMPERATURE = 17.400000 {f} [RE]
1.ACTUAL_TEMPERATURE_STATUS = 0 {i} [RE]
1.BOOST_MODE = false {b} [WE]
1.BOOST_TIME = 0 {i} [RE]
1.CONTROL_DIFFERENTIAL_TEMPERATURE = {f} [W]
1.CONTROL_MODE = {i} [W]
1.DURATION_UNIT = {i} [W]
1.DURATION_VALUE = {i} [W]
1.FROST_PROTECTION = false {b} [RE]
1.HEATING_COOLING = 0 {i} [RWE]
1.HUMIDITY = 43 {i} [RE]
1.HUMIDITY_STATUS = 0 {i} [RE]
1.PARTY_MODE = false {b} [RE]
1.PARTY_SET_POINT_TEMPERATURE = 0.000000 {f} [RE]
1.PARTY_TIME_END = {s} [RWE]
1.PARTY_TIME_START = {s} [RWE]
1.QUICK_VETO_TIME = 0 {i} [RE]
1.SET_POINT_MODE = 0 {i} [RWE]
1.SET_POINT_TEMPERATURE = 20.000000 {f} [RWE]
1.SWITCH_POINT_OCCURED = false {b} [RE]
1.WINDOW_STATE = 0 {i} [RWE]
Device detection:
StateDatapoint = 1.ACTUAL_TEMPERATURE [HEATING_CLIMATECONTROL_TRANSCEIVER]
ControlDatapoint = 1.SET_POINT_TEMPERATURE [HEATING_CLIMATECONTROL_TRANSCEIVER]
Recommended module for device definition: HMCCUCHN
Current state datapoint = 1.ACTUAL_TEMPERATURE
Current control datapoint = 1.SET_POINT_TEMPERATURE
Device description
Device 000E5BE9A77E1B HM_Wandthermostat_Eingang_DEV [HmIP-STH]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 000E5BE9A77E1B:0,000E5BE9A77E1B:1,000E5BE9A77E1B:2,000E5BE9A77E1B:3,000E5BE9A77E1B:4,000E5BE9A77E1B:5,000E5BE9A77E1B:6,000E5BE9A77E1B:7
DIRECTION: NONE
FIRMWARE: 2.6.0
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 4580006
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG,BURST
SUBTYPE: STH
UPDATABLE: 1
Channel 000E5BE9A77E1B:0 HM_Wandthermostat_Eingang_DEV:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 000E5BE9A77E1B
PARENT_TYPE: HmIP-STH
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 000E5BE9A77E1B:1 HM_Wandthermostat_Eingang:1 [HEATING_CLIMATECONTROL_TRANSCEIVER] known
AES_ACTIVE: 1
DIRECTION: SENDER
FLAGS: Visible
LINK_SOURCE_ROLES: CLIMATE_CONTROL_WTH_TRV
PARAMSETS: MASTER,VALUES,LINK,SERVICE
PARENT: 000E5BE9A77E1B
PARENT_TYPE: HmIP-STH
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Defaults
Support for role HEATING_CLIMATECONTROL_TRANSCEIVER of device type HmIP-STH is built in.
Die paramsetDesc habe ich als Datei Angehängt
vielen Dank
mfg wolfgang
Hallo,
ich habe leider eine Zeit lang kein Update gemacht und bin nun von HMCCU Version 4.3.025 auf 5.0 per FHEM update hochgezogen.
Der RPC-Server liefert auch weiterhin updates, es kommen regelmäßig Events rein.
Allerdings werden keine Readings der Datapoints mehr aktualisiert (außer INSTALL_TEST).
Daraufhin habe ich die Device- und Channel - Module resetet, wodurch die Readings der Datapoints dann auch gelöscht wurden.
Wenn ich jetzt aber ein get update mache, bekomme ich alle Datapoints angezeigt.
Hier das Beispiel eines HM-Sen-MDIR-SM:
Readings for config parameters are not updated until you set showXXX flags in attribute ccuflags
Device OEQ0756369
Channel 0 [VALUES]
AES_KEY = off
CONFIG_PENDING = false
DEVICE_IN_BOOTLOADER = false
LOWBAT = ok
RSSI_DEVICE = N/A
RSSI_PEER = -51
STICKY_UNREACH = false
UNREACH = alive
UPDATE_PENDING = false
Channel 1 [MASTER]
AES_ACTIVE = 1
BRIGHTNESS_FILTER = 0
CAPTURE_WITHIN_INTERVAL = 1
EVENT_FILTER_NUMBER = 1
EVENT_FILTER_PERIOD = 00:00:01
LED_ONTIME = 00:00:00
MIN_INTERVAL = 0
Channel 1 [VALUES]
BRIGHTNESS = 254
MOTION = noMotion
NEXT_TRANSMISSION = 17
Der Befehl get datapoint BRIGHTNESS liefert ebenfalls den korrekten Wert für den Datapoint 1.BRIGHTNESS.
Dennoch wird kein Reading angelegt.
Hier noch die RAW-Definition:
defmod HM_BewegungsmelderBalkon_Bewegung HMCCUCHN OEQ0756369:1
attr HM_BewegungsmelderBalkon_Bewegung IODev CCU2
attr HM_BewegungsmelderBalkon_Bewegung ccureadingfilter ^(BRIGHTNESS|INSTALL_TEST|MOTION)$
attr HM_BewegungsmelderBalkon_Bewegung cmdIcon getDevState:refresh
attr HM_BewegungsmelderBalkon_Bewegung group Bewegungsmelder
attr HM_BewegungsmelderBalkon_Bewegung room CCU2_HM
attr HM_BewegungsmelderBalkon_Bewegung userReadings brightness {return ReadingsVal($name,"1.BRIGHTNESS","na")},\
motion {my $motion = ReadingsVal($name,"1.MOTION","noMotion");; if($motion eq "yes"){$motion = "motion";;} if($motion eq "no"){$motion = "noMotion";;} return $motion;;}
setstate HM_BewegungsmelderBalkon_Bewegung noMotion
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .AES_KEY off
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .CONFIG_PENDING false
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .DEVICE_IN_BOOTLOADER false
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .LOWBAT ok
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .NEXT_TRANSMISSION 17
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .R-AES_ACTIVE 1
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .R-BRIGHTNESS_FILTER 0
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .R-CAPTURE_WITHIN_INTERVAL 1
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .R-EVENT_FILTER_NUMBER 1
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .R-EVENT_FILTER_PERIOD 00:00:01
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .R-LED_ONTIME 00:00:00
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .R-MIN_INTERVAL 0
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .RSSI_DEVICE N/A
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .RSSI_PEER -51
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .STICKY_UNREACH false
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .UNREACH alive
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:52:31 .UPDATE_PENDING false
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:58:06 INSTALL_TEST 1
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:58:23 activity alive
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:58:23 battery ok
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:58:23 brightness na
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:58:23 devstate ok
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:58:23 hmstate noMotion
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:58:23 motion noMotion
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:58:23 rssidevice N/A
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:58:23 rssipeer -51
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:58:23 sign off
setstate HM_BewegungsmelderBalkon_Bewegung 2021-12-21 09:58:23 state noMotion
Habt ihr eine Idee, woran das liegen kann? Ich würde ungern meine ganzen Geräte alle neu anlegen müssen.
Viele Grüße
Sebastian
Hallo Sebastian,
das wurde hier schon mehrfach besprochen. Test einmal "set <Device> clear defaults.
s.a. https://forum.fhem.de/index.php/topic,123686.0.html (https://forum.fhem.de/index.php/topic,123686.0.html)
Viele Grüße
Jürgen
Hallo,
Danke für die schnelle Antwort. Hab die Diskussion übersehen.
Leider hat sich dadurch noch nichts geändert.
ich schreib aber trotzdem im Topic " HMCCU 5.0 im SVN verfügbar " weiter.
VG
Sebastian
Hallo!
Wenn ich jetzt das standard FHEM Update durchführe ... wird dann meine HMCCU V5 version inzwischen auch geupdated oder wird sie wieder runter auf v4.3 downgegraded?
Vielen Dank!
Siehe Post im SVN verfügbar. Sie wird also aktualisiert
Homematic Funk-Kombisignalgeber MP3 HM-OU-CFM-TW mit HMCCU 5.0
Bin gerade dabei einige Geräte, die bisher über CUL an Fhem angebunden waren auf CCU3 und HMCCU umzustellen. Im Allgemeinen funktioniert alles wunderbar, aber der HM-OU-CFM-TW wird offensichtlich durch createDev nicht erkannt und sollte mit HMCCUDEV manuell definiert werden. Wie das im Detail sicher funktioniert, konnte ich mir bis jetzt nicht erarbeiten.
Unter diesem Beitrag gibt es von Reinschki am 1.10.2021 18:15:17 schon eine Anfrage zum HM-OU-CFM-TW. Leider ist die für Reinschki gefundene Lösung für mich nicht anwendbar.
Für konkrete Hilfe wäre ich sehr dankbar.
Beste Grüße
Peter
PROBLEM IST GELÖST, SIGNALGEBER FUNZT AUF ALLEN KANÄLEN.
@zap:
Habe heute ein Update gemacht und erhalte jetzt:
2022.02.25 11:20:05 2: HMCCUDEV [Lichtsensor] Can't get parameterset SERVICE for address 000D58A9A5AF41:2
2022.02.25 11:20:06 2: HMCCURPCPROC [d_rpc002252HmIP_RF] RPC request getParamset failed: Generic error (TIMEOUT)
2022.02.25 11:20:06 2: HMCCURPCPROC [d_rpc002252HmIP_RF] Retrying request getParamset
2022.02.25 11:20:07 2: HMCCURPCPROC [d_rpc002252HmIP_RF] RPC request getParamset failed: Generic error (TIMEOUT)
2022.02.25 11:20:07 2: HMCCURPCPROC [d_rpc002252HmIP_RF] Retrying request getParamset
2022.02.25 11:20:07 2: HMCCUDEV [Lichtsensor] Can't get parameterset SERVICE for address 000D58A9A5AF41:3
Der Lichtsensor ist wie folgt definiert:
Internals:
DEF 000D58A9A5AF41
FUUID 602d2b85-f33f-49d8-af93-3b89a7091d78aa47
IODev CCU3
NAME Lichtsensor
NR 55
STATE 2022-02-25 11:30:04<br> lx: 0.0
TYPE HMCCUDEV
ccuaddr 000D58A9A5AF41
ccudevstate active
ccuif HmIP-RF
ccuname Lichtsensor
ccurolestate BRIGHTNESS_TRANSMITTER
ccusubtype SLO
ccutype HmIP-SLO
firmware 1.0.16
readonly no
READINGS:
2022-02-25 11:30:04 1.AVERAGE_ILLUMINATION 2079.0
2022-02-25 11:30:04 1.AVERAGE_ILLUMINATION_STATUS NORMAL
2022-02-25 11:30:04 1.CURRENT_ILLUMINATION 0.0
2022-02-25 11:30:04 1.CURRENT_ILLUMINATION_STATUS NORMAL
2022-02-25 11:30:04 1.HIGHEST_ILLUMINATION 5135.0
2022-02-25 11:30:04 1.HIGHEST_ILLUMINATION_STATUS NORMAL
2022-02-25 11:30:04 1.LOWEST_ILLUMINATION 865.6
2022-02-25 11:30:04 1.LOWEST_ILLUMINATION_STATUS NORMAL
2022-02-25 11:15:19 IODev CCU3
2022-02-25 11:30:04 activity alive
2022-02-25 11:30:04 battery ok
2022-02-25 11:30:04 devstate ok
2022-02-25 11:30:04 hmstate 0.0
2022-02-25 11:30:04 rssidevice -50
2022-02-25 11:15:57 rssipeer N/A
2022-02-25 11:30:04 state 0.0
2022-02-25 11:30:04 voltage 2.4
hmccu:
channels 4
detect 1
devspec 000D58A9A5AF41
forcedev 0
nodefaults 1
role 0:MAINTENANCE,1:BRIGHTNESS_TRANSMITTER,2:COND_SWITCH_TRANSMITTER,3:COND_SWITCH_TRANSMITTER
setDefaults 0
cmdlist:
get
set
control:
dp:
0.ARR_TIMEOUT:
MASTER:
NVAL 10
ONVAL 10
OSVAL 10
OVAL 10
SVAL 10
VAL 10
VALUES:
0.CONFIG_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.CYCLIC_INFO_MSG:
MASTER:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
0.CYCLIC_INFO_MSG_DIS:
MASTER:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
0.CYCLIC_INFO_MSG_DIS_UNCHANGED:
MASTER:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
0.CYCLIC_INFO_MSG_OVERDUE_THRESHOLD:
MASTER:
NVAL 2
ONVAL 2
OSVAL 2
OVAL 2
SVAL 2
VAL 2
VALUES:
0.DISABLE_MSG_TO_AC:
MASTER:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
0.DUTYCYCLE_LIMIT:
MASTER:
NVAL 180
ONVAL 180
OSVAL 180
OVAL 180
SVAL 180
VAL 180
VALUES:
0.DUTY_CYCLE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ENABLE_ROUTING:
MASTER:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
0.INSTALL_TEST:
VALUES:
NVAL true
ONVAL true
OSVAL true
OVAL true
SVAL true
VAL true
0.LOCAL_RESET_DISABLED:
MASTER:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
0.LOW_BAT:
VALUES:
NVAL 0
ONVAL 0
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.LOW_BAT_LIMIT:
MASTER:
NVAL 2.4
ONVAL 2.4
OSVAL 2.4
OVAL 2.4
SVAL 2.4
VAL 2.4
VALUES:
0.OPERATING_VOLTAGE:
VALUES:
NVAL 2.4
ONVAL 2.4
OSVAL 2.4
OVAL 2.4
SVAL 2.4
VAL 2.4
0.OPERATING_VOLTAGE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL -50
ONVAL -50
OSVAL -50
OVAL -50
SVAL -50
VAL -50
0.RSSI_PEER:
VALUES:
NVAL N/A
ONVAL N/A
OSVAL N/A
OVAL 0
SVAL N/A
VAL 0
0.UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
NVAL 0
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL 0
1.AVERAGE_ILLUMINATION:
VALUES:
NVAL 2079.0
ONVAL 2079.0
OSVAL 2079.0
OVAL 2079.0
SVAL 2079.0
VAL 2079.0
1.AVERAGE_ILLUMINATION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.CURRENT_ILLUMINATION:
VALUES:
NVAL 0.0
ONVAL 0.0
OSVAL 0.0
OVAL 0.0
SVAL 0.0
VAL 0.0
1.CURRENT_ILLUMINATION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.FILTER_SIZE:
MASTER:
NVAL 10
ONVAL 10
OSVAL 10
OVAL 10
SVAL 10
VAL 10
VALUES:
1.HIGHEST_ILLUMINATION:
VALUES:
NVAL 5135.0
ONVAL 5135.0
OSVAL 5135.0
OVAL 5135.0
SVAL 5135.0
VAL 5135.0
1.HIGHEST_ILLUMINATION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.LOWEST_ILLUMINATION:
VALUES:
NVAL 865.6
ONVAL 865.6
OSVAL 865.6
OVAL 865.6
SVAL 865.6
VAL 865.6
1.LOWEST_ILLUMINATION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
2.COND_TX_CYCLIC_ABOVE:
MASTER:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
2.COND_TX_CYCLIC_BELOW:
MASTER:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
2.COND_TX_DECISION_ABOVE:
MASTER:
NVAL 200
ONVAL 200
OSVAL 200
OVAL 200
SVAL 200
VAL 200
VALUES:
2.COND_TX_DECISION_BELOW:
MASTER:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
2.COND_TX_FALLING:
MASTER:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
2.COND_TX_RISING:
MASTER:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
2.COND_TX_THRESHOLD_HI:
MASTER:
NVAL 10.0
ONVAL 10.0
OSVAL 10.0
OVAL 10.0
SVAL 10.0
VAL 10.0
VALUES:
2.COND_TX_THRESHOLD_LO:
MASTER:
NVAL 1.0
ONVAL 1.0
OSVAL 1.0
OVAL 1.0
SVAL 1.0
VAL 1.0
VALUES:
2.EVENT_DELAY_UNIT:
MASTER:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
2.EVENT_DELAY_VALUE:
MASTER:
NVAL 3
ONVAL 3
OSVAL 3
OVAL 3
SVAL 3
VAL 3
VALUES:
2.EVENT_RANDOMTIME_UNIT:
MASTER:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
2.EVENT_RANDOMTIME_VALUE:
MASTER:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
3.COND_TX_CYCLIC_ABOVE:
MASTER:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
3.COND_TX_CYCLIC_BELOW:
MASTER:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
3.COND_TX_DECISION_ABOVE:
MASTER:
NVAL 200
ONVAL 200
OSVAL 200
OVAL 200
SVAL 200
VAL 200
VALUES:
3.COND_TX_DECISION_BELOW:
MASTER:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
3.COND_TX_FALLING:
MASTER:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
3.COND_TX_RISING:
MASTER:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
VALUES:
3.COND_TX_THRESHOLD_HI:
MASTER:
NVAL 50.0
ONVAL 50.0
OSVAL 50.0
OVAL 50.0
SVAL 50.0
VAL 50.0
VALUES:
3.COND_TX_THRESHOLD_LO:
MASTER:
NVAL 5.0
ONVAL 5.0
OSVAL 5.0
OVAL 5.0
SVAL 5.0
VAL 5.0
VALUES:
3.EVENT_DELAY_UNIT:
MASTER:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
3.EVENT_DELAY_VALUE:
MASTER:
NVAL 3
ONVAL 3
OSVAL 3
OVAL 3
SVAL 3
VAL 3
VALUES:
3.EVENT_RANDOMTIME_UNIT:
MASTER:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
3.EVENT_RANDOMTIME_VALUE:
MASTER:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
VALUES:
roleCmds:
get:
set:
state:
chn 1
dpt CURRENT_ILLUMINATION
Attributes:
DbLogInclude 1.CURRENT_ILLUMINATION
IODev CCU3
alias Lichtsensor
devStateStyle style="text-align:right"
event-on-change-reading .*
group Sensor
icon message_light_intensity
room Garten,Homematic
stateFormat {ReadingsTimestamp('Lichtsensor','1.CURRENT_ILLUMINATION','')
."<br> lx: ".ReadingsVal('Lichtsensor','1.CURRENT_ILLUMINATION','')}
stripnumber 1
Irgendeinen Tipp?
Gruß
eurofinder
@zap:
Und noch ein Gerät was "Probleme" macht nach de mUpdate:
2022.02.25 13:00:04 2: HMCCU [CCU3] Error during HTTP request: http://192.168.2.252:8181/tclrega.exe: Select timeout/error:
2022.02.25 13:00:04 1: HMCCUCHN [Regler_Bad] HMCCUCHN: Regler_Bad Execution of CCU script or command failed
Hier das Device:
Internals:
DEF 000A1709B23BE3:1
FUUID 602bf6ad-f33f-49d8-2745-c08f85493f6bf825
IODev CCU3
NAME Regler_Bad
NR 38
STATE Raumtemperatur: 20.3 °C<br/>Soll: 20 °C<br/>Fenster: <b>closed</b>
TYPE HMCCUCHN
ccuaddr 000A1709B23BE3:1
ccudevstate active
ccuif HmIP-RF
ccuname Regler_Bad:1
ccurolectrl HEATING_CLIMATECONTROL_TRANSCEIVER
ccurolestate HEATING_CLIMATECONTROL_TRANSCEIVER
ccusubtype TRV
ccutype HmIP-eTRV-2
chntype ?
firmware 2.2.8
readonly no
receiver ccu:Sensor_Bad,Fenster_OG_Bad,Sensor_Bad
sender ccu:Sensor_Bad,Fenster_OG_Bad,Sensor_Bad
READINGS:
2022-02-25 13:12:45 ACTIVE_PROFILE 1
2022-02-25 13:12:45 ACTUAL_TEMPERATURE 20.3
2022-02-25 13:12:45 ACTUAL_TEMPERATURE_STATUS NORMAL
2022-02-25 13:12:45 BOOST_MODE false
2022-02-25 13:12:45 BOOST_TIME 0
2022-02-25 13:12:45 FROST_PROTECTION false
2022-02-25 11:15:19 IODev CCU3
2022-02-25 13:12:45 LEVEL 11
2022-02-25 13:12:45 LEVEL_STATUS NORMAL
2022-02-25 13:12:45 PARTY_MODE false
2022-02-25 11:15:57 PARTY_SET_POINT_TEMPERATURE 0
2022-02-25 11:15:57 PARTY_TIME_END
2022-02-25 11:15:57 PARTY_TIME_START
2022-02-25 13:12:45 QUICK_VETO_TIME 0
2022-02-25 13:12:45 SET_POINT_MODE auto
2022-02-25 13:12:45 SET_POINT_TEMPERATURE 20
2022-02-25 13:12:45 SWITCH_POINT_OCCURED false
2022-02-25 11:15:57 VALVE_ADAPTION false
2022-02-25 13:12:45 VALVE_STATE ADAPTION_DONE
2022-02-25 13:12:45 WINDOW_STATE closed
2022-02-25 13:12:45 activity alive
2022-02-25 13:12:45 battery ok
2022-02-25 13:12:45 control 20
2022-02-25 13:12:45 controlMode auto
2022-02-25 13:12:45 desired-temp 20
2022-02-25 13:12:45 devstate ok
2022-02-25 13:12:45 hmstate 20.3
2022-02-25 13:12:45 measured-temp 20.3
2022-02-25 13:12:45 rssidevice -79
2022-02-25 11:15:57 rssipeer 0
2022-02-25 13:12:45 state 20.3
2022-02-25 13:12:45 voltage 2.8
hmccu:
channels 1
detect 1
devspec 000A1709B23BE3:1
nodefaults 1
role 1:HEATING_CLIMATECONTROL_TRANSCEIVER
setDefaults 0
cmdlist:
get
set auto:noArg holiday:noArg desired-temp boost:noArg off:noArg manu:noArg on:noArg toggle:noArg
control:
chn 1
dpt SET_POINT_TEMPERATURE
dp:
0.CONFIG_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.INSTALL_TEST:
VALUES:
NVAL true
ONVAL true
OSVAL true
OVAL true
SVAL true
VAL true
0.LOW_BAT:
VALUES:
NVAL 0
ONVAL 0
OSVAL ok
OVAL 0
SVAL ok
VAL 0
0.OPERATING_VOLTAGE:
VALUES:
NVAL 2.8
ONVAL 2.8
OSVAL 2.8
OVAL 2.8
SVAL 2.8
VAL 2.8
0.OPERATING_VOLTAGE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL -79
ONVAL -85
OSVAL -85
OVAL -85
SVAL -79
VAL -79
0.RSSI_PEER:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
1.ACTIVE_PROFILE:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.ACTUAL_TEMPERATURE:
VALUES:
NVAL 20.3
ONVAL 20.3
OSVAL 20.3
OVAL 20.3
SVAL 20.3
VAL 20.3
1.ACTUAL_TEMPERATURE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.BOOST_MODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.BOOST_TIME:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.FROST_PROTECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.LEVEL:
VALUES:
NVAL 11
ONVAL 12
OSVAL 12
OVAL 0.12
SVAL 11
VAL 0.11
1.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
1.PARTY_MODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.PARTY_SET_POINT_TEMPERATURE:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0.000000
SVAL 0
VAL 0.000000
1.PARTY_TIME_END:
VALUES:
NVAL
ONVAL
OSVAL
OVAL
SVAL
VAL
1.PARTY_TIME_START:
VALUES:
NVAL
ONVAL
OSVAL
OVAL
SVAL
VAL
1.QUICK_VETO_TIME:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.SET_POINT_MODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL auto
OVAL 0
SVAL auto
VAL 0
1.SET_POINT_TEMPERATURE:
VALUES:
NVAL 20
ONVAL 20
OSVAL 20
OVAL 20.0
SVAL 20
VAL 20.0
1.SWITCH_POINT_OCCURED:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
1.VALVE_ADAPTION:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
1.VALVE_STATE:
VALUES:
NVAL 4
ONVAL 4
OSVAL ADAPTION_DONE
OVAL 4
SVAL ADAPTION_DONE
VAL 4
1.WINDOW_STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL closed
OVAL 0
SVAL closed
VAL 0
roleCmds:
get:
set:
auto:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:CONTROL_MODE:0
usage auto
subcmd:
000:
args 0
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
boost:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:BOOST_MODE:1
usage boost
subcmd:
000:
args 1
dpt BOOST_MODE
fnc
max 1
min 0
parname BOOST_MODE
partype 3
ps VALUES
scn 000
unit
desired-temp:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:SET_POINT_TEMPERATURE:?temperature
usage desired-temp temperature
subcmd:
000:
args
dpt SET_POINT_TEMPERATURE
fnc
max 30.5
min 4.5
parname temperature
partype 2
ps VALUES
scn 000
unit �C
holiday:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:CONTROL_MODE:2
usage holiday
subcmd:
000:
args 2
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
manu:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 1
syntax V:CONTROL_MODE:1
usage manu
subcmd:
000:
args 1
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
off:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 2
syntax V:CONTROL_MODE:1 V:SET_POINT_TEMPERATURE:4.5
usage off
subcmd:
000:
args 1
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
001:
args 4.5
dpt SET_POINT_TEMPERATURE
fnc
max 30.5
min 4.5
parname SET_POINT_TEMPERATURE
partype 3
ps VALUES
scn 001
unit �C
on:
channel 1
role HEATING_CLIMATECONTROL_TRANSCEIVER
subcount 2
syntax V:CONTROL_MODE:1 V:SET_POINT_TEMPERATURE:30.5
usage on
subcmd:
000:
args 1
dpt CONTROL_MODE
fnc
max 3
min 0
parname CONTROL_MODE
partype 3
ps VALUES
scn 000
unit
001:
args 30.5
dpt SET_POINT_TEMPERATURE
fnc
max 30.5
min 4.5
parname SET_POINT_TEMPERATURE
partype 3
ps VALUES
scn 001
unit �C
state:
chn 1
dpt ACTUAL_TEMPERATURE
Attributes:
IODev CCU3
alias Bad
ccuscaleval LEVEL:0:1:0:100
cmdIcon auto:sani_heating_automatic manu:sani_heating_manual boost:sani_heating_boost on:general_an off:general_aus
event-on-change-reading .*
group Regler
icon hc_wht_regler
room Heizung,Homematic
stateFormat Raumtemperatur: ACTUAL_TEMPERATURE °C<br/>Soll: SET_POINT_TEMPERATURE °C<br/>Fenster: <b>WINDOW_STATE</b>
substexcl desired-temp
userReadings controlMode {if(ReadingsVal($name,"BOOST_MODE","") eq "true") {return "boost"}
elsif
(ReadingsVal($name,"SET_POINT_MODE","") eq "auto") {return "auto"}
elsif
(ReadingsVal($name,"SET_POINT_MODE","") eq "manual") {return "manual"} else {return "error"}}
webCmd desired-temp:auto:manu:boost:on:off
widgetOverride desired-temp:slider,4.5,0.5,30.5,1
Gruß
eurofinder
Sieht für mich nach Verbindungsproblemen mit der CCU aus. Firewall-Einstellungen? Authentifizierung aus?
@zap:
Habe an der CCU3 keine Veränderungen vorgenommen und andere HM-IP-Geräte laufen ja einwandfrei.
Seltsam, ich werde mal weitersuchen und die Geräte ggf. nochmals neu anlernen.
Gruß, danke und schönes Wochenende
eurofinder
Wenn der Fehler sich immer nur auf Parameterset SERVICE bezieht: ignorieren. Das werde ich sowieso demnächst rauswerfen
Hallo Zap,
habe meine Installation jetzt auch auf 5.0 umgestellt. Folgendes Problem ist aufgetaucht.
Ich setze einen Wandthermostaten HmIP-BWTH ein. Bei der Abfrage:
get Wandthermostat config P1_ENDTIME_FRIDAY_1
kommt folgende Antwort:
Channel 1 [MASTER]
P1_ENDTIME_FRIDAY_1 = 240
P1_ENDTIME_FRIDAY_10 = 1440
P1_ENDTIME_FRIDAY_11 = 1440
P1_ENDTIME_FRIDAY_12 = 1440
P1_ENDTIME_FRIDAY_13 = 1440
Da sollte als Antwort aber nur P1_ENDTIME_FRIDAY_1 = 240 kommen.
Vermute da fehlt noch eine Stringvergleich.
Leider Funktioniert das setzen überhaupt nicht. Weder
set Wandthermostat config R-1.P1_ENDTIME_FRIDAY_1=100
noch
set Wandthermostat config R-1.P1_ENDTIME_FRIDAY_10=100
funktionieren. Es kommt die Fehlermeldung:
HMCCUDEV [Wandthermostat] HMCCUDEV: Wandthermostat Invalid parameter specified
Kannst Du da was machen?
Grüße gevoo
Hallo Zap,
hier als Nachtrag noch ein list:
[code]Internals:
DEF 000C98A9A989EC sd=9.STATE
FUUID 62223250-f33f-0281-2bcd-586da5339b3d761a
IODev HMCCU3
NAME Wandthermostat
NR 34
STATE off
TYPE HMCCUDEV
ccuaddr 000C98A9A989EC
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-BWTH 000C98A9A989EC
ccurolectrl HEATING_CLIMATECONTROL_TRANSCEIVER
ccurolestate SWITCH_TRANSMITTER
ccusubtype BWTH
ccutype HmIP-BWTH
firmware 1.2.4
readonly no
Helper:
DBLOG:
1.ACTUAL_TEMPERATURE:
DbLog:
TIME 1646587681.00725
VALUE 22.2
1.ACTUAL_TEMPERATURE_STATUS:
DbLog:
TIME 1646587681.00725
VALUE NORMAL
1.PARTY_SET_POINT_TEMPERATURE:
DbLog:
TIME 1646587681.00725
VALUE 0.0
1.SET_POINT_TEMPERATURE:
DbLog:
TIME 1646587681.00725
VALUE 23.0
9.STATE:
DbLog:
TIME 1646587874.46534
VALUE off
desired-temp:
DbLog:
TIME 1646587681.00725
VALUE 23.0
READINGS:
2022-03-06 18:28:00 1.ACTIVE_PROFILE 1
2022-03-06 18:28:00 1.ACTUAL_TEMPERATURE 22.2
2022-03-06 18:28:00 1.ACTUAL_TEMPERATURE_STATUS NORMAL
2022-03-06 18:22:08 1.BOOST_MODE false
2022-03-06 18:28:00 1.BOOST_TIME 0
2022-03-06 18:28:00 1.FROST_PROTECTION false
2022-03-06 18:28:00 1.HEATING_COOLING HEATING
2022-03-06 18:28:00 1.HUMIDITY 30
2022-03-06 18:28:00 1.HUMIDITY_STATUS NORMAL
2022-03-06 18:28:00 1.PARTY_MODE false
2022-03-06 18:28:00 1.PARTY_SET_POINT_TEMPERATURE 0.0
2022-03-06 18:28:00 1.PARTY_TIME_END
2022-03-06 18:28:00 1.PARTY_TIME_START
2022-03-06 18:28:00 1.QUICK_VETO_TIME 0
2022-03-06 18:28:00 1.SET_POINT_MODE manual
2022-03-06 18:28:00 1.SET_POINT_TEMPERATURE 23.0
2022-03-06 18:28:00 1.SWITCH_POINT_OCCURED false
2022-03-06 18:28:00 1.WINDOW_STATE closed
2022-03-04 18:35:23 10.STATE on
2022-03-04 18:35:23 11.STATE off
2022-03-04 18:35:23 12.STATE off
2022-03-04 18:35:23 8.EMERGENCY_OPERATION false
2022-03-04 18:35:23 8.FROST_PROTECTION false
2022-03-04 18:35:23 8.HUMIDITY_ALARM false
2022-03-04 18:35:23 8.STATE true
2022-03-06 18:31:14 9.STATE off
2022-03-06 18:27:27 IODev HMCCU3
2022-03-06 18:15:12 R-1.BOOST_AFTER_WINDOW_OPEN 0
2022-03-06 18:15:12 R-1.BOOST_TIME_PERIOD 5
2022-03-06 18:15:12 R-1.BUTTON_RESPONSE_WITHOUT_BACKLIGHT 0
2022-03-06 18:15:12 R-1.DURATION_5MIN 0
2022-03-06 18:15:12 R-1.MANU_MODE_PRIORITIZATION 1
2022-03-06 18:15:12 R-1.MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE 0
2022-03-06 18:15:12 R-1.OPTIMUM_START_STOP 0
2022-03-06 18:15:12 R-1.P1_ENDTIME_FRIDAY_1 240
2022-03-06 18:15:12 R-1.P1_ENDTIME_FRIDAY_10 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_FRIDAY_11 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_FRIDAY_12 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_FRIDAY_13 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_FRIDAY_2 750
2022-03-06 18:15:12 R-1.P1_ENDTIME_FRIDAY_3 0
2022-03-06 18:15:12 R-1.P1_ENDTIME_FRIDAY_4 0
2022-03-06 18:15:12 R-1.P1_ENDTIME_FRIDAY_5 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_FRIDAY_6 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_FRIDAY_7 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_FRIDAY_8 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_FRIDAY_9 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_MONDAY_1 180
2022-03-06 18:15:12 R-1.P1_ENDTIME_MONDAY_10 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_MONDAY_11 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_MONDAY_12 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_MONDAY_13 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_MONDAY_2 900
2022-03-06 18:15:12 R-1.P1_ENDTIME_MONDAY_3 0
2022-03-06 18:15:12 R-1.P1_ENDTIME_MONDAY_4 0
2022-03-06 18:15:12 R-1.P1_ENDTIME_MONDAY_5 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_MONDAY_6 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_MONDAY_7 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_MONDAY_8 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_MONDAY_9 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SATURDAY_1 360
2022-03-06 18:15:12 R-1.P1_ENDTIME_SATURDAY_10 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SATURDAY_11 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SATURDAY_12 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SATURDAY_13 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SATURDAY_2 780
2022-03-06 18:15:12 R-1.P1_ENDTIME_SATURDAY_3 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SATURDAY_4 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SATURDAY_5 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SATURDAY_6 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SATURDAY_7 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SATURDAY_8 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SATURDAY_9 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SUNDAY_1 0
2022-03-06 18:15:12 R-1.P1_ENDTIME_SUNDAY_10 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SUNDAY_11 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SUNDAY_12 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SUNDAY_13 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SUNDAY_2 0
2022-03-06 18:15:12 R-1.P1_ENDTIME_SUNDAY_3 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SUNDAY_4 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SUNDAY_5 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SUNDAY_6 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SUNDAY_7 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SUNDAY_8 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_SUNDAY_9 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_THURSDAY_1 240
2022-03-06 18:15:12 R-1.P1_ENDTIME_THURSDAY_10 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_THURSDAY_11 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_THURSDAY_12 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_THURSDAY_13 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_THURSDAY_2 1020
2022-03-06 18:15:12 R-1.P1_ENDTIME_THURSDAY_3 0
2022-03-06 18:15:12 R-1.P1_ENDTIME_THURSDAY_4 0
2022-03-06 18:15:12 R-1.P1_ENDTIME_THURSDAY_5 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_THURSDAY_6 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_THURSDAY_7 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_THURSDAY_8 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_THURSDAY_9 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_TUESDAY_1 240
2022-03-06 18:15:12 R-1.P1_ENDTIME_TUESDAY_10 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_TUESDAY_11 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_TUESDAY_12 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_TUESDAY_13 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_TUESDAY_2 1020
2022-03-06 18:15:12 R-1.P1_ENDTIME_TUESDAY_3 0
2022-03-06 18:15:12 R-1.P1_ENDTIME_TUESDAY_4 0
2022-03-06 18:15:12 R-1.P1_ENDTIME_TUESDAY_5 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_TUESDAY_6 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_TUESDAY_7 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_TUESDAY_8 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_TUESDAY_9 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_WEDNESDAY_1 240
2022-03-06 18:15:12 R-1.P1_ENDTIME_WEDNESDAY_10 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_WEDNESDAY_11 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_WEDNESDAY_12 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_WEDNESDAY_13 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_WEDNESDAY_2 780
2022-03-06 18:15:12 R-1.P1_ENDTIME_WEDNESDAY_3 0
2022-03-06 18:15:12 R-1.P1_ENDTIME_WEDNESDAY_4 0
2022-03-06 18:15:12 R-1.P1_ENDTIME_WEDNESDAY_5 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_WEDNESDAY_6 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_WEDNESDAY_7 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_WEDNESDAY_8 1440
2022-03-06 18:15:12 R-1.P1_ENDTIME_WEDNESDAY_9 1440
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_FRIDAY_1 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_FRIDAY_10 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_FRIDAY_11 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_FRIDAY_12 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_FRIDAY_13 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_FRIDAY_2 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_FRIDAY_3 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_FRIDAY_4 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_FRIDAY_5 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_FRIDAY_6 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_FRIDAY_7 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_FRIDAY_8 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_FRIDAY_9 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_MONDAY_1 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_MONDAY_10 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_MONDAY_11 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_MONDAY_12 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_MONDAY_13 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_MONDAY_2 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_MONDAY_3 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_MONDAY_4 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_MONDAY_5 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_MONDAY_6 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_MONDAY_7 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_MONDAY_8 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_MONDAY_9 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SATURDAY_1 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SATURDAY_10 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SATURDAY_11 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SATURDAY_12 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SATURDAY_13 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SATURDAY_2 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SATURDAY_3 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SATURDAY_4 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SATURDAY_5 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SATURDAY_6 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SATURDAY_7 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SATURDAY_8 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SATURDAY_9 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SUNDAY_1 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SUNDAY_10 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SUNDAY_11 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SUNDAY_12 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SUNDAY_13 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SUNDAY_2 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SUNDAY_3 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SUNDAY_4 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SUNDAY_5 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SUNDAY_6 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SUNDAY_7 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SUNDAY_8 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_SUNDAY_9 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_THURSDAY_1 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_THURSDAY_10 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_THURSDAY_11 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_THURSDAY_12 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_THURSDAY_13 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_THURSDAY_2 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_THURSDAY_3 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_THURSDAY_4 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_THURSDAY_5 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_THURSDAY_6 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_THURSDAY_7 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_THURSDAY_8 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_THURSDAY_9 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_TUESDAY_1 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_TUESDAY_10 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_TUESDAY_11 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_TUESDAY_12 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_TUESDAY_13 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_TUESDAY_2 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_TUESDAY_3 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_TUESDAY_4 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_TUESDAY_5 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_TUESDAY_6 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_TUESDAY_7 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_TUESDAY_8 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_TUESDAY_9 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_WEDNESDAY_1 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_WEDNESDAY_10 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_WEDNESDAY_11 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_WEDNESDAY_12 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_WEDNESDAY_13 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_WEDNESDAY_2 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_WEDNESDAY_3 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_WEDNESDAY_4 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_WEDNESDAY_5 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_WEDNESDAY_6 23.0
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_WEDNESDAY_7 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_WEDNESDAY_8 20.5
2022-03-06 18:15:12 R-1.P1_TEMPERATURE_WEDNESDAY_9 20.5
2022-03-06 18:15:12 R-1.P2_ENDTIME_FRIDAY_1 300
2022-03-06 18:15:12 R-1.P2_ENDTIME_FRIDAY_10 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_FRIDAY_11 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_FRIDAY_12 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_FRIDAY_13 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_FRIDAY_2 480
2022-03-06 18:15:12 R-1.P2_ENDTIME_FRIDAY_3 900
2022-03-06 18:15:12 R-1.P2_ENDTIME_FRIDAY_4 1320
2022-03-06 18:15:12 R-1.P2_ENDTIME_FRIDAY_5 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_FRIDAY_6 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_FRIDAY_7 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_FRIDAY_8 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_FRIDAY_9 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_MONDAY_1 300
2022-03-06 18:15:12 R-1.P2_ENDTIME_MONDAY_10 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_MONDAY_11 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_MONDAY_12 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_MONDAY_13 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_MONDAY_2 480
2022-03-06 18:15:12 R-1.P2_ENDTIME_MONDAY_3 900
2022-03-06 18:15:12 R-1.P2_ENDTIME_MONDAY_4 1320
2022-03-06 18:15:12 R-1.P2_ENDTIME_MONDAY_5 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_MONDAY_6 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_MONDAY_7 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_MONDAY_8 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_MONDAY_9 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SATURDAY_1 360
2022-03-06 18:15:12 R-1.P2_ENDTIME_SATURDAY_10 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SATURDAY_11 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SATURDAY_12 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SATURDAY_13 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SATURDAY_2 1380
2022-03-06 18:15:12 R-1.P2_ENDTIME_SATURDAY_3 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SATURDAY_4 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SATURDAY_5 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SATURDAY_6 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SATURDAY_7 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SATURDAY_8 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SATURDAY_9 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SUNDAY_1 360
2022-03-06 18:15:12 R-1.P2_ENDTIME_SUNDAY_10 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SUNDAY_11 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SUNDAY_12 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SUNDAY_13 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SUNDAY_2 1380
2022-03-06 18:15:12 R-1.P2_ENDTIME_SUNDAY_3 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SUNDAY_4 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SUNDAY_5 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SUNDAY_6 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SUNDAY_7 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SUNDAY_8 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_SUNDAY_9 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_THURSDAY_1 300
2022-03-06 18:15:12 R-1.P2_ENDTIME_THURSDAY_10 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_THURSDAY_11 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_THURSDAY_12 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_THURSDAY_13 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_THURSDAY_2 480
2022-03-06 18:15:12 R-1.P2_ENDTIME_THURSDAY_3 900
2022-03-06 18:15:12 R-1.P2_ENDTIME_THURSDAY_4 1320
2022-03-06 18:15:12 R-1.P2_ENDTIME_THURSDAY_5 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_THURSDAY_6 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_THURSDAY_7 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_THURSDAY_8 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_THURSDAY_9 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_TUESDAY_1 300
2022-03-06 18:15:12 R-1.P2_ENDTIME_TUESDAY_10 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_TUESDAY_11 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_TUESDAY_12 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_TUESDAY_13 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_TUESDAY_2 480
2022-03-06 18:15:12 R-1.P2_ENDTIME_TUESDAY_3 900
2022-03-06 18:15:12 R-1.P2_ENDTIME_TUESDAY_4 1320
2022-03-06 18:15:12 R-1.P2_ENDTIME_TUESDAY_5 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_TUESDAY_6 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_TUESDAY_7 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_TUESDAY_8 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_TUESDAY_9 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_WEDNESDAY_1 300
2022-03-06 18:15:12 R-1.P2_ENDTIME_WEDNESDAY_10 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_WEDNESDAY_11 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_WEDNESDAY_12 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_WEDNESDAY_13 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_WEDNESDAY_2 480
2022-03-06 18:15:12 R-1.P2_ENDTIME_WEDNESDAY_3 900
2022-03-06 18:15:12 R-1.P2_ENDTIME_WEDNESDAY_4 1320
2022-03-06 18:15:12 R-1.P2_ENDTIME_WEDNESDAY_5 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_WEDNESDAY_6 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_WEDNESDAY_7 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_WEDNESDAY_8 1440
2022-03-06 18:15:12 R-1.P2_ENDTIME_WEDNESDAY_9 1440
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_FRIDAY_1 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_FRIDAY_10 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_FRIDAY_11 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_FRIDAY_12 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_FRIDAY_13 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_FRIDAY_2 21.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_FRIDAY_3 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_FRIDAY_4 21.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_FRIDAY_5 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_FRIDAY_6 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_FRIDAY_7 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_FRIDAY_8 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_FRIDAY_9 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_MONDAY_1 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_MONDAY_10 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_MONDAY_11 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_MONDAY_12 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_MONDAY_13 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_MONDAY_2 21.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_MONDAY_3 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_MONDAY_4 21.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_MONDAY_5 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_MONDAY_6 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_MONDAY_7 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_MONDAY_8 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_MONDAY_9 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SATURDAY_1 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SATURDAY_10 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SATURDAY_11 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SATURDAY_12 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SATURDAY_13 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SATURDAY_2 21.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SATURDAY_3 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SATURDAY_4 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SATURDAY_5 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SATURDAY_6 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SATURDAY_7 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SATURDAY_8 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SATURDAY_9 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SUNDAY_1 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SUNDAY_10 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SUNDAY_11 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SUNDAY_12 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SUNDAY_13 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SUNDAY_2 21.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SUNDAY_3 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SUNDAY_4 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SUNDAY_5 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SUNDAY_6 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SUNDAY_7 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SUNDAY_8 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_SUNDAY_9 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_THURSDAY_1 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_THURSDAY_10 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_THURSDAY_11 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_THURSDAY_12 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_THURSDAY_13 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_THURSDAY_2 21.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_THURSDAY_3 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_THURSDAY_4 21.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_THURSDAY_5 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_THURSDAY_6 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_THURSDAY_7 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_THURSDAY_8 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_THURSDAY_9 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_TUESDAY_1 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_TUESDAY_10 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_TUESDAY_11 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_TUESDAY_12 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_TUESDAY_13 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_TUESDAY_2 21.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_TUESDAY_3 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_TUESDAY_4 21.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_TUESDAY_5 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_TUESDAY_6 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_TUESDAY_7 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_TUESDAY_8 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_TUESDAY_9 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_WEDNESDAY_1 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_WEDNESDAY_10 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_WEDNESDAY_11 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_WEDNESDAY_12 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_WEDNESDAY_13 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_WEDNESDAY_2 21.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_WEDNESDAY_3 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_WEDNESDAY_4 21.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_WEDNESDAY_5 19.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_WEDNESDAY_6 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_WEDNESDAY_7 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_WEDNESDAY_8 17.0
2022-03-06 18:15:12 R-1.P2_TEMPERATURE_WEDNESDAY_9 17.0
2022-03-06 18:15:12 R-1.P3_ENDTIME_FRIDAY_1 360
2022-03-06 18:15:12 R-1.P3_ENDTIME_FRIDAY_10 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_FRIDAY_11 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_FRIDAY_12 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_FRIDAY_13 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_FRIDAY_2 1320
2022-03-06 18:15:12 R-1.P3_ENDTIME_FRIDAY_3 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_FRIDAY_4 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_FRIDAY_5 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_FRIDAY_6 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_FRIDAY_7 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_FRIDAY_8 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_FRIDAY_9 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_MONDAY_1 360
2022-03-06 18:15:12 R-1.P3_ENDTIME_MONDAY_10 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_MONDAY_11 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_MONDAY_12 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_MONDAY_13 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_MONDAY_2 1320
2022-03-06 18:15:12 R-1.P3_ENDTIME_MONDAY_3 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_MONDAY_4 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_MONDAY_5 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_MONDAY_6 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_MONDAY_7 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_MONDAY_8 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_MONDAY_9 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SATURDAY_1 360
2022-03-06 18:15:12 R-1.P3_ENDTIME_SATURDAY_10 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SATURDAY_11 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SATURDAY_12 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SATURDAY_13 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SATURDAY_2 1320
2022-03-06 18:15:12 R-1.P3_ENDTIME_SATURDAY_3 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SATURDAY_4 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SATURDAY_5 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SATURDAY_6 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SATURDAY_7 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SATURDAY_8 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SATURDAY_9 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SUNDAY_1 360
2022-03-06 18:15:12 R-1.P3_ENDTIME_SUNDAY_10 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SUNDAY_11 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SUNDAY_12 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SUNDAY_13 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SUNDAY_2 1320
2022-03-06 18:15:12 R-1.P3_ENDTIME_SUNDAY_3 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SUNDAY_4 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SUNDAY_5 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SUNDAY_6 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SUNDAY_7 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SUNDAY_8 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_SUNDAY_9 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_THURSDAY_1 360
2022-03-06 18:15:12 R-1.P3_ENDTIME_THURSDAY_10 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_THURSDAY_11 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_THURSDAY_12 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_THURSDAY_13 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_THURSDAY_2 1320
2022-03-06 18:15:12 R-1.P3_ENDTIME_THURSDAY_3 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_THURSDAY_4 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_THURSDAY_5 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_THURSDAY_6 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_THURSDAY_7 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_THURSDAY_8 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_THURSDAY_9 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_TUESDAY_1 360
2022-03-06 18:15:12 R-1.P3_ENDTIME_TUESDAY_10 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_TUESDAY_11 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_TUESDAY_12 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_TUESDAY_13 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_TUESDAY_2 1320
2022-03-06 18:15:12 R-1.P3_ENDTIME_TUESDAY_3 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_TUESDAY_4 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_TUESDAY_5 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_TUESDAY_6 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_TUESDAY_7 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_TUESDAY_8 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_TUESDAY_9 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_WEDNESDAY_1 360
2022-03-06 18:15:12 R-1.P3_ENDTIME_WEDNESDAY_10 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_WEDNESDAY_11 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_WEDNESDAY_12 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_WEDNESDAY_13 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_WEDNESDAY_2 1320
2022-03-06 18:15:12 R-1.P3_ENDTIME_WEDNESDAY_3 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_WEDNESDAY_4 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_WEDNESDAY_5 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_WEDNESDAY_6 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_WEDNESDAY_7 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_WEDNESDAY_8 1440
2022-03-06 18:15:12 R-1.P3_ENDTIME_WEDNESDAY_9 1440
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_FRIDAY_1 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_FRIDAY_10 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_FRIDAY_11 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_FRIDAY_12 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_FRIDAY_13 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_FRIDAY_2 21.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_FRIDAY_3 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_FRIDAY_4 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_FRIDAY_5 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_FRIDAY_6 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_FRIDAY_7 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_FRIDAY_8 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_FRIDAY_9 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_MONDAY_1 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_MONDAY_10 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_MONDAY_11 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_MONDAY_12 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_MONDAY_13 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_MONDAY_2 21.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_MONDAY_3 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_MONDAY_4 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_MONDAY_5 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_MONDAY_6 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_MONDAY_7 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_MONDAY_8 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_MONDAY_9 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SATURDAY_1 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SATURDAY_10 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SATURDAY_11 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SATURDAY_12 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SATURDAY_13 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SATURDAY_2 21.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SATURDAY_3 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SATURDAY_4 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SATURDAY_5 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SATURDAY_6 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SATURDAY_7 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SATURDAY_8 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SATURDAY_9 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SUNDAY_1 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SUNDAY_10 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SUNDAY_11 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SUNDAY_12 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SUNDAY_13 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SUNDAY_2 21.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SUNDAY_3 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SUNDAY_4 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SUNDAY_5 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SUNDAY_6 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SUNDAY_7 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SUNDAY_8 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_SUNDAY_9 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_THURSDAY_1 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_THURSDAY_10 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_THURSDAY_11 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_THURSDAY_12 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_THURSDAY_13 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_THURSDAY_2 21.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_THURSDAY_3 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_THURSDAY_4 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_THURSDAY_5 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_THURSDAY_6 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_THURSDAY_7 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_THURSDAY_8 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_THURSDAY_9 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_TUESDAY_1 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_TUESDAY_10 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_TUESDAY_11 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_TUESDAY_12 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_TUESDAY_13 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_TUESDAY_2 21.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_TUESDAY_3 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_TUESDAY_4 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_TUESDAY_5 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_TUESDAY_6 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_TUESDAY_7 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_TUESDAY_8 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_TUESDAY_9 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_WEDNESDAY_1 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_WEDNESDAY_10 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_WEDNESDAY_11 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_WEDNESDAY_12 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_WEDNESDAY_13 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_WEDNESDAY_2 21.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_WEDNESDAY_3 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_WEDNESDAY_4 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_WEDNESDAY_5 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_WEDNESDAY_6 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_WEDNESDAY_7 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_WEDNESDAY_8 17.0
2022-03-06 18:15:12 R-1.P3_TEMPERATURE_WEDNESDAY_9 17.0
2022-03-06 18:15:12 R-1.P4_ENDTIME_FRIDAY_1 360
2022-03-06 18:15:12 R-1.P4_ENDTIME_FRIDAY_10 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_FRIDAY_11 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_FRIDAY_12 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_FRIDAY_13 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_FRIDAY_2 540
2022-03-06 18:15:12 R-1.P4_ENDTIME_FRIDAY_3 1020
2022-03-06 18:15:12 R-1.P4_ENDTIME_FRIDAY_4 1320
2022-03-06 18:15:12 R-1.P4_ENDTIME_FRIDAY_5 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_FRIDAY_6 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_FRIDAY_7 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_FRIDAY_8 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_FRIDAY_9 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_MONDAY_1 360
2022-03-06 18:15:12 R-1.P4_ENDTIME_MONDAY_10 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_MONDAY_11 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_MONDAY_12 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_MONDAY_13 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_MONDAY_2 540
2022-03-06 18:15:12 R-1.P4_ENDTIME_MONDAY_3 1020
2022-03-06 18:15:12 R-1.P4_ENDTIME_MONDAY_4 1320
2022-03-06 18:15:12 R-1.P4_ENDTIME_MONDAY_5 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_MONDAY_6 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_MONDAY_7 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_MONDAY_8 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_MONDAY_9 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SATURDAY_1 360
2022-03-06 18:15:12 R-1.P4_ENDTIME_SATURDAY_10 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SATURDAY_11 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SATURDAY_12 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SATURDAY_13 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SATURDAY_2 1320
2022-03-06 18:15:12 R-1.P4_ENDTIME_SATURDAY_3 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SATURDAY_4 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SATURDAY_5 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SATURDAY_6 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SATURDAY_7 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SATURDAY_8 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SATURDAY_9 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SUNDAY_1 360
2022-03-06 18:15:12 R-1.P4_ENDTIME_SUNDAY_10 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SUNDAY_11 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SUNDAY_12 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SUNDAY_13 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SUNDAY_2 1320
2022-03-06 18:15:12 R-1.P4_ENDTIME_SUNDAY_3 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SUNDAY_4 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SUNDAY_5 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SUNDAY_6 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SUNDAY_7 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SUNDAY_8 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_SUNDAY_9 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_THURSDAY_1 360
2022-03-06 18:15:12 R-1.P4_ENDTIME_THURSDAY_10 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_THURSDAY_11 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_THURSDAY_12 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_THURSDAY_13 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_THURSDAY_2 540
2022-03-06 18:15:12 R-1.P4_ENDTIME_THURSDAY_3 1020
2022-03-06 18:15:12 R-1.P4_ENDTIME_THURSDAY_4 1320
2022-03-06 18:15:12 R-1.P4_ENDTIME_THURSDAY_5 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_THURSDAY_6 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_THURSDAY_7 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_THURSDAY_8 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_THURSDAY_9 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_TUESDAY_1 360
2022-03-06 18:15:12 R-1.P4_ENDTIME_TUESDAY_10 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_TUESDAY_11 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_TUESDAY_12 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_TUESDAY_13 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_TUESDAY_2 540
2022-03-06 18:15:12 R-1.P4_ENDTIME_TUESDAY_3 1020
2022-03-06 18:15:12 R-1.P4_ENDTIME_TUESDAY_4 1320
2022-03-06 18:15:12 R-1.P4_ENDTIME_TUESDAY_5 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_TUESDAY_6 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_TUESDAY_7 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_TUESDAY_8 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_TUESDAY_9 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_WEDNESDAY_1 360
2022-03-06 18:15:12 R-1.P4_ENDTIME_WEDNESDAY_10 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_WEDNESDAY_11 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_WEDNESDAY_12 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_WEDNESDAY_13 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_WEDNESDAY_2 540
2022-03-06 18:15:12 R-1.P4_ENDTIME_WEDNESDAY_3 1020
2022-03-06 18:15:12 R-1.P4_ENDTIME_WEDNESDAY_4 1320
2022-03-06 18:15:12 R-1.P4_ENDTIME_WEDNESDAY_5 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_WEDNESDAY_6 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_WEDNESDAY_7 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_WEDNESDAY_8 1440
2022-03-06 18:15:12 R-1.P4_ENDTIME_WEDNESDAY_9 1440
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_FRIDAY_1 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_FRIDAY_10 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_FRIDAY_11 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_FRIDAY_12 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_FRIDAY_13 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_FRIDAY_2 21.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_FRIDAY_3 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_FRIDAY_4 21.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_FRIDAY_5 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_FRIDAY_6 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_FRIDAY_7 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_FRIDAY_8 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_FRIDAY_9 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_MONDAY_1 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_MONDAY_10 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_MONDAY_11 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_MONDAY_12 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_MONDAY_13 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_MONDAY_2 21.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_MONDAY_3 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_MONDAY_4 21.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_MONDAY_5 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_MONDAY_6 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_MONDAY_7 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_MONDAY_8 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_MONDAY_9 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SATURDAY_1 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SATURDAY_10 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SATURDAY_11 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SATURDAY_12 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SATURDAY_13 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SATURDAY_2 21.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SATURDAY_3 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SATURDAY_4 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SATURDAY_5 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SATURDAY_6 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SATURDAY_7 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SATURDAY_8 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SATURDAY_9 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SUNDAY_1 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SUNDAY_10 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SUNDAY_11 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SUNDAY_12 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SUNDAY_13 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SUNDAY_2 21.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SUNDAY_3 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SUNDAY_4 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SUNDAY_5 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SUNDAY_6 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SUNDAY_7 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SUNDAY_8 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_SUNDAY_9 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_THURSDAY_1 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_THURSDAY_10 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_THURSDAY_11 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_THURSDAY_12 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_THURSDAY_13 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_THURSDAY_2 21.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_THURSDAY_3 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_THURSDAY_4 21.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_THURSDAY_5 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_THURSDAY_6 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_THURSDAY_7 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_THURSDAY_8 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_THURSDAY_9 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_TUESDAY_1 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_TUESDAY_10 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_TUESDAY_11 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_TUESDAY_12 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_TUESDAY_13 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_TUESDAY_2 21.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_TUESDAY_3 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_TUESDAY_4 21.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_TUESDAY_5 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_TUESDAY_6 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_TUESDAY_7 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_TUESDAY_8 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_TUESDAY_9 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_WEDNESDAY_1 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_WEDNESDAY_10 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_WEDNESDAY_11 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_WEDNESDAY_12 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_WEDNESDAY_13 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_WEDNESDAY_2 21.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_WEDNESDAY_3 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_WEDNESDAY_4 21.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_WEDNESDAY_5 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_WEDNESDAY_6 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_WEDNESDAY_7 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_WEDNESDAY_8 17.0
2022-03-06 18:15:12 R-1.P4_TEMPERATURE_WEDNESDAY_9 17.0
2022-03-06 18:15:12 R-1.P5_ENDTIME_FRIDAY_1 300
2022-03-06 18:15:12 R-1.P5_ENDTIME_FRIDAY_10 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_FRIDAY_11 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_FRIDAY_12 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_FRIDAY_13 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_FRIDAY_2 480
2022-03-06 18:15:12 R-1.P5_ENDTIME_FRIDAY_3 900
2022-03-06 18:15:12 R-1.P5_ENDTIME_FRIDAY_4 1320
2022-03-06 18:15:12 R-1.P5_ENDTIME_FRIDAY_5 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_FRIDAY_6 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_FRIDAY_7 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_FRIDAY_8 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_FRIDAY_9 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_MONDAY_1 300
2022-03-06 18:15:12 R-1.P5_ENDTIME_MONDAY_10 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_MONDAY_11 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_MONDAY_12 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_MONDAY_13 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_MONDAY_2 480
2022-03-06 18:15:12 R-1.P5_ENDTIME_MONDAY_3 900
2022-03-06 18:15:12 R-1.P5_ENDTIME_MONDAY_4 1320
2022-03-06 18:15:12 R-1.P5_ENDTIME_MONDAY_5 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_MONDAY_6 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_MONDAY_7 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_MONDAY_8 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_MONDAY_9 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_SATURDAY_1 360
2022-03-06 18:15:12 R-1.P5_ENDTIME_SATURDAY_10 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_SATURDAY_11 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_SATURDAY_12 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_SATURDAY_13 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_SATURDAY_2 1380
2022-03-06 18:15:12 R-1.P5_ENDTIME_SATURDAY_3 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_SATURDAY_4 1440
2022-03-06 18:15:12 R-1.P5_ENDTIME_SATURDAY_5 1440
20
Das Argument zu "get ... config" ist wohl ein Regex. Mit
get Wandthermostat config P1_ENDTIME_FRIDAY_1$
solltest Du bekommen, was Du suchst.
Hallo,
ich habe eine Frage zum Heizungsthermostat HM-CC-RT-DN.
Ich habe den Thermaostat per get Create automatisch als HMCCUCHN erstelen lassen.
Nun möchte ich die Tastensperre einschalten.
Device KEQ0775567
Channel d [MASTER]
ADAPTIVE_REGULATION = 2
BACKLIGHT_ON_TIME = 00:00:10
BOOST_AFTER_WINDOW_OPEN = 0
BOOST_POSITION = 80
BOOST_TIME_PERIOD = 2
BURST_RX = 1
BUTTON_LOCK = 0
BUTTON_RESPONSE_WITHOUT_BACKLIGHT = 0
CYCLIC_INFO_MSG = 1
CYCLIC_INFO_MSG_DIS = 0
DAYLIGHT_SAVING_TIME = 1
DECALCIFICATION_TIME = 10:00
DECALCIFICATION_WEEKDAY = 0
DISPLAY_INFORMATION = 0
ENDTIME_FRIDAY_1 = 08:00
ENDTIME_FRIDAY_10 = 24:00
ENDTIME_FRIDAY_11 = 24:00
ENDTIME_FRIDAY_12 = 24:00
ENDTIME_FRIDAY_13 = 24:00
ENDTIME_FRIDAY_2 = 15:00
ENDTIME_FRIDAY_3 = 20:00
ENDTIME_FRIDAY_4 = 24:00
ENDTIME_FRIDAY_5 = 24:00
ENDTIME_FRIDAY_6 = 24:00
ENDTIME_FRIDAY_7 = 24:00
ENDTIME_FRIDAY_8 = 24:00
ENDTIME_FRIDAY_9 = 24:00
ENDTIME_MONDAY_1 = 08:00
ENDTIME_MONDAY_10 = 24:00
ENDTIME_MONDAY_11 = 24:00
ENDTIME_MONDAY_12 = 24:00
ENDTIME_MONDAY_13 = 24:00
ENDTIME_MONDAY_2 = 15:00
ENDTIME_MONDAY_3 = 20:00
ENDTIME_MONDAY_4 = 24:00
ENDTIME_MONDAY_5 = 24:00
ENDTIME_MONDAY_6 = 24:00
ENDTIME_MONDAY_7 = 24:00
ENDTIME_MONDAY_8 = 24:00
ENDTIME_MONDAY_9 = 24:00
ENDTIME_SATURDAY_1 = 24:00
ENDTIME_SATURDAY_10 = 24:00
ENDTIME_SATURDAY_11 = 24:00
ENDTIME_SATURDAY_12 = 24:00
ENDTIME_SATURDAY_13 = 24:00
ENDTIME_SATURDAY_2 = 23:55
ENDTIME_SATURDAY_3 = 24:00
ENDTIME_SATURDAY_4 = 24:00
ENDTIME_SATURDAY_5 = 24:00
ENDTIME_SATURDAY_6 = 24:00
ENDTIME_SATURDAY_7 = 24:00
ENDTIME_SATURDAY_8 = 24:00
ENDTIME_SATURDAY_9 = 24:00
ENDTIME_SUNDAY_1 = 24:00
ENDTIME_SUNDAY_10 = 24:00
ENDTIME_SUNDAY_11 = 24:00
ENDTIME_SUNDAY_12 = 24:00
ENDTIME_SUNDAY_13 = 24:00
ENDTIME_SUNDAY_2 = 23:55
ENDTIME_SUNDAY_3 = 24:00
ENDTIME_SUNDAY_4 = 24:00
ENDTIME_SUNDAY_5 = 24:00
ENDTIME_SUNDAY_6 = 24:00
ENDTIME_SUNDAY_7 = 24:00
ENDTIME_SUNDAY_8 = 24:00
ENDTIME_SUNDAY_9 = 24:00
ENDTIME_THURSDAY_1 = 08:00
ENDTIME_THURSDAY_10 = 24:00
ENDTIME_THURSDAY_11 = 24:00
ENDTIME_THURSDAY_12 = 24:00
ENDTIME_THURSDAY_13 = 24:00
ENDTIME_THURSDAY_2 = 15:00
ENDTIME_THURSDAY_3 = 20:00
ENDTIME_THURSDAY_4 = 24:00
ENDTIME_THURSDAY_5 = 24:00
ENDTIME_THURSDAY_6 = 24:00
ENDTIME_THURSDAY_7 = 24:00
ENDTIME_THURSDAY_8 = 24:00
ENDTIME_THURSDAY_9 = 24:00
ENDTIME_TUESDAY_1 = 08:00
ENDTIME_TUESDAY_10 = 24:00
ENDTIME_TUESDAY_11 = 24:00
ENDTIME_TUESDAY_12 = 24:00
ENDTIME_TUESDAY_13 = 24:00
ENDTIME_TUESDAY_2 = 15:00
ENDTIME_TUESDAY_3 = 20:00
ENDTIME_TUESDAY_4 = 24:00
ENDTIME_TUESDAY_5 = 24:00
ENDTIME_TUESDAY_6 = 24:00
ENDTIME_TUESDAY_7 = 24:00
ENDTIME_TUESDAY_8 = 24:00
ENDTIME_TUESDAY_9 = 24:00
ENDTIME_WEDNESDAY_1 = 08:00
ENDTIME_WEDNESDAY_10 = 24:00
ENDTIME_WEDNESDAY_11 = 24:00
ENDTIME_WEDNESDAY_12 = 24:00
ENDTIME_WEDNESDAY_13 = 24:00
ENDTIME_WEDNESDAY_2 = 15:00
ENDTIME_WEDNESDAY_3 = 20:00
ENDTIME_WEDNESDAY_4 = 24:00
ENDTIME_WEDNESDAY_5 = 24:00
ENDTIME_WEDNESDAY_6 = 24:00
ENDTIME_WEDNESDAY_7 = 24:00
ENDTIME_WEDNESDAY_8 = 24:00
ENDTIME_WEDNESDAY_9 = 24:00
GLOBAL_BUTTON_LOCK = 0
I_VALUE_EXTERN = 15
I_VALUE_INTERN = 18
LOCAL_RESET_DISABLE = 0
LOW_BAT_LIMIT = 2.1
MANU_MODE_PRIORITIZATION = 1
MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE = 0
MODUS_BUTTON_LOCK = 0
PARTY_MODE_PRIORITIZATION = 1
P_START_VALUE_EXTERN = 30
P_START_VALUE_INTERN = 45
P_VALUE_EXTERN = 30
P_VALUE_INTERN = 33
SHOW_WEEKDAY = 0
TEMPERATUREFALL_MODUS = 0
TEMPERATUREFALL_VALUE = 1.4
TEMPERATUREFALL_WINDOW_OPEN = 5.0
TEMPERATUREFALL_WINDOW_OPEN_TIME_PERIOD = 00:30
TEMPERATURE_COMFORT = 21.0
TEMPERATURE_FRIDAY_1 = 18.0
TEMPERATURE_FRIDAY_10 = 17.0
TEMPERATURE_FRIDAY_11 = 17.0
TEMPERATURE_FRIDAY_12 = 17.0
TEMPERATURE_FRIDAY_13 = 17.0
TEMPERATURE_FRIDAY_2 = 20.0
TEMPERATURE_FRIDAY_3 = 18.0
TEMPERATURE_FRIDAY_4 = 20.0
TEMPERATURE_FRIDAY_5 = 17.0
TEMPERATURE_FRIDAY_6 = 17.0
TEMPERATURE_FRIDAY_7 = 17.0
TEMPERATURE_FRIDAY_8 = 17.0
TEMPERATURE_FRIDAY_9 = 17.0
TEMPERATURE_LOWERING = 17.0
TEMPERATURE_MAXIMUM = 30.5
TEMPERATURE_MINIMUM = 4.5
TEMPERATURE_MONDAY_1 = 18.0
TEMPERATURE_MONDAY_10 = 17.0
TEMPERATURE_MONDAY_11 = 17.0
TEMPERATURE_MONDAY_12 = 17.0
TEMPERATURE_MONDAY_13 = 17.0
TEMPERATURE_MONDAY_2 = 20.0
TEMPERATURE_MONDAY_3 = 18.0
TEMPERATURE_MONDAY_4 = 20.0
TEMPERATURE_MONDAY_5 = 17.0
TEMPERATURE_MONDAY_6 = 17.0
TEMPERATURE_MONDAY_7 = 17.0
TEMPERATURE_MONDAY_8 = 17.0
TEMPERATURE_MONDAY_9 = 17.0
TEMPERATURE_OFFSET = 7
TEMPERATURE_SATURDAY_1 = 18.0
TEMPERATURE_SATURDAY_10 = 17.0
TEMPERATURE_SATURDAY_11 = 17.0
TEMPERATURE_SATURDAY_12 = 17.0
TEMPERATURE_SATURDAY_13 = 17.0
TEMPERATURE_SATURDAY_2 = 20.0
TEMPERATURE_SATURDAY_3 = 18.0
TEMPERATURE_SATURDAY_4 = 17.0
TEMPERATURE_SATURDAY_5 = 17.0
TEMPERATURE_SATURDAY_6 = 17.0
TEMPERATURE_SATURDAY_7 = 17.0
TEMPERATURE_SATURDAY_8 = 17.0
TEMPERATURE_SATURDAY_9 = 17.0
TEMPERATURE_SUNDAY_1 = 18.0
TEMPERATURE_SUNDAY_10 = 17.0
TEMPERATURE_SUNDAY_11 = 17.0
TEMPERATURE_SUNDAY_12 = 17.0
TEMPERATURE_SUNDAY_13 = 17.0
TEMPERATURE_SUNDAY_2 = 20.0
TEMPERATURE_SUNDAY_3 = 18.0
TEMPERATURE_SUNDAY_4 = 17.0
TEMPERATURE_SUNDAY_5 = 17.0
TEMPERATURE_SUNDAY_6 = 17.0
TEMPERATURE_SUNDAY_7 = 17.0
TEMPERATURE_SUNDAY_8 = 17.0
TEMPERATURE_SUNDAY_9 = 17.0
TEMPERATURE_THURSDAY_1 = 18.0
TEMPERATURE_THURSDAY_10 = 17.0
TEMPERATURE_THURSDAY_11 = 17.0
TEMPERATURE_THURSDAY_12 = 17.0
TEMPERATURE_THURSDAY_13 = 17.0
TEMPERATURE_THURSDAY_2 = 20.0
TEMPERATURE_THURSDAY_3 = 18.0
TEMPERATURE_THURSDAY_4 = 20.0
TEMPERATURE_THURSDAY_5 = 17.0
TEMPERATURE_THURSDAY_6 = 17.0
TEMPERATURE_THURSDAY_7 = 17.0
TEMPERATURE_THURSDAY_8 = 17.0
TEMPERATURE_THURSDAY_9 = 17.0
TEMPERATURE_TUESDAY_1 = 18.0
TEMPERATURE_TUESDAY_10 = 17.0
TEMPERATURE_TUESDAY_11 = 17.0
TEMPERATURE_TUESDAY_12 = 17.0
TEMPERATURE_TUESDAY_13 = 17.0
TEMPERATURE_TUESDAY_2 = 20.0
TEMPERATURE_TUESDAY_3 = 18.0
TEMPERATURE_TUESDAY_4 = 20.0
TEMPERATURE_TUESDAY_5 = 17.0
TEMPERATURE_TUESDAY_6 = 17.0
TEMPERATURE_TUESDAY_7 = 17.0
TEMPERATURE_TUESDAY_8 = 17.0
TEMPERATURE_TUESDAY_9 = 17.0
TEMPERATURE_WEDNESDAY_1 = 18.0
TEMPERATURE_WEDNESDAY_10 = 17.0
TEMPERATURE_WEDNESDAY_11 = 17.0
TEMPERATURE_WEDNESDAY_12 = 17.0
TEMPERATURE_WEDNESDAY_13 = 17.0
TEMPERATURE_WEDNESDAY_2 = 20.0
TEMPERATURE_WEDNESDAY_3 = 18.0
TEMPERATURE_WEDNESDAY_4 = 20.0
TEMPERATURE_WEDNESDAY_5 = 17.0
TEMPERATURE_WEDNESDAY_6 = 17.0
TEMPERATURE_WEDNESDAY_7 = 17.0
TEMPERATURE_WEDNESDAY_8 = 17.0
TEMPERATURE_WEDNESDAY_9 = 17.0
VALVE_ERROR_RUN_POSITION = 15
VALVE_MAXIMUM_POSITION = 100
VALVE_OFFSET = 0
set Buero_Heizungsthermostat config GLOBAL_BUTTON_LOCK=1
Gibt mir die Fehlermeldung:
HMCCUCHN: Buero_Heizungsthermostat Paramset MASTER not supported by device or channel
und
setreading Buero_Heizungsthermostat R-BUTTON_LOCK 1;
Setzt zwar den Wert, überträgt ihn scheinbar aber nicht an das Gerät.
Kann mir hier evtl. jemand den richtigen Weg zeigen ?
Ich weiß nicht, was Du mit "setreading" erreichen willst. Das macht genau das, was der Name erwarten lässt: es ändert das Reading in FHEM. Da passiert gar nichts in Richtung CCU oder Homematic Device.
Meine FHEM Installation ist gerade "down". Aber wenn GLOBAL_BUTTON_LOCK ein Device parameter ist (kein Kanalparameter), müsste das funktionieren:
set Buero_Heizungsthermostat config device GLOBAL_BUTTON_LOCK=1
Siehe auch HMCCUCHN commandref.
Super. Vielen Dank für den Hinweis !
Das hat funktioniert.
Mir war nicht bewusst, wie ich Device Parameter anpasse... mit dem Hinweis habe ich nun auch die richtige Stelle in der Commandref gefunden.
Vielen Dank !
Hallo zusammen,
ich benutze jetzt schonm eine Weile die 5.0 und das ohne Auffälligkeiten. So weit so gut.
Bei den jetzigen Temperaturen wollte ich meinen Wintergarten wieder in Nutzung bringen. Dieser hat mehrere HmIP-FROLL
Aktoren. Diese steuere/steuerte ich mit einem Shelly-Button. Dazu habe ich eine Structur im fhem welche alle ROLL/FROLL-Aktoren
enthält. Der Shelly-Button steuert dann über einen http-Aufruf diese Structur an und gibt ein toggle mit.
Damit kann ich alle Jalousien gleichzeitig öffnen und schliessen. Zumindest im letzten Jahr.
Jetzt bekomme ich immer eine Fehlermeldung der Device
HMCCUDEV: HmIP_FROLL_winter_tuer_zu_3 Current device state doesn't match any state value
Hier das zugehörige Device. Dies habe ich jetzt extra neu mit get hmccu createDev angelegt.
defmod HmIP_FROLL_winter_tuer_zu_3 HMCCUDEV 001158A98B28ED sd=3.LEVEL cd=4.LEVEL
attr HmIP_FROLL_winter_tuer_zu_3 DbLogExclude .*
attr HmIP_FROLL_winter_tuer_zu_3 ccureadingfilter 1,2,3,4..*
attr HmIP_FROLL_winter_tuer_zu_3 cmdIcon open:fts_shutter_up stop:fts_shutter_manual close:fts_shutter_down
attr HmIP_FROLL_winter_tuer_zu_3 room Homematic
attr HmIP_FROLL_winter_tuer_zu_3 substexcl pct
attr HmIP_FROLL_winter_tuer_zu_3 webCmd pct:open:close:stop
attr HmIP_FROLL_winter_tuer_zu_3 widgetOverride pct:slider,0,10,100
Jetzt meine Frage: Was mache ich falsch? Gibt es den toggle in Jalousien nicht mehr, als set toggle noch im device vorhanden?
Viele Grüße
Heiko
Hallo zusammen,
ich würde gerne meine neue Homematic-Zentrale (Raspbi3 mit Raspberrymatic) an FHEM anbinden. Bin nach der Anleitung im Wiki https://wiki.fhem.de/wiki/HMCCU (https://wiki.fhem.de/wiki/HMCCU) vorgegangen. Nun hänge ich jedoch beim Punkt "set d_ccu on"
Fehlermeldung:
HMCCU: d_ccu Start of RPC server failed
Im nächsten Schritt wird der RPC-Server konfiguriert und gestartet. Zunächst werden mit dem Attribut rpcinterfaces die Schnittstellen bzw. Ports festgelegt, für die sich der RPC-Server bei der CCU registrieren soll. Das Attribut zeigt in einer Auswahlliste die möglichen Schnittstellen an. Nur für die hier ausgewählten Schnittstellen werden automatisch Readings aktualisiert.
Welchen Port soll ich hier den festlegen? Ich bekomme hier keine Auswahlliste?
Vielleicht hilft noch ein List vom aktuellem Device:
Internals:
CCUNum 1
CFGFN
Clients :HMCCUDEV:HMCCUCHN:HMCCURPCPROC:
DEF 192.168.178.27
FUUID 62436bbc-f33f-487e-3be3-8aefaf2dc6b940a0
NAME d_ccu
NOTIFYDEV global
NR 13038
NTFY_ORDER 50-d_ccu
RPCState inactive
STATE inactive/Error
TYPE HMCCU
ccuip 192.168.178.27
ccustate active
ccutype CCU2/3
config 5.0
host 192.168.178.27
prot http
version 5.0 220431743
READINGS:
2022-03-29 22:27:40 rpcstate inactive
2022-03-29 22:44:53 state Error
hmccu:
defaults 0
evtime 0
evtimeout 0
postInit 0
rpccount 0
rpcports
updatetime 1648586487.97233
adr:
ccu:
delay 180
delayed 0
sync 1
timeout 1
dev:
grp:
ifports:
interfaces:
prg:
Attributes:
room Homematic
rpcinterfaces 2001
stateFormat rpcstate/state
Wenn Du in diesem Zustand die Config speicherst und FHEM neu startest, gibt es dann Fehlermeldungen im Log?
Hab ihr mal das Log vom FHEM Start:
2022.03.30 20:36:32.857 2: alexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
2022.03.30 20:36:32.861 3: alexa: starting
2022.03.30 20:36:32.865 3: alexa: using logfile: ./log/alexa-2022-03-30.log
2022.03.30 20:36:32.865 0: HMCCU [d_ccu] Scheduling post FHEM initialization tasks in 12 seconds
2022.03.30 20:36:32.870 3: deCONZ: websocket opened to 192.168.178.10:8443
2022.03.30 20:36:32.874 2: deCONZ: autocreate: created 0/0/0 devices (ignored 0/0/0)
2022.03.30 20:36:37.759 1: usb create starting
2022.03.30 20:36:37.850 1: usb create end
2022.03.30 20:36:37.894 0: Featurelevel: 6.1
2022.03.30 20:36:37.894 0: Server started with 78 defined entities (fhem.pl:25852/2022-03-17 perl:5.032001 os:linux user:fhem pid:23849)
2022.03.30 20:36:38.403 1: CUL_HM start inital cleanup
2022.03.30 20:36:38.408 3: No I/O device found for Markise
2022.03.30 20:36:38.411 1: CUL_HM finished initial cleanup
2022.03.30 20:36:38.417 3: deCONZ: websocket: Switching Protocols ok
2022.03.30 20:36:38.685 2: AttrTemplates: got 247 entries
2022.03.30 20:36:44.870 1: HMCCU [d_ccu] Reading device config from CCU. This may take a couple of seconds ...
2022.03.30 20:36:44.871 2: HMCCU [d_ccu] Reading Device Descriptions for interface 2001
2022.03.30 20:36:44.925 2: HMCCU [d_ccu] Read 64 Device Descriptions for interface 2001
2022.03.30 20:36:44.925 2: HMCCU [d_ccu] Reading Paramset Descriptions for interface 2001
2022.03.30 20:36:45.223 2: HMCCU [d_ccu] Read 174 Paramset Descriptions for interface 2001
2022.03.30 20:36:45.237 2: HMCCU [d_ccu] Reading Peer Descriptions for interface 2001
2022.03.30 20:36:45.246 2: HMCCU [d_ccu] Read 8 Peer Descriptions for interface 2001
2022.03.30 20:36:45.250 2: HMCCU [d_ccu] Read device configuration in 1 seconds: devices/channels=64 parametersets=174 links=8
mm, beim Start werden alle Interfaces eingelesen.
Auch nach dem Restart siehst Du keine Auswahlliste beim Attribut rpcInterfaces?
Habe gestern spät abend nochmals alles neu aufgesetzt. Nun bekomme ich eine Auswahlliste.
HmIP-RF
VirtualDevices
BidCos-RF
Welche wähle ich hier am besten? Habe aktuell nur Homematic Komponenten. Später will ich aber Homematic IP noch hinzufügen
BidCos-RF auf jeden Fall.
Ggf. noch VirtualDevices, sofern Du auf der CCU Gruppen nutzen möchtest (z.B. für Heizkörper/Wandthermostate/Fenstersensoren).
Nun kann ich erfolgreich HmIP_RF starten. Sobald ich aber BidCos_RF versuche mit zu starten oder auch allein hängt sich mein ganzens FHEM auf und ich muss mein FHEM-Container neu starten...
Im Log nach dem "aufhängen" finde ich folgendes:
2022.03.31 14:27:09.183 2: HMCCURPCPROC [d_rpc178027BidCos_RF] CCU interface BidCos-RF supports RPC multicalls
2022.03.31 14:27:09.183 1: HMCCURPCPROC [d_rpc178027BidCos_RF] Initialized version 5.0 220431743 for interface BidCos-RF with I/O device d_ccu
2022.03.31 14:29:08.624 2: HMCCURPCPROC [d_rpc178027HmIP_RF] RPC server process started for interface HmIP-RF with PID=16231
2022.03.31 14:29:08.627 2: HMCCURPCPROC [d_rpc178027HmIP_RF] Initializing RPC server CB2010000004178027 for interface HmIP-RF
2022.03.31 14:29:08.629 1: HMCCURPCPROC [d_rpc178027HmIP_RF] RPC server starting
2022.03.31 14:29:08.636 2: HMCCURPCPROC [d_rpc178027BidCos_RF] RPC server process started for interface BidCos-RF with PID=16232
2022.03.31 14:29:08.640 1: HMCCURPCPROC [d_rpc178027BidCos_RF] RPC server starting
2022.03.31 14:29:08.646 2: HMCCURPCPROC [d_rpc178027BidCos_RF] Initializing RPC server CB2001000004178027 for interface BidCos-RF
2022.03.31 14:29:08.652 2: HMCCURPCPROC [d_rpc178027HmIP_RF] Callback server CB2010000004178027 created. Listening on port 7420
2022.03.31 14:29:08.655 2: HMCCURPCPROC [d_rpc178027HmIP_RF] RPC server CB2010000004178027 enters server loop
2022.03.31 14:29:08.656 2: HMCCURPCPROC [d_rpc178027HmIP_RF] Registering callback http://192.168.178.27:2010
2022.03.31 14:29:08.661 2: HMCCURPCPROC [d_rpc178027HmIP_RF] CB2010000004178027 accepting connections. PID=16231
2022.03.31 14:29:08.667 2: HMCCURPCPROC [d_rpc178027BidCos_RF] Callback server CB2001000004178027 created. Listening on port 7411
2022.03.31 14:29:08.667 2: HMCCURPCPROC [d_rpc178027BidCos_RF] CB2001000004178027 accepting connections. PID=16232
2022.03.31 14:29:08.682 1: HMCCURPCPROC [d_rpc178027HmIP_RF] RPC server CB2010000004178027 running
2022.03.31 14:29:08.688 2: HMCCURPCPROC [d_rpc178027BidCos_RF] RPC server CB2001000004178027 enters server loop
2022.03.31 14:29:08.689 2: HMCCURPCPROC [d_rpc178027BidCos_RF] Registering callback http://192.168.178.27:2001
Die RPC Server melden niemals gestartet. Da passt wohl etwas mit der IP Config mit Deinem Container nicht.
Dieses Problem mit Containern und IP-Adressen wurde hier schon einige Male diskutiert. Ich selbst bin da keine Hilfe. Bei mir sind CCU und FHEM getrennt.
Ggf. musst Du das Attribut rpcserveraddr verwenden, damit die CCU das richtige Interface auf der FHEM-Seite anspricht.
@Zap: Ist es evtl möglich, dass du am HM_CCU IO-Device noch ein Reading einführst "VERSION_ONLINE" oder so ähnlich, was im Hintergrund die URL:
https://ccu3-update.homematic.com/firmware/download?cmd=js_check_version&serial=0&product=HM-CCU3 abfrägt und dann die gemeldete Online-Version dort anzeigt. Geht natürlich auch, wenn man dort als product=HM-CCU2 angibt.
Da wir ja hier im Prinzip alles über FHEM machen, schaut man natürlicherweise so gut wie nie auf die CCU. Aber wenn es dieses Reading geben würde, konnte man sich vom FHEM aus super benachrichtigen lassen, wenns für die CCU was neues an Firmware gibt - so wie aktuell ja wieder.
Gruß
Ryker
Hallo Ryker,
ich habe das wie folgt gelöst:
1. In der CCU habe ich eine eigene Variable "Version_Neu" definiert.
2. Einmal am Tag prüft ein Skript die Onlineversion und stellt den Wert in dieser Varable zur Verfügung.
3. Über get VARS stehen alle Variablen aus der CCU dann in FHEM zur Verfügung.
Das ganze ist auch im Homatic-Forum beschrieben.
https://homematic-forum.de/forum/viewtopic.php?f=69&t=71544&sid=4563426d0667364c8c76fb6ef4242f53 (https://homematic-forum.de/forum/viewtopic.php?f=69&t=71544&sid=4563426d0667364c8c76fb6ef4242f53)
Viele Grüße
Jürgen
Hallo Juergen, super Lösung, danke.
Nur zur Info, hier eine Alternative, die direkt aus fhem funktioniert (auszuprobieren für die Kommandozeile) (dank an Otto) !
{my $latestVersion = qx(wget -q -O - "https://ccu3-update.homematic.com/firmware/download?cmd=js_check_version&serial=0&product=HM-CCU3");;fhem("setreading HMCCU3 latestVersion $latestVersion")}
Hallo zusammen,
es gibt hierbei nur einen kleinen Haken. Es wird schon eine neue Version angezeigt, obwohl diese nocht nicht von "deimos" in "stable" bereitgestellt wurde.
https://homematic-forum.de/forum/viewtopic.php?f=69&t=73440&sid=9d1ea57f5150ec5b758cc3af1927b9c4#p712295 (https://homematic-forum.de/forum/viewtopic.php?f=69&t=73440&sid=9d1ea57f5150ec5b758cc3af1927b9c4#p712295)
Hat hierzu noch jemand eine Lösung?
Viele Grüße
Jürgen
@Jamo: Danke - ich hab das nun in ein AT eingebaut und noch die Version rausextrahiert:
defmod CCU_Firmware_Check at *17:00:00 {\
my $latestVersion = qx(wget -q -O - "https://ccu3-update.homematic.com/firmware/download?cmd=js_check_version&serial=0&product=HM-CCU3");;\
my @parts = split /'/, $latestVersion;;\
fhem("setreading HM_CCU VERSION_LATEST $parts[1]");;\
}
Damit kann ich nun direkt in einem Notify vergleichen und wenn unterschiedlich ist, mir dann per Telegram-Bot eine Nachricht schicken.
Super, passt nun perfekt.
Zitat von: juemuc am 02 April 2022, 21:55:10
...
es gibt hierbei nur einen kleinen Haken. Es wird schon eine neue Version angezeigt, obwohl diese nocht nicht von "deimos" in "stable" bereitgestellt wurde....
Hat hierzu noch jemand eine Lösung?
Evtl könnte man da eine Watchdog im Fhem zwischenschalten, der einfach erstmal ein paar Tage abwartet und erst dann das Reading setzt. Mann muss die Info ja nicht gleich am ersten Tag haben.
Ryker
Hallo Ryker,
das mit ein paar Tagen "warten" ist aus meiner Sicht aber nicht die richtige Lösung. Man müsste "stable" abfragen können.
Viele Grüße
Jürgen
Die URL oben frägt ja stable ab. Das ist die URL, die die CCU selbst benutzt für die Anzeige, ob was neues an Firmware vorliegt.
ja, das ist das ofizielle CCU3 update von Homematic für die CCU3 hardware. Alexander Reinert (deimos) kompiliert das dann neu, und stellt das für debmatic dann immer erst ins testing repository, und dann erst 2 Woche später ins debmatic stable.
Zitat von: Jamo am 04 April 2022, 09:54:25
ja, das ist das ofizielle CCU3 update von Homematic für die CCU3 hardware. Alexander Reinert (deimos) kompiliert das dann neu, und stellt das für debmatic dann immer erst ins testing repository, und dann erst 2 Woche später ins debmatic stable.
Und deshlab wird in der pivccu aktuell auch noch keine neue Version angezeigt 8)
Dies passiert erst, wenn Alex seine Version in in seiner "stable"-Umgebung bereitstellt. Deswegen auch die Frage nach dieser Abfrage ;D
Wer kann helfen?
Viele Grüße
Jürgen
Achso, ja, klar, wer RasperryMatic, debmatic, piVCCU oder irgendwas anderes aus der Homematic-Community nimmt, muss dann anders auf updates checken. Die URL oben in dem Beispiel gilt nur für die CCU3-Hardware von Homematic.
So wie ich das bei piVCCU und debmatic sehe, reicht es ja da auf dem Raspi oder DebianServer, wo das läuft, entweder gleich über APT automatisch updaten zu lassen, oder darüber zumindest zu prüfen, ob was neues da ist. Da hat man ja dann gar kein Problem. Mit etwas ShellScripting geht das gut.
Bei RasperryMatic wäre es dann diese URL hier für Releases:
https://raspberrymatic.de/LATEST-VERSION.js
Ryker
Zitat von: tatu123 am 26 März 2022, 14:48:56
Hallo zusammen,
ich benutze jetzt schonm eine Weile die 5.0 und das ohne Auffälligkeiten. So weit so gut.
Bei den jetzigen Temperaturen wollte ich meinen Wintergarten wieder in Nutzung bringen. Dieser hat mehrere HmIP-FROLL
Aktoren. Diese steuere/steuerte ich mit einem Shelly-Button. Dazu habe ich eine Structur im fhem welche alle ROLL/FROLL-Aktoren
enthält. Der Shelly-Button steuert dann über einen http-Aufruf diese Structur an und gibt ein toggle mit.
Damit kann ich alle Jalousien gleichzeitig öffnen und schliessen. Zumindest im letzten Jahr.
Jetzt bekomme ich immer eine Fehlermeldung der Device
HMCCUDEV: HmIP_FROLL_winter_tuer_zu_3 Current device state doesn't match any state value
Hier das zugehörige Device. Dies habe ich jetzt extra neu mit get hmccu createDev angelegt.
defmod HmIP_FROLL_winter_tuer_zu_3 HMCCUDEV 001158A98B28ED sd=3.LEVEL cd=4.LEVEL
attr HmIP_FROLL_winter_tuer_zu_3 DbLogExclude .*
attr HmIP_FROLL_winter_tuer_zu_3 ccureadingfilter 1,2,3,4..*
attr HmIP_FROLL_winter_tuer_zu_3 cmdIcon open:fts_shutter_up stop:fts_shutter_manual close:fts_shutter_down
attr HmIP_FROLL_winter_tuer_zu_3 room Homematic
attr HmIP_FROLL_winter_tuer_zu_3 substexcl pct
attr HmIP_FROLL_winter_tuer_zu_3 webCmd pct:open:close:stop
attr HmIP_FROLL_winter_tuer_zu_3 widgetOverride pct:slider,0,10,100
Jetzt meine Frage: Was mache ich falsch? Gibt es den toggle in Jalousien nicht mehr, als set toggle noch im device vorhanden?
Viele Grüße
Heiko
So ich noch mal zum Problem den nicht funktionierenden toggle.
Ich habe jetzt noch mal weiter gescheut und bin zur Erkenntnis gekommen. Der Fehler betrift einzig die HMIP-FROLL-Geräte. Meine anderen "normalen" HM-Geräte könnten toggle. Vielleicht hilft das bei der Fehlersuche.
Hier noch mal ein List enes HMIP-FROLL:
Internals:
CFGFN
DEF 001158A98B28ED sd=3.LEVEL cd=4.LEVEL
FUUID 624c3bf7-f33f-638b-750f-da13c4d56501f34a
IODev d_ccu
NAME HmIP_FROLL_winter_tuer_zu_3
NR 5042
STATE closed
TYPE HMCCUDEV
ccuaddr 001158A98B28ED
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-FROLL-winter-tuer-zu
ccurolectrl SHUTTER_VIRTUAL_RECEIVER
ccurolestate SHUTTER_TRANSMITTER
ccusubtype FROLL
ccutype HmIP-FROLL
firmware 1.8.12
readonly no
OLDREADINGS:
READINGS:
2022-04-05 14:54:16 3.ACTIVITY_STATE STABLE
2022-04-05 14:54:16 3.LEVEL closed
2022-04-05 14:54:16 3.LEVEL_STATUS NORMAL
2022-04-05 14:54:16 3.PROCESS STABLE
2022-04-05 14:54:16 3.SECTION 15
2022-04-05 14:54:16 3.SECTION_STATUS NORMAL
2022-04-05 14:54:16 4.ACTIVITY_STATE STABLE
2022-04-05 14:54:16 4.LEVEL closed
2022-04-05 14:54:16 4.LEVEL_STATUS NORMAL
2022-04-05 14:54:16 4.PROCESS STABLE
2022-04-05 14:54:16 4.SECTION 0
2022-04-05 14:54:16 4.SECTION_STATUS NORMAL
2022-04-05 14:54:16 activity alive
2022-04-05 14:54:16 control closed
2022-04-05 14:54:16 devstate ok
2022-04-05 14:54:16 hmstate closed
2022-04-05 14:54:16 level closed
2022-04-05 14:54:16 pct 0
2022-04-05 14:54:16 rssidevice -63
2022-04-05 14:54:16 rssipeer -69
2022-04-05 14:54:16 state closed
2022-04-05 14:54:16 voltage 0.0
hmccu:
channels 8
defCDP 4.LEVEL
defSDP 3.LEVEL
detect 5
devspec 001158A98B28ED
forcedev 0
nodefaults 0
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:KEY_TRANSCEIVER,3:SHUTTER_TRANSMITTER,4:SHUTTER_VIRTUAL_RECEIVER,5:SHUTTER_VIRTUAL_RECEIVER,6:SHUTTER_VIRTUAL_RECEIVER,7:BLIND_WEEK_PROFILE
setDefaults 0
cmdlist:
get
set open:noArg up down oldLevel:noArg stop:noArg pct close:noArg toggle:noArg
control:
chn 4
dpt LEVEL
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
NVAL 20.000000
ONVAL 20.000000
OSVAL 20.0
OVAL 20.000000
SVAL 20.0
VAL 20.000000
0.ACTUAL_TEMPERATURE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.DUTY_CYCLE:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.ERROR_CODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.INSTALL_TEST:
VALUES:
NVAL true
ONVAL true
OSVAL true
OVAL true
SVAL true
VAL true
0.OPERATING_VOLTAGE:
VALUES:
NVAL 0.000000
ONVAL 0.000000
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
0.OPERATING_VOLTAGE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL -63
ONVAL -63
OSVAL -63
OVAL 193
SVAL -63
VAL 193
0.RSSI_PEER:
VALUES:
NVAL -69
ONVAL -69
OSVAL -69
OVAL 187
SVAL -69
VAL 187
0.UNREACH:
VALUES:
NVAL false
ONVAL false
OSVAL alive
OVAL false
SVAL alive
VAL false
0.UPDATE_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
3.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
3.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL closed
OVAL 0.000000
SVAL closed
VAL 0.000000
3.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
3.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
3.SECTION:
VALUES:
NVAL 15
ONVAL 15
OSVAL 15
OVAL 15
SVAL 15
VAL 15
3.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
4.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL closed
OVAL 0.000000
SVAL closed
VAL 0.000000
4.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
4.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
5.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL closed
OVAL 0.000000
SVAL closed
VAL 0.000000
5.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
5.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
5.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
6.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL closed
OVAL 0.000000
SVAL closed
VAL 0.000000
6.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
6.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
6.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.WEEK_PROGRAM_CHANNEL_LOCKS:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
roleCmds:
get:
set:
close:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:0
usage close
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
down:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=-20
usage down [delta]
subcmd:
000:
args -20
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
scn 000
unit 100%
oldLevel:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:100.5
usage oldLevel
subcmd:
000:
args 100.5
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
open:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:100
usage open
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
pct:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?level
usage pct level
subcmd:
000:
args
dpt LEVEL
fnc
max 1.01
min 0.0
parname level
partype 2
ps VALUES
scn 000
unit 100%
stop:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:STOP:1
usage stop
subcmd:
000:
args 1
dpt STOP
fnc
max 1
min 0
parname STOP
partype 3
ps VALUES
scn 000
unit
up:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=+20
usage up [delta]
subcmd:
000:
args +20
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
scn 000
unit 100%
state:
chn 3
dpt LEVEL
Attributes:
DbLogExclude .*
ccureadingfilter 1,2,3,4..*
cmdIcon open:fts_shutter_up stop:fts_shutter_manual close:fts_shutter_down
room Homematic
substexcl pct
webCmd pct:open:close:stop
widgetOverride pct:slider,0,10,100
Ein Schreibfehler in HMCCUConf.pm. Dort verwende ich teilweise "close" und teilweise "closed". Deshalb funktioniert toggle nicht.
Alles klar. Dann warte ich mal auf das Update.
Vielen Dank für die Bemühungen.
VG
Heiko
Hallo,
nach einem Update auf HMCCU 5.0 220431743 hab ich ein kleines Problem mit einer Systemvariablen für den Niederschlag meines HB-UNI-Sen-WEA.
Frage ich die Variablen in Fhem mittels
get d_ccu vars .*
ab, erhalte ich
${sysVarAlarmMessages}=0
${sysVarPresence}=true
${sysVarRainToday}=0.370000
${sysVarRainYesterday}=0.385789
${sysVarServiceMessages}=0
0.370000 ist der Niederschlag und dieser ist korrekt.
Im Reading
_sysVarRainToday_
steht aber dann als Wert 0.4
Wird da etwas aufgerundet auf eine Stelle hinterm Komma/Punkt?
Leider weiß ich nicht mehr welche Version von HMCCU ich vor dem Update hatte, da wurde jedoch korrekter Weise 0.37 ausgegeben.
Gruß
Jan
Gibt es das Attribut stripnumber, sonst ccudef-stripnumber
Zitat von: zap am 19 Mai 2022, 22:47:55
Gibt es das Attribut stripnumber, sonst ccudef-stripnumber
Super, danke das klappt!
Guten Morgen,
mir sind noch Logeinträge nach einem Neustrat von Fhem aufgefallen, die wohl auch in Bezug zur "neuen" HMCCU 5 stehen.
Folgendes kommt bei jedem Neustart von Fhem:
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\$\$\{?1.${ <-- HERE sysVarRainToday}\}?/ at ./FHEM/88_HMCCU.pm line 3069.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\$\$\{?${ <-- HERE sysVarRainToday}\}?/ at ./FHEM/88_HMCCU.pm line 3070.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\$\{?1.${ <-- HERE sysVarRainToday}\}?/ at ./FHEM/88_HMCCU.pm line 3073.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\$\{?${ <-- HERE sysVarRainToday}\}?/ at ./FHEM/88_HMCCU.pm line 3074.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\%\%\{?1.${ <-- HERE sysVarRainToday}\}?/ at ./FHEM/88_HMCCU.pm line 3077.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\%\%\{?${ <-- HERE sysVarRainToday}\}?/ at ./FHEM/88_HMCCU.pm line 3078.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\%\{?1.${ <-- HERE sysVarRainToday}\}?/ at ./FHEM/88_HMCCU.pm line 3081.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\%\{?${ <-- HERE sysVarRainToday}\}?/ at ./FHEM/88_HMCCU.pm line 3082.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/1.${ <-- HERE sysVarRainToday}/ at ./FHEM/88_HMCCU.pm line 3083.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\$\$\{?1.${ <-- HERE sysVarRainYesterday}\}?/ at ./FHEM/88_HMCCU.pm line 3069.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\$\$\{?${ <-- HERE sysVarRainYesterday}\}?/ at ./FHEM/88_HMCCU.pm line 3070.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\$\{?1.${ <-- HERE sysVarRainYesterday}\}?/ at ./FHEM/88_HMCCU.pm line 3073.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\$\{?${ <-- HERE sysVarRainYesterday}\}?/ at ./FHEM/88_HMCCU.pm line 3074.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\%\%\{?1.${ <-- HERE sysVarRainYesterday}\}?/ at ./FHEM/88_HMCCU.pm line 3077.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\%\%\{?${ <-- HERE sysVarRainYesterday}\}?/ at ./FHEM/88_HMCCU.pm line 3078.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\%\{?1.${ <-- HERE sysVarRainYesterday}\}?/ at ./FHEM/88_HMCCU.pm line 3081.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\%\{?${ <-- HERE sysVarRainYesterday}\}?/ at ./FHEM/88_HMCCU.pm line 3082.
2022.05.20 08:56:02 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/1.${ <-- HERE sysVarRainYesterday}/ at ./FHEM/88_HMCCU.pm line 3083.
Die Einträge haben alle Bezug zu den Variablen aus meiner CCU (pivccu3) der Wetterstation HB-UNI-Sen-WEA
Hallo zusammen!
Da die alte HM Hardware nach und nach verschwindet und HMIP nicht Nativ von FHEM unterstützt wird, gehe ich jetzt den Schritt über die CCU. Habe angefangen, mich einzulesen, wirkt aber aktuell alles etwas komplex auf mich. Für den Anfang wäre meine Frage: Ist Version 5.0 soweit stabil, dass ich es damit wagen kann, zu starten? Wenn ich es richtig verstanden habe, reduziert die Version ja etwas Komplexität bei der Anbindung, richtig?
Hallo prodicy7,
HMCCU V5 läuft bei mir seit monaten stabil. Habe hierbei HM und HM-IP im Mischbetrieb.
Viele Grüße
Jürgen
Zitat von: juemuc am 31 Dezember 2022, 14:55:41HMCCU V5 läuft bei mir seit monaten stabil. Habe hierbei HM und HM-IP im Mischbetrieb.
Gibt es noch irgendwelche nützlichen Tipps für die Einrichtung, die ich im Wiki nicht finde? Habe HM seit Jahren nativ direkt im Betrieb mit FHEM und das ist mein erster Kontakt mit der CCU
Bei mir läuft die v5 auch schon lange (August 2021) absolut stabil.
Ein Tip wäre vielleicht, sich den HM-IP Key und die SGTIN des physikalischen Devices, im "comment" des jeweiligen fhem Devices zu merken, für den Fall der Fälle.
Zitat von: Jamo am 31 Dezember 2022, 21:52:12
Ein Tip wäre vielleicht, sich den HM-IP Key und die SGTIN des physikalischen Devices, im "comment" des jeweiligen fhem Devices zu merken, für den Fall der Fälle.
Werde ich mir noch anlesen, danke :) Wenn sinnvoll, wäre das vielleicht auch ans Tip im Wiki nützlich.
Zitat von: prodigy7 am 31 Dezember 2022, 22:06:42
Werde ich mir noch anlesen, danke :) Wenn sinnvoll, wäre das vielleicht auch ans Tip im Wiki nützlich.
Der HM-IP Key und die SGTIN des physikalischen Devices ist immer auf dem Karton aufgedruckt, bzw unterhalb des QR-Codes gedruckt, der bei jedem HM-IP Gerät dabeiliegt.
Hi,
ich bekomme viele Perl-Warnings obigen Inhalts, wiewohl die Devices einwandfrei funktionieren.
Stacktrace zeigt Folgendes:
main::__ANON__ called by (eval 523561) (1)
2023.01.19 16:21:56 1: (eval) called by ./FHEM/33_readingsGroup.pm (357)
2023.01.19 16:21:56 1: main::lookup2 called by ./FHEM/33_readingsGroup.pm (1445)
2023.01.19 16:21:56 1: main::readingsGroup_Notify called by fhem.pl (3976)
2023.01.19 16:21:56 1: main::CallFn called by fhem.pl (3888)
2023.01.19 16:21:56 1: main::DoTrigger called by fhem.pl (4995)
2023.01.19 16:21:56 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (9105)
2023.01.19 16:21:56 1: main::HMCCU_EndBulkUpdate called by ./FHEM/88_HMCCU.pm (4843)
2023.01.19 16:21:56 1: main::HMCCU_UpdateParamsetReadings called by ./FHEM/88_HMCCU.pm (4959)
2023.01.19 16:21:56 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (878)
2023.01.19 16:21:56 1: main::HMCCURPCPROC_Read called by fhem.pl (3976)
2023.01.19 16:21:56 1: main::CallFn called by fhem.pl (784)
Liegt das Problem am "ok" im Reading "Battery" ?
battery ok 2023-01-19 17:23:49
Die Fehlermeldung erscheint exakt immer dann, wenn die Devices aktualisiert werden.
Weiß jemand Rat?
LG Ingo
Zitat von: is2late am 19 Januar 2023, 17:36:56
Weiß jemand Rat?
Ja. Du solltest die Antworten in Deinem anderen Thread lesen.
Zitat von: zap am 05 April 2022, 15:53:04
Ein Schreibfehler in HMCCUConf.pm. Dort verwende ich teilweise "close" und teilweise "closed". Deshalb funktioniert toggle nicht.
Hmmm, bei mir, mit der aktuellen fhem-Version und sicherheitshalber einem "update", kommt bei einem FROLL und toggle-Versuch auch die Fehlermeldung
HMCCUDEV: Dachgeschossfenster Current device state doesn't match any state value Woran kann das nun liegen?
Gruß
td
Zitat von: td am 30 Januar 2023, 19:38:42
Hmmm, bei mir, mit der aktuellen fhem-Version und sicherheitshalber einem "update", kommt bei einem FROLL und toggle-Versuch auch die Fehlermeldung
HMCCUDEV: Dachgeschossfenster Current device state doesn't match any state value
Woran kann das nun liegen?
Gruß
td
Evtl. war beim Update auf die aktuelle Version irgendwas mal nicht erreichbar. Dann wird das Device deaktiviert.
Lösch mal das Attribut:
disable 1oder ändere es auf 0
Zitat von: Steigerbalett am 01 Februar 2023, 10:32:54
Evtl. war beim Update auf die aktuelle Version irgendwas mal nicht erreichbar. Dann wird das Device deaktiviert.
Lösch mal das Attribut:
disable 1
oder ändere es auf 0
Das Attribut exisitert gar nicht in dem Device.
Aber: Nach einem erneuten Update funktioniert es, wie es sollte.
Danke.
Gruß
td
Hallo zusammen,
ich habe vor einiger Zeit mal die HMCCU vom Update ausgeschlossen. Bei mir läuft noch die Version 4.3.025
Ist das Upgrade auf 5.x wirklich so einfach wie hier beschrieben?
https://wiki.fhem.de/wiki/HMCCU#Migration_von_HMCCU_4.3
Oder muss ich mit größeren Nacharbeiten rechnen?
Das hängt wohl auch von deinem "Gerätepark" ab.
Für größere Umstellungen empfehle ich ein Testsystem.
Viele Grüße
Jürgen
Also ich habe hauptsächlich Lichtschalter,
Thermostate, Ventile und Fensterkontakte.
Bis auf wenige Ausnahmen alles klassisches HM.
Mein Plan wäre Backup machen, Update Durchführen und dann mal gucken. Dann nach und nach Devices Nacharbeiten.
Ja, das ist auch ein Weg. Ggf. sind dann die HM-Komponenten nicht verfügbar.
Ich hatte nur geringen Anpassungsbedarf.
Viele Grüße
Jürgen
Hallo liebes Forum,
Ich verwende die aktuelle HMCCU Version und habe einen Hm-IP-Broll-2, der nicht toggeln möchte, wenn state=closed ist.
Es kommt die Fehlermeldung:
ZitatHMCCUDEV: HmIP_BROLL_2_Markise Current device state doesn't match any state value
Internals:
DEF 00369F2999F59F sd=3.LEVEL cd=4.LEVEL
FUUID 64ddfaed-f33f-2b6d-b96d-47f45dce3550acbb
IODev d_ccu
NAME HmIP_BROLL_2_Markise
NR 12908
STATE closed
TYPE HMCCUDEV
ccuaddr 00369F2999F59F
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-BROLL-2-Markise
ccurolectrl SHUTTER_VIRTUAL_RECEIVER
ccurolestate SHUTTER_TRANSMITTER
ccusubtype BROLL
ccutype HmIP-BROLL-2
eventCount 101
firmware 1.10.4
readonly no
OLDREADINGS:
READINGS:
2023-08-17 17:02:14 3.ACTIVITY_STATE STABLE
2023-08-17 17:02:14 3.LEVEL closed
2023-08-17 17:02:14 3.LEVEL_STATUS NORMAL
2023-08-17 17:02:14 3.PROCESS STABLE
2023-08-17 17:02:14 3.SECTION
2023-08-17 17:02:14 3.SECTION_STATUS UNKNOWN
2023-08-17 16:50:39 3.SELF_CALIBRATION_RESULT true
2023-08-17 17:02:14 4.ACTIVITY_STATE STABLE
2023-08-17 17:02:14 4.LEVEL closed
2023-08-17 17:02:14 4.LEVEL_STATUS NORMAL
2023-08-17 17:02:14 4.PROCESS STABLE
2023-08-17 17:02:14 4.SECTION 0
2023-08-17 17:02:14 4.SECTION_STATUS NORMAL
2023-08-17 17:02:14 activity alive
2023-08-17 17:02:14 control closed
2023-08-17 17:02:14 devstate ok
2023-08-17 17:02:14 hmstate closed
2023-08-17 17:02:14 level closed
2023-08-17 17:02:14 pct 0
2023-08-17 17:02:14 rssidevice -67
2023-08-17 17:02:08 rssipeer -91
2023-08-17 17:02:14 state closed
2023-08-17 12:48:14 voltage 0.0
hmccu:
channels 8
defCDP 4.LEVEL
defSDP 3.LEVEL
detect 5
devspec 00369F2999F59F
forcedev 0
nodefaults 0
role 0:MAINTENANCE,1:KEY_TRANSCEIVER,2:KEY_TRANSCEIVER,3:SHUTTER_TRANSMITTER,4:SHUTTER_VIRTUAL_RECEIVER,5:SHUTTER_VIRTUAL_RECEIVER,6:SHUTTER_VIRTUAL_RECEIVER,7:BLIND_WEEK_PROFILE
setDefaults 0
cmdlist:
get
set pct close:noArg stop:noArg open:noArg up down oldLevel:noArg toggle:noArg
control:
chn 4
dpt LEVEL
dp:
0.ACTUAL_TEMPERATURE:
VALUES:
NVAL 32.0
ONVAL 33.0
OSVAL 33.0
OVAL 33.0
SVAL 32.0
VAL 32.0
0.ACTUAL_TEMPERATURE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.DUTY_CYCLE:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_CODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.ERROR_OVERLOAD:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
0.INSTALL_TEST:
VALUES:
NVAL true
ONVAL true
OSVAL true
OVAL true
SVAL true
VAL true
0.OPERATING_VOLTAGE:
VALUES:
NVAL 0.000000
ONVAL 0.000000
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
0.OPERATING_VOLTAGE_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL -67
ONVAL -72
OSVAL -72
OVAL -72
SVAL -67
VAL -67
0.RSSI_PEER:
VALUES:
NVAL -91
ONVAL -90
OSVAL -90
OVAL -90
SVAL -91
VAL -91
0.UNREACH:
VALUES:
NVAL 0
ONVAL 0
OSVAL alive
OVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
3.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 2
OSVAL DOWN
OVAL 2
SVAL STABLE
VAL 3
3.LEVEL:
VALUES:
NVAL 0
ONVAL 100
OSVAL open
OVAL 1.0
SVAL closed
VAL 0.0
3.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
3.PROCESS:
VALUES:
NVAL 0
ONVAL 1
OSVAL NOT_STABLE
OVAL 1
SVAL STABLE
VAL 0
3.SECTION:
VALUES:
NVAL
ONVAL
OSVAL
OVAL
SVAL
VAL
3.SECTION_STATUS:
VALUES:
NVAL 1
ONVAL 1
OSVAL UNKNOWN
OVAL 1
SVAL UNKNOWN
VAL 1
3.SELF_CALIBRATION_RESULT:
VALUES:
NVAL 1
ONVAL 0
OSVAL false
OVAL 0
SVAL true
VAL 1
4.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 2
OSVAL DOWN
OVAL 2
SVAL STABLE
VAL 3
4.LEVEL:
VALUES:
NVAL 0
ONVAL 100
OSVAL open
OVAL 1.0
SVAL closed
VAL 0.0
4.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
4.PROCESS:
VALUES:
NVAL 0
ONVAL 1
OSVAL NOT_STABLE
OVAL 1
SVAL STABLE
VAL 0
4.SECTION:
VALUES:
NVAL 0
ONVAL 7
OSVAL 7
OVAL 7
SVAL 0
VAL 0
4.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
5.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL closed
OVAL 0.0
SVAL closed
VAL 0.0
5.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
5.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
5.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
5.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.ACTIVITY_STATE:
VALUES:
NVAL 3
ONVAL 3
OSVAL STABLE
OVAL 3
SVAL STABLE
VAL 3
6.LEVEL:
VALUES:
NVAL 0
ONVAL 0
OSVAL closed
OVAL 0.0
SVAL closed
VAL 0.0
6.LEVEL_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
6.PROCESS:
VALUES:
NVAL 0
ONVAL 0
OSVAL STABLE
OVAL 0
SVAL STABLE
VAL 0
6.SECTION:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
6.SECTION_STATUS:
VALUES:
NVAL 0
ONVAL 0
OSVAL NORMAL
OVAL 0
SVAL NORMAL
VAL 0
7.WEEK_PROGRAM_CHANNEL_LOCKS:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
roleCmds:
get:
set:
close:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:0
usage close
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
down:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=-20
usage down [delta]
subcmd:
000:
args -20
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
scn 000
unit 100%
oldLevel:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:100.5
usage oldLevel
subcmd:
000:
args 100.5
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
open:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:100
usage open
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.01
min 0.0
parname LEVEL
partype 3
ps VALUES
scn 000
unit 100%
pct:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?level
usage pct level
subcmd:
000:
args
dpt LEVEL
fnc
max 1.01
min 0.0
parname level
partype 2
ps VALUES
scn 000
unit 100%
stop:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:STOP:1
usage stop
subcmd:
000:
args 1
dpt STOP
fnc
max 1
min 0
parname STOP
partype 3
ps VALUES
scn 000
unit
up:
channel 4
role SHUTTER_VIRTUAL_RECEIVER
subcount 1
syntax V:LEVEL:?delta=+20
usage up [delta]
subcmd:
000:
args +20
dpt LEVEL
fnc
max 1.01
min 0.0
parname delta
partype 2
ps VALUES
scn 000
unit 100%
state:
chn 3
dpt LEVEL
Attributes:
DbLogExclude .*
ccureadingfilter 1,2,3,4..*
cmdIcon open:fts_shutter_up stop:fts_shutter_manual close:fts_shutter_down
event-on-change-reading .*
room Garten->Terrasse
substexcl pct
webCmd pct:open:close:stop
widgetOverride pct:slider,0,10,100Bei state=open gibt es kein Problem.
Weitere Fehler im Log:
2023.08.18 11:43:34 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:34 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:34 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:34 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:34 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset MASTER for address 00369F2999F59F
2023.08.18 11:43:34 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:34 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:34 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:34 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:34 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset SERVICE for address 00369F2999F59F
2023.08.18 11:43:34 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:34 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset MASTER for address 00369F2999F59F:0
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset SERVICE for address 00369F2999F59F:0
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset MASTER for address 00369F2999F59F:1
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset SERVICE for address 00369F2999F59F:1
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset MASTER for address 00369F2999F59F:2
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset SERVICE for address 00369F2999F59F:2
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:35 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset MASTER for address 00369F2999F59F:3
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:35 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset SERVICE for address 00369F2999F59F:3
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset MASTER for address 00369F2999F59F:4
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset SERVICE for address 00369F2999F59F:4
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset MASTER for address 00369F2999F59F:5
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset SERVICE for address 00369F2999F59F:5
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset MASTER for address 00369F2999F59F:6
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset SERVICE for address 00369F2999F59F:6
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset MASTER for address 00369F2999F59F:7
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] RPC request getParamset failed: Invalid device
2023.08.18 11:43:36 2: HMCCURPCPROC [d_rpc005015HmIP_RF] Retrying request getParamset
2023.08.18 11:43:36 2: HMCCUDEV [HmIP_BROLL_2_Markise] Can't get parameterset SERVICE for address 00369F2999F59F:7Könnt Ihr mir da bitte weiterhelfen? Ganz lieben Dank
Hallo, habe ein komisches Phänomen mit FHEMWEB mit einem Homematic Dimmer (HM-LC-Dim1L-Pl-2) und HMCCU.
Wenn ich dem Dimmer einschalte oder Dimmwerte einstelle bekomme ich die Meldung:
Connection lost, trying a reconnect every 5 seconds.
Der Schaltvorgang selbst funktioniert einwandfrei.
Anscheinend passiert hier im Hintergrund etwas, das FHEM blockiert, es tritt auch nur beim Dimmer auf, normale Schaltaktoren verursachen das Problem nicht. Das
Problem tritt auch nur auf wenn ich im Fhem auf der Seite des Dimmers bin, wenn ich auf der Startseite über die Commandline oben "set Dimmer on" ausführe klappt es auch ohne Probleme.
Habe auch schon die "ccuflags" auf "nonBlocking" probiert aber ohne Erfolg. FHEMWEB ist longpoll auch auf websocket.
Weiß nicht wo ich weitersuchen soll bzw. wo das Problem liegen könnte.
Vielleicht hat ja jemand einen Tipp.
lg
EDIT: Hier noch das list meiner d_ccu (gekürzt)
NOTIFYDEV global
NR 357
NTFY_ORDER 50-d_ccu
RPCState running
STATE running/OK
TYPE HMCCU
ccuaddr BidCoS-RF
ccuchannels 189
ccudevices 34
ccuif BidCos-RF
ccuinterfaces VirtualDevices,BidCos-RF,HmIP-RF
ccuname HM-RCV-50 BidCoS-RF
ccustate active
ccutype CCU2/3
config 5.0
eventCount 40
firmware 3.69.7.20230626
prot http
version 5.0 222930908
READINGS:
2023-08-29 07:45:41 PLATFORM rpi3
2023-08-29 07:45:41 PRODUCT raspmatic_rpi3
2023-08-29 07:45:41 VERSION 3.69.7.20230626
2023-08-29 07:45:41 count_channels 189
2023-08-29 07:45:41 count_devices 34
2023-08-29 07:45:41 count_groups 0
2023-08-29 07:45:41 count_interfaces 3
2023-08-29 07:45:41 count_programs 1
2023-08-29 10:34:42 rpcstate running
2023-08-29 10:34:42 state OK
Hallo,
Hab das selbe Problem.
Bin HMCCU Newbee und möchte in FHEM meine HomeMatic Komponenten in die HMCCU einbringen.
Hab zum Test einen Funk-Schaltaktor 8-fach (HM-MOD-Re-8) integriert der ohne Probleme funktioniert.
Gestern hab ich ein Funk-Wandthermostat (HM-TC-IT-WM-W-EU) mit 2 Direkt Verknüpften Funk-Heizkörperthermostat (HM-CC-RT-DN) eingebunden.
Diese verursachen ebenfalls einen
Connection lost, trying a reconnect every 5 seconds.
Fehler in fhem.
Die Änderungen werden aber Minuten später dann doch übernommen.
RaspberryMatic Firmware: 3.71.12.20230826
Wegen "Connection lost": Bitte mal im Attribut ccuflags im I/O Device das Flag "nonBlocking" setzen.
Das ccuflag nonBlocking hatte ich schon getestet... hat aber leider keinen Erfolg gebracht
Zitat von: zap am 31 August 2023, 13:43:03Wegen "Connection lost": Bitte mal im Attribut ccuflags im I/O Device das Flag "nonBlocking" setzen.
Zitat von: psycho160 am 29 August 2023, 10:59:55Habe auch schon die "ccuflags" auf "nonBlocking" probiert aber ohne Erfolg. FHEMWEB ist longpoll auch auf websocket.
Bei mir auch ohne Erfolg
was ein wenig Abhilfe brachte ist das Attribut event-on-change-reading .*
Es Löst das Problem aber nicht zur Gänze.
Hey zap, ich hatte auch mal nonBlocking gesetzt. Beim starten der HMCCU ist mein FHEM blockiert. Bei mir funktioniert dann leider ,,on-for-timer" nicht mehr.
Hallo,
herzlichen Dank an zap - der Umstieg von CUL_HM auf HMCCU hat super funktioniert und läuft seit > 1 Jahr sehr stabil.
Alle HOMEMATIC Geräte laufen 1a, nur das Gerät HM-Dis-WM55 wird leider teilweise unterstützt Scheinbar ist eine Routine zum Kodieren des Command Strings zum Darstellen von Inhalten auf dem Display nicht implementiert. Das Display WM-DIS-EP-WM55 hingegen läuft, da die Encodier-Routine programmiert worden ist. Wird es vielleicht eine HMCCU v.5.1 geben, bei dem HM-Dis-WM55 vollstäbdig unterstützt wird?
Kann hier gerne auch mit Programmcode unterstützen bzw. testen.
Danke,
muc46
hallo,
hab den neuen Smartmeter von HMIP (HmIP-ESI-IEC). Konnte ihn auch in Debmatic anlernen aber mit der HMCCU bekomme ich ihn leider noch nicht rein. Unter "get Debmatic ccuDevices" wird er zwar angezeigt aber in der Liste bei CreateDev fehlt er. Wie komme ich ihn jetzt in FHEM?
Zitat von: StephanFHEM am 10 Dezember 2023, 16:45:31hallo,
hab den neuen Smartmeter von HMIP (HmIP-ESI-IEC). Konnte ihn auch in Debmatic anlernen aber mit der HMCCU bekomme ich ihn leider noch nicht rein. Unter "get Debmatic ccuDevices" wird er zwar angezeigt aber in der Liste bei CreateDev fehlt er. Wie komme ich ihn jetzt in FHEM?
Du kannst das Gerät auf jeden Fall per define anlegen:
define myDev HMCCUDEV Name_oder_Adresse
Oder Du postest hier mal die Ausgabe von
get Debmatic deviceInfo Name
Dann kann ich Dir sagen, ob HMCCUDEV oder HMCCUCHN sinnvoll ist
Device channels and datapoints
DEV Stromzaehler_Keller 003FA0C9AD73AE interface=HmIP-RF type=HmIP-ESI
CHN 003FA0C9AD73AE:0 Stromzaehler_Keller:0
0.CONFIG_PENDING = false {b} [RE]
0.DUTY_CYCLE = false {b} [RE]
0.ERROR_CODE = 2 {i} [RE]
0.ERROR_COMMUNICATION_SENSOR = true {b} [RE]
0.INSTALL_TEST = true {b} [RW]
0.LOW_BAT = false {b} [RE]
0.OPERATING_VOLTAGE = 0.000000 {f} [RE]
0.OPERATING_VOLTAGE_STATUS = 0 {i} [RE]
0.RSSI_DEVICE = -57 {i} [RE]
0.RSSI_PEER = 0 {i} [RE]
0.SENSOR_ERROR = false {b} [RE]
0.UNREACH = true {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
CHN 003FA0C9AD73AE:1 HmIP-ESI 003FA0C9AD73AE:1
1.CHANNEL_OPERATION_MODE = 4 {i} [RE]
1.GAS_FLOW = 0.000000 {f} [RE]
1.GAS_FLOW_STATUS = 0 {i} [RE]
1.POWER = 378.230000 {f} [RE]
1.POWER_STATUS = 1 {i} [RE]
1.SELF_CALIBRATION = {i} [W]
1.SELF_CALIBRATION_RESULT = 4 {i} [E]
CHN 003FA0C9AD73AE:2 HmIP-ESI 003FA0C9AD73AE:2
2.ENERGY_COUNTER = 40100980.000000 {f} [RE]
2.ENERGY_COUNTER_STATUS = 1 {i} [RE]
2.GAS_VOLUME = 0.000000 {f} [RE]
2.GAS_VOLUME_STATUS = 0 {i} [RE]
CHN 003FA0C9AD73AE:3 HmIP-ESI 003FA0C9AD73AE:3
3.ENERGY_COUNTER = 1300.000000 {f} [RE]
3.ENERGY_COUNTER_STATUS = 1 {i} [RE]
CHN 003FA0C9AD73AE:4 HmIP-ESI 003FA0C9AD73AE:4
4.ENERGY_COUNTER = 2459.200000 {f} [RE]
4.ENERGY_COUNTER_STATUS = 1 {i} [RE]
Device description
Device 003FA0C9AD73AE Stromzaehler_Keller [HmIP-ESI]
AES_ACTIVE: 1
AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 003FA0C9AD73AE:0,003FA0C9AD73AE:1,003FA0C9AD73AE:2,003FA0C9AD73AE:3,003FA0C9AD73AE:4
DIRECTION: NONE
FIRMWARE: 1.0.6
FIRMWARE_UPDATE_STATE: UP_TO_DATE
FLAGS: Visible
PARAMSETS: MASTER,SERVICE
RF_ADDRESS: 5302174
ROAMING: 0
RX_MODE: CONFIG
SUBTYPE: ESI
UPDATABLE: 1
Channel 003FA0C9AD73AE:0 Stromzaehler_Keller:0 [MAINTENANCE]
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 003FA0C9AD73AE
PARENT_TYPE: HmIP-ESI
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 003FA0C9AD73AE:1 HmIP-ESI 003FA0C9AD73AE:1 [ENERGIE_METER_TRANSMITTER] known
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 003FA0C9AD73AE
PARENT_TYPE: HmIP-ESI
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 003FA0C9AD73AE:2 HmIP-ESI 003FA0C9AD73AE:2 [ENERGIE_METER_TRANSMITTER] known
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 003FA0C9AD73AE
PARENT_TYPE: HmIP-ESI
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 003FA0C9AD73AE:3 HmIP-ESI 003FA0C9AD73AE:3 [ENERGIE_METER_TRANSMITTER] known
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 003FA0C9AD73AE
PARENT_TYPE: HmIP-ESI
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
Channel 003FA0C9AD73AE:4 HmIP-ESI 003FA0C9AD73AE:4 [ENERGIE_METER_TRANSMITTER] known
AES_ACTIVE: 1
DIRECTION: NONE
FLAGS: Visible
PARAMSETS: MASTER,VALUES,SERVICE
PARENT: 003FA0C9AD73AE
PARENT_TYPE: HmIP-ESI
RF_ADDRESS: 0
ROAMING: 0
RX_MODE:
UPDATABLE: 1
So:
define Stromzaehler HMCCUDEV Stromzaehler_Keller
Dann solltest Du alle relevanten Datenpunkte als Readings sehen.
Ggf einmal nach der Definition:
get Stromzaehler values