HueDevice Update für Eurotronic Spirit ZigBee

[Shojo]

Hi justme1968,

ich habe mal besten Wissen und Gewissen einen kleinen Patch für die 31_HUEDevice erstellt.

Es werden dadurch die Readings:

• heatsetpoint
• locked
• mode
• valve

für den Thermostaten Eurotronic Spirit ZigBee hinzugefügt, magst du das bitte mit ins Modul aufnehmen?

#Edit:

So habe nun leider merken müssen das meine Perl Skills hier nicht für ausreichend sind....
Darum bitte ich dich das Device auch Steuerbar aufzunehmen 

Hier der API Call des Thermostaten

Code Auswählen Erweitern


    "config": {
        "battery": 100,
        "displayflipped": null,
        "heatsetpoint": 3000,
        "locked": false,
        "mode": "auto",
        "offset": 0,
        "on": true,
        "reachable": true
    },
    "ep": 1,
    "etag": "b0268276c423ea602c3dfeae7a653df9",
    "manufacturername": "Eurotronic",
    "modelid": "SPZB0001",
    "name": "SPZB0001",
    "state": {
        "lastupdated": "2019-06-13T20:45:32",
        "on": true,
        "temperature": 2247,
        "valve": 251
    },
    "swversion": "20181205",
    "type": "ZHAThermostat",
    "uniqueid": "00:15:8d:00:01:92:2c:bf-01-0201"
}

Als zusätliche Readings wären folgende interessant:

- displayflipped * [true|false]
- heatsetpoint * [500 - 3000] (bei den Wert wäre ein  *100 schön)
- locked * [true|false]
- mode * ["auto","heat","off"]
- valve [0-255] (auch hier wäre % ganz nett   ceil((100/255) * $state->{valve}))

die mit  * versehende Readings sollten auch über sein Set setzbar sein.

Hoffe mit den Infos kann man was anfangen.

Gruß
Dennis

[justme1968]

zur anzeige: ist in deinem patch alles (bis auf den wertebereich) drin um die readings anzuzeigen?

zum setzen: kannst du das device über das json kommando des device bzw. das setsensor Kommando der bridge steuern? wenn ja: du kannst dir die set kommandos selber über das setList attribut zusammen bauen.

[Shojo]

zur anzeige: ist in deinem patch alles (bis auf den wertebereich) drin um die readings anzuzeigen?

Ich werde gleich noch ein neuen patch erstellen, da dort noch nicht alles drinnen ist.

zum setzen: kannst du das device über das json kommando des device bzw. das setsensor Kommando der bridge steuern? wenn ja: du kannst dir die set kommandos selber über das setList attribut zusammen bauen.

Nein das geht nicht, ich muss über die Bridge configsensor nutzen.

#Edit:
So den Patch für die Readings hinzugefügt  

[justme1968]

Nein das geht nicht, ich muss über die Bridge configsensor nutzen.

das ist komisch. setList und json benutzen intern configsensor und reichen nur die parameter durch. bitte versuch mal raus zu finden was genau nicht geht.

[Shojo]

das ist komisch. setList und json benutzen intern configsensor und reichen nur die parameter durch.

Wenn ich mich nicht vertue nutzt json doch setsensor und nicht configsensor, oder?

Und wenn ich versuche eine setList zu definieren kommt der Fehler im Popup:
BU.Sensor.Thermostat is not a CLIP sensor device

[justme1968]

Wenn ich mich nicht vertue nutzt json doch setsensor und nicht configsensor, oder?

du hast natürlich recht. ist schon lange her das ich das gebaut habe.

Und wenn ich versuche eine setList zu definieren kommt der Fehler im Popup:
BU.Sensor.Thermostat is not a CLIP sensor device

bei phillips ist/war das setzen der werte nur für CLIP sensoren vorgesehen.

schmeiss mal die zeile 1591 mit der prüfung raus und schau ob es dann geht.

wenn wir die set kommandos auch laufen haben checke ich alles ein.

[Shojo]

schmeiss mal die zeile 1591 mit der prüfung raus und schau ob es dann geht.

Ja jetzt kann ich das setList setzten, allerdings habe ich nun wieder das Problem das hier anscheinend wieder setsensor genutzt wird.

Hier die Meldung:
parameter, mode, not available

Das setlist:
attr BU.Sensor.Thermostat setList mode:{"mode":"auto"}

[justme1968]

probiere mal die angehängte version:

- es gibt zusätzlich zu setList jetzt auch configList. die syntax ist identisch, geht aber über configsensor

- im json kommando kann man als ersten parameter optional jetzt auch setsensor oder configsensor vor dem json code angeben. also: set <name> json [setsensor|configsensor] <json>

[Shojo]

