Using Scheduler with General Logic

[mcockerell]

Hi Karam,

Here's what I am trying to achieve:

1) Outside lights to come on each evening as it gets dark and go off at a set time - currently this is handled via on/off times and an external light level sensor.
2) Outside lights to stay on past the set time if we are 'out late' - we live on an unlit lane so it is useful to be able drive in and unlock the door safely.
I am using one of the QRI buttons to toggle the 'out late' status - when we come home pressing the button toggles the status and kills the outside lights.
3) Outside lights to come on each weekday morning at a set time and go off as it gets light - we often leave before it is light and I want the lights on as we drive off.

I have considered using the PIR in the hall to automate this a bit more, perhaps detecting when someone has come home, but I can think of scenarios where this wouldn't work (for instance, when I am coming home late but everyone else is already in) and also the dog sets the hall PIR off fairly regularly.

Very happy to consider alternative ideas.

Martin

[Viv]

Hi Karam,

Here's what I am trying to achieve:

1) Outside lights to come on each evening as it gets dark and go off at a set time - currently this is handled via on/off times and an external light level sensor.
2) Outside lights to stay on past the set time if we are 'out late' - we live on an unlit lane so it is useful to be able drive in and unlock the door safely.
I am using one of the QRI buttons to toggle the 'out late' status - when we come home pressing the button toggles the status and kills the outside lights.
3) Outside lights to come on each weekday morning at a set time and go off as it gets light - we often leave before it is light and I want the lights on as we drive off.

I have considered using the PIR in the hall to automate this a bit more, perhaps detecting when someone has come home, but I can think of scenarios where this wouldn't work (for instance, when I am coming home late but everyone else is already in) and also the dog sets the hall PIR off fairly regularly.

Very happy to consider alternative ideas.

Martin

Hi Martin,

I must confess to having spent quite a bit of time on this trying to find a complete solution and in doing so abandoned many ideas. However I believe I have a solution that can be broken down to the 3 logic requirements your have outlined.

So each logic requirement is addressed seperately...

1/ This logic is achieved by the lights normal operating methods. The outside light is configured to
Operating Mode = At Lighting up time and dark to turn on , lighting off time to turn off.

The turn off time will be the normal evening off time. Ensure the ‘Auto set override to default…’ is checked and that the default is ‘None’.


2/ This logic is achieved by switching the lights operating mode between

‘At lighting up time and dark to turn on, lighting off time to turn off’
And
‘Use Light level dark to turn on, bright to turn off’.

Using a General Logic object a T-Type flip-flop is configured to create the ‘Out Late’ mode. Its output trigger behavior is ‘On Change’. Its output is connected to Two NOT gates inputs. The T-Type flip-flop has its clock input triggered by a suitable button. The LED of the button can be connected to the output of the T-type flip-flop to indicate you are in ‘out late’ mode.

The first NOT gate is configured to have an ‘Output trigger behavior’ of ‘To False’. This is used for the light to operate in normal mode (e.g as in logic requirement 1 above). The output of the gate is set to send a ‘Value’ of 6 to the outside lights operating mode.

The second NOT gate is configured to have an Output trigger behavior’ of ‘To True’. That is ‘Out Late’ mode. The output of the gate is set to send a ‘Value’ of 8 to the outside lights operating mode. That is to not be time dependant but only dark.

Pressing the button will cause the ‘Out Late’ mode to turn on (press again to turn off). The light will not come on in either mode unless its dark. The light will stay on if it is in ‘Out late’ mode – that is it will not turn off in late evening as in normal mode.

3/ This is achieved by using a second light object. You can use a legacy relay object to create a virtual light (one that is not network enabled). This light is configured to use the outside light level as normal. Configure this light to operate as you want in the morning. Turning on and off at suitable times and using the dark state.

This lights ‘Set State (Output)’ is connected to the Outside lights ‘Follow state (input)’. What this is doing is creating a whole new light behavior at another time. As this virtual light turns on in early morning it sends a message to the real outside light and causes it to turn on. When this virtual light turns off it will also turn the real outside light off.

Viv.

[mcockerell]

Hi Viv,

Many thanks for the very detailed response - it's certainly better than the complex General Logic that I was trying to use.

Part 1 is the base case that I had originally implemented, and works perfectly.

Part 2 is a good way of implementing the required override capability and works well - I did have to swap the mode values on the NOT gates so that a '1' from the T-Type sets the override (operating mode 8) and lights the LED on the QBI.

Part 3 is a neat way to provide a second operating period for lighting (which I was unaware of). The only thing I need to add to this is some 'weekday only' logic. I was using two weekday event triggers to turn an SR Type on and off outside the required operating period; I seem to be able to connect the SR output to a light level input on the second light object - would this achieve the desired gating effect?

