Bug with ignore command OFF in GSD interface

[nite_man]

There is a serious bug in the Plutohome GSD interface. Command OFF is ignored 'because it is useless'. Does this bug exist in LinuxMCE?

---------
Cheers,
Michael

[ddamron]

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 SetLevel
or, 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.

[MarcoZan]

Hi Dan

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.

Did you find the same behaviour?

Thanks and regards
Marco

[ddamron]

Ahh yes, but here's what they did:

GSD now looks at the CURRENT STATE (or what it thinks is the current state) of the device.  If the device is OFF, and an OFF command is executed, that's when you'll get the 'useless' message.

Here's the work around:

to turn a device off, send a command 192 ON to YOURSELF (make sure you ignore it otherwise there will be an endless loop)
THEN, send a command 193 OFF to yourself (again, ignoring it)

I agree, their logic is a bit buggy.. but at least that's a work around..

HTH,

Dan

[MarcoZan]

Hi Dan

I'm a bit thick, so forgive me ...

What do you mean "send 193 to yourself"?
At what level should I send a 193 to myself? At scenario level or at ruby code level inside the GSD?

My understanding is that if I send a 193 command to the child device related to the light I want to switch off, such command won't reach GSD. If not, I would have some trace on logs.

Could you please make a "dummy oriented" example to clarify your point

Thanks a lot and regards

Marco

[ddamron]

Ok, Here's the breakdown:

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 OFF
ignoreoff = true #flag set to ignore next OFF command
SendCommand(cmd)
cmd = Command.new(95, 95, 1, 1, 192) # NOW send the ON command
ignoreon = true #flag to ignore the next ON command
SendCommand(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.

The OFF command is exactly the same, but reversed...
cmd = Command.new(95, 95, 1, 1, 192) #on first
...
cmd = Command.new(95, 95, 1, 1, 193) # now off
...

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

[MarcoZan]

Hi Dan

Let me see if I got your point.

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.

Am I right?

Thanks
Marco

[ddamron]

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 yourself
send a SETLEVEL (with '0') command to yourself
Send a OFF command to yourself.

To turn a device ON:
Send a OFF command
send a ON command
send 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

[MarcoZan]

Thank you Dan

I think I owe you a beer   

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 ...

Thanks again, Dan

Regards
Marco

[ddamron]

Your welcome MarcoZan,

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

[Marie.O]

Hello,

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.

Any thoughts?

rgds
Oliver

[ddamron]

Oliver,

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