Did Restore a piston using a backup code change today?

[jkp]

I noticed today when I add a piston and choose Restore a piston using a backup code that I am no longer presented with the pull down list of devices to select devices. Instead I am presented with a search field that does not work. I must say, I do not like this new feature. Please consider bringing back the pull down list.

[c1arkbar]

Have you tried it again? It is working here

[jkp]

I tried about 10 minutes ago but still nothing. I have tried rebuilding my cache. I have tried different browsers. I guess it doesn’t like me any more.

[c1arkbar]

Ok so just going to check all my bases, you do have at least one RGB bulb correct?

[jkp]

I have 20

[c1arkbar]

What restore code are you trying to use?

[jkp]

Here is one.

Help with my piston

1) Give a description of the problem My piston doesn’t launch when it should 2) What is the expected behavior? The piston should be launch when my doors open 3) What is happening/not happening? In the log, nothing happen 4) Post a Green Snapshot of the piston[image] [téléchargement] 5) Attach any logs (From ST IDE and by turning logging level to Full) Nothing happen at 16h45, when my wife arrived, it work when I arrive at 17h15 08/01/2018 à 17:16:49 +257ms +5ms ╔Received event [Pier-L…

And this one

Report Unlock code used

Here is the code I have been using lately. [Locks Pistpon 2010712]

[c1arkbar]

@ipaterson and/or @ady624

When trying to restore a piston that has RGB bulbs there is no longer a populated list of devices. As you can see below.

Switch is populating correctly and even displays my RGB bulbs (lamps)

[ipaterson]

Thanks for isolating the issue, I’ll take a look at this today.

[ipaterson]

The referenced piston 0u4d is using an attribute from a custom device type handler. The query to build out the device list in these dropdowns is not based on the device type but rather on the attribute. So in the case of this piston, the importer will only show devices that have a $status attribute (which for all of us results in no devices).

This could certainly be handled better with a message to let you know why the list is empty, but I don’t think that defaulting to all available devices is a good solution since the $status attribute will not be available and the piston will not work anyway.

If multiple attributes from a device are used the device list will only include those devices that support all required attributes. In the case of ijo7 you would need locks supporting attributes lock and tamper.

Please let me know if you do have devices with all the attributes used in the piston but still do not see them in the list. Also @c1arkbar, what is the backup code for the piston with RGB bulbs?

[ipaterson]

Oops, previous comment was incorrect on the following:

The referenced piston 0u4d is using an attribute from a custom device type handler.

So in the case of this piston, the importer will only show devices that have a $status attribute (which for all of us results in no devices).

I should have looked this up first; $status is not from a custom device type handler, it is a pseudo-attribute provided by webCoRE so that certainly should be fixable. I’ll look into this.

[ipaterson]

I have a fix ready for the problem mentioned above with the $status attribute and noticed that the same issue affects the axisX, axisY, axisZ, and orientation attributes which are all derived from threeAxis.

This will not be released immediately; instead please let me know if there are any other pistons you have noticed that return a blank device list when you in fact have devices with matching attributes.

[c1arkbar]

Ok I’ll keep an eye out. This one was brought to attention by @jkp and I confirmed on the codes he was using.

[ipaterson]

Restoring devices in pistons that use the $status or axis attributes should be fixed in today’s 0.2.102 update.