Set Variable with OH2 Astro Binding

ptmuldoon · January 22, 2017, 8:42pm

In OH1, I had a rule to dim lights for my Kodi setup during night time hours only.

Pretty sure this incorrect. But would be the correct syntax for the below?

var SunSetTime = astro:sun:local:set#start

Later in the rule, I am comparing the current time to Sunset with

if(now.isAfter(SunSet_Time)) {   
	xxx more code
    	}

KjetilA · January 22, 2017, 8:48pm

Provided you have a thing defined as “astro:sun:local” you can use the following type of rules to control you stuff:

rule "Sunset event"
when
	Channel "astro:sun:local:set#event" triggered START
then
        // Do something
end

ptmuldoon · January 22, 2017, 8:55pm

Yes,

I am already turning on some lights at sunset with that type of rule setup, but think this is slight different.

What I’m doing here is comparing the current time to the sunset time, and then if it is dark do something.

So not sure how to set the variable for the sunset time with the Astro2 Binding.

this is more of the complete rule, and It may be correct now, but will find out later when I get test it some.

when
	Item FF_Sensor_GarageDoorStatus changed
then
	var SunSetTime = (astro_sun_local_set_start.state as DateTimeType).calendar.timeInMillis
 
	if (FF_Sensor_GarageDoorStatus.state==ON) {
		sendNotification("myemail@xxxx.com", "Garage Door was just opened.")
    
	    // If garage was opened after sunset, turn on lights
    	if(now.isAfter(SunSet_Time)) {   
			sendCommand(FF_Light_GarageSwitch, ON)
			sendCommand(FF_Light_FamilyCF, ON)
    	}
		
		}
end

KjetilA · January 22, 2017, 9:17pm

OK. I see…

In this case I would suggest to create a new ‘virtual’ item (i.e. one that is not connected to any binding) of type Switch called something along the lines of “Daylight”. Then you create two rules that trigger on Sunrise and Sunset (as suggested above) and flip the Daylight switch ON and OFF accordingly.

Now you have a very simple way of doing checks in other rules:

  if (Daylight.state == OFF) {
    // Do something
  }

This is very much simpler than doing checks on time and date which rates pretty high on the list of the most asked question in this forum

ptmuldoon · January 22, 2017, 9:35pm

I’m trying to slowly work away from Virtual Items or any Items file if possible. I believe that is the the future of where OH is going.

But I agree with you and think can work off the Checking the Daylight with existing Astro2 items.

I think this should work

// If garage was opened dark when, turn on lights
    	if(astro_sun_local_daylight_end.state==ON) {   
xxxx more code

I believe OH2 sends the ON command to the End daylight state with the above.

Although I don’t know when the OFF statement is sent.

KjetilA · January 22, 2017, 9:53pm

There is definitely a debate as to where OH is going in terms of using text files or UI+database for configuration of items (and other stuff), but I don’t think text files will disappear anytime soon - if ever (I hope not!!).

Anyway, the point is that what I termed a virtual item is not going to disappear regardless of the above. A “virtual item” sounds a bit mysterious - and maybe I should not use that term. In essence this is just the most basic of items, i.e. an item that has no association to any binding. Using such items as part of you home automation setup is essential - at least in my book. As I do all my work in text files I cannot tell you how to create such an item in Paper UI, but I am sure it is possible.

I am pretty sure that will not work - unless you have defined ‘astro_sun_local_daylight_end’ as an item yourself and have another set of rules that switch this ON and OFF.

The Astro 2 binding will only generate events using the concept I described in my first post.

rlkoshak · January 24, 2017, 4:29pm

I’ll point you to the Time of Day Design Pattern

This should be if(now.isAfter((SunSet_Time.state as DateTimeType).calendar.timeInMillis){

I think you are mistaken in this belief. Items are and will remain the primary way your HA system is represented and manipulated inside OH including Rules, Persistence, and Sitemaps. Even the new Experimental Rules engines is based on Items.

Secondly, Virtual Items are key to implementing state machines which are a very well proven approach to implementing many if not most automation tasks. @KjetilA’s solution and the Time of Day Design pattern are nothing more than a simple state machine that is driven by time.

The Astro 2 binding no longer sends ON/OFF commands to Items. It only supports setting DateTime Items or Trigger Events.[quote=“KjetilA, post:6, topic:20937”]
“virtual item” sounds a bit mysterious - and maybe I should not use that term.
[/quote]

I prefer “unbound Item”, as in an Item that is not bound to a binding nor linked to a channel.

You just react the Item and do not link it to any channel.

Furthermore, except as triggering events, Things are not accessible within Rules. However, if you have Simple Mode enabled, OH automatically creates an Item for each Thing. that might be what @ptmuldoon is accessing here. In which case astro_sun_local_daylight is a DateTime Item, not a Switch and this Item gets populated once every midnight, not at the time that it occurs. You need to use the triggering events as illustrated by @KjetilA.

ptmuldoon · January 24, 2017, 7:54pm

To close the loop on this.

Yes, I do have Simple Mode Enabled and was more curious than anything in seeing how much I can do without creating any separate Astro items. So, in working with the default Astro items, I have the following 4 rules to turn On and Off some outside lights.

Note: My light items are set with an xxx.items file. I have not tried moving those to the simple item names yet.

I wonder now though that if I could potentially simplify the below into 1 rule with a case statement. Think that is possible without any custom items?

// Outside Light Rules

rule "Outside Sunset Lights On at Dusk"
when
	Channel 'astro:sun:local:astroDusk#event' triggered START 
then
	sendCommand(FF_Light_FrontPorch, ON)
	sendCommand(FF_Light_OutSideGarage, ON)
end

rule "Outside Sunset Lights Off at 1:30am"
when
	Time cron "0 30 01 ? * * "
then
	sendCommand(FF_Light_FrontPorch, OFF)
	sendCommand(FF_Light_OutSideGarage, OFF)
end


// Lights come on again ~ 1 1/2 hours before Sunrise using astroDawn and civilDawn

rule "Outside Lights astroDawn START"
when
	Channel 'astro:sun:local:astroDawn#event' triggered START
then
	sendCommand(FF_Light_FrontPorch, ON)
	sendCommand(FF_Light_OutSideGarage, ON)
end


rule "Outside Lights OFF at civlDawn START"
when
	Channel 'astro:sun:local:civilDawn#event' triggered START 
then
	sendCommand(FF_Light_FrontPorch, OFF)
	sendCommand(FF_Light_OutSideGarage, OFF)
end

rlkoshak · January 24, 2017, 9:21pm

It’s possible but it would not necessarily be any simpler than what you have here. If you look at the rule that calculates the vTimeOfDay in that design pattern I posted above, you will see what you need to do to calculate what time period you are in.

Since this is a calculation that is highly likely to be needed throughout your automation (e.g. my lights, door open reminders, alerts when doors open and no one is home, and what mechanism is used to issue alerts all behave differently based on the value of vTimeOfDay) it makes a lot of sense to do this calculation once and store the result in an unbound Item which can be used everywhere and for any reason. And by separating it you can add new times of day or adjust when they start and end without needing to go to every rule that cares about time of day and change its triggers and/or conditionals.

Failing that you could write a lambda that returns the current state but you will have to put all the Rules that care about time of day into the same file.