It's not a bug.. I had a hard time figuring this one out..Basically, the ON/OFF State of a device is SEPERATE from the SetLevelor, cmds 192/193 are seperate from 184.

When you send an ON command, it actually comes through as 184 at 100%you must also send a 192 ON command with that. the ON/OFF is like a toggle. Once you send the ON 192, then you can send an OFF 193 and it will work.

Logged

The only intuitive interface is the nipple. After that it's all learned.My other computer is your windows box. I'm out of my mind. Back in 5 minutes.Q: What's Red and smells like blue paint?

I may be wrong, but I think that nite_man is referring to something that I've also spotted before.

With Pluto I had a simple ruby code that I put into a GSD to drive a weeder I/O. It used to work fine sending 192 (ON) and 193 (off) to several channels. Suddenly it stopped working, and this happened upon a Pluto upgrade (from .43 to .44, if I remember well).

By looking at the DCE log it was clear that command 193 was totally ignored, and the reply from Pluto staff was more or less what 1audio is saying.

After that I stopped using GSD and Weeder (so pity, but it's true) because I had no time to find out a possible workaround.

I'm following your progress with Insteon drivers (although I'm living in Europe so I unfortunately won't benefit of your work) basically to see whether this strange situation with 193 - OFF command was solved or not.

To be honest I do not understand clearly what you mean.

I used to see that when I pushed the proper scenario button to switch a light on, a 192 command was sent to GSD (no 184 to level 100%), and when pushing button to switch off a simple 192 was issued to GSD.Ruby code in GSD was in charge to figure out which child the command was coming from and build the proper string to be sent via RS232 to Weeder board.

Simple, stupid, but working.

Moreover Weeder I/O has only digital I/O, so there's no point to set level, it's just a matter of switch channels ON/OFF

All of a sudden the command 193 was discarded. I tried several ways to do it (I think also invoking it from a shell command) but no avail.

Again, I did not investigate that much as Pluto guys seemed not interested in giving me an answer.

Your Child device is number 95.You receive a GSD command (192 ON) from DCERouter.Here's what you do:cmd = Command.new(95, 95, 1, 1, 193) # not this is OFFignoreoff = true #flag set to ignore next OFF commandSendCommand(cmd)cmd = Command.new(95, 95, 1, 1, 192) # NOW send the ON commandignoreon = true #flag to ignore the next ON commandSendCommand(cmd)

In your Receive Command for Child, don't forget to check those flags..If they are set, ignore the command, and reset the flag.

Notice I'm sending the command to myself: Seems useless right? That's what I thought... but what happens is the DCERouter gets the command, and sets it's internal state.. then sends the command back out.

Ideally, this shouldn't happen, but it does, and it caused me about 3 weeks of hairpulling to figure it out.

HTH

Dan

Logged

The only intuitive interface is the nipple. After that it's all learned.My other computer is your windows box. I'm out of my mind. Back in 5 minutes.Q: What's Red and smells like blue paint?

Basically your GSD decodes the child number, and according to the command received (ON or OFF) it sends the very same child a sequence of OFF-ON (or the opposite) to properly set the internal state and make sure that the last one of the 2 command will do the desired effect.

So the "toggling" is made against that Internal state, which is not automatically handled by GSD but has to be set "manually" with this trick.

Yes, that is correct. Most of the time, the intenal state is set correctly IF it's a device on/off..

The problem gets a bit trickier when you introduce the SetLevel (for dimming lights)

From trial and error, I'd deduced you can't send yourself a SETLEVEL command if the internal 'on/off state' is off..so it complicates things a bit...to turn OFF a device, if you just send ON then OFF, the STATE (or setlevel) does not change. so, if you go to (webadmin) Automation/Device Status, it's possible to see states like 'OFF/100' or 'OFF/50'

here's the workaround for that:to turn a device OFF:send a ON command to yourselfsend a SETLEVEL (with '0') command to yourselfSend a OFF command to yourself.

To turn a device ON:Send a OFF commandsend a ON commandsend a SETLEVEL command

Now, here's the tricky part:

ideally, you should track the internal state. This is something I'm NOT doing yet in my insteon driver.

If you track the internal ON/OFF toggle state, AND track the STATE (0 to 100), you can bypass 1 command each time..

HTH,

Dan

Logged

The only intuitive interface is the nipple. After that it's all learned.My other computer is your windows box. I'm out of my mind. Back in 5 minutes.Q: What's Red and smells like blue paint?

It sounds to me that tracking internal state is what GSD logic is already doing by itself (in fact GDS discard OFF command if internal state is already OFF),but it is forgetting to take care to set it properly upon command execution.

So if you want to track Internal state for toggling you may have to replicate something that already exist at a lower level (obviously adding the missing bits), that makes not much sense to me unless there is a clear reason to do it.

Is there anyone that can shed some light upon this strange way to handle Internal state?Have things been arranged this way for a specific reason, or is this to be considered a design bug subject to possible improvements/corrections?

I think that if this behaviour has to be corrected, better to know it in advance ...

I fought with that LONG AND HARD.. with TRIAL AND ERROR, and the only work around I found was sending SELF commands..What led me to sending SELF commands was watching the log when a Orbiter sent a command..all it did was send the command...'So I said to myself, Self: what is the orbiter doing that I'm not.... Sending a command to Self'Ideally, we should have EVENTS to change state information internally.

(I would like to change my previous statement, I do think it is a bug.)

Regards,

Dan

Logged

The only intuitive interface is the nipple. After that it's all learned.My other computer is your windows box. I'm out of my mind. Back in 5 minutes.Q: What's Red and smells like blue paint?

I think, the command should be sent, no matter what the computer think its internal state is. Especially with X-10 it is not guaranteed that a command is executed correct. Also, with external interaction the light can have any setting, and the computer does not know. So, if the user is executing "Light Off" the computer should send that command.

That is indeed why I implemented the functions the way I did.Problem is, even with knowing the internal state, when the router fires 2 OFF commands, the first one will get through, but the second won't. I'll look at the GSD code in question tomorrow to see if I can find any more insight.

Regards,

Dan

Logged

The only intuitive interface is the nipple. After that it's all learned.My other computer is your windows box. I'm out of my mind. Back in 5 minutes.Q: What's Red and smells like blue paint?