ENV-VST-Cs on different masters using Duet module
a_riot42
Posts: 1,624
I am getting some odd behavior using 3 ENV-VST-Cs, 2 on a main master, and one on a guest house master. I am defining all three on the main master and using the AMX Duet module. However the ENV-VST-C on the guest house master isn't communicating with the module defined on the main house master. AMX says you can't do this, and need a comm module on the master the ENV-VST-C is connected to, but when I listen to the main master and the guest house ENV-VST-C is pulled off the wall I see the CIP offline event show up in diagnostics, so the main master can see the guest house master ENV-VST-C. Has anyone run into this issue before or is a symptom with the new NX series master and firmware?
Paul
Paul
0
Comments
I have a feeling I'll need two comm modules one on each master, at least according to AMX TS. I have a feeling the Axlink devices don't care which system they are defined on, just the master they are connected to. In tshooting the issue, I had an installer pull the tstat from the guest house and replace a main house tstat with it. I was about to tell him to change the Axlink address but suddenly it started working, even though it was defined on the guest master at 130:1:3. Simply being connected to the main house master's Axlinx bus was enough to get it to work. So it seems the system number is ignored. I'll have to do some experimenting and see what the best way to do this is with my UI module. My UI module does scheduling as well, so it sends commands to the tstats using PASSTHRU-128, and I'm not sure if the module will pass those along to the other master or not. If not I will need a completely separate comm/ui module on each master, all controlled from TPs attached to the main master.
Paul
I don't think you'll need to separate the code per se. I had the exact same deal going: main house with guest house. Once the duet comm module can talk to the real device, the virtuals can work over M2M just fine. I'm not sure why the real device doesn't fly over the M2M connection but it is what it is. It probably has to do with how Duet deals with device feedback and so forth.
That's what I figured so I am trying that first now. I'll see if it works when it boots back up. My concern was my scheduler not working, since it uses the Axlink address, but actually using PASSTHRU, as long as the virtual knows how to find the Axlink device it shouldn't' be an issue.
Paul
ie: PASSTHRU-', itoa(dvDev[tstat].number),';', sCmd"
Since that Axlinx address belongs to a different master, commands aren't working. I can't really run two scheduler UI modules either, since then I have two UI modules reacting to TP presses/feedback. Hmmm...tricky problem.
Paul
Actually not so tricky. There is an easy fix, I just didn't see it at first. I had to modify my scheduler module to send commands to the virtual of the associated Axlink device rather that just the first in the array, like the AMX module does it.
Paul
I was gonna suggest trying to put a couple fake virtual devices to take the place of the missing TStats in the guest house. I don't know if the DUET module would be okay with that. but it might work. But, if you got it figured out there's not point. glad it's working.
e
Yes that was similar to my thinking as well, but its not needed. Even though the Axlink device isn't attached to the main master, the guest house Duet virtual is defined on it, and it passes along the Axlink command to the other master which then knows what to do with it. Now I have one comm, one UI/scheduler module defined, and it will run any number of tstats/UIs on any number of masters. Life is good!
Paul
send_command vdvHVAC1, "'PROPERTY-Identifiers,128,129,130'"
The module must assume that the Axlink devices are on the same master the comm is running on, since it doesn't see the dps, just the Axlink device address. Whoever wrote this module figured the module would only need the device address, not the entire dps. Pretty lame actually. I shouldn't bother with this module, but I am lazy, and have it working despite this limitation so I will leave it for another day.
Paul
Not good. I’m surprised AMX hasn’t fixed that. And you’re right; you shouldn’t bother with the module. I avoid it as I see it as the more difficult way to go, not the lazy way out.
What advantage does the DUET module have? AMX already did a great job setting up the ENV-VST-C Axlink device (Axlink rocks) to accept send_commands (including the PG send_command for scheduling), levels, and channels for all control and feedback. The native commands, levels, and channels are listed in the ENV-VST-C Operation Reference Guide. Why go thru the hassle of using the DUET module to do the same exact thing? It’s actually more work and more overhead. Glad you got it all working though.
The only reason for the module in my use is iWeather. The old Netlinx module is broken but ironically so is the Duet one; but not as bad.
I don't really deal much with the AMX TStats any more so the need to fix it myself has hit the "do it later when you have some time" pile.
But, yeah... It's always bothered me that the VST duet module doesn't even really follow AMX best practices.
That's pretty much my situation as well. I'd rather write my own module for the tsats and weather, but unless I can control the weather with it, no one is willing to pay for the time for me to do it. Hence, Duet module gets installed.
Paul