Hi everyone,
Happy to hear that local connectivity to gateway is progressing. This is clearly the way to go, bypassing Neviweb API!
But I’ve been working for the past few days in upgrading the current solution. I ran into some problems with this custom component that lead me to take a closer look at the code.
Here are some problems I experienced:
- I have around 25 Sinopé devices in my home (thermostats, switches and load controller). The
home-assistant.log file was always telling me errors about the Sinopé platform taking over 10 seconds to setup or just to update a single device.
- Sending command to a device was taking a long time to complete (same with Google Home which was spinning a lot before confirming me that a specific light was turned on).
- When a device was unavailable (lost connection), there was a crash in the logs and all my devices stop working.
- Home Assistant restart was really long.
What I discover from examining the code was shocking! To update a single device state, we were querying all other devices that are managed by the gateway. Each device was asking for every devices information instead of only its own (even my thermostats were asking for my lights status, there was no isolation between device types).
In my case, every 15 minutes, HA was calling an update for my 25 devices and for each of them, there was 25 queries to the Neviweb API. If you do the math, that was 625 calls to Neviweb each time I wanted to update my 25 devices. That represents 60 000 queries per day for me.
That explains why Sinopé blocked our accounts back in september 2018 and were asking to increasing polling interval to 15 minutes. Now that I’ve corrected this, I only need 25 queries if I want to update my 25 devices. That represents only 2400 queries per day.
Knowing that there will be way less queries to their servers, maybe Sinopé would be willing to accept a 5 minutes interval between polling, but I haven’t ask them… mofify this interval at your own risk!
So I’ve forked @claudegel git repository to correct this. I read a lot of code and documentation about HA component/platform development. I’ve found that defining a “main” component (representing the hub) with multiples platforms (light, switch, climate) was suiting perfectly for Neviweb (central hub/gateway, communicating with multiple kind of devices). This simplifies the way you setup the component in the configuration.yaml file. It also simplifies the code behind since we now have no code duplication between platforms. Eventually, following HA recommendations, the code interacting with the API should be integrated in a separate pypi project, but for now I’ve kept it in the component.
Here is a list of upgrades / improvements I’ve made:
- HA restart is now faster if you have multiple devices. You also get a quicker feedback after sending a command to a device (also applies to Google Home)
- Every device now share the same Neviweb client instance to communicate with the API (instead of instanciating a new client + login for each device)
- Each device only knows about itself and query Neviweb API only to get its own state.
- Light and dimmer are combined in the same ‘light’ platform. Supported features (dimmable or not) are setup dynamically
- An unavailable device won’t cause other devices to crash, but I still need work to manage this properly (you may get a stack trace in the logs)
- Added some debug log messages to get more details in case of problems.
- Added force=1 parameter in the URL when calling Neviweb. I guess this will force gateway to query device directly instead of returning last known value from gateway cache (Neviweb website use this parameter all the time).
- I tried to follow Pylint rules and HA best practices for writing code
- Away mode now use the built-in way in HA and is now separated from the operation mode, so you don’t loose your previous mode when you toggle away mode (@claudegel: I don’t understand why you would need async stuff to set away mode…)
- Added turn_off and turn_on services in climate platform.
- Added some attributes in the switch component to monitor current power watts and today energy kWh.
- No need to add your gateway name in the configuration if you only have one network. It will take the first one by default.
BREAKING CHANGE: treat this as a completely new custom component. If you want to reuse your automations, you will have to change the name of your devices in all your configuration files / automations / scripts / Node-Red / … If you want to completely remove all references to the sinope component, with the new HA 0.87 you can now manage the Entity Registry in the configuration menu and delete unused entites.
All devices will now be called: neviweb_[light|switch|climate]_<name of your device>
Reasons why I decided to change from sinope to neviweb:
When you look at Neviweb website, there’s no mention of Sinopé anywhere, except in your device properties page where you can see the device model. Neviweb seems to have been created to be vendor agnostic so they could integrate differents products from differents manufacturers.
Of course, actually it’s mainly used for Sinopé products, but I’ve found some Ouellet thermostats that are compatible with Neviweb.
So, using a more generic name seems logical to me. Whatever device Neviweb will integrate in the future, this new component will be ready to accept it.
I strongly encourage everyone to use this new custom component since it will reduce the load on Neviweb servers. Sinopé may be more inclined to help us if we are doing it the right way.
Everything has been merged into @claudegel repository:
If you only want to test this new component, you can configure it in parallel with the actual sinope component without changing anything else. You’ll then be able to compare response time between the two components. If you have a few devices, you may see a noticeable difference.
I understand that communicating with Neviweb API is not the best (long-term) way of doing home automation. But with this new component, the API part is now completely separate from the HA device related code. So we could theorically remove this part and replace it by local communication with the gateway. Of course, it will need some refactoring, but I think this is a great step toward this goal. Btw, @claudegel let me know if I can be of any help with your local implementation.
N.B.: don’t expect this new component to be free of bugs!! It still needs work and proper API documentation to manage every situations.
Have fun!
