In order to complete and replace the old TX2/TX3 sensors, I found some new ones using a similar technology (still RF 433 Mhz). These are the TFA ref 30.3208.02 and can be bought with a very handy external housing (ref 98.1114.02):
They also come in sets of 3 sensors + a "climate monitor".
(Edit 27/07/2022: PEARL Diffusion's rebranded NX-6185-675 sensors (sold for Infactory FWS-1000 station) are fully compatible too).
Technical info
The sensors themselves measure and display the temperature as well as the relative humidity. Up to 8 sensors can be used at the same time and their address is set (thus fixed) using microswitches, which is a huge improvement over the previous models (either IDs changing at reboot or limited to 3).
The communication protocol seems to be known as F007TH (from Ambient Weather) and presents 2 singular characteristics:
Various implementations exists and can be found on the Internet; last but not least my version, adaption of one of the different sources and for which I use on a ESP8266 as a gateway to the MQTT broker.
My current ecosystem as a diagram
So far the described ecosystem can be represented as:
Honestly I can’t believe it has been 33 months since the last blog entry…
… time certainly flies…
Loads of changes happened in the meantime, and among them a new addition to the family, which means even less time to tinker. We also moved from a flat to a house with a garden. This certainly opens some new opportunities in term of home automation but also poses some challenges.
There is no gas in the house so I will no longer talk about Gazpar, the gas meter. Linky, the electricity one, is about 20 meters away from the house. This prevents using the old Wifi solution. The house is relatively large and has known multiple extensions during its history. One aisle seems totally impermeable to the highest frequencies (eg 2.4Ghz+); for Wifi, it needs its own router and Zigbee would probably need the same treatment.
In the next few entries I intend to describe the current setup as well as the multitude of (mainly temperature) sensors used with the matching code to decode the different protocols.
See you next time, and hopefully not in 33 months ;-)
On the Gazpar and most (gas and water) meters, there a pulse for every rotation of the second wheel from the right. In this case, every 10 litres of gas (or 0.01 m3). This becomes the base unit for this circuit which doesn't count decimal values.
For example, on figure below, the value is 191675. The shift will have to be done on the computer.
Note also that the change of unit/pulse is sometimes done when the smallest value is "6", not "0". Which means that with the figure above, it would be as follow:
Either: "01916754" => 191675 and later "01916758" => 191676 (overshoot mode)
Or: "01916754" => 191674 and later "01916758" => 191675 (undershoot mode)
Your call. Confusing? Oh yes... but there is nothing to do about it. And it doesn't make much difference in the end.
Protocol
The serial speed is unsually slow (by today's standards) for 2 main reasons:
The microcontroller has to be flashed to run at 1Mhz in order to keep consumption as low as possible and to work even at a low voltage
On these mini microcontollers, there is no hardware UART. It's basically a SoftwareSerial implementation
That said 1200 bit/s is more than enough in our case.
2 modes
Relative: each pulse will increment the counter starting from zero (default mode). Values are prefixed by a star ('*')
Absolute: the counter is initialised to match the real/physical one. Values are prefixed by a superior sign ('>')
The idea of the relative is that in case of reset, by adding the value to the last known value, it is possible to track the reading.
For example, the last recorded value is 14568 on the computer. There is a reset of the microcontroller and it loses its memory. Next pulses will therefore return '*1 ', '*2 ', etc... The computer just has to add 14568 + 1 = 14569, 14568 + 2, etc... to guess the right values.
Initialising the value
Using a terminal (or from the reading software), just send a inferior sign ('<') followed by the value followed by Carriage Return with 5 seconds.
The stored value will be returned (absolute mode above).
Querying the value
Each pulse will send over the wire the new value but it is also possible to query it by sending a question mark ('?').
The stored value will be returned.
Hooking it
Idealy, the pulse meter should be within meters of the meter (sorry for the pun). The capacitance on the wires is not really an issue but it seems more logical this way (your point of view may be different).
Several possibillities of attachments are possible. Among them:
Using a ESP8266 as a relay
The same way I am using a ESP8266 to forward the reading from the electricity smart meter, it is possible to use it to send the reading periodically. Either by keeping the ESP8266 running, in the case the notification is Synchronous or by waking it up every x minutes and polling the current value (by sending a '?').
Using the serial port on the Raspberry
or a USB Serial adapter if the computer and the meter are not too far apart.
In this case, the shorter the better on the serial side but at 1200 bits/s the risk of trouble is low.
Using a RS-422 or RS-485 link
In this case, the distance can be quite long.
Other meters
This solution was developped initially for a gas meter but it can be used for any kind of pulse meter: water, door, etc...
The code and schematics are available (AS IS) on github.
It is notorious that modules/chips sold on Chinese marketplaces can be fake ones. Most of the times, it's not much of an issue for non-industrial applications. As long as the components behave properly, it is almost impossible to check their quality/authenticity.
As I wanted to explore the programming of ATtiny85, I ordered a couple of them on AliExpress. Then time flew and a long time after the "return/complain" window was closed, I gave them a try.
Nothing... Impossible to do anything with them. I double-checked the wiring, but I always ended-up with the famous:
"Device signature = 0xffffff".
Reputable French shop on Ebay
Certainly puzzled, I ordered another pair, this time from a shop I previously used succesfully on ebay. Having received them the next day (one big advantage of buying local!), I tested them and they worked straightaway.
Fuses and quartz
One of the main reasons of a bad signature when programming seems that there is a setting of internal fuses to use external quartz at a specific frequency.
I tried my entire stock of quartz (6 "standards" values)... without success.
High voltage programming
The next step was to try "High" Voltage (meaning more that 5 volts, not mains BTW), using these solutions:
which indicate an ATtiny11! For a ATtiny85, it should be 0x930B...
The fuses were (always):
0x6C 0x80 0x6C
Unfortunately ATtiny11 is a very old series which is almost completely forgotten with low specs and can't be programmed easily (ATtiny13 is the replacement).
Photos of a real ATtiny85 :
Photos of a fake (?) ATtiny85 :
Conclusions
It was the first time I faced a deliberate forgery. I certainly bought a fair share of fakes and clones, sometimes knowningly ("Digispark rev3", etc...). The first thing is certainly to run a test ASAP. Apparently sellers are keen to reimburse immediately when notified there ware is not genuine.
Then, to consider real distributors, like in the old days:
Ebay (France): 48H delivery by post => 12€ inc VAT
Reichelt Elektronic: Delivery 2-6 day => 13€ inc VAT
Farnell Europe: Next day UPS delivery => 14.40€ inc VAT and surcharge if order < 30€ HT, only 6.12€ inc VAT otherwise
I always considered the "big" retailers (Mouser, RS, Farnell, Digi-key, ...) as professional only but in reality they seem more and more keen to accomodate small orders too. I far as I can tell, I could order a single unit for 9.50€ inc VAT and delivery. Not necessary the most cost effective but with a risk of counterfeit stuff certainly very low (but even for controlled supply-chains, the risk is never null).
