Your task is to design an automatic lighting control system using primitive logic blocks in Niagara 4 (N4). The system should control lighting based on occupancy and ambient light levels, ensuring energy efficiency and user comfort.
This challenge is intended to test your ability to interpret functional specifications and implement them using Niagara’s primitive logic blocks. It’s a simulation of how you might translate a consultant’s specifications into a working control strategy.
Instructions:
Setup:
Inputs:
OccupancySensor (boolean): Indicates room occupancy (true for occupied, false for unoccupied).
AmbientLightLevel (numeric): Measures the current light level in lux.
TimeSchedule (boolean): Active during building operating hours.
Excuse the newbie questions, but I’m trying be exhaustive in staying true to the SSO.
In the Basic Operations For Occupied mode it indicates “When OccupancySensor is true AND TimeSchedule is active”. Can I assume this means “OR” instead of “AND” as it seems likely that the intent is to have lighting active when either OccupancySensor senses people or the TimeSchedule is in the normal business hours? Or is there something I’m missing?
Understood. I was thinking lights on all the time during business hours with sensor override during afterhours. This is much better to save energy. This makes better sense. Thank you.
This is my submission for the Lux Lighting Control Challenge. It has 3 parts:
Override Logic
Occupancy Logic
Light Level Logic
The Override logic uses a One-Shot Override Button in conjunction with the Boolean Schedule to reset that logic when the Next time Schedule turns to active (Uses a One-Shot from the schedule to combine with Override One-Shot to trigger a Boolean Switch) The state of the switch is fed by the True state of whichever Trigger is used.
The occupancy logic uses uses a direct connection to the output in combination with aNumeric Delay, fed from the Occupancy Timeout input, which is then fed to the Boolean Delay Block, which keeps the lights on for a configural delay time.
The Light Level Logic Uses a Deadband which is added and subtract from the Light Level Setpoint. This is fed through a Boolean Latch to basically the final output that is combined with the Override and Occupancy Logic to determine the state of the Boolean Writable Lighting Control Output.
These Challenges are so helpful for me to learn. I’m getting addicted!
I think I get a better education with your challenges than doing a five-day cert class. And I see how much you guys do just on this platform (can’t imagine this is all on top of your daily jobs), so just whenever you get the chance. Absolutely loving this!!!
I’m learning when I see a lull in activity on DDC-talk, you guys are wicked busy! I’m spending my time doing deeper learning of N4, but when someone gets a chance to try to break my logic, would be curious if I stayed on the rails with this on. No time rush, just when its easiest! Cheers to all the moderators on this site.
Hi mate, still on my list . We are in the middle of a heat wave and the Christmas rush! So you’re spot on, haha! Hopefully, someone else has a spare moment. Otherwise, usually between Christmas and New Year’s, there isn’t much going on, and I’ll take a look then .
Sorry its taken a while for this one, busiest time of year for us in Australia.
It was a good effort. The only thing that really didn’t work was the override. The override was meant to work for any condition, regardless what was going on.
This is more just of a nitpicky thing, but I don’t think the numeric delay is needed. It can just be set to for a time and no need to delay that I don’t think, unless I read the instructions incorrectly.
You’ll see my comment in the picture but perhaps you were trying to link the output of the schedule rather than the input. You can read what that’s for in the screenshot.
Lastly,
Clocks in the latch blocks are garbage, they don’t work really in the way you would truly want. Just link directly to the latch action to get the desired result. Add a delay in there for cornercase scenarios. I added comments in the picture
Thanks for looking at this sir! I’ll have to look into that override logic to see where I went off into the weeds! Yeah, with the delay logic, I was trying to accomplish the criteria:
OccupancyTimeout (numeric): Time in minutes before lights turn off after the room becomes unoccupied (e.g., 15 minutes).
When I get a chance, I’ll go back in to see what I can do to make that override logic work better.
This is pure gold for me to have you guys critiquing my stuff so that I can modify and learn! Thank you again!
That is high praise coming from you, sir. I look in on the other categories that you guys are involved in to see what seem to be limitless possibilities with N4, and it sets my sights high. That you reach back down the ladder is…treasured!
Lights require 3 things to turn on: Schedule active, Occupancy active, and Light level to be less than the setpoint. Override is controlled by the Xor: When given a true, it holds the true until another true is given. Can be reset by refiring override or the schedule goes active while the override is active.
This challenge is intended to test your ability to interpret functional specifications and implement them using Niagara’s primitive logic blocks. It’s a simulation of how you might translate a consultant’s specifications into a working control strategy.
This challenge is intended to test your ability to interpret functional specifications and implement them using Niagara’s primitive logic blocks. It’s a simulation of how you might translate a consultant’s specifications into a working control strategy.As always, the implementation may differ in the real world.
As always, the implementation may differ in the real world.
I have not forgotten about you!
. We are in the middle of a heat wave and the Christmas rush! So you’re spot on, haha! Hopefully, someone else has a spare moment. Otherwise, usually between Christmas and New Year’s, there isn’t much going on, and I’ll take a look then 
.
