How to update switch status ?

[SevenW]

As previous posted in this topic:

/json.htm?type=command&param=udevice&idx=8&svalue=Off works
/json.htm?type=command&param=udevice&idx=8&svalue=On does not work

Is this a bug? It would really be great if the on command would work in the same way as the off command works. The on command doesn't do anything, despite it returns a status:ok

Already said a few times before in this thread: use nvalue:

Code: Select all

/json.htm?type=command&param=udevice&idx=8&nvalue=0&svalue=
/json.htm?type=command&param=udevice&idx=8&nvalue=1&svalue=

and as bonus try this:

Code: Select all

/json.htm?type=command&param=udevice&idx=8&nvalue=1&svalue=54

It turns out that the svalue is used as the dimmer level.

[SevenW]

Although the topic is put to solved, the original issue, preventing update loops is not solved. There is only a work around proposed.

The root problem is that when one is using on / off actions for the virtual switches.
When a virtual switch is operated from the http-json-api, the actions are triggered, but should not (or at least not operate the switch again). When the switch is operated form the domoticz UI, the actions are triggered as well, and should operate the external switch. Operation of the external switch always report its latest state back. This creates a loop.

The loop can be stopped in different ways:
- Block On/Off actions for a number of seconds after switching with an json command with param=udevice&nvalue=0|1
- Know the source of the switching, pass it with the action and prevent forwarding the action to the external device if that was the party who has sent the switch command.

The first version can be implemented in lua script or node-red (as proposed earlier), but has a downside: In the dead-time (after a udevice update of the switch state) any domoticz user interface action will switch domoticz, but does not tell the external party: Result is inconsistency between domoticz and external device.

So the preferred solution is to add a switcher-uid or something like that to the post-action, so that if the post action calls node-red, targeted blocking of messages can happen. I think adding a switcher-uid is a better solution than conditionally prevent the post-action. There may be many other uses of the post-actions. (On / Off actions).

Is it worthwhile submitting this as a change request?

SevenW

[juankar]

What Galoula wants is update status, not turn on/off the switch, is it oll right?. That's: update status according the real status of the switch.
Polling is a solution.
Or you can see viewtopic.php?f=17&t=7043
bye

[bloemkool]

Although the topic is put to solved, the original issue, preventing update loops is not solved. There is only a work around proposed.

The root problem is that when one is using on / off actions for the virtual switches.
When a virtual switch is operated from the http-json-api, the actions are triggered, but should not (or at least not operate the switch again). When the switch is operated form the domoticz UI, the actions are triggered as well, and should operate the external switch. Operation of the external switch always report its latest state back. This creates a loop.

I Noticed the loop, and tried working with dates and timestamps.
tried to compare MQTT domoticz/out/# output from domoticz and tried to compare that with plugwise/state/circle/#
But the script command was in the way on updating the device status.
I had no quick results. So I left it the way it is right now.

The loop can be stopped in different ways:
- Block On/Off actions for a number of seconds after switching with an json command with param=udevice&nvalue=0|1
- Know the source of the switching, pass it with the action and prevent forwarding the action to the external device if that was the party who has sent the switch command.

