HomeSeer / node-red-contrib-homeseer

HomeSeer Nodes for Node-RED
GNU Affero General Public License v3.0
5 stars 4 forks source link

Control/Update by msg.payload.status and the Device String/Status #17

Closed KSumwalt closed 1 year ago

KSumwalt commented 1 year ago

Setting a Device by setting msg.topic to update and only sending msg.payload.status apparently results in requiring the use of &hs.SetDeviceString(1119, "", True) to reset the deice string so it is controlled in HomeSeer's browser view and have the status change in the browser. This has been tested on virtual devices and also HomeSeer generated light switches both from z-wave switches with no Child items and one with a Child item (A HomeSeer switch in this later case).

Also, it seems I cannot set msg.topic to control and have only msg.payload.status for virtual devices, but need to use update while for HomeSeer created devices (light switches), but need to use update while I need to use control and not update

Node-RED V3.1.2 HomeSeer contrib V1.0.6

spudwebb commented 1 year ago

Setting msg.topic to updateand sending a msg.payload.status is equivalent to using the SetDeviceStringscripting function, so yes you will have to send another string or reset it to "", if you want the status linked to values to become the status of the device.

using msg.topic=controlon a physical device (like ZWave or Zigbee) will send a command to this physical device, whereas using msg.topic=update will only update the string or value of the device in homeseer without sending any command to the physical device. for a virtual device msg.topic=control and msg.topic=update should be pretty much equivalent, if it isn't working for you please provide a test case to reproduce the problem

KSumwalt commented 1 year ago

Thank you for the quick reply and explanation, @spudwebb! A reboot of Node-RED and HomeSeer as well as resets to the tested devices using the SetDeviceString scripting function seems to have worked. I think not understanding the backend of how msg.topic=update works may have confused the situation for me to some degree. I did not expected it to be the same as the SetDeviceString scripting function. The reboots were likely overkill.