Sinope Line Voltage Thermostats

Ok the problem is with the value onUserActive, It should be replace by onUserAction
It’s fix in 2.4.7

Bonjour j,essaye de faire fonctionner neviweb avec un gt130 depuis un bout dans home assistant sans trouver le problème. Est que quelqu’un a une idée quoi faire. Voici le log
Merci pour votre aides.

2023-11-16 23:11:48.907 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration neviweb130 which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant

2023-11-16 23:12:00.273 ERROR (MainThread) [homeassistant.setup] Error during setup of component neviweb130

File “/config/custom_components/neviweb130/init.py”, line 138, in setup

data = Neviweb130Data(hass_config[DOMAIN])

File “/config/custom_components/neviweb130/init.py”, line 170, in init

self.neviweb130_client = Neviweb130Client(username, password, network, network2)

File “/config/custom_components/neviweb130/init.py”, line 200, in init

File “/config/custom_components/neviweb130/init.py”, line 245, in __get_network

Bonjour, c’est simple vous ne vous connectez pas à Neviweb. Vous devez ajouter ceci dans le fichier configuration.yaml

neviweb130:
  username: !secret climate_username <-- votre courriel pour connecter a Neviweb
  password: !secret climate_password <-- votre mot de passe neviweb
  network: !secret climate_gateway130 <-- le nom de la location dans Neviweb où sont vos appareils
  scan_interval: 360
  stat_interval: 600

Il faut aussi ajouter du logging dans configuration.yaml comme ceci:

logger:
  default: warning
  logs:
    homeassistant.custom_components: debug
    custom_components.neviweb130: debug

!secret climate_username signifit que vos informations confidentielles sont inscrites dans le fichier secrets.yaml, username, password et network comme ceci:

climate_username: '[email protected]'
climate_password: 'mot_de_passe'
climate_gateway130: 'la_maison'

ensuite redémarrez HA

Hi Claude, I am new to HA, thanks for all the support you provide.

I have a few Sinope devices including the GT130 and 2 thermostat TH1124ZB and TH1124WF, I am trying to get a trigger on status change from IDLE to HEATING to perform an action on a Switch. During all my test, I am not able to see the trigger happening. Then I realize that even in the Card, the status change from IDLE to HEATING is happeing every 6 minutes, which is the scan_interval in the configuration.yaml. This explain why I was not seeing the trigger happeing.

Is this the normal behaviour ? How could it be faster ?

I have an OpenGarage device and when the state change from CLOSE to OPEN, it apears after 1-2 seconds.

Thanks
Benoit

Un gros gros merci Claude, Mon problème était un stupide . que j’avais oublié, depuis si longtemps. Comment puis contribuer à ton travail exceptionnel?

Hi Benoit, unfortunately neviweb130 cannot receive the event from the device. When there is a change on a device state, the device send it to Neviweb who refresh the neviweb portal. But neviweb130 can only poll Neviweb every scan_interval and never receive event from the device.
If you want a faster interaction, switch to ZHA for your zigbee devices where you will get instant response on each device state change. But this is only for the zigbee devices. For the wifi we have only neviweb130 for now.

Thanks Claude, a lot of learning here for me, not sure what is ZHA and how to integrate it. I will do more reading.

Another side question, you suggest to Cyclone76 the line to put in the configuration.yaml, they are different (they use !secret) compared to the one you suggest in your description page (no !secret).

The initial one (no !secret) work for me but not the new one, it give configuration error.

Which one should we use ?

Thanks
Ben

secrets.yaml is a HA config file where you put your login, passwd etc. this file is protected so nobody can see your secrets. Both method are ok but you need to put only one method in configuration.yaml.
In configuration.yaml you put

  username: !secret climate_username
  password: !secret climate_password
  network: !secret climate_gateway130

and in secrets.yaml you put the real things

climate_username: '[email protected]'
climate_password: 'my_neviweb_pass_word'
climate_gateway: 'my_neviweb_location'

