Deconz-rest-plugin: [Demande d'assistance d'appareil] Eurotronic Spirit ZigBee

Intéressant! Je cherche toujours quelque chose comme ça, à un prix raisonnable.

Est-ce celui-ci : https://eurotronic.org/produkte/zigbee-heizkoerperthermostat/spirit-zigbee/ ? Où l'as-tu acheté? Je vois que Reichelt les vend pour 50,81 euros.

En effet, pas de _Bedienungsanleitung_ pour cet appareil sur leur site web. Est-il livré avec un manuel uniquement en français/espagnol/italien/polonais ou également en allemand et/ou en anglais ? (Je peux lire l'allemand, mais je ne l'écris pas bien).

Les spécifications mentionnent les transitions prises en charge (_Schaltzeiten_) par jour/semaine, suggérant que vous pouvez stocker un programme sur l'appareil. En regardant la spécification ZCL (6.2.2.2.3), il y a beaucoup plus d'attributs dans le cluster 0x0201 pour cela. Je pense que la première chose à faire est de les ajouter à general.xml, ainsi que les commandes pour définir/effacer/obtenir le calendrier. Je doute cependant que l'interface graphique de deCONZ puisse gérer un nombre variable de paramètres pour la commande set schedule.

@manup , la modélisation des horaires sera un beau défi pour le point /devices terminaison

Absolument, supposez que les attributs doivent être ajoutés dans le nouveau ResourceItems .

Un collègue a acheté le thermostat Eurotronic il y a quelques jours et souhaite également obtenir de l'aide sur deCONZ et homebridge-hue, nous allons faire quelques recherches pour obtenir plus d'informations.

Oui, c'est exactement celui-là. Je l'ai eu chez voelkner via amazon pour 41,97 euros. Le manuel imprimé décrit uniquement l'installation/le montage et est disponible en allemand et en anglais. J'espérais voir un peu plus la spécification du protocole comme dans le cas de la version zwave : https://eurotronic.org/wp-content/uploads/2018/08/Spirit_Z-Wave_BAL_web_DE_view_V5.pdf

Cependant, si je peux fournir d'autres journaux, je ferai de mon mieux pour le faire, mais pour le moment, je suis très occupé au travail et je ne veux pas fermer mon installation deCONZ pour obtenir des journaux clairs de l'appareil avant jeudi.

J'ai trouvé des informations selon lesquelles il utilise le profil domotique 1.2 et se présente comme un appareil HVAC...

Cela sera-t-il difficile et long à mettre en œuvre ? Si vous obtenez cela, alors deconz connecté à l'assistant à domicile peut être la meilleure solution zigbee sur le marché.

J'aimerais également obtenir homebridge-hue pour soutenir le groupe de thermostats.

Le groupe de thermostats 0x0201 est déjà pris en charge avec PR #1003.

En utilisant l'API REST, il est possible de modifier la température de chauffage, d'obtenir/définir le programmateur, d'activer/de désactiver le programmateur, de régler le décalage.

@ma-ca, j'aurai besoin d'aide pour ça. Cela va être difficile sans appareil à tester.

Le service HomeKit _Thermostat_ requiert les caractéristiques suivantes :

• _CurrentHeatingCoolingState_ (en lecture seule, valeurs : _Off_, _Heat_, _Cool_) - Je suppose que cela est fourni par state.on : false : _Off_; true : _Chaleur_ ?
• _TargetHeatingCoolingState_ (lecture/écriture, valeurs : _Off_, _Heat_, _Cool_, _Auto_) - Cela devrait probablement être mappé sur config.scheduleron ? Ou devrait-il être corrigé sur _Auto_ et exposer config.scheduleron tant que commutateur séparé ?
• _CurrentTemperature_ (lecture seule, en 0,1°C) - Ce serait state.temperature ?
• _TargetTemperature_ (lecture/écriture, en 0,1°C) - Ce serait config.heatsetpoint ?

Il existe également une caractéristique facultative _HeatingThresholdTemperature_.

Je ne saurais pas comment exposer le calendrier - Ils n'ont pas encore procédé à l'ingénierie inverse de l'interface pour Eve Thermo (voir https://github.com/simont77/fakegato-history/issues/11, https://github .com/simont77/fakegato-history/issues/40), mais je suppose que vous voudriez utiliser les règles deCONZ et/ou les automatisations HomeKit pour définir config.heatsetpoint ?

@ebaauw Je suis heureux que vous envisagiez cela et je suis heureux de vous aider.

CurrentHeatingCoolingState (lecture seule, valeurs : Off, Heat, Cool) - Je suppose que cela est fourni par state.on : false : Off; true : Chaleur ?

Oui, le state.on : true correspond au chauffage allumé. Le cool n'est (actuellement) pas implémenté dans l'API REST.

TargetHeatingCoolingState (lecture/écriture, valeurs : Off, Heat, Cool, Auto) - Cela devrait probablement être mappé sur config.scheduleron ? Ou doit-il être fixé sur Auto et exposer config.scheduleron en tant que commutateur séparé ?

Peut-être que oui. Comment s'affiche cette propriété dans HomeKit et quelle commande est associée ? Si cela est associé à la commande Siri _éteindre le thermostat_, il serait alors logique de désactiver le programmateur.

CurrentTemperature (lecture seule, en 0,1°C) - Ce serait state.temperature ?

Oui. Actuellement, la valeur de température doit être divisée par 100 comme défini dans la spécification Zigbee, par exemple state.temperature : 2150 est de 21,5 °C.

TargetTemperature (lecture/écriture, en 0,1°C) - Ce serait config.heatsetpoint ?

Oui, doit également être divisé par 100.

Je voudrais utiliser HomeKit pour définir config.heatsetpoint et config.scheduleron . Je ne vois aucun avantage à changer le planificateur à partir de HomeKit, car après avoir configuré le planificateur à l'aide de l'API REST, il n'est pas vraiment nécessaire de changer cela.

Dans mes cas d'utilisation, j'aimerais utiliser HomeKit pour

• éteindre le programmateur en partant en vacances
• puis pouvoir rallumer un jour _avant_ le retour à la maison.
• réglage de la température.

Veuillez consulter homebridge-hue v0.11.7.

Très agréable. Après avoir installé homebridge-hue v0.11.7, l'application iOS Home affiche les icônes _Thermostat_ avec la température et la valeur calorifique.

Changer le chauffage change le config.heatsetpoint . Activer ou désactiver le mode définit config.scheduleron sur vrai ou faux.

Le seul problème est que la température affichée semble être arrondie à 0,5 °C, mais l'affichage du thermostat a une résolution de 0,1 °C. Par exemple, l'application affiche 22,5 °C mais l'affichage a 22,3 °C et le state.temperature est 2230. Et la valeur calorifique a un décalage aléatoire, par exemple 17,0 °C change le config.heatsetpoint en 1710, valeur 17,5°C à 1770, valeur 18,0°C à 1800.

Pouvez-vous s'il vous plaît joindre le journal de débogage de homebridge-hue ? Et le fichier de vidage, juste pour être sûr. Voir le README. Utilisez-vous uniquement l'application Home d'Apple ou avez-vous consulté d'autres applications HomeKit. Je pense que Home arrondit la température à 0,5°C lors de l'affichage. C'est du moins ce que je vois pour mes capteurs de température.

