Insteon special triggers

[claude]

I have an event on a switch with an Insteon special trigger of: transmits an On command.

Separately, I have an HS action that dims that same switch after an interval.

It appears that the HS action triggers the first event. I was expecting that only an action from the light would trigger the event.

Questions:
1- What is the expected behavior in the above scenario?
2- what constitutes 'transmits an On command' ? What if the light was at 100%, then sent a dim to 50% ? Is there any documentation on the specifics of the special triggers?

[mnsandler]

my weak documentation on the triggers is located here
http://board.homeseer.com/showthread.php?t=154291#3

Transmits an On is CMD1=11 within the msg

but i think this might be a side effect of the ProcessAcks flag we created. do you still have that set to True in the ini. Change it to False. no need to restart...its read dynamically. I could remove the Trigger call in the process ack routine if you you determine this is the cause but that may not be desirable either

[claude]

Mark,

I think I should first change ProcessAcks to False and see how the events behave.

In the meantime, trying to understand your reply "... Transmits an On is CMD1=11 within the msg ...", my question is: if I send from HS an On command, you are saying the switch returns an Ack message with 11 in cmd1 and that's the basis for the plugin processing the trigger? Could the plugin only process triggers based on original messages and not Ack's?
[edit] As I understand it, on sending a device a direct message, the receiving device will respond by returning the same message flipping the to/from addresses, and setting flag bits 5-7 to 001 (Ack) or 101 (Nak) as opposed to 000 for initiating a direct message. So if flag bits 5-7 = 000 then process trigger, if not then ignore. Easy for me to say...

If the plugin can't differentiate receiving a direct message from receiving an Ack to a message it sent then I'm cooked: what Im trying to detect is a humain intervention at the switch. If the light has been On for a while, I want the event to dim it and then some minutes later, if no one does an On or start ramp (nobody is that room), I'll shut it off.

[claude]

Hi Mark,

Have you given any thoughts to my last post?

I set ProcessAcks=False but still see anomalies in my events.

I need to first make sure I understand the logic behind the conditions I'm using.

I know this is not Plugin territory, but can you help answer the following?

On the condition "has been ON for exactly":
- When does the timer get reset? What action does so?
- If, for example, a light has been on for 1 hour and HS sends it a Dim 50%, will the timer reset on the Dim action or will it continue?
- Would the timer start/restart regardless of whether HS sends an ON to the switch or someone turns on the switch locally?

On the condition "has been ON for at least":
- What happens to this event when the time is reached? Does the timer get reset? What prevents the event from activating every minute after the threshold has been reached?

Now back to Plugin territory, following up on my last post.

Insteon special triggers, for example "[device] transmits an ON or Start ramp command" get activated it seems by either a local intervention at the switch or HS/plugin sending a command to that switch. Sending a command to the switch activates the trigger because, as I understand it, the plugin checks for cmd1=11, which appears in an Ack message back from the switch. I think that's what you were saying in your reply "... I could remove the Trigger call in the process ack routine ...".

Any chance of brewing up a version where the plugin does not process a trigger on an Ack? Do you see obvious side effects?

[mnsandler]

Claude,

if you set ProcessAcks=False and still experience the same results, then there is nothing i can do. I can't change the baseline plugin at this point. the initial ACK msg is not processed as a trigger, its the initial direct command the fires the trigger in this case.

ACK msgs are only used to acknowledge my direct cmds but are otherwise ignored.

The two conditions you referenced fire based on the hs device last updated date/time stamp which changes from the plugin. "On for exactly" fires only once. "On for at least" will fire every minute until the condition is false.

what you need to do is add some virtual devices and set some states in your event actions. You can use these states to either prevent an event from firing or make sure the event does fire when the state is right. A virtual device might be set to ON when you initially set the dim. then you can check that virtual device in other event conditions before proceeding.

hope this helps.

[claude]

... the initial ACK msg is not processed as a trigger, its the initial direct command the fires the trigger in this case.

ACK msgs are only used to acknowledge my direct cmds but are otherwise ignored ...

Sorry, I got confused by your prior post, where you mention "I could remove the Trigger call in the process ack routine". I took that as the plugin does activate the trigger when processing an ACK. Did I read that wrong?

... The two conditions you referenced fire based on the hs device last updated date/time stamp which changes from the plugin ...

So, regardless of who initiates the change, local switch intervention or plugin sending a command, the plugin will effect a change of the time stamp.

Is it also true to say that any type of action against a device will change its date/time stamp? Whatever the device's state, sending it a command that changes/sets its value will modify its time stamp.

For example, the light was set to full ON at 1:00 o'clock and at 1:15 I send it a Dim 50% command : will the time stamp now show 1:15?

What if instead I sent it another full ON at 1:15; what's the time stamp then?

Can you also confirm this: when testing a device for being ON, On means being at the same specific value (not 0 obviously).

[mnsandler]

claude,

lets forget about code changes and that discussion, i don't think it will help.

I'll let you test the various scenarios you mentioned; me trying to answer them will only cause more confusion.

please remember with any insteon dimmer, ON does not mean 100% for everyone. If you have a default on-level set then ON is that value (whatever you set in the plugin)

please investigate virtual devices as part of your solution.

[claude]

... lets forget about code changes and that discussion, i don't think it will help ...

Only trying to reconcile your 2 statements

... I'll let you test the various scenarios you mentioned; me trying to answer them will only cause more confusion ...

Yep, that's one way of doing it. An easier way would be for me to be able to find the information in the documentation (plugin and HS)

... please investigate virtual devices as part of your solution ...

I've been using flags from day 1.

I'm a bit frustrated, but hey, it's ok, I'm on my own