Device Preferences in Edge Driver becoming unset

Developer Programs Support
1

I have recently added a couple of custom device preferences to an Edge driver used for my VIRTUAL devices. As the preferences are not defined as ‘required’ I gate some code that uses them with a check for the device preferences not being nil. So when the device is initially created the code won’t run as the preferences aren’t set, but when the preferences are explicitly saved the gating lets the code run. On the face of it everything works fine, until the next day …

Then despite my device preferences clearly appearing to still be set in the app and definitely showing as still set in the API, my code stops running suggesting they are returning nil again. If I then save the preferences again all starts working fine, until the next day …

I am using ‘the next day’ to mean an as yet undetermined period of time, and I also haven’t determined if this is a period of time since first use, since last use, that passes a fixed time of day, or something else. So, for example, everything worked as expected yesterday evening at 6:30pm, but not at 1pm today.

This has been going on for a few days now, using inline and explicit preferences.

Anyone seen this sort of thing before?

Hub is running beta 58.8 firmware, FWIW.

2

Hi, @orangebucket

We’re trying to replicate this issue, we will see if the preferences go back to nil after today.

Just to confirm as well, your devices are type “VIRTUAL”, not “LAN”, right?

In the meantime, can you replicate the issue and submit hub logs, please?

We would also need:

  1. timestamps of when it worked and when it didn’t because we don’t know exactly when it is returned to nil
  2. Device Name (we’ll see to which driver and hub it is connected)
  3. Preference Name
  4. Support access to your account
3

Yes, the device is of type VIRTUAL, powered by my own Edge driver.

As it happens I was awake at four this morning (16th) so I have been able to generate logs with the device preferences seemingly returning nil at 3:55 am GMT+1, and then working correctly at 4:04 am GMT+1 after I saved them again. The logs might have been timed a minute or so later to allow me time to add a meaningful description to them.

For context, the VIRTUAL device LV Contact (Switch Activated) with Momentary has a momentary capability. When this is ‘pushed’ in the mobile app the handler emits a button pushed event and then reads the anideasortofthing.momentaryInterval (a number) and anideasortofthing.momentaryInactive (a boolean) preferences. If these are both ~= nil then the code will use the two preference values to determine the order in which ‘active’ and ‘inactive’ methods are called and the delay between them.

I’ll try and test it more today to see if I can get a better grasp of when it starts failing, assuming testing it doesn’t keep it going.

Update: Code already failing at 7:52 am GMT+1 (logs submitted). I’d like to think I’m not missing something obvious.

In case anyone is wondering, no that is not typical of my device names. That would be unwise as the mobile app truncates them (as is its irritating wont). No I don’t have a use case for this behaviour but I did have a public DTH that did it once.

4

Hi, @nayelyz

I have similar problems. My device type is VIRTUAL, powered by my own Edge driver.

The device preferences are not updated at all.

I added testing code to my driver. The tested device preference value is always nil.
In CLI logcat log does not show that infoChanged handler is called.

There are also other drivers in the same hub that were made in March and July and they work. The VIRTUAL type devices’ preferences are working.
Hub is running 57.14 firmware.

If you want to investigate the problem further I can send more detailed information about the driver which is not working.

5

I added the line

log.print( utils.stringify_table( device.preferences, "device.preferences", false ) )

to my driver today, just to check exactly what was going on.

I’ve been testing the device relatively frequently since and it just wouldn’t go wrong. Finally, after having left it alone since 20:40 GMT+1 I tried again at 22:30 GMT+1 and it failed (I didn’t dump more hub logs). This is what my extra log line gave:

2025-09-16T21:48:04.027016255Z PRINT Anidea LV Devices  device.preferences={}

So as you can see the cupboard is completely bare. Here is what the API was showing shortly after:

{
    "values": {
        "anideasortofthing.momentaryInterval": {
            "preferenceType": "number",
            "value": 1
        },
        "anideasortofthing.momentaryInactive": {
            "preferenceType": "boolean",
            "value": false
        }
    }
}

So the preferences were still set. Here is the driver log after I saved the preferences again and then ran the test:

2025-09-16T21:54:58.360880763Z PRINT Anidea LV Devices  device.preferences={anideasortofthing.momentaryInactive=false, anideasortofthing.momentaryInterval=1.0}

That is what it has been saying all day. I’ve had a look through the history and saw that I left an interval between tests at 16:06 and 18:37 without issue and that’s a longer interval than the problematic 20:40 to 22:30.

6

@nayely A belated addition to today’s update …

Although the driver has been reinstalled many times today without issue, I realised I hadn’t tried rebooting the hub as I had meant to. After doing so I immediately appeared to have the issue, though it is too late now for me to try and be more thorough in my testing.

The hub is on the beta programme and the recent 58.8 update certainly might have coincided with one incident, though I am not aware of any other reboots lately. Certainly not initiated by me anyway.

If preferences for VIRTUAL devices weren’t surviving a hub reboot I simply wouldn’t have noticed previously.

7

It is now just before 15:00 GMT+1 and a short while ago I tested my device and encountered the nil device preferences for the first time since I was writing the previous post around midnight. I should be clear that I was just reporting an observation as I am unable to correlate my issues with hub reboots that I am aware of.

I’ve now got another observation. Rather than twiddling both preferences to recover functionality I thought I’d tweak just one to see what happened. What happened is that the driver logging is now reporting:

2025-09-17T14:02:05.474077450Z PRINT Anidea LV Devices  device.preferences={anideasortofthing.momentaryInactive=true, anideasortofthing.momentaryInterval=1.0}

It is good to see both preferences present but one of them is incorrect. I switched anideasortofthing.momentaryInactive to true and back to false. The mobile app and the API are reporting false, but the Edge driver didn’t pick up the second change. I’ve repeated the trick and this time it is correct.