Weird result running UPB events with different manufacturers

[verrick]

I have a weird issue that I haven't figured out yet - hoping somebody can point me in the right direction, cause it's driving my wife and I nuts.

I recently added onto my house and installed about 12 new UPB lighting circuits. My existing UPB circuits, about 15 of them, are all Leviton. Since Leviton no longer manufactures those, I decided to go with Simply Automated UPB switches, dimmers, and controllers for the new addition. Individually, they all work fine and I can control them all through Homeseer.

I created events to turn my outside lights on and off at sunset and sunrise. My existing Leviton lights work perfectly when the event is run, however my Simply automated dimmers do not. Here's were I get thrown - I can go into Homeseer and turn them on, and I can go into Homeseer and manually run the event. That all works. The lights never turn on with the event automatically running.

My system:
Most recent version of HS3 Pro running on Hometroller SEL.
I have a phase coupler in my main panel, not the sub panel. New lights are are off the main panel, existing lights are sub panel.
SNR is fine to all lights after installing the phase coupler in the main panel.

Any help is appreciated.

[Uncle Michael]

Welcome to the Board.

Can you post a screen shot of one of the events that turns on the lights when run manually, but not when run with it's trigger?
When you say manually, I assume you mean using the run (>) button on the event page, correct?
Are there conditions on the event? Running an event with the run button ignores the conditions.
Also, to clarify, you have a phase coupler, not a split-phase repeater, correct? (SA switches are not fully compatible with a repeater, but I wouldn't expect the behavior you are describing.)

[verrick]

Thanks for the reply.

When I say manually, you are correct. I hit the run (>) and the event happens as expected. When it is run automagically at sunset, homeseer registers them as on, but alas, they are not. I can manually run the event, or these days, I pull up the new HS Mobile app on my iphone and go to the dashboard I created just for these problem events.

The coupler is phase coupler from SA - Simply Automated UPB Wired-In Inverting Phase Coupler. It took care of a number of noise problems and solved a bunch of other issues with my installation.

Screen shots follow: I grabbed the event, and the logs which show it triggering at the appropriate time. The two highlighted events are the ones in question. The Front lights (existing) function as expected for the event, but the Garage lights do not. The other odd thing is that the corresponding off at sunrise event does work. I've been scratching my head for months.

[Uncle Michael]

I had an event that had similar behavior, but it was unpredictable. Sometimes it worked and sometimes one of the lights reported as on in HS, but did not actually turn on.
The lights that do not turn on are actually a SA plug-in module that controls a low voltage transformer.
I have tried two approaches to remedy the problem, which I think is caused by the the SA devices being less capable in their 2-way communication abilities.
The first is to introduce a delay before issuing the command to the SA module. That helped, but it was still not 100%.
The second is to poll the lights that do not come on reliably. Then if the poll shows them to be off, HS sends another on command.



The event above turns on the Back Patio N lights after a delay of 10 seconds, then triggers an event to poll the lights after a delay of 1 minute.
After a further delay of an additional minute it runs another event (below) that checks the poll results and issues another ON command if the lights reported that they were off. (I have to do something similar for off as well.)
After all that, I'm getting excellent reliability.
It's only SA devices that have given me trouble, but I have a repeater and was prepared for the possibility I'd need to compensate.

[verrick]

I tried something like your event, and I seem to have had some success. I'm going see what happens tonight before I declare it fixed. In any case, here's the new events I created.

I really appreciate the help.

[Uncle Michael]

Please post back after you do your real world test.
FWIW, I think it is more efficient to reserve the Wait action for short pauses. (I restrict it to less than 10 seconds.) The delayed event and delayed device action are better for longer periods because they create temporary new events rather than tie up the thread. You just have to remember that, unlike the Wait, they only delay the action they are applied to, and actions further down in the list will not be delayed like they are after a wait.

[verrick]

There is success! I noticed yesterday morning that my lights were off, but HS was still registering them as on. So I added the UPB monitoring event to the "Off at sunset" routine and monitored them last night and this morning. Everything worked as expected.

Thank you also for the suggestion of using a delay. Here's what my final event looked like.

[Uncle Michael]

Great. I hear that SA is under new management, but do not know where they stand with products. I'm hoping they implement new communication algorithms, though.

[tenholde]

Is there a way to poll a device for its actual status? There are times when UPBspud is not accurately reflecting the status of an actual device. For instance, if you manually dim a light from a wall switch that does not have the capability of reporting its device's load after a manual change (PCS KPLD7), then UPBspud plugin has no way of knowing how dim the light is, so it reflects the HS device as OFF, even though it is on (dim).

[Uncle Michael]

Is there a way to poll a device for its actual status? There are times when UPBspud is not accurately reflecting the status of an actual device.

I haven't used it for dim level, but I do use it to assure that my SA switches have executed their commands. It should be in the list of event actions.