How-To: Eurotronic Spirit Zigbee mit Conbee II

[danny_v1]

@Strberg Kannst Du das auch direkt über iobroker setzen im Datenpunkt? In der Anleitung die ich benutzt hab steht auch der curl Befehl drin mit dem es über Rest-API klappten sollte. Den könnte man ja dann über ein Skript setzen.

[Strberg]

@danny_v1 Wenn ich den Datenpunkt im iobroker setze, ansieht es zwar so aus, als würde der Wert übernommen werden, aber am Display des Thermostats bleibt der alte Wert eingestellt und nach ein paar Minuten wird auch im iobroker wieder Wert, der auf dem Thermostat eingestellt ist, angezeigt.

Über die Deconz Software ändert sich der Wert auf dem Thermostatdisplay sofort, also muss es doch irgendwie möglich sein den Wert zu setzen.

[danny_v1]

@Strberg Versuchs mal mit:

curl -X PUT -d '{"heatsetpoint":1700}' http://localhost/api/<API-KEY>/sensors/<ID>/config

über die konsole oder so. (1700 sind 17°C, <API-KEY> steht im deconz Adapter und <ID> ist die Nummer des Thermostat im deconz.0 Ordner. Wenn das geht könntest Du dir dann ein kleines Blockly zusammen bauen um den Wert zu setzen.

[Strberg]

@danny_v1 Das hatte ich schon versucht. Die API wird hier wohl genau so angesprochen, wie es der deconz Adapter im iobroker tut. Das Verhalten ist das gleiche. Der Datenpunkt im iobroker wird verändert, das Thermostatdisplay zeigt keine Änderung und nach einer Weile wird der Wert wieder vom Thermostat überschrieben auf den Wert, der auf dem Thermostat eingestellt ist.

Die Frage war eher, ob ich über die Rest API irgendwie direkt das Attribut 0x0012 zugreifen kann.

Das Problem scheint aber inzwischen auch bei anderen aufgetaucht zu sein. Im GitHub gibt es einen thread dazu. Ich weiß nicht, ob ich den Link dazu posten darf.
(GitHub->Dresden-Elektronik->deconz-Rest-plugin ->[Device Support Request] Eurotronic Spirit ZigBee #1098

[Asgothian]

@Strberg sagte in How-To: Eurotronic Spirit Zigbee mit Conbee II:

@danny_v1 Das hatte ich schon versucht. Die API wird hier wohl genau so angesprochen, wie es der deconz Adapter im iobroker tut. Das Verhalten ist das gleiche. Der Datenpunkt im iobroker wird verändert, das Thermostatdisplay zeigt keine Änderung und nach einer Weile wird der Wert wieder vom Thermostat überschrieben auf den Wert, der auf dem Thermostat eingestellt ist.

Die eigentlichen Fragen sind:

• Wenn du den Wert am Thermostat verstellst, ändert sich dann der Wert im ioBroker ?
• Wenn du per deconz GUI versuchst den Wert anzupassen, wird er dann geändert ? (Nachtrag: Um den Wert anzupassen solltest du im "Thermostat" Cluster den "occupied heating set point" anpassen. Die Anzeige des Thermostates sollte sofort umspringen, auch wenn der Wert im ioBroker sich erst nicht ändert)

Ich habe zu Testzwecken das bei mir gestern konfiguriert und bisher damit keine Probleme.

Die Frage war eher, ob ich über die Rest API irgendwie direkt das Attribut 0x0012 zugreifen kann.

Nein, das wird meines Wissens nicht nach aussen gegeben

Das Problem scheint aber inzwischen auch bei anderen aufgetaucht zu sein. Im GitHub gibt es einen thread dazu. Ich weiß nicht, ob ich den Link dazu posten darf.
(GitHub->Dresden-Elektronik->deconz-Rest-plugin ->[Device Support Request] Eurotronic Spirit ZigBee #1098

Warum solltest Du den Link nicht posten dürfen ? Ich mach das immer.

A.

[Strberg]

@Asgothian sagte in How-To: Eurotronic Spirit Zigbee mit Conbee II:

Die eigentlichen Fragen sind:

• Wenn du den Wert am Thermostat verstellst, ändert sich dann der Wert im ioBroker ?

Ja, nach ein paar Minuten ändert sich der Wert im iobroker auf den Wert, den ich am Thermostat eingestellt habe.

• Wenn du per deconz GUI versuchst den Wert anzupassen, wird er dann geändert ? (Nachtrag: Um den Wert anzupassen solltest du im "Thermostat" Cluster den "occupied heating set point" anpassen. Die Anzeige des Thermostates sollte sofort umspringen, auch wenn der Wert im ioBroker sich erst nicht ändert)

Ja das klappt, auch im iobroker wird der neue Wert dann sofort angezeigt. Nur wenn ich versuche, den Wert aus dem iobroker heraus zu schreiben, klappt das nicht.

Warum solltest Du den Link nicht posten dürfen ? Ich mach das immer.

Ich bin neu hier im Forum und habe die Regeln ehrlich gesagt nicht wirklich gelesen. Hier der Link:
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098

micha91 created this issue in dresden-elektronik/deconz-rest-plugin

closed [Device Support Request] Eurotronic Spirit ZigBee #1098

[danny_v1]

@Strberg Weiß ja nicht ob man irgendwie auf die Firmware zugreifen kann, also die Version von den funktionierenden auslesen und die Version dann irgendwie auf die nicht funktionierenden zu spielen.

[Strberg]

@danny_v1 Bisher sind keine Flashfiles für das Thermostat im Umlauf. Aber ich denke derzeit muss man abwarten, wie sich die sache entwickelt. Im GitHub Thread wird nach einer Lösung für das Problem gesucht. Im Prinzip müsste sich das ja über die deconz Rest-Api regeln lassen. Derzeit scheint das Hauptproblem zu sein, die beiden Thermostatversionen zu unterscheiden, weil beide identische Werte im Basic-Cluster zurückgeben.

[danny_v1]

@Strberg Gut dann heißt es also abwarten und ggf. die nicht funktionierenden Thermostate zurückschicken. Hab bis jetzt auch noch keine Antwort auf meine Anfrage bei Eurotronic erhalten

[r0b1zZle]

Ist es denn nicht möglich, via REST-Api den Wert (Occupied Heating Setpoint --> 0x0012) händisch zu schreiben? Der Deconz-Adapter schreibt den Heatsetpoint offenbar in die "falsche" Adresse (Current Temperature Setpoint --> 0x4003), denn bei den anderen Firmware-Versionen hat das funktioniert (habe selber eins, bei dem es funktioniert, in 0x4003 zu schreiben (damit auch im Deconz-Adapter)). Bei den anderen Thermostaten kann ich nur händisch im Deconz-Gui den Thermostatwert via 0x0012 ändern.

Via REST-Api-Chrome-Plugin sehe ich in der Config nur den "Heatsetpoint" und hier schreibt er offenbar leider in die 0x4003 rein. Hat jemand schon eine Lösung?

[Asgothian]

@r0b1zZle Nein, das ist nicht möglich. Die restAPI stellt die Datenpunkte zur Verfügung und die Umsetzung auf die Datenpunkte des Thermostaten sind in der Software fest codiert.

A.

[r0b1zZle]

@Asgothian Dazu habe ich die entsprechende *.cpp gefunden (hier).

Im Code steht folgendes:

case 0x0012: // Occupied Heating Setpoint
            {
                if (sensor->modelId().startsWith(QLatin1String("SPZB"))) // Eurotronic Spirit
                {
                    // Use 0x4003 instead.
                }
                else
                {
                    qint16 heatSetpoint = attr.numericValue().s16;
                    item = sensor->item(RConfigHeatSetpoint);
                    if (item && item->toNumber() != heatSetpoint)
                    {
                        item->setValue(heatSetpoint);
                        enqueueEvent(Event(RSensors, RConfigHeatSetpoint, sensor->id(), item));
                        configUpdated = true;
                    }
                }
                sensor->setZclValue(updateType, ind.srcEndpoint(), THERMOSTAT_CLUSTER_ID, attrId, attr.numericValue());
            }

Das heißt, dass er die Bezeichnung "SPZB" abfragt und dann in 0x4003 schreibt. Wenn ich jetzt einfach die if-Abfrage rausnehmen würde, müsste es klappen, weil alles notwendige bereits implementiert ist. Frage ist, wo liegt die *.cpp und muss ich das neu kompilieren?

[Asgothian]

@r0b1zZle sagte in How-To: Eurotronic Spirit Zigbee mit Conbee II:

Frage ist, wo liegt die *.cpp und muss ich das neu kompilieren?

• Wo liegt es - bei deconz im GitHub
• Musst du das kompilieren: ja. Anleitung gibt es auch bei deconz.

A.

[r0b1zZle]

@Asgothian Bin dabei, habe erfolgreich kompiliert und rüber geschoben. Jetzt reboot und dann testen. Ich melde mich. Bei Bedarf reiche ich gleich eine Anleitung dazu nach.

[Strberg]

@r0b1zZle wenn das funktioniert, wäre ich an einer Anleitung sehr interessiert!

[r0b1zZle]

Also, es ist leider doch nicht ganz so einfach. Ich hoffe, dass nach dem Überschreiben der Binaries des Rest-Api-Plugins nicht noch ein weiterer Schritt notwendig ist, damit die API die neuen Binaries nutzt (habe jetzt einfach immer den Raspi rebootet). Denn es ändert sich einfach gar nichts, egal was ich im Code ändere. Leider kann man das auch nicht debuggen. Muss ich mich die Tage noch einmal ran setzen und genau schauen, was da los ist.

[r0b1zZle]

Mittlerweile bin ich überfragt, was das Problem ist. Ich kann den kompletten Code löschen, kompilieren, die Binaries vom REST-Plugin überschreiben, neustarten und trotzdem kann ich mit der REST-Api das eine Thermostat weiterhin ganz normal steuern. Irgendwie kommen die Änderungen nicht an und ich weiß nicht warum. Vielleicht findet sich hier ja jemand, der genau weiß, was zu tun ist. Ich kann leider auch nur raten und ausprobieren, für mehr reicht meine Kenntnis leider nicht aus. Sorry

PS: Scheinbar muss man nach jeder Änderung das Thermostat wieder neu anlernen, damit die Änderungen wirksam werden. Außerdem ist mir aufgefallen (wurde auch hier diskutiert), dass man jeden einzelnen Eintrag in den jeweiligen Clustern des Thermostats separat per Hand noch einmal auslesen muss. Jetzt steht auch ein sinnvoller Wert in "swversion" drin, wo vorher gar nichts stand. Ich teste weiter

[danny_v1]

@Strberg Ich hab mir mal den Issue bei Git-Hub angesehen, und kann das bestätigen. Der Deconz Adapter schreibt auf den Parameter 0x4003, das funktioniert auch bei den alten Thermostaten (bunte Verpackung) bei den neuen ist der Parameter nicht mehr beschreibbar. Es müsste der Parameter 0x0012 beschrieben werden, dieser wird dann auch auf den 0x4003 umkopiert. Den Parameter 0x0012 funktioniert auch bei beiden Versionen!!!

Ich denke das sollt für die Entwickler vom Deconz Adapter keine große Sache das anzupassen und dann würden beide Versionen des Thermostates funktionieren.

[Strberg]

@danny_v1 Mein Verständnis ist, dass der deconz adapter auch nur die Rest-API anspricht. In der API gibt es den Wert "heatsetpoint" und der ist für Eurotronic Thermostate auf das Attribut 0x4003 gemappt. Die Änderung müsste also in der API erfolgen und nicht im Adapter.

[danny_v1]

@Strberg OK, da kenn ich mich leider gar nicht aus, war nur so meine Vermutung mit dem Adapter. Gibt es jemanden der das anpassen kann, bzw an wen kann man sich da wenden?