GivEnergy - Battery/Inverter + home power things

Share your Projects! Custom Integrations
, ,
103

This is a great project. Thanks for all the hard work so far. Successfully running off a raspi2.

Any thoughts on how I might achieve what I’m looking to do (through node red or some such)?

I’d like to stop using the battery during my off peak hours and resume when peak hours resume. Currently I can stop the discharge by adjusting the reserve amount to a high figure, but no matter what I try I can’t then resume the discharge until I reset all settings in the givenergy portal. Any ideas?

EDIT: Looks like I was just being impatient. The MQTT entities work great and just toggling ‘Enable Discharge’ has the desired effect.

104

how have you got it going. trying to control the same setup. are you using rest or mqtt? elaborate a bit on the control setup please.

105

@britkat thanks for all your hard work here, I setup the docker, pointed it at MQTT and my inverter, and then things all started working.

The only outstanding problem, is the seeming random 0-values that are posted to MQTT, which are really messing with my statistics, see image here:

image
image1878×980 59.8 KB

This is showing total discharge, because the problem is easiest to see, however I’ve seen several sensors posting extreme values, including PV power.

Is there a way we can work to filter them out?
Either at the GivTCP level, or within HA?

There doesn’t seem to be much activity with issues/PRs on the GivTCP project, so didn’t want to start over there.

106

Same here. Not that ofter though. It may happen once or twice a day at random times, but more ofter early morning. My setup is the following:

  • HA and GivTCP docker containers are running on the Mac Mini 2012 with i5-3210M CPU
  • MQTT server is running on Raspberry Pi Zero w
107

It seems to have settled to the same frequency as you suggested, once or twice a day.

There appears to be a suggestion that sometimee the underlying call to the inverter fails, but the numbers are still being reported to HA.

108

I ended up setting a node-red filter in-between of GivTCP MQTT server and and MQTT server running on Raspberry. It helps to filter out those “zero” values. The filter is rather simple, it compares the receipt value with previous value and if absolute difference is greater than 10, the filter drops the latests reading. But I still find myself in need to restart all servers to get GivTCP behave consistently. Potentially because of the filter… Would be nice to debug the behaviour on the Modbus protocol level… I’ll see if I can capture debug log of the event.

109