[1/11/2019, 8:24:13 PM] [Hue] Phoscon-GW: 000D6F000C2B8B3D: Bitron Home 902010/32 "Thermostat 40"
[1/11/2019, 8:24:13 PM] [Hue] Phoscon-GW: /sensors/40: ZHAThermostat "Thermostat 40"
[1/11/2019, 8:24:15 PM] [Hue] Initializing platform accessory 'Thermostat 40'...
[1/11/2019, 8:25:06 PM] [Hue] Thermostat 40: homekit target temperature changed from 17.6 to 18.2
[1/11/2019, 8:25:06 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1820,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:25:15 PM] [Hue] Thermostat 40: homekit target temperature changed from 18.2 to 17.5
[1/11/2019, 8:25:16 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1750,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:25:34 PM] [Hue] Thermostat 40: homekit target temperature changed from 17.5 to 16.8
[1/11/2019, 8:25:34 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1680,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: homekit target temperature changed from 16.8 to 16.3
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: set homekit target temperature from 16.3°C to 16.8°C
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1630,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: set homekit target temperature from 16.8°C to 16.3°C
[1/11/2019, 8:26:01 PM] [Hue] Thermostat 40: homekit target temperature changed from 16.3 to 15.8
[1/11/2019, 8:26:01 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1580,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:26:09 PM] [Hue] Thermostat 40: homekit target temperature changed from 15.8 to 14.9
[1/11/2019, 8:26:09 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1490,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:26:30 PM] [Hue] Thermostat 40: homekit target temperature changed from 14.9 to 13.7
[1/11/2019, 8:26:30 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1370,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:27:08 PM] [Hue] Thermostat 40: homekit target temperature changed from 13.7 to 12.7
[1/11/2019, 8:27:09 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1270,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:27:20 PM] [Hue] Thermostat 40: state changed event: {"lastupdated":"2019-01-11T19:27:20","on":false,"temperature":2220}

J'utilise uniquement l'application Apple Home.

Juste au cas où il y aurait une relation, au début, les icônes _Window Covering_ dans l'application Home avaient une résolution de 1% lorsqu'elles affichaient un état ouvert entre 0% et 100%. Plus tard, cela est passé à une résolution de 5%. Je pensais que cela avait été changé exprès dans homebridge-hue.

J'ai vraiment besoin de la sortie complète de homebridge -D , veuillez consulter https://github.com/ebaauw/homebridge-hue#debug -log-file.

J'utilise uniquement l'application Apple Home.

Quelles températures Eve ou une autre application HomeKit affiche-t-elle ?

Plus tard, cela est passé à une résolution de 5%. Je pensais que cela avait été changé exprès dans homebridge-hue.

Oui, j'ai trouvé que mon lumi.curtain ne signale pas toujours une position de 0 ou 254 lorsqu'il est complètement ouvert ou fermé. Même après le recalibrage, c'est parfois un peu décalé. J'ai contourné cela en arrondissant à des multiples de 5. Cependant, cela n'a aucun rapport avec le _Thermostat_.

Le fichier journal de débogage complet d'avant.

homebridge.log.gz

Quelles températures Eve ou une autre application HomeKit affiche-t-elle ?

L'application Eve affiche la température correcte avec une résolution de 0,1 °C. De plus, la température cible est traduite correctement lors de l'augmentation des pas de 0,5 °C.

Merci!

[1/11/2019, 8:25:06 PM] [Hue] Thermostat 40: homekit target temperature changed from 17.6 to 18.2 
[1/11/2019, 8:25:06 PM] [Hue] Phoscon-GW: gateway request 22: put /sensors/40/config {"heatsetpoint":1820}
[1/11/2019, 8:25:06 PM] [Hue] Phoscon-GW: gateway request 22: ok
[1/11/2019, 8:25:06 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1820,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:25:06 PM] [Hue] Thermostat 40: ignore unknown attribute config.scheduler

Cela s'annonce bien. Le thermostat passe de HomeKit à 18,2°C. homebridge-hue définit config.heatsetpoint sur 1820 et deCONZ émet une notification de socket Web avec le nouveau heatsetpoint. Je dois abandonner le message config.scheduler , cependant.

[1/11/2019, 8:25:48 PM] [Hue] Phoscon-GW: gateway request 50: get /sensors
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: homekit target temperature changed from 16.8 to 16.3
[1/11/2019, 8:25:48 PM] [Hue] Phoscon-GW: gateway request 51: put /sensors/40/config {"heatsetpoint":1630}
[1/11/2019, 8:25:48 PM] [Hue] Phoscon-GW: gateway request 50: ok
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: set homekit target temperature from 16.3°C to 16.8°C
[1/11/2019, 8:25:48 PM] [Hue] Phoscon-GW: gateway request 51: ok
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: config changed event: {"battery":100,"heatsetpoint":1630,"offset":0,"on":true,"reachable":true,"scheduler":"Monday,Tuesday,Wednesday,Thursday,Friday 04:00 2200 05:00 2300 06:00 1700 16:00 2300 17:00 2000 21:00 1800;Saturday,Sunday 06:00 2200 21:00 1800;","scheduleron":true}
[1/11/2019, 8:25:48 PM] [Hue] Thermostat 40: set homekit target temperature from 16.8°C to 16.3°C

La joie du traitement asynchrone. La température cible est mise à jour pendant que homebridge-hue interroge /sensors . homebridge-hue ramène HomeKit à la valeur précédente (récupérée du sondage), mais cela est corrigé lorsque homebridge-hue reçoit la notification de socket Web du changement par le put .

Et la valeur calorifique a un décalage aléatoire, par exemple 17,0 °C change le config.heatsetpoint en 1710, la valeur 17,5°C en 1770, la valeur 18,0°C en 1800.

Je ne vois pas ça. Dans les deux cas ci-dessus, homebridge-hue envoie la température correcte (jusqu'à 0,1°C) à la passerelle deCONZ, et la passerelle le confirme via la notification websocket. Je soupçonne que l'application Home pourrait également faire quelque chose d'amusant ici. J'ai revérifié que la _Température actuelle_ et la _Température cible_ ont une résolution de 0,1°C.

Quelques autres remarques :

[1/11/2019, 8:24:09 PM] [Hue] config.json: {"platform":"Hue","host":"127.0.0.1","users":{"00212EFFFF00893F":"*********1"},"sensors":true,"excludeSensorTypes":["CLIPPresence","Geofence"],"lights":true,"wallSwitch":true,"hueMotionTemperatureHistory":true}
[1/11/2019, 8:24:09 PM] [Hue] config.json: {"platform":"Hue","host":"192.***.***.252","users":{"001788FFFE12CA51":"***************************************1"},"sensors":true,"lights":true,"wallSwitch":true}

Vous avez spécifié deux plates-formes "Hue" dans config.json. Bien que cela fonctionne actuellement, il se brisera lors du passage aux accessoires de plate-forme dynamiques. Vous pouvez exposer à la fois le pont Hue et la passerelle deCONZ à partir d'une seule entrée en :

{
  "platform": "Hue",
  "hosts": ["127.0.0.1", "192.***.***.252"],
  "users": {
    "00212EFFFF00893F": "*********1",
    "001788FFFE12CA51": "***************************************1"
  }
}

Ah l'ubisys S2. J'attendais de voir le modèle complet S2 (5502) pour exposer le capteur ZHASwitch. Je peux lire les valeurs buttonevent de l'API deCONZ REST, mais pas le modèle complet. Obtenez-vous de bonnes valeurs pour consumption et power ? Mon D1 (exécutant une version ultérieure du firmware) donne des déchets pour ceux-ci.

[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: 001FEE000000170A: ubisys S2 (5502) "Light 1"
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /lights/1: On/Off output "Light 1"
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /lights/1: config: {"on":true,"bri":false,"ct":false,"xy":false,"wallSwitch":true,"windowCovering":false,"unknown":true}
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /lights/2: On/Off output "Light 2"
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /lights/2: config: {"on":true,"bri":false,"ct":false,"xy":false,"wallSwitch":true,"windowCovering":false,"unknown":true}
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /sensors/5: ZHAConsumption "Consumption 5"
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /sensors/6: ZHAPower "Power 6"
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /sensors/4: ZHASwitch "S2 (5502) 4"
[1/11/2019, 8:24:11 PM] [Hue] Phoscon-GW: /sensors/4: warning: ignoring unknown ZHASwitch sensor {"config":{"group":null,"mode":"momentary","on":true,"reachable":true},"ep":3,"etag":"423162415d68374a920ef22184c6c540","manufacturername":"ubisys","mode":1,"modelid":"S2 (5502)","name":"S2 (5502) 4","state":{"buttonevent":null,"lastupdated":"none"},"swversion":"20160302-DE-FB0","type":"ZHASwitch","uniqueid":"00:1f:ee:00:00:00:17:0a-03-0006"}

Note à moi-même : l'histoire d'Eve.

Veuillez vérifier homebridge-hue v0.11.8 qui devrait :

• N'émet plus de messages sur config.scheduler ;
• Fournir un historique dans Eve pour la température actuelle du _Thermostat_ et la température cible (voir https://github.com/ebaauw/homebridge-hue/issues/426) ;
• Prend en charge la fonction de commutation de l'ubisys S2 (voir https://github.com/ebaauw/homebridge-hue/issues/427).

Continuons la conversation sur le support de homebridge-hue aux problèmes de homebridge-hue.

Je voudrais ajouter l'appareil Eurotronic à la restAPI, mais il y a une erreur :

{ "config": { "on": true "reachable": true } "manufacturername": "Eurotronic" "modelid": "SPZB0001" "name": "Thermo WZ ET" "swversion": "20181205" "type": "ZHAThermostat" "uniqueid": "0x00158d0001922f50" }

[{ "error": { "address": "/sensors", "description": "Not allowed to create sensor type", "type": 501 } }]

Les dernières versions de deCONZ (2.05.54) et homebride-hue (v0.11.8) sont installées

@thommyDD s'il vous plaît essayez avec cette version intérimaire :)

https://www.dresden-elektronik.de/rpi/deconz/alpha/deconz-2.05.56-qt5.deb

Le thermostat doit être reconnecté pendant que la recherche de capteur est en cours.

@manup ça ne marche pas :(

J'ai réinitialisé le thermostat pendant la recherche du capteur, mais le thermostat n'a pas été trouvé.

Hmmm pas sûr de ce qui se passe. Je viens d'en commander un via Amazon devrait arriver lundi prochain.

C'est intéressant, s'abonner pour voir l'évolution ;-)

Je suis également tombé sur cet appareil récemment. La version Z-Wave a la particularité intéressante de supporter des capteurs de température externes (qui peuvent donner des lectures plus réalistes que l'interne).
Parmi ceux qui ont déjà l'appareil, savez-vous si cela est (ou sera) également possible via Zigbee ? Le site du fabricant est malheureusement très clairsemé.

Salut, j'ai aussi récemment eu cet appareil. Pour le moment, je ne peux définir que le point de consigne de chauffage occupé, qui est ensuite copié par l'appareil dans l'attribut Point de consigne de température actuel via deCONZ Gui. Ajouterez-vous également les attributs de planification à l'interface graphique deCONZ ? Comme je ne sais vraiment pas pour le moment, comment je ferais cela via l'API REST, car cela n'est pas à ma connaissance pour le moment. Serait très apprécié.

À votre santé

Lecture d'autres attributs du thermostat :

• Le capteur de température externe peut être pris en charge
• Les horaires ne sont pas pris en charge

Les horaires ne seront donc pas pris en charge par deCONZ pendant longtemps ?

En fait, il existe déjà un code horaire dans deCONZ, mais je ne peux pas le tester car le thermostat Eurotronic ne le prend pas en charge.

Il serait peut-être préférable de créer des règles pour imiter les horaires, ce qui est également plus puissant.

Comment créerait-on ces règles ? via l'API de repos ? ou existe-t-il une fonctionnalité dans deCONZ qui pourrait gérer cela ?

Actuellement, cela n'est possible que via REST-API. Ou peut-être en utilisant quelque chose comme Home Assistant et d'autres systèmes domotiques qui prennent en charge l'intégration deCONZ.

@manup Malheureusement, je
Y a-t-il une explication ?

Cela devrait mieux fonctionner avec la version 2.05.58 à venir, qui contient quelques correctifs connexes.

Solution de contournement pour 2.05.57 :

• Lancer la recherche de capteur
• Lire le cluster de base

Est-ce celui-ci : https://eurotronic.org/produkte/zigbee-heizkoerperthermostat/spirit-zigbee/ ? Où l'as-tu acheté? Je vois que Reichelt les vend pour 50,81 euros.

En effet, pas de _Bedienungsanleitung_ pour cet appareil sur leur site web. Est-il livré avec un manuel uniquement en français/espagnol/italien/polonais ou également en allemand et/ou en anglais ? (Je peux lire l'allemand, mais je ne l'écris pas bien).

Je leur ai demandé des détails par e-mail il y a quelque temps. Même s'ils n'ont pas répondu, ils viennent d'ajouter un manuel assez complet à leur site Web avec des détails sur les attributs Zigbee :
https://eurotronic.org/wp-content/uploads/2019/01/Spirit_ZigBee_BAL_web_DE_view_V9.pdf

J'ai l'un de ces thermostats, mais je n'arrive pas à le coupler correctement.
(Deconz sans tête sur rpi avec raspbee et deconz 2.05.58)
En suivant le lien de documentation dans le commentaire précédent, je peux mettre le thermostat en mode d'appairage et démarrer l'appairage du capteur sur l'application phoscon Après un court instant, le thermostat indique qu'il est appairé avec succès mais l'application phoscon. ne reconnaît jamais l'appariement.

Le thermostat considère définitivement l'appairage comme terminé. Afin de le remettre en mode d'appairage, je dois le réinitialiser complètement.

Des indices sur ce que je fais mal?

Des indices sur ce que je fais mal?

Je suppose que rien. Actuellement, le thermostat n'est pas visible dans l'application Phoscon mais il devrait être visible dans l'API REST.

C'est le problème - ce n'est pas visible lors de l'obtention de tous les objets du reste de l'API

Lors de ma première tentative de couplage via deCONZ GUI, l'appareil s'affichait, mais aucune des propriétés n'était lue, pas même l'ID du fabricant et aucun cluster ne s'affichait. Finalement, j'ai arrêté deCONZ, supprimé toutes les références à l'appareil du zll.db, réinitialisé l'appareil et couplé comme suit, _tout en le maintenant à côté du RasPi_.

• Lancer la recherche de capteurs dans Phoscon.
• Retirez/réinsérez les piles. Appuyez sur moins+plus+boost et maintenez-les enfoncés jusqu'à ce que l'appareil se réinitialise.
• Attendez que l'appareil s'apparie (voyant vert ; après environ 2 secondes), puis installez-le et laissez-le s'adapter.
• La recherche de capteur dans Phoscon avait échoué à ce moment-là, alors redémarrez-la.
• Accédez à l'interface graphique deCONZ, répertoriez les clusters, cliquez sur "Basic" -> "Read" (comme recommandé dans https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-457839093)
• Phoscon signale maintenant une recherche de capteur réussie et cela apparaît dans l'API REST.

Je ne sais pas laquelle des étapes a fonctionné, mais peut-être que cela aide.

En ce qui concerne les attributs, j'ai constaté que le réglage de "Mode TRV" (0x4000) sur "manuel" (2) contrôle l'appareil via le point de consigne (défini via 0x4003). Lorsque le mode est réglé sur "Inconnu 2", l'écran affiche le pourcentage d'ouverture de vanne actuel, qui peut être contrôlé avec 0x4001.

Aucune des autres options ne semble avoir d'effet, bien qu'il semble qu'il y ait des fonctionnalités cachées dans "Host Flags" (0x4008) (par exemple, j'ai réussi à activer la protection enfant...).

On ne sait pas non plus comment la « détection à distance » est censée fonctionner. Peut-être par liaison, avec un appareil qui dispose d'un cluster client « mesure de température » ?

Je confirme que ces étapes fonctionnent :

• Lancer la recherche de capteurs dans Phoscon.
• Retirez/réinsérez les piles. Appuyez sur moins+plus+boost et maintenez-les enfoncés jusqu'à ce que l'appareil se réinitialise.
• Attendez que l'appareil s'apparie (voyant vert ; après environ 2 secondes), puis installez-le et laissez-le s'adapter.
• La recherche de capteur dans Phoscon avait échoué à ce moment-là, alors redémarrez-la.
• Allez sur deCONZ GUI, listez les clusters, cliquez sur "Basic" -> "Read" (comme recommandé dans #1098 (commentaire))

J'ai pu coupler le thermostat et je peux le voir dans l'interface graphique de deconz, mais avec le nom 0x3BEE.
De plus, je ne le vois pas dans l'API. (demander GET /capteurs).

J'ai le mien aujourd'hui ! S'il s'avère que cela fonctionne de manière fiable, j'ai de la place pour sept autres...

Ce serait cool d'exposer la position de la vanne (comme state.bri ?). Eve Thermo rapporte cela également et j'espère pouvoir faire en sorte que homebridge-hue expose l'histoire à l'application Eve.

Dans HomeKit, un thermostat a un _Target Heating Cooling State_ (arrêt, chauffage, refroidissement, auto) et un _Current Heating Cooling State_ (arrêt, chauffage, refroidissement). Avec state.on dérivé de la position réelle de la vanne, l'état actuel est couvert. L'Eurotronic a-t-il un équivalent pour l'état cible ? J'avais l'habitude de mapper config.scheduleron à l'état cible, mais avec le dernier commit, ce n'est plus exposé (car, si je comprends bien, cela n'a rien fait pour l'Eurotronic). Nous pourrions mapper le mode boost sur _heat_ si cela est configurable à partir de Zigbee.

Je pense que nous devons implémenter config.pending pour régler la température cible. Le thermostat semble interroger son parent assez souvent, mais j'ai déjà rencontré des problèmes où la mise à jour ne se produisait pas. De plus, nous devrions probablement définir l'attribut de point de chaleur spécifique au fabricant, au lieu de l'attribut standard (qui ne prend pas en charge le rapport d'attribut).

Ce serait cool d'exposer la position de la vanne (comme state.bri ?). Eve Thermo rapporte cela également et j'espère pouvoir faire en sorte que homebridge-hue expose l'histoire à l'application Eve.

Je préférerais un state.valve ou similaire, je suppose qu'il y aura plus de thermostats pris en charge dans un proche avenir, nous ferions donc mieux d'obtenir les attributs appropriés dans le mélange.

L'Eurotronic a-t-il un équivalent pour l'état cible ? J'avais l'habitude de mapper config.scheduleron à l'état cible, mais avec le dernier commit, ce n'est plus exposé (car, si je comprends bien, cela n'a rien fait pour l'Eurotronic). Nous pourrions mapper le mode boost sur _heat_ si cela est configurable à partir de Zigbee.

Le planificateur n'est pas pris en charge par l'Eurotronic, mais il a plusieurs valeurs qui peuvent être définies. A besoin de plus d'expériences pour déterminer la meilleure approche.

Je pense que nous devons implémenter config.pending pour régler la température cible. Le thermostat semble interroger son parent assez souvent, mais j'ai déjà rencontré des problèmes où la mise à jour ne se produisait pas.

Oui, il interroge toutes les 5 secondes, ce qui est bon pour obtenir des commandes de manière fiable, config.pending est cependant logique.

De plus, nous devrions probablement définir l'attribut de point de chaleur spécifique au fabricant, au lieu de l'attribut standard (qui ne prend pas en charge le rapport d'attribut).

Ils semblent être synchronisés sur l'appareil. J'aime beaucoup le fait que le thermostat rapporte les valeurs et transmette également rapidement lorsque la température est modifiée manuellement. Mais voici un peu de travail à faire, changer manuellement ne modifiera pas le point de consigne de chaleur qui est également signalé.

J'avais l'habitude de mapper config.scheduleron à l'état cible, mais avec le dernier commit, ce n'est plus exposé

J'utilise HomeKit pour activer/désactiver le programmateur sur le thermostat Bitron. Espérons que cela continuera à fonctionner.

J'ai reçu le mien également aujourd'hui, j'ai joué de base avec car mes anciennes vannes utilisent une connexion qui n'est pas adaptée aux adaptateurs livrés avec le thermostat. La patience est une vertu hehhe, il faudra de l'aide pour remplacer l'ancienne valve ici.

Mais ce que je remarque, c'est que maintenant une "norme" semble avoir changé... Jusqu'à présent, les capteurs "complexes" obtiendraient des capteurs API REST séparés. Comme un capteur météo, il existerait trois ensembles de capteurs, pression, température et humidité. Maintenant, pour ce thermostat, la mesure de la température, l'état (marche/arrêt) et la température de consigne sont combinés. Pas de problème pour le plier, mais cela ne devrait-il pas être un point logique à reconsidérer si c'est un moment pour repenser si c'est la bonne piste ? En regardant cela, ce n'est pas un capteur, mais un appareil actif ? Quelque chose qui pourrait introduire la branche /devices ?

Ils semblent être synchronisés sur l'appareil.

À sens unique et pas toujours. D'après le manuel :

Die übertragenen Solltemperaturen wie Attribut de consigne de chauffage occupé / inoccupé (0x0012 ou 0x0014) werden auf das Attribut Consigne de température actuelle (0x4003) kopiert, um den TRV ohne hersteller spezifische Attribute verwenden zu können.

Contrôler le thermostat via ses boutons semble changer seulement 0x4003. Le réglage du mode _Boost_ change de 0x4003 à 3000 (30°C). Je pourrais mapper cet attribut à l'état cible : 500 = off ; 3000 = chaleur ; autres valeurs = auto.

Je pense que nous devons écrire l'attribut lors du réglage de la température cible. La commande _Setpoint Raise/Lower_ modifie 0x0012, mais pas 0x4003. C'est aussi en 0,01°C (comme les attributs de température, pas 0,1°C. Je pense que c'est une faute de frappe en général.xml?

au lieu du standard (qui ne prend pas en charge le rapport d'attributs).

Le manuel contient quelques incohérences. Dans 6.5, 0x008, 0x0012 et 0x0014 sont répertoriés comme non déclarables, mais dans 6.6, ils le sont.

Jusqu'à présent, les capteurs « complexes » obtiendraient des capteurs API REST séparés.

"Complexe" = plusieurs clusters (0x0402, 0x0403, 0x0405 pour le capteur météo). Le thermostat est un cluster (0x0201).

Quelque chose qui pourrait introduire la branche /devices ?

Oui, voir https://github.com/dresden-elektronik/deconz-rest-plugin/issues/579#issuecomment -459957111 et ci-dessous.

J'utilise HomeKit pour activer/désactiver le programmateur sur le thermostat Bitron. Espérons que cela continuera à fonctionner.

J'ai probablement besoin de mettre l'Eurotronic sur liste blanche séparément dans homebridge-hue.

Dans HomeKit, un thermostat a un _Target Heating Cooling State_ (arrêt, chauffage, refroidissement, auto) et un _Current Heating Cooling State_ (arrêt, chauffage, refroidissement).

L'Eurotronic semble contrôler cet état avec l'attribut "System Mode" (attribut id 0x001c) (se référer au manuel d'utilisation à la page 15). J'ai joué un peu avec cet attribut dans le logiciel deCONZ, malheureusement sans succès. La valeur peut être réglée, mais après relecture de la valeur du thermostat, il semble se réinitialiser à la valeur par défaut (Chaleur)

Avec state.on dérivé de la position réelle de la vanne, l'état actuel est couvert. L'Eurotronic a-t-il un équivalent pour l'état cible ?

L'état de la valeur est représenté par "Pi Heating Demand"

Le bit pour 0x000080 dans _Host flags_ (0x4008) correspond au mode de verrouillage (maintien + et - pendant 3 secondes). C'est réglable et effaçable à partir de Zigbee.

Le bit pour 0x000080 dans _Host flags_ (0x4008) correspond au mode de verrouillage (maintien + et - pendant 3 secondes). C'est réglable et effaçable à partir de Zigbee.

Comment avez-vous compris cela? J'ai essayé de définir des bits individuels avec l'éditeur d'attributs dans deCONZ. Mais chaque fois que j'écris quelque chose de différent de zéro, cela active simplement le mode de verrouillage. L'écriture de 0x000000 le déverrouille à nouveau. Et après avoir fait cela, la lecture des indicateurs d'hôte renvoie des valeurs très différentes (0x000001 après la configuration initiale, maintenant la mienne indique 0x42c381).

Edit: La version Z-Wave avait des indicateurs utiles, tels que le réglage de la minuterie de rétroéclairage LCD, la rotation de l'affichage de 90 degrés et la configuration de la sensibilité de la "détection de fenêtre ouverte". J'espérais que cela était caché quelque part dans les drapeaux de l'hôte ici.

Edit2 : (_Host flags_ & 0x000004) est-il le bit pour le mode boost ?

Je pense que nous devons implémenter config.pending pour régler la température cible. Le thermostat semble interroger son parent assez souvent, mais j'ai déjà rencontré des problèmes où la mise à jour ne se produisait pas.

Au début, cela m'est également arrivé, mais après avoir configuré le rapport d'attribut sur 0x4003 à min/max/change=1/600/1 le thermostat rapporte toujours immédiatement une fois que la température a été réglée.

Comment avez-vous compris cela?

Il y a 10 sortes de personnes : celles qui lisent le binaire et celles qui ne lisent pas ;-)

Il a signalé 0x000001 avant et 0x000081 après avoir défini le mode de verrouillage. La réécriture de 0x000001 a effacé le mode de verrouillage. Maintenant, le mien rapporte 0x400341, le réglage du mode de verrouillage le change en 0x4003c1. Je n'ai aucune idée des autres bits.

Edit: La version Z-Wave avait des indicateurs utiles, tels que le réglage de la minuterie de rétroéclairage LCD, la rotation de l'affichage de 90 degrés et la configuration de la sensibilité de la "détection de fenêtre ouverte". J'espérais que cela était caché quelque part dans les drapeaux de l'hôte ici.

Cool, mais je ne pense pas que l'affichage puisse pivoter (ce n'est pas un affichage bitmap ; les éléments sont câblés). Je jouais avec _Mode TRV_ : la valeur _Unknown 2_ fait basculer l'affichage sur la position de la vanne (comme indiqué par 0x0008 - _Pi Heating Demand_).

Est-ce que (_Host flags_ & 0x000004) est le bit pour le mode boost ?

Ne pensez pas, le mode Boost est 0x4003 == 3000.

Boost-Modus
Betätigen Sie die Boost-Taste.
Alternativ können Sie die Plus Taste so lange betätigen bis ON im Display angezeigt wird.

On ne sait pas non plus comment la « détection à distance » est censée fonctionner. Peut-être par liaison, avec un appareil qui dispose d'un cluster client « mesure de température » ?

J'essaie de comprendre _Remote Sensing_. Selon la spécification ZCL (pour le cluster de serveurs _Thermostat_) :

Pour la télédétection de température, le cluster client _Temperature Measurement_ (voir 4.4) PEUT être inclus sur le même point de terminaison. Pour la détection d'occupation, le groupe de clients _Occupancy Sensing_ (voir 4.8) PEUT être inclus sur le même point d'extrémité.
...
_LocalTemperature_ représente la température en degrés Celsius, mesurée localement ou à distance (sur le réseau)
...
_OutdoorTemperature_ représente la température extérieure en degrés Celsius, mesurée localement ou à distance (sur le réseau).
...
_Occupation_ spécifie si l'espace chauffé/refroidi est occupé ou non, tel que mesuré localement ou à distance
(sur le réseau).

Étant donné que ni _OutdoorTemperature_, ni _Occupancy_ ni les clusters clients ne sont implémentés, je crains que _RemoteSensing_ ne fasse rien.

PR ajoute state.valve et config.locked , base config.heatsetpoint sur 0x4003, et configure les rapports d'attributs sur les paramètres recommandés. Correction d'un tas de bugs dans la gestion des attributs du thermostat.

N'ont pas encore implémenté config.pending pour locked et heatsetpoint . Changer config.locked et config.heatsetpoint semble fonctionner (vérifié par reniflage). Pas sûr de la configuration de rapport - Wireshark a signalé un paquet mal formé sur la réponse à la configuration de 0x0001/0x0021 (pourcentage de batterie) ; Je n'ai pas encore capturé la configuration pour 0x0201.

IEEE 802.15.4 Data, Dst: 0x0000, Src: 0x15e9
ZigBee Network Layer Data, Dst: 0x0000, Src: 0x2a38
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x00)
    Destination Endpoint: 1
    Cluster: Power Configuration (0x0001)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 97
ZigBee Cluster Library Frame, Command: Configure Reporting Response, Seq: 152
    Frame Control Field: Profile-wide (0x18)
    Sequence Number: 152
    Command: Configure Reporting Response (0x07)
[Malformed Packet: ZigBee ZCL]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
        [Malformed Packet (Exception occurred)]
        [Severity level: Error]
        [Group: Malformed]

Après le code de commande (0x07), il y a un seul octet 0x00 (indiquant Succès ?), mais aucune confirmation de l'attribut.

deCONZ n'a pas l'air content de ça :

Feb  7 22:37:59 pi1 deCONZ[14715]: 22:37:55:634 0x00158D000192D251 (SPZB0001) create binding for attribute reporting of cluster 0x0001 on endpoint 0x01
Feb  7 22:37:59 pi1 deCONZ[14715]: 22:37:55:634 queue binding task for 0x00158D000192D251, cluster 0x0001
Feb  7 22:37:59 pi1 deCONZ[14715]: 22:37:55:634 binding for attribute reporting of cluster 0x0201 seems to be active
Feb  7 22:39:30 pi1 deCONZ[14715]: 22:39:25:824 binding/unbinding timeout srcAddr: 158D000192D251, retry
Feb  7 22:39:35 pi1 deCONZ[14715]: 22:39:30:824 failed to send bind/unbind request to 0x00158D000192D251 cluster 0x0001. drop
Feb  7 22:43:33 pi1 deCONZ[14715]: 22:43:33:482 binding for attribute reporting of cluster 0x0201 seems to be active
Feb  7 22:47:43 pi1 deCONZ[14715]: 22:47:39:154 binding for attribute reporting of cluster 0x0201 seems to be active

J'obtiens le même package malformé lors de la définition manuelle de la liaison à partir de l'interface graphique de deCONZ.

Cool, merci state.valve et config.locked ça a l'air bien.

Mais la configuration des rapports est-elle nécessaire ? Les attributs ont déjà une configuration par défaut, donc seule la liaison est nécessaire.

Pris en charge dans homebridge-hue v0.11.14 (voir https://github.com/ebaauw/homebridge-hue/issues/426#issuecomment-461920956). Notez que homebridge-hue a besoin du PR pour une prise en charge complète.

Mais la configuration des rapports est-elle nécessaire ? Les attributs ont déjà une configuration par défaut, donc seule la liaison est nécessaire.

Les paramètres recommandés diffèrent des paramètres d'usine par défaut. Cependant, le thermostat renvoie également une _Configure Reporting Response_ incorrecte lors de la configuration des rapports pour les attributs _Thermostat_. Pour l'instant, je vais commenter le code.

J'aimerais toujours que l'interface graphique de deCONZ prenne en charge _Reportable Change_ pour les valeurs 24 bits (et 48 bits), afin que je puisse configurer _Host Flags_ manuellement.

Pris en charge dans homebridge-hue v0.11.14 (voir ebaauw/homebridge-hue#426 (commentaire) ). Notez que homebridge-hue a besoin du PR pour une prise en charge complète.

Nice, merci, sera fusionné pour 2.05.59.

J'aimerais toujours que l'interface graphique de deCONZ prenne en charge _Reportable Change_ pour les valeurs 24 bits (et 48 bits), afin que je puisse configurer _Host Flags_ manuellement.

Je vais vérifier que le code devrait également être corrigé dans la prochaine version.

Est-ce que (_Host flags_ & 0x000004) est le bit pour le mode boost ?

Ne pensez pas, le mode Boost est 0x4003 == 3000.

Non, le mode Boost affiche également « On » sur le thermostat et une pression sur un bouton permet de revenir à la température précédemment réglée. J'ai (localement, pour tester) essayé d'ajouter un config.boost de la même manière que vous avez ajouté config.locked , ce qui fait basculer le drapeau 0x000004 et je peux maintenant activer à distance le mode boost /désactivé.

Il semble y avoir un indicateur pour éteindre également le thermostat (l'écran affiche alors "Off"), mais je n'ai pas toujours réussi à l'activer (ce serait bien pour un capteur de fenêtre, comme mentionné dans le manuel).

Étant donné que ni _OutdoorTemperature_, ni _Occupancy_ ni les clusters clients ne sont implémentés, je crains que _RemoteSensing_ ne fasse rien.

Merci, j'avais peur que ce soit le cas.
Pendant ce temps, j'ai contourné cela en lisant la température d'un capteur Xiaomi et en ajustant config.offset . Cela fonctionnait parfaitement, jusqu'à ce que votre PR change les unités de décalage de 0,1 à 0,01 degrés.
Pouvez-vous s'il vous plaît essayer ce qui suit :

• Réglez config.offset sur 10 via REST. Lisez l'attribut dans deCONZ et il affiche 1. Correct.
  REST répond : [{'success': {'/sensors/12/config/offset': 10, 'set config/offset': 1}}]
• Réglez config.offset sur -10 via REST. Lisez l'attribut dans deCONZ et il affiche -103, alors que je m'attendrais à -1.
  REST répond : [{'success': {'/sensors/12/config/offset': -10, 'set config/offset': 429496729}}] )

En regardant la modification de cette ligne , je pense que cela devrait être toInt au lieu de toUInt (c'était déjà faux auparavant, mais maintenant que le résultat est divisé par 10, il agit).
(_edit : je viens de le tester et toInt corrige_)

Non, le mode Boost affiche également « On » sur le thermostat et une pression sur un bouton permet de revenir à la température précédemment réglée. J'ai (localement, pour tester) essayé d'ajouter un config.boost de la même manière que vous avez ajouté config.locked , ce qui fait basculer le drapeau 0x000004 et je peux maintenant activer à distance le mode boost /désactivé.

En effet. Je ne pouvais pas le définir / l'effacer auparavant à partir de l'interface graphique de deCONZ, mais cette fois j'ai réussi (au moins une fois). Il semble y avoir un bogue dans l'interface graphique de deCONZ écrivant la valeur de l'attribut u24 :

IEEE 802.15.4 Data, Dst: 0x2a38, Src: 0x15e9
ZigBee Network Layer Data, Dst: 0x2a38, Src: 0x0000
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
ZigBee Cluster Library Frame, Mfr: Jennic (0x1037), Command: Write Attributes, Seq: 51
    Frame Control Field: Profile-wide (0x14)
    Manufacturer Code: Jennic (0x1037)
    Sequence Number: 51
    Command: Write Attributes (0x02)
    Attribute Field
        Attribute: Unknown (0x4008)
        Data Type: 24-Bit Unsigned Integer (0x22)
[Malformed Packet: ZigBee ZCL]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]

La valeur (après l'octet 0x22 pour le type) est manquante dans le paquet, mais le thermostat répond quand même avec _Write Attributes Response_ avec le statut OK, puis envoie un _Report Attributes_ pour 0x4008 avec la nouvelle valeur (aléatoire ?). Vérification de la plage manquante dans le firmware ?
J'ai également réussi à faire en sorte que le thermostat affiche brièvement « Off », mais je n'ai aucune idée de comment. 0x4003 était 500 après cela.

@manup , pouvez-vous confirmer qu'il s'agit d'un bogue (et si oui, peut-être même le corriger) ?

Je pense que ça devrait être toInt au lieu de toUInt

Je le pense aussi. J'ai bien peur d'avoir seulement ajouté la division et l'arrondi et de n'avoir jamais regardé la conversion de la valeur de la carte.

@manup , pouvez-vous confirmer qu'il s'agit d'un bogue (et si oui, peut-être même le corriger) ?

Oui, l'écriture de valeurs 24, 40, 48 et 56 bits ainsi que la configuration des rapports n'ont pas été entièrement implémentées. Il est déjà corrigé dans le noyau et fera partie de la 2.05.59.

En utilisant le plugin de ligne de commande de @ma-ca (https://github.com/ma-ca/deconz-cli-plugin), je suis capable d'envoyer des commandes _Write Attribute_ de manière fiable (et également de définir la configuration de rapport d'attribut sur 0x4008, donc la nouvelle valeur est immédiatement signalée).

Jusqu'à présent, j'ai trouvé les éléments suivants :

peu | effet
--- | ------
0x000001 | rien?
0x000002 | mettre l'affichage à l'envers
0x000004 | mode Turbo
0x000008 | rien?
0x000010 | réglé sur le mode d'effacement, mais mais rapporte en tant que 0x000000
0x000020 | défini sur le mode désactivé, mais renvoie 0x000010
0x000040 | rien?
0x000080 | verrouillage enfant

Si vous voulez essayer vous-même, j'utilise ce qui suit pour envoyer la commande :

echo "zclattrmanu 0x2a38 1 0x0201 0x1037 02084022010000" | nc localhost 5008

La charge utile est déchiffrée comme suit :

| |   | + value 0x000001
| |   + type 0x22 = u24
| + attribute 0x4008 = Host Flags
+ command 0x02 = Write Attributes

En regardant la documentation de la version Z-Wave, je m'attendais à moitié à ce qui suit dans _Host Flags_ :

• Délai d'expiration de l'écran LCD (5 bits) ;
• rétroéclairage LCD (1 bit);
• Détection de fenêtre ouverte (2 bits).

J'ai essayé les 16 autres bits. Lorsqu'il est réglé, chacun est signalé par le thermostat, mais je ne vois aucun effet.

Je n'arrive pas à effacer le bit 0x000001 - c'est peut-être le rétroéclairage LCD (que je n'arrive pas à éteindre) ?

Le dernier PR ajoute config.boost , config.displayflipped et config.off (je n'ai pas pris la peine de config.mode ou quelque chose du genre). Les modifications apportées à plusieurs attributs REST sont collectées dans un seul _Attributs d'écriture_ sur _Host Flags_. Le réglage boost efface off et vice versa.

{
  "config": {
    "battery": 100,
    "boost": false,
    "displayflipped": true,
    "heatsetpoint": 2100,
    "locked": false,
    "off": false,
    "offset": 0,
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "19c89536ce4a0af7399c4405f78e516d",
  "manufacturername": "Eurotronic",
  "modelid": "SPZB0001",
  "name": "Living Room Radiator",
  "state": {
    "lastupdated": "2019-02-10T14:54:26",
    "on": true,
    "temperature": 2309,
    "valve": 82
  },
  "swversion": "15181120",
  "type": "ZHAThermostat",
  "uniqueid": "00:15:8d:00:01:92:d2:51-01-0201"
}

Des progrès impressionnants, mais je crains que config.on, config.off et state.on ne soient déroutants pour un utilisateur d'API. Le config.mode ne serait-il pas plus propre et plus facile à comprendre ?

Oui, ça le ferait. C'est le plus rapide à mettre en oeuvre...

Il est assez difficile de combiner les modifications apportées à plusieurs attributs REST en une seule commande d'écriture pour l'attribut _Host Flags_ Zigbee. Il vaut peut-être mieux l'exposer en tant qu'objet, quelque chose comme config.hostflags.boost , config.hostflags.off , etc. Bien sûr, c'est plus de travail du point de vue de l'analyse d'API.

De plus, je ne suis pas très heureux d'utiliser getZclValue() (et setZclValue() après le redémarrage) pour mettre en cache la valeur _Host Flags_, plutôt que d'utiliser une ressource RConfigHostFlags . Je ne sais pas trop comment créer un attribut REST «caché», qui est stocké dans la base de données, mais non exposé par l'API.

Il vaut peut-être mieux l'exposer en tant qu'objet, quelque chose comme config.hostflags.boost , config.hostflags.off , etc. Bien sûr, c'est plus de travail du point de vue de l'analyse d'API.

Je n'ai pas encore examiné les détails, mon problème actuellement est qu'en regardant ces attributs naïvement, je ne comprends pas ce qu'ils sont censés faire. Peut-être qu'une imbrication dans config.hostflags.something n'est pas nécessaire mais une interface plus simple. Par exemple, si config.hostflags.off est censé contrôler l'attribut config.on.. nous pouvons simplement utiliser config.on ?

Aussi, nous devrions trouver un meilleur mot pour le mode boost , je n'ai aucune idée de ce que cela signifie, si cela fait quelque chose d'utile un mot le décrivant aiderait à comprendre le but :)

Je ne sais pas trop comment créer un attribut REST «caché», qui est stocké dans la base de données, mais non exposé par l'API.

Ignorez simplement l'attribut dans la demande d'obtention associée :)

De plus, nous devrions trouver un meilleur mot pour le mode _boost_, je n'ai aucune idée de ce que cela signifie, si cela fait quelque chose d'utile, un mot le décrivant aiderait à comprendre le but :)

Il "booste" la température, bien sûr ;-) Et vous le réglez en appuyant sur le bouton Boost ;-) Le mot vient en fait de la documentation Eurotronic Spirit :

Boost-Modus
Betätigen Sie die Boost-Taste.
Alternativ können Sie die Plus Taste so lange betätigen bis ON im Display angezeigt wird.
Confort-Modus
Befindet sich das Gerät nicht im Komfortmodus kann per Plus ou Minus Taste in den Komfortmodus gewechselt werden.

Le mot "off" n'est pas mentionné dans la documentation, mais fondamentalement, il règle la vanne du thermostat sur min et l'écran affiche "Off". Il est mentionné dans la documentation de la variante Z-Wave.

Par exemple, si config.hostflags.off est censé contrôler l'attribut config.on.. nous pouvons simplement utiliser config.on ?

Il contrôle en quelque sorte l'attribut state.on . config.on est déjà utilisé pour activer ou désactiver (tirer des règles depuis) ​​la ressource. Si nous changions cela, nous perdrions la compatibilité avec l'API Hue. Je suis d'accord, cela prête à confusion, également avec config.scheduleron pour l'autre thermostat.

HomeKit utilise _TargetHeatingCoolingState_ avec les valeurs possibles _Off_, _Heat_, _Cool_ et _Auto_., et _CurrentHeatingCoolingState_ avec les valeurs possibles _Off_, _Heating_ et _Cooling_. Bien entendu, _Cool_ et _Cooling_ ne s'appliquent pas à l'Eurotronic.
Si je traduis cela vers l'API REST, j'obtiendrais config.mode ( config.targetstate ?) avec les valeurs "off", "heat", "cool" et "auto" ; et state.mode ou state.status ( state.currentstate ?) avec les valeurs "off", "heating" et "cooling". Si nous ignorons la partie refroidissement pour le moment, state.heating semble avoir plus de sens. Dans le langage Eurotronic, les valeurs config.mode seraient "off", "boost" et "comfort". Je pense que je préférerais les termes HomeKit (ils semblent plus génériques), mais je suis probablement biaisé.

En passant : je préférerais config.targettemperature à config.heatsetpoint .

Quand la v2.05.59 est-elle due ? Je suis content de faire les changements, mais je ne les finirai pas ce soir.

Oh mon dieu, ce truc de boost est vraiment déroutant :) Même avec la description, je ne sais pas quoi ou pourquoi il existe. Quelqu'un en aura-t-il besoin ou l'utilisera-t-il ?

Je suis d'accord que les termes de HomeKit sont beaucoup plus lisibles par l'homme, totalement ouverts pour les adapter au thermostat.

Mais nous devrions vérifier les changements de rupture, pas sûr que quelqu'un utilise encore les attributs existants. @Kane610 @wvuyk ?

Quand la v2.05.59 est-elle due ?

Eh bien, le programme était aujourd'hui, mais je n'ai pas encore fini tous les détails. Le prochain programme peut donc être demain soir ou mardi. Mais pas pressé 2.05.60 peut également arriver d'ici la fin de la semaine.

J'ai config.mode travaille avec les valeurs "off", "heat" et "auto". N'ont pas changé state.on ni config.heatsetpoint . Introduction d'un config.hostflags caché pour conserver l'attribut _Host Flags_ (0x4008) dans la base de données.

{
  "config": {
    "battery": 100,
    "displayflipped": true,
    "heatsetpoint": 2100,
    "locked": false,
    "mode": "auto",
    "offset": 0,
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "25aac331bc3c4b465cfb2197f6243ea4",
  "manufacturername": "Eurotronic",
  "modelid": "SPZB0001",
  "name": "Living Room Radiator",
  "state": {
    "lastupdated": "2019-02-10T22:41:32",
    "on": false,
    "temperature": 2149,
    "valve": 0
  },
  "swversion": "15181120",
  "type": "ZHAThermostat",
  "uniqueid": "00:15:8d:00:01:92:d2:51-01-0201"
}

Il y a un bug dans changeSensorConfig() : il émet l'événement de socket web trop tôt, avant même qu'une erreur ne soit renvoyée. Essayez de METTRE {"mode": "invalid"} à config .

Dans d'autres systèmes tels que Homematic, MAX! etc. le bouton boost ouvre complètement la vanne pendant une durée limitée. Je ne l'ai jamais utilisé jusqu'à ce que je déménage dans un appartement avec des lucarnes. Après les avoir fermés par temps froid, le verre était si froid qu'il s'est embué. Pour éviter cela, j'utilise le mode boost chaque fois que je ferme mes vitres et que la température est inférieure à 5 degrés

@manup J'ai un PR pour le support du thermostat deconz. C'est donc le bon moment pour faire des changements.

Soit je le publie dans la prochaine version dans 3 semaines ou si vous publiez 59 avec ce support avant la bêta jeudi. Et j'ai bien sûr besoin de la bonne liste d'attributs :)

@manup ,

Je travaille dessus en interne, mais de manière très flexible, alors allez-y et utilisez le bon attribut. En faire une norme car nous nous attendrions tous à ce que davantage de thermostats arrivent ?

modifier Pour autant que je puisse vérifier ici les attributs sont assez proches de ce que Homeseer expose pour les autres thermostats BTW.

J'ai config.mode travaille avec les valeurs "off", "heat" et "auto". N'ont pas changé state.on ni config.heatsetpoint . Introduction d'un config.hostflags caché pour conserver l'attribut _Host Flags_ (0x4008) dans la base de données.

Cela a l'air vraiment bien. S'il y a encore du souci, dans le manuel du Z-Wave le mode "boost" est aussi appelé "pleine puissance". Je pense que cela pourrait être encore plus précis que "chaleur". D'ailleurs, comme pour la version Z-Wave, ce mode chauffe à pleine puissance pendant quelques minutes, puis il revient automatiquement en mode normal (et les drapeaux hôtes sont signalés en conséquence dans ce cas).

Cependant, je pense qu'il reste un cas d'angle : si vous définissez config.mode sur "off", puis modifiez config.heatsetpoint , l'appareil reviendra en mode normal, mais les indicateurs d'hôte seront toujours indiquer 0x000010. Pour résoudre la confusion, je pense que les indicateurs d'hôte doivent être effacés des bits off/boost chaque fois que config.heatsetpoint est touché.

Dans le manuel du Z-Wave, le mode « boost » est également appelé « pleine puissance ». Je pense que cela pourrait être encore plus précis que "chaleur".

Voulez-vous des termes génériques, ou parler Eurotronic? Si ce dernier, nous ferions mieux d'utiliser "off", "boost" et "comfort" (je n'aime pas l'espace en "full power"). Si le premier, "off", "heat" et "auto" semblent plus appropriés.

D'ailleurs, comme pour la version Z-Wave, ce mode chauffe à pleine puissance pendant quelques minutes, puis il revient automatiquement en mode normal (et les drapeaux hôtes sont signalés en conséquence dans ce cas).

Je suppose que je n'ai pas laissé le mode Boost activé assez longtemps pour voir cela se produire. A tester en ce moment...
EDIT en effet, ~15 minutes, semble-t-il.

Feb 11 17:39:11 pi1 dc_eventlog[792]: /sensors/8/config: {"mode":"heat"}
Feb 11 17:39:14 pi1 dc_eventlog[792]: /sensors/8/config: {"heatsetpoint":3000}
...
Feb 11 17:54:31 pi1 dc_eventlog[792]: /sensors/8/config: {"heatsetpoint":2100,"mode":"auto"}

Je pense que les indicateurs d'hôte doivent être effacés des bits off/boost chaque fois que config.heatsetpoint est touché.

Je pense que vous avez raison, mais les indicateurs doivent être effacés sur l'appareil, pas dans le cache de l'API REST. Voir mon commentaire sur votre RP.

Cependant, je pense qu'il reste un cas d'angle

J'ai constaté qu'en passant du mode Boost à Off ou à vv, la valeur d'origine de _HeatSetPoint_ est perdue. Je ne sais pas si c'est facile à contourner.

Dans le manuel du Z-Wave, le mode « boost » est également appelé « pleine puissance ». Je pense que cela pourrait être encore plus précis que "chaleur".

Voulez-vous des termes génériques, ou parler Eurotronic? Si ce dernier, nous ferions mieux d'utiliser "off", "boost" et "comfort" (je n'aime pas l'espace en "full power"). Si le premier, "off", "heat" et "auto" semblent plus appropriés.

Je ne sais pas, car je n'ai que l'Eurotronic disponible. Cela peut dépendre des modes qu'un thermostat mural (par exemple pour le chauffage par le sol) fournirait. Mais pour l'instant, les termes génériques ne me dérangent pas.

J'ai constaté qu'en passant du mode Boost à Off ou à vv, la valeur d'origine de _HeatSetPoint_ est perdue. Je ne sais pas si c'est facile à contourner.

Es-tu sûr? Je viens d'essayer : la consigne est à 21C. Maintenant, j'envoie 0x20 et il passe à "off" et le point de consigne est signalé à 5C. Envoyez maintenant 0x10, il revient à la normale et signale immédiatement à nouveau le point de consigne comme 21C. Je peux également quitter le mode "off" en appuyant sur _+_ ou _-_ sur l'appareil (deux fois).
Cela fonctionne également pour le mode boost (également lorsque vous quittez le mode boost en appuyant sur le bouton _boost_ de l'appareil (deux fois)).

Es-tu sûr? Es-tu sûr? Je viens d'essayer : la consigne est à 21C. Maintenant, j'envoie 0x20 et il passe à "off" et le point de consigne est signalé à 5C. Envoyez maintenant 0x10, il revient à la normale et signale immédiatement à nouveau le point de consigne comme 21C. Je peux également quitter le mode "off" en appuyant sur _+_ ou _-_ sur l'appareil (deux fois).

C'est le passage du mode Off au Confort ; ne pas passer directement du mode Off au mode Boost .

Lors de l'exécution (avec un certain temps entre les commandes) :

$ ph put /sensors/8/config '{"mode": "heat"}'
$ ph put /sensors/8/config '{"mode": "off"}'
$ ph put /sensors/8/config '{"mode": "auto"}'

le Heat SetPoint est laissé à 30°C :

Feb 11 18:13:24 pi1 dc_eventlog[792]: /sensors/8/config: {"mode":"heat"}
Feb 11 18:13:30 pi1 dc_eventlog[792]: /sensors/8/config: {"heatsetpoint":3000}
Feb 11 18:13:30 pi1 dc_eventlog[792]: /sensors/8/state: {"lastupdated":"2019-02-11T17:13:30"}
Feb 11 18:13:30 pi1 dc_eventlog[792]: /sensors/8/state: {"lastupdated":"2019-02-11T17:13:30","temperature":2087}
Feb 11 18:13:44 pi1 dc_eventlog[792]: /sensors/8/config: {"mode":"off"}
Feb 11 18:13:50 pi1 dc_eventlog[792]: /sensors/8/config: {"heatsetpoint":500}
Feb 11 18:13:50 pi1 dc_eventlog[792]: /sensors/8/state: {"lastupdated":"2019-02-11T17:13:50"}
Feb 11 18:13:58 pi1 dc_eventlog[792]: /sensors/8/state: {"lastupdated":"2019-02-11T17:13:57","on":false,"valve":0}
Feb 11 18:14:19 pi1 dc_eventlog[792]: /sensors/8/config: {"mode":"auto"}
Feb 11 18:14:23 pi1 dc_eventlog[792]: /sensors/8/config: {"heatsetpoint":3000}
Feb 11 18:14:23 pi1 dc_eventlog[792]: /sensors/8/state: {"lastupdated":"2019-02-11T17:14:23"}
Feb 11 18:14:30 pi1 dc_eventlog[792]: /sensors/8/state: {"lastupdated":"2019-02-11T17:14:30","on":true,"valve":168}

Oui, je peux le confirmer pour cette séquence : auto -> heat -> off -> auto .
Au moins, tout reste synchronisé, puisque le point de consigne est correctement signalé.

Curieusement, cela fonctionne comme prévu pour auto -> off -> heat -> auto .

cela fonctionne comme prévu pour auto -> off -> heat -> auto

En effet.

Avez-vous essayé de déclencher la détection de fenêtres ouvertes ?

Non, j'utilise des règles basées sur les capteurs de contact Xiaomi.

L'expérience avec mes thermostats précédents était que cela ne fonctionnerait de manière fiable que si le thermostat était monté directement sous la fenêtre.

Pour ajouter à la dernière question, et au cas où quelqu'un serait confus :
Je pense que ce que nous appelons "off" (drapeau 0x20) est en quelque sorte une bascule manuelle de la détection de fenêtre ouverte. Le thermostat s'éteint et le dit à l'écran, mais j'ai constaté qu'il revient au réglage précédent après environ 15 minutes (comme mentionné dans le manuel).

Bonne trouvaille !

Die Empfindlichkeit der Fenster-Offen Erkennung kann konfiguriert werden.

Cela doit être certains des bits encore non identifiés dans _Host Flags_ (0x4008).

Im Stellwertbetrieb (Mode spécifique au fabricant) wird die Fenster-Offen Erkennung nicht ausgeführt.

Je suppose que le "mode spécifique au fabricant" est _TRV Mode_ (0x4000) "Inconnu 2" ?

J'ai trouvé que le réglage du "Mode TRV" (0x4000) sur "manuel" (2) contrôle l'appareil via le point de consigne (défini via 0x4003). Lorsque le mode est réglé sur "Unknown 2", l'écran affiche le pourcentage d'ouverture de la vanne actuel, qui peut être contrôlé avec 0x4001

Die Fenster-Offen Erkennung kann durch einen externen Fensterkontakt aktiviert/deaktiviert werden.

Cela suggérerait une sorte de liaison, mais sans un cluster client approprié, cela sera difficile à comprendre. La seule chose qui s'en rapproche dans la spécification ZCL serait un périphérique _IAS Zone_ de type _Contact switch_.

J'en ai installé quatre autres et je les ai transférés sur mon réseau de production, maintenant le 2.05.59. Je prévois d'en ajouter trois autres, mais je dois d'abord faire de la place. Les thermostats sont beaucoup plus gros que les cadrans d'origine.

L'interface graphique de deCONZ de la version 2.05.59 gère désormais correctement l'attribut u24 _Host Flags_ : je peux modifier la valeur et la configuration de rapport d'attribut. J'ai modifié manuellement la configuration des rapports par défaut sur tous mes thermostats :

• Désactivez les rapports pour 0x0012 et 0x0014, que nous n'utilisons pas à cause de 0x4003. Le thermostat ne semble pas combiner plusieurs attributs dans un seul rapport, ce qui permet d'économiser du trafic et des mises à jour à state.lastupdated ;
• Configurez un intervalle minimum de 1, un intervalle maximum de 600 et un changement à signaler de 1 pour _PI Heating Demand_, _Errors_ et _Host Flags_, de sorte que les changements sont signalés immédiatement. La _température locale_ obtient un changement à signaler de 10 (0,1 °C), le _point de consigne de température actuel_ de 50 (0,5 °C). Toujours à déterminer les paramètres optimaux. Peut-être que je devrais limiter les rapports de période à _Température actuelle_ et configurer uniquement les rapports de modification pour les autres attributs.

Je préférerais toujours que le plugin REST API fasse cela, mais le thermostat semble envoyer une _Configure Reporting Response_ malformée (avec uniquement le statut dans la charge utile).

Je pense que nous ferions mieux d'exposer également l'attribut _Errors_ 0x4002. J'ai réussi à obtenir un de mes thermostats pour signaler une erreur. Murphy s'est assuré que c'était celui caché derrière mon bureau, alors il est passé inaperçu pendant un bon moment.

@manup des progrès sur les changements prévus pour cela ?

Salut @tous ,

J'ai acheté 2 de ces appareils et je voulais les connecter à l'application Phoscon. Mais lorsque je réinitialise les appareils et que l'écran affiche "JiN" et une antenne clignotante, j'obtiens juste une erreur de connexion dans l'application Phoscon, même si j'appuie sur la touche boost de l'appareil après que l'antenne cesse de clignoter.

Y a-t-il une étape que j'ai manquée ou dois-je utiliser l'application GUI pour connecter l'appareil ?

Meilleurs reagards
marque

Edit : j'ai déjà mis à jour le plug-in Rest 2.05.59 et, comme les notes de version, les appareils devraient fonctionner avec cette version.

Hier, j'ai couplé quatre thermostats à mon réseau de production sans aucun problème. Aujourd'hui, j'ajoutais les trois thermostats restants et j'ai également rencontré des problèmes d'appariement. Je n'ai aucune idée de la cause : parfois, un nœud s'affichait dans l'interface graphique de deCONZ, mais la liste des points de terminaison n'était pas mise à jour ou rien ne pouvait être lu à partir du nœud. Peut-être que mon réseau devient trop grand, maintenant sur 101 nœuds. Je soupçonne des problèmes de routage : les messages du thermostat semblent atteindre la passerelle, mais les réponses de la passerelle ne semblent pas atteindre le thermostat.

J'ai supprimé les nœuds de la table devices dans la base de données, retiré la batterie du thermostat pendant un moment et réessayé. Il est préférable d'ouvrir le réseau à partir de l'ancienne application Web/de rechercher des capteurs de Phoscon, puis de réinitialiser le thermostat (maintenez les trois boutons enfoncés pendant 10 secondes - cela compte jusqu'à 10 pour vous). J'ai dû lire manuellement les attributs _Basic_ pour forcer la création de la ressource API REST, mais après cela, le thermostat et deCONZ semblent s'aimer.

Le thermostat doit-il être visible dans l'API ? Ou dans l'assistante à domicile ?

Dans l'api : oui, voir https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment -462189373. Assistante à domicile : Je ne sais pas. Il est visible dans HomeKit via homebridge-hue, voir https://github.com/ebaauw/homebridge-hue/issues/426#issuecomment -461920956.

OK merci. Je suppose que je vais essayer de le supprimer et de le coupler à nouveau maintenant. En utilisant la procédure que vous avez mentionné dans le post précédent.

@Oliviakrkk, il n'est pas encore pris en charge dans l'assistant domestique. J'attends des informations si l'API va changer sous peu ou pas. J'ai un PR ouvert mais il ne sera pas fusionné tant que l'Api ne sera pas stable

@ Kane610 Merci pour les éclaircissements.

@ebaauw : Comment puis-je "lire manuellement les attributs _Basic_ pour forcer la création de la ressource API REST"

@ebaauw : Je vois maintenant les appareils dans l'interface graphique et je peux écrire le point de consigne de température actuel à partir d'ici. Mais si je jette un œil à /sensors dans l'API, les appareils ne sont pas affichés. Devraient-ils être là ?

@Kane610 Comment puis-je ajouter vos modifications à mon HA ? Dois-je faire autre chose que remplacer les fichiers sources ?

@alpha23 il suffit de suivre le pr et tous ses changements

@ Kane610 Je pense que l'API est stable (du moins pour l'instant). Comme je l'ai mentionné précédemment, je pourrais ajouter state.errors , mais je ne pense pas que nous aurons besoin de modifier la fonctionnalité actuelle.

Mais si je jette un œil à /sensors dans l'API, les appareils ne sont pas affichés. Devraient-ils être là ?

@alpha23 oui, mais comme je l'ai déjà dit, vous devrez peut-être déclencher leur création manuellement.

Comment puis-je "lire manuellement les attributs _Basic_ pour forcer la création de la ressource API REST"

@Oliviakrkk Ouvrez le panneau _Cluster Info_ dans l'interface graphique de deCONZ. Appuyez sur le point de droite sur le nœud du thermostat pour faire défiler la liste des clusters. Sélectionnez le _Basic_cluster - cela remplit le panneau. Recherchez de nouveaux appareils dans l'application Phoscon. Faites ensuite défiler le panneau _Cluster Info_ et appuyez sur _Read_. Le nom du nœud passe de l'adresse NWK à « Thermostat xx » lorsque la ressource API REST a été créée.

@ebaauw merci !

Une question : avec « on » ; est-ce l'état ou la configuration qui doit être modifié pour activer/désactiver le chauffage ?

Je crois que ceci est remplacé par "mode"="off" ?

• Le state.on lecture seule reflète la position de la vanne (0 = faux ; >0 = vrai) à partir de _PI Heating Demand_ (0x0008). La valeur numérique également exposée sous la forme state.valve ;
• Lecture seule state.temperature reflète la température mesurée par le thermostat, à partir de _Local Temperature_ (0x0000) ;
• Lecture/écriture config.heatsetpoint reflète la température cible, à partir de _Current Temperature Setpoint_ (0x4003) ;
• Lecture/écriture config.mode reflète le mode, à partir de _Host Flags_ (0x4009) :
  
  
  
  • "off" = mode _Off_ (l'affichage indique Off). Le thermostat modifie _Current Temperature Setpoint_ à 500 (5°C) ; changer cela revient au mode _Normal_.
  
  
  • "auto" = mode _Normal_ (alias Confort) (l'écran affiche la température cible);
  
  
  • "heat" = mode _Boost_ (l'affichage indique On). Le thermostat modifie le _Point de consigne de température actuel_ à 3000 (30°C) ; changer cela revient au mode _Normal_. Notez que le thermostat repasse le mode _Boost_ en _Normal_ après environ 15 minutes environ ;
  
  
• La lecture/écriture config.on est l'attribut standard pour désactiver les règles déclenchées à partir de cette ressource de capteur. Il n'est mappé à aucun des attributs du thermostat.

D'après ma (brève) expérience, il est préférable de laisser "mode": "auto" et de changer config.heatsetpoint pour la température cible (par exemple 2100 quand à la maison et 1500 quand non). Utilisez state.on pour indiquer si le thermostat chauffe ou non.

@wvuyk éteint et

Merci @ebaauw , cette rédaction serait bonne pour tous les types d'appareils (indice @manup )

Quelques conseils pour ceux qui cherchent à obtenir ce thermostat.

• Les prix en ligne de l'Eurotronic Spirit Zigbee varient énormément. J'ai eu mon premier sur getgoods.com pour 37,73 € TTC. expédition de DE à NL, mais ils ont augmenté le prix à 45,86 €, excl. expédition avant que je puisse commander plus. J'ai reçu le prochain lot de yakodo.de pour 38,80 € pièce (et 12,90 € pour l'expédition, toujours de DE à NL), mais ils ont maintenant augmenté le prix à 50,00 € pièce ;
• Mes radiateurs avaient déjà des vannes Danfoss RA installées, mais avec des robinets réguliers (non thermostatiques). Il m'a fallu du temps pour comprendre comment les désinstaller : ouvrez-les complètement et retirez-les simplement (parfois la violence est la bonne solution). Avec l'adaptateur RA vers M30 inclus, l'installation du Spirit était un jeu d'enfant.
• Le radiateur dans mon couloir est trop près du mur latéral pour que le Spirit puisse s'adapter. Je faisais déjà des cauchemars sur le déplacement du radiateur, quand j'ai trouvé un adaptateur M30 avec un angle à 90° . À l'aide de l'adaptateur RA vers M30 inclus et de cet adaptateur d'angle, j'ai installé le Spirit perpendiculairement au radiateur.
  
  Cela semble bien fonctionner - j'ai commandé un autre adaptateur d'angle pour ne pas avoir à déplacer le placard de la salle à manger (ancré au mur) du radiateur de la salle à manger.

@Oliviakrkk Ouvrez le panneau _Cluster Info_ dans l'interface graphique de deCONZ. Appuyez sur le point de droite sur le nœud du thermostat pour faire défiler la liste des clusters. Sélectionnez le _Basic_cluster - cela remplit le panneau. Recherchez de nouveaux appareils dans l'application Phoscon. Faites ensuite défiler le panneau _Cluster Info_ et appuyez sur _Read_. Le nom du nœud passe de l'adresse NWK à « Thermostat xx » lorsque la ressource API REST a été créée.

Joli! Merci!
L'élément API a été créé. Pendant un moment, il s'appelait Thermostat 49, puis il s'appelait SPZB0001.

"59": {
    "config": {
        "battery": null,
        "displayflipped": null,
        "heatsetpoint": 2100,
        "locked": null,
        "mode": "auto",
        "offset": 0,
        "on": true,
        "reachable": true
    },
    "ep": 1,
    "etag": "9c3459545806f30b2a3ad2ec4ce765ca",
    "manufacturername": "Eurotronic",
    "modelid": "SPZB0001",
    "name": "SPZB0001",
    "state": {
        "lastupdated": "2019-02-16T17:47:25",
        "on": null,
        "temperature": 1990,
        "valve": null
    },
    "swversion": "20181205",
    "type": "ZHAThermostat",
    "uniqueid": "00:15:8d:00:01:92:d2:20-01-0201"
}

Je testais le thermostat depuis quelques jours.
J'ai découvert que config.on n'était presque jamais désactivé. J'avais remarqué que la valeur de la vanne était fixée à « 4 » chaque fois que le niveau de chauffage nécessaire était atteint. Avec la réponse de @ebaauw , je comprends maintenant pourquoi le config.on n'a jamais été défini sur false.

Mais assez drôle, depuis hier après-midi la valeur de state.valve est mise à 0 à chaque fois que la consigne est atteinte. Il semble que l'appareil s'ajuste au fil du temps ?

Une autre découverte est que lorsque j'appuie sur le bouton boost de l'appareil, les crochets Web entrent pour config.heatsetpoint , state.valve et state.temperature , mais pas pour config.auto Est cela n'est pas signalé par l'appareil ou ce rapport n'a-t-il pas été envoyé ?

Mais assez drôle, depuis hier après-midi la valeur de state.valve est mise à 0 à chaque fois que la consigne est atteinte. Il semble que l'appareil s'ajuste au fil du temps ?

Je suppose que oui. Il semble trouver le bon réglage de vanne pour une température constante, plutôt que d'ouvrir/fermer la vanne tout le temps. Lorsque vous modifiez le point de consigne de chaleur loin de la température actuelle, cela ouvrira ou fermera complètement la vanne.

Une autre découverte est que lorsque j'appuie sur le bouton boost de l'appareil, les crochets Web entrent pour config.heatsetpoint , state.valve et state.temperature , mais pas pour config.auto Est cela n'est pas signalé par l'appareil ou ce rapport n'a-t-il pas été envoyé ?

Je pense que tu veux dire config.mode ? Il est lu à partir de l'attribut _Host Flags_ 0x4008. Le rapport d'usine par défaut est trop conservateur, à mon humble avis, et il ne signale pas les modifications immédiatement. Si vous modifiez cela manuellement, il est signalé comme les autres attributs, voir https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment -464348217.

En effet, je ment config.mode . J'espérais qu'il rapporterait de manière régulière, environ 5 minutes. Mais j'ai attendu le temps de boost, et il n'a jamais signalé le config.mode comme "chaleur", les autres valeurs ont été signalées de manière cohérente, pourraient les voir changer ici, maintenant 15 minutes se sont écoulées, tout est réinitialisé.

Dommage, cela aurait pu être une information utile pour les événements Homeseer....

Deux de mes thermostats se réinitialisent spontanément (?) en quelque sorte, effaçant displayflipped , même si l'affichage lui-même est toujours inversé. Dans les deux cas, je vois le même schéma dans le journal :

• Le thermostat envoie une _Annonce de l'appareil_ (ZDP 0x0013) ;
• Le thermostat signale _Point de consigne de température actuelle_ 0x4003 à 20°C ;
• Le thermostat signale _PI Heating Demand_ 0x0008 à 255 et _Local Temperature_ 0x0000 à 20°C ;
• Le thermostat signale _Hosts Flags_ 0x4008 à 0x000081 ( locked est conservé, mais displayflipped est effacé) et _Current Temperature Setpoint_ à la valeur réelle ;
• Le thermostat signale _Current Temperature Setpoint_ 0x4003 à la valeur réelle ;
• Le thermostat signale _PI Heating Demand_ 0x0008 et _Local Temperature_ 0x0000 à leurs valeurs réelles.

La prochaine fois que _Host Flags_ est écrit, le bit displayflipped effacé est renvoyé au thermostat et l'affichage se désactive.

Je ne sais pas ce qui a déclenché cette séquence. Il s'agissait de thermostats différents de celui de MIA sur https://github.com/dresden-elektronik/deconz-rest-plugin/issues/849.

Mise à jour Après une analyse plus approfondie du journal, d'autres thermostats ont suivi la même routine, mais comme leur affichage n'a pas été inversé, je ne l'ai pas remarqué au début.

Je ne sais pas ce qui a déclenché cette séquence.

Je pense que c'est l'autotest du thermostat. Selon https://eurotronic.org/produkte/zigbee-heizkoerperthermostat/spirit-zigbee/ , le thermostat effectue un auto-test une fois par semaine :

Selbsttest: 1 x wöchentlich

Cet appareil a l'air super ! @ Kane610 J'ai vu votre RP. Merci pour le travail. Il n'inclut pas les horaires, pour le moment, non? Je veux juste savoir que je ne chercherai pas quelque chose qui n'est pas là.

@akaho pas d'horaires. Pas moyen de l'exposer dans hass atm

Salut,
J'ai trouvé l'appareil avec DeCONZ, merci pour le travail !
Mais le voyez-vous dans Phoscon ? Je ne peux pas le trouver.

Salut,
j'ajoute aussi un Spirit Zigbee, après la procédure Custer Info -read, Phoscon écrit "Sensor bereit"
Mais il n'y a pas de capteur dans Phoscon et aussi rien dans IOBroker.
Mais je peux le voir dans Deconz-GUI comme SPZB001 après un symbole de batterie.

Je lance Deconz 2.05.60 sur un RPI3.

N'étant pas dans le zigbee et les clusters (j'ai utilisé des vannes thermostatiques sans fil basées sur KNX-RF), existe-t-il un support pour piloter manuellement le moteur de la vanne, ou en fait faire votre propre contrôleur PID pour cela ?
De plus, actuellement, seules les vannes thermostatiques de l'appareil de point final (sur batterie) sont-elles prises en charge, ou les vannes thermostatiques zigbee alimentées par le secteur (routeur) fonctionneraient-elles également maintenant ?

existe-t-il un support pour conduire manuellement le moteur de la vanne, ou en fait faire votre propre contrôleur PID pour cela ?

Les vannes Eurotronic Spirit ont un mode dans lequel vous pouvez régler la position de la vanne manuellement. Cela utilise des extensions spécifiques au fabricant pour la norme Zigbee, donc ymmv pour les autres thermostats. Je n'ai pas exposé cette partie sur l'API REST.

Écrire votre propre contrôleur PID me semble assez difficile ; J'adorerais voir votre travail là-dessus.

De plus, actuellement, seules les vannes thermostatiques de l'appareil de point final (sur batterie) sont-elles prises en charge, ou les vannes thermostatiques zigbee alimentées par le secteur (routeur) fonctionneraient-elles également maintenant ?

Chaque type de thermostat doit être explicitement ajouté à la liste blanche et peut nécessiter quelques modifications en fonction de la manière dont il implémente et étend la norme Zigbee. Qu'ils soient sur secteur ou sur batterie, cela ne changera pas grand-chose. Ni qu'il s'agisse de routeurs Zigbee ou de terminaux Zigbee (ce qui n'est pas toujours la même chose que l'alimentation secteur ou batterie). Si vous avez un type particulier en tête, veuillez ouvrir un nouveau numéro en fournissant les informations décrites ici : https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Request-Device-Support.

Salut,

j'ai un problème pour ajouter l'esprit eurotronic avec deconz v2.05.60.

mon deconz s'exécute sur Ubuntu sans interface graphique, je ne peux donc utiliser que l'application Web phoscon et l'API de repos. mon problème est qu'après avoir rejoint l'eurotronic à deconz via l'application Phoscon, l'appareil eurotronic semble être ajouté à mon réseau zigbee (appareil ok, l'application phoscon a signalé "aucun appareil trouvé"), mais je ne peux pas voir l'appareil ni dans l'application phoscon ni au repos api. l'appareil lui-même a signalé une connexion réussie au réseau zigbee.

Est-ce que quelqu'un peut m'aider?

salut Bobby

Je crains que vous ayez besoin de lire les informations sur le cluster.
J'ai récemment acheté des thermostats supplémentaires et je devais effectuer la procédure pour chaque nouveau thermostat ajouté.

Merci pour l'information. existe-t-il un moyen de le faire sans interface graphique x11 ?

@BobbyXXX : j'ai utilisé x11vnc pour cela.

Même problème que BobbyXXX pour moi. J'utilise deconz dans docker (marthoc/deconz). Il n'y a donc pas d'interface graphique. J'ai testé Eurotronic Spirit ZigBee avec CC2531-Stick dans iobroker (basé sur zigbee2mqtt.io). L'appareil est reconnu en quelques secondes et utilisable dans iobroker.
Dans deconz l'appareil est appairé mais pas à trouver dans Phoscon ou REST

cordialement Kay

salut

Docker a une option pour VNC. Vous pouvez accéder à l'interface graphique via VNC.

Options :
-e DECONZ_VNC_MODE=1
-e DECONZ_VNC_PORT=5900

Merci. C'est ça. Je peux le rejoindre.
Merci

Kay
pour docker-compose :
- DECONZ_VNC_MODE=1
- DECONZ_VNC_PORT=5900
- DECONZ_VNC_PASSWORD=XXXX

Salut, En raison des messages ci-dessus, j'ai réussi à faire entrer le mien dans iobroker. Merci! Mais malheureusement, il n'affiche que quelques valeurs et aucune option pour définir une température, ni pour l'activer et la désactiver. Cela sera-t-il ajouté dans un avenir proche? Sinon, il est assez inutile et je dois le retourner. Y a-t-il quelque chose que je puisse faire moi-même ? (compétences de codage faibles) Merci beaucoup ! Wolfgang

Parce qu'il n'y a pas de Chance avec Deconz, j'ai changé l'Eurotronic Spirit Zigbee en un CC2531 chinois à 4$ et voilà ce que j'obtiens :

@Wolfgang :
J'utilise node-red avec iobroker. rweise a raison. Le CC2531 fonctionne bien avec ce thermostat, mais pas avec d'autres appareils. J'ai essayé les deux et je reste avec deconz.
Si vous travaillez avec node red, voici ma solution :
L'idée basée sur l'envoi d'une nouvelle température avec REST-API. Il y a deux boutons, pour augmenter et diminuer la température désirée. Cette température est stockée dans iobroker via node-red. La nouvelle température est envoyée à deconz via http-Request.
La description est en anglais. Nom des nœuds en allemand.

[ { "id": "8c13faa0.312318", "type": "ui_gauge", "z": "82a0e2b1.be156", "name": "Thermostat, Schlazimmer (SOLL)", "group": "62b68445.1ceddc", "order": 2, "width": "3", "height": "3", "gtype": "gage", "title": "Schlafzimmer (Soll)", "label": "°C", "format": "{{value}}", "min": "5", "max": "35", "colors": [ "#0092b5", "#00e627", "#b50000" ], "seg1": "20", "seg2": "25", "x": 1120, "y": 240, "wires": [] }, { "id": "ee827496.0baf08", "type": "http request", "z": "82a0e2b1.be156", "name": "", "method": "use", "ret": "txt", "url": "", "tls": "", "x": 1050, "y": 540, "wires": [ [] ] }, { "id": "16322cea.30f4f3", "type": "ui_button", "z": "82a0e2b1.be156", "name": "+ 1 °C", "group": "62b68445.1ceddc", "order": 3, "width": "2", "height": "1", "passthru": false, "label": "+ 1 °C", "tooltip": "", "color": "", "bgcolor": "firebrick", "icon": "", "payload": "100", "payloadType": "num", "topic": "", "x": 130, "y": 380, "wires": [ [ "d34474dd.fa8458" ] ] }, { "id": "ab90e2a6.95fc2", "type": "ui_button", "z": "82a0e2b1.be156", "name": "- 1 °C", "group": "62b68445.1ceddc", "order": 5, "width": "2", "height": "1", "passthru": false, "label": "- 1 °C", "tooltip": "", "color": "", "bgcolor": "#0092b5", "icon": "", "payload": "-100", "payloadType": "num", "topic": "", "x": 130, "y": 420, "wires": [ [ "d34474dd.fa8458" ] ] }, { "id": "d34474dd.fa8458", "type": "ioBroker get", "z": "82a0e2b1.be156", "name": "Schlazimmer, Temperatur (Soll)", "topic": "node-red.0.deconz.0.Sensor_7.heatsetpoint", "attrname": "heatsetpoint", "payloadType": "value", "x": 430, "y": 400, "wires": [ [ "f1878f12.b4c2d" ] ] }, { "id": "f1878f12.b4c2d", "type": "function", "z": "82a0e2b1.be156", "name": "Set_heatsetpoint", "func": "\nvar new_temp = {payload: (msg.heatsetpoint + msg.payload) }\nvar real_new_temp = {payload:new_temp.payload / 100}\n \n\nmsg.method = \"PUT\";\n// here put your own Apikey\nmsg.headers = { \"X-ApiKey\": \"XXXXXXXXX\" };\n\nvar data = {\"heatsetpoint\": new_temp.payload};\nmsg.payload = JSON.stringify(data);\n// here put sensor_id, mine is 7\nmsg.url = \"http://127.0.0.1/api/DB28CD6F62/sensors/7/config\"\n\nreturn [real_new_temp, new_temp, msg]\n\n\n", "outputs": 3, "noerr": 0, "x": 750, "y": 400, "wires": [ [ "8c13faa0.312318" ], [ "6a17be92.3e904" ], [ "ee827496.0baf08" ] ] }, { "id": "6a17be92.3e904", "type": "ioBroker out", "z": "82a0e2b1.be156", "name": "Schlazimmer, Temperatur (Soll)", "topic": "node-red.0.deconz.0.Sensor_7.heatsetpoint", "ack": "false", "autoCreate": "false", "x": 1110, "y": 400, "wires": [] }, { "id": "acd7e601.65e8f8", "type": "comment", "z": "82a0e2b1.be156", "name": "GUI to change Temperature", "info": "value that increases/decreases temperature\nhere: +/- 100 (-> 1°C)\n\nsaved to msg.payload", "x": 160, "y": 340, "wires": [] }, { "id": "2e589afa.4d0426", "type": "comment", "z": "82a0e2b1.be156", "name": "iobroker place to load heatsetpoint", "info": "This is to store the heatsetpoint somewhere\n\nI want to increase or decrease temperature, \nso i have to store it.\nCan be everywhere.\nIs here loaded to change temperature to:\n\nsaved to msg.heatsetpoint", "x": 440, "y": 360, "wires": [] }, { "id": "edd2e760.bdea58", "type": "comment", "z": "82a0e2b1.be156", "name": "iobroker place to store heatsetpoint", "info": "Here the new temperature is stored", "x": 1120, "y": 340, "wires": [] }, { "id": "b30bf85a.5aafc8", "type": "comment", "z": "82a0e2b1.be156", "name": "Gui of new temperature ", "info": "", "x": 1080, "y": 200, "wires": [] }, { "id": "1962d290.5e630d", "type": "comment", "z": "82a0e2b1.be156", "name": "http request", "info": "All information comes from function", "x": 1050, "y": 500, "wires": [] }, { "id": "f07d3e8e.499a6", "type": "comment", "z": "82a0e2b1.be156", "name": "Function to create Api-Call", "info": "Here you have to change your own API Information.\n- API key\n- Sensors ID", "x": 750, "y": 360, "wires": [] }, { "id": "62b68445.1ceddc", "type": "ui_group", "z": "", "name": "Temperatur", "tab": "e70b7e9b.cc318", "order": 2, "disp": true, "width": "6", "collapse": true }, { "id": "e70b7e9b.cc318", "type": "ui_tab", "z": "", "name": "Werte", "icon": "dashboard", "order": 1, "disabled": false, "hidden": false } ]

Puis-je ajouter un CC2531 à mon Raspberry en plus de mon Conbee afin qu'ils coexistent en tant que deux coordinateurs sur des canaux différents ? Ce serait une solution de 5 à 8 $ et une solution rapide ?

Oui tu peux et je le fais :-)
Kaykoch a raison, deconz a plus d'options et un meilleur support. j'utilise beaucoup de trucs xiaomi. Et deconz a souvent un moyen facile d'automatiser, car il y a une option "dernière mise à jour" qui me manque dans zigbee.
Mais parce qu'il n'y a aucun moyen de travailler facilement avec les thermostats, j'utilise également un bâton Zigbee avec l'adaptateur iobroker zigbee. Les deux fonctionnent très bien et la distance entre le bâton Zigbee à 5 $ et le thermostat est de 6 m avec un mur de pierre de 24 cm entre les deux.

Enfin, j'espère que dresden-elektronik y parviendra, que le Spirit Zigbee fonctionnera avec deconz comme il fonctionne avec zigbee. Normalement, ils ont un très bon support.

Et voilà, la lumière rouge sur deconz et la verte est le bâton zigbee.

Et voici votre version :-)

S'ils sont de D, j'ai plusieurs bâtons...

Salut,
Je viens d'Autriche et j'attends que le mien vienne de Chine. Comme je n'ai besoin que d'un bâton, je n'ai pas de clignotant, etc. S'il n'arrive pas, je me ferai un plaisir de vous contacter...
Merci :)

Seulement pour toi. Rechercher sur Ebay pour jblack_de Écrivez-moi ici,
quand tu m'as envoyé ton adresse via eBay N'achète rien !!! elle
puis recevez une lettre entièrement gratuite à Nach dans quelques jours
L'Autriche...

Tout simplement parce que je peux :-) et j'aime aider...

realwax [email protected] a écrit le mardi 16 avril 2019, 19h22 :

Salut,
Je viens d'Autriche et j'attends que le mien vienne de Chine. Puisque je n'ai que
Je n'ai pas besoin de bâton, je n'ai pas de clignotant etc. S'il n'arrive pas,
J'aime entrer en contact...
Merci :)

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-483767001 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ANHUcloaKts41eqCWnYzlAtZmRXz-NQOks5vhgbQgaJpZM4Zz_-1
.

Je ne sais pas combien de temps prendra le post. J'ai besoin de 24 heures à compter de la réception de l'adresse
pour l'envoi

René Weise [email protected] a écrit le 20h06 :

Seulement pour toi. Rechercher sur Ebay pour jblack_de Écrivez-moi ici,
quand tu m'as envoyé ton adresse via eBay N'achète rien !!! elle
puis recevez une lettre entièrement gratuite à Nach dans quelques jours
L'Autriche...

Tout simplement parce que je peux :-) et j'aime aider...

