How to poll for a channel status
mighe
Posts: 39
Using duet, how can I know a channel status?
I mean: i want to query the master and know if a channel is on or off, without to wait for an event.
I mean: i want to query the master and know if a channel is on or off, without to wait for an event.
0
Comments
You can check it with square brackets ie:
if([vdvDev, 10])
{
print("'Channel 10 is on'")
}
Or use a channel_event. I don't understand what you mean about waiting for a channel_event. It will trigger as soon as the channel turns on. I don't think you will get faster notification than that.
Paul
In APIs I cannot find the method for under Java.
Sorry, I didn't see the Duet part. I know Java but not Duet Java. Wouldn't there be a device class for the master that you can query?
Paul
I was looking for such a solution for quite some time as well. Thanks a lot for this information.
The other thing I still didn't find an easy solution is how to communicate from my duet module to another (existing) non duet Netlinx device, which is kind of the opposite of the above situation. The problem I have, is to get a correct reference to the respective Netlinx device so that I could call one of the methods to send a signal like sendCommand(String s), on(int i), etc. I tried to create new instances and many other things without success, like for example:
NetLinxDevice nld = new NetLinxDevice(new DPS("33001:1:1"),true); nld.on(27);Any ideas are most welcome. Thanks a lot.
Patrick
By the way: I couldn't find any documentation of the class DeviceMgr. Didn't I search long enough or is there really no javadoc or any other kind of public available documentation?
Item 1)
// This gets it going NetLinxDevice device = new NetLinxDevice(dps, false); // allows events from that device to come back to you device.addButtonListener(this); device.addChannelListener(this); device.addDataListener(this); device.addLevelListener(this); // finally initialize the device device.initialize(); // use the device device.on(24); device.off(24);// here is your events that will get information back from the devices public void handleButtonEvent(Event ev) { } public void handleDataEvent(Event ev) { } public void handleChannelEvent(Event ev) { } public void handleLevelEvent(Event ev) { }Item 2)
I do not think there is any javadocs on this class.
Try the following program:
Netlinx:
DEFINE_DEVICE dvVirtual = 33333:1:1 DEFINE_EVENT DATA_EVENT[dvVirtual] { string: { send_string 0:0:0, 'NETLINX - string received' } } DEFINE_PROGRAM wait(10) { send_string dvVirtual, "'hi!'" }Java:
public SpikesSpikes(BundleContext bctxt, NetLinxDevice nd, Properties props) { virtualDevice = new NetLinxDevice(new DPS(33333,1,1), true); } protected void doAddNetLinxDeviceListeners() { virtualDevice.addDataListener(new IDataListener(){ public void handleDataEvent(Event arg0) { System.out.println("JAVA: received something"); } }); } protected boolean doNetLinxDeviceInitialization() { virtualDevice.initialize(); System.out.println("Java started"); return true; }Now, when the duet module is loaded, I expect something like:
But is:
In other words, when a duet device is initialized, netlinx stops to receive events because duet "eats" them.
I would not call this a bug, this works as designed, once duet has the device, NetLInx cannot use it. Others duet modules can.
I suppose it depends upon what you're used to. I've always been a bit creeped out by how Netlinx alows for multiple occurances of the same event. I've always been used to having only one event fire when it occurs.
I've always wondered just what happens with two or more of the same event firing.
for example.
BUTTON_EVENT[TP_1,0] { PUSH: { TP_Button_pushed=BUTTON.INPUT.CHANNEL some_function(TP_Button_pushed) } } (* // a whole bunch of code inbetween here. // a whole bunch of code inbetween here. // a whole bunch of code inbetween here. *) BUTTON_EVENT[TP_1,1] { PUSH: { TP_Button_pushed=BUTTON.INPUT.CHANNEL some_other_function(TP_Button_pushed) } }Now, if you hit button 1 both events will fire. But in what order? Oh, the possiblilites...
But I think that's not a good idea because it makes very hard - or impossible - to write simple scripts.
Three examples:
1) we often use complex netlinx module to control device (eg: kaleidescape or iport), but we cannot send them easily a command from duet.
Pushing a channel on kaleidescape module let you set which panel is controlling a player; our source controller is written in duet, so we have to do dirty things: the panel's buttons act on kaleidescape module directly and it push the panel used in duet.
Sometimes it's impossible: how can I send a feedback from a duet module to a netlinx one?
2) we have a light scenario module in duet where you can set the scene names using the panel's keyboard (which send data to port 1); the same panel controls a kaleidescape player where you can use the panel keyboard to set cd infos.
This duet design makes impossible to kaleidescape module to work correctly.
3) on a netlinx controller we want to use the i/o port as following:
- input 1 -> doorbell contact
- input 2 -> alarm output contact
- input 3 -> temperature sensor
If we cannot have the doorbell manager in duet and the others in netlinx
Keep in mind that DUET Modules are designed for "COMM" modules. if your going write more then comm modules inside your DUET modules. Write all your code inside the duet modules.
Three examples:
1) a) The PASSTHRU- command will send messages into the controlled device.
SEND_COMMAND vdvDuet,"'PASSTHRU-SomeMessage,13,10"
1) b) PASSBACK- command enables/disables responses back from the real device. You will actually get the responses in the string section of the duet device event in NetLinx.
SEND_COMMAND vdvDuet,'PASSBACK-1'
2) do not know what your point is here, are you coding the TP in the duet module? If so... Use different ports on the panel...
3) Send API messages to the Duet Module, do not monitor the IO inside the duet module.
That's exactly the problem, I'm looking for some workaround for quite some time now. I guess this has something to do with the fact that in the code examples in this thread a NEW netlinx device is instantiated - this seems to somehow hide the original device definition. That's why I found it very interesting to see that there is a DeviceMgr class which seems to act on EXISTING devices (referenced by their DPS id). I was hoping that this DeviceMgr class could also be used to get a reference to an existing netlinx device, which could then be used to communicate with this device. But since there is no documentation, it is hard to tell if such a thing is possible...
Patrick
Duet is one of the best AMX ideas and that's why we use those system.
As software developer I can say that using Java to program is much better than using Nelinx.
Netlinx lacks of refactoring, a test suite runner, has an ugly compiler that don't support function overload and sometimes says "major error" without any other clue to spot the error; to test your code you have to load it on a controller and wait it to reboot.
Using Duet we're saving a huge amount of time during development.
If Amx could make easier to a Duet module to communicate with Netlinx (i.e. let a device declared in Duet to receive Netlinx events) and fixes some minor bugs, it would be really the paradise
I would like to challenge this line of thinking. While JAVA is a 'real' programming language and Netlinx is not a 'legit' language in the eyes of the programming world, I find it hard to accept that we need to generate 3000+ lines of code to turn on a relay. I think that's what's missing in the discussion of JAVA vs. Netlinx. For the most part, we're not doing any heavy lifting. We're just controlling simple things and the simple programming method is what is needed.
We cracked open Duet in my last Prog III class. I was excited to get a look at it. I've done quite a bit of JAVA on my own. For fun, we did a 'write a whole Netlinx routine in Java'. The first thing I noticed was that to write something exclusively in JAVA was going to require 10 times the coding than it would in Netlinx. It was almost silly how much headroom is required to get the simplest thing done.
I'm still excited about JAVA because it opens up a whole arena of functionality that was simply not available to us Netlinx programmers. However, I can assure you that I'll still probably stay in Netlinx for a good chunk of the time simply because I'm not hauling hay in a Cadillac just on the principle of 'staying all in JAVA'
I've found that the JAVA community at large suffers from this mindset. I still maintian that the object-oriented paradigm is fine but seems silly when the job only requires a simple routine. JAVA programmers seem to tend towards maintaining the higher level of programming when it is clearly using a sledge hammer to put in a tack.
I also know that Duet was not intended to be a Netlinx replacement. It was mearly meant to be a gateway for companies to become AMX partners. While most companies may not hire Netlinx programmers, they will more than likely have some JAVA people. So, it was AMX's attempt to make it easier for equipment manufacturers to write modules for their stuff.