As described last year, I own a La Crosse Weather Station to which I added several additional (TX2 & TX3) sensors.
Trouble is, as the technology is phased out in favor of a 868Mhz based one, these sensors are harder to come by and are also a bit pricey.
Chance
Unexpectedly, I noticed a news about a firmware update of the RFXtrx433E from RFXCom talking about a well known chinese online shop's version of a sensor. Indeed, I was able to become the owner of a "433MHz Wireless Weather Station Digital Thermometer Humidity Sensor" for the very lucky price of US$8.88 all included.
Protocol
These sensors are apparently compatible with the Alecto WS1700 ones. The protocol was decoded and published on the Pilight wiki and forums.
It looked simple enough so I decided to modify my Arduino/Digispark script in order to decode it as well.
Pulses
Yet there was a catch! La Crosse TX3 protocol uses a variation of pulses on the high level with timing on the low level being almost identical (and ignored by my decoder's implementation).
For the WS1700... it's the opposite! Hence only a succession of 37 identical 500µS pulses was the only thing seen.
Also, the signal finishes by a "very long" (~9200µS) Low and, as usual with this kind of device, the whole sequence is repeated several times.
If we detect at least 8 continous short high pulses, then we know it's not a TX3 sensor but probably a Alecto compatible one and therefore from now on only low pulses will be read.
The strategy is then to wait for very long pulse, read the full signal, checking the header (~1900µS ~3800µS ~1900µS ~3800µS), and at last validating with the last pulse which should be again a very long one.
The new algorithm is represented in the following flowchart:
Reporting
The Id, which is randomly generated when inserting new batteries -- same as TX3 -- is ignored... I will assume that nobody else has a compatible sensors around and use the channel number instead.
Channel (there is a physical switch to select it) is coded 00=CH1, 01=CH2, 02=CH3. This will be my sensor ID because it is fixed. But to avoid any clash, I add 1001 so CH1=1001, CH2=1002, CH3=1003.
Battery will be reported as OK or KO.
There is a small button at the back of the sensor to force the emission. Apart for tests, it is not that useful and we can ignore the bit reporting this.
Temperature is in 10th of degrees Celcius so value is divided by 10. Negative values are taken care of as well.
Humidity is straight out the signal received except if not read properly (0%).
Not everything in The Project is wireless, the Gas and Electricity sensors are (at least for the moment) wired, the Internet connection and, last but not least, the power supply, are too.
This is where the WAF (i.e. Wife acceptance factor) enters. Wikipedia has an extensive explanation about the concept. (Actually, it could also have been called Valentine Acceptance Factor on this day!)
We are not talking about expensive stuff (it's build rather on the cheap, isn't it?) here but having to cope with bizarre (and wired) apparatus in the flat.
The best way I found, on top of having a very accepting and forgiving spouse, was to enlist her and use her newly acquired illumination skills to decorate the wooden box.
When a Raspberry Pi -- which doesn't have a hardware clock -- boots, the time can be set thanks to NTP. It usually works well enough to be totally transparent.
Trouble usually starts if there is a power cut. By the time the Raspberry is up and running, the modem-router is usually still booting/synchronising with the ISP and no clock is set. Programmes start using the Epoch, i.e. 1st of January 1970!
The best hardware workaround is certainly to use an external clock like "real" computers. Maxim's DS1307 has been a reference for years but is both 5V and not reputed for its accuracy.
Raspberry Pi's I²C being in 3.3V, I tried to use a cheap RTC Clock using a DS3231 also from Maxim.
There are loads of webpages explaining how to setup Linux to use this hardware clock and if at first everything worked fine, I then started to notice some problems.
Symptoms
With Raspbian, the main problem was that after a while, I couldn't SSH to the server anymore. The Raspberry being headless, it wasn't easy to guess what was going on but it turned out this behaviour was the result of the disappearance of the root directory.
And this was itself caused by an I/O error on the SD Card. It seems that the 2 main reasons for this to happen are:
Problem with the power supply
Faulty (or incompatible) SD Card
The power supply was bought from RS with the first Raspberry and is rated 1.5A. Swapping with the second one (from Farnell this time) rated 2A didn't change anything. I then decided to use the other SD Card with a brand new Arch Linux on it.
At first, no failure but then 2 problems also showed up:
Loads of log lines related to mmcblk or
An extremely slow Raspberry Pi with an non-explicable high load (~ 6)
Solution?
I was a bit lost but I found a forum message which gave me a very important clue:
Second: disconnected the Dallas RTC DS3231, as it was pulling the 3.3v line too low, along with the DHT22 sensor.
Another test
Since I use a Level Shifter (3.3V/5V) on the I²C bus, it was very easy to move the DS3231 IC to the 5V side and try this theory. Unfortunately, this didn't make any difference.
Since I removed the module, the Raspberry Pi is no longer slow and load is now ~0.05.
Software workaround
With Arch Linux, I now force the application to start only when the network setup has completed (this includes proper NTP initialisation) by adding in the [Unit] section the following lines:
I was very pleased when I discovered last month that Jean-Claude Wippler was thinking about restarting his blog. I was an avid reader of his adventures in the world of Electronics, Home Automation, Computing, etc...
And if I still haven't experimented with the Jeenodes, I could one day find myself in need of the RF variant to use with 868Mhz IT+ sensors, etc...
I was also glad to find PCA9635 already mounted as the chip only exists in SMD form. At the time, I was experimenting with RGB LEDs and debating PCA9635 vs WS2811.
If I can't compete with Mr Wippler in terms of knowledge, skills, style and lab hardware, his blog was certainly one of the sources of inspiration for mine.