ZHA is a component you load via parameters/devices and services zigbee home automation. You need to buy a zygbee gateway like Conbee II usb dongle and it will allow you to connect directly to you zigbee device without neviweb130 or neviweb.
Zigbee devices can only be connected to one network so it is Neviweb via the GT130 or ZHA not both.

Thanks for the explanation Claude, it clarify a lot of things for me.
I thing I prefer to stick with neviweb130 for now.
What is the minimum scan_interval we could set ?

Thanks
Ben

Comment fait on pour afficher les donnés de consommations et autres qui apparaisse sans la passerelle en zha dans le dashboard et la la rbrique energies?

Sinopé long time ago ask us to stay at a minimum of 5 minutes. If you go lower then that Sinopé server will disconnect you.

Si je comprends bien vous voulez afficher des données venant des appareils dans ZHA dans la section énergie. il y a plusieurs méthodes:

  • Tous les données utilisables sont affichées dans outils de développement/etats. sélectionnez votre appareils et dans la colonne de droite il y a la liste des attributs avec leur valeur.

Pour mettre cela dans énergie il faut créer un template sensor comme ceci.

template:
    - sensor:
        - name: "salle_a_diner_floor_temperature"
          unit_of_measurement: '°C'
          device_class: temperature
          state_class: measurement
          state: >
            {% if state_attr('climate.salle_a_diner_thermostat', 'current_temperature') < 1 %}
              {{ states('sensor.salle_a_diner_current_temperature') }}
            {% else %}
              {{ state_attr('climate.salle_a_diner_thermostat', 'current_temperature') }}
            {% endif %}

Vous ajoutez ensuite ce sensor dans énergie

  • vous pouvez également lire directement les valeurs d’un attribut dans un cluster avec zha tooltip:
service: zha_toolkit.attr_read
data:
  ieee: climate.salle_de_bain_thermostat
  cluster: 0xff01
  attribute: 0x010d
  manf: 0x4508
  state_id: sensor.room_temperature
  state_value_template: "value / 100"
  allow_create: true
  force_update: true
  use_cache: true
  event_success: my_read_success_trigger_event
  event_fail: my_read_fail_trigger_event
  event_done: my_read_done_trigger_event

Ca va créer le sensor.room_temperature et lui donner la valeur de température. Il suffit de créer une automation qui utilise ce service pour aller chercher le data selon la dréquence désirée. Vous pouvez donner le nom que vous voulez au sensor

Bonjour à tous,

J’envisage fortement acheter le calypso en ZigBee. J’hésite à acheter aussi le pont gt130 comme j’ai seulement des Thermostats wifi.

Est-ce que l’intégration directe par ZHA se fait bien et est-ce qu’on peut jouer facilement avec pour les défis Hilo?

Merci d’avance! Les promo black Friday sont pas mal alléchantes!

I’m looking to replace a single line voltage programmable Honeywell thermostat with a smart one. It’s only used for supplemental heat in one room - the rest of the house is on a boiler controlled by an Ecobee.

I’ve skimmed through several Sinope threads to try and get an idea of how well it works, and to decide wifi vs. Zigbee (or to consider Mysa instead).

If I understand correctly, for the Sinope thermostats:

  • zigbee can be fully controlled locally by HA, wifi must go through cloud
  • zigbee can be added to neviweb with the GT130 gateway - does this still allow local control by HA?
  • on zigbee w/o the gateway, the only way to interact with the thermostat is via HA - can’t use their app to set schedules, etc.
  • on zigbee local only, there’s no way to update the firmware

Is this correct?

Also, a few more questions

  • what readings and controls are limited to either zigbee or neviweb?
  • what other advantages are there to one vs. the other, other than local control of course
  • which is least effort to set it and forget it?

Thanks, and I really appreciate all of @claudegel 's time and effort on this.

