well my hub updated today and so far everything is working great,edgebridge/ phone prescence etc
martin
1 Like
Re: the endless stream of “HTTP Send error sending response:”, which seems to eventually take down the edgebridge. Where the only thing hitting the server at the moment is the edgebridge_monitor. Since, I found the Google Sheets stuff much more to my liking (better than doing webhook calls to a server I pay for, to create entries in google sheets.)
Made the error message stop with this little change:
--- edgebridge.orig.py 2023-02-13 15:39:40.785620048 -0600
+++ edgebridge.mine.py 2023-02-13 15:39:01.875590929 -0600
@@ -119,7 +119,8 @@
server.end_headers()
- server.wfile.write(bytes(responsetosend, 'UTF-8'))
+ if len(responsetosend) > 0:
+ server.wfile.write(bytes(responsetosend, 'UTF-8'))
log.debug ('Response sent')
except:
log.error (f"HTTP Send error sending response: {responsetosend}")
1 Like
Hi - Sorry to hear about the problems you were having. Can you give me any more insight as to what could have been causing the endless errors in the first place? It seems that Edgebridge was receiving something and trying to forward it back out. Or maybe some socket error was happening that wasn’t getting caught?
Glad you found a patch and I may need to incorporate it into the code!
New issue cropped up for me…
For some reason my registrations file keeps populating with the wrong address for my hub.
Instead of 192.168.1.59 it keeps changing itself to 169.254.40.143
There is nothing at that address so naturally it fails. I’ve deleted reg file and trying to “resync” by changing a device address back and forth but it keeps setting to this unknown IP.
Tue Mar 14 21:21:23 2023 GET request received from: (‘192.168.1.6’, 64663)
Tue Mar 14 21:21:23 2023 >>>>> Forwarding to SmartThings hub
Tue Mar 14 21:21:23 2023 Sending POST: http://169.254.40.143:36967/192.168.1.6/GET/Garage/motion/active to 169.254.40.143:36967
Tue Mar 14 21:21:23 2023 FAILED sending message to Edge hub [‘169.254.40.143’, 36967]
Here is the log when I’m editing IP address back/forth to resync
Tue Mar 14 21:24:26 2023 DELETE request received from: (‘192.168.1.59’, 55758)
Tue Mar 14 21:24:26 2023 Request to remove registration (‘192.168.1.5’, None)
Tue Mar 14 21:24:26 2023 Registration 1 DELETED
Tue Mar 14 21:24:26 2023 Updated registrations: [{‘devaddr’: [‘192.168.1.6’, None], ‘edgeid’: ‘e8a1a0b7-32e4-4882-8d38-45a96ead543d’, ‘hubaddr’: [‘169.254.40.143’, 36967]}]
Tue Mar 14 21:24:26 2023 **********************************************************************************
Tue Mar 14 21:24:26 2023 POST request received from: (‘192.168.1.59’, 55760)
Tue Mar 14 21:24:26 2023 Request to register device at (‘192.168.1.6’, None)
Tue Mar 14 21:24:26 2023 Registration record ADDED
Tue Mar 14 21:24:26 2023 Updated registrations: [{‘devaddr’: [‘192.168.1.6’, None], ‘edgeid’: ‘e8a1a0b7-32e4-4882-8d38-45a96ead543d’, ‘hubaddr’: [‘169.254.40.143’, 36967]}, {‘devaddr’: (‘192.168.1.6’, None), ‘edgeid’: ‘e8a1a0b7-32e4-4882-8d38-45a96ead543d’, ‘hubaddr’: (‘169.254.40.143’, 36967)}]
** UPDATE NOTICE **
I have updated all three versions of edgebridge (edgebridge.py, edgebridge.exe, edgebridge executable for Pi) in the github repository. This change ensures all headers sent by the originator (Edge driver, for example) are passed through when forwarding requests on to addresses outside the LAN.
For example, if you ever had a problem accessing a RESTful API that required an specific authorization key in the header, this update should correct that.
Unless you specifically need this update, it’s not mandatory to update your systems right away. The former version will continue to run just fine.
2 Likes
FYI for current edgebridge users, I just posted a new driver that uses edgebridge for air quality measurements that you might be interested in.
1 Like
@Gavacac I am having the same problem, how did you solve it?
pi@raspberrypi:~ $ wget edgebridge/edgebridge4pi at main · toddaustin07/edgebridge · GitHub
–2023-04-21 15:57:26-- edgebridge/edgebridge4pi at main · toddaustin07/edgebridge · GitHub
Resolving github.com (github.com)… 20.87.225.212
Connecting to github.com (github.com)|20.87.225.212|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: unspecified [text/html]
Saving to: ‘edgebridge4pi’
edgebridge4pi [ <=> ] 135.70K --.-KB/s in 0.05s
2023-04-21 15:57:26 (2.52 MB/s) - ‘edgebridge4pi’ saved [138960]
pi@raspberrypi:~ $ chmod +x edgebridge4pi
pi@raspberrypi:~ $ ./edgebridge4pi
./edgebridge4pi: line 8: syntax error near unexpected token newline' ./edgebridge4pi: line 8: ’
pi@raspberrypi:~ $
DRIVER NOTICE
To add to my ‘family’ of drivers that use Edgebridge to provide LAN-based trigger, motion, presence, contact device types, I’ve just added a new device type driver for temperature/humidity readings. This will allow a LAN-based app or device that can be configured to send readings via HTTP, to locally update a SmartThings temperature/humidity virtual device.
For more information, please refer to the README file here.
3 Likes
I have tested the new temperature/humidity driver and it works perfectly.
I have to say, the Edgebridge, along with its associated drivers has been invaluable with my ‘making my devices work locally’ quest (amongst other things), and I really appreciate the time and effort people like you put in to assist others. Have some coffee on me…
2 Likes
Thanks so much! I’m glad you are finding these things useful. 
1 Like
Try running the Python file and registering it as a service in systemctl, I had a issue similar to this when setting up the EdgeBridge on mine and SlySi’s network but found the issue went away if I used the Python file instead. Todd documents the entire process for this here: GitHub - toddaustin07/edgebridge: Forwarding Bridge Server for SmartThings Edge drivers
Hi @TAustin, recently I have noticed my Edgebridge has been going offline, when checking on my Raspberrry PI, the service seems to be running but isnt responding. I read a post above about changes in ST sockets, so I updated the EdgeBridge script in case any changes had been made but its still happening. Im unsure how long this has been going on as the monitor has an automation If > 15 minutes then Notify, but when i look at the history its happening every day, usually its a ‘blip’ lasting for minutes before it recovers itself but over the last week its turned to hours, and sometimes it doesnt recover and the service needs restarting which I cant always do straight away. The Edgebridge log shows no errors, it just stops after updating prescence, but this is most likely as its the busiest thing it does, and the CLI shows no activity unless I restart the hub, and then it complains that registrations cannot be performed.
The PI is doing other stuff, and seems more than happy and responsive so im not sure where to go next with this one and wondered if you could advise the best route. Ive got quite a lot running through the Edgebridge now so its a bit of a pain when it doesnt respond.
Any pointers would be greatly appreciated!
I get this occassionally myself, but it is usually associated with a firmware update or anytime the hub is rebooted. When that happens and the hub is starting back up again, ALL hub drivers and devices are trying to initialize at the same time, and this can put a temporarily load spike on your Pi as it tries to handle a rapid influx of transactions. During these peak load times, it can’t answer the ping quick enough, so that the Edgebridge monitor thinks Edgebridge is down. I’ll typically give it a few minutes or so then check the monitor again to make sure that it is showing online again. Then I know it was just a temporary hickup.
So how do we address this? I could add an option in the monitor device to be able to configure the time duration that is used before an offline state is declared. The plus side is that you could cut down on the number of false alarms, but on the negative side, it would take longer to find out if it Edgebridge is really down.
I could also potentially rewrite the Edgebridge app to be multi-threaded, which might help ensure it can always respond to pings in a timely manner.
Thank you and the syncronisation after a reboot is to be expected, but my Edgebridge goes AWOL during the day/night and sometimes doesnt return, yesterday for instance I updated the Edgebridge at 10.36am and then monitored the CLI, and traffic from all devices flowed fine until 2.31pm and then traffic to/from the Edgebridge stopped and it reported offline. All other traffic carried on as it should so hub was up and so was the PI as I could ask it the Edgbridge’s status (which was ‘active’ but logs were outdated).
It didnt recover so I waited until I was home and gave the hub a reboot on the off chance the Edgebridge had stallled waiting for a response from the hub, the CLI then showed registration errors until I stopped and started Edgebridge (understandably). It then went off and on a few times until 6pm and (touch wood) has been fine since.
I have a different mixture of LAN sensors, but not many, 8 prescence, 3 contact, 3 motion, 2 temp/humidity and weather, Im not a developer but have been careful with my programming to ensure my ESP devices only POST when a state change occurs to keep traffic to a minimum, and the only thing out of the box I have is a script on the PI that does bespoke prescence but all this does is send the same POST as your LAN presence.
The only changes I have made in the last couple of weeks (when this started) are adding the HTTP and the Temp/Humidity driver.
I’ve done quite a bit of leg work already and I’m happy to do more if you feel the Edgebridge stops due to an outside influence (are there any debug logs?), I just wasnt sure where to start when everything else seems to be working as it should. Maybe a PI rebuild?
I rebuilt the PI, trimmed the fat from the code on my ESP’s so they are not posting excesivley and added each service back one at a time (contact, motion, presence, temp/humidity) and it was bullet proof until I got to the temp/humidity. The post routine used for temp/humidity uses the same function as the contact sensor so no difference in what im sending except for part of the URL.
As the EdgeBridge appears to be device agnostic, is it possible that the hangup is coming from the ST/driver end?
Hi - sorry for the delay in responding, as I’ve been away on vacation.
I’m sorry you are having problems. We’re going to have to try and do some further debugging to see what may be causing the issues. Do you have the SmartThings CLI? If so, we could start some logging and try to catch the error in case it is something going on with the Edge driver.
The other logs to check are those from Edgebridge, which I assume you’ve been doing. It would help me if you would post the output here so I can see what may be going on. You can start edgebridge with a -d command line parameter which will cause it to display some additional info in the log output - mainly the data that is being received if you are using it to forward requests outside your LAN. But since that’s not what you are doing here, it may not give us to much additional info.
Thank you, its appreciated.
This is the CLI
2023-06-03T10:06:58.080863166+00:00 INFO Edgebridge Monitor V1 Response: 200 number
2023-06-03T10:06:58.082038833+00:00 INFO Edgebridge Monitor V1 <Device: bf938913-1b42-43af-ac38-13648d3530e6 (Edgebridge Monitor)> emitting event: {"attribute_id":"status","capability_id":"partyvoice23922.onlinestatus","component_id":"main","state":{"value":"online"}}
2023-06-03T10:06:58.084879833+00:00 DEBUG Edgebridge Monitor V1 driver device thread event handled
2023-06-03T10:07:02.286398501+00:00 TRACE Zigbee Water Leak Sensor Received event with handler zigbee
2023-06-03T10:07:02.292387168+00:00 INFO Zigbee Water Leak Sensor <ZigbeeDevice: f454da54-513f-4448-890f-16959e9eb705 [0xBEF7] (Utility Water)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0xBEF7, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: TemperatureMeasurement >, lqi: 0xCA, rssi: -68, body_length: 0x0008, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x08, seqno: 0x17, ZCLCommandId: 0x0A >, < ReportAttribute || < AttributeRecord || AttributeId: 0x0000, DataType: Int16, MeasuredValue: 1718 > > > >
2023-06-03T10:07:02.357057835+00:00 TRACE Zigbee Water Leak Sensor Found ZigbeeMessageDispatcher handler in zigbee-water
2023-06-03T10:07:02.357916501+00:00 INFO Zigbee Water Leak Sensor Executing ZclClusterAttributeValueHandler: cluster: TemperatureMeasurement, attribute: MeasuredValue
2023-06-03T10:07:02.360750168+00:00 INFO Zigbee Water Leak Sensor <ZigbeeDevice: f454da54-513f-4448-890f-16959e9eb705 [0xBEF7] (Utility Water)> emitting event: {"attribute_id":"temperature","capability_id":"temperatureMeasurement","component_id":"main","state":{"unit":"C","value":17.18}}
2023-06-03T10:07:02.363395835+00:00 DEBUG Zigbee Water Leak Sensor Utility Water device thread event handled
2023-06-03T10:07:02.616098835+00:00 TRACE Zigbee Water Leak Sensor Received event with handler zigbee
2023-06-03T10:07:02.622043835+00:00 INFO Zigbee Water Leak Sensor <ZigbeeDevice: f454da54-513f-4448-890f-16959e9eb705 [0xBEF7] (Utility Water)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0xBEF7, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: IASZone >, lqi: 0xC4, rssi: -68, body_length: 0x0008, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x08, seqno: 0x18, ZCLCommandId: 0x0A >, < ReportAttribute || < AttributeRecord || AttributeId: 0x0002, DataType: Bitmap16, ZoneStatus: 0x0020 > > > >
2023-06-03T10:07:02.645573501+00:00 TRACE Zigbee Water Leak Sensor Found ZigbeeMessageDispatcher handler in zigbee-water
2023-06-03T10:07:02.646401501+00:00 INFO Zigbee Water Leak Sensor Executing ZclClusterAttributeValueHandler: cluster: IASZone, attribute: ZoneStatus
2023-06-03T10:07:02.652835501+00:00 INFO Zigbee Water Leak Sensor <ZigbeeDevice: f454da54-513f-4448-890f-16959e9eb705 [0xBEF7] (Utility Water)> emitting event: {"attribute_id":"water","capability_id":"waterSensor","component_id":"main","state":{"value":"dry"}}
2023-06-03T10:07:02.660083168+00:00 DEBUG Zigbee Water Leak Sensor Utility Water device thread event handled
2023-06-03T10:07:03.128813835+00:00 DEBUG Zigbee Sensors Edge Driver [YG] 1.8.16 driver device thread event handled
2023-06-03T10:07:06.281731503+00:00 DEBUG Xiaomi/Aqara Switch and Button v1.13 driver device thread event handled
2023-06-03T10:07:15.073022507+00:00 INFO Edgebridge Monitor V1 Response: [string "socket"]:1555: timeout string
2023-06-03T10:07:15.082581841+00:00 DEBUG Edgebridge Monitor V1 Current state: online
2023-06-03T10:07:15.083429507+00:00 DEBUG Edgebridge Monitor V1 Failed 1 times
2023-06-03T10:07:15.084613841+00:00 DEBUG Edgebridge Monitor V1 Retrying in 5 seconds
2023-06-03T10:07:15.085780841+00:00 DEBUG Edgebridge Monitor V1 driver device thread event handled
2023-06-03T10:07:15.092009174+00:00 DEBUG Edgebridge Monitor V1 driver device thread event handled
2023-06-03T10:07:22.141861511+00:00 INFO Edgebridge Monitor V1 Response: [string "socket"]:1555: timeout string
2023-06-03T10:07:22.152558177+00:00 DEBUG Edgebridge Monitor V1 Current state: online
2023-06-03T10:07:22.153419511+00:00 DEBUG Edgebridge Monitor V1 Failed 2 times
2023-06-03T10:07:22.154596511+00:00 DEBUG Edgebridge Monitor V1 Retrying in 5 seconds
2023-06-03T10:07:22.155762844+00:00 DEBUG Edgebridge Monitor V1 driver device thread event handled
2023-06-03T10:07:22.160418177+00:00 DEBUG Edgebridge Monitor V1 driver device thread event handled
2023-06-03T10:07:23.709875845+00:00 DEBUG Aqara/Xiaomi Temperature 1.3 driver device thread event handled
2023-06-03T10:07:23.715207511+00:00 DEBUG Zigbee Water Leak Sensor driver device thread event handled
2023-06-03T10:07:29.912956181+00:00 INFO Edgebridge Monitor V1 Response: [string "socket"]:1555: timeout string
2023-06-03T10:07:29.914594514+00:00 DEBUG Edgebridge Monitor V1 Current state: online
2023-06-03T10:07:29.915843848+00:00 DEBUG Edgebridge Monitor V1 Failed 3 times
2023-06-03T10:07:29.917017848+00:00 INFO Edgebridge Monitor V1 <Device: bf938913-1b42-43af-ac38-13648d3530e6 (Edgebridge Monitor)> emitting event: {"attribute_id":"status","capability_id":"partyvoice23922.onlinestatus","component_id":"main","state":{"value":"offline"}}
2023-06-03T10:07:29.921986181+00:00 DEBUG Edgebridge Monitor V1 driver device thread event handled
2023-06-03T10:07:32.071028182+00:00 INFO Edgebridge Monitor V1 Response: [string "socket"]:1555: timeout string
2023-06-03T10:07:32.076234182+00:00 DEBUG Edgebridge Monitor V1 Current state: offline
2023-06-03T10:07:32.077092849+00:00 DEBUG Edgebridge Monitor V1 driver device thread event handled
2023-06-03T10:07:33.138453516+00:00 DEBUG Zigbee Sensors Edge Driver [YG] 1.8.16 driver device thread event handled
2023-06-03T10:07:36.291727517+00:00 DEBUG Xiaomi/Aqara Switch and Button v1.13 driver device thread event handled
2023-06-03T10:07:37.111953851+00:00 TRACE Zigbee Sensors Edge Driver [YG] 1.8.16 Received event with handler zigbee
2023-06-03T10:07:37.112916518+00:00 INFO Zigbee Sensors Edge Driver [YG] 1.8.16 <ZigbeeDevice: 4efd05c1-16bd-4532-a193-91cef5d2e876 [0xC6DA] (Kitchen Motion Sensor)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0xC6DA, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: IlluminanceMeasurement >, lqi: 0xD4, rssi: -65, body_length: 0x0008, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x2A, ZCLCommandId: 0x0A >, < ReportAttribute || < AttributeRecord || AttributeId: 0x0000, DataType: Uint16, MeasuredValue: 0x01EE > > > >
2023-06-03T10:07:37.132963518+00:00 DEBUG Zigbee Sensors Edge Driver [YG] 1.8.16 tuya.can_handle(): false 'Kitchen Motion Sensor' LUMI/lumi.sensor_motion.aq2
2023-06-03T10:07:37.133813518+00:00 DEBUG Zigbee Sensors Edge Driver [YG] 1.8.16 tuya.can_handle(): false 'Kitchen Motion Sensor' LUMI/lumi.sensor_motion.aq2
2023-06-03T10:07:37.135032185+00:00 TRACE Zigbee Sensors Edge Driver [YG] 1.8.16 Found ZigbeeMessageDispatcher handler in Zigbee sensors driver -> Xiaomi Motion Sensor
2023-06-03T10:07:37.136380518+00:00 INFO Zigbee Sensors Edge Driver [YG] 1.8.16 Executing ZclClusterAttributeValueHandler: cluster: IlluminanceMeasurement, attribute: MeasuredValue
2023-06-03T10:07:37.142018185+00:00 INFO Zigbee Sensors Edge Driver [YG] 1.8.16 <ZigbeeDevice: 4efd05c1-16bd-4532-a193-91cef5d2e876 [0xC6DA] (Kitchen Motion Sensor)> emitting event: {"attribute_id":"illuminance","capability_id":"illuminanceMeasurement","component_id":"main","state":{"value":494}}
2023-06-03T10:07:37.172297851+00:00 DEBUG Zigbee Sensors Edge Driver [YG] 1.8.16 Kitchen Motion Sensor device thread event handled
2023-06-03T10:07:37.173145851+00:00 TRACE Zigbee Sensors Edge Driver [YG] 1.8.16 Received event with handler zigbee
2023-06-03T10:07:37.174718851+00:00 INFO Zigbee Sensors Edge Driver [YG] 1.8.16 <ZigbeeDevice: 4efd05c1-16bd-4532-a193-91cef5d2e876 [0xC6DA] (Kitchen Motion Sensor)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0xC6DA, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: OccupancySensing >, lqi: 0xC8, rssi: -67, body_length: 0x0007, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x2B, ZCLCommandId: 0x0A >, < ReportAttribute || < AttributeRecord || AttributeId: 0x0000, DataType: Bitmap8, Occupancy: Occupancy[0x01] > > > >
2023-06-03T10:07:37.183420851+00:00 DEBUG Zigbee Sensors Edge Driver [YG] 1.8.16 tuya.can_handle(): false 'Kitchen Motion Sensor' LUMI/lumi.sensor_motion.aq2
2023-06-03T10:07:37.189635185+00:00 DEBUG Zigbee Sensors Edge Driver [YG] 1.8.16 tuya.can_handle(): false 'Kitchen Motion Sensor' LUMI/lumi.sensor_motion.aq2
2023-06-03T10:07:37.190563185+00:00 TRACE Zigbee Sensors Edge Driver [YG] 1.8.16 Found ZigbeeMessageDispatcher handler in Zigbee sensors driver -> Xiaomi Motion Sensor
2023-06-03T10:07:37.191801851+00:00 INFO Zigbee Sensors Edge Driver [YG] 1.8.16 Executing ZclClusterAttributeValueHandler: cluster: OccupancySensing, attribute: Occupancy
2023-06-03T10:07:37.215378851+00:00 DEBUG Zigbee Sensors Edge Driver [YG] 1.8.16 handle_motion_detected(): timer scheduled interval=30.0 tid={class="timer{}", inner_sock={timeout=0, timer_uuid="7252a9f6-b2d7-4838-9be1-9edf33c9e519"}} time=Sat Jun 3 10:07:37 2023
2023-06-03T10:07:37.219168518+00:00 INFO Zigbee Sensors Edge Driver [YG] 1.8.16 <ZigbeeDevice: 4efd05c1-16bd-4532-a193-91cef5d2e876 [0xC6DA] (Kitchen Motion Sensor)> emitting event: {"attribute_id":"motion","capability_id":"motionSensor","component_id":"main","state":{"value":"active"}}
2023-06-03T10:07:37.231506185+00:00 DEBUG Zigbee Sensors Edge Driver [YG] 1.8.16 Kitchen Motion Sensor device thread event handled
2023-06-03T10:07:37.237352518+00:00 DEBUG Zigbee Sensors Edge Driver [YG] 1.8.16 Kitchen Motion Sensor device thread event handled
2023-06-03T10:07:45.056012188+00:00 INFO Edgebridge Monitor V1 Response: [string "socket"]:1555: timeout string
2023-06-03T10:07:45.059460188+00:00 DEBUG Edgebridge Monitor V1 Current state: offline
2023-06-03T10:07:45.063627522+00:00 DEBUG Edgebridge Monitor V1 driver device thread event handled
2023-06-03T10:07:46.731522522+00:00 DEBUG LAN Contact Device Driver V1 Accepted connection from 192.168.0.22:58688
2023-06-03T10:07:46.740398856+00:00 DEBUG LAN Contact Device Driver V1 Received: POST /192.168.0.27/POST/greenhouse/temperature/22.80 HTTP/1.1
2023-06-03T10:07:46.754256522+00:00 WARN LAN Contact Device Driver V1 No matching configured name found
2023-06-03T10:07:46.792302856+00:00 DEBUG LAN Temp-Humidity Driver V1 Accepted connection from 192.168.0.22:34700
2023-06-03T10:07:46.796792856+00:00 DEBUG LAN Temp-Humidity Driver V1 Received: POST /192.168.0.27/POST/greenhouse/temperature/22.80 HTTP/1.1
2023-06-03T10:07:46.828315189+00:00 INFO LAN Temp-Humidity Driver V1 Message from greenhouse: command=temperature, state=22.8
2023-06-03T10:07:46.829857189+00:00 INFO LAN Temp-Humidity Driver V1 <Device: 53c0e186-9e4d-4230-80a4-d9e8cad81dd6 (Greenhouse Temperature)> emitting event: {"attribute_id":"temperature","capability_id":"temperatureMeasurement","component_id":"main","state":{"unit":"C","value":22.8}}
2023-06-03T10:07:46.861625189+00:00 DEBUG LAN Contact Device Driver V1 Accepted connection from 192.168.0.22:58702
2023-06-03T10:07:46.870037523+00:00 DEBUG LAN Contact Device Driver V1 Received: POST /192.168.0.27/POST/greenhouse/humidity/79.40 HTTP/1.1
2023-06-03T10:07:46.882062523+00:00 WARN LAN Contact Device Driver V1 No matching configured name found
2023-06-03T10:07:46.913715856+00:00 DEBUG LAN Temp-Humidity Driver V1 Accepted connection from 192.168.0.22:34714
2023-06-03T10:07:46.922011189+00:00 DEBUG LAN Temp-Humidity Driver V1 Received: POST /192.168.0.27/POST/greenhouse/humidity/79.40 HTTP/1.1
2023-06-03T10:07:46.947330189+00:00 INFO LAN Temp-Humidity Driver V1 Message from greenhouse: command=humidity, state=79.4
2023-06-03T10:07:46.948888189+00:00 INFO LAN Temp-Humidity Driver V1 <Device: 53c0e186-9e4d-4230-80a4-d9e8cad81dd6 (Greenhouse Temperature)> emitting event: {"attribute_id":"humidity","capability_id":"relativeHumidityMeasurement","component_id":"main","state":{"value":79.4}}
2023-06-03T10:07:46.983103856+00:00 DEBUG LAN Contact Device Driver V1 Accepted connection from 192.168.0.22:58708
2023-06-03T10:07:46.991717189+00:00 DEBUG LAN Contact Device Driver V1 Received: POST /192.168.0.27/POST/greenhouse/temperature/22.90 HTTP/1.1
2023-06-03T10:07:47.004022189+00:00 WARN LAN Contact Device Driver V1 No matching configured name found
2023-06-03T10:07:47.035529856+00:00 DEBUG LAN Temp-Humidity Driver V1 Accepted connection from 192.168.0.22:34730
2023-06-03T10:07:47.046399189+00:00 DEBUG LAN Temp-Humidity Driver V1 Received: POST /192.168.0.27/POST/greenhouse/temperature/22.90 HTTP/1.1
2023-06-03T10:07:47.062301856+00:00 INFO LAN Temp-Humidity Driver V1 Message from greenhouse: command=temperature, state=22.9
2023-06-03T10:07:47.069655523+00:00 INFO LAN Temp-Humidity Driver V1 <Device: 53c0e186-9e4d-4230-80a4-d9e8cad81dd6 (Greenhouse Temperature)> emitting event: {"attribute_id":"temperature","capability_id":"temperatureMeasurement","component_id":"main","state":{"unit":"C","value":22.9}}
2023-06-03T10:07:47.389815523+00:00 DEBUG LAN Motion Device Driver 1.5 Accepted connection from 192.168.0.22:56266
2023-06-03T10:07:47.445108523+00:00 DEBUG LAN Motion Device Driver 1.5 Received: POST /192.168.0.25/GET/motionlounge/motion/inactive HTTP/1.1
2023-06-03T10:07:47.461242523+00:00 INFO LAN Motion Device Driver 1.5 Message from motionlounge: command=motion, state=inactive
2023-06-03T10:07:47.468141523+00:00 INFO LAN Motion Device Driver 1.5 <Device: ec741da2-0405-4630-ac84-08656b5a85fc (Lounge Motion)> emitting event: {"attribute_id":"motion","capability_id":"motionSensor","component_id":"main","state":{"value":"inactive"}}
2023-06-03T10:07:47.502646856+00:00 DEBUG LAN Contact Device Driver V1 Accepted connection from 192.168.0.22:58720
2023-06-03T10:07:47.510980189+00:00 DEBUG LAN Contact Device Driver V1 Received: POST /192.168.0.25/GET/motionlounge/motion/inactive HTTP/1.1
2023-06-03T10:07:47.518901189+00:00 ERROR LAN Contact Device Driver V1 Unexpected HTTP method received: GET
2023-06-03T10:07:48.255344523+00:00 DEBUG LAN Motion Device Driver 1.5 Accepted connection from 192.168.0.22:56268
2023-06-03T10:07:48.269140190+00:00 DEBUG LAN Motion Device Driver 1.5 Received: POST /192.168.0.25/GET/motionlounge/motion/active HTTP/1.1
2023-06-03T10:07:48.281242523+00:00 INFO LAN Motion Device Driver 1.5 Message from motionlounge: command=motion, state=active
2023-06-03T10:07:48.288270857+00:00 INFO LAN Motion Device Driver 1.5 <Device: ec741da2-0405-4630-ac84-08656b5a85fc (Lounge Motion)> emitting event: {"attribute_id":"motion","capability_id":"motionSensor","component_id":"main","state":{"value":"active"}}
2023-06-03T10:07:48.322725523+00:00 DEBUG LAN Contact Device Driver V1 Accepted connection from 192.168.0.22:58736
2023-06-03T10:07:48.330962190+00:00 DEBUG LAN Contact Device Driver V1 Received: POST /192.168.0.25/GET/motionlounge/motion/active HTTP/1.1
2023-06-03T10:07:48.338916523+00:00 ERROR LAN Contact Device Driver V1 Unexpected HTTP method received: GET
2023-06-03T10:07:48.369072190+00:00 DEBUG LAN Contact Device Driver V1 Accepted connection from 192.168.0.22:58752
2023-06-03T10:07:48.377370857+00:00 DEBUG LAN Contact Device Driver V1 Received: POST /192.168.0.27/POST/greenhousewater/temperature/19.25 HTTP/1.1
2023-06-03T10:07:48.391434857+00:00 WARN LAN Contact Device Driver V1 No matching configured name found
2023-06-03T10:07:48.421256523+00:00 DEBUG LAN Temp-Humidity Driver V1 Accepted connection from 192.168.0.22:34740
2023-06-03T10:07:48.429467857+00:00 DEBUG LAN Temp-Humidity Driver V1 Received: POST /192.168.0.27/POST/greenhousewater/temperature/19.25 HTTP/1.1
2023-06-03T10:07:48.455027190+00:00 INFO LAN Temp-Humidity Driver V1 Message from greenhousewater: command=temperature, state=19.25
2023-06-03T10:07:48.459994190+00:00 INFO LAN Temp-Humidity Driver V1 <Device: 267bc40c-a71d-4644-849b-d99087be14bb (Hydroponics Water Temperature)> emitting event: {"attribute_id":"temperature","capability_id":"temperatureMeasurement","component_id":"main","state":{"unit":"C","value":19.25}}
2023-06-03T10:07:49.815934191+00:00 DEBUG LAN Motion Device Driver 1.5 Accepted connection from 192.168.0.22:56276
2023-06-03T10:07:49.824859191+00:00 DEBUG LAN Motion Device Driver 1.5 Received: POST /192.168.0.25/GET/motionlounge/motion/inactive HTTP/1.1
2023-06-03T10:07:49.856957524+00:00 INFO LAN Motion Device Driver 1.5 Message from motionlounge: command=motion, state=inactive
2023-06-03T10:07:49.858594191+00:00 INFO LAN Motion Device Driver 1.5 <Device: ec741da2-0405-4630-ac84-08656b5a85fc (Lounge Motion)> emitting event: {"attribute_id":"motion","capability_id":"motionSensor","component_id":"main","state":{"value":"inactive"}}
2023-06-03T10:07:49.891214524+00:00 DEBUG LAN Contact Device Driver V1 Accepted connection from 192.168.0.22:58760
2023-06-03T10:07:49.902675857+00:00 DEBUG LAN Contact Device Driver V1 Received: POST /192.168.0.25/GET/motionlounge/motion/inactive HTTP/1.1
2023-06-03T10:07:49.909502191+00:00 ERROR LAN Contact Device Driver V1 Unexpected HTTP method received: GET
2023-06-03T10:07:50.586537524+00:00 PRINT Tasmota Edge [cmd:refresh] For "Nathan's Light", IP: "192.168.0.28", type: "PHYSICAL"
2023-06-03T10:07:50.893676858+00:00 DEBUG LAN Motion Device Driver 1.5 Accepted connection from 192.168.0.22:56290
2023-06-03T10:07:50.952300524+00:00 DEBUG LAN Motion Device Driver 1.5 Received: POST /192.168.0.25/GET/motionlounge/motion/active HTTP/1.1
2023-06-03T10:07:50.982705191+00:00 INFO LAN Motion Device Driver 1.5 Message from motionlounge: command=motion, state=active
2023-06-03T10:07:50.984263191+00:00 INFO LAN Motion Device Driver 1.5 <Device: ec741da2-0405-4630-ac84-08656b5a85fc (Lounge Motion)> emitting event: {"attribute_id":"motion","capability_id":"motionSensor","component_id":"main","state":{"value":"active"}}
2023-06-03T10:07:51.019517191+00:00 DEBUG LAN Contact Device Driver V1 Accepted connection from 192.168.0.22:58772
2023-06-03T10:07:51.027520858+00:00 DEBUG LAN Contact Device Driver V1 Received: POST /192.168.0.25/GET/motionlounge/motion/active HTTP/1.1
2023-06-03T10:07:51.039121191+00:00 ERROR LAN Contact Device Driver V1 Unexpected HTTP method received: GET
2023-06-03T10:07:51.160532191+00:00 INFO Tasmota Edge <Device: 24316c81-17f1-4a01-aadb-271f49422a1a (Tasmota Device Creator)> emitting event: {"attribute_id":"supportedDevices","capability_id":"voicehouse43588.tasmotaDevice","component_id":"main","state":{"value":["tasmota-fan","tasmota-generic-switch","tasmota-metering-switch","tasmota-dimmer-switch","tasmota-contact-sensor","tasmota-light-cct","tasmota-light-rgbw","tasmota-light-rgb","tasmota-ir-bridge","tasmota-rf-bridge","http-button","http-switch","http-shade","wled"]},"visibility":{"displayed":false}}
2023-06-03T10:07:51.167007858+00:00 INFO Tasmota Edge <Device: 24316c81-17f1-4a01-aadb-271f49422a1a (Tasmota Device Creator)> emitting event: {"attribute_id":"edition","capability_id":"voicehouse43588.tasmotaEdge","component_id":"main","state":{"value":"<table style=\"width:100%;padding:0;margin:0\"><tr><td>2023.5.1 (Free Edition)</td></tr><tr><td style=\"font-size:70%;\">1 device(s)</td></tr></table>"},"visibility":{"displayed":false}}
2023-06-03T10:07:51.192975525+00:00 PRINT Tasmota Edge [cmd:event] For: "Nathan's Light", DNI: "AS:PHY:766ab4f8-945e-414f-27cf-be2e03d4b736", IP: "192.168.0.28", Parsed: "{ip="192.168.0.28", lqi=90, mac="C82B96E60507", power="off", rssi=-55, switch1="on", version="12.4.0(tasmota)"}"
2023-06-03T10:07:51.201173858+00:00 INFO Tasmota Edge <Device: 46389e5e-1871-49f2-b000-8ce294d11aa9 (Nathan's Light)> emitting event: {"attribute_id":"switch","capability_id":"switch","component_id":"main","state":{"value":"off"}}
2023-06-03T10:07:51.212020191+00:00 INFO Tasmota Edge <Device: 46389e5e-1871-49f2-b000-8ce294d11aa9 (Nathan's Light)> emitting event: {"attribute_id":"lqi","capability_id":"signalStrength","component_id":"main","state":{"value":90},"visibility":{"displayed":true}}
2023-06-03T10:07:51.230391191+00:00 INFO Tasmota Edge <Device: 46389e5e-1871-49f2-b000-8ce294d11aa9 (Nathan's Light)> emitting event: {"attribute_id":"rssi","capability_id":"signalStrength","component_id":"main","state":{"value":-55},"visibility":{"displayed":true}}
2023-06-03T10:07:51.241305191+00:00 DEBUG Tasmota Edge Nathan's Light device thread event handled
2023-06-03T10:07:52.551220859+00:00 DEBUG LAN Motion Device Driver 1.5 Accepted connection from 192.168.0.22:56302
2023-06-03T10:07:52.560055525+00:00 DEBUG LAN Motion Device Driver 1.5 Received: POST /192.168.0.25/GET/motionlounge/motion/inactive HTTP/1.1
2023-06-03T10:07:52.594790525+00:00 INFO LAN Motion Device Driver 1.5 Message from motionlounge: command=motion, state=inactive
2023-06-03T10:07:52.601563859+00:00 INFO LAN Motion Device Driver 1.5 <Device: ec741da2-0405-4630-ac84-08656b5a85fc (Lounge Motion)> emitting event: {"attribute_id":"motion","capability_id":"motionSensor","component_id":"main","state":{"value":"inactive"}}
2023-06-03T10:07:52.662667192+00:00 DEBUG LAN Contact Device Driver V1 Accepted connection from 192.168.0.22:58782
2023-06-03T10:07:52.673697859+00:00 DEBUG LAN Contact Device Driver V1 Received: POST /192.168.0.25/GET/motionlounge/motion/inactive HTTP/1.1
2023-06-03T10:07:52.682750192+00:00 ERROR LAN Contact Device Driver V1 Unexpected HTTP method received: GET
2023-06-03T10:07:53.717178192+00:00 DEBUG Aqara/Xiaomi Temperature 1.3 driver device thread event handled
2023-06-03T10:07:53.726750859+00:00 DEBUG Zigbee Water Leak Sensor driver device thread event handled
2023-06-03T10:07:56.600149527+00:00 DEBUG LAN Motion Device Driver 1.5 Accepted connection from 192.168.0.22:35120
2023-06-03T10:07:56.647677861+00:00 DEBUG LAN Motion Device Driver 1.5 Received: POST /192.168.0.25/GET/motionlounge/motion/active HTTP/1.1
2023-06-03T10:07:56.664268194+00:00 INFO LAN Motion Device Driver 1.5 Message from motionlounge: command=motion, state=active
2023-06-03T10:07:56.671482194+00:00 INFO LAN Motion Device Driver 1.5 <Device: ec741da2-0405-4630-ac84-08656b5a85fc (Lounge Motion)> emitting event: {"attribute_id":"motion","capability_id":"motionSensor","component_id":"main","state":{"value":"active"}}
2023-06-03T10:07:56.711015194+00:00 DEBUG LAN Contact Device Driver V1 Accepted connection from 192.168.0.22:34372
2023-06-03T10:07:56.719332194+00:00 DEBUG LAN Contact Device Driver V1 Received: POST /192.168.0.25/GET/motionlounge/motion/active HTTP/1.1
2023-06-03T10:07:56.728271194+00:00 ERROR LAN Contact Device Driver V1 Unexpected HTTP method received: GET
2023-06-03T10:07:58.067070861+00:00 INFO Edgebridge Monitor V1 Response: 200 number
With the EdgeBridge, I couldnt post here as its too many characters, but I can, however there is nothing in the log, it just stops, then starts again once its recovered.
Interestingly, the CLI is reporting it is receiving a POST for a device that isnt configured:
WARN LAN Contact Device Driver V1 No matching configured name found
And also that it is getting an unexpected HTTP method:
ERROR LAN Contact Device Driver V1 Unexpected HTTP method received: GET
No idea if this is related as this hanging/stalling only occurs when the Temp/Humidity devices are on and reporting to the EdgeBridge.
Hopefully this is what you are after but if it isnt let me know and I will gather more information, although I might need some guidance 
Since running the CLI and it reporting there were one or more devices clocking in with the wrong name, or sending the wrong type of message I have gone back through my ‘generic’ code for my ESP devices, and removed each device on each ESP that wasnt being used and this along with only reporting temperature after a .5 change, humidity after a 10% change and only every 30 minutes the EdgeBridge seems to be a lot happier. I am going to leave this now as these temp/humidity devices are not critical and what I am getting is good enough for my needs. Thanks for taking the time to assist with suggestions anyway, its appreciated.
Glad things are working better for you. I wish I could have reproduced the issues you were seeing to figure out where things were getting hung up, but too many variables. It’s possible that you were simply hitting the edgebridge app so often with invalid transactions that it was bogging it down.
Regarding the frequency of temp/humidity updates, keep in mind also that there is a rate limit in the SmartThings platform that throttles the number of state updates to 12 per minute.