Ja sehr cool das funktioniere
Danke!

Jetzt habe ich aber noch eine Frage, habe ich die Möglichkeit mit der configList eine Auswahlliste zu generieren das ich z.B. eine Mode wählen kann?
Bzw auch ein Wert übergeben kann ?
Wie z.B.  heatsetpoint:{"heatsetpoint":$value}

[justme1968]

das sollte mit widgetOverride gehen.

wenn du parameter übergeben willst musst du aber daran denken den teil vor dem Doppelpunkt als regex mit /.../ anzugeben damit die parameter mit matchen.

beides zusammen gibt dann etwas in der art:

Code Auswählen Erweitern

attr <name> configList /mode (.*)/:{mode: $1}
attr <name> widgetOverride mode:manual,auto

[Shojo]

OK, das klappt auch super 

habe jetzt noch die Möglichkeit dort zu rechnen?
z.B.

Code Auswählen Erweitern

/heatsetpoint (.*)/:{"heatsetpoint": ($1 *100)}

[justme1968]

nein. das geht leider nicht direkt. im json teil werden nur $1 - $3 per suchen und ersetzen ausgetauscht.


du kannst aber mit cmdalias eine zwei stufige variante bauen. im cmdalias kannst du rechnen und gibst das ergebnis dann ans configList kommando weiter.


wenn du dann so weit bist das alles geht:
- mach bitte noch mal einen patch fertig
- zeig deine komplette konfiguration damit wir sie ins wiki stecken können
- idealer wäre es wenn die kommandos so ähnlich wie möglich zu hm thermostaten werden.
  dann werden sie von alexa und siri auch gleich erkannt ohne das ein grosses homebridgeMapping nötig ist

[justme1968]

wenn wir das ganze in ein AttrTemplate wäre das auch nicht schlecht.

[Shojo]

Ja ich werde mal versuchen das Modul zu erweitern wie Du es bei den Hue Devices gemacht hast so das der Thermostat erkannt und angelegt wird.

[justme1968]

du musst garnichts erweitern. das geht alles über konfiguration.

[Shojo]

Achso ich dachte eher an so was wie 

Code Auswählen Erweitern

#Eurotronic Eurotronic Spirit ZigBee (SPZB0001)
'SPZB0001' => {name => 'Eurotronic Spirit ZigBee', type => 'ZHAThermostat' ,subType => 'thermostat',  icon => 'max_heizungsthermostat', },

usw

[justme1968]

achso. ja. das kann gerne rein.

[Shojo]

Die Infos werden leider nicht gezogen, ich finde mich leider nicht so gut in Perl ergo auch nicht so gut Modul zurecht.
Und finde daher nicht die Funktionen die dafür zuständig sind

[Shojo]

wenn wir das ganze in ein AttrTemplate wäre das auch nicht schlecht.

Habe dazu noch nicht viel zu finden können, sehe ich das richtig das die AttrTemplates im Modul hinterlegt werden müssen?

[justme1968]

nein. die template liegen in .../FHEM/lib/AttrTemplate

es gibt irgendwo einen thread dazu. kann gerade nicht schauen.

[Shojo]

OK, bastle grade an einer huedevice.template

Klappt auch wunderbar ABER das will nicht gehen

Code Auswählen Erweitern


attr DEVICE configList /mode (.*)/:{"mode":"$1"}\
/heatsetpoint (.*)/:{"heatsetpoint": $1 }\
/displayflipped (.*)/:{"displayflipped": $1 }\
/locked (.*)/:{"locked": $1 }

Ich habe immer nur den letzten Eintrag (in den Fall locked)

#Edit:
So das habe ich aktuell in der huedevice.template stehen:
(allerdings noch mit den oben beschriebenen Problem und auch das man das heatsetpoint * 100 nehmen müsste)

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

###########################################
# 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]

es könnte sein das es mit mehrzeiligen attributen noch probleme gibt.

ich meine Beta-User hat die meisten erfahrungen mit den templates. ich stupse ihn mal auf das problem hier.


das mit dem *100 müsste wie oben vorgeschlagen zweistufig über ein zusätzlichen cmdalias gehen. da kannst du rechnen. und dieser gibt es dann an das setList/configList kommando weiter

[Beta-User]

Moin zusammen,

willkommen in der Welt der attrTemplates . Ich lese erst mal mit bzw. versuche das Problem zu verstehen, ich kenne hue nämlich (noch) nicht, und habe keinen Schimmer, wie die Attribute wirken, die ihr da vergeben wollt.
Vielleicht wäre es evtl. mal einen Test wert, ob es an den mittleren Doppelpunkten liegt? Rudi hat für die diversen Parameter ja einen Such- und Ersetzungsmechanismus reingebastelt, der kommt evtl. durch die Doppelpunkte (oder die slashes) aus dem Tritt...

