HueDevice Update für Eurotronic Spirit ZigBee

[justme1968]

du musst kein komplett neues kommando bauen. kannst cmdalias auch verwenden um das set kommando eines device zu modifizieren. das geht auf zwei arten:

Code Auswählen Erweitern

defmod heatsetpointX100 cmdalias set .* heatsetpoint .* AS {fhem("set $EVTPART0 $EVTPART1 ". $EVTPART2 * 100)}

hier wird heatsetpoint überschrieben. hier könnte man im perl code sogar prüfen in welchem bereich der wert ist und nur bei <100 multiplizieren.


oder:

Code Auswählen Erweitern

defmod heatsetpointX100 cmdalias set .* heatsetpointX100 .* AS {fhem("set $EVTPART0  heatsetpoint". $EVTPART2 * 100)}

hier wird ein zusätzliches set <name> heatsetpointX100 <wert> kommando erzeugt.


welche der beiden varianten besser ist hängt davon ab was der anwender sehen soll, und beim kommando in fhemweb dropdown der richtige wert angzeigt werden soll.

[Shojo]

Ah das kannte ich noch nicht danke für die Erläuterung!

[Shojo]

Habe nun noch die huedevice.template erweitert, so das dass CMDAlias auch mit angelegt wird

Jetzt bin ich glücklich, danke für die Unterstürzung und Anpassungen!

Code Auswählen Erweitern


###########################################
# $Id: $
#
# Comments start with #. Empty lines are ignored.
# Syntax of one entry: name: line, one optional filter: line, zero or more par: lines,  FHEM-Commands
# filter:INTERNAL=VALUE (optional)
# par: name of the parameter; comment; perl_code (optional)
# perl_code returns a value for the parameter, or undef.
# If undef, the user has to specify them (the comment is shown to the user)


###########################################
# Eurotronic Spirit ZigBee (SPZB0001)
name:Eurotronic_Spirit_ZigBee_SPZB0001
filter:TYPE=HUEDevice
attr DEVICE configList /mode (.*)/:{"mode":"$1"}\
/heatsetpoint (.*)/:{"heatsetpoint": $1 }\
/displayflipped (.*)/:{"displayflipped": $1 }\
/locked (.*)/:{"locked": $1 }
attr DEVICE widgetOverride mode:auto,heat,off displayflipped:true,false locked:true,false heatsetpoint:16,16.5,17,17.5,18,18.5,19,19.5,20,20.5,21,21.5,22
attr DEVICE icon max_heizungsthermostat
defmod heatsetpointX100 cmdalias set .* heatsetpoint .* AS {fhem("set $EVTPART0 $EVTPART1 ". $EVTPART2 * 100)}
attr heatsetpointX100 comment This is an help CMDAlias for the Eurotronic Spirit ZigBee (SPZB0001).\
This CMDAlias prepares the value of heatsetpoint for the Hue/deCONZ API (multiplies the value by 100).

###########################################
# Xiaomi/Aqara Fenster Tür Sensor (lumi.sensor_magnet.aq2)
name:Xiaomi_Aqara_Window_Door_Sensor
filter:TYPE=HUEDevice
attr DEVICE devStateIcon open:fts_window_1w_open@#e56524 closed:fts_window_1w
attr DEVICE stateFormat state

###########################################
# Xiaomi/Aqara WSDCGQ11LM Temperatur Sensor (lumi.weather)
name:Xiaomi_Aqara_Temperature_Sensor
filter:TYPE=HUEDevice
attr DEVICE icon xiaomi_multi
attr DEVICE stateFormat T: temperature °C
# Xiaomi/Aqara WSDCGQ11LM Pressure Sensor (lumi.weather)
name:Xiaomi_Aqara_Pressure_Sensor
filter:TYPE=HUEDevice
attr DEVICE icon xiaomi_multi
attr DEVICE stateFormat P: pressure hPa
# Xiaomi/Aqara WSDCGQ11LM Humidity Sensor (lumi.weather)
name:Xiaomi_Aqara_Humidity_Sensor
filter:TYPE=HUEDevice
attr DEVICE icon xiaomi_multi
attr DEVICE stateFormat H: humidity %

