Menu
Index

Contact
Atom Feed
Comments Atom Feed

Similar Articles

2014-04-19 09:42
PICing up 433MHz Signals for OSS Home Automation - Part 6
2014-06-08 10:30
PICing up 433MHz Signals for OSS Home Automation - Part 7
2014-06-21 22:10
PICing up 433MHz Signals for OSS Home Automation - Part 8
2014-07-21 18:37
PICing up 433MHz Signals for OSS Home Automation - Part 9
2013-12-15 10:34
PICing up 433MHz Signals for OSS Home Automation - Part 1

Recent Articles

2019-07-28 16:35
git http with Nginx via Flask wsgi application (git4nginx)
2018-05-15 16:48
Raspberry Pi Camera, IR Lights and more
2017-04-23 14:21
Raspberry Pi SD Card Test
2017-04-07 10:54
DNS Firewall (blackhole malicious, like Pi-hole) with bind9
2017-03-28 13:07
Kubernetes to learn Part 4

Glen Pitt-Pladdy :: Blog

PICing up 433MHz Signals for OSS Home Automation - Part 5

Progress has been slow with being back in the office, or on site in Scotland depending on the day. That said, I've made some significant if slow progress.

Hardware

The PIC based USB to 433MHz transceiver is now boxed up:

USB-GPIO12 (PIC) based 433MHz Interface USB

LEDs show if the receiver or transmitter are enabled, data down the USB and if the interface is uninitialized (ie. the host OS hasn't got hold of the serial interface):

USB-GPIO12 (PIC) based 433MHz Interface LEDs

I built antennae as per the Elector document on 433MHz Antennae which seem to do a good job - I get all devices clearly where I didn't without these antennae. I found some rigid PVC tubing at a building & hardware supplier and put the antennae inside that to protect it, making the whole thing quite robust.

USB-GPIO12 (PIC) based 433MHz Interface internals

Host Software

The host server software is starting to look like more than the rough hack it started life as.

Plug-in Metadata

It quickly became obvious that I needed to provide configuration information for auto-configuration within each plug-in. As a result each plugin now registers a lot more than just hooks to process data. There is now a comprehensive set of metadata provided which allows the master process to work out everything from sensible de-glitch times to providing usage info in the CLI.

Hook Scripts

It's now got hook scripts that are executed on any data received from a sensor device with an environment reflecting the data received. This allows a lot of extensibility like being able to log or push data such as temperatures, humidity, power usage etc. into other systems (eg. plot in Cacti).

These also allow of arbitrary logic to be configured between devices (eg. it humidity drops below a certain level turn on humidifiers... well perhaps water level and pumps would be more appropriate with the floods we have around here currently).

Network Service

It's now got a minimal network command-line service running which is ultimately to goal. This means that all the output from sensor devices gets sent to anything connected to the network port and commands to send to actor devices can be sent.

Additionally I've created a tiny command-line client that can be used to send commands within shell scripts. This can be used along with the arbitrary logic scripting aspect so that data from sensor devices can be used to operate other devices. It's also possible to use this for scheduling with CRON jobs.

The bit I now need is to be able to do authentication to ensure that only allowed clients can use the service.

Bugs

There are a few things that I am trying to get down to the bottom of but possibly relate to the PIC USB stack and/or host Linux USB stack.

One of the more annoying ones is that I fork the process to execute hook scripts but that intermittently results in the PIC immediately going into idle mode. It's not clear if it's spontaneously resetting or something similar, but without an explicit command from the host I'm not seeing any way that the firmware could do this under normal circumstances. It's also not clear what is triggering this as I wouldn't have expected forking a process to affect it in this way.

The other one that's less of a problem is that if the host server process is restarted enough times the PIC decides that it transmission is suspended.... no idea how this is happening, but it does render things inoperable until it's disconnected and reconnected to USB.