realwax [email protected] a écrit le mardi 16 avril 2019, 19h22 :

Salut,
Je viens d'Autriche et j'attends que le mien vienne de Chine. Comme je
Je n'ai besoin que d'un bâton, je n'ai pas de clignotant, etc.
Je serai ravi de prendre contact...
Merci :)

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-483767001 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ANHUcloaKts41eqCWnYzlAtZmRXz-NQOks5vhgbQgaJpZM4Zz_-1
.

Si cela ne fonctionne pas sur eBay. J'ai ma boite mail sur gmail et mon pseudo ici est la première lettre du prénom suivi du nom. Sur Google, le nom de famille commence à partir d'un point suivi. Ensuite, vous pourriez l'essayer avec René devant le @ 😂 Veuillez également écrire ici que vous avez envoyé un message ...

@rweise Je suis entré en contact via gmail. LG Wolfgang

Est en route, amusez-vous avec :-)

Le mercredi 24 avril 2019 à 13h15, realwax a écrit < [email protected]

:

@rweise https://github.com/rweise Je suis entré en contact via gmail. LG
wolfgang

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-486180283 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADI5I4SBJ4R6C7FDAASRKRTPSA6OJANCNFSM4GOP762Q
.

Je suis également tombé sur cet appareil récemment. La version Z-Wave a la particularité intéressante de supporter des capteurs de température externes (qui peuvent donner des lectures plus réalistes que l'interne).
Parmi ceux qui ont déjà l'appareil, savez-vous si cela est (ou sera) également possible via Zigbee ? Le site du fabricant est malheureusement très clairsemé.

j'ai cette question aussi. est-il possible d'implémenter cela aussi à l'api ?

Si vous pouvez me le dire, et comment, la version Zigbee le prend en charge. Je n'ai pas réussi à le configurer.

je ne suis pas si profond dans la norme zigbee mais j'ai trouvé ceci dans un pdf du fabricant :
identifiant d'attribut : 0x001A
Valeur par défaut : 0x00
Type de données : 0x18 (bitmap 8 bits)
Lecture/écriture : RW
Spécifique au fabricant : N0
Signalable : Non

J'espère que ceci vous aide :)

https://eurotronic.org/wp-content/uploads/2019/01/Spirit_ZigBee_BAL_web_DE_view_V9.pdf

J'ai trouvé cela aussi, mais cela ne me donne aucune idée de la façon de lier le capteur de température externe. J'ai essayé de définir cet attribut et de lier le TRV à un cluster _Temperature Measurement_ de l'un de mes capteurs de mouvement Hue, mais aucune joie.

on dirait qu'il n'est pas possible d'envoyer une température ? et je dois "lier" un autre appareil zigbee avec une lecture de température avec le thermostat ?

à partir du pdf Il semble que je doive envoyer la température réelle dans un cluster 8 bits et tout devrait bien se passer

identifiant d'attribut : 0x001A
Valeur par défaut : 0x00
Type de données : 0x18 (bitmap 8 bits)
Lecture/écriture : RW

à partir du pdf Il semble que je doive envoyer la température réelle dans un cluster 8 bits et tout devrait bien se passer

Je me posais la question aussi. Mais vous pouvez voir que le type de données est un bitmap (c'est-à-dire un tas de drapeaux à basculer) et non un nombre "int" (comme pour les autres températures dans le PDF).
deCONZ permet de basculer ces drapeaux. L'une des options est quelque chose comme "Utiliser un capteur de température externe". Cela peut être activé à l'aide du bitmap, mais je ne comprends pas comment envoyer la température réelle.

Il était déjà pris en charge très tôt dans deCONZ, il semble donc qu'il s'agisse d'un attribut ZigBee standard. Pourtant, je me demande si de telles choses sont censées se produire via des liaisons (que le thermostat ne prend pas en charge si je ne me trompe), alors pourquoi avoir ce bitmap?

D'après le manuel, il devrait également être possible d'utiliser un capteur de fenêtre externe, mais la situation est la même...

Soit on se renseigne à nouveau auprès du constructeur, soit on arrive à les voir sur un salon (comme IFA en septembre à Berlin)... ;-)

Je serais également très intéressé par l'Eurotronic, cependant je suis plutôt nouveau sur hass.io et python

Quelqu'un peut-il résumer ce qui fonctionne et ce qui ne fonctionne pas ? Je recherche des thermostats et j'ai déjà une clé Conbee II, j'aimerais donc l'utiliser pour contrôler les thermostats.
Merci!

Je peux vous dire ce qui fonctionne _en combinaison avec l'interface Home Assistant_ :

1. Lecture des valeurs de température du capteur de température
2. Réglage de la température de consigne/cible
3. Éteindre l'appareil

Ce qui ne fonctionne pas :

1. Réglage du mode CVC/système sur off bien qu'annoncé comme mode CVC possible
2. Activer la télédétection (si j'ai bien compris, il est possible de définir un capteur de température à distance ; cela a du sens lorsque le thermostat est proche du niveau du sol/du plafond et a des valeurs trop basses pour réguler la température ambiante attendue)

Je n'ai pas enquêté davantage sur la localisation des problèmes, mais je pense que l'activation de la télédétection est une option du réseau/appareil ZigBee interne et doit être résolue dans deCONZ jusqu'à présent.

si j'ai bien compris, il est possible de régler un capteur de température à distance

Comment? Je n'ai pas pu configurer cela sur la version ZigBee de l'Eurotronic Spirit.

Comment modifier la valeur de la position de la vanne via l'API lorsque je suis en mode TRV « Unknown 2 » ?
Si j'appelle " http://localhost/api/XXXX/sensors/2/state " via PUT avec le contenu "{"valve": 127}", alors j'obtiens "[{}]" comme retour. Si je le fais via l'application deCONZ, la valeur est modifiée directement.

Vous ne pouvez METTRE que l'état des capteurs CLIP, pas des capteurs ZigBee. L'API REST ne prend pas en charge le réglage direct de la position de la vanne, uniquement via le point de consigne de température.

Doit l'avoir manqué dans la documentation de l'API. Est-ce prévu pour les futures versions ?

Non. Il n'y a pas non plus de support API pour le mode TRV.

Pourquoi voudriez-vous cela? Écrivez-vous votre propre contrôleur PID ?

Oui avec dépendances par exemple "chez vous", "pas chez vous" et "en vacances". Ou température extérieure et température ambiante. Ou le rayonnement solaire dans la pièce, de sorte que le système sache également que la pièce est chauffée par le soleil.

Je suis désolé, je ne comprends pas ce que vous essayez de réaliser. N'est-il pas beaucoup plus simple de régler la température cible et de laisser le TRV gérer la position de la vanne ?

La température extérieure ou la pièce chauffée par le soleil sont importantes lorsque vous avez un seul thermostat d'ambiance pilotant la chaudière de chauffage central et que vous souhaitez toujours chauffer d'autres pièces. Le TRV ne pilote qu'un seul radiateur, n'influençant que la température de la pièce dans laquelle il se trouve.

Imaginez qu'il est tôt le matin et que vous contrôliez le thermostat via votre panneau de commande Smarthome en fonction de l'heure. Alors le soleil se lève, mais c'est nuageux. La vanne s'ouvre à 80 %.
Même scénario, mais ce n'est pas nuageux. Le soleil brille dans la pièce, la vanne ne s'ouvre qu'à 20 %, car le soleil chauffe la pièce en soutenant.
Si je la règle au-dessus de la température cible, par exemple à 22 degrés, la vanne se lève beaucoup plus qu'elle ne le devrait.
De plus, la chaleur s'accumule en un point sur mon radiateur et un thermostat extérieur est obligatoire.
Je devrais le régler à 26 degrés, bien que la pièce ne devrait avoir que 22 degrés, pour que la vanne ne se ferme pas trop tôt par erreur. Cela semble déroutant, mais cela a plus de sens dans mon cas. Par conséquent, la question de savoir si cela vous demanderait beaucoup d'efforts pour mettre en œuvre cela.

Non. Il n'y a pas non plus de support API pour le mode TRV.
Pourquoi voudriez-vous cela? Écrivez-vous votre propre contrôleur PID ?

Je soutiendrais ça aussi.

Depuis que je n'ai trouvé aucun moyen de lier le TRV à un capteur de température à distance jusqu'à présent après avoir essayé les liaisons de périphérique et lu les documents ZigBee spec + TRV.
(Sceanrio était : thermostats près du sol avec des valeurs de température erronées/trop basses de sorte que la régulation est défectueuse en raison de valeurs de retour erronées)

La seule solution consistant à contourner ce problème consiste à implémenter/utiliser un algorithme/modèle PID dans Home Assistant ou NodeRed et à lier ces entités à un niveau d'application supérieur.

Comme @cinemarene l'a décrit, cette solution offre beaucoup plus de possibilités comme des automatisations basées sur le temps.

La mise en œuvre du contrôle direct de la position de la vanne impliquerait la création config ressources state pour signaler le mode TRV réel. Je vois encore des hoquets occasionnels où deCONZ perd temporairement la route vers le TRV, il peut donc être prudent de les mettre à jour en utilisant le mécanisme config.pending . C'est une bonne quantité de travail.

Personnellement, je n'ose pas régler la position de la vanne avant que les problèmes de routage ne soient résolus. En fait, je suis assez satisfait de l'algorithme PID du TRV, qui utilise le cas échéant le décalage de température pour corriger la mesure du TRV. Mon défi est d'aligner le réglage du thermostat d'ambiance de mon chauffage central sur le réglage TRV (dont l'algorithme PID est rejeté lorsque la chaudière ne fournit pas d'eau chauffée), donc je ne travaillerai pas de sitôt sur le contrôle de la position de la vanne.

Je vois encore des hoquets occasionnels où deCONZ perd temporairement la route vers le TRV

Oui, ce serait assez sujet aux erreurs et pourrait se retrouver dans un sauna, d'autant plus qu'un de mes thermostats perd également la connexion pendant de plus longues périodes ;-)

En fait, je suis assez satisfait de l'algorithme PID du TRV, qui utilise le cas échéant le décalage de température pour corriger la mesure du TRV.

Je suis d'accord, la mise en œuvre d'un autre PID ne serait qu'une solution de contournement.
En attendant, je vais jouer un peu avec le décalage de température et peut-être approfondir le sujet du capteur à distance.

Je n'arrive pas à faire en sorte que deCONZ détecte mon Spirit ZigBee. J'ai ouvert l'application Web deCONZ et choisi d'ajouter un nouveau capteur. Ensuite, j'ai mis le thermostat en mode appairage (l'écran affiche INS) en insérant les piles et en l'installant sur le radiateur. Cependant, l'application web conbee II stick / deCONZ ne détecte pas mes appareils (j'en ai essayé 2). Je l'ai essayé plusieurs fois, également avec des piles neuves. J'ai même mis le thermostat directement à côté du manche - rien n'a fonctionné.

Comment avez-vous réussi à coupler deCONZ et le Spirit Zigbee ?

Essayez de vous connecter à deConnz via VNC. Que j'ai pu me connecter.

Ty, maintenant je suis un peu plus loin. Je suis connecté à deCONZ via VPN. Cependant, j'utilise Hass.io et Home Assistant 0.98.5. Si je choisis Permit Join it sais, veuillez utiliser l'application Web pour rejoindre. Cependant, si je clique sur ouvrir WebApp, rien ne se passe. Comment puis-je ouvrir la WebApp ? Je viens de savoir comment me connecter à l'App Phoscon et non à la WebApp.

Mise à jour : j'ai trouvé l'ancienne WebApp, mais l'appareil n'est toujours pas détecté.

Y a-t-il quelque chose qui me manque car je ne suis pas habitué aux nouvelles interfaces graphiques en dehors de Phoscon ?

J'ai la même configuration. Vous devez activer la connexion dans la configuration du plugin. Utilisez ensuite le client VNC pour vous connecter. Ensuite, vous verrez vos appareils.

et tu verras

Merci beaucoup!!! Je l'ai eu dans deDONZ et j'ai fait la découverte dans le menu de contrôle comme décrit dans le manuel d'utilisation. Y a-t-il d'autres étapes pour l'exposer à l'assistant à domicile ?

Si vous réussissez, vous devriez voir

en HA en intégration = deCONZ

si vous ne voyez pas, vous pouvez essayer ceci... pas sûr des étapes exactes,...

cliquez sur l'entité du thermostat, puis sur les informations de cluster (coin gauche en bas), vous devez avoir deux points dans la case.

pouvez sélectionner Périphérique activé et essayez de cliquer sur lire. Après quelques essais, je vois des deuxièmes points et un thermostat apparaître dans HA.

Ou vous pouvez essayer de réparer le thermostat.

Je l'ai réparé plusieurs fois et maintenant j'ai deux points. J'ai lu toutes les entités. Si je modifie la température sur l'appareil, je peux également lire la valeur mise à jour. Néanmoins, le périphérique d'entité activé renvoie un attribut non pris en charge et est maintenant gris. je ne peux pas non plus changer son nom

BTW, tous les paramètres de base de l'appareil semblent ne pas être pris en charge :

Je l'ai fait fonctionner maintenant. Merci beaucoup pour votre aide @rkotulan.

L'essentiel est qu'il a fallu ca. 7 tentatives de suppression et de rattachement jusqu'à ce que le TRV soit reconnu comme "Thermostat 22" au lieu du nom hexadécimal. Je ne sais pas pourquoi, mais tout à coup, immédiatement après la dernière adhésion, il a été directement reconnu dans HA.

J'intégrerai les deux autres les jours suivants et ferai rapport au cas où je ferais des observations divergentes.

Enfin, un pourrait trouver le moyen de coupler correctement cet appareil (il est donc exposé à l'API REST et apparaît dans Home Assistant). Voici les étapes :
1) Placez l'appareil juste à côté du bâton ConBee
2) Réinitialisez l'appareil (maintenez les 3 boutons enfoncés pendant 10 secondes puis relâchez jusqu'à ce qu'il redémarre et affiche "Jin" sur son écran)
3) Ouvrez l'application Phoscon et commencez à rechercher de nouveaux capteurs
4) Connectez-vous à Deconz via VNC et recherchez un nouvel appareil. C'est un point vert qui doit être vert fixe
5) Attendez que le point commence à clignoter de temps en temps
6) Ouvrez les informations sur le cluster de
7) Après cela, le nom de l'appareil doit passer du numéro hexadécimal à l'identifiant de modèle et le processus d'appariement sur l'application Phoscon doit se terminer avec succès.

Après cela, j'ai placé le thermostat sur le radiateur et j'ai appuyé deux fois sur le bouton Boost pour lancer l'étalonnage. Maintenant, tout fonctionne correctement.
PS> Je pense que le problème ici est avec le logiciel Deconz. Il devrait lire le cluster de base, lorsque le point solide sur le nœud commence à clignoter automatiquement, mais ce n'est pas le cas, l'utilisateur doit donc le faire manuellement pour terminer le processus d'appariement.

Merci @airens ! L'instruction a été très utile. Le thermostat est enfin apparu dans HA

Je peux aussi confirmer que la méthode @airens fonctionne ! (RaspBee Bridge sur un Raspberry Pi autonome, connecté à hass.io)

Merci!

Après quelques heures ennuyeuses, j'ai réussi à connecter l'esprit Eurotronic avec deCONZ. Je peux lire et écraser les valeurs dans les infos du cluster, mais l'esprit Eurotronic n'apparaît pas dans l'application Phoscon.
J'ai essayé de me connecter via un nœud au thermostat et installé node-red-contrib-deconz dans Node Red. Avec le deCONZ in-node, je peux appeler l'esprit Eurotronic et voir l'état ON, le taux d'ouverture de la vanne et la lecture du capteur de température interne.
Ce que je ne vois pas, c'est le point de consigne de température actuel, et je n'ai aucune option pour modifier le point de consigne.
Une idée de comment cela pourrait fonctionner ? Je pense que le deConz out-node, mais comment ?

Je peux confirmer les étapes de @airens . La lecture du cluster de base était un point important.

@dresden-elektronik : ce serait formidable, si le composant pouvait être lu automatiquement, comme n'importe quel autre.

Erreur dans l'application Phoscon : elle a été reconnue et fonctionne dans HA, mais n'apparaît toujours pas dans l'application Phoscon sous "Capteurs"...

PS : j'ai eu un comportement étrange dans l'assistant domestique après avoir défini une nouvelle température cible, l'instruction a été donnée correctement au thermostat, mais la température de l'interface graphique Web dans l'assistant domestique est revenue à l'ancienne valeur pendant que le thermostat fonctionnait à droite .. après une certaine attente, l'erreur a semblé disparaître d'elle-même .. juste sur la pile de trucs non reproductibles et merci pour le plaisir avec le mode de débogage @homeassistant 👯‍♂

L'Eurotronic Spirit ZigBee peut-il à ce stade être couplé simplement en utilisant l'application Phoscon ? Je prévois d'en obtenir un, mais mon deconz fonctionne en mode sans tête et je n'ai pas accès à l'interface utilisateur (fonctionnant sur Raspbian sans tête).

Vous pouvez vous connecter à Conbee avec VNC.

Comment ferais-je ça ?

Je pensais qu'il fallait utiliser l'application Phoscon pour appairer des appareils... Pourquoi cela ne peut toujours pas être fait avec l'Eurotronic Spirit ZigBee ?

Comment ferais-je ça ?

