Using cloud cover for lighting?

[wkearney99]

Ok, I set up the other event for test calling.



However, it also fires the speaking and ignores the conditional. The current value is 32. So shouldn't it just silently do nothing, as in, not trip further to the speaking action?

Or am I still running afoul of the event being called (and conditionals being ignored) because I'm calling the event and not letting the event see the value being set on it's own?

HS3 programming is... odd sometimes.

[wkearney99]

It'd sure be convenient of the Speak command allowed passing variables into it...

[randy]

Ok, I set up the other event for test calling.



However, it also fires the speaking and ignores the conditional. The current value is 32. So shouldn't it just silently do nothing, as in, not trip further to the speaking action?

Or am I still running afoul of the event being called (and conditionals being ignored) because I'm calling the event and not letting the event see the value being set on it's own?

HS3 programming is... odd sometimes.

Click on the res airplane on the action to get advanced options, then choose the option to "Run Only if other Event Conditions are TRUE" as I wrote above, then the conditions will be evaluated. Read this post for further clarification. Triggers are never honored, because a trigger is in almost every case a "moment in time" and would not be true at the moment an event is manually run. In your event the trigger is true only at the moment the value changes and is greater than 60, it would not trigger again until the value is "set" again. In the case of your event you could also add a condition that the luminance is above 60 for testing in addition to the trigger for the same, then you could confirm by manually testing. Under normal event operation the condition would have to be true if the trigger were true.

[randy]

It'd sure be convenient of the Speak command allowed passing variables into it...

You can use all HS3 replacement variables in speak actions. Read here.

[randy]

Yes, you were spot-on, I had the Media Controller plug-in active with the proxy enabled. I've disabled the plug-in, I'll check that later.

That is usually the cause.

[wkearney99]

You can use all HS3 replacement variables in speak actions. Read here.

Which confuses me somewhat because I'm unclear on where the $$D... parameter is determined.

For testing I've set up a virtual device with a slider, as shown below.

[wkearney99]

So. from my above device, using the reference ID 1931, here's what I get from the speaker:
(CODE wrapped to disabled the DANGED SMILEY EMOTICONS!)

Cloud cover $$DVA:(1931): gets me "Cloud cover minus 1"
Cloud cover $$DVC:(1931): gets me "Cloud cover minus 1"
Cloud cover $$DVR:(1931): gets me "Cloud cover dollar dollar DVR nineteen thirty one"
Cloud cover $$DSR:(1931): gets me "Cloud cover dollar dollar DSR nineteen thirty one"
Cloud cover $$DSA:(1931): gets me "Cloud cover device not found"
Cloud cover $$DTA:(1931): gets me "Cloud cover device not found"
Cloud cover $$DTR:(1931): gets me "Cloud cover dollar dollar DTR nineteen thirty one"

Ok, so I've tried all the variable replacements listed in the help link, what gives?

[zwolfpack]

Try the DxR ones without the parenthesis, i.e.$$DSR:1931:

[randy]

So. from my above device, using the reference ID 1931, here's what I get from the speaker:
(CODE wrapped to disabled the DANGED SMILEY EMOTICONS!)

Cloud cover $$DVA:(1931): gets me "Cloud cover minus 1"
Cloud cover $$DVC:(1931): gets me "Cloud cover minus 1"
Cloud cover $$DVR:(1931): gets me "Cloud cover dollar dollar DVR nineteen thirty one"
Cloud cover $$DSR:(1931): gets me "Cloud cover dollar dollar DSR nineteen thirty one"
Cloud cover $$DSA:(1931): gets me "Cloud cover device not found"
Cloud cover $$DTA:(1931): gets me "Cloud cover device not found"
Cloud cover $$DTR:(1931): gets me "Cloud cover dollar dollar DTR nineteen thirty one"

Ok, so I've tried all the variable replacements listed in the help link, what gives?

As David wrote, skip the parentheses. If you look at your configuration tab for the device it has no address or code, therefore $$DVA, $$DVC, $$DSA and $$DTA are invalid. The remaining variables all use the Reference ID of the device, which is 1931. $$DTR:1931: will normally return the string value, but will return the Status if it is blank. Since your device has no string value, $$DSR:1931: and $$DTR:1931: will return 74% as that is the Status. $$DVR:1931: will return the value, which is always numeric, in this case it would return 74.

If the speech proxy cannot pronounce the % symbol, then use “cloud cover $$DVR:1931: percent”.

My hourly time announcement uses

“$$DTR:8850:  <silence msec='500'/> it is $$time  <silence msec='500'/> $$DVR:3695:degrees  <silence msec='500'/> $$DVR:3699:percent humidity” 

8850 is the Reference ID of my greeting device 3695 is outside temperature and 3699 is humidity. The greeting device’s string is populated with Good Morning, Good Afternoon or Good Evening by Events.

It speaks Good Evening, it is 2:00 PM, 55 degrees, 25 percent humidity”.

[wkearney99]

Try the DxR ones without the parenthesis, i.e.$$DSR:1931:

