programmatically reboot pi...but only if generator is not running #1316
Replies: 8 comments 8 replies
-
|
Hi @billpribyl This thread discusses how to get the base status of the generator: some examples of using the web API are here: Let me know if you have any questions. |
Beta Was this translation helpful? Give feedback.
-
|
sorry i get:
curl http://192.168.x.x:8000/cmd/getbase
curl: (7) Failed to connect to 192.168.x.x port 8000 after 0 ms: Couldn't
connect to server
…On Mon, Sep 1, 2025 at 3:35 PM jgyates ***@***.***> wrote:
Hi @billpribyl <https://github.com/billpribyl>
This thread discusses how to get the base status of the generator:
#1303 <#1303>
some examples of using the web API are here:
https://github.com/jgyates/genmon/wiki/Appendix-C--Interfacing-Generator-Monitor-to-External-Applications#web-api
Let me know if you have any questions.
—
Reply to this email directly, view it on GitHub
<#1316 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQJPD276QERBKV2TTUEMR533QSUZJAVCNFSM6AAAAACFLFDS3CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRXHEZTANY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Did you replace the x.x with your genmon's IP? The 0ms is the primary reason I'm guessing that. Also if you enabled HTTPS you would need to change the http at the front and probably the 8000 port number. |
Beta Was this translation helpful? Give feedback.
-
|
are you using https or http? If you are using a user name and password then https is enabled so you sould need to use the https url and a username and password. Also, https does not use 8000 so it would be When I do this: curl http://192.168.1.14:8000/cmd/getbase I get a response. Genmon uses port 8000 for non secure and the default port for secure access. |
Beta Was this translation helpful? Give feedback.
-
|
Using https, so i've removed the :8000 as follows:
curl -k https://192.168.x.x/cmd/getbase
and now i get back javascript and the html form for the genmon login page
…On Mon, Sep 1, 2025 at 4:33 PM jgyates ***@***.***> wrote:
are you using https or http?
The url given to curl must be the same as the one you use to access genmon
via the browser.
If you are using a user name and password then https is enabled so you
sould need to use the https url and a username and password. Also, https
does not use 8000 so it would be
https://http://192.168.x.x/cmd/getbase
When I do this:
curl http://192.168.1.14:8000/cmd/getbase
I get a response.
Genmon uses port 8000 for non secure and the default port for secure
access.
—
Reply to this email directly, view it on GitHub
<#1316 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQJPD24PRSFNSFP555L365L3QS3RDAVCNFSM6AAAAACFLFDS3CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRXHE3DAOA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
also note, I've tried with the curl -u option but same result
…On Mon, Sep 1, 2025 at 4:49 PM Bill Pribyl ***@***.***> wrote:
Using https, so i've removed the :8000 as follows:
curl -k https://192.168.x.x/cmd/getbase
and now i get back javascript and the html form for the genmon login page
On Mon, Sep 1, 2025 at 4:33 PM jgyates ***@***.***> wrote:
> are you using https or http?
> The url given to curl must be the same as the one you use to access
> genmon via the browser.
>
> If you are using a user name and password then https is enabled so you
> sould need to use the https url and a username and password. Also, https
> does not use 8000 so it would be
>
> https://http://192.168.x.x/cmd/getbase
>
> When I do this:
>
> curl http://192.168.1.14:8000/cmd/getbase
>
> I get a response.
>
> Genmon uses port 8000 for non secure and the default port for secure
> access.
>
> —
> Reply to this email directly, view it on GitHub
> <#1316 (reply in thread)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AQJPD24PRSFNSFP555L365L3QS3RDAVCNFSM6AAAAACFLFDS3CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRXHE3DAOA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
Beta Was this translation helpful? Give feedback.
-
|
Have you tried the python script in the link above? you could replace the "/cmd/status_json" with "/cmd/getbase" in the example. |
Beta Was this translation helpful? Give feedback.
-
|
I validated that curl with username and password do not work however if you use the python script it does: import requests
url = 'https://192.168.11.22' # change to your pi IP address
values = {'username': 'admin', # change admin to your username
'password': 'adminpassword'} # change adminpassword to your password
try:
session = requests.Session()
# disable SSL checking for self signed keys
# remove if using user generated keys
session.verify = False
r = session.post(url, data=values)
#print r.text
# get the status data via the same session we used to login
r = session.get(url + "/cmd/getbase")
print(r.text)
except Exception as e1:
print ("Error: " + str(e1))NOTE: change to match your IP address, username and password then save the file. If you save this to a file named getstatus.py, then type this It will return the one word status. Note that if you are not using a valid certificste you can use this command to ignore warnings from the python requests library Let me know if you have any issues or questions. I can add the curl / https javascript issue to the known issues list and look into this issue but I don't know that I will have a quick fix as javascript is not my expertise. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, I'm getting a mostly expected result from the script. What's
unexpected is that it was taking 4 or 5 minutes to get a result back. And I
was consistently receiving two emails after launching the script:
"Generator Monitor is not communicating with the controller" followed in a
minute or so by "Generator Monitor communications with the controller has
been restored." So something about running this Python script seemed to be
requiring more resources than available.
BUT then I had the bright idea to reboot my pi...and it ran in less than 3
seconds! I guess this demonstrates why I want to reboot periodically. It
would be really cool to solve the underlying memory leak (?) or whatever is
causing this behavior...But I'm good for now.
…On Mon, Sep 1, 2025 at 6:23 PM jgyates ***@***.***> wrote:
I validated that curl with username and password do not work however if
you use the python script it does:
import requestsurl = 'https://192.168.11.22' # change to your pi IP addressvalues = {'username': 'admin', # change admin to your username
'password': 'adminpassword'} # change adminpassword to your password
try:
session = requests.Session()
# disable SSL checking for self signed keys
# remove if using user generated keys
session.verify = False
r = session.post(url, data=values)
#print r.text
# get the status data via the same session we used to login
r = session.get(url + "/cmd/getbase")
print(r.text)except Exception as e1:
print ("Error: " + str(e1))
NOTE: change to match your IP address, username and password then save the
file.
If you save this to a file named getstatus.py, then type this
python3 ./getstatus.py
It will return the one word status. Note that if you are not using a valid
certificste you can use this command to ignore warnings from the python
requests library
python3 -W ignore ./getstatus.py
Let me know if you have any issues or questions. I can add the curl /
https javascript issue to the known issues list and look into this issue
but I don't know that I will have a quick fix as javascript is not my
expertise.
—
Reply to this email directly, view it on GitHub
<#1316 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQJPD2ZAE7SIDXQTEGU43D33QTIQNAVCNFSM6AAAAACFLFDS3CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRXHE4TSMQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Generally the "Generator Monitor is not communicating with the controller" message is due to faulty comms. If you are using wifi, check your signal strength. You can see the communication stats on the Monitor page of the web interface. This can provide some clues regarding intermittent communication issues. If you want to send your logs via the about page I can take a look and see if anything looks odd. History on this project tends to show problems like this fall into a few categories:
for a wired serial setup, you should get zero comm errors on the Monitor page. Here is mine: Communication Stats : If you are using Ethernet for serial over TCP then you should also expect zero comm errors. If you are using wifi for serial over TCP then a marginal wifi signal strength can cause transmit retries on the wifi and this can cause modbus traffic to get out of sync and some adjust ments to the modbus timeout can be made on the Advanced Settings page. In short, I would need to see your logs which would give more insight into your issue. If you have to reboot your pi every day, then something is definitely wrong. This is not the normal behavior of genmon. Let me know if you want to troubleshoot this issue. |
Beta Was this translation helpful? Give feedback.
-
|
At the moment i'm showing 0 comms errors:
Communication Stats :
Packet Count : M: 126144, S: 126143
CRC Errors : 0
CRC Percent Errors : 0.00%
Timeout Errors : 0
Timeout Percent Errors : 0.00%
Modbus Exceptions : 10
Validation Errors : 0
Sync Errors : 0
Invalid Data : 0
Discarded Bytes : 0
Comm Restarts : 0
Packets Per Second : 63.85
Average Transaction Time : 0.0309 sec
Modbus Transport : Serial
Serial Data Rate : 9600
sent my logs.
…On Mon, Sep 1, 2025 at 7:50 PM jgyates ***@***.***> wrote:
Generally the "Generator Monitor is not communicating with the controller"
message is due to faulty comms. If you are using wifi, check your signal
strength. You can see the communication stats on the Monitor page of the
web interface. This can provide some clues regarding intermittent
communication issues.
If you want to send your logs via the about page I can take a look and see
if anything looks odd.
History on this project tends to show problems like this fall into a few
categories:
1. marginal wifi signal (if you are using serial over TCP)
2. cabeling issues which can include grounding problems.
3. in rare instances it could be caused by other software installed on
the pi that is trying to use the serial port (only for direct serial , not
serial over TCP), but this is only the case if you have installed something
else that uses the serial port or not used the install script to install
genmon.
for a wired serial setup, you should get zero comm errors on the Monitor
page. Here is mine:
Communication Stats :
Packet Count : M: 10850407, S: 10850406
CRC Errors : 0
CRC Percent Errors : 0.00%
Timeout Errors : 0
Timeout Percent Errors : 0.00%
Modbus Exceptions : 0
Validation Errors : 0
Sync Errors : 0
Invalid Data : 0
Discarded Bytes : 0
Comm Restarts : 0
Packets Per Second : 62.42
Average Transaction Time : 0.0314 sec
Modbus Transport : Serial
Serial Data Rate : 9600
If you are using Ethernet for serial over TCP then you should also expect
zero comm errors. If you are using wifi for serial over TCP then a marginal
wifi signal strength can cause transmit retries on the wifi and this can
cause modbus traffic to get out of sync and some adjust ments to the modbus
timeout can be made on the Advanced Settings page.
In short, I would need to see your logs which would give more insight into
your issue.
If you have to reboot your pi every day, then something is definitely
wrong. This is not the normal behavior of genmon.
Let me know if you want to troubleshoot this issue.
—
Reply to this email directly, view it on GitHub
<#1316 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQJPD23PT2V7OYLEDGDTA2D3QTSWVAVCNFSM6AAAAACFLFDS3CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRYGAZDSMY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I received you logs. A few comments: I did notice some errors in the file /var/log/myserial.log 2025-08-21 19:40:57,620 : Resetting SerialDevice:ReadThread Error: /dev/serial0:device reports readiness to read but returned no data (device disconnected or multiple access on port?) : myserial.py:161 These errors should be occurring. This typically occurs when either multiple software entities are trying to access the port, or if there are power issues with the pi (some parts of the pi SoC get shut down when this occurs). Also in /var/log/mymodbus.log you have these errors: 2025-09-01 19:01:28,630 : Error: timeout receiving slave packet for register 0009 Buffer: 3, sequence 174665 These timeouts could be caused by wifi retries. Note that the date an time are different on the errors in myserial.log and mymodbus.log. If you can look at the time of the email you received with the communication notice and see if it matches the times on any of the above errors that may point us in the right direction. You submission also indicates you have a pi zero 2 W. This is not a problem per se however I have seen issues with Pi zeros when powered from the molex connector. I am not sure what is happening with the pi zero when powered from the molex but my theory is that the pi zero has more active power management and the molex power may be triggering some of these power management functions in the system on a chip. If that is occurring it could cause the errors in /var/log/myserial.log Another thing to look at is when this occurs again, before you reboot look on the Monitor page and send the data for both the Comm Stats and the Platform Stats (or just send you logs again). I want to see if you are getting anything besides a timeout error (I am guessing not but just want to make sure) and I also want to see if your pi has any issues with these entries: You submission shows them as OK but a reboot will reset these flags so we want to look at them after the issue occurs but before a reboot. |
Beta Was this translation helpful? Give feedback.
-
|
Not a lot of progress on my side, but I can say that
1. I do not believe that I am powering from the Molex; there is a
separate power connection that comes off of the generator battery.
2. I don't have a WiFi signal problem any more, because I installed a
new access point in my back yard. Last time I checked the signal was -54db.
3. (Probably obvious, but I am not running serial over Ethernet)
I ran the Python script again tonight and it had the same effect of nearly
killing all communications and making it impossible to log into the GUI. I
happened to have an ssh account into the pi but it takes minutes to run the
simplest commands. I was able to get a tail on mymodbus.log and
myserial.log, and there are errors like you showed above.
Any suggestions for more future log inspections? I'm going to reboot, but
I'm sure I will have another opportunity to collect data...
…On Mon, Sep 1, 2025 at 10:35 PM jgyates ***@***.***> wrote:
I received you logs. A few comments:
I did notice some errors in the file /var/log/myserial.log
2025-08-21 19:40:57,620 : Resetting SerialDevice:ReadThread Error:
/dev/serial0:device reports readiness to read but returned no data (device
disconnected or multiple access on port?) : myserial.py:161
2025-08-30 07:00:25,241 : Resetting SerialDevice:ReadThread Error:
/dev/serial0:device reports readiness to read but returned no data (device
disconnected or multiple access on port?) : myserial.py:161
2025-08-30 07:12:05,926 : Resetting SerialDevice:ReadThread Error:
/dev/serial0:device reports readiness to read but returned no data (device
disconnected or multiple access on port?) : myserial.py:161
2025-09-01 08:54:53,714 : Resetting SerialDevice:ReadThread Error:
/dev/serial0:device reports readiness to read but returned no data (device
disconnected or multiple access on port?) : myserial.py:161
These errors should be occurring.
This typically occurs when either multiple software entities are trying to
access the port, or if there are power issues with the pi (some parts of
the pi SoC get shut down when this occurs).
Also in /var/log/mymodbus.log you have these errors:
2025-09-01 19:01:28,630 : Error: timeout receiving slave packet for
register 0009 Buffer: 3, sequence 174665
2025-09-01 19:02:02,189 : Buffer = [0x9d,0x03,0x02,0x00,0xf1,0xa9]
2025-09-01 19:02:37,295 : Error: timeout receiving slave packet for
register 05f1 Buffer: 0, sequence 174666
2025-09-01 19:02:54,819 : Buffer = [0x9d,0x03,0x02]
2025-09-01 19:03:24,897 : Error: timeout receiving slave packet for
register 0238 Buffer: 2, sequence 174667
2025-09-01 19:03:34,080 : Buffer = [0x9d,0x03,0x02,0x00,0x00]
2025-09-01 19:08:53,610 : Error: timeout receiving slave packet for
register 05f1 Buffer: 1, sequence 180072
2025-09-01 19:10:01,425 : Buffer = [0x9d,0x03,0x02,0x3f,0x3d,0xb8,0x79]
These timeouts could be caused by wifi retries.
Note that the date an time are different on the errors in myserial.log and
mymodbus.log. If you can look at the time of the email you received with
the communication notice and see if it matches the times on any of the
above errors that may point us in the right direction.
You submission also indicates you have a pi zero 2 W. This is not a
problem per se however I have seen issues with Pi zeros when powered from
the molex connector. I am not sure what is happening with the pi zero when
powered from the molex but my theory is that the pi zero has more active
power management and the molex power may be triggering some of these power
management functions in the system on a chip. If that is occurring it could
cause the errors in /var/log/myserial.log
Another thing to look at is when this occurs again, before you reboot look
on the Monitor page and send the data for both the Comm Stats and the
Platform Stats (or just send you logs again). I want to see if you are
getting anything besides a timeout error (I am guessing not but just want
to make sure) and I also want to see if your pi has any issues with these
entries:
Pi CPU Frequency Throttling : OK
Pi ARM Frequency Cap : OK
Pi Undervoltage : OK
You submission shows them as OK but a reboot will reset these flags so we
want to look at them after the issue occurs but before a reboot.
—
Reply to this email directly, view it on GitHub
<#1316 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQJPD2ZHKX7PLO6DPM3CXRT3QUF7JAVCNFSM6AAAAACFLFDS3CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRYGEYTKMA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
This may not fix you issue, but try enabling the setting "Optimize for slower CPUs" on the Settings page. The setting optimizes the polling of modbus / serial to compensate for slower CPUs like the Pi Zero. That may make the pi more responseive. If it does not then you may want to look at your process and see what is taking most of the CPU time. On a pi 3B (which is faster than the pi zero) without the "Optimize for slower CPU" setting enabled, my pi has about 7% of the CPU utilized. You can see the CPU utilization on the Monitor page in the web UI under Platform Stats. |
Beta Was this translation helpful? Give feedback.
-
|
FYI, your submission from earlier had the CPU utilization at about 15% |
Beta Was this translation helpful? Give feedback.
-
|
I’ll try that setting, although I have to say, it’s been extremely
responsive immediately following reboot…
…On Wed, Sep 3, 2025 at 8:33 PM jgyates ***@***.***> wrote:
FYI, your submission from earlier had the CPU utilization at about 15%
—
Reply to this email directly, view it on GitHub
<#1316 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQJPD235PGNG3ERQ5OMG56D3Q6JIBAVCNFSM6AAAAACFLFDS3CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMZQGE4TONY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm finding that I periodically need to reboot my pi to clear up performance problems when connecting to genmon via GUI and/or SSH. I was thinking about putting a sudo reboot now into cron, but I don't think I want to reboot if the generator is running. Is there a quick API test I can make that will let me know if a reboot is safe?
Beta Was this translation helpful? Give feedback.
All reactions