Je pense que se connecter directement à conbee était un malentendu, du moins je ne sais pas comment cela pourrait être possible. Mais vous ne pouvez pas vous connecter au deconz-gui via raspi vnc :

Bonnes instructions pour VNC sur Raspi
https://www.elektronik-kompendium.de/sites/raspberry-pi/2011121.htm

Serveur VNC à démarrage automatique
sudo x11vnc -storepasswd /etc/x11vnc.pass
sudo nano /lib/systemd/system/x11vnc.service

[Unité]
Description=Démarrer X11VNC
Après=multi-utilisateur.target

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -display :0 -auth guess -forever -loop -noxdamage -repeat -rfbauth /etc/x11vnc.pass -rfbport 5900 -shared

[Installer]
WantedBy=multi-user.target

sudo systemctl activer x11vnc.service

Ensuite, vous pouvez vous connecter avec des outils comme "Chicken of the VNC"

Pour exécuter deconz-gui au démarrage automatique, il devrait y avoir suffisamment d'informations, si vous google. Soyez juste un peu patient lorsque l'interface graphique démarre automatiquement car au début, vous verrez l'écran où vous pouvez sélectionner un appareil (comme conbee) et vous n'aurez qu'à attendre quelques secondes pour la connexion automatique à l'écran maillé

J'utilise Raspbian Buster Lite qui n'a complètement aucun bureau et cela n'a pas fonctionné pour moi...

Quoi qu'il en soit, alors pourquoi le thermostat ne peut pas être couplé avec Phoscon ? Cela sera-t-il un jour pris en charge ?

Dresden elektronik développe-t-il également la fixation openhab2 ? Je demande car le composant home assistant contient le type "Climat" mais pas la liaison Openhab2.

@merdok @donchrizz
Il existe un autre moyen de gestion à distance si vnc ne fonctionne pas ou si vous souhaitez économiser de la mémoire et utiliser simplement l'interface graphique comme option de débogage. Transférez X11 sur votre bureau.

par exemple avec Windows
1) Installez Cygwin & et excluez dans le pare-feu Windows / désactivez le pare-feu
2) Ouvrez le terminal Cygwin64
3) exécuter : startx -- -listen tcp &
4) exécuter : xhost + [ip_of_your_deconz_conbee_runnig_host]
5) éditez /lib/systemd/system/deconz-gui.service
6) Modifier la ligne - Environment="DISPLAY=[ip_of_your_deconz_conbee_runnig_host]:0"
7) exécuter : systemctl stop deconz
8) exécuter : systemctl démarrer deconz-gui

Une fois terminé, arrêtez simplement l'interface graphique et démarrez deconz sans interface graphique.
Lorsque vous répétez cela, vous devez à nouveau xhost sur cygwin pour autoriser la session.
Une erreur peut se produire avec le pare-feu Windows - vous souhaiterez peut-être le désactiver pendant le temps imparti.
Après la mise à jour de deconz, vous devrez peut-être refaire 5 et 6.
De cette façon, je n'ai pas besoin de x11vnc en cours d'exécution.

Bonne chance!

PS : J'attends avec impatience ce jour où Eurotronic pourra être ajouté et utilisé comme n'importe quelle autre ampoule/interrupteur Ikea. ;)

PS : J'attends avec impatience ce jour où Eurotronic pourra être ajouté et utilisé comme n'importe quelle autre ampoule/interrupteur Ikea. ;)

Je soutiens ce souhait de tout coeur!

En attendant, quelqu'un peut-il m'indiquer des informations sur la manière dont le thermostat Spirit est exposé à l'assistant à domicile ? En particulier, j'aimerais savoir s'il existe des preset_modes définis qui pourraient être définis par le service climate.set_preset_mode . De plus, est-il possible de déclencher le mode boost depuis l'assistant à domicile ?

Meilleures salutations

Comment l'ajouter a été couvert ci-dessus avec l'interface graphique et comment rejoindre et lire le cluster. De cette façon, le processus d'adhésion devrait se terminer et l'API REST exposer les valeurs. Comme cela ne fonctionnait pas très bien, je l'ai ajouté à un adaptateur zigbee (CC2530) et j'utilise iobroker et je ne peux pas vous aider là-bas. Ce sont les états que vous devriez obtenir.

Si vous parvenez à l'ajouter, cela vous aide davantage en termes de réglage des états sur l'affichage ou des modes. Fenêtre activée/désactivée, etc. Ajoutez simplement les valeurs, convertissez-la de HEX en DEC et définissez spz_system_mode en conséquence.

Je n'ai rien trouvé sur le net et je sais aussi qu'il y a du développement ici, mais je ne sais pas où demander. Les vôtres font-ils également le trajet de détartrage (Entkalkungsfahrt) tous les lundis vers 6 heures ?

Je crois que "Entkalkungsfahrt" n'est pas ce que vous vouliez dire :) peut-être pouvez-vous expliquer ?

Chaque lundi à 6h chacun de mes 5 thermostats ouvre et ferme une fois les vannes. Très ennuyeux quand on dort. Ils le font aussi, même si vous les réinitialisez et qu'ils ne sont connectés à aucun pont. Mode de calcul ou quelque chose.

Il pense ce qu'il dit. Ce n'est pas vrai pour la chaux, c'est plus pour faire quelque chose contre les valves fixes.
avant de commencer avec eurotronic, j'utilise des thermostats homematic et ils le font une fois par semaine pour éviter les vannes fixes. Et , je ne sais pas, si je préfère revenir en homematic, car j'ai beaucoup de mal avec les thermostats eurotronic. ils perdent les connexions et vous avez alors votre sauna personnel. J'écris un message à eurotronics et je demande s'il est possible de fermer les vannes en cas d'erreur et il n'y a pas de réponse. 100% ouvert c'est très mal...

Il pense ce qu'il dit. Ce n'est pas vrai pour la chaux, c'est plus pour faire quelque chose contre les valves fixes.
avant de commencer avec eurotronic, j'utilise des thermostats homematic et ils le font une fois par semaine pour éviter les vannes fixes. Et , je ne sais pas, si je préfère revenir en homematic, car j'ai beaucoup de mal avec les thermostats eurotronic. ils perdent les connexions et vous avez alors votre sauna personnel. J'écris un message à eurotronics et je demande s'il est possible de fermer les vannes en cas d'erreur et il n'y a pas de réponse. 100% ouvert c'est très mal...

Le mien n'a jamais perdu la connexion depuis six mois maintenant. Je le sais à coup sûr, car je viens de vérifier les journaux de l'assistant domestique. Je pense que vous devez améliorer la qualité du signal en ajoutant des routeurs à votre réseau ZigBee ou essayer de trouver une meilleure position pour Conbee.

@realwax merci ! J'ai utilisé MobaXterm et l'interface graphique fonctionne. Maintenant mon thermostat est appairé et fonctionne bien !

@manup ce serait bien si l'appairage pouvait se faire directement depuis l'application Phoscon. C'est assez gênant en ce moment. Est-ce prévu ?
De plus, un type de capteur de thermostat dans l'application Phoscon serait vraiment génial !

Quelqu'un obtient-il des informations sur le niveau de batterie du thermostat sur Home-Assistant ? Je ne vois pas le capteur de batterie associé au thermostat et j'aimerais le surveiller. Je peux voir l'indication de la batterie via VNC lorsque j'active "Lire le descripteur de puissance" pour le thermostat ; alors je peux voir l'icône de la batterie, mais même alors sur "Cluster Info", je vois des informations incohérentes :

Sur "Node Info", j'obtiens la lecture correcte :

Les informations correctes sur la batterie ont été chargées sur « Infos sur le cluster » après avoir cliqué sur le bouton « LIRE » :

Il est également lisible depuis Home-Assistant maintenant :

@rsaffi :Pour moi, la batterie

J'ai aussi les niveaux de batterie qui s'affichent dans homeassistant. Je suis sûr que je n'ai rien fait au-delà de la procédure d'appariement mentionnée ci-dessus.

Un bogue dans la mise en œuvre de l'assistant à domicile que j'ai rencontré est les valeurs min/max pour le thermostat. Alors que le manuel spécifie une plage de 5-30C, homeassistant a 7-35C et le réglage de la température cible au-delà de 30 entraîne une erreur. Je ne sais pas s'il s'agit d'un problème avec homeassistant ou dans deconz.

Un bogue dans la mise en œuvre de l'assistant à domicile que j'ai rencontré est les valeurs min/max pour le thermostat. Alors que le manuel spécifie une plage de 5-30C, homeassistant a 7-35C et le réglage de la température cible au-delà de 30 entraîne une erreur. Je ne sais pas s'il s'agit d'un problème avec homeassistant ou dans deconz.

J'ai remarqué cela aussi, mais j'ai oublié de faire rapport. C'est vrai : la portée sur l'appareil lui-même diffère de Home-Assistant.

Je ne peux pas vnc sur mon deconz. il s'exécute dans un conteneur docker sans tête sur mon serveur. y a-t-il un moyen de l'appairer complètement ? Je l'ai jumelé mais il n'apparaît nulle part :/

Comme beaucoup ici, le mien n'apparaît pas non plus sur l'application Web deCONZ sous "Capteurs", mais il s'est couplé avec succès et il est vu de l'intérieur de Home-Assistant. Comment savez-vous que vous l'avez associé s'il n'apparaît nulle part ?

Concernant VNC, vous devriez pouvoir le faire malgré le conteneur docker sans tête. Le mien est également installé sur un conteneur sans tête s'exécutant sur une machine virtuelle sans tête et je peux très bien y entrer VNC.

@rsaffi Après avoir recherché le capteur dans deconz, la barre verte avec "ajout réussi" est apparue

@rsaffi Après avoir recherché le capteur dans deconz, la barre verte avec "ajout réussi" est apparue

J'y ai été, j'ai fait ça. Comme l'intégration est au moins pour le moment, votre prochaine étape serait de vous connecter à VNC, de cliquer sur le périphérique Thermostat, puis de cliquer sur "Lire" pour les informations de cluster "Basique". Ensuite, votre appareil sur deCONZ passera de l'affichage du code hexadécimal à son nom propre et vous pourrez le voir depuis Home-Assistant.

@rsaffi je sais, le mien fonctionne parfaitement... je répondais à ta question :

Comment savez-vous que vous l'avez associé s'il n'apparaît nulle part ?

J'y ai été, j'ai fait ça. Comme l'intégration est au moins pour le moment, votre prochaine étape serait de vous connecter à VNC, de cliquer sur le périphérique Thermostat, puis de cliquer sur "Lire" pour les informations de cluster "Basique". Ensuite, votre appareil sur deCONZ passera de l'affichage du code hexadécimal à son nom propre et vous pourrez le voir depuis Home-Assistant.

Désolé si c'est une question stupide, mais cela signifie-t-il que le thermostat Eurotronics s'affichera dans Home Assistant et disposera de commandes de climatisation fonctionnelles ? J'ai récemment commencé à utiliser HA et je n'ai même pas encore essayé Zigbee2mqtt par exemple.

J'ai lu beaucoup de fils partout où ils ne peuvent pas régler une température. J'ai aussi vu toutes sortes de choses mais elles sont assez anciennes et les choses peuvent changer rapidement.

Une meilleure question pourrait être : qu'est-ce qui _ne_ fonctionne pas ? Merci!

Un peu de contexte si ça compte et que ça intéresse quelqu'un :
J'ai des planchers chauffants à l'eau (je suis sûr que ça s'appelle autrement) mais mes thermostats d'ambiance ne fonctionnent pas. Je ne peux donc changer la température de toutes les pièces en même temps que sur un seul thermostat dans un placard (c'est un robinet de radiateur ordinaire, comme celui d'Eurotronic mais ancien et analogique). Jusqu'à présent, j'ai deviné à quelle température le régler, car sa température et la température réelle dans les pièces sont très différentes.

J'espérais, au moins, faire la même chose facilement mais à partir de Home Assistant et, espérons-le, sans créer de scripts à partir de zéro (car j'apprends encore beaucoup). Fondamentalement, pouvoir facilement régler la température sur, par exemple, 22c. Peut-être que les chambres n'atteindront qu'à 19 °C, mais alors je pourrais simplement régler la température à 25 °C et elle serait plus proche de 22 °C dans les chambres.

Mieux encore, ce serait bien sûr de pouvoir utiliser mes capteurs de température Xiaomi que j'ai, donc je pourrais régler la température à 22c et le thermostat Eurotronic utiliserait les capteurs Xiaomi pour ajuster la température. Mais je suppose que ce peu est trop demander?

Désolé pour le long message et merci de m'avoir lu !

@ wuast94 Oui, il y a. Faites simplement défiler le fil vers le haut. J'ai posté comment transférer X11.... Von Samsung-Tablet gesendet
-------- Ursprüngliche Nachricht --------Von: wuast94 [email protected] Datum: 17.10.19 23:24 (GMTfused) An: dresden-elektronik/deconz-rest -plugin [email protected] Cc : Wolfgang [email protected] , Mentionnez [email protected] Betreff : Re : [dresden-elektronik/deconz-rest-plugin] [Demande d'assistance pour l'appareil] Eurotronic Spirit ZigBee (#1098) Je ne peux pas vnc sur mon deconz. il s'exécute dans un conteneur docker sans tête sur mon serveur. y a-t-il un moyen de l'appairer complètement ? Je l'ai jumelé mais il n'apparaît nulle part :/

—Vous recevez ceci parce que vous avez été mentionné.Répondez directement à cet e-mail, consultez-le sur GitHub ou désabonnez-vous.
[
{
"@context": " http://schema.org ",
"@type": "EmailMessage",
"action potentielle": {
"@type": "ViewAction",
"target": " https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098?email_source=notifications\u0026email_token =ADR3WLQL3G3DUVLCW3AVXBDQPDJ2VA5CNFSM4GOP4322YY3PNVWWWLQL3G3DUVLCW3AVXBDQPDJ2VA5CNFSM4GOP4322YY3PNVWWWLQL3G3DUVLCW3AVXBDQPDJ2VA5CNFSM4GOP4322YY3PNVWWWLQL2TULG3DUVLCW3.
"url": " https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098?email_source=notifications\u0026email_token =ADR3WLQL3G3DUVLCW3AVXBDQPDJ2VA5CNFSM4GOP4322YY3PNVWWLQLQL3G3DUVLCW3AVXBDQPDJ2VA5CNFSM4GOP4622YY3PNVWWWLQL3G3DUVLCW3AVXBDQPDJ2VA5CNFSM4GOP4322YY3PNVWW4XDFK2TULK,
"name": "Afficher le problème"
},
"description": "Afficher ce problème sur GitHub",
"éditeur": {
"@type": "Organisation",
"nom": "GitHub",
"url": " https://github.com "
}
}
]

Désolé si c'est une question stupide, mais cela signifie-t-il que le thermostat Eurotronics s'affichera dans Home Assistant et disposera de commandes de climatisation fonctionnelles ? J'ai récemment commencé à utiliser HA et je n'ai même pas encore essayé Zigbee2mqtt par exemple.

Oui, exactement ça. Cela fonctionne avec Home-Assistant. Comme le développement est en ce moment au moins, le faire apparaître sur Home-Assistant n'a que quelques étapes supplémentaires, mais cela fonctionne vraiment.

J'ai lu beaucoup de fils partout où ils ne peuvent pas régler une température. J'ai aussi vu toutes sortes de choses mais elles sont assez anciennes et les choses peuvent changer rapidement.

Une meilleure question pourrait être : qu'est-ce qui _ne_ fonctionne pas ? Merci!

Rien à ma connaissance, honnêtement. Je veux dire, le processus de configuration peut toujours être amélioré (sans avoir besoin des étapes supplémentaires susmentionnées), mais à part cela, tout fonctionne.

J'ai des planchers chauffants à l'eau (je suis sûr que ça s'appelle autrement) mais mes thermostats d'ambiance ne fonctionnent pas. Je ne peux donc changer la température de toutes les pièces en même temps que sur un seul thermostat dans un placard (c'est un robinet de radiateur ordinaire, comme celui d'Eurotronic mais ancien et analogique). Jusqu'à présent, j'ai deviné à quelle température le régler, car sa température et la température réelle dans les pièces sont très différentes.

J'espérais, au moins, faire la même chose facilement mais à partir de Home Assistant et, espérons-le, sans créer de scripts à partir de zéro (car j'apprends encore beaucoup). Fondamentalement, pouvoir facilement régler la température sur, par exemple, 22c. Peut-être que les chambres n'atteindront qu'à 19 °C, mais alors je pourrais simplement régler la température à 25 °C et elle serait plus proche de 22 °C dans les chambres.

Alors allez-y et obtenez-en un, car c'est faisable.

Mieux encore, ce serait bien sûr de pouvoir utiliser mes capteurs de température Xiaomi que j'ai, donc je pourrais régler la température à 22c et le thermostat Eurotronic utiliserait les capteurs Xiaomi pour ajuster la température. Mais je suppose que ce peu est trop demander?

Cela peut aussi être fait, mais pour cela, vous devrez vous salir un peu les mains et écrire le bon "Automatisation" pour Home-Assistant, mais ce n'est certainement rien d'extraordinaire.

Je me suis intéressé à la possibilité d'utiliser un capteur externe pour déterminer la température actuelle...

Dans le cluster Thermostat, j'ai trouvé l'attribut inscriptible Remote Sensing avec la possibilité de définir "Température locale détectée à distance", "Température extérieure détectée à distance" et "Occupation détectée à distance" mais aucun moyen de spécifier les capteurs externes.

Une question quelque peu connexe est de savoir s'il est possible de configurer la "détection de fenêtre ouverte" et de configurer un capteur de fenêtre externe comme mentionné dans le manuel à la p13 ("Die Fenster-Offen Erkennung kann durch einen externen Fensterkontakt aktiviert/deaktiviert werden")

Edit : peu importe. Je viens de me rendre compte que cela a été discuté plus tôt sans succès.

Salut les gars,

J'ai découvert que mes thermostats à alcool montrent un comportement étrange, alors que pendant quelques heures il n'y a pas de changement de température dans la pièce ou pas de changement d'entrée de l'assistant à domicile. Résultat : il se déconnectera et ne sera plus dans le réseau zigbee. Solution : j'appuie sur le bouton du milieu (o) du thermostat et il est directement de retour… ressemble à une sorte de mode veille… quelqu'un a-t-il des suggestions ? En ce moment je pense laisser tomber les thermostats à spiritueux et passer à l'homematic sans déconz...

Tchin Tchin,
chris

J'ai eu une expérience similaire. La première fois que cela s'est produit, j'ai pensé avoir fait une erreur lors du processus d'appairage initial, alors j'ai réinitialisé les thermostats et les ai réparés. Je n'ai eu aucun problème pendant une semaine environ, mais hier, un thermostat ne réagissait plus aux réglages de température de l'assistant domestique. J'ai changé la température manuellement une fois et maintenant elle réagit bien à nouveau. Cela ressemble au même problème que vous avez rencontré. Je pensais que c'était juste un problème aléatoire, mais je vais voir s'il y a un motif, si cela se reproduisait.

y a-t-il un moyen d'ajouter l'appareil via deconz, lorsque vous utilisez la configuration systemd de deconz?

Lorsque je VNC dans ma framboise sans tête, je peux arrêter le service et utiliser la session VNC pour voir l'appareil (je pense qu'il n'y a pas beaucoup d'informations pour l'identifier, à confirmer). Mais lors de la fermeture de deconz et du redémarrage du service systemd, l'appareil ne s'affiche pas.

Avez-vous suivi les étapes de https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment -460403451 ?

Le processus suivant a fonctionné pour moi sur une configuration raspbian sans tête :

• enregistrer la configuration de phoscon (sauvegarde)
• activer le démarrage sur l'interface graphique via raspi-config
• configurer/installer VNC
• redémarrer
• systemctl stop deconz et systemctl start deconz-gui
• démarrer VNC et ouvrir deconz
• ouvrez phoscon et rechargez la configuration sauvegardée
• réinitialiser le thermostat (devrait afficher Jin)
• rechercher des capteurs dans phoscon
• dans deconz ouvrez le cluster de base du thermostat et cliquez sur lire
• vérifier que l'appairage a été réussi dans phoscon
• sauvegarde de la configuration de phoscon
• quitter le serveur VNC
• systemctl stop deconz-gui et systemctl start deconz
• ouvrez phoscon et chargez la configuration à partir du fichier de sauvegarde

Je ne me souviens pas s'il était vraiment nécessaire de sauvegarder et de charger la configuration de phoscon mais une sauvegarde ne fait probablement pas de mal non plus.

J'ai demandé ceci dans un autre fil:
Je ne sais toujours pas comment obtenir d'autres valeurs que les valeurs inutiles dans ioBroker pour cette chose.
Par exemple, "heatsetpoint" apparaît dans le journal de l'adaptateur deconz dans ioBroker, mais je ne peux pas lire la valeur. Je l'ai essayé avec node Red.
Quelqu'un peut-il me donner un indice?
Merci beaucoup.

L'Esprit Eurotronic est insuffisant et buggy mis en œuvre à Deconz. Après de nombreuses tentatives, j'ai réussi à afficher l'Eurotronic Spirit dans l'application Deconz. Je peux lire toutes les informations de cluster et tout ce qui est affiché en tant que R / W peut également être écrit.
Pour reconnaître l'Eurotronic Spirit, vous devez appeler l'application Phoscon, ici l'Eurotronic Spirit est reconnu, mais pas affiché, l'application est certainement juste capable de contrôler les lumières.
Ainsi, dans le deConz IN-Node dans Node Red, je peux lire la température et l'état, dans le nœud OUT, si je sélectionne "Phoscon" comme serveur, rien ne s'affiche. L'Eurotronic Spirit est donc très mal intégré par Dresden Electronics.
Quelqu'un a-t-il une idée de la façon dont je peux non seulement lire mais aussi contrôler l'Eurotronic Spirit via Node Red ?

Avez-vous suivi les étapes du #1098 (commentaire) ?

Le processus suivant a fonctionné pour moi sur une configuration raspbian sans tête :

• enregistrer la configuration de phoscon (sauvegarde)
• activer le démarrage sur l'interface graphique via raspi-config
• configurer/installer VNC
• redémarrer
• systemctl stop deconz et systemctl start deconz-gui
• démarrer VNC et ouvrir deconz
• ouvrez phoscon et rechargez la configuration sauvegardée
• réinitialiser le thermostat (devrait afficher Jin)
• rechercher des capteurs dans phoscon
• dans deconz ouvrez le cluster de base du thermostat et cliquez sur lire
• vérifier que l'appairage a été réussi dans phoscon
• sauvegarde de la configuration de phoscon
• quitter le serveur VNC
• systemctl stop deconz-gui et systemctl start deconz
• ouvrez phoscon et chargez la configuration à partir du fichier de sauvegarde

Je ne me souviens pas s'il était vraiment nécessaire de sauvegarder et de charger la configuration de phoscon mais une sauvegarde ne fait probablement pas de mal non plus.

Il m'a fallu quelques essais, mais l'utilisation de la méthode de sauvegarde a fonctionné pour moi.
Le problème principal était qu'il n'était apparemment pas possible de donner un nom au nœud du thermostat. après avoir lu les données de base, il avait un nom générique et cela semblait fonctionner.

Il m'a fallu quelques essais, mais l'utilisation de la méthode de sauvegarde a fonctionné pour moi.
Le problème principal était qu'il n'était apparemment pas possible de donner un nom au nœud du thermostat. après avoir lu les données de base, il avait un nom générique et cela semblait fonctionner.

Vous pouvez modifier le nom du thermostat à l'aide de l'API rest. Pour ce faire, vous pouvez soit utiliser un client REST (comme Postman App ou l'extension Tabbed Postman Chrome) soit un outil de ligne de commande comme cURL.
Jetez un œil à la documentation de l'API REST http://dresden-elektronik.github.io/deconz-rest-doc/getting_started/ tout y est bien expliqué.
Une fois que vous avez votre clé API, obtenez une liste de tous les capteurs en exécutant une requête GET vers /api//capteurs. À partir de la réponse, lisez l'identifiant de votre thermostat. Exécutez ensuite une requête PUT vers /api//capteurs/avec les données suivantes { "nom" : "Nom personnalisé" }.
La commande cURL ressemblerait à ceci :
curl -X PUT -H "Type de contenu : application/json" -d '{"name":"Nom personnalisé"}' http://localhost :8080/api/01234abc56/sensors/4

Salut,

rkotulan a écrit :

Si vous réussissez, vous devriez voir

en HA en intégration = deCONZ

et je peux voir HA reconnaître un capteur.thermostat et un climat.thermostat.

Tout seul, il a dit que le capteur.thermostat n'est pas disponible :

Avez-vous une idée du problème ?

Bonjour, j'ai un bug aléatoire avec l'appareil. Je l'ai désactivé et automatique à plusieurs reprises avec l'API en utilisant simplement

{'mode': 'désactivé'}
{'mode' : 'auto'}

Cela fonctionne pendant un certain temps, mais après un moment le point de chaleur en auto reste à 500, il semble que l'appareil oublie la valeur précédente.

J'ai vu la même chose, surtout lors du passage de off à on (mode boost) ou vice versa. Cela semble être une "fonctionnalité" du firmware Spirit. Le mode off semble être lié à la détection d'ouverture de fenêtre à moitié implémentée.

Je règle uniquement le point de chaleur de mon automatisation et laisse le mode sur auto .

Ok, merci, donc je vais essayer d'envoyer mon propre point de chaleur en même temps que le paramètre auto > {'mode': 'auto', 'heatsetpoint':2200 }

Salut les gars,

si quelqu'un veut un thermostat Spirit Zigbee - j'en ai 3 à vendre :

https://www.ebay-kleinanzeigen.de/s-anzeige/eurotronic-spirit-zigbee-thermostat/1249146122-84-9062

n'hésitez pas à me contacter là-bas...

Avez-vous suivi les étapes du #1098 (commentaire) ?

Le processus suivant a fonctionné pour moi sur une configuration raspbian sans tête :

• enregistrer la configuration de phoscon (sauvegarde)
• activer le démarrage sur l'interface graphique via raspi-config
• configurer/installer VNC
• redémarrer
• systemctl stop deconz et systemctl start deconz-gui
• démarrer VNC et ouvrir deconz
• ouvrez phoscon et rechargez la configuration sauvegardée
• réinitialiser le thermostat (devrait afficher Jin)
• rechercher des capteurs dans phoscon
• dans deconz ouvrez le cluster de base du thermostat et cliquez sur lire
• vérifier que l'appairage a été réussi dans phoscon
• sauvegarde de la configuration de phoscon
• quitter le serveur VNC
• systemctl stop deconz-gui et systemctl start deconz
• ouvrez phoscon et chargez la configuration à partir du fichier de sauvegarde

Je ne me souviens pas s'il était vraiment nécessaire de sauvegarder et de charger la configuration de phoscon mais une sauvegarde ne fait probablement pas de mal non plus.

Mon esprit ne se connecte pas à deConz. J'exécute Home Assistant sur un RPI 2. J'ai installé l'addon deConz, je l'ai ajouté et intégré dans HA, je me suis connecté à deConz via VNC et j'ai configuré l'application Phoscon. Lorsque je vais sur "ajouter des capteurs" dans l'application Phoscon, il recherche, mais le Spirit ne se connecte pas. Il dit juste "Jin", mais rien ne se passe. La seule chose que je vois dans deConz est le truc bleu par défaut qui dit "Coordinateur" lorsque vous cliquez dessus. J'ai raté une étape ?

Comme @ebaauw l'a dit dans le post suivant, dois-je ajouter une lampe avant de pouvoir ajouter mon thermostat ?
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1442#issuecomment -484840592

Edit : d'accord, alors j'ai fait un peu de lecture. Le thermostat est un appareil terminal, a-t-il donc besoin d'un routeur pour se connecter ? Je pensais pouvoir brancher le thermostat directement sur le RaspBee..

Je pensais pouvoir connecter le thermostat directement au RaspBee.

Le RaspBee (ou n'importe quel coordinateur ZigBee) est bien un routeur ; vous devriez pouvoir y connecter l'Esprit. Notez qu'un routeur n'autorise qu'un nombre limité de périphériques connectés - vous ne savez pas quelle est la limite actuelle pour le RaspBee : 10 ou 16 ou quelque chose. Pour plus de terminaux, vous avez besoin de routeurs supplémentaires.

Je pensais pouvoir connecter le thermostat directement au RaspBee.

Le RaspBee (ou n'importe quel coordinateur ZigBee) est bien un routeur ; vous devriez pouvoir y connecter l'Esprit. Notez qu'un routeur n'autorise qu'un nombre limité de périphériques connectés - vous ne savez pas quelle est la limite actuelle pour le RaspBee : 10 ou 16 ou quelque chose. Pour plus de terminaux, vous avez besoin de routeurs supplémentaires.

Je n'ai aucun appareil connecté, j'ai tout récupéré aujourd'hui et je l'ai entièrement configuré. Une idée de pourquoi mon Spirit ne se connecte pas au RaspBee alors ?

Très probablement un mauvais signal radio. Quelle est la distance entre le thermostat et le RaspBee ? Essayez de connecter le Raspberry au réseau et désactivez le WiFi et le Bluetooth. Recherchez au mieux les appareils de Phoscon, puis insérez la batterie dans le Spirit. Peut-être réinitialiser le Spirit en appuyant/maintenant les trois boutons simultanément (le compte à rebours commence après quelques secondes).

Très probablement un mauvais signal radio. Quelle est la distance entre le thermostat et le RaspBee ? Essayez de connecter le Raspberry au réseau et désactivez le WiFi et le Bluetooth. Recherchez au mieux les appareils de Phoscon, puis insérez la batterie dans le Spirit. Peut-être réinitialiser le Spirit en appuyant/maintenant les trois boutons simultanément (le compte à rebours commence après quelques secondes).

Que je sois damné! 2h je jouais avec cette merde ! J'étais assis à 2 m de lui et je ne pensais pas que le signal serait le problème ! C'est connecté !

ZigBee utilise la bande 2,4 GHz, tout comme le WiFi, le Bluetooth, le DECT, un four à micro-ondes, etc. Essayez de passer au canal ZigBee 25 - qui se chevauche le moins avec le WiFi. Attention au métal dans les murs, les meubles, les boîtiers de lampes, ...

Fini merci! Je n'arrive pas à faire apparaître l'Esprit dans HA cependant. J'ai déjà lu les données de base, de puissance et thermiques dans deConz, mais dans HA deConz n'affiche que "Phillips Daylight" et "Phoscon-GW" (la passerelle). J'ai ajouté deConz automatiquement en utilisant la découverte. D'après ce que j'ai lu ici, l'Esprit apparaît automatiquement dans HA.

Avez-vous redémarré HA après avoir appairé le Spirit ? Avez-vous revérifié que l'API REST expose le Spirit (si le nom dans l'interface graphique a changé par rapport à l'adresse réseau qu'il fait).

Avez-vous redémarré HA après avoir appairé le Spirit ? Avez-vous revérifié que l'API REST expose le Spirit (si le nom dans l'interface graphique a changé par rapport à l'adresse réseau qu'il fait).

J'ai redémarré, mais je ne pense pas que l'API REST expose l'Esprit. Pouvez-vous poster une photo de quel nom dans l'adresse réseau vous voulez dire exactement ? Juste pour être sûr

Le nœud bleu pour le RaspBee affiche l'adresse NWK (0x0000) ; le nœud gris pour le Spirit montre le name de la ressource REST API /sensors (je l'ai changé après l'appairage, il montre probablement Thermostat 2 ou quelque chose).

Le nœud bleu pour le RaspBee affiche l'adresse NWK (0x0000) ; le nœud gris pour le Spirit montre le name de la ressource REST API /sensors (je l'ai changé après l'appairage, il montre probablement Thermostat 2 ou quelque chose).

Hm non, il affiche toujours 0x9348. Lorsque je le modifie manuellement dans les informations sur le nœud, la « LED » de gauche clignote en rouge et en bas à gauche, elle indique « envoi de la demande de définition de descripteur d'utilisateur », mais rien ne se passe. Comment puis-je lui faire exposer l'API REST ?

Bon j'ai compris ! J'ai dû faire une recherche de capteur dans l'application Phoscon puis relire les données de base.

Mon Esprit ne lit pas la bonne température. Je l'ai réinstallé sur un radiateur différent et même si le radiateur est juste légèrement chaud, le Spirit affiche 31°C. Ce n'est même pas près de ça. Cela fait une heure maintenant et la température n'a toujours pas changé. Des idées? Pas sûr que l'utilisation du décalage soit la bonne façon de gérer cela. De plus, la température était affichée correctement auparavant sur l'autre radiateur.

Pas sûr que l'utilisation du décalage soit la bonne façon de gérer cela.

C'est à ça que sert l'offset, je suppose.

Cela fait une heure maintenant et la température n'a toujours pas changé.

Assurez-vous que le rapport d'attributs a été correctement configuré. Sinon, deCONZ continuera à afficher l'ancienne température. Appuyez sur _Lire_ sur les attributs du cluster _Thermostat_ pour vérifier si la valeur a changé.

J'ai un nouveau journal étrange

2019-11-08 18:47:51.563 Statut : (deconz) Débogage du thermostat : {'config': {'heatsetpoint': 2100, 'reachable': True, 'mode': 'off', 'on': True, 'battery' : 100, 'offset' : 0}, 'id' : '85', 't' : 'event', 'e' : 'changed', 'r' : 'sensors', 'uniqueid' : ' 00:15:8d:00:00:92:3b:6c-01-0201'} 2019-11-08
18:49:39.847 Statut : (deconz) Débogage du thermostat : {'uniqueid': '00:15:8d:00:00:01:92:3b:6c-01-0201', 'id': '85', 't ' : 'événement', 'état' : {'on' : vrai, 'valve' : 24, 'dernière mise à jour' : '2019-11-08T17:49:39', 'température' : 2105}, 'r' : 'capteurs', 'e' : 'modifié'}
2019-11-08 18:49:39.900 Statut : (deconz) Débogage du thermostat : {'uniqueid': '00:15:8d:00:01:92:3b:6c-01-0201', 'id': ' 85', 't' : 'événement', 'état' : {'on' : vrai, 'valve' : 24, 'dernière mise à jour' : '2019-11-08T17:49:39', 'température' : 2105} , 'r' : 'capteurs', 'e' : 'modifié'}

L'appareil envoie le mode "off", mais il a toujours la vanne ouverte et allumée = vrai.

J'ai lu tout le fil mais je ne sais pas comment lire la position actuelle de la vanne (je voudrais vérifier que la vanne fonctionne correctement).
Si je règle le mode TRV sur "Unknown 2", il semble que l'affichage de la vanne indique le pourcentage d'ouverture ?
Est-il possible d'obtenir cette valeur directement ? Merci

@ebaauw , est-il possible de régler la "Limite maximale du point de consigne de chaleur" pour ce thermostat à au moins 40 degrés par défaut ? Vous savez, en Russie, 30 degrés ne suffisent pas. Je peux le régler manuellement via VNC, mais dans Home Assistant, j'ai toujours une limite à 30.

Le Spirit supporte des températures cibles de 5°C à 30°C. C'est également la plage que vous pouvez définir à l'aide de ses boutons physiques. Le plug-in de l'API REST applique cette plage :
https://github.com/dresden-elektronik/deconz-rest-plugin/blob/8bd724cef41aba17536acacb486355d0080e9ee2/resource.cpp#L225
L'API n'expose pas la plage, c'est donc probablement du code dur dans le plugin/liaison HA pour deCONZ. Je l'ai codé en dur dans homebridge-hue.

Je peux le régler manuellement via VNC

Le Spirit semble avoir sa propre version de la norme ZigBee : il utilise un attribut spécifique au fabricant pour le point de consigne : _Current Temperature Setpoint_, 0x4003. Bien qu'il semble accepter de définir le _point de consigne de chauffage occupé_ standard, 0x0012, il (parfois) ne l'honore pas. Idem pour la commande standard _Setpoint Raise/Lower_. Moral : assurez-vous de lire _Current Temperature Setpoint_ pour vérifier que le Spirit a bien accepté la valeur.

Notez que la plage de points de consigne prise en charge est exposée par le Spirit lui-même, dans les attributs 0x0015 et 0x0016.

Le Spirit supporte des températures cibles de 5°C à 30°C. C'est également la plage que vous pouvez définir à l'aide de ses boutons physiques. Le plug-in de l'API REST applique cette plage :
https://github.com/dresden-elektronik/deconz-rest-plugin/blob/8bd724cef41aba17536acacb486355d0080e9ee2/resource.cpp#L225

L'API n'expose pas la plage, c'est donc probablement du code dur dans le plugin/liaison HA pour deCONZ. Je l'ai codé en dur dans homebridge-hue.

Je peux le régler manuellement via VNC

Le Spirit semble avoir sa propre version de la norme ZigBee : il utilise un attribut spécifique au fabricant pour le point de consigne : _Current Temperature Setpoint_, 0x4003. Bien qu'il semble accepter de définir le _point de consigne de chauffage occupé_ standard, 0x0012, il (parfois) ne l'honore pas. Idem pour la commande standard _Setpoint Raise/Lower_. Moral : assurez-vous de lire _Current Temperature Setpoint_ pour vérifier que le Spirit a bien accepté la valeur.

Notez que la plage de points de consigne prise en charge est exposée par le Spirit lui-même, dans les attributs 0x0015 et 0x0016.

D'accord, il semble que l'utilisation de « l'étalonnage de la température locale » soit le seul moyen de réchauffer mes radiateurs. Je l'ai configuré via VNC et cela fonctionne pour l'instant. J'espère que l'appareil ne réinitialisera pas cette valeur tout seul

Uniquement lorsque vous réinitialisez l'appareil (en maintenant les trois boutons enfoncés pendant 10 secondes). Notez que cet étalonnage est exposé comme config.offset par l'API REST. Il est prévu lorsque le thermomètre intégré à l'appareil enregistre la mauvaise température ambiante, généralement parce qu'il est trop proche du radiateur.

Malheureusement, nous n'avons pas été en mesure de lier le Spirit à un thermomètre externe, même si la documentation et l'attribut _Remote Sensing_ (0x000a) suggèrent qu'il le prendrait en charge.

Salut. Petite question : quel est l'état de la mise en œuvre ? J'aimerais acheter certains de ces Eurotronic Spirit. J'utilise Deconz+Home Assistant.

Salut. Petite question : quel est l'état de la mise en œuvre ? J'aimerais acheter certains de ces Eurotronic Spirit. J'utilise Deconz+Home Assistant.

Bonjour, appariement un peu délicat, mais dans cette rubrique vous pouvez trouver la méthode de travail.
Choses qui fonctionnent dans Home Assistant :

• Contrôle de la température de consigne dans la plage 7-30degC
• Lecture de la température actuelle du radiateur, de la position de la vanne et de la batterie

Les choses, ça ne marche pas :

• Commande manuelle de la vanne
• Télédétection de la température
• Étalonnage de la température actuelle du radiateur (peut être effectué via VNC)

Quant à moi - excellent appareil pour son prix.

@airens
Merci pour la réponse rapide. Ok maintenant je n'ai plus qu'à chercher les bonnes offres.

@airens Comment lisez-vous exactement la position de la vanne ? Je n'ai pas réussi à trouver le bon attribut.

Pour la télédétection de la température, une autre astuce utilisée par les utilisateurs de la version Z-wave consiste à utiliser le « Measured Temperature Offset » pour compenser régulièrement la différence entre le capteur de température interne de la vanne et le capteur de température externe :
https://community.home-assistant.io/t/eurotronic-spirit-z-wave-external-temperature-sensor/88430/6

Mais je ne sais pas si on peut modifier le 'Measured Temperature Offset' avec la version Zigbee ?

@airens Comment lisez-vous exactement la position de la vanne ? Je n'ai pas réussi à trouver le bon attribut.

Pour la télédétection de la température, une autre astuce utilisée par les utilisateurs de la version Z-wave consiste à utiliser le « Measured Temperature Offset » pour compenser régulièrement la différence entre le capteur de température interne de la vanne et le capteur de température externe :
https://community.home-assistant.io/t/eurotronic-spirit-z-wave-external-temperature-sensor/88430/6

Mais je ne sais pas si on peut modifier le 'Measured Temperature Offset' avec la version Zigbee ?

Oui, nous pouvons modifier le décalage de la température mesurée en définissant l'attribut "Calibrage de la température locale". Vous pouvez le voir comme "offset" dans HA, mais, malheureusement, vous ne pouvez le changer que via REST ou VNC

state.valve est la valeur de 'PI Heating Demand' ? Et c'est censé être un pourcentage de l'ouverture ? (c'est-à-dire entre 0-100%) ?
Pour moi, il semble que la valeur de « Demande de chauffage PI » ne soit pas du tout la même que la valeur affichée sur la vanne lorsque je règle le mode TRV sur « Inconnu 2 ». Je vais devoir revérifier.

Modifier le "offset" dans HA, est-ce un problème que nous ne pouvons le modifier que via REST ? Je vais devoir jouer avec HA et voir si je peux adapter le script utilisé par les personnes utilisant la version Z-wave.

state.valve est la valeur de 'PI Heating Demand' ? Et c'est censé être un pourcentage de l'ouverture ? (c'est-à-dire entre 0-100%) ?

Oui c'est le cas. c'est 0-254, donc, vous devez le mapper à 0-100

Modifier le "offset" dans HA, est-ce un problème que nous ne pouvons le modifier que via REST ? Je vais devoir jouer avec HA et voir si je peux adapter le script utilisé par les personnes utilisant la version Z-wave.

Ce n'est pas un problème, mais je ne pense pas que ce soit une bonne idée, en raison de la durée de vie de la batterie (dans ce cas, la valve a été déplacée trop fréquemment et la quantité de paquets ZigBee augmente considérablement). Je l'ai fait dans un premier temps, mais plus tard, j'ai dû abandonner cela. Maintenant, j'utilise simplement l'automatisation simple dans NodeRed, qui modifie la température de consigne du thermostat en fonction de la température ambiante

Comment lisez-vous exactement la position de la vanne ?

L'esprit le signale comme _PI Heating Demand_ (attribut 0x0008). Il s'agit d'une u8 , comprise entre 0 et 254. L'API l'expose sous la forme state.valve , normalisée entre 0 et 100 %.

Pour moi, il semble que la valeur de « Demande de chauffage PI » ne soit pas du tout la même que la valeur affichée sur la vanne lorsque je règle le mode TRV sur « Inconnu 2 ».

Le Spirit utilise des attributs spécifiques au fabricant (dans la plage 0x4000) pour les réglages, en particulier 0x4001 pour régler manuellement la position de la vanne. Cet attribut n'est pas à signaler, je suppose donc qu'il ne représente que la position de la vanne cible. Je m'attendrais / j'espère continuer à voir la position actuelle de la vanne en 0x0008, mais peut-être que cela n'est mis à jour que lorsque le Spirit est en mode automatique (par défaut). Vous voudrez peut-être vérifier si l'affichage reflète 0x4001 en mode Inconnu 2.

Comment lisez-vous exactement la position de la vanne ?

L'esprit le signale comme _PI Heating Demand_ (attribut 0x0008). Il s'agit d'une u8 , comprise entre 0 et 254. L'API l'expose sous la forme state.valve , normalisée entre 0 et 100 %.

Ce n'est pas normalisé, en fait, car sa valeur atteint 254, donc je l'ai normalisé moi-même.

Mon mal, désolé. En effet, je fais également la normalisation dans homebridge-hue.

J'ai ajouté 4 appareils Spirit ZigBee, hier. (Avec le nouveau deCONZ 2_05_71)
Malgré la procédure de recherche de capteurs vraiment ennuyeuse, j'ai réussi à les faire fonctionner avec rest-api et fhem.
J'ai remarqué qu'à chaque fois que je connectais un nouveau SpiritZig Bee deCONZ affichait pendant très peu de temps un nom d'appareil avec (je pense!) C'est comme "Thermostat + l'ID du capteur". Mais lors de la lecture du cluster de base, il est remplacé par SPZ0001 pour chaque périphérique !
Donc après chaque appariement je devais démarrer sqlitebrowser pour me débarrasser de 4 fois le nom...

Cela n'affecte-t-il que moi ?

Bonjour,

Comment puis-je reconnecter le Spirit à mon routeur ZigBee lorsque le routeur redémarre ? Ils ne sont pas connectés à un guichet automatique, et je ne sais pas comment je peux y parvenir. Le redémarrage du Spirit en retirant la batterie aiderait-il ou sera-t-il réinitialisé?

Le retrait et la réinsertion de la batterie fonctionnent généralement. Parfois, j'ai besoin d'ouvrir le réseau en faisant cela.

Il y a quelque chose de génial avec l'Esprit. Il ne reconnaît pas quand il est expulsé par son parent. Par conséquent, il ne trouvera pas de nouveau parent. Il continuera à envoyer des rapports d'attributs via son ancien parent, mais il ne répond plus aux commandes, car aucun routeur ne met en cache les messages à l'Esprit. J'ai eu un succès limité en rejoignant l'ancien parent sur le réseau (en appuyant sur L dans l'interface graphique, alors que le nœud est sélectionné), donc l'Esprit prendrait l'indice et trouverait un nouveau parent. Malheureusement, je dois généralement retirer le renifleur pour trouver l'ancien parent, car la ligne dans l'interface graphique a déjà disparu.

Et comment utilisez-vous le renifleur? La ligne dans l'interface graphique a disparu, donc je suppose qu'elle n'est plus connectée.

Edit : j'ai fait quelques recherches sur Google. Est-ce cela? https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html

Si oui, il me manque le CC-Debugger. J'ai un CC2531. Est-ce que quelque chose comme ça fonctionnerait ?

https://de.aliexpress.com/item/32995461002.html
https://www.ebay.de/itm/CC-Debugger-Bluetooth-ZigBee-Emulator-For-2530-2531-2540-2541-protocol-analysis/123956323038

J'utilise ZShark sur un RaspBeery Pi pour la capture (voir https://github.com/dresden-elektronik/deconz-rest-plugin/issues/405) et Wireshark sur mon Macbook pour l'analyse. Je n'ai aucune expérience avec d'autres outils.

J'utilise schedy (https://community.home-assistant.io/t/heaty-will-die-schedy-be-born/71276) pour rendre mes thermostats "intelligents". Mais je vis un comportement étrange.

Pour une raison quelconque, l'assistant à domicile semble enregistrer un changement dans la consigne de température quelques minutes après qu'une nouvelle température a été réglée et confirmée par schedy. Schedy interprète alors cela comme une modification manuelle et désactive la reprogrammation pour les 120 prochaines minutes, comme configuré. Cela arrive si souvent que cela rend plutôt inutile.

Je ne sais pas où donc chercher le coupable. J'ai demandé à roschi, le développeur de schedy et cela ne semble pas être un problème dans schedy mais plutôt dans homeassistant, deconz ou sur l'interface entre les deux.

Je joins un journal schedy, où vous pouvez voir schedy déterminer correctement le résultat des règles de programmation, c'est-à-dire 17°C et appliquer cette valeur aux deux thermostats de mon salon. Ensuite, environ 6 minutes plus tard, un changement manuel à 21 °C est enregistré (l'ancien point de consigne de température) et la température est appliquée à tous les thermostats et une minuterie de reprogrammation est définie.

Maintenant je ne sais pas si
1) pour une raison quelconque, le thermostat n'accepte pas le changement et signale simplement sa température précédente avec le prochain rapport d'état régulier

2) deconz signale ou réinitialise le point de consigne de température précédent

