Curious dependency problem between several lights and switch

I spent a very frustrating day trying to do something that seems like it should be very simple.

I have a multi-button in the entrance to my bedroom, which has no local load but turns on the two bedside lights. One is the load on another MB, one is the load on a simple switch. All I wanted to achieve was to get the on/off buttons in the hall to reflect the status of the two bedside switches, such that entering the room and turning on with the hall on button, followed by turning off each bedside light in turn would result in the hall switch going off once both lights were off. Conversely, turning on either bedside light should turn on the hall on button.

I almost have it working but it was pretty involved and the remaining bug is infuriating!
So, right now we have:-
PowerLinc group 10 is Bed1 & Bed2
PowerLinc group 16 is just the #1 button of Hall

Trigger 'hall on' triggers group 'MBed on' when Hall on button is pressed & 'hall off' triggers 'MBed off' when Hall off button is pressed.
Trigger 'bed1 on' does group 'Bed1 on', 'bed1 off' does 'Bed1 off' when the Bed1 MB on/off buttons are pressed
Trigger 'bed2 on' does group 'Bed2 on' etc.

Action group 'MBed on' sends on to group 10 & then executes group 'update'
'MBed off' send off to group 10 and calls 'update'
'Bed1 on' directly turns on the load for Bed1 MB & then calls 'update', 'Bed1 off' does the obvious.
'Bed2 on' & 'Bed2 off' do the same for Bed2 switch.

'update' is the interesting bit since it does a simple applescript that should logically OR the state of Bed1 & Bed2, sending on to group16 if either Bed1 or Bed2 are on, or sends off otherwise. Turning on either light individually, or using the hall switch should result in the hall on led going on. Once both lights are off then so should the hall on LED (and of course the off LED should turn on). The applescript is -

Code: Select all

delay 3
set c to (on state of device "MBedBridgetControlSwitch")
set b to (on state of device "MBedTimControlMB")
if (c or b) then
    send insteon group instnTurnOn using name "MBed lights indicator"
else
    send insteon group instnTurnOff using name "MBed lights indicator"
end if

{the delay seems to make no actual difference and is there because I though there might be sync issues causing problems}

What actually happens is a bit confusing. So far as I can tell it all works when operated from the Indigo app (executing actions or triggers manually) or from the control page. BUT if I press the physical hall 'on' button the bed lights go on.. .and the hall 'on' LED goes out! If I press the hall 'off' button the lights go out and the 'on' LED goes on! To make it still more confusing, pressing the bedside switches to turn a light off makes the hall LED correct itself. Debugging is proving difficult without an actual debugger. Advice - or even pointers to good advice- on how to get more information out of the system would be welcomed. An actual solution would be even nicer!

[jay (support)]

I think you probably want to step away from what you've actually implemented and just clearly state what you want to happen. Often times when organically growing solutions, bits of previous attempts continue to live in the system and cause unexpected problems.

Here's what I would do:

1) Disable all triggers related to this solution and delete all INSTEON links between the devices. Make sure that when pressing buttons on the hall KPL nothing happens anywhere, pressing the actual switches only controls their respective loads, and controlling the loads from Indigo doesn't cause anything else to happen (like the hall kpl's going on/off).
2) Fully describe (at least to yourself if not here) exactly what you want to happen. Share here if you want some input as to the possible approaches.
3) Only then would I start implementing. Start with the most basic part of the solution - implement that part and test until you're satisfied that it's working correctly. Document exactly what you've done.
4) Add the next part of the solution. If during that implementation the first part stops working then you have the document that describes the first part clearly so you can get back to it.
5) Repeat for each step.

I know it sounds obvious and perhaps tedious, but when you're implementing complex logic you will find that if you follow this procedure you'll reduce the amount of frustration when you find something isn't working correctly - you can always revert back to the previous state.

