Modifiy deviceID

Developer's Corner Scene Scripting
#1

Hi,

Do you know if this is possible (and how to…) to change the deviceID of a device?

Why asking this? I have a HEM2 that has 2 child devices. They used to be device ID #12,13,14. After a firmware update and re-inclusion, the devideIDs are 84,85,86.

That means that all my luup code and scenes using the deviceID as ID are no longer working. So I would like to tell the device to ‘go back home’ on deviceID 12.

Possible ?

#2

No, you can’t change the device IDs.

#3

Hi Mcvflorin,

Thanks for your fast answer.

I feared this answer but thanks for making it clear. I had to change the ids in all my scenes and luup as well as in my database. Not too fun but doable.

I would add this to the wish list. I understand that Vera needs UID for the devices and generates those but users also needs to be able to define stable UID for their implementation.

The only work around I see today is to list all the ids in the startup lua and define constants and use them from everywhere. I would prefer to get some kind of UID (not the name as I may want to lazily name 2 devices with the same name) from Vera, have the ability to get the device id from the UID and have the ability to change the UID myself.

Adding more to the startup lua script adds to the need of what I mentioned in another post: the ability to have several startup lua scripts (or see it as a divided one).

This scene programming would no longer be like:
local id = 173
local var = variable_get(“…”, “…”, id)
but
local id = luup.GetID(“Sensor_Door_123456”)
local var = luup.variable_get(“…”, “…”, id)

Where Sensor_Door_123456 is NOT the name but the ID I defined.
The would give a good abstraction layer to this ID that Vera needs.

There is so much to do with Vera… this is probably your daily pain :))) but it makes the next firmware very interesting to work on I am sure.

#4

The same problem whith Oregon devices with RFXCOM interface. When you replace battery, you have to create again the device (AutocreateOn). And as ID is an editable field, I changed it, in order not to have to change the ID’s in the Luup code. I do not know if there will be problems in the future, but now everything seems ok. Just be sure that the ID you choose is not already used, or there will be a conflict somewhere. I think if it was not something to modify, the field will not be available in edit mode, no?

#5

The id field shouldn’t be editable. Currently it is, but changing it could cause trouble, the result is unpredictable. When I changed the ID of a device MiOS kept the original device with its ID, but created another 2, one with the same ID and one with the ID I gave it. This was a happy case because nothing broke.

#6

I have tried as well and I also got 2 devices with the same ID.
The problem start when you try deleting ‘one’ (no clue which one, and I think Vera also makes no difference).

For me it created a new device and it took a few deletes and reload luup to purge that all and re-include the device.

So definitely no solution. Seeing the results, I think this field should be set read only (that would be clear at least) and any change should be ignored by Vera.

#7

And what about modifying alt id?

#8

As long as the device doesn’t already have an altid it’s safe to change it. Usually the devices that already have an altid are the Z-Wave devices, the Insteon devices, multichannel devices (e.g. 3-in-1 sensors) and alarm panel devices.

#9

Thanks for the answer. But the AltID for Oregon sensors, if I put the “old” ID I had before changing the battery in the AltID field, will this AltID be interpreted in Luup code as the ID of the Oregon device or no hope? No other choice to modify all the Luup code???

#10

Those Oregon sensors are Z-Wave devices? The altid for a Z-Wave device is the node ID, based on which the routes are made. Changing it would probably cause the device to be inaccessible. It’s worth trying though.

#11

No, this is an Oregon device generated through the RFXCOM interface. The problem is the internal ID of the Oregon device change each time the battery is replaced. So my procedure to resolve this is now the following:

  1. Replace the battery
  2. Delete the Oregon device in Vera (because not answering)
  3. Change autocreate parameter to 1 in RFXCom controller device
  4. When the Oregon sensor is detected, put the autocreate parameter to 0
  5. Of course, I have to rename the device name, which is lost too
  6. As the Oregon device has a new Vera ID, I have to modify all the Luup code with this new ID

I have to proceed this way with all my Oregon sensors :stuck_out_tongue:

So it’s a littlebit “heavy” procedure, just for changing batteries, no?
So if someone has a better solution, welcome! :wink:

#12

AFAIK the device ID changes only if the device is remove and re-added. When you change the batteries, is the device deleted?

#13

I think what the chris66 is saying is that the when he changes the battery of the device, the device itself has a new unique id and the plugin can not interface with the device because of this. So he has to to tell the plugin to discover the device and in turn generates a new device with a new device id. Do I have this correct? Sounds to me a limitation of the device. The developer of the plugin would have to figure out how to prevent this. How often do the batteries need to get changed?

  • Garrett
#14

@Garrett, thanks a lot for translating my thoughts in an undertandable speech :wink:
Yes, it’s the translucent truth what you wrote. Now the battery have to be changed once half year.

#15

I agree with this. It does sound like a limitation of the plugin.

#16

Rfxcom LAN? rfxtrx?

Sent from my GT-I9100 using Tapatalk 2

#17

@hhg’s remarks?