MODBUS and System air

[gskjold (Gunnar Skjold)]

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?

[berland (Håvard Berland)]

The most recent rules for my villavent is to set the fan to max while the fire alarm is going, and then set it back to normal when the fire alarm goes back to normal state. Any thoughts on how the ventilation should be set if there is a fire?

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’.

[berland (Håvard Berland)]

I see that I’ve missed some posts here, sorry about that…

@skatun great to hear that you got it working! I love the idea of adjusting it for the fan speed based on CO2. What do you use for CO2 measuring?
Switching it off while you are not home is something I would be careful with due to condensation in the intake and exhaust. There is a reason why VillaventAllowFanStop is off as a default.

@berland did you find a good solution for physical connection between the unit and openhab? Personally I try to run everything over cable if I can.
How is the load on your rpi with this connected?

Is the four sensors standalone, or have you added the fourth sensor to the unit? At least mine seems to be missing the exhaust air temperature sensor and shows no value on this register.

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.

[rossko57]

are you involved in the development of the modbus binding or any other OH development?

Nope. User input only.

[berland (Håvard Berland)]

I have recently converted my setup to 2x binding. I think it took me 3hrs to do so… In short, I’ve done:
Added modbus serial slave. Then added poller for each range of registers I need to read. Then added a thing for each item I needed to read from. You can set the poll interval for each poller. So for the digital input coil, you can set something lower.

Would you mind sharing the Modbus 2 configuration files?

[ssalonen]

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 individu

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…

[skatun (Kim Skatun)]

@gskjold

What do you use for CO2 measuring?

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.

Here I will use the method in my heating tutorial: Tutorial for heating, generic rule

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...

}
 ]

[gskjold (Gunnar Skjold)]

@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.

[berland (Håvard Berland)]

Ok, no rush then, I would be more interested in a textual Modbus2 config, and might stick to my current working (!) modbus1 config until then.

[gskjold (Gunnar Skjold)]

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!

[maverick25 (Miha Mihalj)]

Hi, can you tell me which binding do you use in openhab ? just modbus binding?

[gskjold (Gunnar Skjold)]

Yes, it is the Modbus Binding. Currently v2.4.0 in my case.

[maverick25 (Miha Mihalj)]

FTDI USB-RS485-PCBA

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?

[maverick25 (Miha Mihalj)]

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??

[Kim_Andersen]

I guess it´s the modbus 2.4 binding… Then you need a thing file, not a cfg file.

[maverick25 (Miha Mihalj)]

I have modbus binding 2.5.0.M1, so How then I should put all the register in thing file? Like above did Gunnar

[maverick25 (Miha Mihalj)]

Can you capture picture of poller and thing to see how we can set modbus in binding v2? Some examples please please

[Kim_Andersen]

Look at this thread… It may give you a hint.

How to connect Nilan CTS602 modbus interface

This is a full setup and how to connecting a Nilan ventilation or heatpump using the Nilan CTS602 modbus interface to openhab 2.4 using a RS485 USB dongle. This example applies to Nilan Comfort 300LR (Ventilation) without pre- or after- heating, and no CO2 either. It´s a HVAC without heater or cooler. The three devices are optional addons for the Nilan Comfort 300LR. All data will be available through Modbus, if they´re applied. In this turtorial, they are not applied. First you´ll need a RS48…

[maverick25 (Miha Mihalj)]

Gunnar please copy your things file with binding v2 and item to see difference with new binding

[gskjold (Gunnar Skjold)]

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.

First a modbus serial slave:

Then a poller for the register range you need, here 100 through 138 (start 100, length 38):

And lastly you need a data thing, here for register 111 (actually register 112 in the villavent docs. The config is 0 index):

Read this thread and the modbus pdf from villavent to find the registers you want to read.