EmonESP on Huzzah EmonTX v3.4 - EmonESP 'No latest data'

Mark_Sydney · 27 March 2022 02:25

I’d appreciate some troubleshooting help please!

I have successfully flashed a Huzza ESP8266
It is connected to the EmonTX as per the guidelines (RX on Huzza to RX on EmonTX)
It is powered, and connected to my wifi

2 Problems:

It will not show any values under latest data in EmonESP

image792×167 6.48 KB
it will not connect to emoncms (local) (

image432×806 19.9 KB

EmonTX info:
The EmonTX is a V3.4
Firmware is RF12demo.12

This is the log from emonESP (connection via rfm)

2022-03-27 03:12:10,675 INFO     MainThread Logging level set to DEBUG
2022-03-27 03:12:10,689 INFO     MainThread Creating EmonHubJeeInterfacer 'RFM2Pi'
2022-03-27 03:12:10,697 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2022-03-27 03:12:12,750 INFO     MainThread RFM2Pi device firmware version: [RF12demo.12]
2022-03-27 03:12:12,753 INFO     MainThread RFM2Pi device current settings:  E i5 g210 @ 433 MHz

Picture of wiring

Not quite sure what to do to make progress so would appreciate any suggestions.

Robert.Wall · 27 March 2022 13:12

Are you sure you’ve got the correct pads on the Huzzah module? I can’t see properly for the plastic (strain relief?) moulding, but it looks to me as if the green wire - data out of the emonTx on the (wrongly labelled) Rx pin is actually going to V+, and the Brown (+5 V from the emonTx) is going to the unlabelled pin between GND & V+.

Mark_Sydney · 27 March 2022 23:49

I have double checked this morning - and taken some better pictures for my own benefit.
Back - definitely going to GND
Orange - definitely going to V+
Green - definitely going to RX

Sorry about the moulding - that is just my way of avoiding soldering as I have a 3d printer

Robert.Wall · 28 March 2022 00:18

Do you have a programmer - can you connect that instead of the Huzzah? You should see output on the Arduino IDE.

Mark_Sydney · 28 March 2022 04:59

I don’t specifically have an ‘arduino programmer’ I used one of these to upload the emonESP firmware:

I can plug the EmonTX into my computer (windows) easily enough

Robert.Wall · 28 March 2022 09:30

Using whatever terminal emulator program you have, can you see any output from the emonTx?

Mark_Sydney · 28 March 2022 10:34

OK, I removed the huzzah connections
I left the ac adapter and usb power connected

I only connected RX and TX from my usb to serial thingy and via putty (windows) I get nothing from the EmonTX.

If I connect to serial via rfm over my pi, I can type commands. Note it says it is on firmware “RF12demo.12” which would seem to be out of date? as per here: GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware)

Is the note in there where it says I need to type w0 to user serial still valid? Apologies if that is a dumb question, but I am/was reluctant to type a command like w0 without knowing whether I can get it back.

The picture below is the result of connecting to the EmonTX via serial (usb to serial connector) PUTTY at 38400 baud which is the same as the emonhub log file and serial reports.

emonhub-editconfig-2022.txt (8.2 KB)

In case it matters, I have also attached the emoncms ‘config’

Robert.Wall · 28 March 2022 10:52

Doing things the way I think you are trying to do them, emonHub does not come into the picture. The data from the ESP8266 goes straight into emonCMS via Wi-Fi, your router and your LAN.

That is very clearly the wrong baud rate. Serial comms between the EmonTx and ESP8266 will be at 115200 baud. If you have not reloaded the sketch in the emonTx, and it is a recent acquisition, then the default sketch should indeed be the one it is running. You can read the source code to see the messages you should see when you power up (or reser) the emonTx. Do you see those when you use the correct baud rate?

When you do, you see messages that will help you interrogate the emonTx further.

If you turn the radio off, it should still leave the serial output being sent (line 332 onwards of EmonTxV3CM.ino). If you don’t have Version 3.2 of the sketch, I’d advise you get and load that, or tell me which version you actually have.

