Replacing a door sensor from Insteon with one from Yolink. Noticed in program I can set “Door State” to “Closed” but can’t set it to “Open”. “Open” is a choice in the drop down it just stays “closed”, doesn’t apply it.

I set the line to “Door state is not closed” which works well just wondering about this.

Edited November 1Nov 1 by drprm1

What version are you using?

Can you send me a log with debug enabled - I looked in the code, and see no reason it would not work

The logic is really not in the node (it presets both values being possible) - it is interface not accepting it (I believe) - there should be no node action when creating the program.

Do you see unknown as an option in the drop down?

Using version 1.6.3

Drop down options are open, closed, and unknown

YoLink_11-1-2025_43441_PM.zip

I can see a lot of Errors - it is a device being offline - maybe try to press the SET button

Nothing else obvious - I believe the issue relates to the console code where something has changed - I doubt we can get them to fix it as they are working on a new version

No prob. Like I said “is not closed” is fine.

Thanks for looking into it!

Interesting ... I also ran into this problem. I installed a new Local Hub and went to update my programs so they used the status from that plugin, but in the process, I had to change all of the logic from options like "is Open" and "is Motion" to "is not Closed" and "is not No Motion". The "is not" option is a workaround, but not being able to specify status options like "is Open" and "is Motion" is kind of problematic.

Would it help if we opened a ticket with UDI and asked that they take a look at what's happening on their end? I'm not in any rush, and can certainly wait for them to address things in the new UI, but it would be nice to have that function/capability back at some point.

Sure. Hopefully they can find something

That's very similar to the issue I have with the vibration sensor. The select list shows options, but doesn't apply some of the choices.

it is only when you create a program - correct?

43 minutes ago, Panda88 said:

it is only when you create a program - correct?

For me, yes. But I've only installed the plugin a few,weeks ago, and been trying this with 6.0.0, so no idea if it would be different with an older version.

16 hours ago, Panda88 said:

it is only when you create a program - correct?

It happens for me regardless of if I'm creating new programs or editing programs I've had for long time.

FYI. I submitted a ticket to UDI on this issue, and Michel replied he was "... escalating the ticket. Please stay tuned."

Ok - I think we found the issue - minor bug in AC (and partially my fault) - Issue occurred when I moved key parameter to ST variable (to show status in UDmobile). I left the original value variable with the same name(to ensure existing programs would still work, but AC cannot handle two variable with same name in the same node - I updated the variable names so ST (shows in UDmobile) gets the original name, and I appended a (legacy) to the name of the original variable. It should not affect existing programs as it updates automatically, but I would suggest moving to the ST parameter (without legacy) when creating/editing/modifying programs

Let me know if the issue is fixed in 1.6.10 - refresh store if it does not show yet

44 minutes ago, Panda88 said:

Let me know if the issue is fixed in 1.6.10

The issue seems to be resolved in the Yolink Local plugin for my motion, vibration, and contact sensors. Thanks!

Has the non local version also been updated?

I believe I updated both - 1.6.10 - if it does not show do a store refresh

Edited December 2Dec 2 by Panda88

Updated and now have xx(legacy) as drop down option of status in devices

Ie. In programming Door sensors status has options for “Door status” and “Door status (legacy). Motion sensors have options for “motion status” and “motion status (legacy)….Same with vibration sensors

Are they the same programmatically?

They are two different variables representing the same result so they are programmatically equivalent.

I had to do this because people requested UDmobile to show motion in your case and UDmobile shows the ST variable (which for most nodes originally presented online)

To make existing program run, I had to maintain the original variable (now named legacy) and then assign the same value to ST

Online moved to a new variable in this case

@Panda88

With the new nodes, giving us both Sensor Temperature (legacy) & Sensor Temperature, I am not clear which to use for temperature based programming?

Thank you.

Either one. They are programmatically equivalent.

As it was said, they are the same. If you write new programs I would use the one WITHOUT legacy as some time in the future if we run of variables (there are limited variables we can use in a node server) I would sacrifice the legacy for new functionality - Note, this is not very likely to happen (there are still a lot available), but just in case