'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!

FYI: figured to create a small proof-of-concept with python3 + asyncio; see https://github.com/mhemeryck/unipoll/blob/b40c73f682956b08ede27abb85a904d95d9cf1ab/unipoll.py

Note: CPU usage is quite high though, probably because of the wait I handled the scheduling with asyncio.

Thanks for your reply.

To be honest, I did not fully understand your answer, but that's probably because you have more background on the underlying architecture. From how I understood it, there's a kernel driver that does the SPIdev-level polling and then maps that to some reserved kernel memory -- which is then exposed via the sysfs (virtual) file system.

Rather than polling a modbus TCP server that sits on top of that, I figured to capture any file system level changes using inotify or epoll (or actually, their related counterparts in golang). I did test inotify on a "regular" file system where it does indeed fire for any changes, but it does not so for sysfs. For epoll, I am still missing some background on this.

I guess you are saying that the best option is to just do regular polling the files themselves then? i'll give that a try (probably needn't be that hard, actually).

Edit: nice to learn about IIO -- although I probably would not want to wrap my head about that.

Hi,

Been a while since my previous post on reading spidev. The main gist there was that I was looking for a reliable way to capture any changes to the digital inputs. My "solution" there was to do a simple polling on groups of modbus coils, exposed via the modbus TCP server, see modbridge. I am happy to say this sort of already works for me ...

What I noticed while working on the modbridge was that when I did not constrain the polling speed, CPU load for the polling program got quite high, as well as for the modbus TCP server that needed to keep up with all this polling. Although the current setup would probably work OK, I figured that using the sysfs interfacing would probably have a better performance as this should in principle allow me to deal with events directly provided from the kernel level.

I earlier did install the unipi neuron images with the sysfs drivers and I could indeed see any input changes reflected in the sysfs files. I then looked into how I could capture changes as events using golang's fsnotify (a golang wrapper around inotify). Apparently fsnotify (/inotify) is not really used for sysfs files, so I was instead looking at epoll, but seemed to capture too much changes (probably for every spi-level update).

Before digging deeper into epoll, my main question is what do you recommend as the best way of capturing changes as events from the sysfs interface? Is there some sort of (C)-API to directly capture these -- either via some library you provide or directly via standard linux syscalls (epoll)? I do not have any experience with linux syscalls atm, so I'd rather check what is the "preferred" way of dealing with this.

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

OK, thx for the detailed feedback (including schematics). Worst-case, I'll just need to add a pull-up resistor, should be fine I suppose. Main issue will probably be just to figure out what kind of setup these sensors use.

I would like to connect some digital sensors that are powered on 12VDC to an e.g. M303 Neuron (PIR sensors, actually). What would be the proper way to connect these?

I know that for regular push buttons, I need to connect them to the internal power source connection that's available at the DI, but as this is 24VDC, this is probably not possible for my setup. The specs mention that logic level interpretation are ok though (e.g. min 5V for logical 1).

Similar question for digital out btw (although I believe these are open collector outputs, so I should be able to choose my own voltage levels here, right?)

After giving it some more thought and playing around with the setup, my main motivation really is that my (home asssistant-based) integration still feels rather slow, so I was looking on how to improve on that.

From what I gather here however, there's probably more to gain by improving the way the front-end queries (polls) the modbus TCP server -- so I should probably focus more on that instead.