I’ve upgraded your Trust Level. Try posting now.
How had you confirmed that if the behavior hasn’t changed? Did you check the logs? There is an emonpi update log located in ~/data and you should also check /var/log/service-runner.log too.
Thanks Robert,
Logs as per Glyn’s request:
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2018.03.17 10:11:07 =~=~=~=~=~=~=~=~=~=~=~=
login as: pi
[email protected]'s password:
ooooooooo. o8o
`888 `Y88. `"'
.ooooo. ooo. .oo. .oo. .ooooo. ooo. .oo. 888 .d88' oooo
d88' `88b `888P"Y88bP"Y88b d88' `88b `888P"Y88b 888ooo88P' `888
888ooo888 888 888 888 888 888 888 888 888 888
888 .o 888 888 888 888 888 888 888 888 888
`Y8bod8P' o888o o888o o888o `Y8bod8P' o888o o888o o888o o888o
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
The file system is in Read Only (RO) mode. If you need to make changes,
use the command 'rpi-rw' to put the file system in Read Write (RW) mode.
Use 'rpi-ro' to return to RO mode. The /home/pi/data directory is always in RW mode.
pi@emonpi(ro):~$ sudo service mosquitto status
mosquitto.service - Mosquitto MQTT Broker
Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled)
Active: active (running) since Sat 2018-03-17 09:42:02 AEDT; 29min ago
Docs: man:mosquitto(8)
https://mosquitto.org/
Main PID: 1930 (mosquitto)
CGroup: /system.slice/mosquitto.service
1930 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
Mar 17 09:42:02 emonpi systemd[1]: Started Mosquitto MQTT Broker.
pi@emonpi(ro):~$ cat /var/log/emonpilcd/emonpilcd.log
2018-03-14 08:17:20,709 INFO Starting emonPiLCD V2.1.1
2018-03-14 08:17:20,818 INFO I2C LCD DETECTED 0x27
2018-03-14 08:17:21,260 INFO SD card image build version: emonSD-26Oct17
2018-03-14 08:17:21,263 INFO Connecting to redis server...
2018-03-14 08:17:21,273 ERROR waiting for redis-server to start...
2018-03-14 08:17:22,278 ERROR waiting for redis-server to start...
2018-03-14 08:17:23,284 ERROR waiting for redis-server to start...
2018-03-14 08:17:24,289 ERROR waiting for redis-server to start...
2018-03-14 08:17:25,295 ERROR waiting for redis-server to start...
2018-03-14 08:17:26,301 INFO Connected to redis
2018-03-14 08:17:26,302 INFO Connecting to MQTT Server: 127.0.0.1 on port: 1883 with user: emonpi
2018-03-14 08:17:26,307 ERROR Could not connect to MQTT
2018-03-17 09:42:08,474 INFO Starting emonPiLCD V2.1.1
2018-03-17 09:42:08,576 INFO I2C LCD DETECTED 0x27
2018-03-17 09:42:09,038 INFO SD card image build version: emonSD-26Oct17
2018-03-17 09:42:09,040 INFO Connecting to redis server...
2018-03-17 09:42:09,048 INFO Connected to redis
2018-03-17 09:42:09,050 INFO Connecting to MQTT Server: 127.0.0.1 on port: 1883 with user: emonpi
2018-03-17 09:42:09,059 INFO Connected to MQTT
pi@emonpi(ro):~$ sudo service emonhub restart
pi@emonpi(ro):~$ head /var/log/emonhub/emonhub.log -n50
2018-03-14 08:17:21,010 INFO MainThread EmonHub emonHub emon-pi variant v2.1.1
2018-03-14 08:17:21,011 INFO MainThread Opening hub...
2018-03-14 08:17:21,012 INFO MainThread Logging level set to DEBUG
2018-03-14 08:17:21,013 INFO MainThread Creating EmonHubJeeInterfacer 'RFM2Pi'
2018-03-14 08:17:21,017 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2018-03-14 08:17:23,020 WARNING MainThread Device communication error - check settings
2018-03-14 08:17:23,021 INFO MainThread Setting RFM2Pi frequency: 433 (4b)
2018-03-14 08:17:24,023 INFO MainThread Setting RFM2Pi group: 210 (210g)
2018-03-14 08:17:25,026 INFO MainThread Setting RFM2Pi quiet: 0 (0q)
2018-03-14 08:17:26,028 INFO MainThread Setting RFM2Pi baseid: 5 (5i)
2018-03-14 08:17:27,031 INFO MainThread Setting RFM2Pi calibration: 230V (1p)
2018-03-14 08:17:28,033 DEBUG MainThread Setting RFM2Pi subchannels: ['ToRFM12']
2018-03-14 08:17:28,035 DEBUG MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2018-03-14 08:17:28,037 INFO MainThread Creating EmonHubMqttInterfacer 'MQTT'
2018-03-14 08:17:28,042 DEBUG MainThread Setting MQTT subchannels: ['ToEmonCMS']
2018-03-14 08:17:28,043 DEBUG MainThread Setting MQTT pubchannels: ['ToRFM12']
2018-03-14 08:17:28,044 INFO MainThread Setting MQTT nodevar_format_enable: 1
2018-03-14 08:17:28,045 INFO MainThread Setting MQTT node_format_enable: 1
2018-03-14 08:17:28,046 INFO MainThread Setting MQTT nodevar_format_basetopic: emon/
2018-03-14 08:17:28,048 INFO MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg'
2018-03-14 08:17:28,052 DEBUG MainThread Setting emoncmsorg subchannels: ['ToEmonCMS']
2018-03-14 08:17:28,053 DEBUG MainThread Setting emoncmsorg pubchannels: ['ToRFM12']
2018-03-14 08:17:28,054 INFO MainThread Setting emoncmsorg url: https://emoncms.org
2018-03-14 08:17:28,055 INFO MainThread Setting emoncmsorg senddata: 1
2018-03-14 08:17:28,057 WARNING MainThread Setting emoncmsorg apikey: obscured
2018-03-14 08:17:28,058 INFO MainThread Setting emoncmsorg sendstatus: 1
2018-03-17 09:46:24,952 DEBUG MainThread SIGINT received.
2018-03-17 09:46:24,953 INFO MainThread Exiting hub...
2018-03-17 09:46:25,173 INFO MainThread Exit completed
2018-03-17 09:46:26,750 INFO MainThread EmonHub emonHub emon-pi variant v2.1.1
2018-03-17 09:46:26,751 INFO MainThread Opening hub...
2018-03-17 09:46:26,751 INFO MainThread Logging level set to DEBUG
2018-03-17 09:46:26,752 INFO MainThread Creating EmonHubJeeInterfacer 'RFM2Pi'
2018-03-17 09:46:26,756 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2018-03-17 09:46:28,759 WARNING MainThread Device communication error - check settings
2018-03-17 09:46:28,760 INFO MainThread Setting RFM2Pi frequency: 433 (4b)
2018-03-17 09:46:29,763 INFO MainThread Setting RFM2Pi group: 210 (210g)
2018-03-17 09:46:30,765 INFO MainThread Setting RFM2Pi quiet: 0 (0q)
2018-03-17 09:46:31,767 INFO MainThread Setting RFM2Pi baseid: 5 (5i)
2018-03-17 09:46:32,769 INFO MainThread Setting RFM2Pi calibration: 230V (1p)
2018-03-17 09:46:33,772 DEBUG MainThread Setting RFM2Pi subchannels: ['ToRFM12']
2018-03-17 09:46:33,773 DEBUG MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2018-03-17 09:46:33,774 INFO MainThread Creating EmonHubMqttInterfacer 'MQTT'
2018-03-17 09:46:33,778 DEBUG MainThread Setting MQTT subchannels: ['ToEmonCMS']
2018-03-17 09:46:33,779 DEBUG MainThread Setting MQTT pubchannels: ['ToRFM12']
2018-03-17 09:46:33,779 INFO MainThread Setting MQTT nodevar_format_enable: 1
2018-03-17 09:46:33,780 INFO MainThread Setting MQTT node_format_enable: 1
2018-03-17 09:46:33,781 INFO MainThread Setting MQTT nodevar_format_basetopic: emon/
2018-03-17 09:46:33,782 INFO MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg'
2018-03-17 09:46:33,784 DEBUG MainThread Setting emoncmsorg subchannels: ['ToEmonCMS']
pi@emonpi(ro):~$
Paul,
my confirmation that nothing has changed is based on observations on the LCD screens that I am not seeing anything different than what I originally posted ie nothing that says that there are sensors connected such as the two CT’s, the DS1820B2 or the AC-AC adaptor.
In regards to your update log, I am not really familiar with the how to access the /data and I have checked /var/log/service-runner.log but all I see is a series of “update via service-runner” messages.
Apologies if I don’t understand the messages, but I am not really up on all the aspects of this system - having said that, I pick up most things fairly quickly if given some guidance.
Hi Paul,
Following are the details that I captured during the update - hopefully this will answer your question on confirmation on the ATMega FW update.
Regards,
Dave
Server Information
Emoncms Version low-write 9.8.28 : 2018.01.27 Modules Administration : App v1.1.0 : Backup v1.1.2 : EmonHub Config v1.0.0 : Dashboard v1.1.1 : EventProcesses : Feed : Graph v1.2.0 : Input : postprocess : CoreProcess : Schedule : setup : Time : User : Visualisation : WiFi v1.0.0 Buffer loading… Writer Daemon is running with sleep 60s Server OS Linux 4.14.24-v7+ Host emonpi emonpi (127.0.1.1) Date 2018-03-14 06:47:06 AEDT Uptime 06:47:06 up 14 min, 1 user, load average: 1.04, 1.04, 0.72 HTTP Server Apache/2.4.10 (Raspbian) HTTP/1.1 CGI/1.1 80 MySQL Version 5.5.59-0+deb8u1 Host localhost (127.0.0.1) Date 2018-03-14 06:47:05 (UTC 11:00??) Stats Uptime: 229560 Threads: 3 Questions: 1487 Slow queries: 0 Opens: 58 Flush tables: 1 Open tables: 51 Queries per second avg: 0.006 Redis Version 2.8.17 Host localhost:6379 (127.0.0.1) Size 7 keys (528.65K) Uptime 0 days MQTT Version 1.4.14 Host localhost:1883 (127.0.0.1) Pi CPU Temp 48.85°C Release emonSD-26Oct17 File-system Set root file-system temporarily to read-write, (default read-only) Memory RAM Used: 20.41% Total: 976.77 MB Used: 199.38 MB Free: 777.39 MB Disk Mount Stats / Used: 67.63% Total: 3.33 GB Used: 2.25 GB Free: 938.82 MB /boot Used: 37.30% Total: 59.95 MB Used: 22.36 MB Free: 37.59 MB /home/pi/data Used: 0.92% Total: 3.46 GB Used: 32.65 MB Free: 3.25 GB PHP Version 5.6.33-0+deb8u1 (Zend Version 2.6.0) Modules apache2handler : bcmath : bz2 : calendar : Core v5.6.33-0+deb8u1 : ctype : curl : date v5.6.33-0+deb8u1 : dba : dio v0.0.4RC4 : dom v20031129 : ereg : exif v1.4 : fileinfo v1.0.5 : filter v0.11.0 : ftp : gettext : hash v1.0 : iconv : json v1.3.6 : libxml : mbstring : mcrypt : mhash : mosquitto v0.3.0 : mysql v1.0 : mysqli v0.1 : openssl : pcre : PDO v1.0.4dev : pdo_mysql v1.0.2 : Phar v2.0.2 : posix : readline v5.6.33-0+deb8u1 : redis v2.2.7 : Reflection : session : shmop : SimpleXML v0.1 : soap : sockets : SPL v0.2 : standard v5.6.33-0+deb8u1 : sysvmsg : sysvsem : sysvshm : tokenizer v0.1 : wddx : xml : xmlreader v0.1 : xmlwriter v0.1 : Zend OPcache v7.0.6-devFE : zip v1.12.5 : zlib v2.0 :
Client Information
HTTP Browser Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko Screen Resolution 1366 x 768 Window Size 1366 x 643
RFM69Pi is populated with RFM69CW module not RFM12B before running RFM69Pi update: Identifying different RF Modules.
emonPi Update emonBase Update
Download Log
Filesystem is unlocked - Write access
type ' rpi-ro ' to lock
I2C LCD DETECTED Ox27
Starting emonPi Update >
via service-runner-update.sh
Service Runner update script V1.0.0
EUID: 1000
Argument: emonpi
Wed 14 Mar 06:47:39 AEDT 2018
#############################################################
emonSD version: emonSD-26Oct17
emonSD base image check passed...continue update
#############################################################
Filesystem is unlocked - Write access
type ' rpi-ro ' to lock
git pull /home/pi/emonpi
* master
wifiap
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add ..." to include in what will be committed)
1
hardware/emonpi/emonpi2c/
nothing added to commit but untracked files present (use "git add" to track)
Already up-to-date.
git pull /home/pi/RFM2Pi
* master
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
Already up-to-date.
git pull /home/pi/emonhub
K0den-wibeee_interface
* emon-pi
hmm01i-syslogging
On branch emon-pi
Your branch is up-to-date with 'origin/emon-pi'.
nothing to commit, working directory clean
Already up-to-date.
git pull /home/pi/oem_openHab
* master
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
Already up-to-date.
git pull /home/pi/usefulscripts
* master
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
Already up-to-date.
git pull /home/pi/huawei-hilink-status
* master
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
Already up-to-date.
Start emonPi Atmega328 firmware update:
=================================
EmonPi update started
=================================
EUID: 1000
Requirement already up-to-date: paho-mqtt in /usr/local/lib/python2.7/dist-packages
Stopping OpenEnergyMonitor emonHub: emonhub has been stopped ok.
Start ATmega328 serial upload using avrdude with latest.hex
Discrete Sampling
avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/home/pi/emonpi/firmware/compiled/latest.hex
avrdude-original: Using autoreset DTR on GPIO Pin 7
Starting OpenEnergyMonitor emonHub: emonhub has been started ok.
[email protected] ../node_modules/node-red-node-emoncms
Start emonhub update script:
=================================
EmonPi update started
=================================
Running emonhub automatic node addition script
EUID: 1000
EUID: 1000
[[5]]
Node 5 already present
[[6]]
Node 6 already present
[[7]]
Node 7 already present
[[8]]
Node 8 already present
[[9]]
Node 9 already present
[[10]]
Node 10 already present
[[11]]
Node 11 already present
[[12]]
Node 12 already present
[[13]]
Node 13 already present
[[14]]
Node 14 already present
[[19]]
Node 19 already present
[[20]]
Node 20 already present
[[21]]
Node 21 already present
[[22]]
Node 22 already present
[[23]]
Node 23 already present
[[24]]
Node 24 already present
[[25]]
Node 25 already present
[[26]]
Node 26 already present
Start emoncms update:
=================================
Emoncms update started
Emoncms update script V1.1.1
Wed 14 Mar 06:49:06 AEDT 2018
#############################################################
emonSD version: emonSD-26Oct17
emonSD base image check pass...continue update
#############################################################
EUID: 1000
Checking cron tab for service runner entry...
service runner crontab entry already installed
current settings.php md5: a828cb3e3c9f015e348d86defd1a5d53
Default settings.php md5: a828cb3e3c9f015e348d86defd1a5d53
git pull /var/www/emoncms
dev-mosquitto-php
master
* stable
symlinked_modules
On branch stable
Your branch is up-to-date with 'origin/stable'.
nothing to commit, working directory clean
Already up-to-date.
NEW default settings.php md5: a828cb3e3c9f015e348d86defd1a5d53
settings.php has NOT been user modifed
settings.php not updated
git pull /var/www/emoncms/Modules/app
9.0
* stable
On branch stable
Your branch is up-to-date with 'origin/stable'.
nothing to commit, working directory clean
Already up-to-date.
Your branch is up-to-date with 'origin/stable'.
git pull /var/www/emoncms/Modules/config
9.0
* stable
On branch stable
Your branch is up-to-date with 'origin/stable'.
nothing to commit, working directory clean
Already up-to-date.
Your branch is up-to-date with 'origin/stable'.
git pull /var/www/emoncms/Modules/wifi
9.0
* stable
On branch stable
Your branch is up-to-date with 'origin/stable'.
nothing to commit, working directory clean
Already up-to-date.
Your branch is up-to-date with 'origin/stable'.
git pull /var/www/emoncms/Modules/dashboard
On branch stable
Your branch is up-to-date with 'origin/stable'.
nothing to commit, working directory clean
Already up-to-date.
Your branch is up-to-date with 'origin/stable'.
git pull /var/www/emoncms/Modules/graph
master
* stable
On branch stable
Your branch is up-to-date with 'origin/stable'.
nothing to commit, working directory clean
Already up-to-date.
Your branch is up-to-date with 'origin/stable'.
git pull /home/pi/postprocess
Your branch is up-to-date with 'remotes/origin/emonpi'.
Already up-to-date.
git pull /home/pi/backup
master
* stable
On branch stable
Your branch is up-to-date with 'origin/stable'.
nothing to commit, working directory clean
Already up-to-date.
Your branch is up-to-date with 'origin/stable'.
update mqtt_input systemd unit file
Update Emoncms database
[]
Restarting Services...
Restarting OpenEnergyMonitor emonHub: emonhub has been restarted ok.
Log is turned off
Restarting feedwriter
Restarting openhab (via systemctl): openhab.service.
Filesystem is unlocked - Write access
type ' rpi-ro ' to lock
I2C LCD DETECTED Ox27
Starting emonPi Update >
via service-runner-update.sh
Service Runner update script V1.0.0
EUID: 1000
Argument: emonpi
Wed 14 Mar 06:47:39 AEDT 2018
#############################################################
emonSD version: emonSD-26Oct17
emonSD base image check passed...continue update
#############################################################
Filesystem is unlocked - Write access
type ' rpi-ro ' to lock
git pull /home/pi/emonpi
* master
wifiap
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add ..." to include in what will be committed)
1
hardware/emonpi/emonpi2c/
nothing added to commit but untracked files present (use "git add" to track)
Already up-to-date.
git pull /home/pi/RFM2Pi
* master
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
Already up-to-date.
git pull /home/pi/emonhub
K0den-wibeee_interface
* emon-pi
hmm01i-syslogging
On branch emon-pi
Your branch is up-to-date with 'origin/emon-pi'.
nothing to commit, working directory clean
Already up-to-date.
git pull /home/pi/oem_openHab
* master
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
Already up-to-date.
git pull /home/pi/usefulscripts
* master
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
Already up-to-date.
git pull /home/pi/huawei-hilink-status
* master
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
Already up-to-date.
Start emonPi Atmega328 firmware update:
=================================
EmonPi update started
=================================
EUID: 1000
Requirement already up-to-date: paho-mqtt in /usr/local/lib/python2.7/dist-packages
Stopping OpenEnergyMonitor emonHub: emonhub has been stopped ok.
Start ATmega328 serial upload using avrdude with latest.hex
Discrete Sampling
avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/home/pi/emonpi/firmware/compiled/latest.hex
avrdude-original: Using autoreset DTR on GPIO Pin 7
Starting OpenEnergyMonitor emonHub: emonhub has been started ok.
[email protected] ../node_modules/node-red-node-emoncms
Start emonhub update script:
=================================
EmonPi update started
=================================
Running emonhub automatic node addition script
EUID: 1000
EUID: 1000
[[5]]
Node 5 already present
[[6]]
Node 6 already present
[[7]]
Node 7 already present
[[8]]
Node 8 already present
[[9]]
Node 9 already present
[[10]]
Node 10 already present
[[11]]
Node 11 already present
[[12]]
Node 12 already present
[[13]]
Node 13 already present
[[14]]
Node 14 already present
[[19]]
Node 19 already present
[[20]]
Node 20 already present
[[21]]
Node 21 already present
[[22]]
Node 22 already present
[[23]]
Node 23 already present
[[24]]
Node 24 already present
[[25]]
Node 25 already present
[[26]]
Node 26 already present
Start emoncms update:
=================================
Emoncms update started
Emoncms update script V1.1.1
Wed 14 Mar 06:49:06 AEDT 2018
#############################################################
emonSD version: emonSD-26Oct17
emonSD base image check pass...continue update
#############################################################
EUID: 1000
Checking cron tab for service runner entry...
service runner crontab entry already installed
current settings.php md5: a828cb3e3c9f015e348d86defd1a5d53
Default settings.php md5: a828cb3e3c9f015e348d86defd1a5d53
git pull /var/www/emoncms
dev-mosquitto-php
master
* stable
symlinked_modules
On branch stable
Your branch is up-to-date with 'origin/stable'.
nothing to commit, working directory clean
Already up-to-date.
NEW default settings.php md5: a828cb3e3c9f015e348d86defd1a5d53
settings.php has NOT been user modifed
settings.php not updated
git pull /var/www/emoncms/Modules/app
9.0
* stable
On branch stable
Your branch is up-to-date with 'origin/stable'.
nothing to commit, working directory clean
Already up-to-date.
Your branch is up-to-date with 'origin/stable'.
git pull /var/www/emoncms/Modules/config
9.0
* stable
On branch stable
Your branch is up-to-date with 'origin/stable'.
nothing to commit, working directory clean
Already up-to-date.
Your branch is up-to-date with 'origin/stable'.
git pull /var/www/emoncms/Modules/wifi
9.0
* stable
On branch stable
Your branch is up-to-date with 'origin/stable'.
nothing to commit, working directory clean
Already up-to-date.
Your branch is up-to-date with 'origin/stable'.
git pull /var/www/emoncms/Modules/dashboard
On branch stable
Your branch is up-to-date with 'origin/stable'.
nothing to commit, working directory clean
Already up-to-date.
Your branch is up-to-date with 'origin/stable'.
git pull /var/www/emoncms/Modules/graph
master
* stable
On branch stable
Your branch is up-to-date with 'origin/stable'.
nothing to commit, working directory clean
Already up-to-date.
Your branch is up-to-date with 'origin/stable'.
git pull /home/pi/postprocess
Your branch is up-to-date with 'remotes/origin/emonpi'.
Already up-to-date.
git pull /home/pi/backup
master
* stable
On branch stable
Your branch is up-to-date with 'origin/stable'.
nothing to commit, working directory clean
Already up-to-date.
Your branch is up-to-date with 'origin/stable'.
update mqtt_input systemd unit file
Update Emoncms database
[]
Restarting Services...
Restarting OpenEnergyMonitor emonHub: emonhub has been restarted ok.
Log is turned off
Restarting feedwriter
Restarting openhab (via systemctl): openhab.service.
set log rotate config owner to root
Restarting Services...
Starting emonPi LCD service..
Filesystem is locked - Read Only access
type ' rpi-rw ' to unlock
Wed 14 Mar 06:50:02 AEDT 2018
...................
emonPi update done
Can you clarify exactly what hardware you have?
I thought we were talking about a “homebrew emonpi” but now you are talking about a “RFM69Pi” I’m not sure what we have here.
You must use the correct “update emonpi” or “update emonbase” button, which one depends on 2 things, what hardware you actually have and whether you want that to be over written or not.
See Update EmonPi Button or Update EmonBase Button?
The logs you provide do not show anything to confirm success or failure of the FW upload, I believe these error might land in another log file called /var/log/service-runner.log if there are any errors, but I cannot be 100% sure.
See Errors not reported in emonpiupdate.log file
If this is a RFM69Pi or indeed an uncased emonPi can you tell us what’s going on with the on-board LED as that may give us some clues to.
Does this homebrew device have a 6pin FTDI header to connect a serial usb programmer? How did you install the original bootloader and sketch? What did you install?
Paul,
To answer your questions:
Hardware:
I have had boards made (Emonpi and LCD) from the gerbers available and assembled both boards. Both boards are the latest revision (Emonpi V1.6 and LCD V1.2).
Note I am using a Raspberry Pi 3 board.
I installed an RFM69 module on the EmonPi board because they were very cheap and just in case I used it down the track.
In regards to the word homebrew in the title, I never used that word and was apparently changed, but if the gerbers were correct, it is definitely not a homebrew system and for all intents and purposes it should be an EmonPi (V1.6) board. It is effectively an uncased EmonPi.
In regards to the onboard LED on the EmonPi board, it is lit and a steady light, and as it connected to D9 on the ATMega 328P chip, I assume it means that there is probably software running to set D9 to light the led (?).
In regards to the board (not a homebrew!) , yes, it does have a 6 pin header but I programmed the ATMega chip using an Arduino Uno using the method described in various articles and using AVRDude. My recollection is that the messages I received did indicate a successful load, but I can’t recall the actual message/s.
The S/W I installed was latest.hex from the Github repository.
I can’t help but think that some of the issues experienced may relate to using an RPi3, but I have no real grounds to base this on, and it is just a hunch.
One other point is that the red led on the RPI3 flashes in a regular pattern and the adjacent green led flashes occasionally.
Hope this information can assist you in resolving the issues, and thanks for your interest.
Regards,
Dave
Although I didn’t change the title myself, I would have to say that is accurate and most informative. The term “homebrew” is word play on the term “homemade” from the world of beer making, to stick with beer, if you got hold of Heineken’s recipe and made your own to the same exacting standards, it would still be “homebrew”. It is not used here as a derogatory term, it simply states the fact it has not come through the usual channels.
This is important because a “homebrew” emonpi may have slight differences in components or build quality of the PCB or assembly. It will not have been inspected or tested by a familiar eye, there are many places that differences can creep in that can be initially ruled out if it was shop sourced, eg we would know that the correct bootloader was installed and that it passed testing after the firmware was installed.
My confusion was not due to the term homebrew but due to the use of both the “emonpi” and “rfm69pi” terms. I now understand it is a emonPi.
I’m still left to assume what method and FW you used. I guess you mean the Uno was used as a parallel programmer using the 2x3pin header on the emonpi board? The “latest.hex” in the Github repository won’t contain a bootloader as it is usually installed via the serial port and that is only made possible by the installation of the bootloader, so for that you most likely need the “latest_bootloader.hex”. Do not worry that it is 2yrs old, the emonpi update will overwrite the FW part once your up and running, it’s the bootloader part that is not included in the “latest.hex” that we need here.
I see no reason to suspect it has anything to do with being a PI 3, all the emonpi’s have been Pi 3 for a substantial time now, only the very first couple of batches were Pi 2.
Moving forward the best thing to do it to reinstall the hex and take note of any output good or bad in case there are any further issues. If you have a usb-serial programmer you could test the emonpi board off the Pi via the 1x6pin header which would help you if you knew you were fitting a board that was confirmed as working.
Paul, the issue of homebrew doesn’t worry me at all, and I just wanted to make it clear that it wasn’t a deviation in design of the original board, and I accept your point about quality control of components etc. Also I do see why there needs to be some differentiation with a commercial product.
I think you are hitting on the issue of why I can’t get it working so I appreciate your efforts in assisting me.
I have reloaded both the bootloader and the EmonPi firmware using an Arduino UNO as the ISP and I think I can see a likely problem and its due to my lack of experience in Arduino programming. I think it possibly relates to the parameters I used for both bootloader and firmware using avrdude.
I see from the responses using avrdude, that I again erased the chip when I loaded the EmonPi firmware and probably removing the bootloader. Would this be the problem, or can you see anything else I may have done wrong?
(BTW, I used an earlier bootloader rather than the latest_bootloader.hex that I wasn’t aware of until your response above).
See below:
Loading Bootloader.hex
C:avrdude -P com1 -b 19200 -c avrisp -p m328P -u -U flash:w:c:\bootloader.hex:i
avrdude: AVR device initialized and ready to accept instructions
Reading : ################################################## : 100% 0.10s
avrdude : Device signature = 0x1e950f
avrdude : NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude : erasing chip
avrdude : reading input file "c:bootloader.hex
avrdude : writing flash (32768 bytes)
Writing : #########################################
avrdude : 32768 bytes of flash written
avrdude : verifying flash memory against c:\bootloader.hex
avrdude : load data flash data from input file c:\bootloader.hex
avrdude : input file c:\bootloader.hex contains 32768 bytes
avrdude : reading on-chip flash data:
Reading : #################################################### : 100% 22.47s
avrdude : verifying ...
avrdude : 32768 bytes of flash verified
avrdude done. Thank you.
Loading Latest.hex
C:avrdude -P com1 -b 19200 -c avrisp -p m328P -u -U flash:w:c:\latest.hex:i
avrdude: AVR device initialized and ready to accept instructions
Reading : ################################################## : 100% 0.1s
avrdude : Device signature = 0x1e950f
avrdude : NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude : erasing chip
avrdude : reading input file "c:latest.hex
avrdude : writing flash (19554 bytes)
Writing : #########################################
avrdude : 19554 bytes of flash written
avrdude : verifying flash memory against c:\latest.hex
avrdude : load data flash data from input file c:\latest.hex
avrdude : input file c:\latest.hex contains 19554 bytes
avrdude : reading on-chip flash data:
Reading : #################################################### : 100% 14.41s
avrdude : verifying ...
avrdude : 19554 bytes of flash verified
avrdude done. Thank you.
Appreciate your guidance on this issue.
Regards,
Dave
Hi Dave
I’m not overly familiar with this but I suspect the issue might be that you are flashing the AVR with a FW that includes a bootloader, then reflashing with a FW with out a bootloader. The erase in between isn’t the issue directly because you should always do a delete cycle to ensure the old FW doesn’t “show though” to the new FW, eg if the second FW was 1k smaller, the last 1k of the old FW would still be thre after reflashing. Not deleting will not retain the bootloader from the first flash.
If the latest.hex is from the emonpi repo’s it is intended to be flashed via the serial upload method provided by the bootloader, it doesn’t have a bootloader because you are using the existing bootloader to upload the non-bootloader FW after the bootloader (first 2k I think).
You just need to flash a bootloader FW via ISP and leave it at that. The emonPi updater will take care of the rest. Alternatively, you can use a serial to USB programmer on the 1x6pin header and install the latest.hex via serial, it you want to test it fully before assembly.
1 Like
Hi Paul,
after much testing I agree with you that the issue is with the FW on the Atmega 328 on the EmonPi board. I think the loading method via the Arduino UNO as the ISP via the ISP1 socket is the issue, so I will try using the serial port. Can you give me some guidance on how I use the serial port i.e. what can I use to download the bootloader hex file and how do I use the reset pin - do I toggle it (which I think I need to do)? BTW, I have looked through the various posts, but have been unable to find anything revelant.
Regards,
Dave
The whole idea of using the serial port is to simplify the uploading of FW making it much more user friendly, so hopefully you won’t need to be playing with the reset line directly unless you choose to try and do this via a Pi’s GPIO that’s not running an emonSD, but even then there is a utility you can install.
This ability to upload FW over serial is provided by the bootloader!
To be able to upload over serial you must first install “the bootloader” using a ISP eg “Arduino UNO as the ISP”
The bootloader has not changed in several years (to my knowledge), the difference between different versions of the emonPi’s bootloader.hex or bootloader_latest.hex etc is not a change to the bootloader but a different FW above the same bootloader. Think of those files as “original_bootloader_with_older_firmware.hex” and “original_bootloader_with_nwer_firmware.hex”.
So when you have successfully installed one of those via ISP (I don’t think it matters which because neither is the latest FW) you will have the bootloader in place to overwrite the older FW via serial.
At this point you can simply use the 6pin FTDI header from here on in.
You can (should you choose) plug in a usb-serial programmer, connect it to a PC and install any sketch via the Arduino IDE, eg Blink.ino or indeed the emonPi src.ino.
However there is no NEED to do that as the emonSD is configured to update the emonpi board FW over serial whenever the emonPi update routine is run.
As long as you have that bootloader in place, you are good, the emonpi updater can take it from there.
If you want to experiment or learn about programming and Arduino (which the emonpi board is essentially) and manually using the reset line you might be better looking at the Arduino forum or there will be literally hundreds of blog posts out there you can read up on it. It is not documented here because you don’t need to that info to use a usb-serial device and the method we use via the Pi’s GPIO serial port uses a utility by Dean Mao called avrdude-rpi, the development of which he documented at http://www.deanmao.com/2012/08/12/fixing-the-dtr-pin/ if you want to know the nitty gritty.
I would recommend just installing the bootloader_latest.hex" via your “Arduino as ISP” then plug in a usb-serial adapter and see if you get any serial output from the emonpi board using the Arduino IDE. Assuming you do, connect it up to the emonpi and try running the emonpi updater.
Hi
I built emonPi from gerber files, too.
i have exact same problem and i programmed using an ISP Programmer and then used update option on emoncms but still no change in behaviour.
still shutdown button doesn’t work and i connected every sensor but none of them are recognized and LCD shows connecting… please wait
i also checked mosquitto MQTT and its active.
what should i do?
Can you please describe the issue you have, giving any detail you can and what you have tried.
If you do indeed “have exact same problem” then the fix is already there for you, otherwise we will need to know more.
Have you power cycled the emonpi since adding the sensors? they are only recognised at start-up (of the emonpi board not the Pi).
That suggests the emonpi board IS working.
Hi Paul,
after a long delay due to family, work and a lot of travel (plus some frustration with lack of progress causing me to give up for a while), I have been working on the “connecting… please wait” issue and this is my progress to date:
You recall that I had boards made using the gerbers provided on Github, which I assume are the same as your commercial boards (same as Amir?). I have been over the boards as much as I can and haven’t found any obvious issue - the boards were made by a company that has produced other boards for me with no issues.
Could there be a small difference in the gerbers between the boards I found on Github and yours?
How can I check? - I realise that you don’t want to do a comparison, but I would be happy to do a comparison if you were able to supply your gerbers. I accept that you may not want to, and this is OK with me.
I have also built a second Emonpi board with just the basic Arduino components and there is no difference in result.
I have also obtained a USBASP and have programmed both boards with the test sketches I have found on the Raspi software and the results are as follows:
Blink_Led - works OK and led blinks 5 secs on/5 secs off
Pi_shutdown_LCD - short press and I get the LCD message Raspberry Pi Booting
Long press and I get the count down 5 to 0 and the LCD shows SHUTDOWN.
DS18B20 Test Sketch - doesn’t work (nothing on LCD).
Pi Shutdown_button_test - doesn’t work (nothing on LCD)
So, from these tests it appears that the EmonPi is able to load software and function, so I don’t now believe it is an EmonPi s/w load issue.
I have also loaded the latest software emonpi Build - EmonSD-13Jun18 and no change in behavior
(didn’t think it would, but tried anyway).
I have also ran the Emonpi update with no obvious issues.
(BTW, printout of the emoncms below - Seems to be connecting to MQTT OK)
View last entries on the logfile:/var/log/emoncms.log
Auto refresh Download Log Copy to clipboard
2018-08-05 05:18:04.246|WARN|phpmqtt_input.php|Not connected, retrying connection
2018-08-05 05:18:04.321|WARN|phpmqtt_input.php|Connecting to MQTT server: Connection Accepted.: code: 0
So, I really don’t know where to go from here, and there is a common issue between myself and Amir’s, and this is we have both had boards made from your Github-published gerbers.
Do you have any other diagnostic software I could try, or what else should we try to overcome the issues? - happy to work with you online or offline (I can Skype at a mutually convenient time if you want to).
Alternatively if there is another Australian reading this post (and preferably lives in Sydney) I could communicate with them, and try to resolve the issues.
Either way, it would be good to close out this issue if others have similar problems down the track.
Paul, in your response to Amir, you said "the fix is already there for you - can you elaborate on what you mean?
As a side issue, I found that the red led on the RPi3 was either flickering or stayed on, and on researching this, I see it relates to a low voltage issue and changing the USB cable for a heavier cable seems to have cured this problem - I don’t think it was the cause but worth including anyway.
Regards,
Dave
After 18 days wait, I have received no response from Paul so I assume he must be away or otherwise distracted.
I have come to the conclusion that the problem is a lack of serial communication between the EmonPi board and the RPI3 as I can see pulsing on the TxD lead from the ATMega328 and nothing on the RxD.
I am aware of the need to change the Uart over from UART1 to UART0 and have done the requisite steps except when I enter the last step:
sudo systemctl disable hciuart
I get an error message - see below
looking at the config.txt file I see:
Disable Pi3 BT (Not used EMONSD Nov 2017) (Note there is no hashtag at the start of the line??)
#dtoverlay=Pi3-disable-bt
# Switch Pi3 Bluetooth function to use the mini-UART (ttys0) and restore UART0/ttyAMA0 over GPIO 14 & 15.
Note This may reduce the maximum useable baudrate.
dtoverlay = pi3-miniuart-bt
After exiting and trying to stop BT modem trying to use UART by entering the following command
sudo systemctl disable hciuart
I get: failed to disable unit: No such file or directory.
I think I am getting closer to resolving the issues (caused mainly due to my lack of experience), so once again, I would like some assistance and guidance to resolve this issue. (Note I have loaded emonpi Build - EmonSD-13Jun18)
Paul, Glyn, Trystan and anyone else, can you offer any guidance please?
Dave
If you put an ‘@’ in front of somebody’s user name, they will generally get an email to notify them of the mention. Without that, they might not notice your post.
Sorry, I did see your post but over the 127 days between my last reply and your next response, I forgot a fair amount of detail and did not have the time to review the whole thread again, I did intend to do that but I have been very busy and unable to get back to this (I still have not reread all of it), most of us only do this on a voluntary basis in our spare time and have our own jobs and lives too.
From that last reply in March…
Did you do this? Is the emonPi serial communications as expected and fully functional when tested standalone without the Pi?
Normal running the emonpi only transmits serial, emonhub will configure the emonpi board at start up using serial and at changes of settings only (unless you have set up the emonGLCD time transmissions). Just seeing a pulsing line doesn’t tell us if that is good data or not.
When we know exactly what is coming out of the emonpi and how it reacts to commands issued via the serial terminal (Arduino IDE) we will know better whether it might work with the Pi.
Going back to the “homebrew” discussion, I explained the fact that a “shop bought” unit would be tested to a certain degree before shipping, those tests will most likely be done via that 6pin FTDI header without attaching to a PI. That is the main reason why identifying a “homebrew” unit is important. We need to know that the emonpi board works in it’s own right before plugging it on to a Pi.
Please post some serial output from your emonpi board.
Are you thinking the RPi tx line is damaged?
You should not need to make any changes to the emonSD image for it to work with an emonpi board, however, if your emonpi IS outputing valid serial data and you still cannot get it working, please use the tried and tested image NOT the beta June2018 image as that too adds too many possibilities for locating issues as it is not tried and tested. In fact since G&T are currently working on a new image it’s quite possible the June2018 image will never get finished/released.
Once you know your board is good and it is working with the known good (older) emonSD image, you will then be in a better position to try other images etc.
@pb66
Paul,
after much investigation, I have determined the following:
The EmonPi board is outputting serial data at 38400 bps on power-up as follows:
EmonPi V2.90
OpenEnergyMonitor.org
Startup…
The RPi V3 is responding with what I believe is serial data (repeating several times), but I can’t find the correct baudrate that it is transmitting at the best result I get is at 38400 bd and the characters are:
v4b210g0q5ilp (repeated several times)
This occurs several times and I have tried every baud rate on Putty that I could find and even tried odd and even parity (which I didn’t expect to make any difference, but tried in desperation any way).
I have made the appropriate changes in the config.txt as follows:
dtoverlay=pi3-disable-bt (comment says it is not required in EmonSD Nov 2017 which I had reloaded at your suggestion)
dtoverlay=pi3-miniuart-bt
I have also set the core clock in the RPi3 to 250MHz (core_freq=250) as also suggested with no effect.
BTW, I have also tried minicom with the following command with the Rx and RX looped and nothing printed on the screen : sudo minicom -D /dev/ttyAMA0 -b 38400.
So, along my travels, I have certainly learnt a lot about Arduino and RPi which has been good, but extremely frustrating at times, and I think I have proven the issue down to a serial data issue with the RPI, but I have run out of ideas on where to go from here. Anyone have any ideas on what the issue is with the RPi and how I can prove the issue and fix it?
The obvious solution is to try another RPI, but I don’t have one (apart from a Pi Zero W that I purchased, but never used in anger)
In summary (for readers of this lengthy series of posts), the issue is that I only get as far as the LCD displaying Connecting… Please Wait.
I don’t want to abandon this project as I have put considerable effort so far, as Paul has provided considerable assistance in helping me identify the problem, but I admit I am close to giving up.
Regards,
Dave
Is that all it outputs?
How are you testing this? Are you checking the emonpi away from the RPi using the Arduino IDE and a serial programmer on the 6 pin header as I suggested?
Assuming you are testing as above and that the serial output does just stop after the “Startup…” line, then it looks like there might be a problem with the rfm side of your board. IIRC you have fitted an RFM69CW, is it definitely a “69CW”? Is it orientated the right way? Are there any bad connections or solder bridges etc on close inspection?
Looking at these few lines in the emonpi firmware
they call 4 functions (“emonPi_startup()”,“RF_Setup()”,“check_for_DS18B20()” and “i2c_lcd_detect()”), the first function is confirmed as working by the serial output you have provided, the middle 2 functions do not produce serial prints and the last one should print a message on success or fail
So it suggests the emonpi firmware is executing the first of those 4 functions ok but not reaching the 4th one. From experience I would look at the RFM stuff before even considering the temp sensor code, as a quick test you maybe able to just change this one line in the emonpi firmware and recompile/reload if you have the Arduino IDE and serial USB programmer connected.
by setting that to 0 it should bypass any RFM checks and go straight onto the temp sensor checks, although the confirmation of successfully detecting temp sensors doesn’t get printed to serial until the “serial_print_startup()” function is called in L208 (see here). So the line you are looking to see is either “LCD not found” or begins with “LCD found”.
Ultimately you want all the setup info to finish printing and then a new line every 5s starting with “OK” and containing all numbers, the first number on each line will be 5 and the last will be “(0)”.