###########################################
# Xiaomi/Aqara Motion Sensor (lumi.sensor_motion.aq2)
name:Xiaomi_Aqara_Motion_Sensor
filter:TYPE=HUEDevice
attr DEVICE devStateIcon motion:people_sensor@#e56524 nomotion:people_sensor@lightgray
attr DEVICE icon motion_detector
attr DEVICE stateFormat state
# Xiaomi/Aqara Lightlevel Sensor (lumi.sensor_motion.aq2)
name:Xiaomi_Aqara_Lightlevel_Sensor
filter:TYPE=HUEDevice
attr DEVICE icon IR
attr DEVICE stateFormat lux Lux


[justme1968]

hab eben meine und deine änderungen an 31_HUEDevice.pm eingecheckt.

@Beta-User: wer soll die attrTemplates einchecken?

[justme1968]

@Beta-User: und noch eine template frage: ist es sinnvoll den filter noch enger zu fassen? z.b. auf die internals modelid und/oder type?

[cyablo]

Mit den aktuellen Änderungen sind nach 'update all' heute morgen wieder alle Hue Lampen und Sensoren weg bei mir und das Log ist voll mit Meldungen wie:

019.06.20 08:07:40 2: huebridge: message for unknow device received: huebridge-8 sowie stacktraces:

Code Auswählen Erweitern

2019.06.20 08:07:55 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/31_HUEDevice.pm line 1368.
2019.06.20 08:07:55 1: stacktrace:
2019.06.20 08:07:55 1:     main::__ANON__                      called by ./FHEM/31_HUEDevice.pm (1368)
2019.06.20 08:07:55 1:     main::HUEDevice_Parse               called by ./FHEM/30_HUEBridge.pm (1758)
2019.06.20 08:07:55 1:     main::HUEBridge_dispatch            called by ./FHEM/30_HUEBridge.pm (1178)
2019.06.20 08:07:55 1:     main::HUEBridge_GetUpdate           called by ./FHEM/30_HUEBridge.pm (429)
2019.06.20 08:07:55 1:     main::HUEBridge_OpenDev             called by ./FHEM/30_HUEBridge.pm (274)
2019.06.20 08:07:55 1:     main::HUEBridge_Notify              called by fhem.pl (3750)
2019.06.20 08:07:55 1:     main::CallFn                        called by fhem.pl (3670)
2019.06.20 08:07:55 1:     main::DoTrigger                     called by fhem.pl (653)

hab eben meine und deine änderungen an 31_HUEDevice.pm eingecheckt.

@Beta-User: wer soll die attrTemplates einchecken?

[Beta-User]

Zu den attrTemplate-Fragen:

Es wäre gut, wenn dazu jemand den Maintainer macht, der (Anwender-) Ahnung hat, wie HUEDevice "tickt", also wann welche Attribute Sinn machen usw. (und vielleicht ein paar verschiedene hat). Ich stehe gerne bereit, um das eine Zeitlang zu coachen und kann es ggf. auch einchecken, aber tendenziell fände ich es besser, wenn sich ein anderer (Haupt-) Verantwortlicher fände (Shojo, wie wäre es?).

Filtern würde ich zunächst nicht weiter. Es ist zwar super, wenn man als Anwender immer nur das angezeigt bekommt, was man tatsächlich benötigt, aber evtl. ist es für's Sammeln erst mal gut, wenn Helfende mitbekommen, dass es evtl. für ähnliche Devices bereits ein template gibt, das man sich mal ansehen könnte. Später, wenn sich noch mehr Leute damit beschäftigt haben und die Sammlung groß genug ist, kann (und sollte man) dann die Filter enger fassen.

