otaviojr / node-red-contrib-smartthings

Allows you to control your devices and get their status using NodeRed
MIT License
32 stars 16 forks source link

onoff switch not updating #47

Closed Zbrooklyn closed 3 years ago

Zbrooklyn commented 3 years ago

I ran a loop with the update topic for the on-off switch to get the current state for a light it just keeps saying the same value given when the light was off

the only time the value changed was when I would make a change on more red and save (deploy) for some reason, it is not forcing an update from the api

traeblain commented 3 years ago

I'm getting the same problem. Cannot get the actual current status. It appears as the documentation says:

Every node will keep its state. Every time a device state changes a message will be send to the output node with the msg.topic of device with all relevant informations at the msg.payload property.

So the device nodes are storing the status in Node-Red independent of the actual status.

Furthermore:

Device changes are received through the webhook you set up at SmartThings Developers Portal.

So are we to assume that when we set the msg.topic as update the node isn't pinging the SmartThings' API? It is simply getting the stored state? And we have to setup a webhook to tell the node what the actual status is? That doesn't make any sense to me, if I'm asking for an update I should get the actual status not what Node-Red thinks it is.

Deltachaos commented 3 years ago

I am exactly the same opinion as @traeblain

otaviojr commented 3 years ago

We can have the pull, but the actual state should be send using the webhook.

Is the webhook working well for you?

regards, Otávio Ribeiro

Deltachaos commented 3 years ago

As mentioned in my other comment: https://github.com/otaviojr/node-red-contrib-smartthings/pull/52#issuecomment-781937027

Just because there is one way to get the current state, there are cases and situations where this way does not suite the real needs. Because of restrictions where you cannot access the system from the internet, because of the requirement that you need to work around "lost" updates using the webhook.

Adding this feature dose not conflict with the webhook, rather than just adding more possibilities.