3) l'assistante à domicile se comporte juste bizarrement.

Le point 1) semble peu probable car je peux confirmer un changement de position de la vanne après le réglage de la température programmée. Le problème semble donc se situer quelque part sur l'interface entre deconz et homeassistant.

Peut-être que quelqu'un a une idée de la façon de procéder afin d'identifier le problème ou même a une idée d'où le problème pourrait être ?

Meilleures salutations

2019-11-27 09:23:56.192242 INFO schedy_heating: --- [R:living] Final result: 17.0��
2019-11-27 09:23:56.194555 INFO schedy_heating: --- [R:living] Setting value to 17.0��.  [scheduled]
2019-11-27 09:23:56.197652 INFO schedy_heating: <-- [R:living] [A:climate.thermostat_wz] Setting value 17.0�� (left tries = 10).
2019-11-27 09:23:56.200876 INFO schedy_heating: <-- [R:living] [A:climate.thermostat_wz] Setting temperature = 17.0��, HVAC mode = 'auto'.
2019-11-27 09:23:56.269871 INFO schedy_heating: --- [R:living] [A:climate.thermostat_wz] Re-sending in 30 seconds.
2019-11-27 09:23:56.274596 INFO schedy_heating: <-- [R:living] [A:climate.thermostat_ez] Setting value 17.0�� (left tries = 10).
2019-11-27 09:23:56.284171 INFO schedy_heating: <-- [R:living] [A:climate.thermostat_ez] Setting temperature = 17.0��, HVAC mode = 'auto'.
2019-11-27 09:23:56.341412 INFO schedy_heating: --- [R:living] [A:climate.thermostat_ez] Re-sending in 30 seconds.
2019-11-27 09:23:56.351558 INFO schedy_heating: <-- [R:living] Value set to 17.0��.  [scheduled]
2019-11-27 09:23:56.355287 INFO schedy_heating: <-- [R:living] Sending state to HA: state='17.0', attributes={'actor_wanted_values': {'climate.thermostat_wz': '17.0', 'climate.thermostat_ez': '17.0'}, 'scheduled_value': '17.0', 'rescheduling_time': None, 'overlay_active': False}
2019-11-27 09:23:56.460744 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Attribute 'state' is 'auto'.
2019-11-27 09:23:56.474545 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Attribute 'temperature' is 17.0.
2019-11-27 09:23:56.477044 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Attribute 'current_temperature' is 18.6.
2019-11-27 09:23:56.479650 INFO schedy_heating: --- [R:living] [A:climate.thermostat_wz] Cancelled re-sending timer.
2019-11-27 09:23:56.481889 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Received value of 17.0��.
2019-11-27 09:23:56.484209 INFO schedy_heating: --- [R:living] Unchanged HA state: state='17.0', attributes={'actor_wanted_values': {'climate.thermostat_wz': '17.0', 'climate.thermostat_ez': '17.0'}, 'scheduled_value': '17.0', 'rescheduling_time': None, 'overlay_active': False}
2019-11-27 09:23:56.486919 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'state' is 'auto'.
2019-11-27 09:23:56.489353 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'temperature' is 17.0.
2019-11-27 09:23:56.491747 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'current_temperature' is 18.5.
2019-11-27 09:23:56.494162 INFO schedy_heating: --- [R:living] [A:climate.thermostat_ez] Cancelled re-sending timer.
2019-11-27 09:23:56.496311 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Received value of 17.0��.
2019-11-27 09:23:56.498661 INFO schedy_heating: --- [R:living] Unchanged HA state: state='17.0', attributes={'actor_wanted_values': {'climate.thermostat_wz': '17.0', 'climate.thermostat_ez': '17.0'}, 'scheduled_value': '17.0', 'rescheduling_time': None, 'overlay_active': False}
2019-11-27 09:24:08.587687 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'state' is 'auto'.
2019-11-27 09:24:08.591273 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'temperature' is 17.0.
2019-11-27 09:24:08.601148 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'current_temperature' is 18.5.
2019-11-27 09:24:08.604167 INFO schedy_heating: --- [R:living] Unchanged HA state: state='17.0', attributes={'actor_wanted_values': {'climate.thermostat_wz': '17.0', 'climate.thermostat_ez': '17.0'}, 'scheduled_value': '17.0', 'rescheduling_time': None, 'overlay_active': False}
2019-11-27 09:30:38.403937 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Attribute 'state' is 'auto'.
2019-11-27 09:30:38.412780 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Attribute 'temperature' is 21.0.
2019-11-27 09:30:38.415900 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Attribute 'current_temperature' is 18.6.
2019-11-27 09:30:38.419592 INFO schedy_heating: --> [R:living] [A:climate.thermostat_wz] Received value of 21.0��.
2019-11-27 09:30:38.422193 INFO schedy_heating: --- [R:living] Propagating the change to all actors in the room.
2019-11-27 09:30:38.424761 INFO schedy_heating: --- [R:living] Setting value to 21.0��.  [manual]
2019-11-27 09:30:38.427664 INFO schedy_heating: --- [R:living] [A:climate.thermostat_wz] Not sending value 21.0�� redundantly.
2019-11-27 09:30:38.430957 INFO schedy_heating: <-- [R:living] [A:climate.thermostat_ez] Setting value 21.0�� (left tries = 10).
2019-11-27 09:30:38.434282 INFO schedy_heating: <-- [R:living] [A:climate.thermostat_ez] Setting temperature = 21.0��, HVAC mode = 'auto'.
2019-11-27 09:30:38.518710 INFO schedy_heating: --- [R:living] [A:climate.thermostat_ez] Re-sending in 30 seconds.
2019-11-27 09:30:38.528690 INFO schedy_heating: <-- [R:living] Value set to 21.0��.  [manual]
2019-11-27 09:30:38.531972 INFO schedy_heating: --- [R:living] Re-applying the schedule not before 11:30:38 (in 2:00:00).
2019-11-27 09:30:38.534834 INFO schedy_heating: <-- [R:living] Sending state to HA: state='21.0', attributes={'actor_wanted_values': {'climate.thermostat_wz': '21.0', 'climate.thermostat_ez': '21.0'}, 'scheduled_value': '17.0', 'rescheduling_time': 1574850638.0, 'overlay_active': False}
2019-11-27 09:30:38.661966 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'state' is 'auto'.
2019-11-27 09:30:38.665726 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'temperature' is 21.0.
2019-11-27 09:30:38.668367 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Attribute 'current_temperature' is 18.5.
2019-11-27 09:30:38.670909 INFO schedy_heating: --- [R:living] [A:climate.thermostat_ez] Cancelled re-sending timer.
2019-11-27 09:30:38.673100 INFO schedy_heating: --> [R:living] [A:climate.thermostat_ez] Received value of 21.0��.
2019-11-27 09:30:38.675437 INFO schedy_heating: --- [R:living] Unchanged HA state: state='21.0', attributes={'actor_wanted_values': {'climate.thermostat_wz': '21.0', 'climate.thermostat_ez': '21.0'}, 'scheduled_value': '17.0', 'rescheduling_time': 1574850638.0, 'overlay_active': False}

Je vois la même chose. Ce qui se passe, c'est que le plug-in de l'API REST met à jour son cache lors de la mise en file d'attente de la demande de modification du point de consigne. Cependant, la demande n'atteint pas le thermostat. Lorsque le thermostat envoie son prochain rapport périodique, le plugin REST API met à jour son cache avec la valeur réelle.

Je trouve que cela se produit plus fréquemment lors de la mise à jour (en essayant de mettre à jour) plusieurs TRV en même temps. Planifier les mises à jour à quelques secondes d'intervalle peut être utile ici. J'utiliserais des commandes de groupe, mais malheureusement, le Spirit ne prend pas en charge les groupes (et l'API REST ne prend pas en charge les groupes contenant des ressources /sensors ).

Je pense que nous aurions dû implémenter config.pending pour le TRV, comme nous l'avons fait pour le capteur de mouvement Hue. J'ai besoin de vérifier la logique que nous avons utilisée, en particulier quand effacer l'attente : à l'envoi de la commande, à la réception de l'accusé de réception, ou à la réception d'un rapport avec la nouvelle valeur. Pour la fiabilité, nous aurions besoin de ce dernier.

Il y a toujours le problème que de temps en temps, le TRV est « renié » par son parent, mais ne trouve pas de nouveau parent. Ses rapports atteignent toujours la passerelle, mais les commandes de passerelle n'atteignent plus le TRV. Cela ne peut pas être résolu par config.pending ; uniquement en redémarrant le TRV, en retirant la batterie et en la réinsérant.

En Allemagne, les Spirit ZigBee ont une offre Black Friday et un prix de 27,99 euros maintenant sur amazon !

Aujourd'hui j'ai passé toute la journée à intégrer le thermostat dans deconz. Malheureusement jamais avec un plein succès. J'ai lu tous les commentaires ici et j'ai suivi la plupart des instructions étape par étape. Le thermosate n'a jamais été affiché sur la surface de la bande de phoscon. Dans l'interface graphique de deconz, nous avons créé un nouveau nœud et je peux également lire le cluster de base. le fabricant et le modèle sont chargés, etc. mais dans l'iobroker, seuls quelques nœuds tels que la température et la batterie viennent. mais tous les autres manquent. quelqu'un peut-il écrire une instruction détaillée sur la façon dont il a intégré les thermostats ? Je voudrais acheter plus à cause du vendredi noir

En Allemagne, les Spirit ZigBee ont une offre Black Friday et un prix de 27,99 euros maintenant sur amazon !

épuisé :(

Bonjour les gens, je n'ai pas lu tous les 250 messages de ce fil, donc je ne sais pas si la description a déjà été publiée.
À partir de la page 14, vous trouverez les données concernant le registre Zigbee.
Cela peut faciliter la prise en charge de ce thermostat dans deconz.
https://eurotronic.org/wp-content/uploads/2019/11/Spirit_ZigBee_BAL_web_DE_Okt.-2019.pdf

WTF : ok n'est pas initialisé, ce qui fait que l'appel addTaskThermostatReadWriteAttribute() est ignoré de manière aléatoire ? Pas d'avertissement du compilateur, @manup ?!
https://github.com/dresden-elektronik/deconz-rest-plugin/blob/14c07293647d78385ee0b4dea61a8fdd04e270d7/rest_sensors.cpp#L1036 -L1062

Je suppose que la bonne nouvelle est que nous n'avons pas besoin de jouer avec config.pending .

Je suppose que la bonne nouvelle est que nous n'avons pas besoin de jouer avec config.pending .

Les tâches sont en cours de traitement à partir d'une file d'attente, mais il n'y a pas de vérification si la cible vient d'envoyer un rapport d'attribut ou quoi que ce soit d'autre.

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/14c07293647d78385ee0b4dea61a8fdd04e270d7/de_web_plugin.cpp#L10320 -L10530

Salut tout le monde!
J'apprécie beaucoup le travail que vous faites pour cette communauté!
Malheureusement, je ne connais pas toutes les technologies en arrière-plan - juste un utilisateur normal ;).

Pouvez-vous déjà estimer quand l'App Phoscon prend en charge les appareils Eurotronic ? J'ai vraiment hâte car tout ce que j'ai réussi à faire était de connecter l'appareil à l'interface graphique de deconz. Maintenant je suis coincé...

//jacdec

Salut et tout d'abord, merci beaucoup à tous pour tout l'excellent travail avec les trucs deconz- et homebridge-hue !

Maintenant pour ma question (j'espère que ce n'est pas stupide):
J'exécute deconz sous la forme d'un bouclier raspbee sur une tarte 3 en mode sans tête (plate-forme minimale).
Y a-t-il un moyen, je pourrais effectuer cette étape

• Allez dans deCONZ GUI, listez les clusters, cliquez sur "Basic" -> "Read" (comme recommandé dans #1098 (commentaire) )

sans vous soucier d'installer un environnement x11 ou une configuration vnc ?

J'aimerais ajouter quatre spiritueux à ma configuration homebridge, mais il me manque l'étape pour les rendre disponibles via l'api :)

Merci encore et s'il vous plaît continuez votre bon travail!

John

Merci @ebaauw pour la solution rapide ! Malheureusement, je n'ai pas encore eu le temps de vérifier si cela fonctionne pour moi. Je suppose que ce correctif sera inclus dans la prochaine version? Y a-t-il un ETA pour la prochaine version ?

Pendant que j'y suis, je veux aborder certains des derniers messages:

• @kugelkopf123 Je pense que les gens ici connaissent le manuel d'eurotronics, mais il semble que le manuel que vous avez lié soit une version mise à jour d'octobre, bien que je n'aie pu repérer aucune différence par rapport à l'ancienne version. En particulier, l'attribut "détection à distance" et la "détection d'ouverture de fenêtre" ne sont pas traités plus en détail qu'auparavant. J'ai écrit à eurotronics pour demander des éclaircissements. Je les ai également dirigés vers ce fil.
• @jacdec moi aussi j'apprécierais, si l'esprit (et éventuellement plus de thermostats) était supporté dans phoscon. Je crois, j'ai lu quelque part dans ce fil que cela nécessiterait un remaniement complet de phoscon. Cela étant dit, je pense qu'au moins exposer les capteurs dans phoscon et rendre le processus d'appariement plus simple et possible même dans une configuration sans tête serait formidable !
• @irrwitzer42 AFAIK, il n'y a aucun moyen pour le moment de jumeler l'esprit sans le deCONZ Gui.

Meilleures salutations

D'après tout ce que j'ai lu jusqu'à présent, l'utilisation d'un capteur de température à distance n'est pas possible avec le Spirit. Existe-t-il une manière appropriée de l'utiliser avec Home Assistant ? Quelque chose comme « si la température est inférieure à 23 °C, réglez le climat sur la vanne 255 » ou « ... réglez le climat sur le mode chauffage » ? Je ne sais pas si le contrôle des vannes est possible à partir de HA.

Salut tout le monde.
Pourquoi n'est-il pas possible d'utiliser 0x4003 Current Temperature Setpoint s16 rw pour contrôler le thermostat ? Parce que de mon point de vue, c'est l'attribut nécessaire ou je me trompe totalement ?

Salut à tous, je viens de recevoir mon Eurotronic Zigbee et j'ai du mal à l'appairer via deconz. L'interface utilisateur Web de deconz se lance cependant, lorsque je choisis d'ajouter un nouvel appareil -> capteur et effectuez la recherche, puis allumez le thermostat, le mode de connexion apparaît et le bouton ne commence pas à clignoter. Est-ce que je manque certaines étapes que je dois effectuer avant d'essayer de le coupler ?

Il y a quelque chose de génial avec l'Esprit. Il ne reconnaît pas quand il est expulsé par son parent. Par conséquent, il ne trouvera pas de nouveau parent. Il continuera à envoyer des rapports d'attributs via son ancien parent, mais il ne répond plus aux commandes, car aucun routeur ne met en cache les messages à l'Esprit. J'ai eu un succès limité en rejoignant l'ancien parent sur le réseau (en appuyant sur L dans l'interface graphique, alors que le nœud est sélectionné), donc l'Esprit prendrait l'indice et trouverait un nouveau parent. Malheureusement, je dois généralement retirer le renifleur pour trouver l'ancien parent, car la ligne dans l'interface graphique a déjà disparu.

@ebaauw Comment utilisez-vous exactement le renifleur pour reconnecter les appareils ? Je n'ai pas seulement ce problème avec le Spirit, mais avec tous les appareils ZigBee (1 multicapteur Aqara + 2 capteurs de mouvement Xiaomi).

salut tout le monde

J'ai installé la version bêta 2.05.72 hier. Mais je dois signaler que mon problème n'est pas résolu. Lorsque vous essayez de mettre à jour deux thermostats simultanément, l'un des appareils semble enregistrer le changement de point de consigne de température, mais la prochaine fois qu'il envoie un rapport d'état, il signale l'ancien point de consigne de température, qui est à son tour interprété comme un changement manuel et donc f ** ing mon emploi du temps.

Je pourrais demander au développeur de schedy s'il existe un moyen de retarder la commande sur un périphérique lors de la mise à jour d'un groupe, mais cela ne pourrait être qu'une solution de contournement et je considère cela comme un bogue dans deCONZ.

J'ai une question quelque peu indépendante, c'est-à-dire que dans deCONZ gui, il y a ce voyant d'état rond sur chaque appareil. Je n'ai trouvé aucune explication sur ce que cela signifie et ce que signifient les différentes couleurs (vert/bleu). J'ai lu quelque part que le vert indique un processus d'adhésion inachevé. Certains de mes thermostats clignotent en bleu, d'autres en vert et certains parfois en vert et parfois en bleu. Je ne sais pas quoi en faire.

Enfin, @gacekk Il n'y a aucun moyen pour le moment de coupler le Spirit Zigbee via l'interface utilisateur Web, vous devez accéder à l'interface graphique deCONZ et effectuer le processus de couplage comme décrit dans ce fil. Peut-être qu'une entrée wiki serait une bonne idée ?

Meilleures salutations!

Comment utilisez-vous exactement le renifleur pour reconnecter les appareils ?

Vous ne le faites pas. Vous utilisez le renifleur pour voir à quel routeur le périphérique final envoie ses commandes au niveau MAC (en supposant qu'il s'agit de l'ancien parent) et pour confirmer que le périphérique final est absent de la réponse à la commande _Query Neightbour Table_ (à partir de la gauche liste déroulante dans l'interface graphique de deCONZ). Ensuite, vous utilisez l'interface graphique de deCONZ pour forcer une reconnexion par ce routeur (en appuyant sur la touche L ).

Lorsque vous essayez de mettre à jour deux thermostats simultanément, l'un des appareils semble enregistrer le changement de consigne de température, mais la prochaine fois qu'il envoie un rapport d'état, il signale l'ancien point de consigne de température

Pourquoi pensez-vous que l'appareil semble enregistrer le changement ? Avez-vous lu l'attribut 0x4003 dans l'interface graphique de deCONZ ? Sinon, vous ne voyez que le cache deCONZ, qui a été mis à jour lors de l'envoi de la commande. Mais il n'y a aucune garantie que la commande ait réellement atteint le TRV, encore moins que le TRV a honoré la commande.

Comment mettre à jour les deux appareils ? Les Spirit TRV ne prennent pas en charge les groupes, vous devez donc envoyer plusieurs commandes. J'ai vu des problèmes avec les règles ne se déclenchant pas quand je m'y attendais (#2148), il vaut donc mieux vérifier le journal deCONZ ou utiliser un renifleur pour confirmer que la passerelle envoie bien la commande.

dans deCONZ gui, il y a ce voyant d'état rond sur chaque appareil

Si ma mémoire est bonne :

• Vert : le terminal interroge la passerelle (uniquement pour les terminaux connectés directement au RaspBee/ConBee) ;
• Bleu : deCONZ envoie ou reçoit des commandes pour cet appareil ;
• Jaune : deCONZ a envoyé une commande, mais n'a pas reçu d'ACK ;
• Rouge : deCONZ a atteint un délai d'attente lors de l'envoi d'une commande - c'est ce que vous verrez lorsque le TRV a été désavoué par son parent.

ce qui est à son tour interprété comme un changement manuel et donc foutre mon emploi du temps.

Je vois la même merde. J'ai essayé une règle pour définir à nouveau le point de consigne lors de la réception d'un rapport avec une valeur de point de consigne autre que la valeur planifiée, mais je ne peux plus modifier manuellement le calendrier.

Je pense à la mise en œuvre d'un moteur à états finis dans les règles deCONZ, qui se souvient s'il y a toujours un changement de point de consigne non confirmé en attente (à l'aide d'un capteur CLIP), renvoyant la commande, jusqu'à ce que le point de consigne signalé corresponde à la cible. Après cela, il accepterait les dérogations manuelles.

Cependant, il faudra attendre les vacances de Noël. Bien sûr, cela ne fonctionnera qu'une fois que le Spirit aura trouvé un nouveau routeur parent (soit spontanément, soit après l'avoir redémarré).

Ah et encore une chose : est-il possible de mettre à jour le firmware du Spirit via deCONZ ? Mes spiritueux les plus anciens sont _HW Version_ 34, _Application Version_ 18 avec _Date Code_ 20190408 et OTAU _Current File Version_ 0x0122c380 tandis que mes plus récents sont _HW Version_ 35, _Application Version_ 22 avec _Date Code_ 20191014 et OTAU _Current File Version_ 0x0162e9d2

Je ne trouve pas non plus d'informations sur les mises à jour du firmware sur la page d'accueil d'Eurotronics. Le manuel dit simplement "Un historique des révisions est fourni séparément" mais aucun indice où le trouver.

Ah et encore une chose : est-il possible de mettre à jour le firmware du Spirit via deCONZ ?

Devrait être, une fois que nous aurons trouvé le firmware. Les miens sont sur 20181205 (qui, selon la norme, devrait être la date de fabrication, pas la date du firmware, mais j'ai vu de nombreux appareils qui l'utilisent comme date de firmware) et _HW Version_ 34. Le firmware a _SW Build ID_ 15181120 et _Application Version_ 15.

Pourquoi pensez-vous que l'appareil semble enregistrer le changement ? Avez-vous lu l'attribut 0x4003 dans l'interface graphique de deCONZ ? Sinon, vous ne voyez que le cache deCONZ, qui a été mis à jour lors de l'envoi de la commande. Mais il n'y a aucune garantie que la commande ait réellement atteint le TRV, encore moins que le TRV a honoré la commande.

Lorsque j'ai rencontré ce problème pour la première fois, j'ai pu voir que les vannes réagissaient au nouveau point de consigne. Mais environ 5 minutes plus tard, le point de consigne précédent a été signalé comme le point de consigne réel. Je n'ai pas confirmé que la commande a atteint le TRV cette fois et j'enquêterai plus en détail demain.

Comment mettre à jour les deux appareils ? Les Spirit TRV ne prennent pas en charge les groupes, vous devez donc envoyer plusieurs commandes. J'ai vu des problèmes avec les règles ne se déclenchant pas quand je m'y attendais (#2148), il vaut donc mieux vérifier le journal deCONZ ou utiliser un renifleur pour confirmer que la passerelle envoie bien la commande.

Comme je l'ai mentionné plus tôt, j'utilise schedy pour homeassistant. Il s'agit d'un framework de planification python qui permet de regrouper des appareils dans des pièces. Je ne sais pas comment cela fonctionne en interne, mais oui, j'enverrai plusieurs commandes à coup sûr ! Je vérifierai le journal deCONZ quand je trouverai le temps.

Merci d'avoir clarifié les couleurs de l'indicateur d'état. Je n'ai pas vu d'indicateur de statut rouge, donc je n'ai pas encore eu de problème avec les parents qui désavouent leurs enfants.

S'il existait un moyen de s'assurer qu'un changement de point de consigne atteint la VTR ou au moins de réagir lorsqu'un point de consigne signalé ne correspond pas à un point de consigne souhaité, ce serait formidable ! Si je peux être utile en testant ou autre chose, je serais heureux de vous aider !

Meilleures salutations

Edit : j'ouvre un nouveau sujet pour ça

Comment utilisez-vous exactement le renifleur pour reconnecter les appareils ?

Vous ne le faites pas. Vous utilisez le renifleur pour voir à quel routeur le périphérique final envoie ses commandes au niveau MAC (en supposant qu'il s'agit de l'ancien parent) et pour confirmer que le périphérique final est absent de la réponse à la commande _Query Neightbour Table_ (à partir de la gauche liste déroulante dans l'interface graphique de deCONZ). Ensuite, vous utilisez l'interface graphique de deCONZ pour forcer une reconnexion par ce routeur (en appuyant sur la touche L ).

Pour être honnête, je ne suis pas sûr de pouvoir suivre. Le renifleur me montre que l'Esprit continue d'envoyer une demande de réintégration et que mon coordinateur envoie une réponse de réintégration :

Demander:

Réponse:

Voici mon interface graphique deCONZ :

Où est la _Query Neightbour Table_ maintenant ? Je ne le vois pas dans l'interface graphique de deCONZ.
Lorsque j'appuie sur L (tout en sélectionnant le coordinateur), il part et rejoint. Rien ne se passe quand je fais ça à l'esprit, même quand je pars et que je rejoins en appuyant sur le bouton du haut. Est-ce que je fais quelque chose de mal ou est-ce que cela ne fonctionne tout simplement pas ?

Le renifleur me montre que l'Esprit continue d'envoyer une demande de ralliement et que mon coordinateur envoie une réponse de ralliement

Je n'ai jamais vu ça avant. On dirait que l'Esprit n'accepte pas la réponse et réessaye. Pas trop familier avec ces commandes, mais la réponse ne devrait-elle pas contenir l'adresse NWK du périphérique final ?

Voici mon interface graphique deCONZ

Le coordinateur est donc votre seul routeur. Dans ce cas, vous savez déjà ce que le routeur parent est censé être, donc pas besoin de le découvrir en utilisant le renifleur.

Où est la table de voisinage de requête maintenant ?

Dans le menu déroulant derrière la gauche des deux cercles à droite du nœud.

Rien ne se passe quand je fais ça à l'esprit

C'est normal lorsque deCONZ ne peut pas atteindre l'Esprit.

Je n'ai jamais vu ça avant. On dirait que l'Esprit n'accepte pas la réponse et réessaye. Pas trop familier avec ces commandes, mais la réponse ne devrait-elle pas contenir l'adresse NWK du périphérique final ?

Pas sûr tbh. Je ne pouvais pas le résoudre, alors je l'ai juste réinitialisé.

Dans le menu déroulant derrière la gauche des deux cercles à droite du nœud.

Ah, je vois. J'ai donc dû sélectionner "Lire la table des voisins".

Bon, maintenant c'est plus ou moins résolu. Savez-vous comment je récupère les lignes vertes de tous les autres appareils ? Ils sont connectés comme il semble puisque mes capteurs de mouvement fonctionnent en HA. Mais la ligne verte vers le coordinateur ne revient pas.

Les lignes ne sont qu'une représentation graphique des tables voisines. Ils n'indiquent pas une connexion active - il n'y a rien de tel dans ZigBee - juste des messages. Ils sont dessinés lorsque deCONZ interroge les tables voisines.

Salut tout le monde,
Je ne sais pas si c'est pertinent, mais peut-être intéressant de savoir qu'Amazon les vend actuellement aujourd'hui pour 27,99 €. Maintenant je vais remplacer tous les thermostats par ceux-ci : https://amzn.to/2YRHqOB

@ebaauw Je viens d'essayer de mettre à jour ma teinte homebridge vers la v.11.8. C'est ce qui s'est passé. Que dois-je faire?

Ouvrez un problème avec homebridge-hue. Cela n'a rien à voir avec le support Eurotronic Spirit dans deCONZ.

J'utilise 3 spirit zigbees depuis cette période de chauffe et ils deviennent périodiquement des zombies. Ils ne réagissent plus à aucune commande que j'envoie via deCONZ/hassio. Je les ai également rejoints plusieurs fois et j'ai assuré une bonne couverture zigbee. Deux d'entre eux sont connectés via le raspberry pi 4 qui actionne le bâton conbee 2 - un via un maillage sur une lumière de teinte.

Phoscon GW : 2.05.72 / 12.12.2019
Micrologiciel : 264A0700
Module complémentaire Hassio : V4.1
Hassio : 0,102,3
Version de l'esprit Zigbee : 20190408

Une fois qu'ils sont devenus zombies, je peux les récupérer en appuyant sur l'un des boutons du TRV afin qu'ils transmettent à nouveau leur état au réseau.

Y a-t-il quelqu'un qui rencontre également ces problèmes ou qui a des conseils sur ce qui peut mal tourner ?

Au cas où j'essaierais d'envoyer une commande à un TRV zombie, le journal confirme que la commande n'atteint pas le TRV :
18:11:11:193 delay sending request 129 dt 0 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:293 delay sending request 129 dt 0 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:393 delay sending request 129 dt 0 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:493 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:592 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:692 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:793 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:893 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:11:993 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:093 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:111 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:193 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:293 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:392 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:423 delay sending request 129 dt 1 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:493 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:515 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:593 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:692 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:793 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:893 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:12:992 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:093 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:193 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:214 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:293 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:393 delay sending request 129 dt 2 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:492 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:510 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:592 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:614 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:692 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:793 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:893 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:13:993 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:093 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:193 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:292 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:312 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:393 delay sending request 129 dt 3 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:493 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:593 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:614 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:693 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:713 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:793 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:893 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:14:992 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:15:093 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:15:193 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:15:293 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:15:392 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:15:412 delay sending request 129 dt 4 ms to 0x00158D000192CF05, cluster 0x0201 18:11:15:506 0x00158D000192CF05 error APSDE-DATA.confirm: 0xD0 on task 18:11:15:506 max transmit errors for node 0x00158D000192CF05, last seen by neighbors 4124 s 18:11:16:008 don't close database yet, keep open for 900 seconds 18:11:17:274 no button map for: SML001 ep: 0x02 cl: 0x0402 cmd: 0x0A pl[0]: 000 18:11:17:274 ZCL attribute report 0x001788010213B2D6 for cluster 0x0402, ep 0x02 18:11:21:330 0x00158D000192CF05 error APSDE-DATA.confirm: 0xD0 on task 18:11:21:330 max transmit errors for node 0x00158D000192CF05, last seen by neighbors 4129 s

Une fois qu'ils sont devenus zombies, je peux les récupérer en appuyant sur l'un des boutons du TRV afin qu'ils transmettent à nouveau leur état au réseau.

Je n'ai jamais vécu ça. Dans mon cas, la passerelle ne peut pas atteindre le TRV, mais le TRV peut toujours atteindre la passerelle ( state.lastupdated continue d'être mis à jour). Je dois éteindre et rallumer le TRV (retirer et réinsérer la batterie) pour remédier à la situation.

Tous mes TRV SPZB0001 viennent de laisser tomber le roulement de tambour hors

Edit : ils répondent aux opérations de lecture de cluster, mais ils apparaissent comme déconnectés dans l'interface graphique de deconz.

Une pensée qui me vient à l'esprit : AFAICS le SPZB0001 considère l'heure actuelle comme le début de l'époque UNIX, le RTC ne semble pas fonctionner. Existe-t-il un moyen de définir la bonne heure via le cluster Time (0x000A) ?

Je viens de recevoir 2 de ces jouets. J'ai réussi à les faire apparaître dans l'interface graphique et même à régler la température dans l'interface graphique.
Malheureusement, je ne le trouve pas dans l'application Web et il n'apparaît pas non plus dans mon domoticz. Y a-t-il un moyen de les y amener ?

Malheureusement, je ne le trouve pas dans l'application Web et il n'apparaît pas non plus dans mon domoticz. Y a-t-il un moyen de les y amener ?

J'ai eu le même problème au début. Le redémarrage du serveur a fait le travail pour moi.

Malheureusement, cela n'a pas aidé. redémarré plusieurs fois. L'interface graphique affiche les deux comme connectés mais l'interface Web ne les affiche toujours pas. Je suis sur v2.05.71. Dois-je passer à la version 2.05.72 pour qu'ils fonctionnent ?
C'est ma sortie d'interface graphique :

EDIT : mis à jour à .72 et toujours le même

Malheureusement, cela n'a pas aidé. redémarré plusieurs fois. L'interface graphique affiche les deux comme connectés mais l'interface Web ne les affiche toujours pas.

L'interface utilisateur Web de Phoscon n'affichera pas le SPZB0001, il sera cependant disponible via l'API REST.

Le problème avec les TRV zombies se produit toujours plus ou moins fréquemment, entraînant environ 15 % d'échecs de déclenchement.

Je suis ennuyé que comme je l' ai passé des heures d'heures des recherches au cours des derniers mois que je pense que je vais écrire le vendeur et demander à ce que s * ils vendent (cette question est largement rapporté dans Internet)

Le problème avec les TRV zombies se produit toujours plus ou moins fréquemment, entraînant environ 15 % d'échecs de déclenchement.

Je suis ennuyé que comme je l' ai passé des heures d'heures des recherches au cours des derniers mois que je pense que je vais écrire le vendeur et demander à ce que s * ils vendent (cette question est largement rapporté dans Internet)

Eh bien, j'ai 14 de ces appareils et j'en suis plus qu'heureux. Le seul problème que j'ai eu était que parfois l'un des appareils ne réagissait pas à une commande envoyée simultanément à 3 appareils dans une pièce. J'ai résolu ce problème en retardant chaque commande de quelques secondes. Fonctionne impeccable. Peut-être que vous n'avez pas de "serveur" comme une ampoule à proximité et que le signal est trop faible. J'ai les appareils sur 3 étages et je les adore.

J'en ai 8 qui, à l'occasion, semblent être expulsés par leur routeur parent et ne trouveront pas de nouveau parent. Ils envoient toujours des rapports à la passerelle (par exemple, lors de la modification de la température cible sur le TRV), mais les commandes de la passerelle n'atteignent pas le TRV. Lorsque je retire et réinsère les piles du TRV, cela fonctionne à nouveau.
Je n'ai pas été en mesure de détecter un modèle dans quelles circonstances cela se produit. Certains de mes VRT semblent plus vulnérables que d'autres, mais c'est arrivé à tous. Ils exécutent tous le firmware 15181120 . La plupart d'entre eux ont ensuite choisi une ampoule Hue comme parent, mais parfois ils choisissent une prise innr ou même un XBee.

Il y a un problème avec le plugin de l'API REST qui régit les règles basées sur /config.localtime et les règles avec une condition ddx sont parfois pas déclenchées, voir https://github.com/dresden-elektronik/deconz -rest-plugin/issues/2148. J'en utilise beaucoup pour contrôler les TRV.

Hé les gars, je viens d'acheter un de ces thermostats à esprit ZigBee pour jouer avec, mais je ne parviens pas à le connecter à mon réseau, bien que j'aie d'autres appareils comme des interrupteurs, des ampoules, des capteurs connectés sans problème. Quelqu'un pourrait-il m'aider à savoir ce que je fais mal? J'ai un conbee II connecté à Home Assistant et le processus d'ajout se fait de la même manière que pour les autres capteurs via l'interface utilisateur Web.
@ Tobi0892 pouvez-vous m'aider à connecter mon téléviseur à HASSIO ? quelles mesures dois-je prendre :
Ce que je fais c'est :

1. Ouvrir l'interface utilisateur Web de deconz
2. Allez sur capteurs et cliquez sur ajouter un nouveau capteur
3. Pendant que le scan est en cours, j'insère les piles dans le TVR

Je peux voir comment l'icône wifi clignote sur le téléviseur mais rien ne se passe :(

Les gars, laissez-moi intervenir ici depuis que j'ai reçu le mien il y a 2 jours pour évaluer s'ils pourraient être un remplacement facultatif pour mon fritz 301.

Une chose frappante que j'ai observée est que lorsque le TRV perd la connexion avec le coordinateur pendant une période plus longue (disons 18h), alors c'est un peu fubar. Littéralement rien en reniflant (passerelle de test dédiée avec uniquement le TRV connecté). Aucune chance de le récupérer à l'exception de la réinitialisation et de l'adhésion.

Quelqu'un d'autre a fait cette expérience ?

@Valcob Je suppose que vous vouliez dire Phoscon? Sinon, essayez-le là-bas. Parfois, je ne travaille pas sur la première tentative de jointure. Au fait, il doit être en mode jointure (jin sur l'écran). La réinitialisation consiste à appuyer simultanément sur les 3 boutons pendant 10 secondes.

J'ai le même problème que @Valcob ici, Phoscon n'est pas en mesure de trouver les appareils si j'essaie de les ajouter en tant que capteur. Les deux appareils TRV viennent d'être réinitialisés et dans Jin, le bouton du milieu clignote. Le scan se termine avec le message Failed to connect dans Phoscon. D'autres capteurs et lumières ont été connectés sans aucun problème.

J'utilise un Raspberry Pi 3 avec Docker et RaspBee.
Gateway-Version: 2.05.72 / 12/12/2019
Micrologiciel : 26330500

J'ai eu beaucoup de mal à faire reconnaître le mien correctement. Qu'est-ce que l'astuce consistait à suivre ces étapes:

• ouvrir l'interface graphique de deconz
• démarrer la recherche de capteurs dans le service Web phoscon
• coupler le téléviseur avec le réseau
• dans l'interface graphique : accédez aux informations sur le cluster et lisez les informations de base pendant que la recherche de capteur est toujours en cours.
  Ces étapes ont fonctionné à chaque fois pour moi.

@SwoopX merci mec u m'a sauvé :) le manuel freaking dit que je dois appuyer sur le cercle et plus des boutons pendant dix secondes pour réinitialiser l'appareil , mais je l' ai vérifié la version allemande aussi bien et a remarqué que en fait u devez appuyer sur tous les trois boutons d'une instruction trompeuse paniquer en version anglaise bon sang. Maintenant, j'ai mes TVRs connectés et peut procéder aux essais de nouveau les remerciements

@michi1g J'ai essayé vos suggestions et elles semblent être associées maintenant. Au moins, je peux voir les deux appareils dans l'interface graphique de deconz et y modifier certaines valeurs. Mais je ne peux toujours pas voir les capteurs dans la vue des capteurs dans Phoscon.

Ce n'est pas possible pour le moment, @githtz. Les esprits ne peuvent pas être contrôlés via phoscon. Ils sont néanmoins exposés via l'API REST et devraient donc apparaître dans homeassistant.

Nous devrions vraiment mettre la procédure d'appariement et l'information selon laquelle les esprits ne peuvent pas être contrôlés via phoscon dans le wiki. L'information est enfouie dans ce fil.

Salut les gars, tout d'abord j'apprécie vraiment votre aide : ce fil est super utile ! Cela permet d'économiser beaucoup de temps et d'efforts pour l'appairage initial : il aurait dû être écrit partout que les thermostats ne sont pas affichés dans l'application Phoscon alors qu'ils sont affichés dans Home Assistant après la procédure initiale (recherche de nouveaux capteurs - lire les informations de base sur le cluster de deconz GUI) !

Quoi qu'il en soit, comme déjà dit, j'ai les mêmes soucis que quelqu'un d'entre vous : le réglage de la température ne fonctionne que pendant les premières heures après l'appairage, ensuite l'intégration semble ne plus fonctionner et il faut revenir au reset-appairage procédure. Pensez-vous que cela peut être résolu par une mise à jour du micrologiciel du thermostat/de la passerelle ? J'utilise raspbee sur raspberry pi...

Salut les gars, j'ai un problème similaire, de plus je suis très nouveau dans ce sujet. J'utilise Home Assistant (0.103.6; HassOS 3.7) sur RPi 4 et j'ai effectué ces étapes de @michi1g jusqu'à la dernière. Ici, je ne peux pas comprendre comment "lire les informations de base sur le cluster à partir de l'interface graphique de deconz".
(Je pouvais associer des capteurs Xiaomi Aqara auparavant et je peux lire leurs données ; d'après ceux-ci, j'ai conclu que mon système fonctionne.)
Après avoir réinitialisé mon TRV, il affiche l'état de connexion mais je ne peux toujours pas l'atteindre sous Home Assistant. Pouvez-vous m'aider avec une procédure étape par étape? :)
Merci.

Salut @rollair, comme mentionné à plusieurs reprises dans ce fil (je sais que c'est beaucoup à lire), vous devez avoir accès à l'interface graphique de deconz. Ce n'est pas l'interface utilisateur Web de Phoscon mais l'interface graphique que vous voyez dans les captures d'écran du tout premier message de ce fil. Vous devez lire le cluster de base à partir de l'interface graphique pour déclencher la génération d'entités REST-API. À cette fin, vous devez identifier votre nœud TRV, cliquer sur le cercle le plus à droite, puis sélectionner le cluster de base dans le menu déroulant. Dans le cadre de gauche, sélectionnez l'onglet « infos sur le cluster » et appuyez sur « lire ».

Voir la capture d'écran dans https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment -569644645 et l'une des instructions étape par étape de ce fil.

Malheureusement, je ne peux pas vous dire comment accéder à l'interface graphique de deconz à partir d'une installation hass.io. Mais je crois que j'ai vu des instructions pour cela aussi.

Désolé mais je veux dire que c'est du temps perdu. Tôt ou tard, vous
faire une coupe et l'argent et le temps sont perdus. Normalement, mon objectif est seulement
Zigbee, uniquement avec iobroker. Mais il n'y a pas de thermostat zigbee qui
travailler sans erreurs. J'ai plus d'un événement Sauna et aucune réponse de
Assistance Eurotronic. Et c'est pourquoi je retourne à netter Systems pour
Des thermostats comme homematic ip ou salus.

Sk4zz [email protected] schrieb am Do., 9 janvier 2020, 19:23:

Salut @rollair https://github.com/rollair comme mentionné à plusieurs reprises dans
ce fil (je sais que c'est beaucoup à lire) vous devez avoir accès au
deconz GUI. Ce n'est pas l'interface utilisateur Web de Phoscon mais l'interface graphique que vous voyez dans le
captures d'écran du tout premier message de ce fil. Vous devez lire le
cluster de base depuis l'interface graphique pour déclencher la génération d'entités REST-API.
Pour cela vous devez identifier votre nœud TRV, cliquez sur le plus à droite
cercle, puis sélectionnez le cluster de base dans le menu déroulant. À gauche
cadre, sélectionnez l'onglet « infos sur le cluster » et appuyez sur « lire ».

Voir la capture d'écran dans #1098 (commentaire)
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-569644645
et l'une des instructions étape par étape de ce fil.

Malheureusement, je ne peux pas vous dire comment accéder à l'interface graphique de deconz à partir de
une installation hass.io. Mais je crois avoir vu des instructions pour ça,
trop.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098?email_source=notifications&email_token=ADI5I4QJQFIHXGKVAATAIV3Q45TQJA5CNFSM4GOP7622YY3PNVWWK3TUL52HS4DFVREXLNLO43VMXWWHJ888
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/ADI5I4VLHQ3AXI7XNY6IM73Q45TQJANCNFSM4GOP762Q
.

Désolé mais je veux dire que c'est du temps perdu. Tôt ou tard, vous ferez une coupe et l'argent et le temps sont gaspillés. Normalement, mon objectif n'est que Zigbee, uniquement avec iobroker. Mais il n'y a pas de thermostat zigbee qui fonctionnera sans erreur. J'ai plus d'un événement Sauna et aucune réponse du support Eurotronic. Et c'est pourquoi je reviens à Netter Systems for Thermostats comme homematic ip ou salus. Sk4zz [email protected] schrieb am Do., 9 janvier 2020, 19:23:
…
Salut @rollair https://github.com/rollair comme mentionné à plusieurs reprises dans ce fil (je sais que c'est beaucoup à lire), vous devez avoir accès à l'interface graphique de deconz. Ce n'est pas l'interface utilisateur Web de Phoscon mais l'interface graphique que vous voyez dans les captures d'écran du tout premier message de ce fil. Vous devez lire le cluster de base à partir de l'interface graphique pour déclencher la génération d'entités REST-API. À cette fin, vous devez identifier votre nœud TRV, cliquer sur le cercle le plus à droite, puis sélectionner le cluster de base dans le menu déroulant. Dans le cadre de gauche, sélectionnez l'onglet « infos sur le cluster » et appuyez sur « lire ». Voir la capture d'écran dans #1098 (commentaire) < #1098 (commentaire) > et l'une des instructions étape par étape dans ce fil. Malheureusement, je ne peux pas vous dire comment accéder à l'interface graphique de deconz à partir d'une installation hass.io. Mais je crois que j'ai vu des instructions pour cela aussi. — Vous recevez ceci parce que vous avez été mentionné. Répondre à cet e - mail directement, voir sur GitHub <# 1098? Email_source = notifications & email_token = ADI5I4QJQFIHXGKVAATAIV3Q45TQJA5CNFSM4GOP7622YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIRITNA # issuecomment-572688820> ou désabonnement https://github.com/notifications/unsubscribe-auth/ADI5I4VLHQ3AXI7XNY6IM73Q45TQJANCNFSM4GOP762Q .

Comme je l'ai dit : j'ai 14 appareils et tous fonctionnent impeccablement depuis plus d'un mois. Au début, j'ai eu le problème qu'un appareil ne répondait plus après quelques jours. Mais maintenant, zéro problème. C'est peut-être parce que je tire la valeur du point de consigne thermique toutes les 15 minutes ? Ainsi, aucun appareil ne tombe en veille profonde ou quelle que soit la cause de l'erreur. Je les utilise avec conbee II sur un nuc Intel via ioBroker. La "programmation" se fait avec le nœud Rouge. Mais je suis un noob absolu...

je tire la valeur de la température de consigne toutes les 15 minutes

Avez-vous modifié le plugin REST API pour cela, ou utilisez-vous deconz-cli-plugin ? Notez que l'interrogation de l'appareil à partir de l'API REST renvoie simplement l'état mis en cache et n'entraîne aucun message ZigBee.

Désolé mais je veux dire que c'est du temps perdu. Tôt ou tard, vous ferez une coupe et l'argent et le temps sont gaspillés. Normalement, mon objectif n'est que Zigbee, uniquement avec iobroker. Mais il n'y a pas de thermostat zigbee qui fonctionnera sans erreur. J'ai plus d'un événement Sauna et aucune réponse du support Eurotronic. Et c'est pourquoi je reviens à Netter Systems for Thermostats comme homematic ip ou salus. Sk4zz [email protected] schrieb am Do., 9 janvier 2020, 19:23:
…
Salut @rollair https://github.com/rollair comme mentionné à plusieurs reprises dans ce fil (je sais que c'est beaucoup à lire), vous devez avoir accès à l'interface graphique de deconz. Ce n'est pas l'interface utilisateur Web de Phoscon mais l'interface graphique que vous voyez dans les captures d'écran du tout premier message de ce fil. Vous devez lire le cluster de base à partir de l'interface graphique pour déclencher la génération d'entités REST-API. À cette fin, vous devez identifier votre nœud TRV, cliquer sur le cercle le plus à droite, puis sélectionner le cluster de base dans le menu déroulant. Dans le cadre de gauche, sélectionnez l'onglet « infos sur le cluster » et appuyez sur « lire ». Voir la capture d'écran dans #1098 (commentaire) < #1098 (commentaire) > et l'une des instructions étape par étape dans ce fil. Malheureusement, je ne peux pas vous dire comment accéder à l'interface graphique de deconz à partir d'une installation hass.io. Mais je crois que j'ai vu des instructions pour cela aussi. — Vous recevez ceci parce que vous avez été mentionné. Répondre à cet e - mail directement, voir sur GitHub <# 1098? Email_source = notifications & email_token = ADI5I4QJQFIHXGKVAATAIV3Q45TQJA5CNFSM4GOP7622YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIRITNA # issuecomment-572688820> ou désabonnement https://github.com/notifications/unsubscribe-auth/ADI5I4VLHQ3AXI7XNY6IM73Q45TQJANCNFSM4GOP762Q .

C'est un combat de sorcière et de déconz, je dois l'admettre. Mais c'est un modèle du marché zigbee. Oui, le protocole est standardisé, mais sans une bonne intégration de nouveaux appareils ou de processus d'auto-intégration appliqués, il s'agit de savoir qui est le plus rapide.
Dans le cas d'Eurotherm Zigbee, l'intégration dans l'adaptateur iobroker.zigbee en combinaison avec un koenkk flashé cc2531 fonctionne à merveille. Il ne se perd jamais et je peux l'exporter via l'adaptateur iot vers Alexa. En fin de compte, j'exploite 2 réseaux zigbee avec des ponts différents en utilisant celui qui fonctionne le mieux en fonction du capteur utilisé. On croise les doigts pour qu'il obtiendra toujours une meilleure intégration dans rest/conbee/deconz.

C'est un combat de sorcière et de déconz, je dois l'admettre.

ConBee II / deCONZ semble avoir un gros problème de routage lorsque le SPZB0001 n'est pas directement connecté au coordinateur (les routes se perdent au bout de quelques jours). Malheureusement, le support n'a pas encore répondu aux demandes de renseignements.

Dans le cas d'Eurotherm Zigbee, l'intégration dans l'adaptateur iobroker.zigbee en combinaison avec un koenkk flashé cc2531 fonctionne à merveille. Il ne se perd jamais et je peux l'exporter via l'adaptateur iot vers Alexa. En fin de compte, j'exploite 2 réseaux zigbee avec des ponts différents en utilisant celui qui fonctionne le mieux en fonction du capteur utilisé.

Pouvez-vous partager plus de détails sur votre configuration ? Je suis prêt à abandonner ConBee II / deCONZ dès que mon CC2531 arrive de Chine. ATM, j'utilise Home Assistant, donc tout type d'intégration serait bien.

Quelqu'un a-t-il pu utiliser la détection d'ouverture de fenêtre après le couplage des appareils ? Selon le manuel, la détection est désactivée après l'appairage et je peux le confirmer. Un moyen de le réactiver ?

//Éditer

Ok, on dirait que la détection fonctionne toujours, juste assez lente. Est-il possible de régler la sensibilité d'une manière ou d'une autre ?

@ginkel Je ne recommanderais pas de l'abandonner. C'est un produit solide avec une très bonne portée par rapport au CC2531 (sans antenne ni lumière à proximité). Les fonctions de regroupement, les scènes, etc. sont très puissantes comme n'importe quel autre pont comme ikea ou philips. Vous pouvez utiliser tout cela et inclure des appareils manquants / défectueux sur conbee avec un autre réseau zigbee (sur un autre canal) exploité par le CC2531. C'est précisément ma configuration. J'ai toutes mes lumières et beaucoup de capteurs/boutons Xiaomi sur conbee stick mais j'utilise toutes mes prises d'alimentation IKEA et Xiaomi et Eurotherm via CC2531. N'oubliez jamais que si vous n'utilisez pas Phoscon, vous devez utiliser des scènes et des trucs iobroker. Beaucoup de travail à faire où Dresden elektronik a fait du bon travail ! Je joins des photos de mon installation...

Les gars, merci pour l'aide apportée à ce post jusqu'à présent : j'ai fait fonctionner mon régulateur Eurotronics sur mon ConnBee-II dans iobroker - du moins d'une manière ou d'une autre...
Beaucoup de difficultés quand il n'était pas reconnu, de nombreuses réinitialisations et puis cela a fonctionné.
Mais il semble que le capteur ne soit pas correctement mis en œuvre. Je ne peux pas voir la température cible, la position de la vanne, etc. (comparez ma capture d'écran avec celle de @realwax ci-dessus)

Par où puis-je commencer à chercher une solution ? Ou quelqu'un a-t-il vécu la même chose et connaît-il une solution ?

@selen278 Je suppose que c'est une limitation d'iobroker (ou comment deconz gère les thermostats). La température cible du SPZB0001 est stockée dans le config du capteur et non dans le state .

J'ai le même problème ici.

Et c'est ce que montre iobroker.

@githtz Je ne

@realwax je ne sais pas comment ça se passe avec l'iobroker je ne l'utilise pas dans mon instance d'assistant à domicile tout est visible même l'état de la valve et tout est cliquable et réglable sans problème


Donc, je suppose que deconz est d'accord pour transmettre les informations TVR à HA (homeasistant) la seule chose que j'avais est la façon dont j'ai besoin de connecter le TVR au réseau

1. Connectez-vous au backend VNC du deconz
2. Déballez le TVR et dans l'interface utilisateur Web de phoscon, accédez aux capteurs, cliquez sur ajouter un nouveau capteur
3. Étant donné que le TVR est déballé et prêt à être connecté, mettez les piles
4. Vérifiez le VNC à ce stade, il affichera un périphérique sur le réseau local zigbee mais rien d'autre ne devrait se produire
5. Cliquez sur les propriétés le cercle le plus à droite sur la carte de périphérique apparue et le cluster de base
6. Sur la gauche, il y a un bouton qui dit lire les informations du cluster, cliquez sur celui-ci et vous verrez des informations sur votre TVR
7. Réinitialisez l'appareil (appuyez sur les 3 boutons pendant 10 secondes)
8. Il passera à nouveau en mode connexion et cette fois, il apparaîtra comme prévu dans le VNC, ce qui signifie que toutes les informations sur l'appareil seront sur la carte elle-même. Et en même temps, les informations sur l'appareil seront également envoyées à l'instance HA.

C'est tout, cela devrait être assez simple pour ajouter plus de TVR. J'en ai 8 et je n'ai aucun problème du tout.
Assurez-vous simplement que vous avez suffisamment de répéteurs dans votre maison, c'est-à-dire n'importe quel appareil zigbee (ampoule ikeea, douille ou tout ce qui est alimenté par le secteur) qui peut servir de répéteur

J'espère que cela t'aides

J'ai installé l'image docker home-assistant sur mon rpi3 en plus de deconz et iobroker et voilà !

Donc, je suppose que les TVR sont correctement couplés, oui. Bien que je me demande pourquoi iobroker n'est pas en mesure d'accéder à la configuration des TRV. Peut-être que le iobroker-deconz-plugin ne prend pas complètement en charge l'api deconz ?

Bon à entendre. Je me suis donc trompé en ce qui concerne mes réflexions sur deconz rest api. Concernant iobroker deconz, il y a eu une mise à jour il y a deux jours. Peut-être que l'un des avec iobroker veut réessayer ? https://github.com/iobroker-community-adapters/ioBroker.deconz
Je le ferais moi-même mais j'ai déjà le mien connecté et intégré.

Je l'ai essayé aujourd'hui et recréé mon instance iobroker à partir de zéro, mais les capteurs sont toujours en lecture seule dans l'interface iobroker. Je suppose que je vais créer un problème à ce projet.

Je peux confirmer que je ne peux pas non plus les contrôler à l'aide d'iobroker. Ils apparaissent mais en lecture seule, il n'y a aucun moyen de régler la température.

On dirait que la dernière version 1.2.3 résout le problème ! Au moins, je peux maintenant voir une modification des valeurs TRV.

Puis-je en quelque sorte définir le nom du TRV ? Quand je change la valeur dans deCONZ cela n'a aucun effet

Non!
Mais vous pouvez utiliser sqlitebrowser et ouvrir~/.local/share/dresden-elektronik/deCONZ/zll.db
et remplacez "SPZ0001" manuellement par n'importe quoi ;)
Mais sauvegardez d'abord votre zll.db 8)

J'ai utilisé le facteur pour le faire via l'API. Obtenez simplement la clé API de l'application Phoscon et effectuez un PUT sur http://{$DOCONZ_HOST}/api/{$IP_KEY}/sensors/{$SENSOR_ID} avec le corps brut suivant : {"name": "{$ NOUVEAU NOM}"}

Quelqu'un d'autre a-t-il des problèmes pour connecter le Spirit à Hassio avec deConz 5.1 ? J'ai mis à jour mon Hassio à 104.2 et après le redémarrage, le Spirit ne s'est pas reconnecté (un autre l'a fait). Je l'ai donc supprimé via VNC et j'ai essayé de l'ajouter via Phoscon, mais le Spirit ne trouve pas Hassio même s'ils sont littéralement côte à côte.

@Valcob Pouvez-vous préciser ce que vous entendez par « Et en même temps, les informations sur l'appareil seront également envoyées à l'instance HA » ?
J'essaie de suivre vos instructions pour une autre marque de thermostat (eCozy) et je peux lire toutes les données dans VNC mais je ne sais pas comment obtenir l'entité dans HA. Exécution de deCONZ sur un stick conbee en tant que module complémentaire hassio, RPi.

@ddppddpp veuillez ouvrir une nouvelle demande d'intégration ou émettre celle-ci est pour l'esprit désolé.

J'ai relu tout le fil étant donné que mes derniers commentaires ici remontaient à octobre 2019.
Alors juste pour que les choses soient claires en ce moment (02.02.2020) :

• Le thermostat doit être couplé en lisant les informations du cluster sur l'interface graphique ;
• L'interface Web n'affichera pas le thermostat sous l'onglet Sensors ;
• Toute personne disposant de routeurs secondaires (lumières, prises, etc.) : si le thermostat se connecte au réseau via ceux-ci, à un moment donné, il perd cette connexion et ne peut pas automatiquement rejoindre le réseau, et il faudra le retirer et le réinsérer la batterie;

Ces trois points sont-ils corrects à ce jour ?

Si oui, y a-t-il des WIP en cours pour y remédier pour améliorer la prise en charge de ces TRV (couplage et WebUI) et également augmenter la fiabilité (perte de connexion lorsque le réseau a un coordinateur + des routeurs) ?

J'ai relu tout le fil étant donné que mes derniers commentaires ici remontaient à octobre 2019.
Alors juste pour que les choses soient claires en ce moment (02.02.2020) :

• Le thermostat doit être couplé en lisant les informations du cluster sur l'interface graphique ;
• L'interface Web n'affichera pas le thermostat sous l'onglet Sensors ;
• Toute personne disposant de routeurs secondaires (lumières, prises, etc.) : si le thermostat se connecte au réseau via ceux-ci, à un moment donné, il perd cette connexion et ne peut pas automatiquement rejoindre le réseau, et il faudra le retirer et le réinsérer la batterie;

Ces trois points sont-ils corrects à ce jour ?

Si oui, y a-t-il des WIP en cours pour y remédier pour améliorer la prise en charge de ces TRV (couplage et WebUI) et également augmenter la fiabilité (perte de connexion lorsque le réseau a un coordinateur + des routeurs) ?

Mes 14 thermostats sont connectés via plusieurs lumières et prises et au cours des 2 derniers mois, je n'ai eu aucun cas de perte de connexion.
J'ai beaucoup de capteurs d'aqara qui sont moins fiables.

J'ai relu tout le fil étant donné que mes derniers commentaires ici remontaient à octobre 2019.
Alors juste pour que les choses soient claires en ce moment (02.02.2020) :

• Le thermostat doit être couplé en lisant les informations du cluster sur l'interface graphique ;
• L'interface Web n'affichera pas le thermostat sous l'onglet Sensors ;
• Toute personne disposant de routeurs secondaires (lumières, prises, etc.) : si le thermostat se connecte au réseau via ceux-ci, à un moment donné, il perd cette connexion et ne peut pas automatiquement rejoindre le réseau, et il faudra le retirer et le réinsérer la batterie;

1) et 2) sont corrects. Pour 3) je pense qu'il y a à mon humble avis un problème de routage plus général qui supprime des périphériques du réseau. Hier, j'ai à nouveau perdu des ampoules TRADFRI après qu'un SPZB0001 soit devenu inaccessible la veille. Comme le support ignore principalement les demandes depuis plus d'un mois, j'ai migré vers un CC2531 avec zigbee2mqtt et je ne regarde pas en arrière.

Edit: En utilisant un renifleur Zigbee, je pouvais clairement voir que le SPZB0001 ne perdait pas la connexion au réseau, mais envoyait avec plaisir des paquets de demande de données à son routeur, mais lors de la tentative de lecture d'un cluster à partir de l'interface graphique deCONZ, il était clair que deCONZ n'envoyait pas toute demande dans ce cas.

J'ai la WebApp deCONZ Phoscon fonctionnant sur un Raspi. J'utilise l'application Version 2.05.72 / 12.12.2019, Firmware 264A0700 en tant que service. Sans l'interface graphique, mais avec la webUI (qui est excellente, soit dit en passant). J'utilise des lumières et des capteurs zigbee pour les rendre disponibles dans ioBroker et openHAB et cela fonctionne à merveille. Mais je peux confirmer : avec le Phoscon-WebUI, il n'y a aucun moyen d'appairer le thermostat Eurotronic Spirit pour le moment.

Ma solution de contournement : je n'utiliserai pas l'application UI/VNC, j'ai donc dû utiliser un stick CC2531 à la place (comme proposé plusieurs fois ci-dessus), qui fonctionne ... un peu peu fiable (chaque 5ème commande fonctionne, les autres produisent juste entrées dans le journal des erreurs), mais cela ne me dérange pas. Dès que deCONZ WebApp prend en charge ce thermostat, je vais changer.

Ce que je trouve ennuyeux : Eurotronic Spirit ZigBee est répertorié dans la liste des éléments pris en charge (ce qui était la raison pour laquelle j'ai acheté le conBEE2). Le commentaire de cette entrée vous amène à cette même page de demande, où vous lisez, que vous devez utiliser la version UI et faire des trucs techniques, pour lesquels je ne suis vraiment pas assez intelligent ou vous devez utiliser une autre passerelle complète pour obtenir ce thermostat couplé (https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Supported-Devices).

Le thermostat doit être couplé en lisant les informations du cluster sur l'interface graphique ;

Je ne pense pas que ce soit toujours le cas et ce n'est certainement pas un problème exclusif à l'Esprit. L'appariement d'appareils alimentés par batterie est difficile et je recommanderais vraiment d'avoir accès à l'interface graphique pour surveiller et redémarrer un processus d'appariement bloqué.

L'appariement peut certainement être amélioré, mais cela nécessiterait une refactorisation du code correspondant. Pas quelque chose que vous faites un dimanche après-midi pluvieux perdu. Le mieux est probablement de combiner cela avec l'API v2.

L'interface Web n'affichera pas le thermostat sous l'onglet Capteurs ;

Correct. Une fois que le plug-in Web REST API ajoute la prise en charge d'un nouvel appareil, chaque client API doit également ajouter une prise en charge. Phoscon est « juste » un autre client API (qui s'exécute dans votre navigateur Web).

Et j'apprécierais vraiment, si l'Eurotronic Spirit ZigBee pouvait être intégré dans Phoscon WebApp, bientôt. Ce qui, à ma connaissance, est le but de cette demande de support de périphérique ouverte.

Ce référentiel est pour le plugin API REST open source. Phoscon n'est pas open source, donc personne ici, à l'exception de Dresden elektronik eux-mêmes, ne peut faire quoi que ce soit à ce sujet.

Toute personne disposant de routeurs secondaires (lumières, prises, etc.) : si le thermostat se connecte au réseau via ceux-ci, à un moment donné, il perd cette connexion et ne peut pas automatiquement rejoindre le réseau, et il faudra le retirer et le réinsérer la batterie;

Il y a beaucoup de problèmes de routage, en particulier sur les grands réseaux avec des lumières mixtes, mais je ne pense pas que cela s'applique au thermostat. Je trouve qu'il reste bien connecté au réseau, et continue d'envoyer des rapports au coordinateur. Cependant, le routeur parent (ancien) ne reconnaît plus le Spirit comme un enfant, le rendant effectivement inaccessible par d'autres appareils (vous ne pouvez donc plus contrôler ou interroger le thermostat depuis deCONZ).

J'ai vu cela sur mes huit spiritueux, mais certains semblent plus sensibles à ce problème que d'autres. Lorsqu'ils choisissent une prise innr SP 120 ou mon lumi.curtain tant que parent, le problème apparaît dans la journée. Lorsqu'ils choisissent l'une de mes lampes Hue, elles peuvent fonctionner correctement pendant des semaines. Je vois le même problème avec mon store FYRTUR, d'ailleurs.

Je pense que ce problème est causé par le firmware Spirit, en ce sens qu'il ne reconnaît pas (toujours ?) J'ai eu quelques occasions où il a spontanément trouvé un nouveau parent, mais je n'ai pas pu isoler les conditions pour cela. Le cycle d'alimentation/réinitialisation de l'ancien parent semble parfois faire l'affaire ; le cycle d'alimentation du thermostat le fait toujours - pas besoin de réinitialiser et de ré-appairer le thermostat. Je trouve qu'à l'occasion, le thermostat s'est réinitialisé et nécessite un ré-appairage.

Dans l'esprit (jeu de mots) de divulgation complète, je pense qu'il y a deux autres problèmes :

• Je trouve que parfois les commandes ne semblent pas atteindre le thermostat, même s'il est accessible. Je débogue toujours ce problème, j'ai trouvé que parfois les règles ne se déclenchent pas (voir #2148), ce qui sera corrigé dans la v2.05.73. Je crains que nous n'ayons dû implémenter state.pending après tout, même si l'Esprit semble avoir le sommeil léger, interrogeant son parent toutes les cinq secondes.
• Toutes les fonctionnalités de Spirit ne sont pas encore prises en charge par le plugin REST API. En particulier, vous ne pouvez pas changer son mode et contrôler la position de la vanne manuellement. À mon humble avis, il serait irresponsable de soutenir cela avant d'aborder le problème ci-dessus.

Exactement mon expérience !

1er étage : Raspbee et un TRADFRI Driver 30W avec trois esprits connectés à Raspbee ou Driver
==> Tout fonctionne bien pendant des semaines ! Ils envoient des rapports et reçoivent de nouveaux heatsetpoints ;)

Rez-de-chaussée : Routeur mixte Situation : innr sp120, osram smart plug01, ampoule ikea
==> Seul l'envoi des rapports se déroule bien. La définition d'un nouveau heatsetpoint n'atteint jamais la cible (4 autres esprits, mais tous les esprits sont connectés)

@githtz pourrait expliquer comment exactement vous l'avez fait apparaître dans l'assistant à domicile?

De plus, est-ce que quelqu'un a contacté Dresden Electronic au sujet du support Web Phoscon ?

@LennyPenny Avez-vous essayé ceci?
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment -460403451

@githtz oui, je l'ai connecté à l'interface utilisateur mais cela ne s'affiche pas dans l'assistant à domicile

ah ok tant pis je me suis mis au travail : cliquer sur le bouton "lire" dans le deconz gui était la partie que j'ai raté

@realwax je ne sais pas comment ça se passe avec l'iobroker je ne l'utilise pas dans mon instance d'assistant à domicile tout est visible même l'état de la valve et tout est cliquable et réglable sans problème


Donc, je suppose que deconz est d'accord pour transmettre les informations TVR à HA (homeasistant) la seule chose que j'avais est la façon dont j'ai besoin de connecter le TVR au réseau

1. Connectez-vous au backend VNC du deconz
2. Déballez le TVR et dans l'interface utilisateur Web de phoscon, accédez aux capteurs, cliquez sur ajouter un nouveau capteur
3. Étant donné que le TVR est déballé et prêt à être connecté, mettez les piles
4. Vérifiez le VNC à ce stade, il affichera un périphérique sur le réseau local zigbee mais rien d'autre ne devrait se produire
5. Cliquez sur les propriétés le cercle le plus à droite sur la carte de périphérique apparue et le cluster de base
6. Sur la gauche, il y a un bouton qui dit lire les informations du cluster, cliquez sur celui-ci et vous verrez des informations sur votre TVR
7. Réinitialisez l'appareil (appuyez sur les 3 boutons pendant 10 secondes)
8. Il passera à nouveau en mode connexion et cette fois, il apparaîtra comme prévu dans le VNC, ce qui signifie que toutes les informations sur l'appareil seront sur la carte elle-même. Et en même temps, les informations sur l'appareil seront également envoyées à l'instance HA.

C'est tout, cela devrait être assez simple pour ajouter plus de TVR. J'en ai 8 et je n'ai aucun problème du tout.
Assurez-vous simplement que vous avez suffisamment de répéteurs dans votre maison, c'est-à-dire n'importe quel appareil zigbee (ampoule ikeea, douille ou tout ce qui est alimenté par le secteur) qui peut servir de répéteur

J'espère que cela t'aides

Vous êtes un homme qui sauve la vie ! J'étais en train de fouiner et j'avais tout oublié de l'interface vnc. Votre explication m'a parlé de l'interface vnc et du protocole zigbee. Je suis moi aussi maintenant l'heureux propriétaire d'un TRV entièrement opérationnel qui fonctionne à merveille avec HA, merci !

@BeamMeUpTo @rsaffi
Avez-vous trouvé une solution de contournement pour cela? J'ai une sorte de situation similaire ici maintenant avec deux SPZB0001 (directement connectés au concentrateur) qui fonctionnent très bien, mais le troisième est connecté à divers routeurs et il cesse de fonctionner après quelques jours. :déçu:

@BeamMeUpTo @rsaffi
Avez-vous trouvé une solution de contournement pour cela? J'ai une sorte de situation similaire ici maintenant avec deux SPZB0001 (directement connectés au concentrateur) qui fonctionnent très bien, mais le troisième est connecté à divers routeurs et il cesse de fonctionner après quelques jours.

Je n'ai toujours pas (encore) d'autre appareil à la maison qui se comporte comme un routeur, donc je ne peux pas le dire moi-même. J'ai un ami qui a quelques routeurs et quelques TRV Spirit Zigbee et qui a été confronté au même problème. Elle a même créé une routine personnalisée pour forcer une communication entre Home-Assistant et ses VTR toutes les 2 heures, pour éviter de les "perdre".

Mes premières prises intelligentes arriveront entre aujourd'hui et demain, j'aurai donc enfin d'autres appareils qui sont des routeurs, je garderai un œil pour voir si les TRV commencent à mal se comporter ou non.

Edit : pour être juste, toutes mes lumières sont des Philips Hue qui peuvent servir de routeurs, mais elles ne sont pas connectées à mon Home-Assistant directement via Conbee+deCONZ, mais plutôt en utilisant le pont Hue, c'est donc un réseau Zigbee séparé.

@githtz - Non, pas vraiment.

@tkintscher

Pendant ce temps, j'ai contourné ce problème en lisant la température d'un capteur Xiaomi et en ajustant config.offset . Cela fonctionnait parfaitement, jusqu'à ce que votre PR change les unités de décalage de 0,1 à 0,01 degrés.

Pouvez-vous s'il vous plaît m'expliquer comment avez-vous fait? Je suis nouveau dans ce domaine...
Aussi @ebaauw des nouvelles de la télédétection ?
Merci

Aussi @ebaauw des nouvelles de la télédétection ?

Pourquoi voudriez-vous que j'aie des nouvelles? Pour autant que j'ai pu le déterminer, le TRV ne prend pas en charge cette fonction, même s'il expose l'attribut _Remote Sensing_. Le manuel ne mentionne pas cette fonction et le support Eurotronic ne semble pas réagir aux e-mails. Il n'y a rien que je puisse faire.

je demande juste... merci

N'y a-t-il toujours pas de mise à jour sur le rajout d'un TRV après redémarrage du routeur ? Je le redémarre un peu régulièrement (Home Assistant sur un RPI) pour installer les mises à jour. Habituellement, un de mes deux TRV ne se reconnecte pas. Le cycle d'alimentation en retirant la batterie n'aide pas, et il continue de chauffer tout le temps tout en essayant de se connecter. La réinitialisation de tout est pénible car j'ai quelques autres appareils connectés.

@FlyingPersian J'ai la même situation.

@FlyingPersian J'ai la même situation.

Bizarrement, après la suppression de l'appareil dans VNC et sa réapparition, la LED à côté continue de clignoter en vert et bleu, même lorsque l'appareil était momentanément éteint. Le redémarrage, la lecture des données, la recherche de nouveaux appareils, etc. n'ont pas aidé à le rajouter :o J'ai peur que si je supprime l'appareil, il sera encore plus difficile de le rajouter.

J'ai dû réinitialiser l'appareil et répéter toutes les étapes comme pour le nouvel appareil

J'ai dû réinitialiser l'appareil et répéter toutes les étapes comme pour le nouvel appareil

Cela ne fonctionne généralement pas pour moi. Si je fais cela, l'appareil ne se couplera pas avec deCONZ. Je n'ai pas essayé depuis les dernières mises à jour, mais j'ai peur de le faire.

Si l'appareil perd sa connectivité, je répare la désactivation et l'activation de l'appareil dans Home Assistant. Parfois, je dois répéter cela deux fois, mais cela fait presque toujours le travail.

N'y a-t-il toujours pas de mise à jour sur le rajout d'un TRV après redémarrage du routeur ? Je le redémarre un peu régulièrement (Home Assistant sur un RPI) pour installer les mises à jour. Habituellement, un de mes deux TRV ne se reconnecte pas. Le cycle d'alimentation en retirant la batterie n'aide pas, et il continue de chauffer tout le temps tout en essayant de se connecter. La réinitialisation de tout est pénible car j'ai quelques autres appareils connectés.

@FlyingPersian C'est très étrange, mais tous les TRV que j'ai toujours reconnectés automatiquement lorsque je redémarre HASS (en raison d'une mise à jour, par exemple).

Ahh, ce que je fais principalement, ce sont des redémarrages de Home Assistant lui-même (donc deCONZ continue de fonctionner). Mais il y a quelques jours, il y a eu une mise à jour du système d'exploitation de hass.io et il a redémarré et mes thermostats se sont également reconnectés automatiquement.

Ahh, ce que je fais principalement, ce sont des redémarrages de Home Assistant lui-même (donc deCONZ continue de fonctionner). Mais il y a quelques jours, il y a eu une mise à jour du système d'exploitation de hass.io et il a redémarré et mes thermostats se sont également reconnectés automatiquement.

Ouais, étrangement, un seul de mes deux appareils se reconnecte. L'autre ne le fait pas. Je ne sais pas pourquoi ni comment je pourrais même le trouver.

Est-ce encore quelque chose que vous regardez dans?
Je viens d'acheter 4 Thermostats et je réussi à se connecter 1, mais même celui-ci ne fonctionnait pas correctement (ne pouvait pas contrôler via Accueil Assistant). Je pense que j'ai tout essayé et il semble un peu aléatoire qu'il se connecte parfois après plusieurs réinitialisations et ainsi de suite. En ce moment, je peux voir un thermostat dans l'interface graphique Phoscon VNC mais il ne peut plus se connecter et « Ajouter un nouveau capteur » sur la WebApp ne fonctionne pas, aussi.

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité ne se produit. Merci pour vos contributions.

@Paragrimm Mine fonctionnent toujours. Comme il fait chaud, ils ne sont pas utilisés très souvent, mais je peux toujours envoyer des commandes aux thermostats (comme le verrouillage de l'écran). Mais j'ai eu beaucoup de problèmes avec ceux-là aussi :déçu:
Pouvez-vous modifier l'état du thermostat connecté depuis l'interface graphique VNC ?

Je viens d'en recevoir deux et j'aimerais aussi les faire fonctionner.
@ebaauw Est-ce que ça aiderait si on essayait de réveiller eurotrinoc ? Quelles questions doit-on leur poser ?

• S'ils ont un firmware plus récent. Où ils le publient.
• Si/quand/comment ils prendront en charge la liaison à un capteur de température externe.
• s'ils ont connaissance d'un bogue dans leur micrologiciel, par lequel le TRV ne parvient pas à détecter que son parent l'a expulsé et ne trouve pas de nouveau parent.

J'ai demandé au support d'eurotronics en début d'année des mises à jour du firmware. Leur réponse était qu'ils avaient décidé de ne pas rendre les mises à jour du firmware accessibles au public. La raison invoquée est que de nombreux fabricants de passerelles ne prennent pas en charge les mises à jour. Quelle que soit la raison.

Hé Erik, ok va faire, c'est quoi TRV ? :-)

Vanne de radiateur thermostatique

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité ne se produit. Merci pour vos contributions.

J'ai remarqué que homebridge-hue désactive le mode TRV s'il est désactivé dans HomeKit. Est-ce que quelqu'un sait si la protection antigel est toujours active même si le TRV est réglé sur "OFF" ?

J'ai remarqué que homebridge-hue désactive le mode TRV s'il est désactivé dans HomeKit. Est-ce que quelqu'un sait si la protection antigel est toujours active même si le TRV est réglé sur "OFF" ?

Pour mes thermostats, ils passent du mode « arrêt » au mode défini auparavant après 15 minutes. Cela ne devrait donc pas faire de différence. (Je suppose que le mode "off" est pour une sorte de détection de fenêtre ouverte)

@tkintscher Intéressant ! Pour une raison quelconque, le mien garde le mode "OFF" pendant plusieurs jours. Mais si je lis "Current Temperature Setpoint", il renvoie "500", donc je soupçonne que la protection antigel est toujours activée. Peut-être ai-je préinstallé un firmware plus récent ? Ma "version d'application" est "22".

@titus-leistner C'est intéressant. La mienne semble être une version antérieure, où "Version de l'application" est "15":

Je crois que quelque part plus tôt, l'existence de différentes versions de firmware a été discutée, mais il n'y avait pas de version plus récente disponible auprès du fabricant pour la mise à jour manuelle 😕

Étant donné que le mien ne reste pas éteint, je n'ai pas beaucoup étudié cela... mais je suppose que le régler manuellement sur "500" au lieu d'utiliser le mode "OFF", maintiendrait la protection contre le gel activée.

La mienne semble être une version antérieure, où "Version de l'application" est "15"

Le rapport de la mine est également _Application Version_ 15.

Le mode _Off_ (ainsi que _Boost_ ou _On_) est défini via l'attribut spécifique au fabricant _Host Flags_, voir https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment -462077343. Comme effet secondaire, ils modifient également le point de chaleur. Je ne pense pas que vous puissiez définir _Off_ via les commandes de l'appareil, et je ne l'ai jamais vu s'allumer automatiquement, mais vraisemblablement, il est défini sur la détection de fenêtre ouverte (c'est-à-dire une chute soudaine de température).

J'ai remarqué que homebridge-hue désactive le mode TRV s'il est désactivé dans HomeKit.

Je crains que Homebridge Hue n'utilise pas correctement _TargetHeatingCoolingState_. Dans HomeKit, vous pouvez le régler sur _Off_, _Heat_, _Cool_ ou _Auto_, où ce dernier signifie chauffer ou refroidir. Accueil grise la tuile lorsque _TargetHeatingCoolingState_ est _Off_. Il éclaire la tuile pour les autres vallées. Vous ne pouvez modifier la _TargetTemparature_ que lorsque _TargetHeatingCoolingState_ n'est pas _Off_. Comme l'Eurotronic ne prend pas en charge le refroidissement, les seules valeurs logiquement valides seraient _Off_ et _Heat_.

Le fait que le _Thermostat_ chauffe ou refroidisse est indiqué par _CurrentHeatingCoolingState_. Il prend les valeurs _Off_, _Heat_ et _Cool_. Lorsque _Off_, le cercle autour de la température actuelle est vert ; quand _Heat_, c'est orange. Je pense qu'il est bleu en refroidissant, mais je n'ai pas d'appareil à vérifier. Lorsque _TargetHeatingCoolingState_ est _Off_, _CurrentHeatingCoolingState_ devrait l'être également et le cercle est gris.

Ne comprenant pas encore complètement cela lors de l'ajout de la prise en charge d'Eurotronic, Homebridge Hue définit actuellement _TargetHeatingCoolingState_ sur _Heat_ pour le mode _Boost_, sur _Off_ pour le mode _Off_ et sur _Auto_ sinon. J'ai pensé que ce serait un bon moyen d'exposer les modes _Off_ et _Boost_ à HomeKit. Cependant, Eve ne prend en charge que le réglage de _TargetHeatingCoolingState_ sur _Off_ et _Heat_ (il est affiché comme _Mode_ avec les valeurs _Off_ et _On_), car Eve Thermo ne refroidit pas non plus. Je pense maintenant qu'il est sémantiquement correct d'utiliser _TargetHeatingCoolingState_ pour _Off_, mais pas pour _Boost_.

Est-ce que quelqu'un sait si la protection antigel est toujours active même si le TRV est réglé sur "OFF" ?

Je suppose que cela ouvrira la valeur lorsque la température mesurée tombe en dessous de 5°C. Je n'ai jamais essayé ça, cependant. Pour vérifier, réinitialisez-le au mieux, désinstallez-le de votre radiateur, ré-appairez-le et placez-le à l'extérieur pendant l'hiver, ou placez-le au réfrigérateur.

L'appareil couplé n'envoie pas de mises à jour et n'est plus disponible lorsque deCONZ est redémarré

J'ai couplé mon appareil comme décrit ci-dessus. Le nom correct apparaît dans deCONZ, Temperaturregler apparaît dans Phoscon et la température est affichée. Des points clignotants bleus et verts dans deCONZ sont affichés.

Ensuite, j'exécute les commandes suivantes :

curl localhost:/api/FB61B91470/sensors/6 |jq

{
  "config": {
    "battery": null,
    "displayflipped": null,
    "heatsetpoint": 2100,
    "locked": null,
    "mode": "auto",
    "offset": 0,
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "49e35c802d0c3e55c4f1451a2af33fe1",
  "lastseen": "2020-10-16T08:53Z",
  "manufacturername": "Eurotronic",
  "modelid": "SPZB0001",
  "name": "Temperaturregler",
  "state": {
    "lastupdated": "2020-10-16T08:50:25.579",
    "on": true,
    "temperature": 2050,
    "valve": 255
  },
  "swversion": "20191014",
  "type": "ZHAThermostat",
  "uniqueid": "00:15:8d:00:05:3d:36:23-01-0201"
}

Remarquez que la batterie, l'affichage retourné et verrouillé sont nuls, pourquoi?

curl --header "Content-Type: application/json" --request PUT --data '{"heatsetpoint": "2300"}' localhost/api/FB61B91470/sensors/6/config
[{"success":{"/sensors/6/config/heatsetpoint":"2300"}}]

Sortie du journal deCONZ lors de la définition du point de consigne thermique : https://pastebin.com/fkAAnVDP

Problèmes:

• la température affichée dans Phoscon n'obtient qu'une seule mise à jour juste après l'appairage, puis plus jamais
• après le redémarrage, deCONZ affiche un point rouge lorsque vous appuyez sur read basic attributes .

Des questions:

• Est-ce que quelqu'un sait pourquoi il met à jour initialement la température mesurée mais n'honore jamais heatsetpoint ?
• Pourquoi la communication se perd-elle après le redémarrage de deCONZ ?

la température affichée dans Phoscon n'obtient qu'une seule mise à jour juste après l'appairage, puis plus jamais

Très probablement, le plug-in API n'a pas réussi à configurer les liaisons et les paramètres de rapport d'attributs appropriés. Cela pourrait également expliquer les valeurs manquantes pour battery et locked et displayflipped . Se remplissent-ils lorsque vous lisez manuellement les attributs correspondants à partir de l'interface graphique (_Battery Percentage Remaining_, 0x001/0x0021 et _Host Flags_, 0x0201/0x4008) ? Consultez le manuel d'utilisation sous Aide pour configurer les liaisons et la configuration manuellement. Ou essayez de réparer. Assurez-vous de revérifier les batteries : l'appairage nécessite plus de puissance que les opérations normales.

Est-ce que quelqu'un sait pourquoi il met à jour initialement la température mesurée mais n'honore jamais le point de consigne thermique ?
Pourquoi la communication se perd-elle après le redémarrage de deCONZ ?

Je doute que cela soit lié au redémarrage de deCONZ. Mes TRV sont devenus inaccessibles assez souvent, jusqu'à ce que je les déplace vers un réseau séparé avec un seul routeur (un répéteur Trådfri) en plus du RaspBee. Pour autant que j'ai pu le déterminer, ils ont été expulsés par leur routeur parent, mais n'ont pas remarqué et trouvé un nouveau parent. Notez que dans ce cas, ils enverraient toujours des rapports à la passerelle, mais les commandes de passerelle n'atteindraient pas le TRV.
Cela semble être un problème dans (entre) le micrologiciel TRV (et le micrologiciel du routeur parent), je crains que deCONZ ne puisse faire grand-chose ici. La solution de contournement consistait à redémarrer le TRV (retirer et réinsérer les batteries).

Merci pour ta réponse Erik !

J'ai réinitialisé l'appareil et j'ai essayé vos suggestions, ce qui a donné :

• displayflipped et locked encore null
• battery est 90 après avoir cliqué sur le bouton de lecture
• heatsetpoint est signalé comme 500 lorsque le bouton de lecture est cliqué (un peu glacial à mon avis)
• l'écriture de 2200 ou de toute autre valeur pour heatsetpoint échoue définitivement

Vous devez lire/écrire l'attribut 0x4003 spécifique au fabricant pour heatsetpoint ; l'attribut standard 0x0012 ne fonctionne pas pour l'Eurotronic. Pour un affichage inversé et verrouillé, vous devez lire 0x4008. Il pourrait toujours y avoir un bogue dans l'API REST qui ne mettra à jour les attributs REST que lorsque la valeur change. Essayez peut-être de les mettre à jour à partir de l'API, ou verrouillez l'affichage en maintenant + et - sur le TRV.

Mon mauvais, utilisé 0x0012 la première fois, comme vous l'avez compris ;-) . J'ai essayé 0x4003, la lecture fonctionne en mode d'appairage, une fois l'appareil apparié, ni la lecture ni l'écriture ne fonctionnent. Dois-je lire tous les attributs relatifs à l'API en mode couplage pour que l'appareil fonctionne correctement par la suite ?

C'est étrange. L'Eurotronic a le sommeil léger et doit être réactif aux commandes. Pouvez-vous voir dans l'interface graphique quel parent il utilise ? De quelle version du firmware dispose-t-il (attributs _Date Code_ et _SW Build ID_).

La capture d'écran montre deCONZ pendant que TRV est en mode d'appairage (attribut de base lu une fois). L'éditeur d'attributs affiche l'échec de la tentative d'écriture sur 0201:0x4003. J'ai ensuite appuyé sur le bouton de lecture pendant SW Build ID et après une minute, les valeurs ont été lues : 22190930 .

C'est un firmware différent (plus récent ?) que le mien. Je n'ai jamais trouvé le firmware Eurotronic en ligne, même s'il semble pouvoir être mis à jour sans fil.

Pouvez-vous vérifier la fréquence à laquelle le nœud clignote en vert ? C'est à ce moment-là que le TRV interroge son routeur parent pour tout message. Cela devrait être une fois toutes les 7 secondes ou plus fréquemment pour que l'appareil soit accessible. Sinon, nous devons implémenter config.pending pour écrire les attributs config .

Le TRV peut être forcé à se réveiller en appuyant sur l'un des boutons physiques. Vous pouvez essayer cela juste avant et pendant la lecture ou l'écriture des attributs.

Pour autant que je sache, le téléchargement/téléchargement du firmware n'est pas pris en charge. Il n'y a donc aucune chance de downgrader le firmware.

J'ai modifié mon commentaire précédent (désolé, mon iPad a pensé que ce serait amusant de le publier pendant que je tapais encore).

Une heure après l'appairage, il est simplement vert et ne commence pas à clignoter si vous appuyez sur le bouton du TRV

Suggérer qu'il est constamment en train de voter. C'est normal après l'appairage, mais devrait s'arrêter sous peine d'épuiser la batterie très rapidement.

Pouvez-vous renifler le trafic Zigbee ? Sinon, pouvez-vous exécuter deCONZ avec --dbg-info=2 --dbg-aps=2 --dbg-error=1 et vérifier le journal. Vous devriez voir des messages indiquant que le TRV interroge la passerelle (en tant que parent).

deCONZ fonctionne actuellement avec l'indicateur --dbg-info=2 et enregistre beaucoup de ces instructions :
MAC Poll 0x02 0x164E
suivi d'un seul verify 0x00158d00053d3623 is child node after 809128 s

Si les autres drapeaux sont également nécessaires, je redémarrerai. Mais alors l'icône deviendra très probablement grise au lieu de vert fixe.

Quel outil de sniff me proposeriez-vous (sans tête si possible) ?

J'utilise ZShark avec un ConBee original sur un Raspberry Pi pour capturer les paquets et Wireshark sur un Mac pour les analyser. Voir https://github.com/dresden-elektronik/deconz-rest-plugin/issues/405.

Alors voyez-vous des messages de journal indiquant que les commandes _Read Attributes_ ou _Write Attributes_ sont envoyées ? Et les réponses correspondantes du TRV ?

Vous pourriez probablement compiler une version spéciale de deconz où deconz peut renifler la plupart du trafic si vous êtes intéressé et n'avez pas de renifleur disponible.

Je vois la lecture dans le journal :
0x00158D00053D3623: update ZCL value 0x01/0x0201/0x4003 after 0 s
mais pas l'écriture défaillante dans 0x4003 (du moins pas pour la chaîne de recherche 4003 ). À quoi devrait ressembler le message de journal pour Read Attributes ou Write Attributes ?

deCONZ --auto-connect=1 --dbg-info=2 --dbg-aps=2 --dbg-error=1 --http-port=8080 --pid-file=/deconz/deconz.pid est utilisé pour démarrer deCONZ.

Je n'ai pas de deuxième ConBee pour renifler le trafic, donc les outils de reniflage ne sont pas une option.

Occupied Heating Setpoint 0x0012 peut être écrit et TRV modifie l'affichage en conséquence alors que 0x4003 ne peut être que lu. Je demanderai à eurotronic s'ils ont modifié quelque chose dans leur firmware qui affecte l'écriture de 0x0012 .

Je suppose que cela pourrait toujours être lié à l'ordre des attributs spécifiques au fabricant dans general.xml. Eurotronic n'est pas premier, mais 2ème si je me souviens bien.

eCozy est 1er. Proposeriez -vous de les changer à des fins de test,

Vous pouvez même le supprimer si vous n'avez pas d'eCozy. Mais oui, ça vaut peut-être le coup d'essayer.

J'ai la même version du firmware et j'émets également le problème dowhiletrue.
Dans deCONZ, je suis capable d'écrire une valeur sur 0x0012 qui s'affiche sur l'écran de l'appareil - 2050 à titre d'exemple.

une requête via API me donne ceci :
{
"config": {
"batterie": 80,
"displayflip": null,
"point de consigne de chaleur": 2000,
"verrouillé": nul,
"mode": "auto",
"décalage": 0,
"on": vrai,
"accessible": vrai
},
"ep": 1,
"etag": "d2affd7f0acd6f30e10e5fb9db713d4b",
"vu dernièrement": "2020-10-20T19:45Z",
"nom du fabricant": "Eurotronic",
"modelid": "SPZB0001",
"nom": "Thermostat",
"Etat": {
"dernière mise à jour": "2020-10-20T19:45:51.313",
"on": vrai,
"température": 1950,
"valve": 38
},
"swversion": "20191014",
"type": "ZHAThermostat",
"uniqueid": "00:15:8d:00:03:2f:62:4f-01-0201"
}

et Openhab affiche la valeur de 0x4003 jusqu'à ce que j'appuie à nouveau sur "READ" dans deCONZ. Essayer de modifier la valeur du point de consigne thermique dans Openhab n'est pas écrit dans le HAVC.

J'ai également des problèmes avec swversion 20191014. Je peux écrire 0x0012 via deCONZ Gui mais pas depuis home assistant ou deCONZ api. Le point de consigne thermique n'est pas non plus actualisé lorsque je le règle manuellement sur le HAVC.

Même problème ici!
il s'agit du journal avec une erreur lorsque le mode TRV est modifié dans l'application home ou eve d'automatique à chauffage par exemple.

Quelqu'un peut-il aider?

@olliox Les questions/problèmes concernant les intégrations tierces ne doivent pas être posés ici. Mettez-les dans leurs connards.

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/rest_sensors.cpp#L1086 peut être modifié en quelque chose comme (en pseudo-code) :

attrId = swversion >= 20191014 ? 0x0012 : 0x4003
if (addTaskThermostatReadWriteAttribute(task, deCONZ::ZclWriteAttributesId, VENDOR_JENNIC, attrId, deCONZ::Zcl16BitInt, heatsetpoint)) {
...

Je ne sais pas comment obtenir swversion cependant.

Seriez-vous d'accord avec ce changement @SwoopX et @ebaauw ?

attrId = 0x0012;

Je viens de le tester, l'écriture du point de consigne sur 0x0012 fonctionne également pour moi sur le firmware 20181205.

Avons-nous besoin de cette distinction entre les firmwares, c'est-à-dire y a-t-il un firmware qui n'accepte pas également l'attribut 0x0012 à côté du 0x4003 spécifique au fabricant ?

Je suis moi-même sur 20181205. C'est il y a un certain temps, mais si ma mémoire est bonne, 0x0012 n'est pas mis à jour lorsque la commande _Setpoint Raise/Lower_ est émise, et 0x4003 n'est pas mis à jour lorsque 0x0012 est défini. L'utilisation constante de 0x4003 (pour obtenir et définir la cible) a fonctionné de manière cohérente, j'ai donc eu recours à cela dans l'API.

Bien sûr, si les nouvelles versions du firmware ne prennent plus en charge cet attribut, nous devons nous en accommoder. Rendre le comportement dépendant de la version du logiciel semble être la voie à suivre. Notez que vous mentionnez les valeurs _Date Code_ au lieu de la version du logiciel. L'API expose soit comme swversion , selon l'attribut qui a été lu en dernier. Je ne sais pas s'il existe un ResourceItem , mais il est probablement plus sûr de vérifier le zclValue pour l'attribut Zigbee. Assurez-vous de modifier également les paramètres de rapport d'attributs, avec la même vérification de version.

Les TRV semblent pouvoir être mis à niveau par micrologiciel, mais je n'ai trouvé aucun fichier de micrologiciel.

Salut,

Malheureusement, j'ai les mêmes problèmes que @alpha23 et @olliox. Je viens d'acheter l'Eurotronic Spirit Zigbee hier et j'ai également le même code de date "20191014". Ce serait super si quelqu'un pouvait nous aider ici.

Meilleures salutations :)

Je vais le rouvrir pour le moment.

J'en ai acheté un début septembre avec la version 20191014 et j'ai pu me connecter en suivant cette instruction :
https://forum.iobroker.net/topic/28785/how-to-eurotronic-spirit-zigbee-mit-conbee-ii

J'en ai acheté deux autres hier avec le même firmware 20191014 et j'ai des problèmes pour les rejoindre. J'essaierai de revenir avec mes versions de docker.

Pourrait avoir besoin d'aide pour une enquête plus approfondie sur la façon de configurer mon journal pour voir ce qui se passe. J'ai essayé de régler le point de chaleur via deconz directement. Sur l'appareil déjà connecté, il fonctionne pour définir et le matériel est mis à jour :

Sur un nouvel appareil, l'écriture échoue

@DerOetzi Dans le nouveau firmware, le 0x4003 n'est plus accessible en écriture, pour changer le point de chaleur, vous devez écrire sur 0x0012. C'est tout l'intérêt des changements de code suggérés par

@DerOetzi Dans le nouveau firmware, le 0x4003 n'est plus accessible en écriture, pour changer le point de chaleur, vous devez écrire sur 0x0012. C'est tout l'intérêt des changements de code suggérés par

Mais les deux thermostats signalent la même version du micrologiciel 20191014 ?

Le mien a à 0x0030 (Source de changement de point de consigne) les valeurs :

• Manuel (sélectionné)
• Calendrier
• Zigbee

Peut-être que cela pourrait être la solution.. mais malheureusement c'est un attribut en lecture seule

@DerOetzi Dans le nouveau firmware, le 0x4003 n'est plus accessible en écriture, pour changer le point de chaleur, vous devez écrire sur 0x0012. C'est tout l'intérêt des changements de code suggérés par

Mais les deux thermostats signalent la même version du micrologiciel 20191014 ?

J'ai acheté deux unités récemment et les deux ne fonctionnent qu'en définissant le 0x0012, je suppose qu'eurotronic s'éloigne de l'écriture dans des attributs personnalisés et utilise désormais l'ensemble d'attributs plus standard.

@DerOetzi : il se peut que 20191014 représente en fait le Date Code plutôt que swversion comme ebaauw mentionné ci-dessus et vos modèles diffèrent par un autre attribut de fabrication. Tous les attributs sont-ils égaux entre le modèle de travail et le modèle de non-travail, si vous lisez un attribut après l'autre pour Basic , Power et Thermostat ?

J'ai remarqué sur mon modèle que read basic attributes lors de l'appariement ne conduit pas toujours à la lecture réussie des mêmes attributs. Cela pourrait peut-être expliquer pourquoi un modèle fonctionne et l'autre non.

J'ai vérifié deux fois les attributs Basic (0000), Power (0001), Identifier (0003) et Thermostat (0201), je ne trouve aucune différence au niveau des identifiants, des types, des accès et des valeurs.

Mes attributs de base sont (peut-être que cela vous aide à comparer les différentes versions) :

Concernant la consigne de température actuelle, le manuel du 10/2019 dit :

[] https://eurotronic.org/wp-content/uploads/2019/11/Spirit_ZigBee_BAL_web_DE_Okt.-2019.pdf

Les miens ont à peu près la même apparence. Remarquez la différence entre Date Code et SW Build ID .

Comme il peut y avoir des inconvénients lors du passage de 0x4003 à 0x0012 , je suggère de définir l'attribut en fonction de SW Build ID . Toutes les solutions plus sophistiquées sont les bienvenues.

Tu as raison. J'ai les mêmes valeurs. Je ne savais pas qu'il fallait double-cliquer sur un attribut pour lire cet attribut explicitement.

Plus je regarde le problème, je crois qu'il est toujours dû à l'ajout de deconz.

L'"ancien" de travail de septembre et le nouveau à partir de maintenant rapportent les valeurs suivantes sur les attributs de base :

• 0x0006 Code de date : 20191014
• ID de construction du logiciel 0x4000 : 22190930

Plus je regarde le problème, je crois qu'il est toujours dû à l'ajout de deconz.

L'"ancien" de travail de septembre et le nouveau à partir de maintenant rapportent les valeurs suivantes sur les attributs de base :

• 0x0006 Code de date : 20191014
• ID de construction du logiciel 0x4000 : 22190930

Chaque appariement se comporte différemment, car toutes les valeurs disponibles à partir de la base ne sont pas lues lorsque le bouton de lecture est cliqué.

Est-ce que quelqu'un sait pourquoi certains attributs n'apparaissent pas lorsque le bouton de lecture est cliqué mais apparaissent si le bouton de lecture d'un seul attribut est cliqué ?

À des fins de test, j'ai modifié le code comme suit :

DBG_Printf(DBG_INFO, "TEMP %d for sensor attribute %x\n", heatsetpoint, 0x0012);
if (addTaskThermostatReadWriteAttribute(task, deCONZ::ZclWriteAttributesId, VENDOR_JENNIC, 0x0012, deCONZ::Zcl16BitInt, heatsetpoint))

la sortie du journal affiche l'instruction du journal, mais rien ne change par la suite, pourquoi ?

Je peux également confirmer que sur un Spirit Zigbee acheté vers le 12 septembre, je peux écrire à la fois à 0x0012 et à 0x4003.
Sur 4 Spirit Zigbee que j'ai achetés cette semaine, aucun 0x4003 n'est accessible en écriture, mais 0x0012 l'est.

Les 5 appareils ont
Code de date 20191014
Code produit 1991
SW Construire ID 22190930

Seul le dispositif répond plus actuellement aux commandes temporaires de HA.

Utilisation de Conbee II, Phoscon 2.05.84, micrologiciel 26650700
HassOS 4.15 avec module complémentaire deCONZ 6.4.1, HA 0.116.4

Les 5 appareils ont

Es-tu sûr? Il n'y a aucun moyen de distinguer le dispositif qui ne permet la consigne à régler par 0x4003 des quatre appareils qui ne sont pas?

Je n'ai trouvé aucun attribut distinctif dans les clusters de base des deux appareils. Si vous le souhaitez, je peux lier des captures d'écran des deux.
Pour être sûr, j'ai d'abord lu le cluster de base, puis j'ai double-cliqué individuellement et lu chaque entrée individuellement également.

Même l'apparence physique externe est exactement la même - aucune différence dans l'anneau de fixation.

La seule différence que j'ai remarquée, c'est que l'adresse MAC de l'ancienne, qui fonctionne se termine par 2XXX, tandis que les 4 qui ne fonctionnent pas ont des adresses MAC se terminant par 3XXX

Encore une chose, FWIW :
J'ai jeté un œil au plugin STD OTAU. Pour chacun des 4 thermostats non fonctionnels, l'onglet Mise à jour OTAU n'affiche aucune donnée, c'est-à-dire. 0x000 pour tous les champs. Pour le thermostat qui fonctionne, les valeurs sont :
Fournisseur = 0x1037
Image = 0x110c
Version = 0x0162e9d2

Je ne sais pas si cela a une importance, mais j'ai pensé que je le partagerais quand même. :)

Si je peux faire autre chose pour comparer ou fournir des informations sur les appareils, faites-le moi savoir.

J'ai récemment acheté un Sprit ZigBee et je suis confronté au même problème (je peux régler la température via 0012, mais pas via 4003). Les attributs de la page de base sont les mêmes que ceux de petermarasek, donc aucune différence avec les thermostats plus anciens. L'adresse MAC se termine également par 3XXX.
J'ai déjà essayé de compiler une version modifiée du reste de l'api, mais sans succès (l'api s'exécute, aucun changement au thermostat, les boutons ne signalent plus les changements). Si quelqu'un pouvait modifier le code, je pourrais aider à tester avec le nouveau thermostat.

Même l'apparence physique extérieure est exactement la même

@petermarasek C'est

Pour être complet : voici le cluster _Basic_ de l'ancien firmware :

Et la vue OTAU (avec 8 Eurotronic Spirit TRV). Je n'ai aucune idée si/comment la version du fichier du micrologiciel se rapporte au _SW Build ID_.

Pour chacun des 4 thermostats non fonctionnels, l'onglet Mise à jour OTAU n'affiche aucune donnée

@petermarasek , les lignes finiront par se remplir (le TRV doit interroger le serveur _OTAU_), ou vous pouvez essayer de forcer cela en sélectionnant le nœud et en appuyant sur _Query_.

Sur les thermostats qui ne fonctionnent pas, quel code d'état est renvoyé lors de la tentative d'écriture de l'attribut 0x4003 ?

Quelqu'un a-t-il déjà essayé la télédétection avec le firmware 22190930 ?

Quelqu'un a-t-il contacté le support Eurotronic ?

@petermarasek , juste une idée folle : quelle est la valeur de 0x4000 sur le TRV qui fonctionne et sur ceux qui ne fonctionnent pas. Je pourrais imaginer le TRV n'acceptant pas 0x4003 lorsque 0x4000 a la mauvaise valeur. Cet attribut permet de basculer entre le mode point de consigne et le contrôle direct de la vanne (en contournant l'algorithme PID des TRV). Le manuel est nul pour expliquer les détails...

0x4000 = la valeur par défaut est "manuel". Si vous définissez l'attribut sur "Inconnu 1", le TVR l'écrase par "manuel". Si vous définissez l'attribut sur "Unknown 2", le TVR ne l'écrase pas, mais la modification de 0x4003 ne fonctionne pas encore.

Comme je l'ai écrit ci-dessus, tous les attributs de base, d'alimentation, d'identification et de thermostat sont identiques pour fonctionner et ne pas fonctionner. Revérifié 0x4000 aucune différence

Sur les thermostats qui ne fonctionnent pas, quel code d'état est renvoyé lors de la tentative d'écriture de l'attribut 0x4003 ?

Quelqu'un a-t-il déjà essayé la télédétection avec le firmware 22190930 ?

Quelqu'un a-t-il contacté le support Eurotronic ?

J'ai contacté le support Eurotronic et leur ai donné l'URL de ce fil. Espérons qu'ils répondent et parviennent à dissiper les confusions ici :)

Salut,

J'ai le Danfoss Ally qui est très similaire à l'Eurotronic, j'ai trouvé que le réglage du point de consigne semble bien fonctionner. L'écran du thermostat se met à jour instantanément, mais le moteur de la vanne réagit parfois immédiatement même à de grands changements de 10 degrés +, mais parfois cela peut prendre des heures pour se déplacer. J'imagine que cela pourrait être dû au PID, mais je ne sais pas comment contourner cela.

Salut, j'ai eu un Spirit Zigbee hier et j'ai essayé de le coupler, ma configuration est pi 3b+ avec Hass 0.116.4 et conbee II.
Je suis allé l'associer à Phoscon en tant que capteur mais rien n'y est apparu, mais sur le de CONZ s'affiche comme apparié, appuyez plusieurs fois sur le bouton de lecture et les attributs sont maintenant renseignés, mais vous ne pouvez toujours pas l'ajouter à Phoscon.
Est-il possible de le contrôler via Homeassistant ? comment puis-je l'ajouter en tant qu'appareil ?

Merci!

L'appareil n'apparait pas dans phoscon, vous avez besoin d'une troisième application ou utilisez directement l'api pour cela.

Mais il semble qu'il y ait un problème avec la version récente, tout n'est pas clair.

Je peux également confirmer que sur un Spirit Zigbee acheté vers le 12 septembre, je peux écrire à la fois à 0x0012 et à 0x4003.
Sur 4 Spirit Zigbee que j'ai achetés cette semaine, aucun 0x4003 n'est accessible en écriture, mais 0x0012 l'est.

Les 5 appareils ont
Code de date 20191014
Code produit 1991
ID de construction SW 22190930

Seul l'ancien appareil répond actuellement aux commandes temporaires de HA.

Utilisation de Conbee II, Phoscon 2.05.84, micrologiciel 26650700
HassOS 4.15 avec module complémentaire deCONZ 6.4.1, HA 0.116.4

J'ai le même problème. Deux Spirit Zigbees achetés le 30 juillet fonctionnent très bien. Deux autres Spirit Zigbees achetés le 20 octobre ne fonctionnent pas car 0x4003 n'est pas inscriptible :

Le manuel Eurotronic Spirit Zigbee suggère d'écrire à 0x0012 ou 0x0014, pas à 0x4003 :

6.5.4 Point de consigne de température actuel
Toute valeur écrite dans l'attribut de point de consigne de chauffage du thermostat / occupé / inoccupé (0x0012 ou 0x0014) sera automatiquement copiée dans l'attribut du point de consigne de température actuelle (0x4003) pour permettre le fonctionnement du TRV sans avoir besoin de connaître les attributs spécifiques du client.

J'utilise Home Assistant 0.117.1, Phoscon 2.05.86, Conbee II Firmware 26580700

Mais il n'y a aucun moyen de reconnaître l'ancien / le nouveau périphérique ?

Mais il n'y a aucun moyen de reconnaître l'ancien / le nouveau périphérique ?

Je regarde cela depuis 2 semaines et la seule différence que j'ai pu trouver concerne les MAC Id du TVR, mais c'est plus une observation qu'une certaine différence.

Le seul TVR qui a un 0x4003 inscriptible a un MAC Id se terminant par 2XXX. J'ai quatre autres TVR qui ont un 0x4003 en lecture seule et tous leurs identifiants MAC se terminent par 3XXX.

Mais il n'y a aucun moyen de reconnaître l'ancien / le nouveau périphérique ?

Je regarde cela depuis 2 semaines et la seule différence que j'ai pu trouver concerne les MAC Id du TVR, mais c'est plus une observation qu'une certaine différence.

Le seul TVR qui a un 0x4003 inscriptible a un MAC Id se terminant par 2XXX. J'ai quatre autres TVR qui ont un 0x4003 en lecture seule et tous leurs identifiants MAC se terminent par 3XXX.

Malheureusement, je ne peux pas le confirmer. L'ID MAC de mon TVR qui a un 0x4003 en lecture seule se termine par 261A. :(

Alors, pourquoi ne pas simplement tester la méthode 1 et si elle échoue, utiliser la méthode 2 ?

Ainsi, mes deux Eurotronic Spirits (les deux se terminent par 3XXX) ne sont pas capables d'écrire en 0x4003. Comme observé cependant, je peux écrire sur 0x0012 sans aucun problème et, comme indiqué, cela entraîne une modification immédiate du point de consigne sur l'appareil. Existe-t-il un moyen de modifier manuellement l'adresse que deCONZ utilise pour régler la température ? J'utilise deCONZ sur Hassio et le problème semble si facile à résoudre si je pouvais simplement trouver comment changer 0x4003 en 0x0012, n'est-ce pas ?

Alors, pourquoi ne pas simplement tester la méthode 1 et si elle échoue, utiliser la méthode 2 ?

Je ne suis donc vraiment pas fan des programmations exceptionnelles.

Je veux résumer ce que j'ai compris jusqu'à présent. Alors corrigez-moi si je me trompe !

Tous les appareils avec les attributs suivants fonctionnent comme prévu, lors du réglage de la température à l'adresse 0x0012 :
Code de date 20191014
Code produit 1991
ID de construction SW 22190930
MAC se termine par 2XXX (ceux-ci fonctionnent également avec 0x0012 et 0x4003) ou 3XXX (ceux-ci fonctionnent uniquement avec 0x0012)

Les appareils comme celui de @ebaauw avec les attributs suivants ne fonctionnent que sur l'adresse 0x4003 comme prévu :
Code de date 20181205
Code produit 1001
ID de version logicielle 15181120

Donc, à mon avis, nous pouvons décider par un ou les trois attributs Date Code, Product Code ou SW Build ID quelle adresse utiliser, si nous pouvons être sûrs que le premier groupe mentionné fonctionne vraiment comme prévu sur 0x0012. Pour avoir 3 appareils de ce groupe un avec 2XXX et deux avec 3XXX, je peux confirmer ce comportement correct pour moi.

Quelqu'un a-t-il essayé de faire fonctionner la "télédétection" sur l'un des nouveaux appareils ? Ce serait formidable s'ils mettaient en œuvre cela.

Et BTW, personne n'a de "défaut de segmentation" lors de l'ajout de l'appareil ?

Salut! J'ai également acheté un Eurotronic Spirit Zigbee récemment et je rencontre exactement les mêmes problèmes (je peux écrire sur 0x012 mais pas sur 0x4003).
Puisqu'il semble qu'il n'y ait pas de moyen clair de faire la distinction entre l'ancienne et la nouvelle version : que se passe-t-il si nous procédons dans l'autre sens et envoyons toujours 0x012 ? Comment l'ancienne version du thermostat réagit-elle à cela ?

Désolé, je viens de lire un article précédent décrivant que l'écriture de 0x012 est problématique sur la version précédente.
@petermarasek L'écriture de 0x012 sur l'appareil qui accepte le code 0x4003 est-elle également problématique ? Sinon, la vérification du code de date (ou l'un des autres attributs) pourrait toujours fonctionner.

Je viens de découvrir d'autres mauvaises nouvelles : dans mon unité Eurotronic Spirit, il semble également que la consigne de température actuelle (les valeurs récupérées par 0x4003) ne soit pas non plus mise à jour de manière cohérente après avoir fait fonctionner manuellement l'unité :( D'autre part, la "consigne de chauffage occupée" (la valeur 0x012) est mise à jour de manière cohérente après une opération manuelle.Je pense donc que cette valeur devrait également être utilisée pour lire la température de consigne actuelle des unités les plus récentes... Quel gâchis...

@petermarasek L'écriture de 0x012 sur l'appareil qui accepte le code 0x4003 est-elle également problématique ? Sinon, la vérification du code de date (ou l'un des autres attributs) pourrait toujours fonctionner.

Le TVR qui accepte d'écrire sur 0x4003 accepte également d'écrire sur 0x0012 et 0x0014. (Consigne de chauffage occupé et inoccupé). L'écriture dans 0x0012 ou 0x0014 copie automatiquement ces valeurs dans 0x4003 selon la documentation et l'observation personnelle.

Le TVR qui accepte d'écrire sur 0x4003 accepte également d'écrire sur 0x0012 et 0x0014. (Consigne de chauffage occupé et inoccupé). L'écriture dans 0x0012 ou 0x0014 copie automatiquement ces valeurs dans 0x4003 selon la documentation et l'observation personnelle.

Ok, ça a l'air encourageant ! Alors peut-être pourrions-nous utiliser la version matérielle ou l'un des attributs pour savoir quel code envoyer au TVR. Et puis faites de même lors de la lecture de la température actuelle.

@petermarasek Merci d'avoir vérifié !

D'accord, je suis un peu confus maintenant...

Lorsque j'avais l'habitude de rechercher comment régler la consigne de chauffage sur mon nouveau thermostat, j'ai vu un autre thermostat (que j'ai acheté l'année dernière) avec la même version logicielle que celle qui ne fonctionnait pas.

J'ai ouvert l'interface graphique DeCONZ et vérifié que les deux unités ont les mêmes versions matérielles et logicielles :

Ce qui est amusant, c'est que l'unité appelée "Küche..." ne rapporte pas d'erreur, si j'écris à 0x4003. Même si j'utilise les boutons pour régler la température manuellement, la valeur stetted est signalée correctement. Tout fonctionne comme prévu.

L'unité appelée "Büro..." signale une erreur si j'écris en 0x4003 et ne signale aucun changement.

Les deux unités sont venues dans une boîte avec des impressions dorées dessus. Toutes les autres unités que je possède avaient une boîte avec des impressions vertes.

Peut-être y a-t-il des unités buggy là-bas?

@ alpha23 C'est l'expérience que plusieurs ici ont décrite. Il semble qu'Eurotronic ait produit des lots de l'appareil qui ne permettent pas d'écrire sur 0x4003 et certains qui le font, sans qu'ils aient d'attributs différentiels, physiquement ou selon les attributs de base du cluster. À mon avis, ce n'est pas un bug, mais par conception. La dernière documentation disponible indique que l'écriture sur 0x0012 et 0x0014 est autorisée et conforme aux spécifications, au lieu d'écrire sur 0x4003, ce qui, je pense, est un attribut spécifique au fabricant selon ceci : (voir la section 6.5.4)
https://eurotronic.org/wp-content/uploads/2019/11/Spirit_ZigBee_BAL_web_EN_November-2019.pdf

@petermarasek Mais si tous les modèles les plus récents fonctionnent normalement (ceux qui fonctionnent et ceux qui n'écrivent pas sur 0x4003) lors de la lecture et de l'écriture sur 0x0012, nous pourrions utiliser de manière fiable la version matérielle, le code de date ou l'ID de construction du logiciel pour avoir une simple instruction if (ou extension celle en cours) pour envoyer le bon code (0x4003 pour la version HW < 5 et 0x0012 pour HW >= 5).

Je suis prêt à apporter les modifications nécessaires au code source, mais cela prendra un certain temps car je n'ai pas encore touché le code deconz-rest-api (ou le projet d'ailleurs) et j'ai besoin de comprendre comment configurer un environnement de test de développeur (puisque j'exécute deconz sur mon PI en tant que plugin pour HA).
A côté de ça, je n'ai qu'une unité qui ne fonctionne pas pour le moment donc je ne peux pas faire de test de régression. Je n'ai pu vérifier que le code modifié fonctionne sur mon appareil lors de l'envoi et de la lecture de 0x0012.

Je suis prêt à apporter les modifications nécessaires au code source, mais cela prendra un certain temps car je n'ai pas encore touché le code deconz-rest-api (ou le projet d'ailleurs) et j'ai besoin de comprendre comment configurer un environnement de test de développeur (puisque j'exécute deconz sur mon PI en tant que plugin pour HA).
A côté de ça, je n'ai qu'une unité qui ne fonctionne pas pour le moment donc je ne peux pas faire de test de régression. Je n'ai pu vérifier que le code modifié fonctionne sur mon appareil lors de l'envoi et de la lecture de 0x0012.

Ce serait génial. Je n'ai absolument aucune expérience de tout cela et comme je cours sur Hassio, je pense qu'il n'y a pas grand-chose à essayer pour moi. Ce que j'ai trouvé était un code spécifique dans le cpp du
Ici, il vérifie si le thermostat est d'Eurotronic et indique spécifiquement d'utiliser 0x4003. Peut-être que cela est d'une quelconque aide.

@petermarasek Si c'est par conception, il devrait y avoir une différence dans le firmware ou le matériel. Si les deux unités ont les mêmes versions, il devrait y avoir un autre problème. Pour moi, la seule différence entre l'appareil qui fonctionne et l'appareil qui ne fonctionne pas est que j'ai commandé celui qui fonctionne sur voelkner.de et celui qui ne fonctionne pas sur amazon.de

@joukestoel J'ai une unité avec la version HW 5 qui fonctionne avec 0x4003 et une avec la même version HW qui ne fonctionne pas. Si j'écris sur 0x0012 sur l'unité de travail, je dois lire 0x4003 manuellement pour obtenir la valeur mise à jour.

Comme la documentation le dit, le problème suivant est que seul 0x4003 est à signaler. Mais cela ne se produira pas lorsque j'écrirai à 0x0012 ou que j'utiliserai les boutons de l'appareil pour modifier la valeur.

Comme la documentation le dit, le problème suivant est que seul 0x4003 est à signaler. Mais cela ne se produira pas lorsque j'écrirai à 0x0012 ou que j'utiliserai les boutons de l'appareil pour modifier la valeur.

@alpha23 De quelle documentation parlez-vous ? Je pense que le correctif devrait être (comme l'a souligné @ mod3k ) que le code utilisé pour lire la température de consigne actuelle devrait également « juste » lire la valeur 0x0012 et oublier la valeur 0x4003. Dans la capture d'écran du code joint par @ mod3k, cela signifierait que la condition if doit être étendue pour vérifier également la version matérielle.

Mais comme je suis nouveau ici (et la base de code), je pourrais très bien me tromper et je pourrais manquer complètement quelque chose.

@joukestoel https://eurotronic.org/wp-content/uploads/2019/11/Spirit_ZigBee_BAL_web_EN_November-2019.pdf

Le O/N à droite indique si l'attribut est à signaler ou non.

@alpha23 Merci pour le lien ! Et merci de l'avoir signalé. Comme je l'ai mentionné plus tôt, je suis nouveau dans le monde de la domotique et des appareils Zigbee, j'ai donc beaucoup à apprendre :s Est-ce que le rapport signifie que seuls les attributs de rapport envoient périodiquement leur valeur à deconz ?

Je dois revenir sur ma déclaration précédente selon laquelle je pensais que la valeur 0x4003 n'avait pas été mise à jour. Il s'avère que le temps de rapport par défaut est défini sur 600 secondes maximum. En guise de test, j'ai remplacé la configuration pour signaler après 20 secondes maximum et maintenant je vois la valeur mise à jour dans l'attribut 0x4003. Cela signifie que le code qui lit la température de consigne actuelle n'a pas à changer (et le changement n'aurait probablement pas fonctionné de toute façon puisque l'attribut 0x0012 n'est pas un attribut de rapport)

Oui, je pense que le seul changement à apporter est une décision dépendante du matériel d'écrire sur 0x0012 ou 0x4003. Je viens d'écrire manuellement une nouvelle température à 0x0012 et la valeur a été immédiatement mise à jour à 0x4003.

tbh : si j'écrivais ce code uniquement pour moi-même, j'enverrais simplement la commande aux deux identifiants. Cela semble sale, mais quoi que le thermostat accepte, il devrait être mis à jour de toute façon

J'ai contacté le support Eurotronic et leur ai donné l'URL de ce fil. Espérons qu'ils répondent et parviennent à dissiper les confusions ici :)

J'ai également contacté le support Eurotronic et leur ai demandé de répondre à ce fil pour expliquer comment nous pouvons résoudre le problème actuel. Je n'ai pas reçu de réponse avec une solution jusqu'à présent...

Je viens d'ajouter une pull request (#3626) qui devrait résoudre nos problèmes de modification du point de consigne de chauffage actuel.
Il m'a fallu un certain temps pour comprendre, mais en plus d'écrire sur l'attribut 0x0012 discuté précédemment (point de consigne de chauffage occupé), je devais également envoyer un code de fabricant générique.

Pour faire la distinction entre les unités les plus anciennes et les plus récentes, j'ai utilisé l'attribut Version du logiciel. Pour les unités avec une version logicielle inférieure à 22190903, l'ancien attribut 0x4003 sera également écrit. Pour les modèles avec la version SW 22190903 et plus, l'attribut 0x0012 sera utilisé.

Ce correctif fonctionne pour mon unité, mais comme je n'ai qu'une seule unité, je ne peux pas garantir qu'il fonctionnera également pour les unités plus anciennes et autres, alors gardons les doigts croisés 🤞

Wow c'est rapide. Merci beaucoup! J'espère que ces changements pourront être mis en œuvre rapidement. Jusque-là, j'utilise ZHA au lieu de deCONZ. Je l'ai installé hier et tout semble bien fonctionner là-bas (l'intégration de ZHA utilise 0x0012 en soi).

Un grand merci à @joukestoel pour cette correction ! Maintenant, nous devons attendre la sortie, espérons-le bientôt

Pour ce que ça vaut : Peut confirmer que https://github.com/dresden-elektronik/deconz-rest-plugin/pull/3626 a résolu le problème de mon côté.

Avoir une unité Spirit avec SW Build ID de 22190930 et avec la version 2.5.87 de Phoscon/deCONZ je peux maintenant contrôler avec succès la consigne de chauffage depuis l'API REST (et par extension, Home Assistant).

A rencontré un problème où la lecture des informations de base sur le cluster (afin de configurer l'appareil dans l'API REST) ​​n'a _pas_ récupéré correctement les informations d'ID de build SW (le champ est resté vide). J'ai dû explicitement "lire" ce champ à partir de l'interface graphique pour que les choses commencent à fonctionner ...

De plus, sans aucun rapport : la documentation de Sensors mentionne que le paramètre config est heatingsetpoint alors qu'en réalité il semble être heatsetpoint ...

Je viens d'ajouter une pull request (#3626) qui devrait résoudre nos problèmes de modification du point de consigne de chauffage actuel.
Il m'a fallu un certain temps pour comprendre, mais en plus d'écrire sur l'attribut 0x0012 discuté précédemment (point de consigne de chauffage occupé), je devais également envoyer un code de fabricant générique.

Pour faire la distinction entre les unités les plus anciennes et les plus récentes, j'ai utilisé l'attribut Version du logiciel. Pour les unités avec une version logicielle inférieure à 22190903, l'ancien attribut 0x4003 sera également écrit. Pour les modèles avec la version SW 22190903 et plus, l'attribut 0x0012 sera utilisé.

Ce correctif fonctionne pour mon unité, mais comme je n'ai qu'une seule unité, je ne peux pas garantir qu'il fonctionnera également pour les unités plus anciennes et autres, alors gardons les doigts croisés 🤞

J'ai SW Build ID 22190930 et cela fonctionne bien avec l'ancienne variante (2.05.81 / 14.9.2020).
Je ne sais pas si cela va casser si je mets à jour maintenant?

Je viens de lancer la nouvelle version. Malheureusement, nous devons signaler que nous n'avons qu'à mi-chemin du correctif de @joukestoel sur ce problème. l'attribut Basic cluster 0x4000 SW Build ID ne semble pas être lu automatiquement après le redémarrage. Pour cela, l'adresse correcte 0x012 n'est utilisée qu'après lecture manuelle de cet attribut. Pour le moment je n'ai que trois thermostats pour faire ça après redémarrage, mais quand j'en aurai 13 j'aurai besoin de ne pas faire ça manuellement après chaque redémarrage

Même problème ici. Si je redémarre deCONZ ou Spirit, plus aucune mise à jour n'est reçue et la température ne peut plus être réglée.

@DerOetzi @dowhiletrue Ah, désolé ! Toujours en train d'apprendre ce truc de Zigbee Deconz :) Je vais apporter une amélioration au code pour qu'il soit plus robuste ! Espérons que cela puisse être inclus dans la prochaine version.

Je vous tiens au courant!

Et j'ai remarqué un autre problème sur les nouveaux :

Le commutateur de mode désactivé ne fonctionne pas aussi bien sur ceux-ci. Je vais essayer d'enquêter là-dessus !

Mise à jour : l'écriture des indicateurs d'hôte sur 0x4008 échoue également

Bonjour à tous, notre société travaille actuellement pour Eurotronic sur la révision du code du firmware et sur la résolution des problèmes d'écriture dans les attributs 0x4003 et 0x4008. Veuillez être patient car nous ne sommes pas les auteurs du firmware original.

La bonne nouvelle est que j'ai réussi à mettre à jour le firmware par liaison radio (OTA).

S'il vous plaît, si vous avez découvert un autre problème, écrivez-le ici ou contactez-moi par e-mail. Merci.

Bonjour à tous, notre société travaille actuellement pour Eurotronic sur la révision du code du firmware et sur la résolution des problèmes d'écriture dans les attributs 0x4003 et 0x4008. Veuillez être patient car nous ne sommes pas les auteurs du firmware original.

La bonne nouvelle est que j'ai réussi à mettre à jour le firmware par liaison radio (OTA).

S'il vous plaît, si vous avez découvert un autre problème, écrivez-le ici ou contactez-moi par e-mail. Merci.

Merci pour les bonnes nouvelles. Pouvez-vous s'il vous plaît donner une brève instruction, comment faire l'OTA? Par exemple, où trouver le fichier du firmware ?

@witriol Pour autant que j'ai pu tester, le thermostat ne répond pas non plus correctement à la tentative de définition de local_temp_calibration (attribut 0x0010). Auparavant, cela acceptait des valeurs comprises entre -500 et 500 (+- 5 degrés) mais répond maintenant avec une "valeur illégale", quelle que soit la valeur écrite.
Veuillez également vérifier que 0x4001 peut être écrit lorsque le thermostat est réglé en mode manuel (0x4000 réglé sur 0x02, si je me souviens bien)
Si vous avez un micrologiciel prêt à être testé, j'ai un nouveau et quelques-uns des anciens, je peux donc vérifier que le micrologiciel se comporte comme les anciens (correspond également au document sur l'ancien).

UNE.

La bonne nouvelle est que j'ai réussi à mettre à jour le firmware par liaison radio (OTA).

@Witriol C'est

Le principal problème avec le micrologiciel est qu'il semble prendre en charge la détection de température à distance, mais il ne semble pas accepter les messages _Report Attribute_ d'un capteur de température à distance.

Bonjour à tous, notre société travaille actuellement pour Eurotronic sur la révision du code du firmware et sur la résolution des problèmes d'écriture dans les attributs 0x4003 et 0x4008. Veuillez être patient car nous ne sommes pas les auteurs du firmware original.

La bonne nouvelle est que j'ai réussi à mettre à jour le firmware par liaison radio (OTA).

S'il vous plaît, si vous avez découvert un autre problème, écrivez-le ici ou contactez-moi par e-mail. Merci.

Salut @Witriol , ça fait plaisir d'apprendre que les mises à jour OTA fonctionnent ! :-)

Outre les problèmes déjà mentionnés, j'en ai deux supplémentaires :

• Je peux changer le "mode TRV (0x4000)" en 1 afin de pouvoir changer la position de la vanne manuellement. Je peux voir que le mode de fonctionnement de la vanne change lorsque l'écran affiche "0", qui est la position actuelle de la vanne. Lorsque vous essayez de modifier cette position de vanne via "Définir la position de la vanne (0x4001)", l'appareil renvoie "INVALID_VALUE", quelle que soit la valeur que j'envoie.
• De plus, je perds la connexion Zigbee tous les deux jours et même un cycle d'alimentation n'aide pas. Je vais devoir réinitialiser et ré-appairer l'appareil via la "méthode à trois boutons".

Comme il semble y avoir beaucoup de problèmes avec le firmware actuel, une rétrogradation serait une solution rapide et propre que j'apprécierais grandement.

Salut les gars, je rencontre le même problème avec un tout nouveau thermostat à alcool. Est-il possible que les gars d'Eurotronic aient publié par erreur une version du firmware avec une faute de frappe dans son nom (22190930) avant de revenir à la convention de nommage d'horodatage d'origine (20191014) ? Le nom de l'attribut 0x0006 "Date Code" implique un horodatage. peluche

@Witriol J'attends également avec impatience la mise à jour du firmware OTA ! Merci d'avance!
peluche

@teddy-rpi : Il y a une date de construction du firmware et une version du firmware :

Je viens de créer une deuxième demande d'extraction qui implémente une solution de contournement temporaire brute comme proposé précédemment par @DerOetzi : il suffit d'écrire aux deux attributs (0x4003 et 0x0012) lors de la modification du point de consigne de chauffage.
Ce n'est certainement pas une bonne solution, mais depuis que @Witriol nous a
Encore une fois le correctif fonctionne sur ma version du thermostat mais je ne peux pas donner plus de garanties :)

@magicdude4eva : Merci ! Comment puis-je découvrir la version du firmware ? Dans deCONZ sous le cluster de base, l'attribut 0x0006 "Date Code" me donne 20191014 et l'attribut 0x4000 "SW Build ID" est vide.

Je viens d'ajouter une pull request (#3626) qui devrait résoudre nos problèmes de modification du point de consigne de chauffage actuel.
Il m'a fallu un certain temps pour comprendre, mais en plus d'écrire sur l'attribut 0x0012 discuté précédemment (point de consigne de chauffage occupé), je devais également envoyer un code de fabricant générique.

Pour faire la distinction entre les unités les plus anciennes et les plus récentes, j'ai utilisé l'attribut Version du logiciel. Pour les unités avec une version logicielle inférieure à 22190903, l'ancien attribut 0x4003 sera également écrit. Pour les modèles avec la version SW 22190903 et plus, l'attribut 0x0012 sera utilisé.

Ce correctif fonctionne pour mon unité, mais comme je n'ai qu'une seule unité, je ne peux pas garantir qu'il fonctionnera également pour les unités plus anciennes et autres, alors gardons les doigts croisés 🤞

Merci beaucoup. Maintenant, il fonctionne très bien pour moi.

Je viens de créer une deuxième demande d'extraction qui implémente une solution de contournement temporaire brute comme proposé précédemment par @DerOetzi : il suffit d'écrire aux deux attributs (0x4003 et 0x0012) lors de la modification du point de consigne de chauffage.
Ce n'est certainement pas une bonne solution, mais depuis que @Witriol nous a
Encore une fois le correctif fonctionne sur ma version du thermostat mais je ne peux pas donner plus de garanties :)

Je n'ai jamais suggéré une telle méthode. Pensez que c'est une solution de contournement vraiment laide. Préférez nous utilisons votre première solution et la force deconz à lire l'adresse du cluster de base 0x4000 si elle est vide.

Désolé @DerOetzi , j'ai mal cité. C'est @mod3k qui l'a suggéré. Je suis d'accord que la solution de contournement est moche mais j'espère que ce n'est pas nécessaire trop longtemps et pour être honnête, mon correctif précédent n'était pas non plus un joyau :s

Je pense que ce correctif très moche est plus robuste et à sécurité intégrée que ma précédente implémentation

Le correctif fonctionne pour moi avec une fonction très basique (réglage de la température cible). Mon erreur : l'attribut 0x4000 était vide car je n'ai lu que le cluster entier dans deCONZ au lieu de double-cliquer sur l'attribut et de le lire séparément. Le champ a ensuite été renseigné avec le même numéro de firmware commençant par 22 que vous. Merci encore, en attendant le correctif OTA approprié pour pouvoir utiliser toutes les fonctionnalités. peluche

Désolé @DerOetzi , j'ai mal cité. C'est @mod3k qui l'a suggéré. Je suis d'accord que la solution de contournement est moche mais j'espère que ce n'est pas nécessaire trop longtemps et pour être honnête, mon correctif précédent n'était pas non plus un joyau :s

Pas de problème 👍 Je ne suis pas sûr que votre nouveau correctif fonctionnera correctement avec les anciennes versions du firmware. Si je comprends bien @ebaauw dans son article, écrire sur le mauvais attribut peut en quelque sorte dérouter les appareils plus anciens :

Je suis moi-même sur 20181205. C'est il y a un certain temps, mais si ma mémoire est bonne, 0x0012 n'est pas mis à jour lorsque la commande Setpoint Raise/Lower est émise, et 0x4003 n'est pas mis à jour lorsque 0x0012 est défini. L'utilisation constante de 0x4003 (pour obtenir et définir la cible) a fonctionné de manière cohérente, j'ai donc eu recours à cela dans l'API.

Je ne sais pas ce qui leur arrive lorsqu'ils écrivent sur les deux attributs. Personnellement, je préférerais donc vivre avec la solution de contournement pour lire le cluster de base 0x4000 manuellement après le redémarrage, ce qui est nécessaire pour que votre premier correctif fonctionne, avant de gâcher toutes les autres versions de firmware plus anciennes. Et peut-être que quelqu'un qui connaît mieux que moi deconz insides peut dire s'il est possible de le forcer à lire cet attribut automatiquement s'il est vide. A mon avis ce serait la meilleure solution.