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.
Thanks for the quick and very extensive reply!
Follow-up question: with the modbus TCP server / evok, I know it's possible to change the behavior of how I/O should be interpreted, e.g. the toggle or direct switch functionality. How is this initiated? Is this an interpretation that happens on the "server side" (pi-side) or is this some behavior that actually gets set on the SPI slave device? Does the server side also keep the SPI slave register state locally in its memory?
As a more generic question, what kind of software is running on the SPI slaves? Probably something like a single program that handles the modbus RTU interfacing?
Besides the SPI interfacing, are the standard GPIO also still used in the 24V pins? Are they also made available via the neuron TCP server?
About the asynchronous behavior: SPI does seem indeed inherently synchronous. It might be possible to have the slave devices initiatie interrupts, but most docs I've read about it seem to indicate it's indeed not that common + I probably wouldn't know how to do it in practice :). In that respect, I am beginning to doubt whether there's much to gain by bypassing the modbus TCP server ...
Bit of a follow-up of a thread I started earlier on home assistant.
TL;DR: what is the spec of the SPI transmitted values for the neuron models?
Since my posts there, I've been reading a bit about the way home assistant does its magic and it has a lot of built-in support for asynchronously polling IO -- which is pretty much what I'd like to do. The next step I thought of was to have a direct way to read those values -- which appear to already be available through the spidev overlay; part of the solution provided by you in the neuron modbus TCP server
I already tried reading the spidev directly through a python library called spidev, which is quite simple really (example from neuron L303)
>>> import spidev
>>> spi = spidev.SpiDev()
>>> spi.open(0, 1)
>>> spi.readbytes(10)
[250, 0, 85, 14, 182, 10, 250, 255, 255, 0]
My question now: is there any spec of how the spi device puts those values on the spi line? How should I interpret these values? I can probably start looking into how the modbus TCP server interprets these values, but it's probably easier to ask here first :)
Thanks for the reply. In short:
Thx for your quick reply! I have some more remarks / questions in follow-up; (perhaps I can start some separate topics on some of these).
I can see the value of this direct switch functionality, but I would rather have the connection of input-to-output managed at a higher level (e.g. home assistant). Besides, the number of outputs on the L303 is not enough for that. Will have a look at the toggle function though!
I was also wondering whether there could be a simpler way to capture events from the SPI-interface. A lot of IoT solutions nowadays use protocols specifically for this, like MQTT; home assistant has a lot of support for it and e.g. arduino also has libraries for it. For my home automation setup, I would like to expand the number of IO and platforms, so something like MQTT has the added advantage to add more neurons that can run independently, but communicate directly with MQTT.
What would the best way to do this translation; I am thinking of:
The fastest would probably be the SPI polling solution, directly connecting the polled SPI interface with an MQTT broker. I don't have that much experience with this low-level coding though, so it seems pretty hard. What are your thoughts on this? (perhaps I should move this to a separate topic)
On a related note, currently, the RPI seems to polling the SPI devices, but is there also a way to have the SPI devices directly trigger (interrupt?) the RPI? This seems even harder though and I am not sure whether there is that much advantage to it in practice.
The toggle function is something I could indeed do perfectly at this level; no need to emulate this at a higher level such as home assistant.
I already tried to directly connect a 24VDC LED strip and toggle the DO, but this didn't seem to work. I'll probably need some more time to investigate it.
For my lighting solution, I would actually like to build a DALI controller (yet another topic). The shop mentions the axon S605 to be suited for this, but I don't seem to be able to find any further documentation for this. Ideally, I would just have the axon run its own linux distro and have a common DALI library on it to interface with the DALI bus. I would then write my own MQTT client as a bridge between the DALI interface and the other unipi. Not sure how realistic this is though.
FYI, some background: