View Full Version : Device Manager Device Retype

September 20th, 2008, 08:39 PM
Is there a mechanism in place to let a provider know that a device has been retyped in the Device Manager Type tab?

September 20th, 2008, 10:44 PM
I'm trying to understand what you are trying to do. Can you explain? According to DeviceRetyping.lua it should be "change opaque to the provider."

This means that we cannot subclass a device and put intelligence in it. This is a rather unlucky choice i.m.o. but for this major rev of Girder we are stuck with it.

September 20th, 2008, 11:32 PM
The lighting devices that are added to the DM from the Elk plugin are experiencing occasional problems. Since the Elk does not provide device type, dimmer or switch, the user has to make those changes. Occasionally these changes are being set back to dimmer without the users knowledge causing problems. If when a device is retyped there is an event generated indicating that the type has changed then I could keep track of the changes internally to the Elk plugin and make sure they are used.

September 21st, 2008, 09:17 AM
Right, I believe I worked on this with Phon33z.

Did he relay his findings? I believe the re-retyping happens when the ELK re-exports a device loosing the retyping. The Elk appears to resend it's devices when the management application connects to the Elk. Have you been able to confirm/deny this?

September 22nd, 2008, 11:51 AM
Yes, while the plugin is communicating, if the ElkRP software connects the Elk will notify the plugin. Once the ElkRP software disconnects the plugin will be notified. At that time I essentially restart the plugin so that it will rediscover any changes. It appears that when I do this, the DM is removing all instances of the devices and the changed settings. When discovery completes the devices are added without the retyping saved.

In the component file I use this to accomplish reloading of the plugin. I suspect this is the cause of the problem.

InstanceEventHandler = function (self,Instance,Event,...)
--print (ComponentManager.Component.Events.Update,Instance .Name,Event,unpack (arg))
if Event == "ProgramModeExit" then
local settings = self:GetInstanceSetting({Name = Instance.Name})
self:Event (ComponentManager.Component.Events.Update,Instance ,Event,unpack (arg))

September 24th, 2008, 05:17 PM
Any comments? I believe this to be the cause of the problem.

Any suggestions on fixing this?

September 24th, 2008, 05:35 PM
Can you check if a device exists already and then not re-publish it.

September 24th, 2008, 06:17 PM
What I believe is happening is that the devices are being removed from the DM completely. As a result when the plugin reloads, DM sees the devices has brand new devices. I have done some minor testing and have noticed that the devices are also being removed from the LocalDevices.cfg file, which stores the typing info.

The same thing happens if I just disable the plugin from the Component Manager.

September 24th, 2008, 07:02 PM
I see. That's not a brilliant way of storing retyping. I'll see what I can do.

October 5th, 2008, 12:35 PM
I see. That's not a brilliant way of storing retyping. I'll see what I can do.

Any word on this. Every time I add a device to the Elk and rerun Girder I have to go and reset all the non dimmer devices. Kind of a pain


October 8th, 2008, 08:58 AM
We didn't forget about this. My current project is leading towards this and I will address it soon.

November 12th, 2008, 09:07 AM
Ron anything on this? In the meantime is there a way we could change the device type programmically with a LUA script? That would at least be a work around.

Its kind of a pain to have to go in and reset all the non-dimming devices to appliance or light/switches. I have done it dozens of times now.

I am beta testing the new Elk plugin and have to say its rock solid and is even better than before. This is the last thing that needs to be addressed and I am sure Harelydude has done all he can to make it the best he can.

November 12th, 2008, 09:35 AM
I didn't get around to this yet. I've been incredibly busy. I'll put a higher priority on it.