Mark_Sydney · 28 March 2022 11:28

The direction I am heading ’ is to send the data into my HomeAssistant instance via mqtt.

I didn’t make any changes so happy with that.

Ok, I am not sure what that means, are you referring to this? GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware)
I am the original owner (sometimes a bit lost but still the original owner) had this thing for several years now

Not sure what that means sorry - is there a suggested thread/post/something?

Unless you mean this:

2022-03-28 11:03:31,362 INFO     MainThread Creating EmonHubJeeInterfacer 'RFM2Pi'
2022-03-28 11:03:31,381 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2022-03-28 11:03:33,425 INFO     MainThread RFM2Pi device firmware version: [RF12demo.12]
2022-03-28 11:03:33,429 INFO     MainThread RFM2Pi device current settings:  E i5 g210 @ 433 MHz
2022-03-28 11:03:33,434 INFO     MainThread Setting RFM2Pi quiet: 0 (0q)
2022-03-28 11:03:34,449 INFO     MainThread Setting RFM2Pi calibration: 230V (1p)
2022-03-28 11:03:35,453 DEBUG    MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2022-03-28 11:03:35,457 DEBUG    MainThread Setting RFM2Pi subchannels: ['ToRFM12']
2022-03-28 11:03:35,473 INFO     MainThread Creating EmonHubMqttInterfacer 'MQTT'
2022-03-28 11:03:35,493 DEBUG    MainThread Setting MQTT pubchannels: ['ToRFM12']
2022-03-28 11:03:35,507 DEBUG    RFM2Pi     acknowledged command: > 0q
2022-03-28 11:03:35,511 DEBUG    MainThread Setting MQTT subchannels: ['ToEmonCMS']
2022-03-28 11:03:35,517 INFO     MainThread Setting MQTT node_format_enable: 1
2022-03-28 11:03:35,520 INFO     MainThread Setting MQTT nodevar_format_enable: 1
2022-03-28 11:03:35,522 INFO     MainThread Setting MQTT nodevar_format_basetopic: emon/
2022-03-28 11:03:35,541 INFO     MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg'
2022-03-28 11:03:35,559 DEBUG    MainThread Setting emoncmsorg pubchannels: ['ToRFM12']
2022-03-28 11:03:35,561 DEBUG    MainThread Setting emoncmsorg subchannels: ['ToEmonCMS']
2022-03-28 11:03:35,564 WARNING  MainThread Setting emoncmsorg apikey: obscured
2022-03-28 11:03:35,574 INFO     MainThread Setting emoncmsorg url: https://emoncms.org
2022-03-28 11:03:35,577 INFO     MainThread Setting emoncmsorg senddata: 1
2022-03-28 11:03:35,579 INFO     MainThread Setting emoncmsorg sendstatus: 1
2022-03-28 11:03:35,677 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz
2022-03-28 11:03:35,810 DEBUG    RFM2Pi     acknowledged command: > 1p
2022-03-28 11:03:36,183 DEBUG    RFM2Pi     acknowledged command: <nn> i     - set node ID (standard node ids are 1..30)
2022-03-28 11:03:36,341 DEBUG    RFM2Pi     acknowledged command: <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
2022-03-28 11:03:36,493 DEBUG    RFM2Pi     acknowledged command: <nnnn> o   - change frequency offset within the band (default 1600)
2022-03-28 11:03:37,024 DEBUG    RFM2Pi     acknowledged command: <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
2022-03-28 11:03:37,202 DEBUG    RFM2Pi     acknowledged command: <n> c      - set collect mode (advanced, normally 0)
2022-03-28 11:03:37,489 DEBUG    RFM2Pi     acknowledged command: ...,<nn> a - send data packet to node <nn>, request ack
2022-03-28 11:03:37,629 DEBUG    RFM2Pi     acknowledged command: ...,<nn> s - send data packet to node <nn>, no ack
2022-03-28 11:03:37,943 DEBUG    RFM2Pi     acknowledged command: <n> q      - set quiet mode (1 = don't report bad packets)
2022-03-28 11:03:38,183 DEBUG    RFM2Pi     acknowledged command: <n> x      - set reporting format (0: decimal, 1: hex, 2: hex+ascii)
2022-03-28 11:03:38,609 DEBUG    RFM2Pi     acknowledged command: <hchi>,<hclo>,<addr>,<cmd> f     - FS20 command (868 MHz)
2022-03-28 11:03:38,846 DEBUG    RFM2Pi     acknowledged command: <addr>,<dev>,<on> k              - KAKU command (433 MHz)
2022-03-28 11:03:39,124 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz
2022-03-28 11:03:41,694 DEBUG    RFM2Pi     7 NEW FRAME : OK 10 0 0 0 0 0 0 0 0 50 91 0 0

Also I have tried to ‘help myself’ but am uncertain if I have this scenario “rfm12b based RFM2Pi”

Robert.Wall · 28 March 2022 15:00

In which case, the sketch in the emonTx will be similar, but certainly not the same. Until we know what sort of radio is inside your emonTx (see Learn→Electricity Monitoring→Networking→RFM12B & RFM69cw wireless transceiver modules→RFM12B & RFM69CW Wireless Transceiver Modules) do not upload the current default sketch to your emonTx. If it has the old RFM12B radio, it will stop working until you have a compatible sketch.

No - look at the source code for the sketch which you can download from Github. When you start the emonTx, assuming you have your programmer and your computer connected and a terminal emulator running at 115200 baud, you should see something like (though not exactly like) this:

emonTx V3.4 EmonLibCM Continuous Monitoring V3.2
OpenEnergyMonitor.org
RFM69CW only Node: 15 Freq: 433MHz Group: 210

Then

POST…wait 10s
‘+++’ then [Enter] for config mode

If you do that and enter config mode, that’s where you see the list of commands for settings and calibration that are available. The commands available depend on how old your sketch is.

The LED should come on for 10 s (if you wait and allow it to start normally) and then give a short flash every 10 s approx, each time data is sent. That data should appear on your serial monitor. If it does, the emonTx itself is working and sending data. It does appear to be working and sending data by radio, but not Wi-Fi (not the same thing).

No I didn’t. That is output from emonHub, and shows it setting up the ISM Band radio in the emonPi. It shows the “emon” part of the emonPi, which includes the radio, communicating with the Raspberry Pi itself at 38,400 baud. Because you’re not sending your data using the same radio in the emonTx (intentionally), that’s largely irrelevant - EXCEPT THAT it does appear to have received valid data by radio - the data is from Node 10 and the voltage is 233.46 V. Unfortunately, that’s not enough information for me to identify the sketch.

So maybe you should assume I know nothing about what you are trying to achieve, and start from the beginning by describing your setup and what you want to do.
What would also be very useful is the first few lines output by the emonTx as it starts up “emonTx V3.4 … etc” which should tell us which sketch you’ve actually got, and maybe, the emonTx version.

Mark_Sydney · 28 March 2022 23:32

Thanks Robert for sticking with me!

That is a fair statement.
I want to move from EMONCMS on a Pi1 to MQTT into home assistant
I appear to have an EmonTX 3.4 with the RFM12B - 433 option
Despite my best efforts I cannot get the EmonTX to communicate via the uart into Windows or EmonESP

Looking at the link to identify the radio I am 100% sure I have the The RFM12B - 433 MHz Option, this is my closeup photo:

I’d love to say I have this working, but despite double and triple checking I am not seeing anything on the serial monitor

I have tried putty
I have installed the Arduino IDE and used serial monitor (with the correct drivers installed)
Note: I am 100% sure the USB/serial converter works, because I programmed the Huzza with EmonESP that way.

Robert.Wall · 29 March 2022 00:22

A reminder that Rx and Tx on the emonTx are labelled “unconventionally” - the changeover is on the PCB, so Tx is looking for transmitted data and Rx is looking for something to receive the data.

What’s been puzzling me is the output that your emonPi appears to have received is consistent with the emonTx being a V3.2, yet you say - and this photo looks very much like - it’s a V3.4. If that is the sketch you have, there’s no means of setting or configuring it via the serial input. It predates that development.

Also, the serial output is at 9600 baud. Try that. If you get nothing or rubbish, try all the baud rates you have between 9600 and 115200 (I don’t think we’ve ever used anything outside that range). If you get something, sensible or otherwise, on any one, you have Tx and Rx the right way round. If you get nothing on every baud rate you can try swapping Rx and Tx.

Also, the sketch for the V3.2 doesn’t have the correct output for the Huzzah software to interpret, so this could explain why you have nothing via that route. I can find or convert a sketch that will send the right output if needs be.

I’ve never had to deal with MQTT & home assistant, so I know nothing about the method of getting the data to it, but I’ve been under the impression that the emonPi can do that. It needs somebody familiar with those things to help you on that score.

Mark_Sydney · 29 March 2022 00:59

It’s nice being special - except when it isn’t here is a photo that says it is 3.4

I have the Pi-RFM board plugged into my Pi1 but did not specifically buy the EmonPI full kit, I am wanting to retire the pi and just go straight to Homeassistant - I am good with mqtt and all that stuff, once I get the data working.

Mark_Sydney · 29 March 2022 03:50

Success when configured at 9600 baud:

emonTx V3 DS V1.4 RFM12B
13:39:30.206 -> OpenEnergyMonitor.org
13:39:30.254 -> POST.....wait 10s
13:39:43.534 -> CT 1 Calibration: 90.90
13:39:43.581 -> CT 2 Calibration: 90.90
13:39:43.581 -> CT 3 Calibration: 90.90
13:39:43.626 -> CT 4 Calibration: 16.67
13:39:44.575 -> RMS Voltage on AC-AC Adapter input is: ~3V
13:39:44.623 -> AC-AC adapter NOT detected - Apparent Power measurements enabled
13:39:44.717 -> Assuming VRMS to be 230V
13:39:44.717 -> Assuming powering from batteries / 5V USB - power saving mode enabled
13:39:44.812 -> CT 1 detected
13:39:44.812 -> Unable to detect DS18B20 temperature sensor
13:39:44.859 -> RFM12B Initiated: 
13:39:44.907 -> Node: 10 Freq: 433Mhz Network: 210
13:39:46.652 -> 0

typing +++ then hitting SEND does not enter any config mode, but pressing anything immediately returns a value - so I guess that means RX/TX works

Robert.Wall · 29 March 2022 12:21

You’ve been seriously misleading me with that. In our terminology, you have an emonBase, NOT an emonPi. That’s wasted quite a bit of time and effort, and it’s not fair to take advantage of my goodwill in that way.

As I wrote, with the sketch I thought you had (not that one you’ve shown the output for even) you won’t get that response because your sketch predates the development of that.
What I think you have is an early version of this sketch, but in what must count as a genius move, there’s no source code to go with it - so that’s totally useless.

What I suggest is you give me a full and complete specification of what data you need your emonTx to send, be that serially to the Huzzah or by radio, in what format, and a list of what sensors you will use and I’ll seek out and if necessary alter a modern sketch to suit.

Mark_Sydney · 29 March 2022 12:51

Ok

I wonder if some of the confusion I have is that I have such a rare ‘version’ I have never quite found the right wording because of having half right answers.

It doesn’t seem like this will benefit anyone apart from me, and you also appear frustrated by this situation. I didn’t come here to inconvenience anyone, I came here to get something working.

I think in the interests of not bothering you any more, I’ll just call it quits. I can’t thank you enough for helping me at least realise that I wasn’t doing something wrong, I was just unlucky when it came to which board was shipped.

Robert.Wall · 29 March 2022 12:57

I’ve offered - taking a known up-to date sketch is far easier that trying to get Github to spit out an old one that’s carefully hidden (whether by accident or design is immaterial). I think it’s likely to be no more than a few minutes’ work (yes, I know - maybe an hour). I’m reasonably certain I could get it working, I need to know what you want of it, because of my lack of knowledge of MQTT and the rest of your system downstream. But it’s your decision.