Many thanks,
Martin

[Viv]

Hi Viv,

The only thing I need to add to this is some 'weekday only' logic.

Hi Martin,

I also had much more complicated methods initially!!!.

For weekday only logic I would create two Event Scheduler events.

1. On a 'Week Day' I would trigger the Virtual Light to 'Enable' at some suitable time in the morning which is before its Lighting up Time.
2. On the 'Week End' I would trigger the Virtual Light to 'Disable at time as above.

This is the lights 'Overall Master Control' state as seen in the Lights behaviour menu top left.

So in 1 it will trigger the light Monday through Friday to ensure its Enabled and similarly on Saturday and Sunday to ensure its disabled.


Viv.

[mcockerell]

OK, during experimentation I found a couple of issues with the method that I was using for the virtual light:

1) The virtual light wasn't turning off when the light level went above the dark threshold if using operating mode 6.
2) Disabling the virtual light doesn't turn the light off if it is already on.

So I've adopted a simpler approach:

The first Event Scheduler event sets the operation mode to '8' on a weekday - this turns the the light on at the event time if it is dark and turns it off under light sensor control.

The second Event Scheduler event sets the operation mode to '7' every day of the week at a later time in the morning - this effectively prevents the light coming on at weekends.

It took me a while to find out that 'Manual Control' is operation mode '7' - although this is displayed when the cursor hovers over the option, the same value is displayed for a couple of other modes as well. I eventually found it in the help for 'Light Connections' - but not all the modes are listed there.

Anyway, hopefully I now have what I want - many thanks for your earlier help, it was the trigger for these latest ideas.

Martin

[mcockerell]

Ok, it's back to the drawing board.

Yesterday morning the virtual light didn't come on with the first event at 7:15; with the clock change it was already light enough - good!
Instead, it came on at 8:30 when the second event switched the operation mode from 'Dark on/Light off' to 'Manual Control only' - not what as wanted.

I may be missing something, but this doesn't seem to make sense to me - I guess I'm going to have to implement something smarter.
The ideal would be if the 'Dark and operating time' mode worked at both ends of the day but this doesn't seem to be the case.

Any thoughts Viv?

Regards,
Martin

[Viv]

Ok, it's back to the drawing board.

Yesterday morning the virtual light didn't come on with the first event at 7:15; with the clock change it was already light enough - good!
Instead, it came on at 8:30 when the second event switched the operation mode from 'Dark on/Light off' to 'Manual Control only' - not what as wanted.

I may be missing something, but this doesn't seem to make sense to me - I guess I'm going to have to implement something smarter.
The ideal would be if the 'Dark and operating time' mode worked at both ends of the day but this doesn't seem to be the case.

Any thoughts Viv?

Regards,
Martin

If your switching to manual control from Dark On, Bright off then it does leave it in what ever state it changed from if the new mode does not create some logical change. Manual control does not evaluate a condition and set the light. Hence it remains as it was operating.

You are correct that the if the light is on and then the master control is not enabled the light remains on. This is not desirable and will be corrected in next update (26.4.3).

I would recommend you update to Cortex 26 if you are not already on it.

I would then suggest a refinement of the virtual light control to leave it in mode 7 (using light level only) and use the scheduler to master enable the light at the required time in the morning and disable it at the required time. This way if its dark at on time it will come on, if not it will stay off. Then it will be guaranteed to go off at scheduler off time (after the update).

Viv.

[mcockerell]

Ok, so I upgraded to V26 over the weekend and applied 26.4.3 earlier today - with the correction to the 'disable' master control this now seems to provide the functionality that I am looking for if I leave the virtual light in mode 8.

Thank you Viv.

[mikesrv]

Hi m****erell,

If you want to have all your required function, use PIC16F84 plus operational amplifier for the sensing of light. This way, you can have all the functions you want because you can just program it in the PIC16F84 and it will automatically do the job. Just be sure to use also an op amp for sensitivity.

[Karam]

Mike,

First of all, welcome to the forum

The IDRATEK hardware already has processors reading light level sensors and you could in principle write some low level code to do something specific, but the system is not just a collection of individual devices doing their own thing - it has moved on from that type of concept to something more integrated where there is often much interaction between various parts. So the solution to a more specific requirement can sometimes be a bit more complicated to initially work out because it is generally useful for it to tie in with the system's wider strategies rather than being an island on its own. On the other hand many interactive features which would quickly get complicated to achieve using individualy programmed devices become trivial.

BTW I see the anti-profanity filter has been somewhat over zealous