Robert, that’s most unlike you. One comment on another thread shouldn’t lead to the pov you are putting forward.
There are probably hundreds if not thousands of members who don’t regularly comment that have had no issues with esp8266 based controllers. I’m one of them - had several homebrew ones running for a few years and a lot of the commercial iot devices I have around the house use esp8266s and run without any problems.
In fact the esp system I have reporting temperatures on our heat bank is mounted on the heat bank, so next to the metal casing - it works perfectly. A pi zero some distance away and nearer the router is pretty flaky - it regularly loses WiFi for a time.
I think @borpin also said a pi was better because it has a proper o/s but I think I’d rather not have any sophisticated system running on my iot devices as I would then have to make sure they were up to date with the latest security patches.
esp boards are cheap and there are some great esp platforms out there, e.g. tasmota that make implementing simple controllers for sensors very easy. Tasmota has mqtt support built in which enables easily routing data to an emoncms system.
The ESP8266 is suspected of sending rogue data back to the emonTx, there have been 2 reports of that to my knowledge. It should only be sending commands back from the remote user, not generating (or echoing) characters.
When you say ESP8266, do you mean the emonESP board that plugs into an emonTX?
On the assumption you do, then it’s not the ESP8266 but the emonESP software that is most likely to be the cause of the issues on the 2 reports you mention.
I didn’t reply to the thread where @borpin made the comments but if you confirm that you mean the emonESP software then I’ll go back to that thread and add my comments in there as well.
And apologies if you think I’m being picky but the esp8266 controllers are great as simple sensor controllers, it would be a shame if readers were put off because of a comment that attributed an emonESP issue to the whole family of esp devices.
I wrote “suspected” because I’ve no direct evidence - only what has been posted here. If those who’ve written “ESP8266” in fact mean “emonESP”, then you may well be correct.
I’ve had lots of bad experience with ESP8266. The only reliable firmware I have used is Tasmota. Even then, the router the ESP connects to has to ‘like’ the ESP. PI Zero is simply rock solid.
Looking at the wiki EmonTx V3.4 - OpenEnergyMonitor Wiki , can a Pi Zero be powered from the emonTx directly, or vice versa? I’m always keen to reduce the number of plugs in use …
I have a 3D printer (Prusa i3mk3S) on order, so could be tempted to print a couple of Pi Zero c/w emonTx housings
I’ve personally, in my own home, had good experience with EmonESP running on the ESP8266, in particular the latest version which used to be called the timer branch for some time. It seems to be more reliable than my Pi which appears to be more prone to SD card corruption relating from power failures.
This said there are clearly issues with EmonESP reported on the forums recently that need further investigation to work out why the reliability has not been so good for others.
I know @haffle has the latest EmonESP firmware version as we replaced a number of faulty units last November (faulty because of software version rather than hardware). While the reliability appears a lot better than the previous version, for some reason it did get stuck again and required a power cycle to get going in recent days.
As @Robert.Wall noted, there is a separate issue resulting from the combination of the latest EmonTxV3CM firmware and the EmonESP that I need to investigate further. The EmonESP seems to send commands/serial data to the EmonTx which is causing the EmonTx to trip up.
I’m using the EmonESP + ESP8266 on a heatpump monitor without the ESP8266 TX to MICRO RX line connected, so there’s no risk there of any return data causing an issue.
And that is exactly the “cure” that one of the users with the recent problem has implemented. The other removed the emonTx’s serial input in software.
Both solutions infer exactly the same problem. The point is, the Arduino IDE does not send anything back to the emonTx except commands from the user, so as it uses the same interface, the emonESP/ESP8266 should be expected to behave in exactly the same way.
If the user can legitimately send commands back to the emonTx via WiFi and the ESP8266, then disconnecting the connection labelled “Tx” will prevent that. Does the ESP have that capability? As it’s advertised “for controlling devices over the Internet”, one would assume so, and therefore I’d expect it to have some means of accepting and passing on only data intended to the connected device - in this case the emonTx.
If the emonESP software has no instructions to write to the serial port then it won’t. However the esp8266 firmware will write to the serial port when it crashes - it outputs the reason for the the crash, it might even do it when it does a restart - it’s a long time since I set all of mine up.
I did too Brian especially when I overthought the wifi connection. the esp wifi library actually does a great job of keeping a connection going and reconnecting if necessary.
I had a quick look at the emonESP software last night and noticed a number of places where delay() was being used. This is dangerous as the watchdog can trigger forcing a restart (with output to the serial line). I replaced all delays in the code I run with timers. A bit more effort and another library. But setting a timer and having a timeout handling routine is much better than having a delay trigger the watchdog.
As I said above it’s a long time since I did any coding for the esp8266 but my bet would be that it’s a reset that is sending stuff to the serial line. And like @TrystanLea , my esp8266 based devics are a lot less flaky than ones based on Pi’s
The other advantage of the Pi in this scenario, is that it is using emonhub, so if the HTTP interface is used, it will buffer data in the event of connection issues. I’ve also used an orangePi in the past with a wired connection - even better IMO.
As I’ve repeatedly written, I don’t have an emonESP/ESP8266, I cannot verify what is happening so I can only go by what has been reported. By all appearances, rogue characters are being sent to the emonTx. There is no indication that there is a reason for that in the evidence that I have seen.
Discussing with @glyn.hudson and @Gwil re the link between the ESP8266 TX and the EmonTx RX. The adapter that we have sold for some time now does have this link removed. eg:
There has been however a change to the EmonTx hardware that has in recent weeks made its way to our production stock that allows for the ESP8266 to be soldered in place internally in the EmonTx. Both RX and TX lines are connected. We have only shipped a couple of units with this configuration which appears to have been a misunderstanding on our part, I will try and contact those affected, these orders will have been shipped 14th to 17th of April.
Thanks @Robert.Wall for the PM linking the threads. Looks like both users in the forum threads are using custom ESP8266 hardware rather than the shop bought adapter.
I think this is only one of the issues relating to the EmonESP and doesn’t explain @haffle’s issue that required a power cycle, but its at least one issue clarified
I’ve now (almost - still checking) got a version on the “config” module that requires the serial input to be explicitly turned on at startup, then it requires a physical reset (presumably after saving the setting to EEPROM) to disable it.
I think that doesn’t hamper usability in normal use with a computer as a terminal because nothing will go back the the emonTx except under user control, so it can be left enabled while the effect of a calibration change is evaluated. And presumably if an ESP8266 is in use, the emonTx would have been calibrated with the ESP8266 disconnected and would be powered down to connect it, thereby effecting a reset.
However, what is the position if the ESP8266 is soldered in? Presumably, on-line calibration is no longer possible as it hogs the serial FTDI interface? Therefore all the ‘on-line’ setup and calibration in the sketch is pointless?
