Problem with ASCII interface and button press events

[Doug Meredith]

When using the ASCII interface I am correctly notified of single, double, and triple click events on HomeSeer brand switches. However, if the same event occurs twice in a row, the notification is only sent for the first one. For example, after I am notified of a double click of the off button, I will NEVER again get notified of subsequent double clicks of the off button, until some other click event has occurred. Is this a bug in the ASCII interface? Is there something I can change, either in general settings, or on the device? Any help would be appreciated.

[AllHailJ]

is the behavior with the black arrow checked? This might cause the behavior you are seeing.

[Doug Meredith]

That option was indeed checked. I unchecked it, and unfortunately there was no change in the behavior. Thanks for the idea, none the less.

[jmaddox]

Are you using one of these two event triggers in the attached image? Both could account for the behavior you're seeing. The correct trigger to use is 'value set to' when triggering on central scenes.

Aside from that, posting the event may help with trouble shooting.

[Doug Meredith]

Are you using one of these two event triggers in the attached image?

The problem I'm having doesn't involve HomeSeer events, it is through the ASCII interface.

[AllHailJ]

I went to the A2Z-link manual and I found this

"Notification of updates

If a device changes status, a notification is sent over the open port. The format is:

DC,REF,NEWVAL,OLDVAL

For example, the device with reference # 576 changes from 0 to 1:

DC,576,1,0"

A repeat action would not cause a change in status (and if the programmer only checked a change in status not change in timestamp) only a change in the timestamp. I wonder if this is by "design" and this is what is preventing the notification?

[Doug Meredith]

It may well be by design, but, if so, I'd have to guess it was a design that didn't consider anything like scene notifications. The behavior makes sense if the device represents the dim value of a light, but it's obviously not the correct behavior for a device that only deals with events.

If anyone has a workaround for this, or a suggestion of an alliterative approach other than the ASCII interface, I'd love to hear it.

[Guest]

I use the same thing that jmaddox uses, the event trigger being if the switch has "its value set to" action. I do not see your problem at all. Does your ASCII interface eventually resolve to running a HS Event? If so, one thing to check is if the event itself will have set the setting to prevent being re-run for a certain length of time.

[Doug Meredith]

What I'm trying to do doesn't involve HomeSeer events at all. The ASCII Control Interface is core HomeSeer functionality that permits an application to connect to HomeSeer using TCP sockets. You can read about it here: http://help.homeseer.com/help/ASCII-...asic_functions

[AllHailJ]

I did have a thought that might help although it is a pain in the a$$ to execute. When you receive notification that the device has triggered then set the device to a status that you do not use. You might have to add a blank status to the device. This will always force the device to record the change.

Outline of process would be:

Receive Status update.
If changed to status acknowledged exit routine
Else Save Values Needed.
Set to Status Acknowledged.
Perform anything additional you need.

Hope this helps

[Doug Meredith]

I did have a thought that might help although it is a pain in the a$$ to execute. When you receive notification that the device has triggered then set the device to a status that you do not use. You might have to add a blank status to the device. This will always force the device to record the change.

Great idea. The ASCII Control Interface doesn't seem to support updating device status, but I'll see if I can do that using the JSON API.

[Guest]

Great idea. The ASCII Control Interface doesn't seem to support updating device status, but I'll see if I can do that using the JSON API.

Yeah I would also like to be able to change status device with Hs telnet

[sparkman]

How about running a HS event that is triggered by the same scene command occurring and its action is to reset the switch scene value back after a few seconds?

[Doug Meredith]

How about running a HS event that is triggered by the same scene command occurring and its action is to reset the switch scene value back after a few seconds?

That should work, but would be a last resort for me, as it would mean creating an event for every switch. Very tedious and error prone.