A question for the home automation programmers amoung us, if you have a rfxcom receiver for example you often get several triggers for a contact or sensor within a few seconds, what is a good mechanism to only get one devicechange/trigger in your program without blocking changes which should be there (clicking on a device on/off button in your program for example within a few seconds), which thresholds/mechanisms do you guys use?
I need to implement this in my program, I now get 5 emails in a few seconds noteing that I have receive postal mail on my doormat
You can check for device changes only. For example; if the curent device status is Off and you receive an On cmd you have a device change and will set the new status to On. The next On messages do not trigger a device change because the device status is already On.
You can also ignore multiple received messages by checking the last change time. If the last change time is less than 1 second AND the device cmd is equal to the device status ignore the received message.
The last option is the one I use with the last received time as a parameter. So for my doorbell event I have like 10 seconds delay untill the next can come in.
For every receiver I have I filter all the duplicate messages that follow each other within X seconds (2 seconds). If you don't do this your application or Homeseer can be quite busy with doing duplicate (useless) things.
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by Bwired</i>
<br />The last option is the one I use with the last received time as a parameter. So for my doorbell event I have like 10 seconds delay untill the next can come in.
For every receiver I have I filter all the duplicate messages that follow each other within X seconds (2 seconds). If you don't do this your application or Homeseer can be quite busy with doing duplicate (useless) things.<hr height="1" noshade id="quote"></font id="quote"></blockquote id="quote">yeah, my app and system still can manage with about 35 sensors. But I have to add some functionality still triggering more events upon device changes is one of them, which can become quite stressful for the system (and myself )
Do you have a config param for this X secs value for each device, or does each device calls a separate vb script where you handle this?
Or maybe hardcoded?
In my application I have a grid, which is being updated from all incoming sensors etc. All the params are set there, and there can be a list of events hanging on a device-record. I can also hang a buch of scripts which execute after change. Check http://www.bwired.nl/How_bwiredhcsnew.asp its from a while back but you get the picture
Ok thanks for the info.
I have already looked at your 'how pages'
This is how my devices screen looks like, I have stolen some good interface gui ideas, hope you don't mind...
No of course I don't mind, it's a good thing to help and I didn't made up everything myself either
Looks good, with which programming language you made this.
It's Linux only and it has an fantastic graphical programming environment among other things... great support via mailinglists.
I'm going to release my first version (alpha) soon, so maybe I can use a small space on your forum under software/linux for discussions
It started as a proof of concept to see if Gambas provided the needed routines, and to see if i'm capable to write code to control and read all my devices, it worked so well that i'm using it everyday now for controlling and monitoring my house...
Hi Ron,
If it's working as good as it looks
I think you will make a lot of Linux users happy.
I will check those links, as you know I am a Windows guy but sick and tired about the direction Microsoft & Windows is going now. I like Lean & Mean and thats definitely not Windows at the moment:-)
I can make a separate forum under software with you as Moderator, no problem, lets see how it goes.
regards Pieter
Everything my RFXCOM receiver receives is being decoded only to determine the protocol (X10, OS, Visonic) and address involved with the packet. Next thing that happens is that the packet is 'sent' to the device that corresponds to those 2 parameters. From there the packet is decoded further and the device takes out all relevant info from the packet, updates data-, event- and status-tables and so on. So i don't filter at interface-level (there where the packets are received) but at device-level. Most devices do check on identical packets and ignore duplicates, there's only 1 exception to that: my KAKU doorbell. It has some sort of timer that will ignore anything coming in after the first packet that arrived.
Robert,
For a lot of devices like Oregon, Rfxcom and Visonic sensors its better to filter the duplicates right at interface level. For example Oregon Scientific sends the same package 3 or more times, if you receive the first one you can directly skip all the other packages so they don't have to be processed any further. So your resources are not bothered anymore with those extra packages. I think this is best option, and you benefit even more ones you get a lot of sensors. For other devices like PLCbus It can be possible, I have no experience with those.
I know, it would probably save me CPU cycles. OTOH, i like to keep the logic where it should be; let me explain.
My RFXCOM receiver code only knows how to identify packets (protocol, address) but no further 'intelligence' is built into it.
I mean, the RFXCOM receiver receives, nothing more (sorry Bert [:I]), nothing less. That makes the code that makes the RFXCOM receiver work, easy to understand, maintain and modify when needed. So for example, checksums are done at device-level. That's the proper place, right? Just look at all the OS devices and their checksums.
Furthermore, the way my app is made, i have classes like THWR288, SAIX, SD90, MCT302 and so on. For all physically different devices i make a dedicated class.
That is where i put the code specific to that class. Most of the times it's not more than 5-10 lines of code, really! 95% of all things are handled by the parent class of all device-specific classes i have. This way i can keep it simple (and stupid [:)]).
And it does have some advantages to...just an example.
I have an ELRO wireless switch laying around. When i push it, it is supposed to trigger an event that switches off all lights in the living and garden.
I only use the 'on'-side (or -button) of this switch. If i would discard packets at interface-level, the event would not be triggered again 24 hours later...cause the packet would be filtered.
Yes, pushing the off-button once would solve it but i forget to do that, every morning.[xx(]
Nice discussion [:)]
I Understand, it has more to do with the way your software is setup, and yes it does not matter so much. With filtering the package I mean within a few seconds. It takes like 5 lines of code to filter them regardless which device they are coming from. So if you receive more of the same packages after each other and within X seconds filter it, otherwise put it through. In this case your Elro solution still works.
