HueDevice Update für Eurotronic Spirit ZigBee

Begonnen von Shojo, 13 Juni 2019, 21:43:20

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: Shojo am 27 Juni 2019, 10:16:17
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 :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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
FUIP

Beta-User

Zitat von: Thorsten Pferdekaemper am 17 Oktober 2019, 10:17:47
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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

justme1968

#63
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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Thorsten Pferdekaemper

Zitat von: justme1968 am 17 Oktober 2019, 10:42:59
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
FUIP

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

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
FUIP

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 :)
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

wuast94

#70
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 ?
Zigbee  Temp+Luftdruck+Humi Bewegungsmeldern Tür Kontakte, Klingel, TV, Denon, Schaltbare Steckdosen mit leistungsmessung, und weiteres

Homeassistant mit Nodered

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?
$readings{heatsetpoint} = $config->{heatsetpoint} * 0.01 if( defined ($config->{heatsetpoint}) );
ersetzten durch:
$readings{heatsetpoint} = sprintf("%.1f",$config->{heatsetpoint} * 0.01) if( defined ($config->{heatsetpoint}) );

Ich sage schon mal danke!

Gruß
Dennis
FHEM auf: Shuttle PC (x64) (Docker)
Bridge: SignalESP 433mHz, ConBee (deCONZ in Docker)
Rest: ESP8266, SONOFF, Sonos, Echo Dot, Xiaomi Vacuum (root), ESP RGBWW Wifi Led Controller, Node-RED, LEDMatrix, Pixel It

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

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

Zitat von: Shojo am 28 November 2019, 23:01:37
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?
$readings{heatsetpoint} = $config->{heatsetpoint} * 0.01 if( defined ($config->{heatsetpoint}) );
ersetzten durch:
$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