Closed zsole2 closed 6 years ago
I have put back the old SD card, it's version is 5.0.17. Started up OK, and the sensor still works.
Thanks. I'll look into it.
I can't find any differences in the HTU21D code from 5.0.17 and the latest version. I did read here that this error may be due to not being able to connect to pigpiod, with the issue resolved by fixing the loopback device. Can you investigate with their recommendation of adding the following after self.pi = pigpio.pi()
:
self.logger.error("TEST: {}".format(pi.connected))
Saving, restarting the daemon, activating the sensor, and observing the log output.
OK, now that I can access the Pi, I could go forward with the sensor issue. This is what I got in the daemon log:
2018-01-04 20:19:17,035 - mycodo.daemon - INFO - Received command to terminate daemon 2018-01-04 20:19:17,124 - mycodo.daemon - INFO - All LCD controllers stopped 2018-01-04 20:19:17,126 - mycodo.daemon - INFO - All PID controllers stopped 2018-01-04 20:19:17,129 - mycodo.daemon - INFO - All Math controllers stopped 2018-01-04 20:19:17,165 - mycodo.input_1 - INFO - Deactivated in 41.1 ms 2018-01-04 20:21:11,660 - mycodo.daemon - INFO - Mycodo daemon v5.5.4 starting 2018-01-04 20:21:13,858 - mycodo.daemon - INFO - Anonymous statistics enabled 2018-01-04 20:21:14,181 - mycodo.daemon - INFO - Starting rpyc server 2018-01-04 20:21:16,667 - mycodo.output - INFO - Output controller activated in 625.8 ms 2018-01-04 20:21:17,170 - mycodo.daemon - INFO - All activated Timer controllers started 2018-01-04 20:21:17,792 - mycodo.input_1 - INFO - Activated in 406.9 ms 2018-01-04 20:21:18,648 - mycodo.daemon - ERROR - Could not activate Input controller with ID 5: 'HTU21DSensor' object has no attribute 'logger' Traceback (most recent call last): File "/var/mycodo-root/mycodo/mycodo_daemon.py", line 476, in controller_activate ready, cont_id) File "/var/mycodo-root/mycodo/controller_input.py", line 291, in init self.measure_input = HTU21DSensor(self.i2c_bus) File "/var/mycodo-root/mycodo/inputs/htu21d.py", line 51, in init self.logger.error("TEST: {}".format(pi.connected)) AttributeError: 'HTU21DSensor' object has no attribute 'logger' 2018-01-04 20:21:18,672 - mycodo.daemon - INFO - All activated Input controllers started 2018-01-04 20:21:18,674 - mycodo.daemon - INFO - All activated Math controllers started 2018-01-04 20:21:18,677 - mycodo.daemon - INFO - All activated PID controllers started 2018-01-04 20:21:18,679 - mycodo.daemon - INFO - All activated LCD controllers started 2018-01-04 20:21:19,509 - mycodo.conditional - INFO - Conditional settings refreshed 2018-01-04 20:21:19,512 - mycodo.conditional - INFO - Conditional controller activated in 329.0 ms 2018-01-04 20:21:19,514 - mycodo.daemon - INFO - Mycodo daemon v5.5.4 started in 7.852 seconds 2018-01-04 20:21:19,524 - mycodo.daemon - INFO - 38.82 MB RAM in use
This looks easily correctable to me...
In addition, I checked that issue you mentioned, but adding the two lines suggested to the interface settings did not help. Although my file only had 1 line,
source-directory /etc/network/interfaces.d
take off the "self" so it's:
logger.error("TEST: {}".format(pi.connected))
Can you also confirm pigpiod is running with ps aux | grep pigpiod
edit: whoops. wrong issue.
Here is the log snippet:
2018-01-05 07:58:50,761 - mycodo.daemon - ERROR - Could not activate Input controller with ID 5: name 'pi' is not defined
Traceback (most recent call last):
File "/var/mycodo-root/mycodo/mycodo_daemon.py", line 476, in controller_activate
ready, cont_id)
File "/var/mycodo-root/mycodo/controller_input.py", line 291, in __init__
self.measure_input = HTU21DSensor(self.i2c_bus)
File "/var/mycodo-root/mycodo/inputs/htu21d.py", line 51, in __init__
logger.error("TEST: {}".format(pi.connected))
NameError: name 'pi' is not defined
BTW, ps aux | grep pigpiod
returns:
pi 11259 0.0 0.4 6004 2248 pts/3 S+ 08:07 0:00 grep --color=auto pigpiod
Okay, 2 issues. pigpiod not running is a big problem that could fix the issue. Cron should be starting pigpiod at startup. Can you run sudo crontab -e
and see if that line is in there, then check if pigpiod exists with whereis pigpiod
then try to start pigpiod with sudo /usr/local/bin/pigpiod -s 1 &
The second issue is pi.connected
should be self.pi.connected
I remember trying self.pi.connected
, but then the original error returned. I'll double-check, though.
pigpiod is at the correct place, and the crontab is OK, as well.
On the other hand, starting pigpiod gives the following error:
pi@chz-112:~ $ sudo /usr/local/bin/pigpiod -s 1 &
[1] 19586
pi@chz-112:~ $ 2018-01-05 20:05:21 initMboxBlock: init mbox zaps failed
Can't initialise pigpio library
^C
[1]+ Done sudo /usr/local/bin/pigpiod -s 1
Feel free to SSH in again, I set it up again as last time.
This is a Pi Zero? I've never seen that error before. I'll look into it.
Yes, it's a Zero
I'm unable to access your mycodo install via HTTPS to the address you gave me. I want to disable the sensor and reboot to see if pigpiod will start.
OK, I searched for the error, and it can be caused by low GPU memory allocation. It can be because I decreased the split to 16 MB, being headless. So after running 'raspi-config' and setting it back to 64MB, rebooting resulted in 'Error 502: Bad Gateway Error'. Checking 'sudo service mycodo status', it failed. 'journalctl -xe' is full with timeout errors. Last time for the 504 Error, you increased those, maybe it is the same issue here?
Mycodo/install/mycodoflask.service has --timeout 90
in the gunicorn parameters. Try increasing this to 120. You'll also need to make sure it's using the new file. This is how I would do it.
sudo service mycodoflask stop
Edit 90 to 120, save, then:
sudo mycodo-commands web-server-update
sudo mycodo-commands web-server-restart
Still no good:
pi@chz-112:~ $ journalctl -xe
-- Support: https://www.debian.org/support
--
-- Unit nginx.service has finished starting up.
--
-- The start-up result is done.
jan 05 20:53:52 chz-112 systemd[1]: Started gunicorn daemon for Mycodo flask web user interface.
-- Subject: Unit mycodoflask.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit mycodoflask.service has finished starting up.
--
-- The start-up result is done.
jan 05 20:53:52 chz-112 sudo[1031]: pam_unix(sudo:session): session closed for user root
jan 05 20:54:00 chz-112 sudo[1068]: pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/usr/sbin/service mycodo start
jan 05 20:54:00 chz-112 sudo[1068]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
jan 05 20:54:09 chz-112 systemd[1]: Starting Mycodo server...
-- Subject: Unit mycodo.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit mycodo.service has begun starting up.
jan 05 20:54:20 chz-112 gunicorn[1064]: [2018-01-05 20:54:20 +0100] [1064] [INFO] Starting gunicorn 19.7.1
jan 05 20:54:20 chz-112 gunicorn[1064]: [2018-01-05 20:54:20 +0100] [1064] [INFO] Listening at: unix:/var/run/mycodoflask.sock (1064)
jan 05 20:54:20 chz-112 gunicorn[1064]: [2018-01-05 20:54:20 +0100] [1064] [INFO] Using worker: gthread
jan 05 20:54:20 chz-112 gunicorn[1064]: [2018-01-05 20:54:20 +0100] [1100] [INFO] Booting worker with pid: 1100
jan 05 20:54:21 chz-112 gunicorn[1064]: [2018-01-05 20:54:20 +0100] [1101] [INFO] Booting worker with pid: 1101
jan 05 20:54:22 chz-112 sshd[1098]: Received disconnect from 221.194.47.245 port 35900:11: [preauth]
jan 05 20:54:22 chz-112 sshd[1098]: Disconnected from 221.194.47.245 port 35900 [preauth]
jan 05 20:55:39 chz-112 systemd[1]: mycodo.service: Start operation timed out. Terminating.
jan 05 20:55:39 chz-112 systemd[1]: Failed to start Mycodo server.
-- Subject: Unit mycodo.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit mycodo.service has failed.
--
-- The result is failed.
jan 05 20:55:39 chz-112 systemd[1]: mycodo.service: Unit entered failed state.
jan 05 20:55:39 chz-112 systemd[1]: mycodo.service: Failed with result 'timeout'.
jan 05 20:55:39 chz-112 sudo[1068]: pam_unix(sudo:session): session closed for user root
jan 05 20:56:07 chz-112 sudo[1113]: pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/usr/sbin/service mycodo status
jan 05 20:56:07 chz-112 sudo[1113]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
jan 05 20:56:08 chz-112 sudo[1113]: pam_unix(sudo:session): session closed for user root
jan 05 20:56:21 chz-112 gunicorn[1064]: [2018-01-05 20:56:21 +0100] [1064] [CRITICAL] WORKER TIMEOUT (pid:1100)
jan 05 20:56:21 chz-112 gunicorn[1064]: [2018-01-05 20:56:21 +0100] [1064] [CRITICAL] WORKER TIMEOUT (pid:1101)
jan 05 20:56:21 chz-112 gunicorn[1064]: [2018-01-05 20:56:21 +0100] [1100] [INFO] Worker exiting (pid: 1100)
jan 05 20:56:21 chz-112 gunicorn[1064]: [2018-01-05 20:56:21 +0100] [1101] [INFO] Worker exiting (pid: 1101)
jan 05 20:56:22 chz-112 gunicorn[1064]: [2018-01-05 20:56:22 +0100] [1128] [INFO] Booting worker with pid: 1128
jan 05 20:56:22 chz-112 gunicorn[1064]: [2018-01-05 20:56:22 +0100] [1129] [INFO] Booting worker with pid: 1129
Then I increased the timeout to 150 secs, and here is the log:
pi@chz-112:~ $ journalctl -xe
jan 05 21:03:34 chz-112 systemd[1]: Starting A high performance web server and a reverse proxy server...
-- Subject: Unit nginx.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit nginx.service has begun starting up.
jan 05 21:03:36 chz-112 systemd[1]: Started A high performance web server and a reverse proxy server.
-- Subject: Unit nginx.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit nginx.service has finished starting up.
--
-- The start-up result is done.
jan 05 21:03:41 chz-112 systemd[1]: Started gunicorn daemon for Mycodo flask web user interface.
-- Subject: Unit mycodoflask.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit mycodoflask.service has finished starting up.
--
-- The start-up result is done.
jan 05 21:03:41 chz-112 sudo[1293]: pam_unix(sudo:session): session closed for user root
jan 05 21:03:49 chz-112 sudo[1330]: pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/usr/sbin/service mycodo start
jan 05 21:03:49 chz-112 sudo[1330]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
jan 05 21:03:58 chz-112 systemd[1]: Starting Mycodo server...
-- Subject: Unit mycodo.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit mycodo.service has begun starting up.
jan 05 21:04:10 chz-112 gunicorn[1326]: [2018-01-05 21:04:10 +0100] [1326] [INFO] Starting gunicorn 19.7.1
jan 05 21:04:10 chz-112 gunicorn[1326]: [2018-01-05 21:04:10 +0100] [1326] [INFO] Listening at: unix:/var/run/mycodoflask.sock (1326)
jan 05 21:04:10 chz-112 gunicorn[1326]: [2018-01-05 21:04:10 +0100] [1326] [INFO] Using worker: gthread
jan 05 21:04:10 chz-112 gunicorn[1326]: [2018-01-05 21:04:10 +0100] [1408] [INFO] Booting worker with pid: 1408
jan 05 21:04:10 chz-112 gunicorn[1326]: [2018-01-05 21:04:10 +0100] [1409] [INFO] Booting worker with pid: 1409
jan 05 21:04:24 chz-112 sshd[1418]: Received disconnect from 121.18.238.125 port 42275:11: [preauth]
jan 05 21:04:24 chz-112 sshd[1418]: Disconnected from 121.18.238.125 port 42275 [preauth]
jan 05 21:05:28 chz-112 systemd[1]: mycodo.service: Start operation timed out. Terminating.
jan 05 21:05:28 chz-112 systemd[1]: Failed to start Mycodo server.
-- Subject: Unit mycodo.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit mycodo.service has failed.
--
-- The result is failed.
jan 05 21:05:28 chz-112 systemd[1]: mycodo.service: Unit entered failed state.
jan 05 21:05:28 chz-112 systemd[1]: mycodo.service: Failed with result 'timeout'.
jan 05 21:05:28 chz-112 sudo[1330]: pam_unix(sudo:session): session closed for user root
I don't know what to look for, but the timeout is still after 90 secs, based on the timestamps.
Try adding TimeoutSec=120
to mycodoflask.service, so it looks like this:
[Service]
User=root
Group=mycodo
WorkingDirectory=/var/mycodo-root/mycodo
TimeoutSec=120
ExecStart=/var/mycodo-root/env/bin/gunicorn \
--workers 2 \
--worker-class gthread \
--threads 2 \
--timeout 120 \
--pid /var/lock/mycodoflask.pid \
--bind unix:/var/run/mycodoflask.sock start_flask_ui:app
Then:
sudo mycodo-commands web-server-update
sudo mycodo-commands web-server-restart
Error again:
pi@chz-112:~ $ journalctl -xe
--
-- Unit nginx.service has begun starting up.
jan 05 21:21:07 chz-112 systemd[1]: Started A high performance web server and a reverse proxy server.
-- Subject: Unit nginx.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit nginx.service has finished starting up.
--
-- The start-up result is done.
jan 05 21:21:12 chz-112 systemd[1]: Started gunicorn daemon for Mycodo flask web user interface.
-- Subject: Unit mycodoflask.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit mycodoflask.service has finished starting up.
--
-- The start-up result is done.
jan 05 21:21:13 chz-112 sudo[1721]: pam_unix(sudo:session): session closed for user root
jan 05 21:21:20 chz-112 sudo[1758]: pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/usr/sbin/service mycodo start
jan 05 21:21:20 chz-112 sudo[1758]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
jan 05 21:21:29 chz-112 systemd[1]: Starting Mycodo server...
-- Subject: Unit mycodo.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit mycodo.service has begun starting up.
jan 05 21:21:39 chz-112 gunicorn[1754]: [2018-01-05 21:21:38 +0100] [1754] [INFO] Starting gunicorn 19.7.1
jan 05 21:21:39 chz-112 gunicorn[1754]: [2018-01-05 21:21:39 +0100] [1754] [INFO] Listening at: unix:/var/run/mycodoflask.sock (1754)
jan 05 21:21:39 chz-112 gunicorn[1754]: [2018-01-05 21:21:39 +0100] [1754] [INFO] Using worker: gthread
jan 05 21:21:39 chz-112 gunicorn[1754]: [2018-01-05 21:21:39 +0100] [1788] [INFO] Booting worker with pid: 1788
jan 05 21:21:39 chz-112 gunicorn[1754]: [2018-01-05 21:21:39 +0100] [1789] [INFO] Booting worker with pid: 1789
jan 05 21:22:59 chz-112 systemd[1]: mycodo.service: Start operation timed out. Terminating.
jan 05 21:22:59 chz-112 systemd[1]: Failed to start Mycodo server.
-- Subject: Unit mycodo.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit mycodo.service has failed.
--
-- The result is failed.
jan 05 21:22:59 chz-112 systemd[1]: mycodo.service: Unit entered failed state.
jan 05 21:22:59 chz-112 systemd[1]: mycodo.service: Failed with result 'timeout'.
jan 05 21:22:59 chz-112 sudo[1758]: pam_unix(sudo:session): session closed for user root
jan 05 21:23:09 chz-112 gunicorn[1754]: [2018-01-05 21:23:09 +0100] [1754] [CRITICAL] WORKER TIMEOUT (pid:1788)
jan 05 21:23:09 chz-112 gunicorn[1754]: [2018-01-05 21:23:09 +0100] [1754] [CRITICAL] WORKER TIMEOUT (pid:1789)
jan 05 21:23:09 chz-112 gunicorn[1754]: [2018-01-05 21:23:09 +0100] [1788] [INFO] Worker exiting (pid: 1788)
jan 05 21:23:09 chz-112 gunicorn[1754]: [2018-01-05 21:23:09 +0100] [1789] [INFO] Worker exiting (pid: 1789)
jan 05 21:23:10 chz-112 gunicorn[1754]: [2018-01-05 21:23:10 +0100] [1824] [INFO] Booting worker with pid: 1824
jan 05 21:23:10 chz-112 gunicorn[1754]: [2018-01-05 21:23:10 +0100] [1825] [INFO] Booting worker with pid: 1825
Set them both ridiculously high, like 500 and see what happens.
Also try adding Type=forking
so it looks like this (try removing the TimeoutSec
option):
[Service]
Type=forking
User=root
Group=mycodo
WorkingDirectory=/var/mycodo-root/mycodo
ExecStart=/var/mycodo-root/env/bin/gunicorn \
--workers 2 \
--worker-class gthread \
--threads 2 \
--timeout 500 \
--pid /var/lock/mycodoflask.pid \
--bind unix:/var/run/mycodoflask.sock start_flask_ui:app
You can also try something like this with just one thread and the default worker class:
[Service]
Type=forking
User=root
Group=mycodo
WorkingDirectory=/var/mycodo-root/mycodo
ExecStart=/var/mycodo-root/env/bin/gunicorn \
--workers 1 \
--timeout 500 \
--pid /var/lock/mycodoflask.pid \
--bind unix:/var/run/mycodoflask.sock start_flask_ui:app
Starting mycodo still fails after 90 secs:
pi@chz-112:~ $ journalctl -xe
--
-- Unit nginx.service has finished shutting down.
jan 05 21:31:03 chz-112 systemd[1]: Starting A high performance web server and a reverse proxy server...
-- Subject: Unit nginx.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit nginx.service has begun starting up.
jan 05 21:31:05 chz-112 systemd[1]: Started A high performance web server and a reverse proxy server.
-- Subject: Unit nginx.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit nginx.service has finished starting up.
--
-- The start-up result is done.
jan 05 21:31:10 chz-112 systemd[1]: Started gunicorn daemon for Mycodo flask web user interface.
-- Subject: Unit mycodoflask.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit mycodoflask.service has finished starting up.
--
-- The start-up result is done.
jan 05 21:31:11 chz-112 sudo[1995]: pam_unix(sudo:session): session closed for user root
jan 05 21:31:17 chz-112 sudo[2032]: pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/usr/sbin/service mycodo start
jan 05 21:31:17 chz-112 sudo[2032]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
jan 05 21:31:26 chz-112 systemd[1]: Starting Mycodo server...
-- Subject: Unit mycodo.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit mycodo.service has begun starting up.
jan 05 21:31:38 chz-112 gunicorn[2028]: [2018-01-05 21:31:38 +0100] [2028] [INFO] Starting gunicorn 19.7.1
jan 05 21:31:38 chz-112 gunicorn[2028]: [2018-01-05 21:31:38 +0100] [2028] [INFO] Listening at: unix:/var/run/mycodoflask.sock (2028)
jan 05 21:31:38 chz-112 gunicorn[2028]: [2018-01-05 21:31:38 +0100] [2028] [INFO] Using worker: gthread
jan 05 21:31:38 chz-112 gunicorn[2028]: [2018-01-05 21:31:38 +0100] [2062] [INFO] Booting worker with pid: 2062
jan 05 21:31:38 chz-112 gunicorn[2028]: [2018-01-05 21:31:38 +0100] [2063] [INFO] Booting worker with pid: 2063
jan 05 21:32:56 chz-112 systemd[1]: mycodo.service: Start operation timed out. Terminating.
jan 05 21:32:56 chz-112 systemd[1]: Failed to start Mycodo server.
-- Subject: Unit mycodo.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit mycodo.service has failed.
--
-- The result is failed.
jan 05 21:32:56 chz-112 systemd[1]: mycodo.service: Unit entered failed state.
jan 05 21:32:56 chz-112 systemd[1]: mycodo.service: Failed with result 'timeout'.
jan 05 21:32:56 chz-112 sudo[2032]: pam_unix(sudo:session): session closed for user root
Okay. That indicates you may need the TimeoutSec
option to remain.
What I don't understand, how this timeout issue came back again after resetting the GPU memory-split and then rebooting?
Maybe I'll leave it now, and try to start from scratch again tomorrow....
Perhaps you need to execute some command for your change to take effect. It's a strange one.
Just refreshed the browser now, and the error disappeared, and the web-interface works... but the daemon indicator is red, which is expected.
OK, I sleep on it and try it tomorrow with fresh mind...
Are you using the default 5.5.5 mycodoflask.service file, or one of the changes?
Okay. Seems you've figured it out, but we may be able to make the service file better for low-resource boards like the Zero.
I'm not sure about figuring out... Here is where I stand now:
Did fresh install of latest raspbian stretch lite, installed Mycodo as usual. Setup included 5 cycles of connection tries. Then I got 502 Error from the weg-gui, so I rebooted. After reboot, the mycodo service failed to start due to timeout. However, the web-gui started at this time. Then I issued sudo service mycodo start
form the command line, and the daemon started in 40 secs! This was all done with the default settings.
Now I'll have a few things to take care of, but later this evening will try to add sensors, and check if the original error returns.
So... apparently the original issue is resolved. Rookie mistake, the HTU sensor was not connected properly. On deactivation, it gave the error:
2018-01-06 17:30:49,115 - mycodo.input_5 - ERROR - StopIteration raised. Possibly could not read input. Ensure it's connected properly and detected.
Looking at the i2cdetect, indeed nothing showed up, and redoing the connections solved the problem.
On the other hand, by disconnecting the wires on the running Pi, it caused it to freeze. Which in turn resulted in daemon timeout, which could be overcome by the manual start of the daemon. So the secondary problem still persists.
So when you disconnected SDA/SCL it caused the daemon to freeze? or stop? It wasn't detected with ps aux | grep mycodo_daemon
?
I'm not really sure what could cause that, but disconnecting any wires from the PI while it's on can be a risky thing to do.
I have exception handling in the HTU sensor module, so I'm not really sure how, if it's the sensor disconnect fault, that it can be prevented software-wire. Let me know if you get any more info about what's happening to the daemon.
I think the Pi itself froze, in my experience it doesn't really like pulling wires off the GPIO headers
I can also imagine the Zero being more sensitive than the larger boards to electrical disturbances like that. So, I suppose we've really fixed all the issues that are able to be fixed from this thread?
I think so, the daemon timeout is a different thing, I'll start a new issue if there are more troubles.
Mycodo Issue Report:
Problem Description
No measurement after setting up Mycodo on another PiZero, and transferring the SD card. All else seems to be working.
Errors
Daemon log:
Additional Notes
The previous version of Mycodo running this hardware was OK. I don't think that will be helpful, but that version was 4.0.???