The modbus level data is handled by the givenergy-modbus library (https://github.com/dewet22/givenergy-modbus). There is minimal filtering happening inside GivTCP. In my early versions (pre-library) there was some. The challenge is how to drop the outliers in a stateless manner. Without knowing that its a big drop to zero from a larger value, do we filter out all zeros (as that can be a valid response). I’ve tended to live with it as it doesn’t happen too frequently for me. But it is annoying!
Any suggestions on how to handle them would be appreciated!

110

On a seperate note it is now possible to run the docker image as an Addon in HA. If you add:

To the Addon Store repo list you can install it inside the supervisor. As long as you are running MQTT addon already, its a pretty seamless way of integrating into HA.

111

I don’t believe the reserve battery level can be set below 4%? So when the battery SOC reports 0% is that not an indicator that the data is bad?
It certainly would appear to be in my system.

Clearly doesn’t help anyone without a battery, but the issues mostly seem to affect my battery reporting.

112

Hi. I’m looking to do the same thing. What automations did you create to get this working if you don’t mind sharing? Cheers

113

I’m soak testing a version which does some filtering of values to remove spurious data. Next release of GivTCP will have a number of new features inc filtering, web dashboard, Octopus Go/Economy 7 cost tracking and multiple invertor handling.

Watch this space

1 Like
114

New version of GivTCP now available 1.1.4 on GitHub, dockerhub and as an addon

115

I have installed GivTCP v1.1.5 as an Add-on. I have configured it to write to my HA MQTT broker by specifying the MQTT_address as the HA IP address. The log shows it is finding the inverter and getting some data. But the MQTT explorer shows no topics published. I have set Log_Level to debug and get:

INFO:GivTCP:In wait loop
INFO:GivTCP:Publishing: GivEnergy/CE2215G174/Last_Updated_Time
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:Publishing: GivEnergy/CE2215G174/status
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:Publishing: GivEnergy/CE2215G174/Energy
INFO:GivTCP:Prepping Total for publishing
INFO:GivTCP:Prepping Today for publishing
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:Publishing: GivEnergy/CE2215G174/Power
INFO:GivTCP:Prepping Power for publishing
INFO:GivTCP:Prepping Flows for publishing
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping
INFO:GivTCP:No command topic avaiable, skipping

A device GivTCP has been created with 6 entities (running, Version etc) all disabled.

Any pointers would be appreciated. Many thanks - it looks to have huge promise.

116

I don’t have a version 1.1.5, latest release is 1.1.4…
Are you using the addon from my repo: https://github.com/britkat1980/giv_tcp ??

I think s0ckhamster has a repo forked from mine which is 1.1.5, perhaps that’s where the discrepancy. Those logs look like a previous version to me.

117

Thanks for the heads up. I think you are right although my install was shown as britkat1980, it perhaps wasn’t. I have uninstalled, rebooted and reinstalled, now showing as v1.1.4 but I get the same errors. I am not totally convinced that the previous install has been completely purged. So I need to investigate further. Thanks agains

118

@britkat Hi Mark, hope you can help. My Givtcp REST setup was working fine until my router threw a wobbly yesterday and it seemed to be looping round presenting old data. As I hadn’t updated since April I deleted the docker image and pulled the :latest tag from hub.docker. Now I keep getting an error when bringing the container up. It seems to think I am running MQTT but I have MQTT_OUTPUT=False in the compose. The failing line is 193 in startup.py

2022-09-27 07:13:23,721 - startup - [CRITICAL] - No config directory exists, so creating it…
2022-09-27 07:13:23,721 - startup - [CRITICAL] - Running Redis
2022-09-27 07:13:23,722 - startup - [CRITICAL] - Running RQ Dashboard on port 9181
2022-09-27 07:13:23,722 - startup - [CRITICAL] - Setting up invertor: 1 of 1
2022-09-27 07:13:23,726 - startup - [CRITICAL] - Recreating settings.py for invertor 1
2022-09-27 07:13:23,727 - startup - [CRITICAL] - Running RQ worker to queue and process givernergy-modbus calls
2022-09-27 07:13:23,727 - startup - [CRITICAL] - Running Invertor read loop every 5s
2022-09-27 07:13:23,727 - startup - [CRITICAL] - Starting Gunicorn on port 6345
2022-09-27 07:13:23,743 - startup - [CRITICAL] - Setting daily charge target forecast job to run at: 00:20
Traceback (most recent call last):
File “/app/startup.py”, line 193, in
if os.getenv(‘MQTT_ADDRESS’)==“127.0.0.1” and not mqttBroker.poll()==None:
NameError: name ‘mqttBroker’ is not defined

I’ve had a look at startup.py and the failing block looks different from the other similar checks done above it because they are all under ELIFs in the inverter loop whereas this is outside as a stand-alone IF. Python destroys my brain so I don’t know if that’s wrong or not…

My compose file is:

version: “3.5”
services:
givtcp:
image: britkat/giv_tcp-ma:latest
container_name: givtcp
ports:
- “6345:6345/tcp”
environment:
- INVERTOR_IP=192.168.100.159
- NUMBATTERIES=1
- MQTT_OUTPUT=False
restart: “no”

Cheers, Mike

119

Although… In or out it shouldn’t ever see the address as 127.0.0.1 so I don’t know why it seems to try and restart the broker… I never realised how dependent I’d become on your code until it’s not there - it’s killing me :slight_smile: Can’t be dealing with the web or mobile slow updates from the stock apps.

120

The latest version is a major update v2.0. The best bet is to use the new compose file located in the GitHub. There are new ENV used so the error is probably not related to MQTT but rather the differences in the compose.

121

Hi Mark thanks. As far as I know I am not using the web dash so am I fine to exclude all the optional block and any MQTT parms or ports?

I can see changes for inverter, battery and cache so will apply those and give it a go.

122

It now gets further and kind of appears to start but it keeps getting worker timeouts:
Recreating givtcp_GivTCP_1 … done
Attaching to givtcp_GivTCP_1
GivTCP_1 | 2022-09-27 09:51:13,244 - startup - [CRITICAL] - No config directory exists, so creating it…
GivTCP_1 | 2022-09-27 09:51:13,245 - startup - [CRITICAL] - Running Redis
GivTCP_1 | 2022-09-27 09:51:13,245 - startup - [CRITICAL] - Setting up invertor: 1 of 1
GivTCP_1 | 2022-09-27 09:51:13,248 - startup - [CRITICAL] - Recreating settings.py for invertor 1
GivTCP_1 | 2022-09-27 09:51:13,249 - startup - [CRITICAL] - Running RQ worker to queue and process givernergy-modbus calls
GivTCP_1 | 2022-09-27 09:51:13,249 - startup - [CRITICAL] - Running Invertor read loop every 5s
GivTCP_1 | 2022-09-27 09:51:13,249 - startup - [CRITICAL] - Starting Gunicorn on port 6345
GivTCP_1 | [2022-09-27 09:51:13 +0100] [13] [INFO] Starting gunicorn 20.1.0
GivTCP_1 | [2022-09-27 09:51:13 +0100] [13] [INFO] Listening at: http://0.0.0.0:6345 (13)
GivTCP_1 | [2022-09-27 09:51:13 +0100] [13] [INFO] Using worker: sync
GivTCP_1 | [2022-09-27 09:51:13 +0100] [14] [INFO] Booting worker with pid: 14
GivTCP_1 | [2022-09-27 09:51:13 +0100] [15] [INFO] Booting worker with pid: 15
GivTCP_1 | [2022-09-27 09:51:13 +0100] [17] [INFO] Booting worker with pid: 17
GivTCP_1 | 2022-09-27 09:51:18,053 - read - [CRITICAL] - First time running so saving AC Charge status
GivTCP_1 | [2022-09-27 09:52:13 +0100] [13] [CRITICAL] WORKER TIMEOUT (pid:14)
GivTCP_1 | [2022-09-27 09:52:13 +0100] [14] [INFO] Worker exiting (pid: 14)
GivTCP_1 | [2022-09-27 09:52:13 +0100] [22] [INFO] Booting worker with pid: 22
GivTCP_1 | [2022-09-27 09:52:43 +0100] [13] [CRITICAL] WORKER TIMEOUT (pid:15)
GivTCP_1 | [2022-09-27 09:52:43 +0100] [15] [INFO] Worker exiting (pid: 15)
GivTCP_1 | [2022-09-27 09:52:43 +0100] [24] [INFO] Booting worker with pid: 24
GivTCP_1 | [2022-09-27 09:53:11 +0100] [13] [CRITICAL] WORKER TIMEOUT (pid:17)
GivTCP_1 | [2022-09-27 09:53:11 +0100] [17] [INFO] Worker exiting (pid: 17)
GivTCP_1 | [2022-09-27 09:53:11 +0100] [26] [INFO] Booting worker with pid: 26

When I use the RunAll command to host:6345 I get unable to connect so although it’s cycling round (I see connects to the inverter if I run debug level, there doesn’t seem to be any data available.

2022-09-27 09:56:57,452 - startup - [CRITICAL] - No config directory exists, so creating it…
2022-09-27 09:56:57,453 - startup - [CRITICAL] - Running Redis
2022-09-27 09:56:57,453 - startup - [CRITICAL] - Setting up invertor: 1 of 1
2022-09-27 09:56:57,457 - startup - [CRITICAL] - Recreating settings.py for invertor 1
2022-09-27 09:56:57,458 - startup - [CRITICAL] - Running RQ worker to queue and process givernergy-modbus calls
2022-09-27 09:56:57,458 - startup - [CRITICAL] - Running Invertor read loop every 5s
2022-09-27 09:56:57,458 - startup - [CRITICAL] - Starting Gunicorn on port 6345
[2022-09-27 09:56:57 +0100] [13] [INFO] Starting gunicorn 20.1.0
[2022-09-27 09:56:57 +0100] [13] [INFO] Listening at: http://0.0.0.0:6345 (13)
[2022-09-27 09:56:57 +0100] [13] [INFO] Using worker: sync
[2022-09-27 09:56:57 +0100] [16] [INFO] Booting worker with pid: 16
[2022-09-27 09:56:57 +0100] [18] [INFO] Booting worker with pid: 18
2022-09-27 09:56:57,724 - read - [INFO] - ----------------------------Starting----------------------------
2022-09-27 09:56:57,725 - read - [INFO] - Getting All Registers
2022-09-27 09:56:57,725 - read - [INFO] - setting lock file
2022-09-27 09:56:57,725 - read - [INFO] - Connecting to: 192.168.100.159
2022-09-27 09:56:57,749 - sync - [DEBUG] - Connection to Modbus server established. Socket (‘172.19.0.2’, 44747)
2022-09-27 09:56:57,750 - transaction - [DEBUG] - Current transaction state - IDLE
2022-09-27 09:56:57,750 - transaction - [DEBUG] - Running transaction 1
2022-09-27 09:56:57,751 - sync - [DEBUG] - New Transaction state ‘SENDING’
[2022-09-27 09:56:57 +0100] [19] [INFO] Booting worker with pid: 19
2022-09-27 09:56:57,993 - transaction - [DEBUG] - Changing transaction state from ‘WAITING FOR REPLY’ to ‘PROCESSING REPLY’
2022-09-27 09:56:57,993 - payload - [DEBUG] - [b’\x00\x00’, b’\x00\x00’, b’\x00\x00’, b’\x00\x8a’]
2022-09-27 09:56:57,993 - transaction - [DEBUG] - Adding transaction 1
2022-09-27 09:56:57,993 - transaction - [DEBUG] - Changing transaction state from ‘PROCESSING REPLY’ to ‘TRANSACTION_COMPLETE’
2022-09-27 09:56:58,494 - transaction - [DEBUG] - Current transaction state - TRANSACTION_COMPLETE
2022-09-27 09:56:58,494 - transaction - [DEBUG] - Running transaction 2
2022-09-27 09:56:58,494 - sync - [DEBUG] - New Transaction state ‘SENDING’
2022-09-27 09:56:58,723 - transaction - [DEBUG] - Changing transaction state from ‘WAITING FOR REPLY’ to ‘PROCESSING REPLY’
2022-09-27 09:56:58,724 - payload - [DEBUG] - [b’\x00\x00’, b’\x00\x00’, b’\x00\x00’, b’\x00\x8a’]
2022-09-27 09:56:58,724 - transaction - [DEBUG] - Adding transaction 2
2022-09-27 09:56:58,724 - transaction - [DEBUG] - Changing transaction state from ‘PROCESSING REPLY’ to ‘TRANSACTION_COMPLETE’
2022-09-27 09:56:59,225 - transaction - [DEBUG] - Current transaction state - TRANSACTION_COMPLETE
2022-09-27 09:56:59,226 - transaction - [DEBUG] - Running transaction 3
2022-09-27 09:56:59,226 - sync - [DEBUG] - New Transaction state ‘SENDING’
2022-09-27 09:56:59,463 - transaction - [DEBUG] - Changing transaction state from ‘WAITING FOR REPLY’ to ‘PROCESSING REPLY’
2022-09-27 09:56:59,464 - payload - [DEBUG] - [b’\x00\x00’, b’\x00\x00’, b’\x00\x00’, b’\x00\x8a’]
2022-09-27 09:56:59,464 - transaction - [DEBUG] - Adding transaction 3
2022-09-27 09:56:59,464 - transaction - [DEBUG] - Changing transaction state from ‘PROCESSING REPLY’ to ‘TRANSACTION_COMPLETE’
2022-09-27 09:56:59,966 - transaction - [DEBUG] - Current transaction state - TRANSACTION_COMPLETE
2022-09-27 09:56:59,966 - transaction - [DEBUG] - Running transaction 4
2022-09-27 09:56:59,966 - sync - [DEBUG] - New Transaction state ‘SENDING’
2022-09-27 09:57:00,203 - transaction - [DEBUG] - Changing transaction state from ‘WAITING FOR REPLY’ to ‘PROCESSING REPLY’
2022-09-27 09:57:00,203 - payload - [DEBUG] - [b’\x00\x00’, b’\x00\x00’, b’\x00\x00’, b’\x00\x8a’]
2022-09-27 09:57:00,203 - transaction - [DEBUG] - Adding transaction 4
2022-09-27 09:57:00,204 - transaction - [DEBUG] - Changing transaction state from ‘PROCESSING REPLY’ to ‘TRANSACTION_COMPLETE’
2022-09-27 09:57:00,705 - transaction - [DEBUG] - Current transaction state - TRANSACTION_COMPLETE
2022-09-27 09:57:00,705 - transaction - [DEBUG] - Running transaction 5
2022-09-27 09:57:00,705 - sync - [DEBUG] - New Transaction state ‘SENDING’
2022-09-27 09:57:00,933 - transaction - [DEBUG] - Changing transaction state from ‘WAITING FOR REPLY’ to ‘PROCESSING REPLY’
2022-09-27 09:57:00,934 - payload - [DEBUG] - [b’\x00\x00’, b’\x00\x00’, b’\x00\x00’, b’\x00\x8a’]
2022-09-27 09:57:00,934 - transaction - [DEBUG] - Adding transaction 5
2022-09-27 09:57:00,934 - transaction - [DEBUG] - Changing transaction state from ‘PROCESSING REPLY’ to ‘TRANSACTION_COMPLETE’
2022-09-27 09:57:01,436 - transaction - [DEBUG] - Current transaction state - TRANSACTION_COMPLETE
2022-09-27 09:57:01,436 - transaction - [DEBUG] - Running transaction 6
2022-09-27 09:57:01,436 - sync - [DEBUG] - New Transaction state ‘SENDING’
2022-09-27 09:57:01,673 - transaction - [DEBUG] - Changing transaction state from ‘WAITING FOR REPLY’ to ‘PROCESSING REPLY’
2022-09-27 09:57:01,674 - payload - [DEBUG] - [b’\x00\x00’, b’\x00\x00’, b’\x00\x00’, b’\x00\x8a’]
2022-09-27 09:57:01,674 - transaction - [DEBUG] - Adding transaction 6
2022-09-27 09:57:01,674 - transaction - [DEBUG] - Changing transaction state from ‘PROCESSING REPLY’ to ‘TRANSACTION_COMPLETE’
2022-09-27 09:57:02,177 - read - [INFO] - Removing lock file
2022-09-27 09:57:02,178 - read - [INFO] - Invertor connection successful, registers retrieved
2022-09-27 09:57:02,178 - read - [INFO] - Getting Total Energy Data
2022-09-27 09:57:02,178 - read - [INFO] - Getting Today Energy Data
2022-09-27 09:57:02,178 - read - [INFO] - Getting PV Power
2022-09-27 09:57:02,178 - read - [INFO] - Getting Grid Power
2022-09-27 09:57:02,178 - read - [INFO] - Getting EPS Power
2022-09-27 09:57:02,178 - read - [INFO] - Getting PInv Power
2022-09-27 09:57:02,179 - read - [INFO] - Getting Load Power
2022-09-27 09:57:02,179 - read - [INFO] - Getting Self Consumption Power
2022-09-27 09:57:02,179 - read - [INFO] - Getting Solar to H/B/G Power Flows
2022-09-27 09:57:02,179 - read - [INFO] - Getting Grid to Battery/House Power Flow
2022-09-27 09:57:02,179 - read - [INFO] - Getting SOC
2022-09-27 09:57:02,179 - read - [INFO] - Getting Solar to H/B/G Power Flows
2022-09-27 09:57:02,179 - read - [INFO] - Getting Battery to House Power Flow
2022-09-27 09:57:02,180 - read - [INFO] - Getting Grid to Battery/House Power Flow
2022-09-27 09:57:02,180 - read - [INFO] - Getting Battery to Grid Power Flow
2022-09-27 09:57:02,180 - read - [INFO] - Getting mode control figures
2022-09-27 09:57:02,180 - read - [INFO] - Calculating Mode…
2022-09-27 09:57:02,180 - read - [INFO] - Mode is: Eco
2022-09-27 09:57:02,180 - read - [INFO] - Getting TimeSlot data
2022-09-27 09:57:02,180 - read - [INFO] - Getting Invertor Details
2022-09-27 09:57:02,180 - read - [INFO] - Getting Battery Details
2022-09-27 09:57:02,180 - read - [INFO] - Building battery output:
2022-09-27 09:57:02,182 - read - [INFO] - No Night Start Energy so setting it to: 607.8
2022-09-27 09:57:02,182 - read - [INFO] - No Day Start Energy so setting it to: 607.8
2022-09-27 09:57:02,182 - read - [CRITICAL] - First time running so saving AC Charge status
2022-09-27 09:57:02,285 - read - [INFO] - ----------------------------Starting----------------------------
2022-09-27 09:57:02,285 - read - [INFO] - Getting All Registers
2022-09-27 09:57:02,285 - read - [INFO] - setting lock file
2022-09-27 09:57:02,285 - read - [INFO] - Connecting to: 192.168.100.159
2022-09-27 09:57:02,307 - sync - [DEBUG] - Connection to Modbus server established. Socket (‘172.19.0.2’, 34539)
2022-09-27 09:57:02,307 - transaction - [DEBUG] - Current transaction state - IDLE
2022-09-27 09:57:02,307 - transaction - [DEBUG] - Running transaction 1
2022-09-27 09:57:02,307 - sync - [DEBUG] - New Transaction state ‘SENDING’
2022-09-27 09:57:02,543 - transaction - [DEBUG] - Changing transaction state from ‘WAITING FOR REPLY’ to ‘PROCESSING REPLY’
2022-09-27 09:57:02,543 - payload - [DEBUG] - [b’\x00\x00’, b’\x00\x00’, b’\x00\x00’, b’\x00\x8a’]
2022-09-27 09:57:02,544 - transaction - [DEBUG] - Adding transaction 1
2022-09-27 09:57:02,544 - transaction - [DEBUG] - Changing transaction state from ‘PROCESSING REPLY’ to ‘TRANSACTION_COMPLETE’
2022-09-27 09:57:03,045 - transaction - [DEBUG] - Current transaction state - TRANSACTION_COMPLETE
2022-09-27 09:57:03,045 - transaction - [DEBUG] - Running transaction 2
2022-09-27 09:57:03,046 - sync - [DEBUG] - New Transaction state ‘SENDING’
2022-09-27 09:57:03,276 - transaction - [DEBUG] - Changing transaction state from ‘WAITING FOR REPLY’ to ‘PROCESSING REPLY’
2022-09-27 09:57:03,276 - payload - [DEBUG] - [b’\x00\x00’, b’\x00\x00’, b’\x00\x00’, b’\x00\x8a’]
2022-09-27 09:57:03,277 - transaction - [DEBUG] - Adding transaction 2

and so on…

also I now see:
2022-09-27 11:03:51,855 - read - [INFO] - Battery_kWh has gone from: 3.6044799999999997 → 3.85024
GivTCP_1 | 2022-09-27 11:03:51,855 - read - [INFO] - Battery has been charged in the last 30mins so recalculating battery value and ppkwh:
GivTCP_1 | 2022-09-27 11:03:51,855 - GivLUT - [CRITICAL] - Consecutive failure count= 5
GivTCP_1 | 2022-09-27 11:03:51,855 - read - [ERROR] - Error processing registers: (<class ‘KeyError’>, KeyError(‘Current_Rate’), <traceback object at 0x7f98d4e8fa00>)
GivTCP_1 | 2022-09-27 11:03:51,856 - read - [ERROR] - Invertor Update failed so using last known good data from cache (2022-09-27T10:01:47.932169+00:00)

Apologies for the incessant trickle of updates but I now see that the worker timeout happens after that error message and then sits on a “Booting worker with PID…” line for almost 3 minutes OR until I send a RunAll request from the browser. The request hangs but I see an immediate iteration of the cycle in the logs.