After discussion with @glyn.hudson I’ve reverted back to the previous version for now as there where a few flags missing.
1 Like
I haven’t tried the new version yet. However I did revert to an earlier version and did a git pull. I got the changes referred to by Trystan and was able to set up MQTT server and port.
The new smartplug appeared in inputs requesting to be allowed. Did this and it appeared in inputs but with no clock icon. Noticed an update to run.php so I pulled that in. No change.
Looked in log and found this:-
LAST ENTRIES ON THE LOG FILE
2019-03-04 17:52:49.200|ERROR|feedwriter.php|Starting feedwriter script
2019-03-04 17:52:50.450|WARN|emoncms_mqtt.php|Not connected, retrying connection
2019-03-04 17:52:50.482|WARN|emoncms_mqtt.php|Connecting to MQTT server: Connection Accepted.: code: 0
2019-03-04 17:52:51.475|ERROR|feedwriter.php|Starting feedwriter script
2019-03-04 17:54:14.691|WARN|emoncms_mqtt.php|Not connected, retrying connection
2019-03-04 17:54:20.001|WARN|emoncms_mqtt.php|Not connected, retrying connection
2019-03-04 17:54:35.851|WARN|emoncms_mqtt.php|Connecting to MQTT server: Connection Accepted.: code: 0
2019-03-05 09:41:48.162|ERROR|emoncms_mqtt.php|ErrorException: Missing argument 2 for Device::init_template(), called in /var/www/emoncms/Modules/device/device_model.php on line 323 and defined in /var/www/emoncms/Modules/device/device_model.php:593
Stack trace:
#0 /var/www/emoncms/Modules/device/device_model.php(593): exceptions_error_handler(2, 'Missing argumen...', '/var/www/emoncm...', 593, Array)
#1 /var/www/emoncms/Modules/device/device_model.php(323): Device->init_template(57)
#2 /var/www/emoncms/scripts/services/emoncms_mqtt/emoncms_mqtt.php(347): Device->autocreate(1, 'smartplug2', 'smartplug')
#3 [internal function]: message(Object(Mosquitto\Message))
#4 /var/www/emoncms/scripts/services/emoncms_mqtt/emoncms_mqtt.php(130): Mosquitto\Client->loop()
#5 {main}
Thanks for testing @ian, that sounds like an older version of the device module… can you run git pull on the device module and then try restarting emoncms_mqtt?
cd /var/www/emoncms/Modules/device
git pull
git describe
restart emoncms_mqtt
sudo systemctl restart emoncms_mqtt.service
There is a minor modification that I missed in the setup guide to speed up the device paring. If you add the following to emoncms/settings.php it will broadcast message that the smartplug picks up when you have the demandshaper page open:
$enable_UDP_broadcast = true;@ian I’ve been able to replicate the issue here that was causing the device module errors, now fixed: fix autocreate device initialization · emoncms/device@958fd6c · GitHub running git pull will bring it in.
Situation to date.
As a further test I cloned EmonESP from scratch.
This time everything went without hitch.
A couple of things I did note that might need to be addressed. The default MQTT IP address is correct for my setup but the default port is 65535. Also MQTT user defaulted to root with a password which of course was blanked so I can’t tell what it is.
However I was able to set my SSiD and MQTT parameters from the AP screen and MQTT connected almost immediately.
I then added $enable_UDP_broadcast = true; to settings.php.
I then ran update_emoncms.sh.
On first opening Inputs I could see no clock icons.
I did have the 2 old smartplug entries so I deleted them.
I think at this stage I rebooted emoncms. Still no clock items so I went into demandshaper screen and at that stage I got
Device on ip address 192.168.1.58 would like to connect
This is the sonoff so I allowed this and was able to set a schedule switch on and off and set the signal to Octopus.
At this point it went a bit pear shaped.
I think I had just reflashed the firmware on the 2 wemos ESPs I was using for test and went through the setting process again without hitch. They were appearing in inputs but with no clock icon.
At this point I reassembled the Sonoff and plugged into the mains. It did not reappear on inputs so I rebooted emoncms. This time no clock items and no smartplug2086 (the sonoff) but one of the Wemos.
Looking at the Sonoff webpage I noticed the MQTT port had changed back to 192.168.1.22 and MQTT was not connected. I corrected it to 192.168.1.28 and it reconnected.
My suspicion is that the eeprom writing of the ESP parameters has a bug. I haven’t got time to confirm this but I will try to test later.
One question. Does the sonoff MQTT Base-topic have to have a specific setting for demandshaper?
I think I have just proved there is a problem with the eeprom saving. I have had the same issue on a Wemos. However to be absolutely sure I will try this afternoon on a brand new Wemos just in case these issues are because the eeprom is not being cleared properly even though I always erase the ESPs before I upload new firmware.
The situation with emoncms is:-
I have one wemos smartplug showing in demandshaper with a clock icon and full control from the demandshaper window but this device is not actually powered or on the network.
I have the sonoff showing in Inputs with no clock icon.
I can connect to the sonoff directly via it’s URL and it is showing connected to MQTT. I can switch it On and Off from there. But I cannot access it from demandshaper window.
Any suggestions as to the best way forward? Do I need to delete the inputs to restore correct function?
I can confirm the ESPs are losing the URL and reverting to 192.168.1.22.
I have to enter correct URL and hit save to get them to show connected.
I also have a clue as to why no clock icons. I have just 2 smart plugs powered and connected. I get 4 smartplugs showing in inputs.
I think this is confusing emoncms. smartplug2086 and smartplug2516 are the correct names.
If I delete smartplug1 and smartplug2 via the inputs view the clock icons appear for smartplug2086 and smartplug2516 and I can control them from demandshaper.
If I then go back to inputs view smartplug1 and smartplug2 have shown up again but demandshaper still works as expected.
I have just set up a second Sonoff 20. There is something amiss with your naming routine as it came up as a duplicate to the first plug.
I also have confirmed that the MQTT parameters have to be reentered on every power up to connect to MQTT so they are not being saved properly.
1 Like
I will get back to you on this soon @ian, thankyou for the testing and detailed notes, much appreciated!
Thanks again for the testing!
Yes I noticed that as well, a factory reset clears it back to a default of 1883. It seems that the port setting is reading non zero EEPROM data remnant of the previous configuration. Do you know if there is a way to clear the EEPROM as part of the firmware upload process?.. esptool.py erase_flash is I guess flash only…
The inputs but no clock icon may be due to the delete device process as part of the demandshaper module not being entirely clean. I need to look at that again. I’ve got into the habit of turning the device off first before deleting it and I need to double check that the inputs are not recreated if the device was on when it was deleted. I will look into it.
No, you dont need to set any mqtt settings (assuming port 1883) for the smartplug to work with the emonbase/emonpi and demandshaper.
Is there any chance you have two emoncms installations with $enable_UDP_broadcast = true; or the UDP broadcast cron running? Devices will switch ip address if the emonbase/emonpi changes ip address, and so if you had two emoncms installations both sending out broadcasts it could switch between them… It may not be caused by this and be an EEPROM issue as you suggest…
Perhaps try deleting the device completely, you can do this either from the inputs interface by clicking on the cog icon and then deleting the device - or deleting it from the demandshaper module (top-right of the orange box).
I will try and replicate and look again at the naming & deletion process and hopefully get to the bottom of it.
Thanks again
I am not sure what you mean by this. I may have misunderstood the install instructions
Add enable_UDP_broadcast setting to emoncms/settings.php to enable automatic WIFI device setup:
$enable_UDP_broadcast = true;
Optional: Enable the periodic UDP broadcast script on the emonbase/emonpi:
crontab -e * * * * * php /home/pi/emonpi/UDPBroadcast/broadcast.php 2>&1
I had done both. was that wrong? I have now removed the crontab entry but it does not seem to have made any difference.
Any way I have disconnected the 2 smart plugs I was using.
I deleted the entries in demandshaper.
The 4 entries were still in inputs so I deleted them.
I rebooted emonCMS and all four entries are still there and updating!
They all have a single topic “in” and its null
You haven’t got retain set on any of the MQTT topics have you? This has caused me problems in the past. I am assuming that until I remove these entries there is no point in proceeding further in emonCMS but I am going to try installing the ESP firmware from scratch.
Had you considered this matter I reported?
I have just set up a second Sonoff 20. There is something amiss with your naming routine as it came up with the same name as the first plug.
Doing both is fine, the issue would occur if you set the same settings on say an emoncms installation on your laptop at the same time as a pi on the same network. That would result in two installations on different ip addresses trying to claim the same smartplug…
Is that the unique id on the end of the name smartplug? e,g smartplug1626? I realize I need to revisit that, perhaps using the last characters in the id string. I wanted to shorten the length of the unique id
@TrystanLea Any thoughts as to why I still have 4 smartplug entries in inputs despite deleting them.
Big red window in demandshaper with
no devices found
checking for pairing request.
Maybe your on to something there, I now realise, looking on my inputs page I see i have 5 smartplugs that I have deleted… all updating but not showing in the demandshaper log:
sudo journalctl -f -u demandshaper -n 1000
I’ve managed to fix it, turns out I left a section of code in there that kept publishing to devicename/in/state on a 5min basis, I must have missed needing to remove it after reworking the implementation to use a different approach fix ghost inputs · emoncms/demandshaper@dea4c67 · GitHub
If you pull in the latest and restart the demandshaper service, you should then be able to delete those inputs and they wont recreate.
Hi @TrystanLea
Success!
It took 2 goes to get rid of the entries. Presumably there were MQTT messages floating in the ether!
I deleted my mosquitto retained database in between just to make sure.
As an aside who maintains update_emon script in useful scripts? It would be good to have update of demandshaper added as I routinely use the script whenever I do manual git pulls just to keep everything up to date.
I have now setup a new smartplug. I am using a Wemos as it is much quicker than using a Sonoff plug for testing purposes.
Process:-
I do a factory reset.
Erase flash.
Upload firmware and SPIFFS.
Logged in to AP via phone.
Set up WiFi.
Logged in from network.
Set up MQTT, save and got immediate connection.
So first time of use everything is fine.
However if I restart the Wemos when you log back into the ESP web page the MQTT server always reverts to 192.168.1.22 and not 192.168.1.28 which I had entered when I saved at the MQTT drop down. My non standard port number is retained.
From then on its a devil to get MQTT to reconnect. Invariable I have to complete all the fields again and even that does not always work the first time. So I still suggest something is amiss with how the MQTT connection detail storing/reading routine is working Never any problems with saved WiFi credentials.
I am pleased to report once I have got MQTT connected I have full control from demandshaper window and everything seems to work as expected.
Yes it’s the last four digits I am referring to. All my Wemos come up as smartplug2516 and all my Sonoffs come up as smartplug2086.
Thanks @ian
I would see if I can replicate the MQTT configuration reverting issue here, sounds like that issue has been quite consistent for you.
The update_emoncms script in usefulscripts was written by @borpin, we are currently reviewing the build & update process as part of the discussion on emonSD next steps - #7 by TrystanLea and associated discussions.