I think one of the things you’re suggesting is all channel types automatically available/created for every register polled?
One does not need to have them automatically generated. The user can be presented with the manual configuration of channels. This is done by adding the extensible parameter on the poll things xml descriptor. The user can then add individual channels on the thing manually and afterwards configure how the register for that channel should be interpreted (16bit, 32bit, signed, unsigned, read/write etc). I have used this approach myself when developing binding for Phidgets.
@rossko57, are you involved in the development of the modbus binding or any other OH development?
The manual Z-wave adapter suggests that the “Boost mode” can be used in connection with a smore or fire alarm. I guess that is the same as setting the fans to ‘max’.
The load from socat on the Raspberry is in the order of 1% cpu (15-min load is 0.03). But here, socat is the single thing this Pi is doing.
The temp+rh sensors are self-made, it is four Sensirion SHT-31D (one in each chamber) connected via I2C to an ESP8266 that publishes values over MQTT every 15 second. From these I compute dew-point, enthalpy and absolute moisture content (and deltas for each chamber-combination). Difference in absolute moisture between inlet and exhaust (before heat exchanger) is what I use to detect showers etc. This could just as well been connected to the same Raspberry PI that is now running socat.
I’m the developer behind the version 2 of the binding. Thanks for the comments, really appreciate it.
A bit of background
The work started with an open design process (taking months in calendar time, it’s a hobby project after all), and early prototypes (original thread). @rossko57 and active power users were truly helpful in this process and providing feedback based on their long experience with various devices and typical issues users are struggling with.
The design was discussed quite much in github with the maintainers but the topic of dynamic channels actually never came up.
When I was developing the binding, the KNX & MQTT adaptations were quite much in flux. Later on I have observed the same thing as you that some new bindings (that are “general” protocol bindings, similar to modbus) have opted for the dynamic channel approach. This is shame since user has to “learn” two ways of thinking things & channels (similar to different configuration syntaxes in openHAB1).
I remember considering it but do not remember exactly why I opted for static channels… perhaps I thought that there is no PaperUI support for the dynamic channels (I think this is not the case, at least any more, and you can configure dynamic channels in UI) and it’s advanced feature best left for advanced use cases.
Anyways, yeah there are many sides to this. It’s true that current design has more things compared to dynamic-channel approach but in the end is the goal to minimize number of things? Both design approaches have same number of active channels after all.
However, it’s not all bad – there certain symmetry/semantic benefits that I see with the current design:
each data thing (and the associated configuration which brings quite much flexibility) can now be one-to-one something physical, e.g. “rollershutter position” is represented by one thing. In my mind it’s a bit similar to Hue for example – we shouldn’t have one thing only: hue bridge with channels for each lamp. Instead, the philosophy of openHAB2 is more towards having one thing for each light bulb, having hue bridge as parent thing.
thing status can communicate configuration errors more locally (each data thing is independent of other data things). As you know, in modbus you can have 100+ things easily under same poller, and with dynamic channels, we would be forced to communicate all (configuration and other) errors of these channels in the same thing
With dynamic channels, one would have to have the same dynamic channels for serial/tcp things to support write-only use case. However, it turned out that serial & tcp things can be reused in external, device specific modbus-bindings. Having the “messy/raw” modbus details (as exposed by data and poller thing) separate makes sense. Device specific binding can almost hide the “complexity” of the protocol.
As @rossko57 also pointed out, what I am really looking for active user-developers building device specific bindings on top of the general architecture. First one is binding for sunspec: https://github.com/openhab/openhab2-addons/pull/4220 which is reusing the tcp and serial things. It’s just so time consuming for the user to figure out the register indexes, endianness details etc. especially when you are not familiar with modbus terminology (and you shouldn’t be when you just want to get your device data in!).
From my personal perspective I consider architecture fixed now since there’s little gains (but definitely more pains, being backwards incompatible) to change it at this stage…
Netatmo sensor in each room… I am working on making some MQTT air valve so I can control how much air is going into each room. Will keep you posted.
Switching it off while you are not home is something I would be careful with due to condensation in the intake and exhaust. Sorry I mean turn it fanspeed 1 I meant…
My idea is to use fanspeed 1 as off, fanspeed 4 as ON and then I use fanspeed 2 to alter fanspeed based on CO2 level.
val Functions.Function3 fan= [ GenericItem setPointCO2,GenericItem C02,GenericItem relay |
// Increase the fan speed if the C02 level changes more than 50ppm to prevent rapid cycling
if((c02.state as DecimalType)-50.0< (setPointCO2.state as DecimalType)) {
//alter fan speed based on some smart algoritm...
}
]
@berland Thanks for the input on fire alarm. I did all the v2 setup via paperui. My Thing.json is huge, but if there is an export fuction or someone has a good filter with jq or similar, I can post the generated config here.
Thanks you @ssalonen for all your information here. It is nice to get some insight in how it all ended up. My main focus when suggesting the dynamic channel approach is having one thing as close to representing a physical unit as possible as this is more intuitive to a first time user. I can understand that it possibly is a bit late to change it at this point. Let me know if the benefits of changing it one day outweighs the challenges, and we’ll see if I have some spare time to pitch in.
I like your point about developing device specific bindings reusing the original modbus implementation. I will definitely look into this in the near future!
Hi, I purchased FTDI USB-RS485-PCBA and I have different pins for A ad B, so do you recommend that solid blue goes to B and strip blue and white goes to A? I will try to connect this today or probably over the weekend…so Gunnar are you sure that this wires goes like you said?
Hi, now I am confused, I finally bought FTDI USB and made modbus binding and don’t have any modbus.cfg file, so must I first create that file or is something wrong with modbus binding??
Sorry, I’ve been a bit busy the last weeks. The 2x modbus configuration for a complete villavent setup is huge. I used hours to set up mine even when I knew how it was done. There is no way I’ll cover all of it, but here is a partial fan config.