Bonjour @Anteal, le calypso est parfaitement supporté dans ZHA. Ça te prends juste un gateway zigbee comme le conbee II ou autre. Il y en a plusieurs qui fonctionnent bien dans HA.
Pour jouer avec les défis hilo ou les pointes d’hydro tu peux installer le module complémentaire hydroqc que tu installes via parametres/modules complémentaires tu auras les infos pour savoir quand il y a une pointe d’hydro.
Si tu as installé mon module neviweb130 tu peux monitorer tes thermometres wifi pour l’attribut eco_status qui devient «on» quand la période de préchauffage commence.
Il est aussi possible avec le composant Imap de recevoir les courriel d’hydro annoncant une pointe et enclancher automatiquement l’arrêt et le redémarrage du calypso.
Dans ZHA tu as accès à la température de l’eau, à l’alerte de fuite, à la consommation électrique et naturellement au on/off.

Hi @jwabbit, effectively zigbee devices control can go via Neviweb and the custom_component neviweb130 or you can buy a zigbee dongle like the conbee II and go local via ZHA. All Sinopé devices are supported both way on HA.
wifi thermostat must be connected to Neviweb and can be controlled by neviweb130 on HA.
For the zigbee device they cannot be connected to ZHA and Neviweb at the same time. For HA control it’s Neviweb+Gt130+neviweb130 or ZHA+zigbee dongle.
Unfortunately on ZHA, the firmware update is still not available. zigbee devices can only be updated by Neviweb.
For the schedule on Neviweb you don’t have access to them if you go ZHA. But in HA you have a lot more scheluling than what Neviweb can offer. Hav a look at the Scheduler component and Scheduler card.
Feel free to ask more questions if you need. You may check this github

Sorry didn’t see the bottom. Both ZHA and neviweb130 have the same fonction. ZHA is faster as it get the event from the devices directly. neviweb130 is a little slower as it only poll Neviweb to send command or read state.
ZHA try to expose all device controle which are more complete then Neviweb. With zigbee you have acess to all cluster and attributes. with Neviweb you have access to what Sinopé want you to see and use.
As for the effort, Neviweb is a little easier to set but once it is done in neviweb130 or ZHA you have a lot more fun with all automation.
For example in HA with ZHA and neviweb130, I can turn off my heat pump when the local outside temperature goes too low and turn on all my thermostats and go back to heatpump when outside temperature raise and turn off my thermostats. With Neviweb you control only Neviweb devices.
When you install neviweb130 it poll Neviweb and install all devices found. When you install ZHA you have to pair each zigbee device one by one. But it takes few seconds to pair a device. After it’s done you just forget it and start to build automations.

Merci @claudegel ! L’intégration est vraiment super et fonctionne nickel

Par contre n’arrive pas à trouver l’entité Eco, est-ce qu’il y a un ajout à faire dans la config.yaml?

using TH1300ZB + Z2M

Quick question:

I know how to create sensors manually via YAML but is there a specific reason why current temperature is not an available as a default sensor?

image

Thanks!

Si c’est d’Éco Sinopé que vous parlez, tous les appareils participants ont les attribut suivants:
Pour les contrôleur de puissance:

  • eco_status: valeur «off» en dehors des période de pointe, devient «on» au début de la période de pré-chaufage.
  • eco_onoff: à «off» hors pointe, devient «on» au début de la pointe.
  • eco_optout: à «off» durant la pointe, devient «on» si on change le setpoint ou allume le contrôleur dyrant la pointe.
    On peut monitorer eco_status avec une automation pour savoir quand débute une période de pointe et contrôler d’autres appareils ne participant pas à Eco Sinopé.
    Pour les thermostats:
  • eco_status: valeur «off» en dehors des période de pointe, devient «on» au début de la période de pré-chaufage.
  • eco_optout: à «off» durant la pointe, devient «on» si on change le setpoint ou allume le contrôleur dyrant la pointe.
  • eco_setpoint: la valeur du setpoint durant la pointe

Vous les trouverez dans outils de développement/etats pour chacun de vos appareils participants