[Warning] Modbus TCP Rollershutter proxy

Add-ons Bindings
,
1

Hello,
Modbus (TCP) is my key binding in OH2 (+140 items) and it has has been working fine over 8 months now ( 2.5.7 on RPI3) except some challenges with rollershutter items. I have defined Rollershutter as a semi-proxy item as follows:

  • Rollershutter Item is linked to modbus RollerShutter channel for which Thing has specified Read Address only (int 16 ) without Write Address specified (so that I can read the position of physical rollershutter via modbus but I am not sending any signal to my physical rollershutter using this RollerShutter Item)
  • When I click UP/DOWN/STOP, the Rollershutter Item sends command to Switch items which are linked to modbus switch channels (so that the signal is sent via modbus to my PLC)
Rollershutter    GF_LivingDining_RollerShutter4  "Rollershutter 4 [%d %%]"     <rollershutter>  (GF_LivingDining, gShutter)               {channel="modbus:data:29d4e8ec:rollershutter"}
Switch           RS_4Up                          "RS 4 UP"                                                                                           {channel="modbus:data:e15e2872:switch", expire="2s, command=OFF"}
Switch           RS_4Down                        "RS 4 DOWN"                                                                                               {channel="modbus:data:4c71eb31:switch", expire="2s, command=OFF"}
Switch           RS_4Stop                        "RS 4 STOP"                                                                                              {channel="modbus:data:62b75b0e:switch", expire="2s, command=OFF"}

Since few months when clicking on the Rollershutter UP/DOWN/STOP ( PC, touching Screen or Android) more and more often there is no reaction of the physical rollershutter and I have the following warning:

2020-08-19 19:22:48.961 [ome.event.ItemCommandEvent] - Item 'GF_LivingDining_RollerShutter4' received command UP
2020-08-19 19:22:48.981 [nt.ItemStatePredictedEvent] - GF_LivingDining_RollerShutter4 predicted to become UP
2020-08-19 19:22:48.999 [vent.ItemStateChangedEvent] - GF_LivingDining_RollerShutter4 changed from 100 to 0
2020-08-19 19:22:49.006 [WARN ] [ernal.handler.ModbusDataThingHandler] - Thing modbus:data:29d4e8ec 'RS_Roleta4_Position': not processing command UP since writeStart is missing and transformation output is not a JSON
2020-08-19 19:22:58.977 [vent.ItemStateChangedEvent] - GF_LivingDining_RollerShutter4 changed from 0 to 100

Is there any workaround for this issue?
Could this be somehow solved in the new version of modbus bindning which is now underprepartion?

2

I think your complaint is the [WARN] from the binding, because the associated channel is not configured to write?
It’s just a nuisance, the logging level for that report just needs changing

3

Yes, you are right this is the missing writing channel as in your note/enhancement.

But in addition to the Warning when I click on the Up/Down/Stop button of the rollershutter icon on Basic UI it does not trigger my rules to send command to switch items. Initially when I have set it up ~ 8 months ago it worked fine and I have not changed anything. But since few months now (I have performed few updates up till 2.5.7 OH2 version) it triggers my rules, very, very rarlly and I have to move rollershutter using my the physical swich near the window.

I am thinking if this might be due to computer mouse click button, but the same issue I have while using my touchscreen or Android mobile.

4

Okay, let’s follow that trail. Start by looking in your events.log for when you have trouble. Each click should produce a command event on whatever Item you have linked to your widget.
If it does not, then looking for a UI issue.
If it does, maybe a rules issue.

Obviously UI issue will be affected by environment - device, browser, UI, blah. Maybe you are using Android app?

5

Yes each click produces command event and warning. Then after 2 seconds binding expires (which is correct since I need only to transmit start/click signal via modbus to my rolershutter block/program in PLC/twincat) as follows:

2020-08-21 12:12:49.047 [ome.event.ItemCommandEvent] - Item 'GF_LivingDining_RollerShutter1' received command UP
2020-08-21 12:12:49.081 [nt.ItemStatePredictedEvent] - GF_LivingDining_RollerShutter1 predicted to become UP
2020-08-21 12:12:49.116 [WARN ] [ernal.handler.ModbusDataThingHandler] - Thing modbus:data:0281c11b 'RS_Roleta1_Position': not processing command UP since writeStart is missing and transformation output is not a JSON
2020-08-21 12:12:49.118 [vent.ItemStateChangedEvent] - GF_LivingDining_RollerShutter1 changed from 100 to 0
2020-08-21 12:12:54.407 [vent.ItemStateChangedEvent] - GF_LivingDining_RollerShutter1 changed from 0 to 100

The rule is very simple

rule " OH RS1 - UP"
when
    Item GF_LivingDining_RollerShutter1 received command UP or Item GF_ALL_RollerShutters received command UP
then 
   if (RS_1Down.state == ON || RS_1Up.state == ON || GF_LivingDining_RollerShutter1.state == 0) {
        return;
    }
    else RS_1Up.sendCommand(ON)
end

My conclusions so far:

  1. This shall not be a rule problem since (i) the rule is very simple and (ii) from time to time the physiscal rollershutter works after click (following the command produced there are logs of rollershutter position changes as well)
  2. This shall not be an expire binding issue since changing from 2s to 4s does not change anything
  3. This might be an issue related to the warning of the modbus binding?
  4. This might be a device/browser/UI issue? - however, I have dozen of switches which send signals via modbus binding and after clicking they always work (switch on or off a light), so the problem is only for rollershutter widget

I have no other thoughts at present

6

I can see a huge race condition in your rule.

Your rule is triggered by Item receiving command.
Then you look at the same Item state.
But the results you get there will be indeterminate. This stuff is asynchronous, and commands are not states.

Your Item has autoupdate enabled by default. So a command will eventually update the Item state. That takes time, and may or may not have been done by the time the rule looks at the state.
You can log out the value of state at the start and end of your rule to see what I mean.

I usually advise disabling autoupdate for Modbus linked Items, as you’re probably polling for state regularly and do not need its guesses. This is especially true for roller shutters, which will have a slow response to commands, if you want to see “actual” state in your Item.

This mentioned in the Modbus binding docs.

1 Like
7

Thank you for looking at the rule and pointing this - looks like a source of problem here
(1) After removing the triggering item state checking condition, there is a short delay then the command is passed and the blind moves!
I have put the item`s state checking condition for the triggering item in order to prevent the following cases:

  • when the blind is UP and I click by mistake UP the power is supplied to blind/motor over 30seconds (motor hums)
  • the motor of one of my blinds has a damaged end, if the blind is UP and I click by mistake UP, the blind goes down

Hence, I need to move the checking condition at the PLC/programming level, but:

This seems to be even a better solution. (2) Without changing the rule (preserving triggering items state checking condition) I have added the autoupdate=false` and the blind moves and its reaction is very fast after clicking.

So I will stick to (2) at present but if any issue occurs I will proceed with (1)

By the way, I have ~140 items using mobdus binding - is it possible to set autoupdate = false for all items? I have seen some conversation about it but not sure if its now available in 2.5.7?

Thanks for your help!

8

It is an individual setting per Item. It is no more difficult to set than giving each Item its unique channel. You need not change autoupdate for any Item that you do not send commands, because in that case it does nothing.