I managed to solve this part. I discovered that “1” is sent to MB130 via the rule. Now I’m wondering about writing “0” or “100” to MB132. I assume that “0” is linked with “OFF” state of my switch and “100” is linked with “ON”. There is “But only if” in the rules so I need to figure out if I could use this for selecting between 0 and 100.
I don’t use UI rules.
You would send 0/100 based on whether the command was ON or OFF.
You’ve not said how long a time you want between the parts of your sequence, you may need to use a timer. You’ve not said if you need to do anything about reg 130 after the sequence.
Or if it just wants to be a sequence of actions with no real delay, you want to produce a UI version of this using whatever scripting language you have chosen
rule "my modbus sender"
when
Item myswitch received command
then
MB130.sendCommand(1)
if (receivedCommand == ON) {
MB132.sendCommand(100)
} else {
MB132.sendCommand(0)
}
There is a small chance of read poll occurring between the 130 and 132 writes - is that going to be a problem?
Great, many thanks. I must be really blind now. First I pasted your code into a new UI rule and saved it but when I reopened the code window the code was gone. I tried to google for rule tutorials but didn’t find any useful info yet. I believe we are now very close to solve my project.
As I mentioned above I could manually write “1” to MB130 and either “0” to MB132 or “100” to MB132.
OK, now I figured this out. My rule is:
configuration: {}
triggers:
- id: "2"
configuration:
itemName: Autotalli_OnOff
type: core.ItemCommandTrigger
conditions: []
actions:
- inputs: {}
id: "1"
configuration:
type: application/vnd.openhab.dsl.rule
script: |-
rule "Autotalli lämmitys OnOff"
when
Item Autotalli_OnOff received command
then
Autotalli_OnOff_130.sendCommand(1)
if (receivedCommand == ON) {
Autotalli_OnOff_132.sendCommand(100)
} else {
Autotalli_OnOff_132.sendCommand(0)
}
end
type: script.ScriptAction
Unfortunately it won’t write anything to reg130 and to reg132. data Things Autotalli_OnOff_130 and Autotalli_OnOff_132 worked when I manually wrote “1” to reg130 and either “0” or “100” to reg132 so these Things should be OK. Getting somewhat tired now so I need a beer.
Yup, that’s a text-file rule like wot I write in. You would have tomodify for UI use - the UI does the when-then stuff. The part between then-end is suitable for inclusion in a DSL type script action section.
Now I got it working. Many thanks for your help.
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:
configuration: {}
triggers:
- id: "1"
configuration:
itemName: Autotalli_T_set
type: core.ItemCommandTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
type: application/vnd.openhab.dsl.rule
script: |+
Reg130.sendCommand(2)
Autotalli_T_set_2 = Autotalli_T_set.state * 100
Reg132.sendCommand(Autotalli_T_set_2)
type: script.ScriptAction
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.
Look in your events.log or use API Explorer tool to be sure of Item states, without UI remodelling.
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.
Yes. But why would you want to do that? Any number of rules or UI widgets can send the same Item commands.
Perhaps I wasn’t clear enough.
I am just wondering if I can group somehow items.
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.