upstatemike
Senior Member
Working on a simple project this week where I need to control 16 relays to follow the state of 16 wired inputs. I was going to do this in my Elk M1 but found I only had 8 relays left. I don't have physical space to add another relay board to the Elk easily so I decided I would use 8 relays and 8 Stargate relays for my project. It was in the process of setting this up that I was reminded how much easier it is to accomplish things in Stargate than in any modern automation system.
In Stargate I set up a simple event for each relay:
If Input1 is ON
Then Relay1 ON
Else Relay1 OFF
That is it, nothing else required. By contrast for the Elk relays I had to use two events for each relay:
Whenever Input1 becomes not secure
Then turn Relay1 ON
Whenever Input1 becomes secure
Then Relay1 OFF
Then I had some situations where I needed 2 inputs to control 1 relay... again simple in Stargate:
If Input1 is ON
OR Input2 is ON
Then Relay1 ON
Else Relay1 OFF
But In Elk I have to now use three events:
Whenever Input1 becomes not secure
OR Input2 becomes not secure
Then turn Relay1 ON
Whenever Input1 becomes secure
AND Input2 is secure
Then Relay1 OFF
Whenever Input2 becomes secure
AND Input1 is secure
Then Relay1 OFF
As things get more complex the gap between clean Stargate logic and messy "trigger based" logic just keeps getting bigger and bigger. I have some events in Stargate that evalute nested logic 4 or 5 layers deep. I can't even imagine how many individual trigger based events would be required to replicate those!
The other thing I was reminded of is just how fast a Stargate is. According to the statistics page it is currently taking 2 milliseconds for each Stargate cycle. That means every 2 milliseconds it checks the state of all 80 inputs and all 40 outputs and evaluates all the logic in every event and fires off any resulting actions. I never worry that the system will miss a transition since it will recheck all of the inputs a hundred or more times and correct itself before I could even begin to percieve a delay.
Unfortunately the inputs and outputs on my Stargate are now maxed out so I can't move more stuff onto it. Maybe I'll start hunting for a used unit and run 2 Stargates instead of wasting time on the modern but much lower performance alternatives being offered these days.
In Stargate I set up a simple event for each relay:
If Input1 is ON
Then Relay1 ON
Else Relay1 OFF
That is it, nothing else required. By contrast for the Elk relays I had to use two events for each relay:
Whenever Input1 becomes not secure
Then turn Relay1 ON
Whenever Input1 becomes secure
Then Relay1 OFF
Then I had some situations where I needed 2 inputs to control 1 relay... again simple in Stargate:
If Input1 is ON
OR Input2 is ON
Then Relay1 ON
Else Relay1 OFF
But In Elk I have to now use three events:
Whenever Input1 becomes not secure
OR Input2 becomes not secure
Then turn Relay1 ON
Whenever Input1 becomes secure
AND Input2 is secure
Then Relay1 OFF
Whenever Input2 becomes secure
AND Input1 is secure
Then Relay1 OFF
As things get more complex the gap between clean Stargate logic and messy "trigger based" logic just keeps getting bigger and bigger. I have some events in Stargate that evalute nested logic 4 or 5 layers deep. I can't even imagine how many individual trigger based events would be required to replicate those!
The other thing I was reminded of is just how fast a Stargate is. According to the statistics page it is currently taking 2 milliseconds for each Stargate cycle. That means every 2 milliseconds it checks the state of all 80 inputs and all 40 outputs and evaluates all the logic in every event and fires off any resulting actions. I never worry that the system will miss a transition since it will recheck all of the inputs a hundred or more times and correct itself before I could even begin to percieve a delay.
Unfortunately the inputs and outputs on my Stargate are now maxed out so I can't move more stuff onto it. Maybe I'll start hunting for a used unit and run 2 Stargates instead of wasting time on the modern but much lower performance alternatives being offered these days.