Grundsätzlich noch meine Erfahrungen:
- Wenn es ggf. sehr viele Devices/templates werden, sollte man sich frühzeitig über die Sortierung Gedanken machen. In der Darstellung bei "?" sortiert AttrTemplate dann nach dem Namen. Meine Gedanken zum Nummernsystem (die hier nicht notwendigerweise passen müssen), hatte ich irgendwo bei den MQTT2 und HTTPMOD-Threads niedergeschrieben.
- Wenn es eigentlich "generische" templates sind, die auf mehrere Geräte (also reale Hardware-Typen/Modelle) passen (könnten), ist es m.E. besser, das auch generisch zu benennen und dann in der "desc" klarzumachen, womit es konkret (schon) getestet wurde. Das "fehlt" hier ggf. noch. In der desc (oder in comment) kann man dann auch Links (insbes. wiki/forum) hinterlegen, wenn man z.B. weitere Konfigurationsvarianten hat. (Tendenziell würde ich vermuten, dass z.B. die Sensorik Tem/hum gleich ist, egal, welchen Sensor man konkret verwendet; ähnliches gilt ggf. für Leuchten (die aber wohl schon modulseitig passend verarbeitet werden, erwähne das eher wegen des Prinzips)).
- Weitere Hinweise kann man in eine abschließende Rückmeldemessage packen (farewell, z.B. bei der mqtt2-GeneralBridge)
- Dinge, die sowieso so sind, oder nur dann klappen, wenn das Umfeld paßt (insbes. Sprachsteuerung), würde ich eher weglassen, hier also v.a. "stateFormat state".
- Wegen der Verwendung usw. ist es evtl. sinnvoll, auch "model" zu pflegen.

