@bravenel There is something very wrong with the Linked RGBW Light driver. It constantly turns the switch on without any input from the user or rule.
I have had to disable Link to Hub because of this as it is useless at this point. Please fix !!
dev:36682019-12-02 11:51:19.862 am infoTV Back Light level was set to 84%
dev:36682019-12-02 11:51:19.678 am debugparse 84
dev:36682019-12-02 11:51:19.631 am debugparse on
dev:36682019-12-02 11:51:16.476 am infoTV Back Light level was set to 84%
dev:36682019-12-02 11:51:16.301 am debugparse 84
dev:36682019-12-02 11:51:16.287 am debugparse on
dev:36682019-12-02 11:51:13.250 am infoTV Back Light level was set to 84%
dev:36682019-12-02 11:51:13.106 am debugparse on
dev:36682019-12-02 11:51:12.993 am debugparse 84
Can you show me the device page for that device. parse is called from something coming from the other side. What is the corresponding real device, and what are its events?
Give me a second here to set it backup again
I'm not seeing anything weird with this, works as expected.
on the master hub
dev:36782019-12-02 02:58:05.333 pm infoBookcase level was set to 18%
dev:36782019-12-02 02:58:05.229 pm debugparse 18
dev:36782019-12-02 02:58:02.523 pm infoBookcase level was set to 18%
dev:36782019-12-02 02:58:02.349 pm debugparse 18
dev:36782019-12-02 02:57:59.761 pm infoBookcase level was set to 18%
dev:36782019-12-02 02:57:59.649 pm debugparse 18
dev:36782019-12-02 02:57:57.104 pm infoBookcase level was set to 18%
dev:36782019-12-02 02:57:57.009 pm debugparse 18
dev:36782019-12-02 02:57:54.502 pm infoBookcase level was set to 18%
dev:36782019-12-02 02:57:54.415 pm debugparse 18
dev:36782019-12-02 02:57:51.924 pm infoBookcase level was set to 18%
dev:36782019-12-02 02:57:51.844 pm debugparse 18
On the slave
dev:572019-12-02 02:57:45.694 pm debugparse on
dev:572019-12-02 02:57:43.067 pm debugparse on
dev:572019-12-02 02:57:40.399 pm debugparse on
dev:572019-12-02 02:57:37.756 pm debugparse on
dev:572019-12-02 02:57:35.106 pm debugparse on
dev:572019-12-02 02:57:33.554 pm warndescription logging is: true
dev:572019-12-02 02:57:33.551 pm infoupdated...
Slave hub is where the actual device is located -- master hub is where it is linked to
What is your nomenclature? Slave = Link to Hub?
So, who's turning on the real device every 3 seconds? Your logs are for two different spans of time. Need same spans of time.
What type of device is the real bulb?
Please use screenshots for logs, not copy/paste....
So my master hub where the device is linked to from the slave is the one sending the command.
I tested this by setting the vd_Bookcase on the slave to Linked Dimmer and watched the parsing from the master hub which shows this.
dev:572019-12-02 03:04:31.075 pm info vd_Bookcase was turned on
dev:572019-12-02 03:04:27.963 pm info vd_Bookcase was turned on
dev:572019-12-02 03:04:25.329 pm info vd_Bookcase was turned on
dev:572019-12-02 03:04:22.698 pm info vd_Bookcase was turned on
If I set the Bookcase on the master hub back to Linked Dimmer the issue stops.
BTW I even had this same issue cleaning out all virtual devices on both hubs and did a fresh link.
You aren't providing useful information. You are assuming that I understand your context, but it's not visible to me.
I'm happy to help, but don't have what I need from you
Slave hub contains all my shelly devices which uses http calls the device. I used Linked to hub to create those devices on the Master hub.
Bookcase is really on the Slave -> Linked -> Master
The bug starts on the Master hub when the virtual device is ONLY set to Linked RGBW device driver. It does not happen with any other linked to* driver.
Master hub VD
Slave
Do you have any Zigbee RGBW bulb you can try?
No because all those devices are linked to either rules or motion lighting and really didn't want to spend hours attempting to move stuff and fix rules.
I can always send you a Shelly RGBW2 device to test with.
You don't have to change anything, just link one of those bulbs as is. Control it from its device page.
I'm trying to narrow the possible explanations for what is going on. Hub type is irrelevant.
Ok i'll try that... btw the master hub is a C-4 and the slave is the new C-5 hub if that makes any difference.
If you link one of those up, see if you can control it successfully from either device page, the one for the real device (which should control the virtual device), and from the virtual device page, you should be able to control the real device. This is just a basic sanity check.
A RGBW light device from the Master to the slave hub works just fine.
So, it probably has something to do with Shelly and http.
Please post all three device pages: Shelly, it's corresponding virtual device on the other hub of the same name, and the vr_ device from the hub with the Shelly (name is vr_[shelly-device-name]). I want to see their DNIs.
Slave
The vr DNI is 322aba79-8b7e-4e86-8eba-febed76f25c8_25f6e603-3402-408d-8889-4abd23fd056f
Master
The DNI is 322aba79-8b7e-4e86-8eba-febed76f25c8_25f6e603-3402-408d-8889-4abd23fd056f
What model Shelly bulb is this?
