Hi All
I have seen numerous topics regarding phantom devices that are created by the Vera controller with no real solution. I have the Vera edge controller on firmware version 1.7.1320 and during the initial setup it created a scene controller as a child of a Fibaro 2x1.5kW relay (only saw today it was created as a child).
Woke up this morning and found a random Fibaro dimmer module named “1” under my devices list with the parent showing “device not responding”. Under advanced settings the embedded check box is ticked. By unticking this I can delete the device and about 2 minutes later it is back which is extremely frustrating.
Has anyone found a proper solution of how to fix this and to keep it fixed as I do not want to delete a phantom device every few days.
I am seriously starting to doubt my decision to buy this system as I have quite a few problems, sms function doesnt work to alert on motion detection while armed, motion sensing sometimes work, sometimes it doesn’t and other times it is frustratingly slow.
Reviving that topic as I do not want to add a new thread.
My Vera Lite on 1.7.11 yesterday displayed 6 ghost instances of a Fibaro Motion Sensor, scattered across two rooms… Similar issues had happened to me a few times across last year and each time I had limited success deleting these ghosts and found that restoring a backup (including restoring the Z-Wave network) was the only stable fix…
Still I do not know the root cause of the issue (Fibaro device, Vera hardware or software or the z-wave chip ?) but suspect it has to do with low batteries on some devices on the network.
Anybody experienced similar situation ? Any fix suggested ?
Havent had any phantom devices for the fibaro motion sensors. But i have had issues with the Fibaro dimming modules. There is a luup code to hide the duplicate device entries…
Well, same here,
I have 15 phantom devices, since my entire system is only a few months old, i doubt it has anything to do with the battery.
My system hasn’t been used since day 1 because of a bunch of problems with configuring the entire thing!
i really love how there is such a support for this device! :-\
Guess i’ll just throw it in the bin and buy a different controller
I recently had an issue with my Vera Edge and a load of phantom devices.
I raised a ticket with Mios, and they were great. They identified the devices that were creating these phantoms, and then i asked them to hide them. Have you tried that yet?
A new firmware version was released a month or so ago that stopped more of them being created (for me anyway). To get rid of them permanently, they suggested a device reconfigure if they could be brought near to the Vera. Mine couldn’t so i just removed the devices when i had a chance and re-added. Perfect ever since and no reoccurrence.
My AEON HEM was also creating a load of them. I used to delete them all one by one (A real PITA) and have them come back randomly during LUUP reloads. I found out later that indeed a reconfiguration of the HEM device gets rid of them all. Somehow, it’s been over a month (a record) without them being recreated so… I guess some fix was put in the latest firmware.
I don’t think the firmware mentioned in the previous post took care of this. I have been getting phantom devices since adding the AEON HEM V1 device. I have resorted to restoring from backup to get rid of them, but this is really annoying. Currently I have 15 such devices with the name of “_Generic IO” and many with the name of "_GET_LANG(generic_sensor,sensor)10 where 10 is the unique number assigned to each on of these phantom devices.
I have not upgrade to the release that just came out last week, as I tend to wait a while on the most recent to see what is broke, but I don’t see this issue noted in the release notes anyways.
I may end up removing the HEM device. In addition to the phantom devices, the HEM actual metering devices continually freeze as they lose their capabilities definitions. If I tell the main HEM metering device to configure, it will create new remote devices, but this is not a great solution if you are currently using these devices in scenes as they get new device numbers.
The recent update got rid of about 17 phantom devices and created 10 new ones from an Aeon Labs Smart Energy Switch that has been in place for about 6 months without problems.
The problem isn’t the device, there is something with the firmware that Vera can’t fix. Calling them only “hides” the devices from the device screen, they still show up elsewhere. Changing the parent of the phantom device to “1” allows it to be deleted but at the risk of having the original parent device disappear on its own. Then you need to reinclude and fix any scenes/PLEG/Plugins it may have been part of.
It is a very frustrating situation that Vera needs to fix. I can see them loosing new customers if this continues. I’m on my 4th instance of phantom devices in just about as many months.
[quote=“RHINESEL, post:8, topic:188463”]The recent update got rid of about 17 phantom devices and created 10 new ones from an Aeon Labs Smart Energy Switch that has been in place for about 6 months without problems.
The problem isn’t the device, there is something with the firmware that Vera can’t fix. Calling them only “hides” the devices from the device screen, they still show up elsewhere. Changing the parent of the phantom device to “1” allows it to be deleted but at the risk of having the original parent device disappear on its own. Then you need to reinclude and fix any scenes/PLEG/Plugins it may have been part of.
It is a very frustrating situation that Vera needs to fix. I can see them loosing new customers if this continues. I’m on my 4th instance of phantom devices in just about as many months.[/quote]
Hi
I’m having the same problem with phantom devices (_GET_LANG(generic_sensor,sensor)). In this case it is for an Everspring Siren. Anyone know of a fix? The parent_id=1 on the phantom device.
If it’s a hardwired device and in a fair range, these ghost devices will disappear by configuring the device. Go to main device that generates these, then Device Settings-> Advanced → Commands → Configure node right now.
If it’s a hardwired device and in a fair range, these ghost devices will disappear by configuring the device. Go to main device that generates these, then Device Settings-> Advanced → Commands → Configure node right now.[/quote]
Hi John M.
Thanks for your prompt response.
The phantom device seems to have disappeared by itself. No idea why I got it.
If it’s a hardwired device and in a fair range, these ghost devices will disappear by configuring the device. Go to main device that generates these, then Device Settings-> Advanced → Commands → Configure node right now.[/quote]
I’ve also got a mess of these _GET_LANG(generic_sensor,sensor)
Doesn’t configuring the device delete all child devices though which causes a massive mess for things like a dual relay? I’ve probably got over 40 ghosted devices in my installation now because of this stupid bug. I wish they would just fix it. Like many tech companies they are focusing too much on new features and not enough on getting what they have to work correctly.
Feedback we get from all the social media channel is the backbone of all our firmware release paths. This particular issue is part of a broader range of factors which are independent of us, however we are trying our best to cover every exception.
I know that we covered many of the these situations in latest firmware updates. And as a start point, people need to make sure they are running the latest firmware updates on their units. Then devices in question need to be re-included.
Also setting Automatically configure to NO, will stop these devices to generate these ghost devices in the future.
And of course, Customer Care team will gladly help as well.
Feedback we get from all the social media channel is the backbone of all our firmware release paths. This particular issue is part of a broader range of factors which are independent of us, however we are trying our best to cover every exception.
I know that we covered many of the these situations in latest firmware updates. And as a start point, people need to make sure they are running the latest firmware updates on their units. Then devices in question need to be re-included.
Also setting Automatically configure to NO, will stop these devices to generate these ghost devices in the future.
And of course, Customer Care team will gladly help as well.[/quote]
Can you point me to which version you are speaking of and where in the release notes it says these issues were fixed? I must have missed it…
Also, what is the ramification of disabling automatic configuration? What would I need to do by hand moving forward if I disable it?
Also setting Automatically configure to NO, will stop these devices to generate these ghost devices in the future.
What other implications does setting automatically configure to NO introduce? On an existing and already included device; is there anything which needs to be dealt with manually that is dealt with automatically when this is set to ON?
Setting this option to off will cause any manual device configuration, like adding a new parameter, to NOT take the configuration, until you go to Advanced->commands → Configure node right now.
I had a ge dimmer switch that, after upgrading to the latest beta firmware, wouldn’t stay connected. It would communicate if I turned it on or off, but only for a few minutes before going offline again. I performed the procedure of “Configure node right now”, the same recommendation to remove the phantom devices, on the device, and it fixed this problem too.
I’m not sure I understand. By setting the option off, I will need to click configure node now every time I apply an update? Or just only if I ever make any config changes in the future?