Lately I have been working on splitting the service into one part that runs inside the webserver an one part that runs in the background for signal processing. All these changes together with some patches needed in python make it necessary to make a new image soon. This will include database backup and restore as well as system update from the admin interface (you should never need to log in over ssh - in fact I want this to work for people that don't understand anything in this blog post). Unfortunately I am working much more right now so I don't have much time to work on this.
20/9/2012 03:23:00 am

Interesting project, I´m looking forward to follow this.. :-)

22/9/2012 07:11:58 pm

I have been working with similar project since fall 2011 with TuxRail and Dreamplug SBC-computers which are similar to RasperryPi except that they don't have video output and TuxRail does not even have audio output either. Dreamplug is also more complete product that RasperryPi, but is of course more expensive and without the video.

I have a project, which I think has a good structure:

1) event service with a tcp socket server and Telldus API to connect into local Telldus daemon (telldusd). This server shares all events to all clients connected to it and also accepts events not only from the telldus API callback, but also from those client sockets. Everything that is received is sent to all other clients. The service also self-provides local sunrise and sunset events, but these should not be there as this is better to have as a client implementation which would provide this event to all others.This was implemented with effective c-language .

2) event listener client. This is also implemented with c-language and connects to configured event server as tcp socket client. It does not do mostly anything by itself, except that it tries to maintain the connection and enters a reconnection loop if the connection gets lost for some reason. It just waits for events from the socket and when it has received event completely it just calls a specific shell script that user can modify. The event is passed as a parameter(s) to this script. This is very flexible way for "superusers" to add any reaction to any event which is possible from a script. Just as an example. when a certain outdoor PIR-detector reports movement and it is not nighttime, one scripts asks mocp to play doorbell.wav (Mocp = music on console). On other occasion when the burglar alarm is on and movement was detected, the mocp is instructed to play wolfgrowl.mp3 or dogbarg.mp3

3) If I wish to create a new event into system or command any of the RF-devices, I just use netcat (nc) in any computer to send an event or command to the event server.

4) I also have apache2 and php installed. The simplest way to allow web pages to interact is to create a /usr/lib/cgi-bin/control.cgi (just example) that outputs a web page and allows URL-parameters to turn on or off some RF devices. The script would use for example tdtool to do the action. An another way is that php-based page just opens a socket connection to the event server and passes either command or event to the system.

In addition one of the most important parts of my system is the timestamped event log. This is created by the listener client so it can be made distributed and collected everywhere. The web pages allow me to view this log (most recent events) just below the controls that I have.

24/9/2012 06:13:04 am

Thanks for sharing. My idea here is that there should not be any need to writable bash script at least not if you just want to do simple things like "if alarm is on and time is after sunset and motion detector is trigger turn on some lamps, turn them off 30 min later and turn on tv".
I also focus on Pyrhon for more rapid development than C but that's just my preferences on language.

24/9/2012 04:45:23 pm

Yes I understand your point and its a great goal to achieve!

My model just presents one possible foundation layer below the automation logic and user interface layers, including the easy-to-use user interface and wizards.

One of my favorite mottos is that Good software is easy to install and use by typical target audience user, but Great software additionally also provides tools, interfaces and configurability for advanced target audience users who most often want to integrate something that was often out of scope for the original developers.

5/9/2013 04:20:26 pm

Good read


Leave a Reply.