Ok, "Cloud cover $$DVR:1931:" properly responded with the current value. And it spoke 'percent' since the Suffix: value contained it. Take that out and you get just the number spoken (and I'm guessing might affect other number/string situations, or not?)

I also used "Cloud cover $$DTA:Rachio1-Current-Cloud-Cover:" and that properly grabs the value from the UltraRachio plug-in, since it has that as the "Technology Address" for the device.

[wkearney99]

Thank you, really, HS3's approach to things really seems opaque a lot of the time.

I hear you regarding the "moment in time" aspect of events. For scheduled times that's not hard to understand. But for actions based on a value being 'set' it's not quite as simple.

How do I "know" when a value is going to be something HS is going to poll or otherwise know about being changed?

[randy]

Thank you, really, HS3's approach to things really seems opaque a lot of the time.

I hear you regarding the "moment in time" aspect of events. For scheduled times that's not hard to understand. But for actions based on a value being 'set' it's not quite as simple.

How do I "know" when a value is going to be something HS is going to poll or otherwise know about being changed?

HomeSeer “knows” when any HomeSeer device is set or changed. All HomeSeer devices are virtual devices, some control physical devices through plug-ins such as Z-Wave, Insteon and X-10. Others may be updated by a plug-in such as BLLan or UltraMon3. These plug-ins will set or change the HS devices bases when a monitored IP dvice is online or offline. Every plug-in is likely to affect one or more HS devices. When a physical device is changed the HS virtual device is updated by a variety of methods. For example Z-Wave plus devices will send an update to the HS device when it is changed. Older Z-Wave devices may need polling to update the HS device. Regardless of the method of updating the HS device, HS will “know” at the moment the HS device is updated. Counters, timers and the system clock are also essentially virtual devices, so HS “knows” when they are updated. When used as Triggers, HS devices will trigger at the exact time they are updated or “set”.

The methodology of updating the HS device determines whether it is “set” or not, if the value isn’t changed. Generally a device is always “set” when it’s value is changed by a plug-in. It is always “set” when changed by an Event. It is possible to change a value of a device without setting it with a scripting call.

It is really about understanding what plug-in “owns” the HS device and its methodology of updating it.

[wkearney99]

It is really about understanding what plug-in “owns” the HS device and its methodology of updating it.

Makes sense. The next step is figuring that out for each of them (this UltraRachio plug-in being one of them).

My goal is being reliable and predictable, without unexpected/unintended consequences. There's a thread I read here recently that mentioned outside lights and annoying/surprising/irritating the wife. I'm always keenly focused on not setting myself up for that failure.

Lighting being sort of like motion where it might change during specific hours, in either direction and at any time. So knowing the update interval can help avoid the system being stupid about managing itself. As in, if I know the value is actively updating I might not want to have actions take place too quickly/often. Especially for something like window shades. No point in cranking them up/down just for passing clouds, but sustained cloud cover, sure that'd potentially be worth making adjustments. For lighting, however, I might ok with making more frequent adjustments to dimming levels (within reason, of course).

My thought is:

• It's after sunrise (which really means about an hour after sunrise as the sun has not yet risen enough to be providing effective nature light (low angle)
• The cloud cover is beyond a certain point (higher value is darker)
• Bring the motion sensors online and see if anyone's there
• If so adjust the lighting to offset the cloud cover
• Repeat this as necessary "during the day" (a timeframe ending about an hour before sunset due to low light angle)
• Once the 'during the day' point has passed, stop checking cloud cover and allow motion control to resume supervision of lights.

I've got the EasyTriggers plug-in to handle the 'daylight hours' window of time.
I'm going to start with using this plug-in's 'Current Cloud Cover' value for luminance.
I have Lutron Ra2 lighting and motion sensors and they're quite good at determining occupancy/vacancy but not necessarily as effect at luminance,
So now it's down to constructing proper events in HS3.

Lutron does make some pretty nifty daylight harvesting systems but those don't directly integrate with Ra2.

[bdickhaus]

My thought is:

• It's after sunrise (which really means about an hour after sunrise as the sun has not yet risen enough to be providing effective nature light (low angle)
• The cloud cover is beyond a certain point (higher value is darker)
• Bring the motion sensors online and see if anyone's there
• If so adjust the lighting to offset the cloud cover
• Repeat this as necessary "during the day" (a timeframe ending about an hour before sunset due to low light angle)
• Once the 'during the day' point has passed, stop checking cloud cover and allow motion control to resume supervision of lights.

I do something similar. All of my lights are controlled by motion using a combination of events and scripts. I monitor one luminance sensor and based on ranges of values, set a virtual device to "not cloudy", "cloudy" or "very cloudy". If it is "very cloudy" and "during the day", some lights are turned on when motion is detected. I am not currently using the "cloudy" state for anything.

[wkearney99]

I've been using a single event to speak whenever the Cloud Cover data changes. Is this the right way to be checking?

If Outside UltraRachio3 Plugin Rachio1 Current Cloud Cover has a value that just changed.

or should I use "just had its value set or changed" instead?

Because using 'just changed' isn't resulting in the speak command being run very often. Granted, I don't know "how often" the plug-in is updating (this was my crude attempt to find out).