I never managed to get this kind of switch working in HA because I really don’t understand the link between the configuration.yaml and scripts.yaml. I even tried splitting of the configuration but didn’t succeed. In this respect OH is lot more logical than HA. Only good thing which I saw in HA was creation of the dashboard which was super easy.
Now I can move on to topic 3 in my first post.
I think I’m not going to continue with HA any more and start migrating my system from Homeseer to OH. This will be really huge project.
Now struggling with issue 3 so I want to add a setpoint. Basically I need to write “2” to reg 130 and then new setpoint to reg 132.
I have created a number item for setpoint and I added “oh-stepper-card” widget as a Metadata which allows me to change the setpoint in the main UI. I use basically same logic as for the switch above so I created a new rule:
In the script section I send first “2” to reg 132. After this I want to multiply the setpoint (Autotalli_T_set) by 100. I’m not sure if I need .state here. Next I want to write to reg 132 new setpoint (Autotalli_T_set_2).
This script is not working and I don’t know if the maths or the syntax for writing to reg132 is causing problems.
You should find out how to inspect your openhab.log.
??
Find out more - look in your events.log, maybe you’ll see the command sent to the first Item so you can tell if it got started.
You have to declare new variables in DSL.
It is the Item state that you want, but you can’t really do maths on a state object. var Autotalli_T_set_2 = (Autotalli_T_set.state as Number) * 100
But overall comment, you used a transformation elsewhere for the divide-by-100 when reading (I can’t tell exactly where - a profile perhaps?)
Wouldn’t you want to use the same method for writing x100, for consistency?
Great, this did the trick. I did look at the documentation for VAR, but somehow didn’t quite understand how to use it.
Great thing is that when I have the stepper widget and click it, the new setpoint is written to reg 132 more or less immediately (I checked this with Modbus Master). This is really awesome feature in OH. In Homeseer this wouldn’t be feasible so easily. I guess you would need to hard code this stepper somehow.
When reading e.g. a temp value I need to use gain 0.01. For writing I have used x100 in the rules. I don’t know whether I could do this multiplication somewhere else because I’m not enough familiar with OK.
I have one problem with my temp value. If I use “number:temperature” type for my item Temp it seems that updating in the UI stops for some reason. The temp value is updated in the UI when the type is “number”. I have also tried to use %.1f °C in the metadata but this doesn’t seem to work. This is a minor thing at the moment so I will have a look at it later.
If you want to use Number:Temperature type Item, ideally you would update it with temperatures - that is to say a quantity, a numeric with units.
Temperature 20 means nothing - you need 20°C.
You seem to be using Modbus gain profile, which allows you to specify a unit by hand (as Modbus itself does not understand any units)
Note that if you are changing unit types and editing profiles etc. in flight, it probably will not work properly until the next reboot. Set everything up how you want it, then reboot.
Yes, I had a look at the Modbus documentation and I do have “0.01 °C” in the Gain box. Scaling by 0.01 seems to work but the temp value is still missing the unit. I have rebooted my OH every time after making any changes but °C is still missing. OK, this is only a small glitch now.
I have one more controller from Ouman which has slightly different Modbus protocol. So, I will be busy still with Modbus stuff for pretty long time.
Thanks. I have already looked at the events.log but not API Explorer yet.
I think I have solved most of my Modbus issues now. Next step is to get new Modbus TCP gateways (from Aliexpress?) and start replicating the items I have managed to create so far. During these last few days I have learned lot. Your help has been vital; without that it would have taken enormous amount of my time and in the worst case I might have even abandoned OH completely like happened with HA because I never understood it. OH seems to lot more logical.
I’m now moving on to my 2nd configuration but using same test programmable controller. I want to check few things. In the code above OH allows in principle to link e.g. MB130 to more than one modbus data Things (i.e. to reg130 and to reg132), but this MB data Thing (e.g. reg130) can have only parent bridge.
Now when I’m setting up polling of temp values, adding on/off switch and setpoint similarly as in my first post I guess I have to create new reg130, reg132, MB130, MB132 and myswitch for this 2nd configuration.
As I have ~10 controllers with different configurations there will be lots of data Things and number Items. I guess there is no way of combining them. Now I have setup my 1st configuration and multiplication is straightforward in principle but the OH system is getting very big and complicated. In Homeseer I had a script for each controller so the number of scripts was rather small.
I assume that I have to create reg130 and reg132 for each controller because you need to create a parent bridge to corresponding controller. How about the number Items MB130 and MB132? Do I need to create these for each controller? MB130 and MB132 can belong to one or more parent groups in principle.
Of course I could create these items for each of my controller but the number of them would be huge.
If I could combine some of these items how would OH know to which controller I want to write?
Yes. Otherwise how would it know which device you meant? (The bridge identifying the Modbus slave)
This is where you’ll find developing a naming convention helps, I go with pollers like slv21_hold_100 and data like slv21_h100
You can link many channels to one Item. The consequence is that many channels are linked to one Item - i.e. if you send a command to this Item it gets sent to all channels, that’ll be all linked slaves in your case. If any one channel updates from poll, it updates the Item regardless of other idle channels (and you cannot tell which one did it).
If you have 50 different data sources you can’t get around having 50 Items to represent them. That’s okay, they don’t cost anything.
OK, many thanks for the info. I think this is clear now. I guess I need to make backups very often if something breaks while making changes to the OH system.
Just remembered one more thing. The configuration I’m testing now is for an underfloor heating manifold, i.e. the controller operates 6 on/off valves based on temperature measurements. MB reg 81 has information on the status of the relays in the following way (copied from the Modbus manual for the controller):
R1=bit0, R2=bit1…R6=bit7
Now I realised that there are only 6 relays but this register 81 has 8 bits so what are these additional 2 bits for.
I created a poller Thing for polling reg81 (length 1) and MB data Thing with read type unint8. In this data Thing I tried Read Address 81.1 and this Thing was online. With other addresses, e.g. 81.2 the This was offline. I created a number Item and linked it to the data Thing. This number Item had a value of 0 even though relay 1 was on so bit0 should be 1. MB Master also showed 1. If relay 2 is also on, MB master shows 3 but my number item still is 0. So, it is obvious that my number Item doesn’t pick up right value. This relay status is also interesting information because then I would know which relays are ON so then I would know in which room heating is ON.
Edit: Forgot to mention that the controller is an independent thermostat with setpoints so OH is not controlling the relays.
When you are ready, show us your Things and channels code for the problematic relays. We cannot see over your shoulder, your descriptions will not reveal typos or or incorrect assumptions.
I will do this tomorrow. I’m still replicating your logic to my 2nd configuration. I have to say your logic works really nicely. Your help has been paramountal.
Edit: managed to find few Moxa Modbus tcp gateways in Ebay.
Hi, I managed to solve this problem. I thought that I should have uint8 for the Read Value Type because I thought that reg81 has 8bits (R1=bit0, R2=bit1…R6=bit7) but when I changed the Read Value Type to uint16 then I’m getting right value for the relay status and it changes if I open/close relays. I need to do some maths in order to see which relays are open and which ones closed. I guess I could do this in the script for reading reg81 but let’s see. I still have lots of other things to be done with OH. I haven’t started to create my own pages yet.
Somewhat confusing situation but I have made huge progress during the last few days, thanks to you.
