With a growing Z-Wave device base in two separate buildings, I’ve recently acquired a third VeraLite. I have two separate Z-wave networks, each with a VeraLite, one for each building, and each bridged to the third one. The idea is simply to have a single place to define scenes, triggers, virtual devices, etc. HOWEVER…
…it appears that bridging functionality for some device types is incomplete. Two specific examples:
[ol][li]The UI5 controls for dimmer devices is missing entirely (although you can see a device control panel, it is entirely blank, except for a generic icon)[/li]
[li]Some features of more complex devices (eg. Denon AVR plugin) are not only missing from the UI, but also from the list of available services under the Advanced tag in scenes - things such as Volume control)[/li][/ol]
This rather undermines the goal of achieving full remote control of the bridged Veras.
Any insight which might help to address this issue would be much appreciated.
Interesting. Sounds similar to what I observed quite a while ago, in a private beta build and reported on the private beta board.
Other testers had no issues getting their Vera’s bridged and there was no input from the MCV side, and no personal need for me to operate my Vera’s that way (i.e. IIRC the reason some of us were testing it, is because it didn’t work at all anymore in one of the intermediate builds), so I abandoned it and haven’t re-attempted to bridge again.
Also, there are some public reports here of folks using bridged Vera’s in large deployments, and I believe there are no complaints. So I figured it was something specific to my setup. I haven’t spent much time on it, or investigated it.
[quote=“akbooer, post:1, topic:174179”]With a growing Z-Wave device base in two separate buildings, I’ve recently acquired a third VeraLite. I have two separate Z-wave networks, each with a VeraLite, one for each building, and each bridged to the third one. The idea is simply to have a single place to define scenes, triggers, virtual devices, etc. HOWEVER…
…it appears that bridging functionality for some device types is incomplete. Two specific examples:
[ol][li]The UI5 controls for dimmer devices is missing entirely (although you can see a device control panel, it is entirely blank, except for a generic icon)[/li]
[li]Some features of more complex devices (eg. Denon AVR plugin) are not only missing from the UI, but also from the list of available services under the Advanced tag in scenes - things such as Volume control)[/li][/ol]
This rather undermines the goal of achieving full remote control of the bridged Veras.
Any insight which might help to address this issue would be much appreciated.[/quote]
I have at least this much trouble bridging including icons that at first have controls then later don’t. My Vlite will not import in any useful form, my V3 is the one I referred to in the beginning
So the ticket is in and I’ve had an email asking for a bit more information (like what type of dimmers I’m using - although I think that any device which is not a basic switch is somehow deficient).
Quite by chance, I also loaded a new plugin (System Monitor), and I see that THAT doesn’t display correctly either - indeed I saw a Lua error when reloading. So PERHAPS this has nothing to do with bridging Veras…
…just a thought: this system has NO Z-Wave network devices included at all. Could this make a difference? Easy to try, of course, but I just haven’t yet done it.
oTi@ - might this also have been the case for your system in Beta testing???
The way I recall it, is that a whole of bunch of (what I thought were) standard devices did not render properly. Maybe I’ll find some time try this again in the next few days.
The issue you describe is similar to the issues i had when i bridged my 2 vera systems. Does the generic icon you mention look like the ones in my image attached?
If so, please check if the dimmer device type is installed on both vera systems. If not the vera system that has no dimmer installed probably will show the generic icon attached.
With my bridged vera’s these generic icons disappeared after ensuring that the device type was installed at least once on both vera’s
Yes, that’s icon in question. Files D_DimmableLight1.json and D_DimmableLight1.xml are both there (on both systems), apparently no I_ or J_ on either system. But, as I say, the ‘master’ device linked to has no Z-Wave devices attached at all. I did just wonder whether this might bypass some essential initialisation steps?
oTi@
Thanks - appreciate any help… and I’m still holding out for MCV support too!
@all
System Monitor turned out to be a bit of a red-herring, since it’s now working just fine…
…suspect I just didn’t reload enough times! I have not yet learned enough patience.
We did some testing last year and identified a number of issues:
When bridging, it will download installed apps for the “apps stores” of available and the most recent version. So a small mismatch in version can cause other related problems.
That as may require a number of manual restarts before everything is updated.
It won’t copy any manually install files and they should be copied to the new system before bridging otherwise you will encounter errors as the files do not exist.
Of course the workaround was to copy all file from one system to another first; including the icons.
With your dimmers try copying the impl-file name into one of the newly created devices on the bridged unit. IIRC, this will rectify that issue…
I will see if I can find the thread later to jog my memory and will update this if found.
I gave it a go and imported my main Vera 3 to another Vera that only had a 4-in-1 sensor on it. Interestingly those were about the only devices that rendered properly. So I proceeded to import to a factory-default Vera, and the result was all generic icons, except for scene controllers!
After creating a dummy device of one of the non-rendered types, doing a reload and a browser refresh, the imported devices of that type render properly.
I am pretty sure that once you haved paired 1 dimmer to your master, it will show all dimmer device panels correctly. This is exactly what I obeserved with my master vera.
MCV support should be able to recognise and provide help on this. I also openened a ticket, and provided feedback to MCV on the solution.
Let us know if the solution did work for you as well, it might help others with bridging plans.
Thanks folks. Sounds like @Jackpost and I have the same observation: it appears that if there isn’t a local instance of a particular device (switch, dimmer, thermostat, etc.), you’ll get a generic widget.[sup]1[/sup]
As a workaround, you could include such a device locally on the Vera that was imported to (per @Jackpost’s note). Or instantiate a dummy device ([tt]Apps[/tt] > [tt]Develop Apps[/tt] > [tt]Create device[/tt]).[sup]2[/sup]
As @Jackpost said, there should be enough here for MCV to take a look at.
[sup]1[/sup] Except for scene controllers. Possibly because Vera (the scene controller) herself is always there, but hidden.
[sup]2[/sup] Copy the [tt]device_file[/tt] value (e.g. [font=courier]D_DimmableLight1.xml[/font]) from the [tt]Advanced[/tt] tab of an imported device, then go to [tt]Apps[/tt] > [tt]Develop Apps[/tt] > [tt]Create device[/tt], paste the value in the [tt]Upnp Device Filename[/tt] field, provide a [tt]Description[/tt] (e.g. Dummy Dimmer), hit [tt]Create device[/tt]. Reload. Refresh browser.
It’s I who should be thanking all of you - there’s lots to try out now. Solution #2 (dummy device) would seem to be the best way forward (simply because I don’t have spares for all the missing device types!). Strangely enough, the ST814 temperature/humidity devices seem to be the only non-switch ones that are properly rendered.
The version mismatch problem for apps would seem to bode badly for system maintenance in future - especially since automatic updates don’t seem to work.
I will report back, but “I may be gone for some time!” Thanks again.
The “dummy device” approach works a treat - both for the dimmers, and also for a Variable Container (although for that it’s actually a case of installing the app AND creating a local virtual device which is functional).
Icons are right, controls are right - hats off to the power of collective minds!
Now, of course, this is not a robust solution to the issue ticketed with MCV, but it is a successful work-around (if you know about it). I will report the progress to MCV, but hope that the issue is looked at more closely for a permanent fix. The good thing is that is would seem to be easily reproducible.
My thanks again - this encourages me to continue to help others, wherever I can, through the medium of this forum - a great community.
I have had a ticket with MCV for over month. It is partly the reverse of this after removing bridging, and factory reset, the unit still request device updates. So it is specific technical affected files during bridging and how destructive to completely reverse the affects. oTi@, I’d be interested if you observations.
However, one statement they made in the response was install all apps first. I seem to think, that I never encountered this originally due to all units were being utilised with devices already added before bridging. So I assume you won’t get too much info.
@pgrover516,
Does any of this apply to your situation as well, or is it different?[/quote]
My issue is different and may well relate to bridging different UI’s, what is odd is that it worked correctly for months (with a few glitches) then one day all the icons on the “master” unit became generic
