I have a Modbus controller sending out 100 messages.
I have migrated some 60 to the Modbus thing with some 60 channels.
If it is too much, I can potentially change the firmware of the Modbus controller to push out a group of values in JSON.
It might be easier to dissect a JSON string in OH into 60 values (say 6 lots of ten values)) than receiving and processing 60 MQTT messages every 10 seconds.
That question doesn’t make sense that way, plus I think you’re on the wrong track.
You should not push anything but have OH query Modbus, selectively.
And you should only link items to channels that you really need. Most of what can be read shouldn’t.
exactly what I am doing, as this controller publishes over 100 values.
The question remains, and I slightly rephrase:
From an OH perspective, is there a sensible or practical limit to the number channels one should associate with a thing?
I still don’t understand your question.
Modbus controllers don’t “send” or push anything, at least not to OH. OH queries them.
And you won’t need 60 values or even more. Just don’t query the others and the question on max channels becomes irrelevant (there’s no reasonable answer to it anyway as as I said the question in itself does not make much sense and smells a lot like XY problem).
This Modbus controller does “send”!
This controller reads a Modbus interface of another device, and then publishes the values via MQTT.
And where is your evidence that I do not need 60 out 100 values? How can you tell? Without knowing what kind of data is being presented by said controller?
It is a question I ponder about.
If if makes no sense to you, why not ignore my post altogether?
I am almost certain there is someone out there who has an opinion about my query may chose to quote a number with a reason why either they or the system should have x number of channels.
They may say one thing can have 65000 channels, e.g. as the physical limitation, and having that many would be unwieldy.
I think from my experience with OH and similar application servers: Not the sheer volume of endpoints/attributes is relevant, but the overall load.
Then again: you have to be precise with your wordings!
the controller sends 100 attributes, each of which contains values. You have some kind of modbus client, which polls the attributes and sends the attributes in seperate MQTT-Topics and place the values in the MQTT-payload/value.
So, if I understand correctly OH doesn’t deal with 100+ modbus addresses, but with 100+ MQTT-topics and has to process their values. As you don’t want OH to directly poll the modbus of your device, but you want to use the output of a modbus controller. That’s fine!
So, in my OH3 installation, I deal with about >400 topics, which send regularly about >500 messages per minute (have to have a look in my statistics). There are devices, which send every seconds (like my wallbox), every 30secs (like my S0 Counters), up to every 10mins for my weatherstation and devices like this.
If you query/send/whatever your 100+ values every 10/20/60secs, you’ll get a little peak everytime, but OH will work just fine with it. That’s what it does with the 51 messages from my Wallbox right now as you read.
But: if you have some channel-based transformations in your MQTT-payloads for every single 100 attributes, it could be a bit more of a load for OH to re-calculate the channel information and subsequently the item-updates.
tl;>dr;
With 100 channels to a thing you’re almost certainly good to go. As I said, I have about 300 MQTT-channels running, about 5% do have some kind of transformation and together with my other about 700 items, my OH3.3-release on a Raspberry Pi 4 (4GB) idles at about 2% CPU time.
CPU Usage = 1.76% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
I don’t know for sure, because I am no developer and no sysadmin and know nothing about the internal structure of openHAB or the appserver, or whatever…
But: I chose to dissect JSON-strings into MQTT (e.g. from my regular KIA EV6 car information) beforehand and sort them out in individural MQTT-topics, because then I can for example do some error-handling with NodeRed (which I mainly use a means to pre-collect data and package it for OH3). So I get the JSON from KIA Web-API and then I’ll split that into 28 topics for my EV-state. So OH3 doesn’t have to to the JSON-transformation, but NodeRed does (as the NodeRed runs on my Synology I can’t tell you the exact CPU-load, but it’s way under 1% showing in my Synology-Docker dashboard)
…and my NodeRed hast 20 Flows with about 1000+ nodes.
Yes, your words: the controller sends 100 attributes, each of which contains values. You have some kind of modbus client, which polls the attributes and sends the attributes in separate MQTT-Topics and place the values in the MQTT-payload/value.
The questions was about max. number of channels per thing (until it gets ridiculous)
To elaborate, the Modbus client gets a register value and publish(es) this a MQTT topic.
There are 106 registers, only some 60 are of interest for my automation.
Thank you for your detailed answer. It instils some peace of mind that OH can handle quite a bit.
Well I haven’t finished my migration from v2 to v3 yet, but count already 372 topics.
I thought, in case I am overdoing it with channels, I could change the firmware on the controller to publish JSON strings with, say, 10 values each, to reduce traffic and/or load and the number of individual messages.
In a nutshell: what I am doing is well within OH’s capability, and others (taking you as an example) are seemingly doing similar things.
PS:
…and my 2cents to add: I once also wanted to have all logic within openHAB regarding my data, because I wanted to have all data persisted in the same way to have access and do some statistics with it.
But over time I changed it and “outsourced” some logic from OH into NodeRed or others.
To make it more clear: my heating controller offers an serial interface and I can read/send bytecode. But it has an known bug in the firmware (won’t be solved from the manufacturer, though), that some readouts contain false values (like temperature spikes of 50 or more K), so my nodeRed now takes control over the readouts. I have an Pi zero directly next to the heating controller, which runs a python-script readingvalues and putting them in one JSON every 2mins. NodeRed splits the attributes in topics and only sends “realistic” values over to OH in seperate topics, so my “real” logic within OH3 doesn’t get affected via those spike readings.
So - your case it is comparable as your modbus controller collecting the readouts into a JSON. You can start with openHAB reading the JSON and transforming (106 registers) into 60 channels/items. If you’re unhappy, just later on either change the modbus controller or put some nodeRed in between and you’re good to go.
There is no practical limit, long before you get to any magical number you will run into performance issues.
What kind of performance issues? Don’t know, that depends on what resources you have available (e.g. hosting) and what you are doing with it.
60 channels might be expected to link to 60 Items. If they all lie there and do something once a day, you don’t need many resources. If you’re updating them all every second and recording thse updates in a database and running rules to analyse the new data, that’s quite a lot of work.
This probably the source of confusion. From your description, you don’t have any Modbus Thing at all, rather an MQTT Thing. What the remote device is doing is no business of openHAB, it sees MQTT messages.
Almost certainly more efficient. Not least by unloading your network.
good point! I forgot the persistence: all my items (1111 atm) are persisted:
rrd4j (locally on my OH3)
influxDB (remote database)
MariaDB (remote database)
=> and I’ve got as explained - a LOT of items, which change at least every second.
I’ve got Zabbix up and running and the Zabbix agent on my OH3 RPi4 doesn’t find any issues at all. On my Pi-Hole it sometimes finds some I/O warnings: like
[mmcblk0: Disk read/write request responses are too high (read > 20 ms for 15m or write > 20 ms for 15m)](javascript:void(0))
jwiseman
(Mr. Wiseman (OH 4.2 Snapshot on Pi4))
12
Running OH 3.2 on rPi4 with 36 bindings, 416 things and 2,911 items along with running HabPanel on 3 tablets rotating 26 web pages every 3 minutes on them with no performance issues.
All I can do is second much of what has already been said. There is no fixed maximum number of Channels. The Astro binding has scores of Channels. But not all Channels are created equal. What matters is how much work they are doing which is going to be a combo of how often it receives messages and how much work gets done by OH for each message. You could have one OH instance with 3 Channels but those Channels are so busy you use up all your resources. Similarly you could have an instance with 1000 Channels but they are invoked so rarely as to have no significant load on the machine.
However, there are two practical concerns, one of which was touched upon and the other not.
First, do you really need all those Channels? This is where @mstormi was going. Especially with Modbus, but often with other technologies too, there are far more data points than is relevant to home automation. Just because you can publish and access the information doesn’t mean it’s meaningful. You should only create Channels (where you are responsible for creating the Channels) and link them to Items when you can definitively say “I need that for X purpose.” X needs to be clear and concrete. “It’s interesting” or “because I can” isn’t sufficient. It needs to be an answer like “so I can decide when to turn on the AC” or “so I can track my energy usage and make changes to my behavior as appropriate.”
The second is rarely do you have a single device with hundreds of sensors/actuators. A Thing is supposed to represent a single device. When I say device, I mean something that someone in your home could point to and name it. “That’s the kitchen light.” “That’s the AC.” " That’s the den TV." You would usually want to group all the Channels for one device into one Thing. From what little information presented here, it seems like you might benefit from breaking it up into multiple Things.
One last thing I’ll note is that one of the philosophies of MQTT is to not impose work on your clients/subscribers. Packaging up a bunch of stuff into JSON and publishing that could impose quite a great deal of work on your subscribers. So it is closer to a best practice in MQTT to have multiple topics as opposed to fewer topics with larger messages that must be parsed. That way subscribers need not process irrelevant data just because it happens to be packaged in the big JSON string nor does it need to load parsing libraries and waste cycles parsing and extracting the data it needs. Don’t forget, MQTT tries to support battery powered microcontrollers and then like where a 1k library and a few thousand processor cycles could be the difference between a viable device and one that needs to have its batteries replaced too often.
Yes, I wasn’t after definitive numbers; just an idea of a limit (if there ever was one)…
… and understand the reasoning around “what work needs to be done”.
I thought I add for those interested:
The thing is plugged into an inverter/charger, connected to 2 x 6kW of panels, and a 20kWh battery; there is quite some data I definitely need, to check. monitor, control and graph on energy/power quality values, loads that are allowed to turn on at specific times, including EV charge adjustments. It also controls grid charge schedules driven by rules.
Anyway, 16 cells in a battery, temperature, some V, A, I values of the different technologies and 60 values seem reasonable
just to add some oil to the fire!
I’m not so sure, if you’ll need ALL of that data in OH. Of course, you’ll need the main data in OH to allow it to work as an EMS. But for monitoring or controlling purposes my solution was to do it in a more simpler environment. There’s either hands-on in e.g. some low-code tool like Nodered or a bit more powerful with some real-life monitoring like Zabbix, icinga, et al.
The sheer value of those items makes OH a bit convoluted in my eyes. If you need the amperage of Cell 14 in battery 12 for your smarthome or regulation within OH, as you already have all rules setup for it: ok!
but on the other hand, if you’re about to establish some sorts of monitoring on those inputs I’d go with a monitoring software instead.
Some interpret some loose commentary too strict. The V, A, is not for the cells, the V is. But there is panels V, A; source and load V, A; and others; details I didn’t get into as this is about channel numbers. The graphing of cells allows for early warnings on cells starting to die (eventually). Any outliers are generating email notifications, and sh!tloads more
Yes, I don’t need all 100+, but 60
Relevant sections are nicely grouped in relevant sitemaps.
Here an example of some grid charge calculation results:
