search

kizniche / Mycodo

An environmental monitoring and regulation system
http://kylegabriel.com/projects/
GNU General Public License v3.0
2.93k stars 491 forks source link

HTU21D error #349

Closed zsole2 closed 6 years ago

zsole2 commented 6 years ago

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:

2017-12-17 16:18:46,306 - mycodo.inputs.htu21d - ERROR - HTU21DSensor raised an exception when taking a reading: 'NoneType' object has no attribute 'sendall' Traceback (most recent call last): File "/var/www/mycodo/mycodo/inputs/htu21d.py", line 142, in read self._temperature) = self.get_measurement() File "/var/www/mycodo/mycodo/inputs/htu21d.py", line 101, in get_measurement self.htu_reset() File "/var/www/mycodo/mycodo/inputs/htu21d.py", line 153, in htu_reset handle = self.pi.i2c_open(self.I2C_bus_number, self.address) # open i2c bus File "/usr/local/lib/python2.7/dist-packages/pigpio.py", line 2585, in i2c_open self.sl, _PI_CMD_I2CO, i2c_bus, i2c_address, 4, extents)) File "/usr/local/lib/python2.7/dist-packages/pigpio.py", line 1006, in _pigpio_command_ext sl.s.sendall(ext) AttributeError: 'NoneType' object has no attribute 'sendall'

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.???

zsole2 commented 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.

kizniche commented 6 years ago

Thanks. I'll look into it.

kizniche commented 6 years ago

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.

zsole2 commented 6 years ago

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

kizniche commented 6 years ago

take off the "self" so it's:

logger.error("TEST: {}".format(pi.connected))
kizniche commented 6 years ago

Can you also confirm pigpiod is running with ps aux | grep pigpiod

kizniche commented 6 years ago

edit: whoops. wrong issue.

zsole2 commented 6 years ago

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

kizniche commented 6 years ago

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

zsole2 commented 6 years ago

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.

kizniche commented 6 years ago

This is a Pi Zero? I've never seen that error before. I'll look into it.

zsole2 commented 6 years ago

Yes, it's a Zero

kizniche commented 6 years ago

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.

zsole2 commented 6 years ago

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?

kizniche commented 6 years ago

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
zsole2 commented 6 years ago

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.

kizniche commented 6 years ago

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
zsole2 commented 6 years ago

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
kizniche commented 6 years ago

Set them both ridiculously high, like 500 and see what happens.

kizniche commented 6 years ago

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
kizniche commented 6 years ago

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
zsole2 commented 6 years ago

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
kizniche commented 6 years ago

Okay. That indicates you may need the TimeoutSec option to remain.

zsole2 commented 6 years ago

What I don't understand, how this timeout issue came back again after resetting the GPU memory-split and then rebooting?

zsole2 commented 6 years ago

Maybe I'll leave it now, and try to start from scratch again tomorrow....

kizniche commented 6 years ago

Perhaps you need to execute some command for your change to take effect. It's a strange one.

zsole2 commented 6 years ago

Just refreshed the browser now, and the error disappeared, and the web-interface works... but the daemon indicator is red, which is expected.

zsole2 commented 6 years ago

OK, I sleep on it and try it tomorrow with fresh mind...

kizniche commented 6 years ago

Are you using the default 5.5.5 mycodoflask.service file, or one of the changes?

kizniche commented 6 years ago

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.

zsole2 commented 6 years ago

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.

zsole2 commented 6 years ago

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.

kizniche commented 6 years ago

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.

zsole2 commented 6 years ago

I think the Pi itself froze, in my experience it doesn't really like pulling wires off the GPIO headers

kizniche commented 6 years ago

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?

zsole2 commented 6 years ago

I think so, the daemon timeout is a different thing, I'll start a new issue if there are more troubles.