- Another right way could be that a MQTT/API able status update is implemented and is separated from the switch command if needed. I think that that would give much more power to Domoticz. Switching can be done via MQTT in Domoticz. (https://www.domoticz.com/wiki/MQTT#Send ... ch_Command)
- Maybe plugwise can be made hybrid and more Domoticz capable and read/write into the domoticz MQTT tree... (dunno if that is possible )
- Why not a new api option that just updates the status but not execute the command.
param=udevice&nvalue=[0|1]&execscript=[0|1]
By default the execscript is 1, this way nothing changes in API behavior.

As I look at it, this is a problem in Domoticz.
I see another example that might go wrong.... KAKU for instance. You don't know the state of the product, you just fire commands at it and hope the receiver really receives the command. With the execscript you can update the status of the KAKU device if you can read the device (maybe a webcam) it switches.

Another thing (that personnaly annoyed me).... Adding the virtual switches or sensors via, in our case, NodeRed. We create devices with a sensible and for us a reproducible ID. Now we cannot switch with that ID via the API. When looking at it from NodeRed we need the unknown internal idx value to switch. Of course I can find out what the value of the idx is via our ID... but hey, looking up an ID/idx combo, create a translate table and use that translate table to switch the correct idx number. Why can't I use the ID directly in the API?

And another thing.... Why can't I create virtual switches and sensors with the same ID and use unit number 1 for the switch and use unit number 2 for the readout of the power?

The first version can be implemented in lua script or node-red (as proposed earlier), but has a downside: In the dead-time (after a udevice update of the switch state) any domoticz user interface action will switch domoticz, but does not tell the external party: Result is inconsistency between domoticz and external device.

You are pushing for a concession. I would go for a right solution into Domoticz. If I would have the programming skills, I would be very glad in doing that. But I only master shell scripting.

So the preferred solution is to add a switcher-uid or something like that to the post-action, so that if the post action calls node-red, targeted blocking of messages can happen. I think adding a switcher-uid is a better solution than conditionally prevent the post-action. There may be many other uses of the post-actions. (On / Off actions).

Is it worthwhile submitting this as a change request?

SevenW

As I interpret/read it... I think it is too complicated and would not be reusable for other projects.

You have written a very cool program with plugwise2py but Domoticz does not play nice with it. I really like the scheduling tool in it, but is incompatible with Domoticz in every way. I removed all plugwise2py schedules from the circles and am forced to use the _crappy_ (NFI) schedules in Domoticz. Just to get updated statuses. I use a extensive schedule for my floor heating and that switches on and off every quarter and changes by weekdays and weekends. Now I have a 40line schedule in Domoticz.
Would it very hard for Rob to implement the pluswise code ( automagically transformed to the C language ) natively into Domoticz? This way plugwise would behave more like the Fibaro wallsockets which perform very nice in Domoticz. I would lend him a Plugwise set if needed for testing.

I hope I gave you some more and/or better ideas to work with.
Of course these are my 2 cents for tonight ...

[SevenW]

I could perfectly live with a dedicated command that updates the switch status, but does not execute the on/off actions. I also have been looking into contributing to the domoticz source code to have a better plugwise support. The code is however rather intimidating (I have programming skills). Adding new devices touches many files. However with the help of gizmocus I am willing to put some effort in this.

That said, I have solved some issues by now:

Another thing (that personnaly annoyed me).... Adding the virtual switches or sensors via, in our case, NodeRed. We create devices with a sensible and for us a reproducible ID. Now we cannot switch with that ID via the API. When looking at it from NodeRed we need the unknown internal idx value to switch. Of course I can find out what the value of the idx is via our ID... but hey, looking up an ID/idx combo, create a translate table and use that translate table to switch the correct idx number. Why can't I use the ID directly in the API?

Actually the api has switch commands end update device commands. I am using the update device, and that just takes the mac-based did. I will post my code soon.

And another thing.... Why can't I create virtual switches and sensors with the same ID and use unit number 1 for the switch and use unit number 2 for the readout of the power?

That would also be a nice idea. I solved this in another way. I take the last seven (what is in a name?) digits of the MAC, end prefix it with a letter. I noticed that meters can have any free string as did, but switches have a hexadecimal 32bit number. So I choose form the letters A-F. To be specific B=breaker/switch C=clock/timer E=energy F=power. A schedule-switch would get did=C0123456.

I really like the scheduling tool in it, but is incompatible with Domoticz in every way. I removed all plugwise2py schedules from the circles and am forced to use the _crappy_ (NFI) schedules in Domoticz. Just to get updated statuses.

When one settles with defining/modifying schedules in the plugwise-2-py webapp, then schedules can be quite usable. In my shot at node-red I can automatically create for each cirle a switch and a schedule-switch. They are updated correctly, but at the cost of not being able to switch faster then one UI-click per five seconds (this will be solved with the special api call that does not invoke post-actions).

Thanks for your feedback
SevenW

[SevenW]

What Galoula wants is update status, not turn on/off the switch, is it oll right?. That's: update status according the real status of the switch.
Polling is a solution.
Or you can see viewtopic.php?f=17&t=7043
bye

To opening post specifically mentions the issue with updates, actions and loops. There are several posts on the same loop issue. I thought this post was closest to the issue that I was seeing.

If I use JSON "type=command&param=switchlight&idx=1&switchcmd=On" tu Action URL is called too, I can use this method, because I have a LOOP.

I need to update the ligth status with URL, but without action, but need when I click in GUI, the action.

Polling could be a solution. I may be missing the point, but if I poll from node red, then I still have to call the api with param=udevice to update, and then I get the loop. This may be different for integrated hardware solutions such as zwave, but for pure virtual solutions like plugwise binding through only http api it does not seem to work.

SevenW

[nikels]

Hello i am struggling with Lua and updating devices. I both a Thermocouple from yoctopuce I am using this solution of updating devices.

I use the same settings as described in the explanation of Domoticz.




The information the device (Thermocouple) is sending is this.

Code: Select all

Request URI: /json.htm?type=command&param=udevices&script=yoctopuce.lua&timestamp=1450868355&network=virtualwindows&THRMCPL1%2d57DD1%23dataLogger=OFF&THRMCPL1%2d57DD1%23temperature2=13%2e46&THRMCPL1%2d57DD1%23temperature1=15%2e03

The Lua sript i am using is this.

Code: Select all

local temperature = uri['meteo#temperature1'];
local humidity = uri['meteo#temperature2'];

domoticz_updateDevice(150,151,temperature1 .. ";" .. temperature2 .. ";" .. "0" .. ";" .. pressure .. ";" .. "0");

I am using this script from the manual. The devices IDX is 150 and 151the devices are named temerature1 and temperature2. What am I doing wrong or how do I get this working..some help please.

[lmvlmv]

Is there any update on this topic? Haven't seen an answer that works yet. I have a similar problem with some Orvibo s20 switches.

Using the perl script from here (https://stikonas.eu/wordpress/2015/02/2 ... 20-socket/) is perfect. I have dummy hardware with a virtual switch. The on command runs a script:/ that sends the on command, similar for off. Perfect.

If the state of the switch is changed outside Domoticz, (button, app, power failure...) the state in Domoticz is now out of sync.

If you try to change the state of the device with the JSON API and set nvalue to 1/0, the start/stop script is executed.
If you try to change the state of the device with the JSON API and set svalue to 1/0, the start/stop script is executed.

While I could have an external process polling the status of the switch and then set the status of the switch manually that assumes the script is effectively a no-op. The discussion above indicates that could generate loops if the "toggle" action is used,

It would be much nicer to have a "status poll" option for a dummy switch that could call a third script and change the internal state of the switch only...

[yfaykya]

Has anyone ever come up with a good solution for this?
I have a central heating system that I like to control with domoticz along side the wall stats. The stats update domo via the api which is ok with no on/off script. However if I use domoticz to control same I get the on/off loop pain.

[ahache]

According to my mind there's at the moment a only solution:
like a guy said here you must create a virtual switch and put it like a sub/slave device of your real one. After this you update only the slave via any json command.

For example i have a bath_light_1, i create the S_bath_light_1 (idx 241) switch to go with. In bath_light_1 parameters i put the other one like a sub/slave
When the light is switching on via physical button a 0-1 input of my ipx800 card is switching on and a /json.htm?type=command&param=switchlight&idx=241&switchcmd=On is sending to domoticz.

In your scripts you must deal with 2 switch to check state cause there may be a little delay to get them same state.
But get rid off loops and you can use only one switch in you domoticz webpage, you forget the Status switch

Works for me for many devices from long now...was here to find a better one

Sorry for my english

[yfaykya]

I am going to use some uservariables for each and use them as flags on whether to exit out of on/on switches. I have ~ 20 switches so I really do not want to double that for this to work. I took a look at hacking domoticz today to add a flag to skip the event in SwitchLightInt but once it hit being queued extra it went past somewhere I was ok changing.
I really wish this was a standard feature! I'll try and give it more time at a later date.

[ahache]

you can hide state switch from switches page with $ prefix

[merula]

Hi,

I have similar problem with a switch that should control a PC. As the PC can be switched on and off manually too, I want to be able to update the state. I tried with json.htm but this on always triggers the action to. An additional status poll script would be perfect.

[Egregius]

You can get the status before updating the switch.
http://www.domoticz.com/wiki

[merula]

You can get the status before updating the switch.

Getting the status before update wont work reliable. In the time between button triggers the on command and the PC is up as well as between the button triggers off triggers and the PC really shuts down button state and PC state are out of sync. So the polling mechanism would trigger the button again.

[Egregius]

Then your polling mechanism does something wrong

[jake]

Still, the original request has not been answered yet. In my case I would like to update a selector switch with the status of Kodi. This works well both ways
However, once and a while Kodi changes for a very short time to 'on', while video/audio remains playing, triggering the script to switch the selector to 'stop'. This selector update causes the second script to fire: stop Kodi. The result is that this little misfire of Kodi will make it actually really stop from playing.

Question is therefore as well, please let us update the status, without firing the events connected to that status.

[Nautilus]

Not sure what is your exact setup (the script controlling the selector switch etc) but there has for a long time been the option to use UpdateDevice method in commandArray (lua) or udevice via json. The latter was changed for a brief moment (viewtopic.php?f=6&t=16052&p=119728&hili ... ce#p119728) but now working again without triggering the device change.

[mikkel75]

Not sure what is your exact setup (the script controlling the selector switch etc) but there has for a long time been the option to use UpdateDevice method in commandArray (lua) or udevice via json. The latter was changed for a brief moment (https://www.domoticz.com/forum/viewtopi ... ce#p119728) but now working again without triggering the device change.

Hi,

I have created a bug report
https://github.com/domoticz/domoticz/issues/3863

Since the 'udevice' param still triggers the event system to run and thus create a loop....

I'm testing with

Code: Select all

mosquitto_pub -h localhost -p 1883 -t domoticz/in -m '{"type":"command", "param":"udevice","idx" : 641,"nvalue" : 1,"svalue" : "On"}'

/M

p.s. I'm running Version: 4.11574, Compile Date: 2019-12-17 12:44:24.