Weihnachtsangebot 2025! 🎄

[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

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

[Asgothian]

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

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.

Du hast da durchaus recht. Das lässt sich einfach anpassen. Allerdings ist damit nicht alles gut. Es sind noch weitere Datenpunkte von dem Problem betroffen:

• local_temperature_calibration
• spz_system_mode
• trv_system_mode

A.

[r0b1zZle]

@Strberg Genau das habe ich probiert (thermostat.cpp in der Rest-Api angepasst, neu kompiliert, Plugin überschrieben, Thermostat neu angelernt). Leider kann ich das nicht wirklich durchdebuggen, um genau zu sehen, wo das Problem ist.

Unteranderem existieren diese switch cases in der thermostat.cpp:

            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());
            }
                break;

und

            case 0x4003: // Current temperature set point
            {   // this will be reported when manually changing the temperature
                if (zclFrame.manufacturerCode() == VENDOR_JENNIC && sensor->modelId().startsWith(QLatin1String("SPZB"))) // Eurotronic Spirit
                {
                    qint16 heatSetpoint = attr.numericValue().s16;
                    item = sensor->item(RConfigHeatSetpoint);
                    if (item)
                    {
                        if (updateType == NodeValue::UpdateByZclReport)
                        {
                            stateUpdated = true;
                        }
                        if (item->toNumber() != heatSetpoint)
                        {
                            item->setValue(heatSetpoint);
                            enqueueEvent(Event(RSensors, RConfigHeatSetpoint, sensor->id(), item));
                            stateUpdated = true;
                        }
                    }
                }
                sensor->setZclValue(updateType, ind.srcEndpoint(), THERMOSTAT_CLUSTER_ID, attrId, attr.numericValue());
            }
                break;

Die "attrId" enthält entweder 0x0012 oder 0x4003 in diesem Fall. Ich habe im ersten case die if / else weggeschmissen und im zweiten case die attrId per bruteforce auf 0x0012 gesetzt (in der setZclValue). Leider hat dies noch nicht den gewünschten Effekt gehabt. Immerhin, wenn ich beide cases rausschmeiße, wird gar nichts mehr aktualisiert (was ja auch so sein sollte).

Zur Info:
Die THERMOSTAT_CLUSTER_ID ist der Block 0201, der ist fix und auch korrekt. updateType bezeichnet den Fall, ob die Werte an der jeweiligen Stelle gelesen oder beschrieben werden sollen. Die attr.numericValue ist dann der eigentliche Wert. Hier habe ich noch überlegt, ein eigenes attr zu erstellen und nicht im ersten Case 0x0012 zu lesen, sondern 0x4003. Aber bislang kam ich noch nicht dazu, das zu testen. Ansonsten wüsste ich nicht weiter.

Habt ihr noch Ideen?

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

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

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.

Du hast da durchaus recht. Das lässt sich einfach anpassen. Allerdings ist damit nicht alles gut. Es sind noch weitere Datenpunkte von dem Problem betroffen:

• local_temperature_calibration
• spz_system_mode
• trv_system_mode

A.

Die Werte sind mir erst mal egal, weil ich das ganze eh via Script mittels ioBroker steuern wollte. Aber dafür findet sich sicher auch noch etwas.

[Asgothian]

@r0b1zZle @danny_v1 @Strberg

Ich hab mir zum Testen noch einen Thermostat besorgt und der zeigt das gleiche Verhalten, sowohl am deconz als auch am Zigbee Adapter. Da ich mehrere funktionierende Thermostate besitze habe ich mir diese mal genauer angeschaut, und bin auf eine Art "Seriennummer" der Thermostate gestossen (unter den Batterien versteckt eingelagert, ETxxxxxx - xxxx

Ich würde alle die nicht funktionierende Thermostate besitzen (bzw. auch funktionierende) diese ET Nummer zusammen mit der Info ob der thermostat geht oder nicht hier zu posten, damit ich damit an den Hersteller heran treten kann.

A

[danny_v1]

@Asgothian Ok, ich würde heute abend mal nach den Nummern schauen. Hatte den Hersteller auch schon mal angeschrieben und nach Infos der Firmware gefragt, was sich da genau geändert hat und welche davon der aktuelle Stand ist. Aber außer der Frage ob ich schon einen Reset durchgeführt habe kam da nichts zurück.