As part of a push to drive the home’s electricity consumption down and better understand how energy was being utilized, I installed a clamp-style wireless energy monitor from Efergy in the house. Operating over 433Mhz, the transmissions were also useful as they could be decoded with an RTL-SDR and a software decoder. It made a simple “device” quite desirable, and I really liked being able to spot when someone has accidentally left a high draw device powered up.
Sadly, a month ago, the receiver started showing blank values for several hours each day and the daily consumption became unexpectedly low. The transmitter was still blinking every 6 seconds to indicate its transmission status. Resetting the link didn’t seem to do much, so I did what most people would do troubleshooting battery operated devices – I simply replaced the batteries in both units. This prompted it to work, until the next day, roughly at the same time, when the screen stopped showing information again.
I thought that this is likely a manifestation of receiver blocking or desense by a nearby strong transmission, either in-band (433Mhz) or out of band but sufficiently strong to pass through the front end. Getting an RTL-SDR proved that no such signals existed in-band, and the spectrum analyzer didn’t turn up any obvious strong signals. Instead, it revealed the transmitter wasn’t sending its signals at all.
I reset the transmitter, and it was visibly sending signals again, but the receiver was still blank even after a link reset. Perplexed, now I thought the receiver might have had a receiver front-end failure as well. But a dual failure is highly unlikely, unless by supreme coincidence.
Eventually, I decided to get out EfergyRPI and try decoding it with the RTL-SDR, and this is when the failure became more obvious. The code no longer decoded the transmissions at all, even when visible, indicating something was wrong with the transmitted data format. This may have been a failure in the modem chip on the transmitter, or a failure in the microcontroller (say, a corruption in program code causing unexpected execution failures and behaviours).
I decided that it probably wasn’t repairable, but I should tear it down and photograph it anyway, if only for users to compare it with the torn down Efergy Elite Classic 2.0 which I had posted earlier. It was noted earlier that the receivers and transmitters for the Classic 1.0 and 2.0 aren’t interchangeable despite them both being decoded equally well by the EfergyRPI code. The presently sold product is now version 3.0, and the changes are not known to me at this time.
Since the units weren’t going to be deployed again, I decided to tear it down with no fear of actually breaking it. As a result, virtually everything was torn down, although honestly, it was not that exciting.
Physically, from the outside, the receiver units share a common design. The moulding was probably the same, with more colour in the printing used on the 2.0. The version number is clearly stated, on the printing, although one change is that the 2.0 operates off a 5v DC input whereas the 1.0 uses 6v DC. In fact the cut in the side panels may have been oriented the wrong way as I may have torn it apart and incorrectly reassembled it in the past. The rear has two buttons, one which resets the link, and the other which is used to toggle alarm and set the time.
The unit features four top buttons for normal operation, allowing navigation of the limited internal memory. A full clear of the stored values can be done by holding history and mode/set until Clr shows on the display.
Inside the battery compartment are the QC and serial numbering labels. The unit cracks open in the same way as the V2.0, namely you remove the two pieces of grey plastic trim on the sides, and undo four small Phillips head screws to part the two halves of the case.
Here we find the battery compartment cables nicely leading to a connector which can be simply unplugged to allow us clearer access to the main board.
A closer examination of the main board shows a clear sharing of heritage between the V1.0 and V2.0 units, with this unit labelled WPM100-RX-V21, whereas the V2.0 has WPM101-6SRX-V30. The board itself is labelled with WPM100V01-02V12, whereas the V2.0 has WPM101V01-01V13. This PCB is dated Week 18 of 2009. The PCB features an array of LEDs on the bottom which shine through the matte plastic bottom to make a visual alarm, a buzzer above that with a dedicated drive transistor, the modem chip in the bottom left, namely a Amiccom A7201A FSK 315/433Mhz reciever. There is a main IC, which is gob-top mounted, but is likely to be the same Holtek as in the V2.0 which was in a plastic package, with an EEPROM hiding behind the wires. The antenna is a coil of thick copper wire on the side of the unit.
The differences with the V2.0 are mainly with the incorporation of a thermocouple bead and humidity sensor to provide some rudimentary weather data.
Undoing a few more screws allows us to see how the top and rear buttons are connected to the main board by a board-to-board connector (two actually) and a stacked board arrangement. We can also see the two wires leading to an LED backlight assembly for the LCD.
The front LCD is connected to the main board by an elastomer rubber connector. The backlight diffuser is seen taped to the other side of the PCB which doesn’t have any notable components on it.
The transmitting unit looks the same as the V2.0 unit, except with a much blander printing and lack of regulatory marks and FCC IDs everywhere.
Of course, the serial number and QC labels are in the battery compartment.
The connection to the current transformer clamps are made by three 2.5mm stereo jacks on the front of the unit. In the case of single phase application, using any one of the jacks is sufficient.
Opening the unit up shows a very odd battery design where the 3-series cell configuration is tapped at one-cell, to provide 3v and 4.5v to the board when operating with Alkaline cells. I wonder whether this arrangement was used to save money on a reference voltage IC or something, as the transmitter does seem to do something with just two batteries inserted of the three, but likely does not operate properly.
The rear of the board shows again, its WPM101-TX-24-V10 markings, and PCB markings dating it to Week 15 of 2009 with code WPM101V01-02V10. The antenna is another wound thick copper wire, and the input is three 2.5mm stereo sockets on a separate PCB soldered to the main PCB by board to board link.
The other side shows the marking WPM101V01-03V10. It is superficially quite similar to the V20, just that the transmitter arrangement is different, with this one utilizing a Amiccom A7103A 315/433Mhz FSK transceiver, instead of a transmitter only chip in the V2.0. The board utilizes an NXP PCF8563 RTC and has a main IC labelled with 11193 (possibly a serial or firmware version), whereas the V2.0 I received had 681564 on the label.
Regardless, the IC underneath was a Holtek 46RU24 8-bit OTP Microcontroller with UART, with 16kB of program memory, 384 bytes of RAM, and operating frequency up to 8Mhz. The V2.0 uses a 46RU232 which has 8kB program memory and 192 bytes RAM.
Current Transformer Clamp
The current transformer clamp is pretty much the same as the V2.0 without any of the specifications and printing on it. There is a label reminding you to ensure the sensor is completely closed to ensure that there is no stray flux leakage which could lead to incorrect under-reporting of current. Even though it has a 2.5mm stereo plug, it really only uses two contacts of the three.
The clamp opens up to be a “split” ring style design. The rest of the clamp is enclosed inside the plastic shell for safety reasons but is easily freed with a screwdriver or two.
The transformer is based on insulated windings with PCB ends.
The components on the other side of the PCB are all the same, and it seems like D1 is used as a half-wave rectifier (namely, shorting out the negative half of the cycle), with R1 likely to be some sort of bleeder resistor to insure any static or accumulated voltage is safely dissipated. D2 and R2 appear to form a current-limited crowbar limiter, so that the signal amplitude is positive only up to the voltage drop of the diode, with the 39 ohm resistor to stop excess peak current from impulses from ruining the protective diode and possibly to provide a soft clamp (and reduction in accuracy) when approaching saturating levels of current.
In the end, the fault seems to be with the transmitter, which, despite all troubleshooting, did not return to reliable operation. The transmitter would emit transmission bursts, at times with the right format, but often with incorrect data format which could not be decoded by the receiver, nor EfergyRPI. After a while, the transmitter stops broadcasting altogether. At first the fault was thought to be in the receiver due to intermittent decoding, but this was quickly ruled out as the RTL-SDR based code was not able to decode the transmitter anymore. It’s regrettable that it had failed, but after four years of service, I felt I had gotten my value from it. I wonder if other people have had similar failures with their Efergy transmitters?
It also shows that the Efergy Elite Classic R2.0 is a substantially similar product to the R1.0, with only a change to the display to add one more digit and temperature/humidity sensing locally and a change to the transmitter to use a different transmitter-only IC as opposed to a transciever IC.
I then uninstalled the system from the load centre, and tried to replace it with the clamp from the older Efergy HM01, but the larger clamp didn’t fit as easily, and once clamped in, had a loud mains 50Hz buzzing probably due to interaction with the magnetic field from an adjacent RCD. As a result, now I’m left with no energy monitoring in the house, but that’s not too much of a loss. If anything, the past four years have given me a good indication of what to expect power-consumption wise by turning appliances on and off.
ASIDE: Welp, my ADSL went down again, although the guys claim the technicians will be checking for the fault over the next two days. It’s mobile data to the rescue, again. Sigh.