Also erst mal sowas:

Code Auswählen Erweitern

attr DEVICE configList /mode (.*)/{"mode":"$1"}\
/heatsetpoint (.*)/{"heatsetpoint": $1 }
Wenn das klappt, würde ich es dann mal mit escapen testen:

Code Auswählen Erweitern

attr DEVICE configList /mode (.*)/\:{"mode":"$1"}\
/heatsetpoint (.*)/\:{"heatsetpoint": $1 }

Wenn es das nicht ist: evtl. dasselbe mit den slashes testen?
Ich vermute aber fast, ihr kommt mit dem Quellcode bei AttrTemplate.pm besser klar als ich oder solltet Rudi mal kontakten, der hat viele Anregungen (in meinem Fall rund um JSON) schnell aufgegriffen und in klasse-einfache Lösungen umgestrickt . Ist sicher kein großes Problem, das hier ähnlich zu halten.

[Shojo]

Code Auswählen Erweitern


attr DEVICE configList /mode (.*)/:{"mode":"$1"}\
/heatsetpoint (.*)/:{"heatsetpoint": $1 }\
/displayflipped (.*)/:{"displayflipped": $1 }\
/locked (.*)/:{"locked": $1 }

Ich habe immer nur den letzten Eintrag (in den Fall locked)

Sorry hier habe ich mich etwas unverständlich ausgedrückt, das Problem ist hier nicht das attrTemplates!
Der Fehler tritt auch auf wenn ich das configList händisch setzte.

Moin zusammen,

willkommen in der Welt der attrTemplates . Ich lese erst mal mit bzw. versuche das Problem zu verstehen,...........

Willkommen in der Runde freue mich über die Anteilnahme

das mit dem *100 müsste wie oben vorgeschlagen zweistufig über ein zusätzlichen cmdalias gehen. da kannst du rechnen. und dieser gibt es dann an das setList/configList kommando weiter

Ich habe tatsächlich schon paar cmdalias am laufen bin nur am grübeln an welcher stelle ich das hier unterbringen könnte.... statt das heatsetpoint !?

Code Auswählen Erweitern


/heatsetpoint (.*)/\:{"heatsetpoint": $1 }


[justme1968]

wie genau setzt du das configList denn ?

zum cmdalias: du konfigurierst zwei kommandos. eines über configList wie oben, und ein zweites mit cmdalias das den übergebenen wert mit dem faktor multipliziert und dann damit das configList kommando aufruft.

[Shojo]

wie genau setzt du das configList denn ?

Genau wie oben beschrieben

Habe mal ein List erstellt: 

Code Auswählen Erweitern



Internals:
   DEF        sensor 50  IODev=deCONZ
   FUUID      5d039c94-f33f-7625-71a6-23836b235c099281
   FVERSION   31_HUEDevice.pm:0.195540/2019-06-05
   ID         S50
   INTERVAL   60
   IODev      deCONZ
   NAME       BU.Sensor.Thermostat
   NR         308
   STATE      Initialized
   TYPE       HUEDevice
   lastupdated 2019-06-18 19:52:18
   lastupdated_local 2019-06-18 21:52:18
   manufacturername Eurotronic
   modelid    SPZB0001
   name       SPZB0001
   on         1
   reachable  1
   swversion  20181205
   type       ZHAThermostat
   uniqueid   00:15:8d:00:01:92:2c:bf-01-0201
   READINGS:
     2019-06-18 20:29:55   battery         95
     2019-06-18 20:29:55   displayflipped  false
     2019-06-18 20:29:55   heatsetpoint    25.5
     2019-06-18 20:29:55   locked          false
     2019-06-18 20:29:55   mode            auto
     2019-06-18 20:29:55   reachable       true
     2019-06-18 21:52:18   temperature     24.17
     2019-06-18 21:52:18   valve           100
   helper:
     devtype    S
     reachable  0
     update_timeout 1
     configList:
       regex:
         HASH(0x5624d745d2f8)
     setList:
Attributes:
   IODev      deCONZ
   configList /mode (.*)/:{"mode":"$1"}
/heatsetpoint (.*)/:{"heatsetpoint": $1 }
/displayflipped (.*)/:{"displayflipped": $1 }
/locked (.*)/:{"locked": $1 }
   icon       max_heizungsthermostat
   room       HUEDevice
   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

Was auffällt ist halt

Code Auswählen Erweitern

configList:
       regex:
         HASH(0x5624d745d2f8)
und ich habe aber keine Ahnung was das sagen soll .

[justme1968]

zum configList attribut: hab den fehler gefunden war noch ein tippfehler beim auswerten der attribute.

