hi @marko2276,
Thank you for sharing your integration.

I am a beginner and now I used it for HA communication with NEURON M203 via EVOK layer. Installation of the integration and configuration of the LIGHT sensors (I used for DO and RO outputs) are fast and functional. Turning on/off the relay on M203 has a small response:
Clipboard01.jpg
When I added the BINARY sensors (DI) configuration, the problem already arose => LIGHTs do not work at 100%:
Clipboard02.jpg
I always check the configuration in Developer Tools before restarting HA:

#UNIPI NEURON via EVOK unipi_neuron: - name: "neuron5" type: M203 ip_address: 192.168.88.20 reconnect_time: 30 light: - platform: unipi_neuron device_id: "neuron5" devices: - name: svetlo_garaz device: relay mode: "on_off" port: "1_02" - name: svetlo_dilna device: relay mode: "on_off" port: "1_03" - name: svetlo_vcelin device: relay mode: "on_off" port: "1_04" - name: svetlo_zidky_1 device: relay mode: "on_off" port: "2_05" - name: svetlo_zidky_2 device: relay mode: "on_off" port: "2_06" - name: svetlo_zidky_3 device: relay mode: "on_off" port: "2_07" - name: majacek_svetlo_zelena device: relay mode: "on_off" port: "2_08" - name: blikac_fasadni device: relay mode: "on_off" port: "2_11" - name: svetlo_fasada_garaze device: relay mode: "on_off" port: "2_12" - name: majacek_svetlo_zluta device: relay mode: "on_off" port: "2_13" - name: majacek_svetlo_cervena device: relay mode: "on_off" port: "2_14" binary_sensor: - platform: unipi_neuron device_id: "neuron5" devices: - name: tlacitko_svetlo_fasada device: input port: "1_01" - name: tlacitko_svetlo_garaz device: input port: "1_02" - name: tlacitko_svetlo_dilna device: input port: "1_03" - name: tlacitko_svetlo_vcelin device: input port: "1_04" - name: kontakt_dalkove_ovladani_A device: input port: "2_01" - name: kontakt_dalkove_ovladani_B device: input port: "2_02" - name: tlacitko_otevreni_vrat device: input port: "2_03" - name: tlacitko_zahradni_zalivka device: input port: "2_04" - name: kontakt_vrata_v_pohybu device: input port: "2_05" - name: kontakt_vrata_zavrena device: input port: "2_06" - name: kontakt_vrata_otevrena device: input port: "2_07" - name: kontakt_vrata_prekazka_v_zavreni device: input port: "2_08" - name: tlacitko_opusteni device: input port: "2_09" - name: kontakt_PIR_osoba_vgarazi device: input port: "2_10" - name: kontakt_kour_v_garazi device: input port: "2_11"

Could you advise me where the problem could be?

I would also like to use this integration on the NEURON L303 and L403, where I have connected analog inputs, analog outputs, and 1-Wire temperature, humidity, and lighting sensors. Will you please complete the configuration for these mentioned inputs and outputs as well?

I look forward to your reply
Petr

Hi @knebb,

Thanks for this post, it's very helpful.

Best regards,
Antonin, Unipi

Thank you for your contribution!

Best regards
Unipi team

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