OK, that does sound like a PWM-like dimmer. I’m wondering how you read the time the button is pushed with just the websocket approach, since I don’t see this time exposed there.
At this moment I don’t check the input signals of the dimmers.
I only need the signals of the relais at the moment. Only need to figure out the false positives
I fixed the false positives the developer way. I can’t figure out how to filter out the false positives with hardware so I’ve added a extra check in the python script that if a certain circuit is triggerd to check for another circuit and if that value is high stop checking.
It’s quiet a dirty hack but it works
thanks for mentioning this! Great to hear someone is actually using it. Please let me know if there is anything I can improve on. It’s definitely not complete; mostly written to my personal needs.
In terms of dimming, I just use the analog output of my UniPi and use this 0-10 volt output to steer led drivers with this as input (if your google for 0-10 volt led driver you’ll find a lot). Do make sure you use 0-10 volt, not 1-10 volt as that won’t turn off the led lights completely (you need to cut the 110 / 230 voltage to the driver in the 1-10v case).
Dali would be really cool, but since the 0-10 volts works really nice for me and I would need to buy a a new UniPi and LedDrivers that’s not an option right now.
Working on adding some additional 1-wire devices right now. Will adjust the code to make sure this works. Note: correct 1-wire values depend on EVOK version, some older versions gave me back incorrect values for some sensors.
Can you share an example of the false positives?
it’s just when I push one button it’s sometimes registered on another input.
I’ve added a option in your config file to check for other inputs and if that input is high it stops for the current input.
It’s hacky but it works(all my inputs are 24v impulse, so one pulse switches a relay)
Hey Matthijs,
i’m looking to do something similar…
Can i contact you in dutch?
(also from belgium here)
Look also Looking for decent light integration
I’m doubting to go with the unipi route
not sure if i should take a unipi 1.1 or neuron or axon
or loxone miniserver or arduino …
How difficult is this to do so?
Thx for the help.
1 Like
Yes, Did you a PM.
Hi Martijn,
Huge thanks for modbridge, was able to poll my modbus Wago PLC with it to have instant response time on my push buttons connected to its inputs to use them in Home Assistant.
Had to add username and password for MQTT broker connection to it, but otherwise worked liked a charm!
Tom
1 Like
Nice to hear it’s even helping you even if you’re on a different hardware platform!
Hi,
First of all, huge thanks to Martijn (@mhemeryck ) to make this happen. I’m using the Modbus TCP integration now for over a year to connect my UniPi M103 to Home Assistant, works like a charm!
Right now I’m busy to wire every room with a 1-wire temperature sensor (working on a zone heating for my house). I was wondering if the TCP integration also supports the 1-Wire input of the UniPi? If not; whats the best option to get this data into hassio?
Maby the repository of Matthijs (@matthijsberg) will give me the answer but can you use both; TCP integration and the EVOK-MQTT bridge?
Dutch greetings,
Bernd
Hi Bernd,
I’m not aware of Martijn his project, bus as long as the websocket server on the EVOK install is running I think it should work. My script just connects to this websocket and translates it to MQTT messages, for all buses in the unipi, both incoming as outgoing, including the 1-wire sensors. I use them too in my house. In theory you should even be able to run my script in your HASSIO server, though not tested by me.
I would say, give it a go, and see what happens. You can just download the script and "python3 " and see what happens (do change the vars in the script and the config file the goes with it 
).
Cheers back!
Hi Bernd,
Thx for the kind words 
My evok2mqtt wrapper does not have support for 1-wire out of the box atm. If evok / websockets supports it, I should it be possible in theory to also push out this information over MQTT. The current implementation maps between the evok websockets interface and MQTT. The websocket API allows to do push-based notifications. I don’t think 1-wire is supported by the websocket API. This needn’t be a problem though (for polling e.g. temperature sensor values, it’s not issue if that takes some time to poll it) – but it does mean I would need to implement the bridging a bit differently.
Actually, now I think of it, you might even just connect home assistant directly to evok REST API, no need to first translate them to MQTT events.
I will have a look at this myself at some point, but unfortunately it’s quite on my list tbh 
1 Like
Hi,
I wonder if you could share with me your experience using Unipi and Home Assistant. I understand that you wrote a script which connects to EVOK using websockets and then it publishes MQTT messages for Home Assistant.
How long does it take to propagate a signal from an input (a switch) through Unipi and Home Assistant to an output (light bulb)?
Do you run Home Assistant on Unipi, which image do you use? Can I run HA on Mervis OS?
Are there any tasks which you have not been able to complete using Unipi? Would you recommend Unipi or you would rather choose a different device?
I know that it is a lot of questions. I am thinking about using Unipi for my home automation project.
Thank you, Martin.
Hi everyone, I’m trying to make a server communicate in TCP / IP mode with Home Assistant, is it possible to make any Server communicate and exchange data through Home Assistant and other servers ??
I wonder if you could share with me your experience using Unipi and Home Assistant
Sure! Essentially, my full house runs on home assistant and unipi.
So, from a push button to toggling lights, the following happens:
- push button pushed
- 24V contact is toggled
- unipi digital input sees the toggle (actually, one of the connected IO boards sees this first)
- unipi evok pushes out websocket event
- my evok2mqtt library translates the websocket event into a MQTT event
- MQTT events goes to MQTT broker: separate device, dockerized mosquitto: Docker
- home assistant has a button entity that follows the MQTT event
- home assistant has an automation, that links the button entity to a corresponding light;
- home assistant has a light entity that gets toggled by the automation; MQTT event is sent out to the broker
- another unipi which is connected to the lights is subscribed to the MQTT event for the light
- on this other unipi, the MQTT event gets converted again into a websocket event
- the websocket event triggers the relay for the light
It’s a lot of steps, but it allows the overall setup to remain pretty decoupled. For example, I recently made a separate containerized service completely at the layer of MQTT events to control my blinds: GitHub - mhemeryck/covers: Quick-and-dirty MQTT input button to cover matching
How long does it take to propagate a signal from an input (a switch) through Unipi and Home Assistant to an output (light bulb)?
All of this occurs pretty much instantaneously.
Do you run Home Assistant on Unipi, which image do you use? Can I run HA on Mervis OS?
No, I run a dockerized version of home assistant on a separate (2GB RAM only) x86 PC. I use https://k3s.io/ / GitHub - alexellis/k3sup: bootstrap K3s over SSH in < 60s 🚀 for orchestrating the container
I think over time I will want to migrate the home assistant setup into a (cluster of) raspi4s
Are there any tasks which you have not been able to complete using Unipi? Would you recommend Unipi or you would rather choose a different device?
The overall system works quite OK now. I still have a lot of ideas to extend it, but I would mainly like to focus on making it more reliable.
Specifically for unipi:
- the polling from the evok library (the library provided by unipi themselves) is not always fast enough, resulting in missed events (lights not toggling when pushing buttons). I intend to use their sysfs interface SysFS [Unipi.technology Knowledge Base] to get a faster polling rate. Ideally, the unipi software would have been able to push out MQTT events in the first place.
- I’ve also had some issues with corrupt SD cards in the past; suddenly, the unipi would just stop working because of a corrupted file system on the SD card. I recently switches to pSLC SD cards, hoping these will be a bit more reliable (might not be an issue directly related to unipi
; this is just a general raspi / SD card issue). Btw, I also have a 24V DC UPS to make sure that even in the event of a short power failure, the unipi’s don’t directly get switched off. - wiring: I did all my wiring in star configuration (everything ends up in central cabinet), which makes it possible for me to switch to any other hardware setup. It’s a lot of wiring though, with a lot of manual work. A bus-based system might have been easier in that respect.
One of my main concerns right now is that I’m the only one that really knows how this works in my house. I guess it’s the case for any DIY system though …
I know that it is a lot of questions. I am thinking about using Unipi for my home automation project.
That’s nice to hear, since I am currently working on writing a series of blog posts on this topic. I wasn’t really sure there’d be an interest in that, so this motivates me to keep on going 
1 Like
Old post, but since I have been working on a series of blog posts for this, here’s the link in case someone would still be interested: Why
3 Likes
I’m really looking forward to the next articles!
The reason is that couple weeks ago I chose Unipi Patron for my home automation (wired, exactly like you described).
My new Unipi Patron already arrived! I’m not sure if default OS (Mervis) is ok or should I put there “Patron Node-RED OS” because it contains EVOK.
Thanks for an answer!
Nice to hear!
I did add another post today, Architecture
I will post any future updates for the blog on this dedicated forum post: Wired DIY home automation system
2 Likes
will this work with this power meter bridge ?