Hi @knebb,

Thanks for this post, it's very helpful.

Best regards,
Antonin, Unipi

Thank you for your contribution!

Best regards
Unipi team

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,
Manuel

Hi @honza-muller,
yes, that will work as well. Arduino + MAX485 is tried and true. Just be aware, that the Unipi 1.1 doesn't have RS485, only Neuron / Patron / Gate.

Thanks a lot for the feedback!

Hi @Martijn-Hemeryck,
I checked your other posts and have some notes on the Software part:

I think it's really nice you took this effort, tbh :)

The Evok is planned (well, maybe "wished" is a better word:)) to be rewritten to Python 3 and to a multithreaded application. Along with that, major changes to the API will happen. We will abandon some of the less used APIs (RPC and SOAP probably) and definitely add native MQTT support since it is a driving force in the industry.

How far along is this idea? Would you also be taking PRs? I mainly develop in python3 for my job and have some experience with asyncio (see e.g. https://github.com/mhemeryck/covers), so I might be interested to have a look at that.

The missed state changes of the DI can be detected by checking the state of the DI counter. The counter is implemented in the HW and can count as fast as 10kHz signals.

I wasn't aware of this polling speed!

And a bit of explanation of the low level communication:

The HW boards are connected over SPI The protocol on the SPI level is modified ModbusRTU The Unipi kernel module (part of the unipi-kernel-modules package) exposes this communication channe as /dev/unipispi device The Unipi ModbusTCP server (part of the unipi-modbus-tools) exposes this as a ModbusTCP server running on TCP/502 The rest is correct. Evok polls the ModbusTCP server as fast as it can. And creates a "system image" of the HW state.

I obviously did get some of details wrong, so thanks for pointing this out!

Would you mind if I did include your comments in an edit on this blog post?

I really appreciate this kind of feedback; I never really did ask for your permission to publish on your product in the first place, so I am glad to see your reaction like this.

@kratas

Mervis a Evok je SW, který můžete nainstalovat na jednotku zároveň, stejně jako Home Assistant, openHAB apod. Problém nastává v logice ovládání vstupů a výstupů, pokud s nimi pracuje více SW souběžně. Mervis, jelikož je spíše pro průmyslové nasazení, tak zapisuje neustále do IO jeho aktuální stav. Tedy pokud program v Mervisu má nastavovat relé, tak jej nastavuje na tu stejnou hodnotu několikrát za sekundu. Je to z důvodu bezpečnosti, kdy jedno nastavení by nemuselo "dotéct" až do IO a tím pádem by byla technologie v mezistavu.
SW typu Node-RED, openHAB apod. fungují událostně - tedy zapíší hodnotu do IO pouze při její změně.
Míchání těchto dvou postupů vede k problémům, tedy tento postup silně nedoporučujeme.

Pokud hodláte používat naše rozšiřující moduly, doporučím použít Evok, protože přes něj budete moci z HA ovládat jak lokální IO Patrona, tak IO na rozšiřujících modulech.

DirectSwitch je funkcionalita, která celé řízení velmi komplikuje. Současné ovládání relé autonomním DirectSwitchem a externě ze SW je velmi složitá a osobně ji nedoporučuji.

S pozdravem,
Martin Kudláček

Here is a brief video about the system. https://www.youtube.com/watch?v=9mjHFFgHrBA It is controlling heating actuators, lights, it is reading rooms tempertaure via 1w sensors and it operates an anti-theft system (sensors on windows and doors). I also have multiroom audio (with snapcast) but that is not fully integrated yet.

Ďakujem za odpoveď!
áno, relé výstupy som myslel a tiež som zvažoval použiť samostatný zdroj pre relé.

Zdravím @Whitegg,
píšete, že se PLC nepřipojí. Znamená to, že jej nevidíte na routeru, nebo že jej IDE nenadetekuje

S pozdravem,
Martin Kudláček

Hello Martin,

Perfect, many thanks for your answer!

Best regards,

Hello @lessmann,
the limit of how many devices can be connected to one RS485 line comes from the RS485 transceiver (the chip on the RS485 output) and on our PLCs it is 32. But be aware, that this is just a theoretical limit and the real limit depends on the current situation.

Second limit of the RS485 is the speed of the communication. Since RS485 is a half-duplex type of communication (master can speak only to one slave at a time), the more devices you have the lower speed of updates you will have.

If you have PLC with more RS485 ports, you can split the extensions into groups.

Best regards,
Martin

Hello @mike,
I am currently working on a very similar project - monitoring of a groundwater level and a independently controlled water pumps. There will be a web interface with information about exact water level in cm (up to 5m) with charted historical values and when the set threshold level will be exceeded an email and SMS will be sent to a set of addresses. All of that accesible via web interface.

If you are interested, please contact me on martin@modori.cz. We can continue in Czech language there.

Have a nice day,
Martin

Hello,

I expect that by console, you mean SSH. You need to enable the SSH in order to use putty (via SSH) the raspbian way: https://www.raspberrypi.org/documentation/remote-access/ssh/ check option 3

@sennevds

My notes:

reading of inputs: works reasonably well right now. I did create my own implementation (based on golang) that basically just polls the states of the switches continuously and pushes out any change as an MQTT event -- processed directly by home assistant. The polling implementation works on the background and eats about 5-10% CPU (still tolerable, might still be improved), switch behavior feels instantaneous for me. writing outputs: my implementation is also able to again translate incoming MQTT events into toggle outputs. Here, you don't need to poll directly (the MQTT handler itself is able to deal with that). Alternatively, you could look into home assistant modbus, to send a modbus command directly from home assistant. My implementation completely sidesteps the whole modbus translation phase, so if you'd be using it for reading, writing would make sense as well. pushing out DALI commands: I did receive my axons S605 not that long ago, been fiddling with it, see https://forum.unipi.technology/topic/966/dali-interface-integration-in-python-dali . I have the feeling support for this product is still in its infancy, as well as the python-dali library it depends on. If I would have some more low-level documentation on it, I would very much like to take the development on this to a higher level!

If you'd like more input on how to use the unipitt binaries, and you feel a bit tech-savvy yourself, I'd be happy to help you set it up. That way, I can improve the project to make it more robust a portable for other interested users.

Hi Steven,
thanks for sharing us your experience with UniPi and kudos on the EVOK-MQTT bridge! We definitely want to support some ready-to-use opensource home automation SW and Home Assistant is one of the candidates (alongside the openHAB). But we have no definite plans yet...

Martin

@martin-kudláček said in Another home automation project:

our din rail mounted relay - and connect it to DO or RO. Awkward, but it works.

In most of my projects i use external relays to extend the life of embedded hardware relays, so it's not that awkward. I use mostly relays with coil voltage 230 V AC with UniPi 1.1 but now with the shared COM port and neuron power suply, i'll go with coil voltage 24 V DC.

@tomas_hora Hi Tomas,
It is already, this is the test version: Dr.OnOff
Have a nice day!
Boris