Recent Posts71
Decider / New Feature - TORX Time Definitions
« Last post by Cube on September 26, 2015, 06:18:53 PM »Decider 0.5.0-459 marks a key new feature, one which has long been on my wish list. It gives Decider a number of new capabilities for scheduling things to happen, and it also incorporated an idea I've been meaning to implement for years. In order to appreciate the Torx Timer, you have to understand the history. For that, let me begin with a story.
When I was a little boy, my father and I used to collect stuff from commercial and industrial bins around the city. You simply would not believe some of the items that people threw out in those days, and my collection quickly grew to include all manner of security systems, built-in vacuum cleaner parts, intercom systems, cameras, sensors, motors, switches, speakers, transformers, tools, amplifiers, sprinklers, light fixtures, humidifiers (both ultrasonic and steam) - the list was nearly without end. Some things needed minor repair, but most worked as we found them. One such find was a brand new Tork 7102 mechanical timer. It had never even been powered up, nor had any of the knockouts been punched. It was brand new, in it's box.
Anyone who's ever managed a building has seen or set one of these things, knows of their simplicity and reliability. I put a cord and a plug on mine so that I could use it to control the operation of things around the house, and it's probably still in one of my dad's sheds to this day. I'd even reckon that were I to find it, it would probably still work. You control the load by screwing little Pegs onto a wheel with markings indicating time of day within a 24 hour period. White pegs switch the load on, black pegs switch the load off. A special copper wheel (to the bottom-left of the main wheel) allows you to install or remove additional pegs to specify days of week for operation. A simple description of what it could do might be written like this: Turn the load on at 7:00 PM and off at 6:00 AM, Monday through Friday.
Up until now, all of the time definitions within Venturii have been stateful. In other words, they have a start and an end point in time. Day of Week has a Value Interpreter that becomes a 1 at midnight on any day that is selected in it's configuration, and becomes a 0 at midnight on any days NOT in it's configuration. Hour periods have a start and end time, as do Month of Year, Absolute Time Periods, etc. While excellent at making sure plants are watered for 30 minutes every morning at 4:00 on Mondays, Thursdays and Saturdays, these time definitions do not allow you to configure something that happens every ten minutes. They also require something like a comparison to attach commands to them. The comparison evaluates the value of the time period, and then executes different commands based on whether that time period is true or not. I have an amplifier for my whole home audio system that I'd like to make sure gets turned off every day. Everyone in the house knows how to turn it on when they want to listen to music, but no one remembers to turn it off. I don't want to turn it on automatically, but I would like to turn it off automatically as it draws half an amp (~60 watts) when idle. I could set up an hour period and a comparison with a command that executes only when the time period becomes true to turn the amp off at 11:00 pm every night, but it feels a bit clumsy.
Perhaps the biggest motivation for creating the Torx timer has, like all good features, been invented to solve a problem. We have this requirement at work to sign in and out every day by sending an email to the office, telling them where you're working for the day so they know where to start looking if you don't make it home. It's a good idea in theory, however if you haven't signed in by 9:00 am, and haven't signed out by 4:45 pm, the office staff send an email to your supervisor tattling on you for your negligence. The problem I've had with this system is that I work 9-5 or later, sometimes 6 or 7. What's worse is that I'm often IN the office, around a glass wall from the people tasked with policing the sign in board. In latter weeks they've grown accustomed to walking around that corner and seeing if I'm still at the office, but still sign me out regardless of whether I'm done working for the day or not. That system is completely broken. What I've been doing is using Venturii to send my sign in and out emails to the office, which has saved me no end of grief (except one time when I forgot to inhibit it on a long weekend. Oops! haha) Even so, I wondered if someone might notice that my messages to sign in and out came at [exactly] the same time, every day.
A summary of the features of the new Torx Timer system in Decider is this:
The Random Deviation functionality has been an idea I've been toying with for a long time, which may see itself emerge in some of the other time definition constructs as well. It solves what I call the Home Alone problem with traditional timers. If you remember the movie, the burglars had memorized when the lights in each house turned on, confirming the vacancies of those premises. By incorporating a random deviation to the set time of any given Peg, you can obtain a more unpredictable result while still maintaining the convenience of automation. Random Deviation has two parameters, number of seconds before the peg time and number of seconds after the peg time to randomly deviate. This allows you to constrain the behavior to something like "Turn on the lights AFTER 6:00 PM but before 7:00 PM." The CONDI integration allow each peg's command execution to require meeting a set of conditions and clear a list of inhibitors, giving you the ability to constrain operation to certain days of the week, times during the year, or only if any other Value Interpreter is a certain value or not a certain value. The repeat feature provides an easy way to do things at regular intervals like resetting counters or sending status emails.
As with many of the features I've come up with, I can't wait to see how other people find interesting uses for them that I had never even considered.
When I was a little boy, my father and I used to collect stuff from commercial and industrial bins around the city. You simply would not believe some of the items that people threw out in those days, and my collection quickly grew to include all manner of security systems, built-in vacuum cleaner parts, intercom systems, cameras, sensors, motors, switches, speakers, transformers, tools, amplifiers, sprinklers, light fixtures, humidifiers (both ultrasonic and steam) - the list was nearly without end. Some things needed minor repair, but most worked as we found them. One such find was a brand new Tork 7102 mechanical timer. It had never even been powered up, nor had any of the knockouts been punched. It was brand new, in it's box.
Anyone who's ever managed a building has seen or set one of these things, knows of their simplicity and reliability. I put a cord and a plug on mine so that I could use it to control the operation of things around the house, and it's probably still in one of my dad's sheds to this day. I'd even reckon that were I to find it, it would probably still work. You control the load by screwing little Pegs onto a wheel with markings indicating time of day within a 24 hour period. White pegs switch the load on, black pegs switch the load off. A special copper wheel (to the bottom-left of the main wheel) allows you to install or remove additional pegs to specify days of week for operation. A simple description of what it could do might be written like this: Turn the load on at 7:00 PM and off at 6:00 AM, Monday through Friday.
Up until now, all of the time definitions within Venturii have been stateful. In other words, they have a start and an end point in time. Day of Week has a Value Interpreter that becomes a 1 at midnight on any day that is selected in it's configuration, and becomes a 0 at midnight on any days NOT in it's configuration. Hour periods have a start and end time, as do Month of Year, Absolute Time Periods, etc. While excellent at making sure plants are watered for 30 minutes every morning at 4:00 on Mondays, Thursdays and Saturdays, these time definitions do not allow you to configure something that happens every ten minutes. They also require something like a comparison to attach commands to them. The comparison evaluates the value of the time period, and then executes different commands based on whether that time period is true or not. I have an amplifier for my whole home audio system that I'd like to make sure gets turned off every day. Everyone in the house knows how to turn it on when they want to listen to music, but no one remembers to turn it off. I don't want to turn it on automatically, but I would like to turn it off automatically as it draws half an amp (~60 watts) when idle. I could set up an hour period and a comparison with a command that executes only when the time period becomes true to turn the amp off at 11:00 pm every night, but it feels a bit clumsy.
Perhaps the biggest motivation for creating the Torx timer has, like all good features, been invented to solve a problem. We have this requirement at work to sign in and out every day by sending an email to the office, telling them where you're working for the day so they know where to start looking if you don't make it home. It's a good idea in theory, however if you haven't signed in by 9:00 am, and haven't signed out by 4:45 pm, the office staff send an email to your supervisor tattling on you for your negligence. The problem I've had with this system is that I work 9-5 or later, sometimes 6 or 7. What's worse is that I'm often IN the office, around a glass wall from the people tasked with policing the sign in board. In latter weeks they've grown accustomed to walking around that corner and seeing if I'm still at the office, but still sign me out regardless of whether I'm done working for the day or not. That system is completely broken. What I've been doing is using Venturii to send my sign in and out emails to the office, which has saved me no end of grief (except one time when I forgot to inhibit it on a long weekend. Oops! haha) Even so, I wondered if someone might notice that my messages to sign in and out came at [exactly] the same time, every day.
A summary of the features of the new Torx Timer system in Decider is this:
- 24-hour Timing Cycle, perfect for things that need to happen at certain times each day.
- A single timer can have an unlimited number of Pegs.
- Each Peg has a fixed time, with microsecond resolution.
- Each Peg can have a repeat interval, and repeat limit, allowing you to execute that peg's commands at recurring intervals in a single construct.
- Each Peg can randomly deviate up to a set number of seconds before and/or after the set time, solving the Home Alone problem.
- Each Peg can have an unlimited number of commands to execute.
- Each Peg uses the Condition / Inhibitor system for allowing / blocking execution based on other Value Interpreter values.
- The commands in each peg can be manually executed at the command prompt or from within other objects in Decider.
The Random Deviation functionality has been an idea I've been toying with for a long time, which may see itself emerge in some of the other time definition constructs as well. It solves what I call the Home Alone problem with traditional timers. If you remember the movie, the burglars had memorized when the lights in each house turned on, confirming the vacancies of those premises. By incorporating a random deviation to the set time of any given Peg, you can obtain a more unpredictable result while still maintaining the convenience of automation. Random Deviation has two parameters, number of seconds before the peg time and number of seconds after the peg time to randomly deviate. This allows you to constrain the behavior to something like "Turn on the lights AFTER 6:00 PM but before 7:00 PM." The CONDI integration allow each peg's command execution to require meeting a set of conditions and clear a list of inhibitors, giving you the ability to constrain operation to certain days of the week, times during the year, or only if any other Value Interpreter is a certain value or not a certain value. The repeat feature provides an easy way to do things at regular intervals like resetting counters or sending status emails.
As with many of the features I've come up with, I can't wait to see how other people find interesting uses for them that I had never even considered.
Suddenly it dawned on me, the only way it would be getting such a low reading of distance was if the sound pulse emitting from the transmitter was actually traveling through the PCB and being picked up physically by the receiver. A theory began to form, I was testing the sensor long before the hot glue had solidified. What if, as the hot glue got cooler, it also became harder and therefore made the whole assembly more rigid, allowing physical transmission of sound better? It would explain why it took a few minutes of decent operation for the sensor to begin to get sporadic readings, and once it was fully hardened - remain consistent at returning 2-3 uS times...