mit der angehängten version sollte es gehen.

edit: ist inzwischen eingecheckt.

[Shojo]

Ja super, das klappt 

[justme1968]

na also

was fehlt noch zum einchecken?

[Shojo]

Bin grade noch mit den cmdAlias zugange, funktionier tut es aber gefallen tut es mir nicht .... 

Code Auswählen Erweitern

defmod c_setX100 cmdalias setX100 .* AS {my $newVal = $EVTPART2 * 100;; fhem("set $EVTPART0 $EVTPART1 $newVal");;}
attr c_setX100 room 9.1_CMDAlias

Da man immer  setx100 BU.Sensor.Thermostat heatsetpoint 21 eingeben muss.

Sonst hast du alles im letzten Diff.

[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...

[justme1968]

ich würde den cmdalias in diesem fall mit ins template stecken. er ist ja zwingend nötig damit man die temperatur in grad angeben kann statt in 100tel.

im json code kann ich ja leider nicht rechnen und die syntax umzustellen wird unhandlich da ich nicht einfach und sicher zwischen json und perl code unterscheiden kann. beide verwendend die gleichen geschweiften klammern an anfang und ende mit etwas dazwischen.


wenn das mit den bedingungen tatsächlich schon geht haben wir hier den perfekten anlass es auszuprobieren .

[rudolfkoenig]

Die AttrTemplate-Syntax dafuer ist prereq:XXX
Wenn XXX die Form {.*} hat, dann wird sie ausgewertet (und muss 1 zurueckliefern), sonst muss sie den Names eines Geraetes zurueckliefern, per devspec2array Syntax.
prereq wird beim FHEM-Start / { AttrTemplate_Initialize() } ausgewertet, und die Templates, bei denen prereq schiefgeht, werden aus der Liste entfernt.

[justme1968]

ich habe auch den tread mit den ursprünglichen ideen wieder gefunden: https://forum.fhem.de/index.php/topic,99195.0.html .

[Beta-User]

ich würde den cmdalias in diesem fall mit ins template stecken. er ist ja zwingend nötig damit man die temperatur in grad angeben kann statt in 100tel.

Dann eventuell ja, wobei dann für diesen Teil die Auswertefrage via prereq ggf. sinnvoll sein könnte; denn an sich sollte jedes neue Device einen "room" bekommen (hier m.E. optimalerweise den HUE-default), was aber nur dann "ok" ist, wenn der user noch nichts festgelegt hatte (so eine Auswertung macht die GeneralBridge im mqtt2.template-file, wenn ich mich recht entsinne), und eigentlich ist es auch sinnvoll, den user dann zum neuen Device zu leiten (also das anzuzeigen). Das ist einleuchtender, wenn es via post-Behandlung läuft (denke ich jedenfalls, das sind aber alles eher nebensächliche Geschmacksfragen, gebe ich gerne zu...).

Eventuelle Gedanken zum Aufbau der Sprachsteuerungstemplates würde ich ggf. in dem anderen Thread beisteuern... (im Moment fällt mir aber nix neues ein).

[Shojo]

Dann eventuell ja, wobei dann für diesen Teil die Auswertefrage via prereq ggf. sinnvoll sein könnte; denn an sich sollte jedes neue Device einen "room" bekommen (hier m.E. optimalerweise den HUE-default)

So z.B. ?

Code Auswählen Erweitern


....
par:DeviceRoom;Room of the Device.;{AttrVal("heatsetpointX100","room","HUEDevice" )}
....
attr heatsetpointX100 room DeviceRoom


und eigentlich ist es auch sinnvoll, den user dann zum neuen Device zu leiten (also das anzuzeigen). Das ist einleuchtender, wenn es via post-Behandlung läuft.

Und wie ist das umzusetzen ?

[justme1968]

ich habe eben eingebaut das man bei configList statt {...} als json code auch perl:{...} angeben kann. der perl code muss dann einen gültigen json string zurück geben. im perl teil kann man rechnen und spart so den cmdalias.

noch völlig ungetestet... vielleicht hats du kurz zeit dazu.

falls es geht baue ich es auch für setList ein.

edit 2019-06-27: ist jetzt eingecheckt.

[Shojo]

noch völlig ungetestet... vielleicht hats du kurz zeit dazu.

Huhu, gleich mal probiert!

Code Auswählen Erweitern

/heatsetpoint (.*)/:perl:{'{"heatsetpoint":' . $1 * 100 . '}'}
erzeugt den Fehler

Code Auswählen Erweitern

invalid value, 0, for parameter heatsetpoint

[justme1968]

es kann sein as die $X bei eval zurück gesetzt werden. nimm mal bitte $VALUE1 statt $1.

wenn das nicht hilft muss ich in schauen sobald zeit ist.

[Shojo]

nimm mal bitte $VALUE1 statt $1.

Ja das war es  \o\ \o/ /o/  nun geht es!
Sehr geil!

[Beta-User]

Und wie ist das umzusetzen ?

Mit einem Perl-Aufruf aus dem template heraus; DEVCID ist hier der Name des neuen Devices.
Aus dem Code zum A_00_MQTT2_CLIENT_general_bridge (Zeile 41 mqtt2.template):

Code Auswählen Erweitern

{ fhem "trigger $FW_wname JS:location.href='$FW_ME?detail=DEVCID'" if($cl && $cl->{TYPE} eq "FHEMWEB") }
(Credit goes to Rudi)

[Beta-User]

So z.B. ?

Code Auswählen Erweitern


....
par:DeviceRoom;Room of the Device.;{AttrVal("heatsetpointX100","room","HUEDevice" )}
....
attr heatsetpointX100 room DeviceRoom


(hatte ich erst überlesen...)
Im Prinzip ja, wobei ich mich bei allen par-Abfragen an Rudi's Vorarbeit orientiert hatte und grundsätzlich alle Parameter groß schreibe und den Unterstrich als ausschließliches Trennzeichen verwende; das vermeidet tendenziell auch versehentliches Überschreiben anderer Teile beim Ersetzen, man sieht m.E. einfach schneller, was passieren wird.

[justme1968]

sollte man das umleiten aufs device (und andere solche dinge) nicht jeweils in eine routine stecken die nur noch mit den nötigen parametern aufgerufen wird?

das macht die template files kleiner und übersichtlicher und macht auch spätere änderungen einfacher wenn sich in der verbindung zum frontend etwas ändert.

[Beta-User]

Hmm, in der Tendenz finde ich den Ansatz richtig, aber...:
- Zusätzliche Devices zu erstellen, sollte man möglichst soweiso vermeiden (s.o.)
- Das hier ist der 2. Fall, in dem das notwendig ist (neben ein paar ebus-templates, dieses Geräte-Thema erfordert aber mMn sowieso eine etwas intensivere Einarbeitung auf Userseite)
=> geringe praktische Relevanz
- Es ist jeweils eine Zeile pro Zusatzdevice. Kürzer wird es kaum (höchstens innerhalb der Zeile)- würde show (analog list) bei devspec, die nur ein Device erfaßt, auch nur das anzeigen, hätte ich "damals" diesen Befehl genommen. Da hier jetzt am Ende zwei Devices rauskommen, die ggf. noch nachzuarbeiten sind, könnte es sein, dass show hier die bessere Wahl wäre (zusammen mit einem post-Hinweis-Dialogfeld, was jetzt zu tun ist). (Da dieses Verhalten bei show mWn. gar nicht gewollt war mit der Anzeige des "vollen Programms", fällt das aber für obiges Problem weg; dieser Ablauf bei dem Bridge-MQTT2_DEVICE ist (und bleibt vermutlich) ein Spezialfall).

Aber wenn es was zentrales geben sollte, pflege ich das dann gerne ein...

[Shojo]

...
Das hier ist der 2. Fall, in dem das notwendig ist...
...

Durch die neue Möglichkeit jetzt auch Perl bei der configList einzusetzen, fällt hier zum Glück das zusätzlich Device weg

[justme1968]

ich habe die perl code variante für setList und configList eingecheckt.

[Beta-User]

Durch die neue Möglichkeit jetzt auch Perl bei der configList einzusetzen, fällt hier zum Glück das zusätzlich Device weg

Das ist dann der noch bessere Ansatz...

@justme1968: Danke übrigens noch für die Einladung, meinen Senf hier dazugeben zu düfen .
@Shojo: Vermutlich werde ich in Kürze noch einiges von dir lernen können . Wenn du dann mal etwas Erfahrung gesammelt hast mit dem attrTemplate-feauture, würde ich mich daher über Rückmeldungen zu "meinen" files freuen (wenn dir was auffällt...). das HUE-template-file scheint mir jedenfalls in sehr guten Händen zu sein .

[Thorsten Pferdekaemper]

Hi,
kann man bei den Teilen eigentlich die Ventilstellung auch direkt steuern?
...und hat jemand eine API-Doku für die Teile? Bei https://developers.meethue.com habe ich nicht wirklich was passendes gefunden.
Danke&Gruß,
   Thorsten

[Beta-User]

Hi,
kann man bei den Teilen eigentlich die Ventilstellung auch direkt steuern?
...und hat jemand eine API-Doku für die Teile? Bei https://developers.meethue.com habe ich nicht wirklich was passendes gefunden.
Danke&Gruß,
   Thorsten

Zumindest findet sich im Handbuch https://eurotronic.org/wp-content/uploads/2019/01/Spirit_ZigBee_BAL_web_DE_view_V9.pdf auf Seite 15 das "Set Valve Position" als RW-"Attribut". "An sich" sollte es also gehen, die Frage ist vermutlich aber, welche Implementierung das unterstützt (am ehesten geht da vermutlich was mit deCONZ, wenn es als HUEDevice laufen soll; ansonsten hättest du evtl. über zigbee2mqtt noch einen alternativen Zigbee-Weg, der "freier" ist).

@all: Da mir das HM-Zeug auch zunehmend auf den Zeiger geht, würde mich auch "präventiv" interessieren, wie man den Eurotronic eigentlich sinnvoll in FHEM einbindet? Scheinbar kann der "nur" die Solltemperatur von einer Zentrale empfangen, kennt aber selbst keine Zeitprogramme oä.. Das müßte man dann via Zentrale/FHEM vorhalten, also z.B. über WeekdayTimer uä.. Soweit korrekt?

[justme1968]

das template von shojo macht doch genau das. es konfiguriert das zugehörige hue device so das es die zusätzlichen kommandos für mode, temperatur, lock, unlock und display spiegel hat.

das sollte für die ventilposition genau so gehen wenn man den parameter irgendwo in der doku findet und er im json der bridge auftaucht.

das gilt für den betrieb an einer hue bridge. ich habe keine ahnung ob deconz diesen teil des hue api such implementiert hat.

[Thorsten Pferdekaemper]

das sollte für die ventilposition genau so gehen wenn man den parameter irgendwo in der doku findet und er im json der bridge auftaucht.

Die Ventilposition scheint mir bei den Teilen etwas besonderes zu sein. In der Doku steht, dass man die Ventilposition setzen kann, wenn das Ding im "Stellwertmodus" ist. Ich habe aber nicht gefunden, wie man diesen "Stellwertmodus" einschalten kann. Außerdem gibt es zwei Parameter für die Ventilposition: Eine, die man nur lesen kann und eine, die man nur setzen kann. D.h. selbst wenn die Ventilstellung im json auftaucht, kann man sie nicht unbedingt so einfach setzen.
Gruß,
   Thorsten

[justme1968]

ok.

da ich das ding selber nicht habe: der erste schritt wären mit verbose 5 zu schauen wie das json ausschaut.

taucht überhaupt etwas auf? wenn ja: ein parameter oder beide.

entspricht der mode den du meinst dem mode kommando aus dem template? wenn ja: vielleicht wäre es gut im template die liste der möglichen modes zu hinterlegen?

ich weiß nicht wie phillips das umwandeln des json aus dem api in das tatsächliche protokoll von und zum device macht. prinzipiell kann die json seite aber beliebig komplex und verschachtelt sein und mehr als einen wert und datentyp enthalten. d.h. von fhem seite sollte alles gehen wenn phillips es prinzipiell unterstützt.

[Thorsten Pferdekaemper]

Hi,
ja, man kann das im Prinzip erforschen, wenn man so ein Ding hat. Ich habe aber keins und frage das eher als Entscheidungsgrundlage, um herauszufinden, wodurch ich Homematic vielleicht mal ersetzen will.
Siehe auch hier:
https://forum.fhem.de/index.php/topic,104578.0.html
Danke&Gruß,
   Thorsten

[justme1968]

verstehe.

gefühlsmäßig würde sagen: vermutlich geht es. das ganze ist aber mehr oder weniger eine black box und du würdest dich von phillips abhängig machen. die könnten morgen entscheiden das sie keine 3rd party geräte mehr in der bridge unterstützen. oder nur noch eingeschränkt. oder ...

mit de wäre es etwas offener, ich weiß aber nicht ob das api es her gibt.


da ich nur fb heizung habe ist es prinzipiell einfacher selbst etwas zu basteln. ist ja alles hinter eine klappe versteckt und es gibt keine probleme mit stromversorgung, anfassen und aussehen

[Beta-User]

So wie ich das deCONZ-Konzept verstanden habe, müßte sich via xml-file "jedem" zigbee Gerät alles mögliche "beibringen" lassen. Es gibt einen github-Faden zu der Hardware, https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098, da ist aber bisher wenig von Ventilstellung zu lesen.

Muß aber zugeben, dass ich damit (deCONZ-xml-Konfiguration) bisher auch keine praktishen Erfahrungen habe. Der support von DE wird aber allgemein gelobt, vielleicht läßt sich darüber was in Erfahrung bringen?

[justme1968]

ja. der de support ist sehr gut.

das ,beibringen' per config file ist aber nur die eine hälfte des problems. damit wird das gerät ja erst mal nur innerhalb der deconz software/web interface steuerbar.

ich weiß nicht ob und welche auswirkung das auf die steuerbarkeit des gerätes über das api hat. darauf kommt es ja für fhem an.

ich vermute damit hat sich noch niemand beschäftigt.

[wuast94]

habe die thermostate dann gerade auch mal eingebunden bekommen und über "define Thermostat_Wohnzimmer HUEDevice sensor 24 IODev=deCONZ" in fhem erstellt.

wie sieht das Homebridge mapping dazu aus um es auch in homekit nutzen zu können?

und muss ich da noch mehr an attributen machen ?

[Shojo]

Hi justme1968,

Mir ist noch aufgefallen das ich bei meinen Patch "damals" das Reading heatsetpoint sehr ungünstig formatiere.
Der Standard bei Temperaturen im FHEM ist ja z.B. 20.0  und so wie ich 20 darstelle 

Magst du bitte noch die Änderung in der Zeile 1420 aufnehmen?

Code Auswählen Erweitern

$readings{heatsetpoint} = $config->{heatsetpoint} * 0.01 if( defined ($config->{heatsetpoint}) );
ersetzten durch:

Code Auswählen Erweitern

$readings{heatsetpoint} = sprintf("%.1f",$config->{heatsetpoint} * 0.01) if( defined ($config->{heatsetpoint}) );

Ich sage schon mal danke!

Gruß
Dennis

[justme1968]

habs geändert.

[Reinemann67]

Hallo Leute,

vielen Dank für die Arbeit !!!

Habe nun auch endlich einen zigbee spirit ans laufen bekommen !
Der Erste ließ sich nicht in deCONZ einbinden, der Zweite hat dann aber funktioniert.

Schöne Grüße
Reine

[popy]

Hi justme1968,

Mir ist noch aufgefallen das ich bei meinen Patch "damals" das Reading heatsetpoint sehr ungünstig formatiere.
Der Standard bei Temperaturen im FHEM ist ja z.B. 20.0  und so wie ich 20 darstelle 

Magst du bitte noch die Änderung in der Zeile 1420 aufnehmen?

Code Auswählen Erweitern

$readings{heatsetpoint} = $config->{heatsetpoint} * 0.01 if( defined ($config->{heatsetpoint}) );
ersetzten durch:

Code Auswählen Erweitern

$readings{heatsetpoint} = sprintf("%.1f",$config->{heatsetpoint} * 0.01) if( defined ($config->{heatsetpoint}) );

Ich sage schon mal danke!

Gruß
Dennis

Hallo Dennis.

Danke für deine Implementation.
Ich hätte auch vor vll. dieses Jahr meine Heizkörper damit auszurüsten und in deconz über conbee II an fhem anzubinden.

Hast du schon Erfahrungen zu folgenden Fragen:

• Stabilität mit deconz + fhem
• Stabilität insgesammt, also hängt sich das Teil mal auf oder so...
• Batterielebenszeit? Was verwendest du Alkali oder Akkus? Hätte vor die Dinger mit eneloop Akkus zu betreiben.

Danke
pOpY

[Shadow3561]

Moin,

Ich habe jetzt auch das Thermostat in FHEM eingebunden und bekomme auch regelmässig readings.

Jedoch bin ich nicht in der Lage die Soll-Temp über FHEM zu ändern.

Habe versucht herauszufinden wie das ganze funktioniert, scheitere aber kläglich.

Was ich herausfinden konnte ist, dass wenn ich in FHEM den heatsetpoint ändere, passiert am Thermostat nichts, auch in deconz kommt keine Änderung an.

Ändere ich am Thermostat die Temp, wird sie in FHEM und deconz aktualisiert.
Ändere ich in deconz die Temp, wird der Wert am Thermostat und FHEM ebenso aktualisiert.

Auf Welche Adresse wird der heatsetpoint-Wert von FHEM geschrieben?
oder wo kann ich die Adresse ändern?

Mit freundlichen Grüßen

[uwSH]

Guten Abend zusammen,

Habe hier zunächst auch mal den Zustand wie von @Shadow3561 beschrieben.
Thermostat in FHEM vorhanden, reading passt aber heatsetpoint nicht veränderbar. Auch ich kann über deconz den Wert variieren, was dann auch erfolgreich zum Thermostat übertragen werden kann, aber das krieg ich leider nicht über FHEM hin - auch wenn ich mich hier erst dem ganzen Thema nähere (sprich Annahme, dass Fehler vor der Tastatur ist mehr als berechtigt).

Gibt es hier irgendeinen Tip wie ich der Ursache auf den Grund gehen kann? Meine bisherigen Vermutungen gehen in die Richtung, dass ich den Parameter von einem reinen Reading in eine setzbare Größe umwandeln muss...?

Beste Grüße
Uli

[Intmic]

Hallo zusammen,

ich verwende ebenfalls diese Thermostate. Funktioniert soweit auch alles sehr gut. Aber wie kann ich in einem Dashboard den Ist-Wert für den Heatsetpoint anzeigen lassen? Bei mir stehe da nur 3?
Als Icon habe ich dieses hier gewählt. max_heizungsthermostat
Gibt es da eventuell ein passenderes?

Viele Grüße

[uwSH]

Hallo zusammen,

Nachdem ich nun nochmal etwas Zeit hatte und um den nächsten Nutzern weitere Infos zu geben:
Sobald man das Gerät anzeigen kann, kann man das attrTemplate "C_01_Eurotronic_SPZB0001_Spirit_ZigBee" auswählen, auch wenn das erstmal für mehr wie ein Heizkörpertermostat aussieht.

Das ermöglicht dann letztlich ein widgetOverride
(Im Event Monitor sieht das bei mir wie folgt aus:
Global global ATTR FBH_Kueche widgetOverride mode:auto,heat,off heatsetpoint:16,16.5,17,17.5,18,18.5,19,19.5,20,20.5,21,21.5,22,22.5,23,23.5,24,24.5,25,25.5,26 )

Dann nicht vergessen die Config zu speicher 

Sobald dies erfolgt ist, kann man den heatsetpoint als dropdown überschreiben und das wird auch erfolgreich an das Thermostat übermittelt. - DONE -

Auch wenn ich vom logischen Fluss eigentlich etwas anderes erwartet hätte: Wenn ich im deconz den Wert manipulieren möchte funktioniert das nämlich nicht über den heatsetpoint wert sondern über die Heat Variable.
Hier fehlen mir leider aktuell noch FHEM Skills um das im Template zu korrigieren - aber das kommt noch. Immerhin das Ding tut nun bei mir was es soll.

Herzlichen Dank an die Entwickler!

[Beam2FHEM]

Da Eurotronic den "Spirit Zigbee" wohl eingestellt hat, aber der "Eurotronic Comet Zigbee" die Nachfolge mit intern gleicher Modellbezeichnung übernommen hat, und die gleiche Funktionalität bietet, wollte ich mal fragen, ob es möglich wäre, das huedevice.template und 31_HUEDevice.pm um den Offset zu erweitern.

Mein momentan nach jedem Update händisch eingefügter Code:
huedevice.template

Code Auswählen Erweitern

###########################################
# 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>
order:C_01
par:ICON;ICON as set, defaults to max_heizungsthermostat;{ AttrVal('DEVICE','icon','max_heizungsthermostat') }
attr DEVICE configList /mode (.*)/:{"mode":"$1"}\
/heatsetpoint (.*)/:perl:{'{"heatsetpoint":' . $VALUE1 * 100 . '}'}\
/displayflipped (.*)/:{"displayflipped": $1 }\
/offset (.*)/:{"offset": $1 }\
lock:{"locked": true }\
unlock:{"locked": false }
attr DEVICE widgetOverride mode:auto,heat,off displayflipped:true,false heatsetpoint:5,16,16.5,17,17.5,18,18.5,19,19.5,20,20.5,21,21.5,22,22.5,23,23.5,24,24.5,25,26,32
attr DEVICE icon ICON
setreading DEVICE attrTemplateVersion Eurotronic_SPZB0001_Spirit_ZigBee_20211015

31_HUEDevice.pm

Code Auswählen Erweitern

#Eurotronic Spirit ZigBee (SPZB0001)
      $readings{heatsetpoint} = sprintf("%.1f",$config->{heatsetpoint} * 0.01) if( defined ($config->{heatsetpoint}) );
      $readings{locked} = $config->{locked}?'true':'false' if( defined ($config->{locked}) );
      $readings{displayflipped} = $config->{displayflipped}?'true':'false' if( defined ($config->{displayflipped}) );
      $readings{mode} = $config->{mode} if( defined ($config->{mode}) );
      $readings{offset} = $config->{offset} if( defined ($config->{offset}) );


[Beta-User]

ob es möglich wäre, das huedevice.template und 31_HUEDevice.pm um den Offset zu erweitern.

Moin.

Die Änderung in huedevice.template checke ich bei Gelegenheit mit ein, allerdings weiß ich nicht, ob es nicht sinnvoll wäre, @justme1968 direkt anzupingen, ob er das auch in HUEDevice mit eincheckt.

[Beam2FHEM]

Wäre schon besser, das auch im 31_HUEDevice zu ändern, sonst wird ja das Reading mit Wert gar nicht angezeigt.