All good advice Jay, and pretty much what I did. Your reminder to check for any left over insteon links caught one possible problem though. (later - nope, didn't make any actual difference, dang)

The intent is to have the hall MB on/off buttons turn on/off both bedside lights. That's obviously easy enough with simple links and is what I had before. I also previously had a link back from bed1 to the main load on hall so that if I turned off bed1 the hall 'on/off' leds would show off. Bed2 was left to fend for itself. It worked ok but didn't play nicely with control pages etc.

What I'd like is for the hall 'on/off' leds to reflect the logical OR of the two bedside lights; if either of them is on, so should the hall 'on' led be.

Good news is that I spotted the 'log' action in the applescript dictionary so at least I can do some good ol' printf type debugging. You don't want to know how many years of experience I have of that particular pleasure…

More later to report what happens next

[jay (support)]

Off the top of my head:

1. Leave the responder links from the kpl to the lights - that part should work fine.
2. Create a trigger that fires when bed1 becomes ON that turns on the hall kpl.
3. Create a trigger that fires when bed2 becomes ON that turns on the hall kpl.
4. Create a trigger that fires when bed1 becomes OFF, add a condition that bed2 is off, and action turns off the hall kpl.
5. Create a trigger that fires when bed2 becomes OFF, add a condition that bed1 is off, and action turns off the hall kpl.

The conditions create your OR - only the last one off will actually turn off the hall KPL. The above has some redundancies (the hall kpl could be told to turn ON when it's already ON, etc.) and you could solve that by adding a few more conditionals - but it probably doesn't make that much difference unless you're having some severe traffic issues.

You could, of course, do it with a script as well - just one big script that you trigger whenever either light has any change.

Ah. It's a synchronisation issue. At the point where the applescript to OR the two bedside light states gets run the system has not done whatever it does to get the switch state up to date. I'm using 'on state of device' to read the status - is that the right thing?

I imagine I need to do something to either read the switch state explicitly, or cause a synch sweep, or offer it a candy or whatever. I was under the impression that the state would be up to date based on something on the forums that implied state got update each time a script was triggered, but obviously I misunderstood.

OK, with some logging scattered around it appears that the action group/applescript to update the hall 'on' led is being called *before* the actual insteon send to turn the lights on is sent. That would make it hard to get an appropriate answer to a status request… I'm obviously missing some important information about how actions and scripts are executed.

Here's the log output:-

Code: Select all

Trigger Action      MBedBridget MB-1 off
  Action Group        MBed Bridget light off
  Action Group        MBedUpdateIndicatorLight
  Script              update light
  Script              c =
  Script              false
  Script              b =
  Script              true
  Script              indicator on
  Sent INSTEON        "PowerLinc Interface" off (group/scene 12)
  Sent INSTEON        "MBedBridgetControlSwitch" status request (received: 0)
  Sent INSTEON        "MBedTimControlMB" status request (received: 100)
  Sent INSTEON        "PowerLinc Interface" on (group/scene 16)

You can see that the update script gets run - which should include a couple of status requests I stuck in more in hope than expectation - before the actual send to either the status requests or the group off to #12. I was expecting to get the latest state *after* turning off group 12 and thereby turn off group 16 (the indicator light). I'm pretty puzzled at this point.

[jay (support)]

Again, not enough information about the parts to respond...

OK, I'll try explaining what appears to be happening again; let me know where there isn't enough detail for you.

Hall-1 being pressed triggers Trigger Action "MBed hall MB-1 on".
"MBed hall MB-1 on" calls action group "MBed lights on"
"MBed lights on"

sends group on to group 10 - both the bedside lights
executes action group "MBedUpdateIndicatorLight"

"MBedUpdateIndicatorLight" runs Applescript -

Code: Select all

log "update light"
status request "MBedBridgetControlSwitch"
status request "MBedTimControlMB"

set c to (on state of device "MBedBridgetControlSwitch")
log "c = "
log c
set b to (on state of device "MBedTimControlMB")
log "b = "
log b
if (c or b) then
    log "indicator on"
    send insteon group instnTurnOn using name "MBed lights indicator"
    set value of variable "MBedUpdateIndicator" to "true"
else
    log "indicator off"
    send insteon group instnTurnOff using name "MBed lights indicator"
end if

And the log output is

Code: Select all

Trigger Action      MBedBridget MB-1 off
  Action Group        MBed Bridget light off
  Action Group        MBedUpdateIndicatorLight
  Script              update light
  Script              c =
  Script              false
  Script              b =
  Script              true
  Script              indicator on
  Sent INSTEON        "PowerLinc Interface" off (group/scene 12)
  Sent INSTEON        "MBedBridgetControlSwitch" status request (received: 0)
  Sent INSTEON        "MBedTimControlMB" status request (received: 100)
  Sent INSTEON        "PowerLinc Interface" on (group/scene 16)

*IF* the log output is an accurate reflection of what is actually happening, then it implies that the applescript trying to find the status of the two bedside lights is not getting accurate replies before continuing.
What I expected was to find that hitting the Hall-1 button would turn on both lights, the status would be 'true' for both of them when the script ran, ORring would of course be true and thus the indicator light would be turned on.

So,

is the log supposed to accurately reflect the order of what is going on?
are the 'on state of device' statements supposed to be up to date even without using explicit status requests? (I've read forum postings that seem to imply that)
are my status requests supposed to return a correct answer before the applescript proceeds?
if not, how does one get accurate status into applescript?
do you have documentation that explains all of this that I ought to have found and read earlier?
is there any way to turn up the level of detail the logging shows?

[jay (support)]

I think your problem is that you're expecting the actions in the action group "MBed lights on" to run sequentially. They don't. Indigo attempts to parallelize actions as much as possible. So, while Indigo queues up the send group command to send the INSTEON group, it also attempts to run the AppleScript. So when the script runs the state of the lights is still potentially in flux because the commands to turn them on/off are in a queue for the PowerLinc.

But, I have to say - this is a rather Rube Goldbergish approach to the problem. See my post above with my thoughts - I think it's much easier.

Ah, right, so the log output is accurate and I was unaware of the asynchronous nature of the sends/requests. That explains the problem. Is it documented anywhere? Are there any options to do blocking calls for some sends/requests? For example, a status check sent from an applescript used as part of a Condition within a trigger surely has to wait for the request to return its answer? It would be nice to get a really good understanding of it for future work.

I should add that using a variable set to true/false by the action that turns on/off each light instead of trying to find the 'real' status works just fine. It has the conceptual problem that it will be incorrect should the light fail to turn on for some reason, which is probably not a big problem in reality but one of the things I like about the insteon h/w is the status checking ability. Using it seemed like a pretty obvious thing to do!

[jay (support)]

Is it documented anywhere?

We've said it on the forums many times but I don't know that it's in the actual docs.

Are there any options to do blocking calls for some sends/requests? For example, a status check sent from an applescript used as part of a Condition within a trigger surely has to wait for the request to return its answer? It would be nice to get a really good understanding of it for future work.

Status requests are by nature asynchronous because of how they work at the INSTEON transport layer. However, given what you're trying to accomplish, I don't see how a status request is necessary. I really think you're making this much harder than it needs to be which is why I suggested that you take a look at the problem outside of what you've already implemented.

timrowledge wrote:
Is it documented anywhere?


We've said it on the forums many times but I don't know that it's in the actual docs.

Please consider this a plea for you to put a few paragraphs about this into the documentation.

Leaving aside any particular thing I might be trying to do, could you explain how I would find a trustable value for the status of any particular switch etc?

[matt (support)]

Leaving aside any particular thing I might be trying to do, could you explain how I would find a trustable value for the status of any particular switch etc?

If they are INSTEON devices, then Indigo's internal state representation (via "on state of device XYZ") should reflect their current state. The cases where it won't: Indigo was not running when the device was turned on/off, or there is a power line signal problem or a signal collision. For the latter, the preferred solution is to work on getting your INSTEON network more reliable (find signal problems and isolate them). You can issue a status request command to have Indigo poll out the current state, but note if there is a signal problem then they might fail as well. Because the status request happens asynchronously, if you then need your script to read out the current value then you'll want to add a delay after the status request, to give the interface thread time to fulfill the request.

Ack. I've finally figured out some of this with a load of forum digging. If only Jay had added a couple of words to one of his above posts, or if I had spotted any reference to what he was talking about, it would all have been much clearer much sooner.
In this case the words that I needed to hear were 'device state changed' in respect of the type of trigger. Sigh. Because I didn't 'get' that part, I missed understanding all the rest of it and used up a lot of time unnecessarily.

So, I changed to using a 'trigger on device state change' for each of the two bedside lights, with the action for both being to execute an applescript action group that ORs the on state of both devices. That seems to work nicely and only requires two triggers and one action group.

Now I've just got to track down which damn action keeps saying' tweedle' at me. What seemed a clever debugging action now just seems stupidly annoying...

[jay (support)]

I don't believe device state changed triggers are a particularly hidden feature of Indigo given that it's the default trigger type when creating a new one...

… but confusion can hide the nose on your own face. Even one as big as mine