Grundsätzlich habe ich zumindest bei MQTT2 (das m.E. ähnlich ist, v.a. wg. zigbee2mqtt) die Erfahrung gemacht, dass man als Maintainer für die templates eigentlich nur mal die Anwender für das Thema gewinnen muß (was dort einfach war), dann gibt es genug, die einem RAW-Definitionen oder gertige Templates liefern, die man "nur einchecken" muß. (Ok, etwas mehr, nämlich häufig noch sinnvoll einsortieren, ggf. redigieren, checken, was man zusammenfassen kann, und ggf. auch widersprüchliche Aussagen mal hinterfragen (hatte @mqtt aber häufig damit zu tun, dass man die Dienste/Geräte selbst unterschiedlich konfigurieren konnte, v.a. bei tasmota). Aber "an sich" war das eine Art Selbstläufer, und weil sich die templates nicht auf den laufenden Betrieb auswirken, ist das Ganze auch recht "fehlertolerant".

Wenn das obige "kryptisch" ist wegen den Begrifflichkeiten usw.: Einfach mal die MQTT- und HTTPMOD-templates mit dem "?" anzeigen lassen und den Quellcode dazu vergleichen. Ansonsten natürlich auch gerne fragen .

[justme1968]

ACHTUNG: mit der gestern eingecheckten version ist irgendetwas schief gegangen.

ich habe das eben korrigiert.

bitte erst morgen updaten oder die aktuelle svn version verwenden.

[Shojo]

...tendenziell fände ich es besser, wenn sich ein anderer (Haupt-) Verantwortlicher fände (Shojo, wie wäre es?).

Ja würde ich machen, muss mir das nur mal ansehen mit dem SVN, habe noch nie damit gearbeitet.

[Beta-User]

Ja würde ich machen, muss mir das nur mal ansehen mit dem SVN, habe noch nie damit gearbeitet.

svn ist nicht schwierig (kannte vorher git iVm. github, und empfinde svn als einfacher).

Den Zugangsantrag gibt's hier: https://svn.fhem.de/

Zu den templates selbst habe ich zwei (oder drei) Threads gestartet, da steht auch (hoffentlich) manches informative drin. Vieles zu dem, was möglich (und ggf. nicht so wünschenswert) ist, ist auch im Heizungssteuerungsbereich zum ebus@mqtt zu finden (schon ein kurzes Überfliegen sollte einen Eindruck geben).

Jendefalls: Willkommen an Bord!

[Shojo]

So der Rudi hat mich Freundlicherweise schon für das SVN freigeschaltet
Dann werde ich mal so schnell wie möglich etwas Zeit aufbringen um mich da einzuarbeiten.

[Shojo]

So @Beta-User ich hoffe das es so passen sollte, magst Du bitte nochmal dein Senf dazu geben?

Code Auswählen Erweitern


###########################################
# $Id: $
#
# Comments start with #. Empty lines are ignored.
# Syntax of one entry: name: line, one optional filter: line, zero or more par: lines,  FHEM-Commands
# filter:INTERNAL=VALUE (optional)
# par: name of the parameter; comment; perl_code (optional)
# perl_code returns a value for the parameter, or undef.
# If undef, the user has to specify them (the comment is shown to the user)


###########################################
# Eurotronic Spirit ZigBee (SPZB0001)
name:Eurotronic_SPZB0001_Spirit_ZigBee
filter:TYPE=HUEDevice
desc: All necessary attr are set and also a helper CMDAlias for the Eurotronic Spirit ZigBee thermostat.<br><a href="https://eurotronic.org/produkte/zigbee-heizkoerperthermostat/spirit-zigbee/">Manufacturer link: Klick me</a>
attr DEVICE configList /mode (.*)/:{"mode":"$1"}\
/heatsetpoint (.*)/:{"heatsetpoint": $1 }\
/displayflipped (.*)/:{"displayflipped": $1 }\
/locked (.*)/:{"locked": $1 }
attr DEVICE widgetOverride mode:auto,heat,off displayflipped:true,false locked:true,false heatsetpoint:16,16.5,17,17.5,18,18.5,19,19.5,20,20.5,21,21.5,22
attr DEVICE icon max_heizungsthermostat
defmod heatsetpointX100 cmdalias set .* heatsetpoint .* AS {fhem("set $EVTPART0 $EVTPART1 ". $EVTPART2 * 100)}
attr heatsetpointX100 comment This is an help CMDAlias for the Eurotronic Eurotronic Spirit ZigBee (SPZB0001).\
This CMDAlias prepares the value of heatsetpoint for the Hue/deCONZ API (multiplies the value by 100).


###########################################
# Xiaomi/Aqara MCCGQ11LM Fenster Tür Sensor
name:Xiaomi_Aqara_MCCGQ11LM_Window_Door_Sensor
filter:TYPE=HUEDevice
desc: The Xiaomi/Aqara temperature, humidity and pressure sensor is a multisensor, and is interpreted by ZigBee as three sensors that is temperature sensor.<br><a href="https://www.aqara.com/en/door_and_window_sensor-product.html">Manufacturer link: Klick me</a>
attr DEVICE devStateIcon open:fts_window_1w_open@#e56524 closed:fts_window_1w


###########################################
# Xiaomi/Aqara WSDCGQ11LM Temperatur Sensor
name:Xiaomi_Aqara_WSDCGQ11LM_Temperature_Sensor
filter:TYPE=HUEDevice
desc: The Xiaomi/Aqara temperature, humidity and pressure sensor is a multisensor, and is interpreted by ZigBee as three sensors that is temperature sensor.<br><a href="https://www.aqara.com/en/temperature_and_humidity_sensor-product.html">Manufacturer link: Klick me</a>
attr DEVICE icon xiaomi_multi
attr DEVICE stateFormat T: temperature °C

# Xiaomi/Aqara WSDCGQ11LM Pressure Sensor
name:Xiaomi_Aqara_WSDCGQ11LM_Pressure_Sensor
filter:TYPE=HUEDevice
desc: The Xiaomi/Aqara temperature, humidity and pressure sensor is a multisensor, and is interpreted by ZigBee as three sensors that is pressure sensor.<br><a href="https://www.aqara.com/en/temperature_and_humidity_sensor-product.html">Manufacturer link: Klick me</a>
attr DEVICE icon xiaomi_multi
attr DEVICE stateFormat P: pressure hPa

# Xiaomi/Aqara WSDCGQ11LM Humidity Sensor
name:Xiaomi_Aqara_WSDCGQ11LM_Humidity_Sensor
filter:TYPE=HUEDevice
desc: The Xiaomi/Aqara temperature, humidity and pressure sensor is a multisensor, and is interpreted by ZigBee as three sensors that is humidity sensor.<br><a href="https://www.aqara.com/en/temperature_and_humidity_sensor-product.html">Manufacturer link: Klick me</a>
attr DEVICE icon xiaomi_multi
attr DEVICE stateFormat H: humidity %


###########################################
# Xiaomi/Aqara RTCGQ11LM Motion Sensor
name:Xiaomi_Aqara_RTCGQ11LM_Motion_Sensor
filter:TYPE=HUEDevice
desc: The Xiaomi/Aqara motion sensor is a multisensor, and is interpreted by ZigBee as two sensors that is motion sensor.<br><a href="https://www.aqara.com/en/motion_sensor.html">Manufacturer link: Klick me</a>
attr DEVICE devStateIcon motion:people_sensor@#e56524 nomotion:people_sensor@lightgray
attr DEVICE icon motion_detector

# Xiaomi/Aqara RTCGQ11LM Lightlevel Sensor
name:Xiaomi_Aqara_RTCGQ11LM_Lightlevel_Sensor
filter:TYPE=HUEDevice
desc: The Xiaomi/Aqara motion sensor is a multisensor, and is interpreted by ZigBee as two sensors that is lightlevel sensor.<br><a href="https://www.aqara.com/en/motion_sensor.html">Manufacturer link: Klick me</a>
attr DEVICE icon IR
attr DEVICE stateFormat lux Lux

[justme1968]

@Shojo: wie wäre es statt set <name> lock true|false ein set <name> lock und set<name> unlock zu verwenden?

verwendet du eigentlich einen der sprachasaistenten? siri oder alexa?

@Beta-User: wir hatten ja vor einer weile schon mal über die templates dür die sprachasaistenten gesprochen. die idee war diesen teil mit wunder bedingung zu versehen die schaut ob es ein entsprechendes device in fhem gibt. geht das eigentlich schon? oder muss dafür noch etwas eingebaut werden?

[Shojo]

@Shojo: wie wäre es statt set <name> lock true|false ein set <name> lock und set<name> unlock zu verwenden?

Ja das finde ich gut,  werde ich ändern!

verwendet du eigentlich einen der sprachasaistenten? siri oder alexa?

Grade heute mit angefangen
(https://wiki.fhem.de/wiki/FHEM_Connector_für_Amazon_Alexa)

[Beta-User]

die idee war diesen teil mit wunder bedingung zu versehen die schaut ob es ein entsprechendes device in fhem gibt. geht das eigentlich schon? oder muss dafür noch etwas eingebaut werden?

Das mit option hatte Rudi damals m.E. eingebaut; hab's aber bisher nicht austesten "müssen".

magst Du bitte nochmal dein Senf dazu geben?

Here you are:

- Namen: würde nach wie vor ein Nummernsystem für die Namensanfänge gleich zu Anfang mit verwenden, also z.B. C_01_Eurotronic_SPZB0001_Spirit_ZigBee, D_01_Xiaomi_Aqara_MCCGQ11LM_Window_Door_Sensor, E_01a_Xiaomi_Aqara_WSDCGQ11LM_Temperature_Sensor, E_01b_Xiaomi_Aqara_WSDCGQ11LM_Pressure_Sensor...
- Comment zum Xiaomi_Aqara_MCCGQ11LM_Window_Door_Sensor paßt wohl nicht?

- den cmdalias würde ich eher in ein eigenes template aufnehmen, und in das "Basistemplate" nur per farewell den (optimalerweise klickbaren) Hinweis aufnehmen, dass man einen cmdalias anlegen sollte. (Klickbar=per HTTP-Anweisung gleich aufrufbar). Am Ende dann wieder ein farewell, das darauf hinweist, wie er zu verwenden ist (cmdalias: da ist evtl. nicht jedem user präsent, was es tut...)

- Farben: evtl. lieber unterschiedliche Symbole, dann ist das vom user verwendete Farbschema egal (z.B. people_sensor/message_presence für nomotion/motion)

- Evtl. kann man über die DEF des angesprochenen Devices via par ermitteln, welche anderen Devices dazu gehören? Dann könnte man z.B. gleich alle drei temp/pressure/hum-Devices mit einem template "erschlagen". Kann aber auch verwirren, dann ggf. lieber jeweils via farewell darauf hinweisen, dass man die anderen beiden Kanäle auch noch bearbeiten kann/sollte.

Konkretere Hilfe kann ich bei Bedarf erst Anfang nächster Woche geben...