Current States not updating

Hello all,
I have a number of Philio PAN06 Dual Relays for which I have written my own handler. They have been working fine for months and then at 4:30am the other day one of my Smart Apps started logging errors because the PAN06s disappeared! I don’t mean it lost connection, power etc. but it was completely deleted from my system! No sign of it in the app nor the IDE; it was as if I never owned it!
So I factory reset it and re-added it to my system. The problem is, now it is added the two channel states (switch1 and switch2) are not showing in the Current States section if you go in to the device in the IDE (as they do for the other PAN06s I have). This means the handler fails to set the state of the two buttons in the app and is logging errors when I try and get the device.currentState(“switch1”).value because as far as it is concerned switch1 and switch2 don’t exist?!
I saw someone mention re-adding the device, so I tried that but no luck. How do I force it to add these two extra states?
Thanks for any help or guidance…

Attributes won’t appear until you first send an event to set them. You often see the installed() method of device handlers request devices report in (triggering the attributes being set via parse()), or sending events to initialise the attributes if reporting isn’t available.

Update: I should also say that the IDE only shows attributes associated with the current device handler.

Ah, so I am missing something from my handler then?

I have looked through several other multi-channel device handlers this morning and can’t find what you describe though. How do I send an event to an attribute that doesn’t exist? And of the handlers I have looked at (and I have looked at all the multi-channel ones I can find) I don’t see any requesting a device report? Or sending events to initialise attributes.

Do you know of any examples where this is done, just to give me an idea of what I need to be doing?


def installed() {
    sendEvent(name: "switch", value: "off")        

So simple… …if you know how! :wink:

Thank you :smiley:

When you view a device in the IDE, the ‘Current States’ only displays the attributes associated with the capabilities and custom attributes of your current device handler, and only those that have actually been assigned a value. So if, for example, you are using the ‘Button’ capability, you will only see ‘numberOfButtons’ and ‘supportedButtonValues’ if they have been created for your device at some time.

That doesn’t necessarily mean your current device handler created them. You will see attributes created by any device handler you have used your device with since it was created (if there is a way of getting rid of the things, I wish I knew what it is). That includes any you only used for a few seconds because you may have been trying to update the way your device displayed in the app.

If you declare a custom attribute, you set it like any other attribute i.e. createEvent(name: "myattribute", value: "myvalue") as a return value from parse(), or sendEvent(name: "myattribute", value: "myvalue") used elsewhere. You will probably see a Z-Wave library method being called instead but that is what it effectively does. However, if you are only using the state within the device handler, it does seems you don’t actually have to declare an attribute, you can just use a custom event name e.g. sendEvent(name: “mystate”, value: “myvalue”) and things still work. Though that was only something I encountered few days ago and I wasn’t expecting it.

It seems to me that if your device handler has been working fine for ages, there can’t be an awful lot wrong with it. My best guess is that you may have inherited values for ‘switch1’ and ‘switch2’ for your devices from use with a previous handler, and when it came to a brand new device, they just weren’t there.

I think you are right, the previous handler created them months ago and then after this odd deletion event was the first time I tried adding a new device again. And thank you for explaining, that makes a lot more sense now…

I know what you mean about not being able to clear them up though; what I wouldn’t give for direct access to their back-end database on occasion!