Topics created by Martijn Hemeryck

Small update: check out my blog for the solution I did create https://blog.mhemeryck.com/2021-11-16/modbusbackup

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.

@Petr-Helebrant Thanks for your reply.

in the end, I did indeed end up putting in a separate series of relays to control the blinds. I did use relays from Eltako though, which were a lot more expensive than the solution you did provide. Thanks anyways for the tip, I can imagine it to come in handy for a future project.

Hi @martijn-hemeryck,
some of the dependencies are quite tricky and we weren't able to handle the transitions between new package names gracefully. The repo is reachable, however the URL has to end with slash: https://repo.unipi.technology/debian/

Best regards,
Martin

@martin-kudláček said in Neuron L303 and M303 DI not working -- LED not showing:

mbpoll 127.0.0.1 -a 0 -0 -1 -r 1136

mhemeryck@L303-sn17:~ $ mbpoll 127.0.0.1 -a 0 -0 -1 -r 1130 mbpoll 1.4-12 - FieldTalk(tm) Modbus(R) Master Simulator Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; type 'mbpoll -w' for details. Protocol configuration: Modbus TCP Slave configuration...: address = [0] start reference = 1130, count = 1 Communication.........: 127.0.0.1, port 502, t/o 1.00 s, poll rate 1000 ms Data type.............: 16-bit register, output (holding) register table -- Polling slave 0... [1130]: 50 mhemeryck@L303-sn17:~ $ mbpoll 127.0.0.1 -a 0 -0 -1 -r 1137 mbpoll 1.4-12 - FieldTalk(tm) Modbus(R) Master Simulator Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; type 'mbpoll -w' for details. Protocol configuration: Modbus TCP Slave configuration...: address = [0] start reference = 1137, count = 1 Communication.........: 127.0.0.1, port 502, t/o 1.00 s, poll rate 1000 ms Data type.............: 16-bit register, output (holding) register table -- Polling slave 0... [1137]: 65535 (-1)

Right, so it indeed looks like a very high debounce time!

Strange, since I thought I had already checked that with the web view / can't recall changing it myself.

Anyways, I ran the firmware updates again, and now it's fixed! Thanks a lot!!

Hi @martijn-hemeryck, those are great news! I'm glad we were able to put it together, together:) I'm looking forward for your results.

Martin

'nother update: giving it some thought, I quickly wanted to see if I could do the same stuff again in go, so here goes another POC: https://github.com/mhemeryck/unipitt/blob/37b9a07bc570301c2a11836526df1a2be8b21647/main.go

(Don't mind the project name though, I've sort of ran out of original names, I guess)

Anyways, performance seems much better in this case. I figure I'll put my efforts into polishing this project as it seems to be the simplest, fastest, most robust.

I did notice however when toggling one of the DI's, that another DI also got toggled somehow, still need to investigate that further.

Thanks for continuous feedback, this actually adds a lot to me for the overall unipi experience!

Ok; took me quite some time, but I just did manage to read out the sensor values.

Leaving this here as future reference; the involved PIR sensor was the Jablotron JS-20 Largo. A small schematic was provided with the sensor out of the box, but the key find for me was that the sensor outputs also need to be wired up to the 12V power source; see adapted schematic and pictures.

Thanks a lot for the schematics, since they really made it possible for me to reverse-engineer the setup.

Thanks for the reply.

Since my last posts, I have been fiddling around with the setup and noticed that when I directly poll the modbus tcp server, the updated state is made available almost instantaneously.

My issue is really on the polling side of the home assistant visualization I am using. I have now started a project to do the polling in a separate server, that then pushes out any changes in the form of an event via MQTT, see https://github.com/mhemeryck/unipusher . It currently works as a proof of concept for a single toggle switch, I am now looking into how I can make it more scalable to all kinds of inputs / outputs. I'll get back here if this ever works out :)

EDIT: given it's not really unipi specific, I decided to rename it to modbridge, see https://github.com/mhemeryck/modbridge

@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 Martijn,

I am also trying to read analog and digital ports on unipi to collect sensor data from few sensors. I was also just wondering if we can do it in the same way like we do it on raspberry pi using a python script. I can see that even you wanted to do something like that. I have also gone through evok api but they seem to be specific models. I dont think using that we can directly read analog and digital I/Os on unipi. Can you please suggest any ideas if you were successful doing that?

Thanks,
Jitu