Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

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

[Asgothian]

@danny_v1 Deswegen ja die Sammlung der Nummern. Ich will denen vor Augen führen das es kein Problem von einem Thermostat ist.

A.

[danny_v1]

@Asgothian Ja das macht Sinn. Aber eine Änderung am Deconz Adapter oder am Rest-API müsste bestimmt dennoch erfolgen.

[Strberg]

@Asgothian
Ich habe nur ein Thermostat und das funktioniert nicht.
ET 200431 - 2238

[r0b1zZle]

@Asgothian
Eins das funktioniert: ET 200431 - 0470
Eins das nicht funktioniert: ET 200431 - 2120

Zwei weitere habe ich hier irgendwo noch rumzuliegen, da muss ich dann morgen nochmal nachschauen.

PS: Alle vier habe ich bei Amazon bestellt.

[Asgothian]

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

Eins das funktioniert: ET 200431 - 0470

Das funktioniert zu 100%, inclusive. dem Temperaturoffset ?

Gibt es irgend welche erkennbaren Unterschiede zwischen dem funktionierenden und dem nicht funktionierenden Thermostat ?

A.

[r0b1zZle]

@Asgothian Ja, das funktioniert. Kann alles ändern. Heute habe ich noch die anderen beiden getestet:

ET 200431 - 2256 --> funktioniert nicht
ET 200431 - 0993 --> funktioniert nicht

Keine erkennbaren Unterschiede. SW Build ID bei allen: 22190930 und Date Code: 20191014 auch bei allen gleich. Ansonsten ist alles identisch.

[danny_v1]

ET200431-1029 -> funktioniert nicht
ET195031-0231 -> funktioniert
ET195031-0209 -> funktioniert

[danny_v1]

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

@Asgothian Ja, das funktioniert. Kann alles ändern. Heute habe ich noch die anderen beiden getestet:

ET 200431 - 2256 --> funktioniert nicht
ET 200431 - 0993 --> funktioniert nicht

Keine erkennbaren Unterschiede. SW Build ID bei allen: 22190930 und Date Code: 20191014 auch bei allen gleich. Ansonsten ist alles identisch.

Wie sehen die Befestigungsmuttern aus eine fein geriffelt und das andere grob?

[Asgothian]

@danny_v1
der Thermostat der bei mir nicht funktioniert hat eine feine Riffelung. Ich denke für Diskussionen mit dem Hersteller sind die ET Nummern aber besser

[danny_v1]

@Asgothian ja klar sind die ET Nummern besser, wollte nur wissen ob das mit den Muttern auch immer so ist. Oder ob das kein richtiges Unterscheidungsmerkmal ist.

[r0b1zZle]

@danny_v1 Hast du ein Vergleichsfoto, damit ich sehe, was du meinst? Ansonsten sehe ich auf den ersten Blick keinen Unterschied.