Home assistant integration
Just to let you know that I have implemented a home assistant integration for unipi devices. Compared to other solutions that you may find on the net (in most cases using MQTT as as a client/broker architecture), I have done a more direct integration in HA with EVOK and websockets. Thing are working really fast and provide good user experience (at least for me :).
Functionality wise, the integration supports bare minimum (multiple device instances, lights, binary sensors and covers) so that my home-assistant project works - and it does. I have all my lights and blinds hooked up to HA (running server on a NUC).
Anyhow, you can check it here https://github.com/marko2276/ha-unipi-neuron.
Well done! I am thinking about using Unipi and HA as well.
I was wondering whether you could share with us some details. What unit do you use? Which image did you install? Do you think that it would be possible to run HA on a Unipi device or NUC is a better option?
I would like to have just one device for my home automation project.
I have been searching for more information about Unipi and HA integration. I have found these repositories so far
I find this https://community.home-assistant.io/t/modbus-tcp-integration/64395 topic useful as well.
Would you recommend a combination of Unipi and HA? Did you try to integrate some zigbee devices?
Thank you, Martin.
Due to relatively large number of inputs (All my switches are hooked to a DI on a Neuron device, the same goes for motion sensor. Then I have each light connected over a relay output or digital output for PWM control. Then there are blinds, each requiring two relay outputs. ...) I have three Neuron devices installed. 2 x L203 and 1 x M203.
I am running Neuron OpenSource OS image from May last year I think.
In the beginning I did intend to run my HA server on one of the Unipi devices, but have ultimately decided to rather use a separate NUC server that I had laying around. But I don't see any reason why it wouldn't work on the integrated RPi (especially if you plan to use only one device).
I also did start with some of the links that you are mentioning. But all of them eventually came to the questions how to lower the latency of getting a signal change state from Unipi device to HA. All solution are designed around polling (MODBUS registers) - and this is already being done by EVOK SW layer running on unipi device, so why introduce another layer on top of that that would do the same. So then it is just a question how to hook to EVOK. With number of standard interfaces EVOK luckily also exposes asynchronous one (websockets) and this is where the performance increase (compared other polling mechanisms) comes handy.
I am running HA with Neuron device for a while now and I haven't had any stability issues so far. So yes, I would definitely recommend trying it out.
I don't have any Zigbee devices installed but there are standard integrations available in HA so this should work out of the box, if you ask me.
thank you for your efford, creating this custom integration.
I have two UniPi 1.1 boards (with RPI 4 - 2 GB version) to control my garden watering.
With your integration, I_m now able to control both devices from HA, running in a docker container together with EVOK, not running in a container but installed on Pi-OS (buster) on one of these RPIs.
The only flaw was the built in configuration validation, done by the regex check for the port value (in lights.py, line 36
The port number scheme differs for UniPi 1.1 ("/relay/1") from Neuron ("/relay/1_01").
I managed to add an regex alteration, thus both variants could be passed to Evok ,but only one will work, of course ("1" for UniPi or "1_01" for Neuron).
One might add some
if elsecode depending on the so far unused type parameter ("L203", "M203", "S203" ) and addd "UniPi" to this list.
But I'm not used to program with python, thus I'm happy with this little hack.
Maybe one will find this useful, too.
@joe_at_home Thanks for the additional info for the Unipi1.1 devices (unfortunately I only have Neuron devices so I was not able to try this on anything else). I agree with you that the best (and simplest) solution to a proper fix (or support for Unipi 1.1.) should be designed around currently unused Type parameter.
If I find time, I will make the necessary changes on github and let you know (and also ask you to test it out :) )
Hi @marko2276 , thank you for your great project. I have been testing it in my house installation since it was published, and it works bug-free and really fast (pressing buttons - DI Inputs -Automation HA - RO without noticeable latency). Can you possibly say whether there is the possibility of integrating Modbus in the near future , because I am now dependent on the extensions due to the installation(;.
Thanks in advance,