Closed Masterz69 closed 1 year ago
Same here with Sonoff Plugs S31. If the app is open energy data is available and changes as expected with usage. Once you close the app you no longer get any data updated. But the switch still operates. Only happens on 2022.8. Rolling back fixes the issue.
HA Core upgraded to 2022.8.1.
After OS upgrade to 8.4 (from 7.6), on same Core 2022.8.1 & Sonoff 3.1.0:
Reconnected TH16R2 to network - it still working as before (previous time in March). Thermostat also fine - show actual data from eWelink settings.
Ignore previous comment, it was mistake.
I'm having the same problems - also unable to get humidity to report to HA at all. I tried disconnecting and repairing but it made no change sonoff-629b6a5cf0ae45ee6eba841bdae44ab0-Filament Drying Box-061e7fc765d57a4da01bb0c18ec387ca.json.txt .
I have the same problem with humidity sensor with none informations:
sensor.sonoff_100172016d_humidity : unknown state_class: measurement unit_of_measurement: % device_class: humidity friendly_name: ELITE EXT
Other sensors are ok: switch, temp, led, RSSI
Do You receive temperature readings when eWelink App is not opened ?
Humidity You can fix as described here: https://github.com/AlexxIT/SonoffLAN/issues/876#issuecomment-1184172702 It works for me, f.e.
This topic is for another issue: data from device (temperature, humidity, rssi, ...) arrives ONLY while eWelink App is opened on mobile !!!
readings not updating with the app closed, no
@Masterz69 the fix for humidity it's ok for me too.
The app closed... i don't have sensors updating...
As well just noticed in logs regarding same device:
This error originated from a custom integration.
Logger: custom_components.sonoff.core.ewelink.local
Source: custom_components/sonoff/core/ewelink/local.py:255
Integration: Sonoff (documentation, issues)
First occurred: 14 August 2022, 15:03:00 (5363 occurrences)
Last logged: 13:10:00
100171fd9d => Local4 | {'sledOnline': 'on'} <= {'sequence': '1660817160000', 'seq': 138960, 'error': 400, 'encrypt': True}
100171fd9d => Local4 | {'sledOnline': 'on'} <= {'sequence': '1660817220000', 'seq': 138972, 'error': 400, 'encrypt': True}
100171fd9d => Local4 | {'sledOnline': 'on'} <= {'sequence': '1660817280000', 'seq': 138984, 'error': 400, 'encrypt': True}
100171fd9d => Local4 | {'sledOnline': 'on'} <= {'sequence': '1660817340000', 'seq': 138996, 'error': 400, 'encrypt': True}
100171fd9d => Local4 | {'sledOnline': 'on'} <= {'sequence': '1660817400000', 'seq': 139008, 'error': 400, 'encrypt': True}
As far as I know - nothing not updated etc, on 14 August 2022, 15:03:00
.
HA Core was restarted last time at 2022-08-14T08:30:58+00:00
.
Data from the THR316D sensor is not transmitted to the HA if the eWeLink application is closed, but you can control the relay from the HA. What kind of bug?
Someone needs to share this device with my account sonofflan@gmail.com
Here is debug LAN reg. THR316D for today. It looks not visible/discoverable on LAN. eWeLink app show it as locally managed, but see lot of zeroconf messages.
At the end can see when eWelink app started. sonoff_debug_20220903_01.txt
Installed some zeroconf browser. THR3 appears in scan as well as other sonoff devices. See some data from it.
At same time, around 13:57 in debug log:
2022-09-03 13:55:51 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:55:56 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:56:00 [D] 100171fd9d => Cloud4 | 1662202560000
2022-09-03 13:56:00 [D] 100171fd9d <= Cloud3 | {'version': 8, 'fwVersion': '1.0.2', 'switch': 'off', 'startup': 'off', 'pulseConfig': {'pulse': 'off', 'switch': 'off', 'pulseWidth': 500}, 'sledOnline': 'on', 'tempUnit': 0, 'sensorType': 'AM2301', 'currentTemperature': '14.7', 'currentHumidity': '73.0', 'rssi': -62, 'autoControl': [], 'autoControlEnabled': 0, 'uiActive': 60, 'timeZone': 3, 'only_device': {'ota': 'success', 'ota_fail_reason': 0}, 'mainSwitch': 'off', 'deviceType': 'normal'} | 1662202560000
2022-09-03 13:56:01 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:56:06 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:56:11 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:56:16 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:56:21 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:56:26 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:56:31 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:56:36 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:56:41 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:56:46 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:56:51 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:56:56 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:57:00 [D] 100171fd9d => Cloud4 | 1662202620000
2022-09-03 13:57:00 [D] 100171fd9d <= Cloud3 | {'version': 8, 'fwVersion': '1.0.2', 'switch': 'off', 'startup': 'off', 'pulseConfig': {'pulse': 'off', 'switch': 'off', 'pulseWidth': 500}, 'sledOnline': 'on', 'tempUnit': 0, 'sensorType': 'AM2301', 'currentTemperature': '14.7', 'currentHumidity': '73.0', 'rssi': -62, 'autoControl': [], 'autoControlEnabled': 0, 'uiActive': 60, 'timeZone': 3, 'only_device': {'ota': 'success', 'ota_fail_reason': 0}, 'mainSwitch': 'off', 'deviceType': 'normal'} | 1662202620000
2022-09-03 13:57:01 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:57:06 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:57:11 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:57:16 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:57:21 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:57:29 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:57:35 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:57:37 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:57:42 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:57:47 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:57:51 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:57:56 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:58:00 [D] 100171fd9d => Cloud4 | 1662202680000
2022-09-03 13:58:00 [D] 100171fd9d <= Cloud3 | {'version': 8, 'fwVersion': '1.0.2', 'switch': 'off', 'startup': 'off', 'pulseConfig': {'pulse': 'off', 'switch': 'off', 'pulseWidth': 500}, 'sledOnline': 'on', 'tempUnit': 0, 'sensorType': 'AM2301', 'currentTemperature': '14.7', 'currentHumidity': '73.0', 'rssi': -62, 'autoControl': [], 'autoControlEnabled': 0, 'uiActive': 60, 'timeZone': 3, 'only_device': {'ota': 'success', 'ota_fail_reason': 0}, 'mainSwitch': 'off', 'deviceType': 'normal'} | 1662202680000
2022-09-03 13:58:01 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:58:06 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:58:11 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:58:16 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:58:21 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:58:26 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:58:31 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:58:36 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:58:41 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:58:46 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:58:51 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:58:56 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:59:00 [D] 100171fd9d => Cloud4 | 1662202740000
2022-09-03 13:59:00 [D] 100171fd9d <= Cloud3 | {'version': 8, 'fwVersion': '1.0.2', 'switch': 'off', 'startup': 'off', 'pulseConfig': {'pulse': 'off', 'switch': 'off', 'pulseWidth': 500}, 'sledOnline': 'on', 'tempUnit': 0, 'sensorType': 'AM2301', 'currentTemperature': '14.7', 'currentHumidity': '73.0', 'rssi': -62, 'autoControl': [], 'autoControlEnabled': 0, 'uiActive': 60, 'timeZone': 3, 'only_device': {'ota': 'success', 'ota_fail_reason': 0}, 'mainSwitch': 'off', 'deviceType': 'normal'} | 1662202740000
2022-09-03 13:59:01 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:59:06 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:59:12 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:59:17 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:59:22 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
2022-09-03 13:59:27 [D] Can't find address for eWeLink_100171fd9d._ewelink._tcp.local.
Looks like cloud returns same data again and again.
Well. You need to wait zeroconf fix for Sonoff Micro. Maybe that helps and for your model too.
Maybe that helps and for your model too.
If device is not reachable locally, is integration must receive readings from Cloud ? But it not happens too. See same data every time, but Cloud definitely receives them, as eWeLink app show temperature graphs for past periods, not only current data.
Some pow models has cloud command to force device updates. So you can see them when open mobile app. So I have asked to share this model with me. To check if this model has some similar command.
Some pow models has cloud command to force device updates. So you can see them when open mobile app. So I have asked to share this model with me. To check if this model has some similar command.
Shared device in App (by eWelink user name), pls check.
@AlexxIT I am having very similar issues with a THR320, that Masterz69 is having with his THR316:
Do you need my THR320 to be shared also? Or do you think you can resolve the cloud issue with the THR316 example device?
For local, you commented:
Well. You need to wait zeroconf fix for Sonoff Micro. Maybe that helps and for your model too.
Is that something you work on and have a time line for? Or is that work done elsewhere?
Apologies for asking potentially silly questions.
Thanks
I have the same problem as Masterz69, but with a POW320D
{
"home_assistant": {
"installation_type": "Home Assistant OS",
"version": "2022.9.2",
"dev": false,
"hassio": true,
"virtualenv": false,
"python_version": "3.10.5",
"docker": true,
"arch": "x86_64",
"timezone": "Europe/Madrid",
"os_name": "Linux",
"os_version": "5.15.60",
"supervisor": "2022.08.6",
"host_os": "Home Assistant OS 8.5",
"docker_version": "20.10.14",
"chassis": "embedded",
"run_as_root": true
},
"custom_components": {
"climate_ip": {
"version": "3.5.2",
"requirements": [
"requests>=2.21.0",
"xmljson>=0.2.0"
]
},
"hacs": {
"version": "1.27.2",
"requirements": [
"aiogithubapi>=22.2.4"
]
},
"formulaone_api": {
"version": "0.1.5",
"requirements": [
"requests >=2.20"
]
},
"edge_tts": {
"version": "0.0.1",
"requirements": [
"edge-tts==5.0.1"
]
},
"sonoff": {
"version": "3.2.0",
"requirements": [
"pycryptodome>=3.6.6"
]
},
"alexa_media": {
"version": "4.1.2",
"requirements": [
"alexapy==1.26.3",
"packaging>=20.3",
"wrapt>=1.12.1"
]
},
"alarmo": {
"version": "v1.9.5",
"requirements": []
}
},
"integration_manifest": {
"domain": "sonoff",
"name": "Sonoff",
"config_flow": true,
"documentation": "https://github.com/AlexxIT/SonoffLAN",
"issue_tracker": "https://github.com/AlexxIT/SonoffLAN/issues",
"codeowners": [
"@AlexxIT"
],
"dependencies": [
"http",
"zeroconf"
],
"requirements": [
"pycryptodome>=3.6.6"
],
"version": "3.2.0",
"iot_class": "local_push",
"is_built_in": false
},
"data": {
"version": "1b3db6f",
"cloud_auth": true,
"config": null,
"options": {
"mode": "auto",
"debug": false,
"homes": 1
},
"errors": [
{
"name": "custom_components.sonoff.core.ewelink.local",
"message": [
"100173850d => Local4 | {'switches': [{'outlet': 0, 'switch': 'off'}]} <= {'sequence': '1663090065000', 'seq': 57, 'error': 400, 'encrypt': True}",
"100173850d => Local4 | {'switches': [{'outlet': 0, 'switch': 'on'}]} <= {'sequence': '1663090075000', 'seq': 61, 'error': 400, 'encrypt': True}",
"100173850d => Local4 | {'switches': [{'outlet': 0, 'switch': 'off'}]} <= {'sequence': '1663090108000', 'seq': 64, 'error': 400, 'encrypt': True}",
"100173850d => Local4 | {'switches': [{'outlet': 0, 'switch': 'on'}]} <= {'sequence': '1663090114000', 'seq': 68, 'error': 400, 'encrypt': True}",
"100173850d => Local4 | {'switches': [{'outlet': 0, 'switch': 'off'}]} <= {'sequence': '1663090124000', 'seq': 71, 'error': 400, 'encrypt': True}"
],
"level": "WARNING",
"source": [
"custom_components/sonoff/core/ewelink/local.py",
255
],
"timestamp": 1663090125.0121412,
"exception": "",
"count": 15,
"first_occurred": 1663015031.2881017
},
{
"name": "custom_components.sonoff.core.ewelink.cloud",
"message": [
"Cloud ERROR: {'error': 400, 'deviceid': 'ab300001fe', 'apikey': 'acb441d7-1b57-48d8-8fd5-XXXXXXXXXXX', 'sequence': '1663083519000'}",
"Cloud ERROR: {'error': 504, 'reason': 'Request Timeout', 'deviceid': '100173850d', 'apikey': 'acb441d7-1b57-48d8-8fd5-XXXXXXXXXXX', 'sequence': '1663086962000'}",
"Cloud ERROR: {'error': 400, 'deviceid': 'ab300001fe', 'apikey': 'acb441d7-1b57-48d8-8fd5-XXXXXXXXXXX', 'sequence': '1663087119000'}",
"Cloud ERROR: {'error': 504, 'reason': 'Request Timeout', 'deviceid': '100173850d', 'apikey': 'acb441d7-1b57-48d8-8fd5-XXXXXXXXXXX', 'sequence': '1663090562000'}",
"Cloud ERROR: {'error': 400, 'deviceid': 'ab300001fe', 'apikey': 'acb441d7-1b57-48d8-8fd5-XXXXXXXXXXX', 'sequence': '1663090720000'}"
],
"level": "WARNING",
"source": [
"custom_components/sonoff/core/ewelink/cloud.py",
286
],
"timestamp": 1663090720.3333123,
"exception": "",
"count": 46,
"first_occurred": 1663014965.9067159
}
],
"device": {
"uiid": 190,
"params": {
"bindInfos": "***",
"version": 8,
"ssid": "***",
"bssid": "***",
"fwVersion": "1.0.6",
"switches": [
{
"outlet": 0,
"switch": "off"
}
],
"configure": [
{
"startup": "stay",
"outlet": 0
}
],
"pulses": [
{
"pulse": "off",
"switch": "off",
"outlet": 0,
"width": 500
}
],
"rssi": -55,
"threshold": {
"actPow": {
"min": 10,
"max": 500000
},
"voltage": {
"min": 18500,
"max": 26400
},
"current": {
"min": 10,
"max": 2000
}
},
"current": 4,
"voltage": 23341,
"power": 492,
"dayKwh": 0,
"monthKwh": 0,
"uiActive": 60,
"timeZone": 2,
"getHoursKwh": {
"start": 0,
"end": 743
},
"sledOnline": "on",
"only_device": {
"ota": "success",
"ota_fail_reason": 0
}
},
"model": "POWR320D",
"online": true,
"localtype": "plug",
"deviceid": "100173850d"
}
}
}
@Masterz69 @ocigam69 OK, I have found a work around for this issue. Its a bit hacky but it seems to be working. There are 2 key elements to it:
The Smart Home version of eWeLink functions the same way as the mobile app, so you need to be actively using it in order for updates to be pulled from the cloud through SonoffLAN integration. This is done through a cURL command, which you can find from your browser.
All the instructions to get eWeLink Smart Home working are in https://sonoff.tech/product-review/how-sonoff-works-with-home-assistant/ or https://appcms-src.coolkit.cn/uncategorized/9213.html. These instructions are for the version of HA that includes the Supervisor tab. I run docker, so have to also run eWeLink as a docker instance - the docker reference commands are in https://github.com/CoolKit-Technologies/ha-addon. I reference my HA_URL as an IP address, to ensure no DNS issues. The steps don't explicitly state it, but you need to create a Long Lived Token in HA to be input into the docker run command.
Once you have eWeLink running and you have logged in, you should see your devices in your browser session. If you open the network inspection tools (F12 in Chrome), then click the refresh button for the device you are interested in and a line item will show for "proxy2wxs". Right click that entry, select Copy, then your required "Copy as ...." command. I used "Copy as cURL (bash)". It will look something like this:
You can create a scheduled task using your preferred method (cron, HA automation or something else), and get it to issue the cURL command you just copied. My cURL command issues a refresh command that is then active for 2 minutes, so you get updates that duration. You can then re-issue your scheduled task as often as you need. I have set a 10 mins gap at the moment. I only have 1 device at this point, but I believe you will need to have a scheduled task for each device you want to collect cloud data from.
@AlexxIT if you could still look at a way to resolve the local access that would be much appreciated. I did find an HA document that said it was something that needed to be covered in integrations, instead of by HA as a whole. I don't believe it to be a general mDNS or zeroconf issue on my network, because if I ping the mDNS name from putty on the NAS I am running docker (with host network settings) the name resolves correctly.
@Masterz69 looks like problem same as #839 Fix already in master version. Will be in next release
Fix already in master version. Will be in next release
Just installed master
version - see data from THR316D.
Now receiving reading every ~5 seconds. Amazing.
Attaching diagnostics & integration log FYI: sonoff-a0656de0df0bb579aa4ece0459ab70e2-sTH Test-a9d3a7d4bf9eb492b9dbe427bfb4f40c.json.txt sonoff-log_20220925.txt
Btw. integration looks receiving data locally
2022-09-25 01:37:47 [D] 100171fd9d <= Local0 | {'switch': 'off', 'startup': 'off', 'pulseConfig': {'pulse': 'off', 'switch': 'off', 'pulseWidth': 500}, 'sledOnline': 'on', 'tempUnit': 0, 'timeZone': 3, 'sensorType': 'AM2301', 'currentTemperature': '5.7', 'currentHumidity': '84.6', 'autoControlEnabled': 0, 'fwVersion': '1.0.2', 'rssi': -57} | 604209
but device diagnostics contains "localtype": null,
. Is it Ok ?
Unfortunately, this is "normal" situation for Local0
, device sends only data, without IP-address. New version support processing incoming data without IP. But you can not control device locally. Because didn't know it's IP-address.
You can try to ping ewelink_100171fd9d.local
from Hass server. To check if OS know device IP-address.
But how the eWeLink Mobile App control device locally ? At least it show LAN icon for that device. Is it mean application no need to know device IP, but still can control it locally ?
Maybe ewelink app works better with zeroconf (mDNS) than python library.
Just performed a test. W/out home network being connected to Internet:
Bonjour browser f.e. can detect/show IP address of that device - see previously attached screenshot:
So, device send data w/out IP, but "discovery" can obtain device IP. Is it possible to formulate/describe this issue for HA to fix/enhance library.
You can try to
ping ewelink_100171fd9d.local
from Hass server. To check if OS know device IP-address.
Just checked from HA OS:
➜ ~ ping ewelink_100171fd9d.local
PING ewelink_100171fd9d.local (192.168.1.217): 56 data bytes
64 bytes from 192.168.1.217: seq=0 ttl=255 time=6.001 ms
64 bytes from 192.168.1.217: seq=1 ttl=255 time=100.305 ms
64 bytes from 192.168.1.217: seq=2 ttl=255 time=123.462 ms
^C
--- ewelink_100171fd9d.local ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 6.001/76.589/123.462 ms
➜ ~ date
Sun Sep 25 11:16:02 EEST 2022
From Windows OS:
Microsoft Windows [Version 10.0.19044.2006]
(c) Microsoft Corporation. All rights reserved.
C:\Users\IgMi>ping ewelink_100171fd9d.local
Pinging eWeLink_100171fd9d.local [192.168.1.217] with 32 bytes of data:
Reply from 192.168.1.217: bytes=32 time=81ms TTL=255
Reply from 192.168.1.217: bytes=32 time=93ms TTL=255
Reply from 192.168.1.217: bytes=32 time=34ms TTL=255
Reply from 192.168.1.217: bytes=32 time=29ms TTL=255
Ping statistics for 192.168.1.217:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 93ms, Average = 59ms
As I checked zeroconf.org little bit - mDNS translate name to IP, which is required for actual communication. In my case: HA & Windows OS can translate THR316D mDNS name to IP, Bonjour browser see it too.
Integration log during Internet was disconnected attached - see bottom of message.
Approximate outage times: from 10:41 till 10:43.
See "missing data" on temperature reading graph:
And here is data flow from device same time:
2022-09-25 10:44:07 [D] 100171fd9d <= Local0 | {'switch': 'off', 'startup': 'off', 'pulseConfig': {'pulse': 'off', 'switch': 'off', 'pulseWidth': 500}, 'sledOnline': 'on', 'tempUnit': 0, 'timeZone': 3, 'sensorType': 'AM2301', 'currentTemperature': '9.8', 'currentHumidity': '92.8', 'autoControlEnabled': 0, 'fwVersion': '1.0.2', 'rssi': -75} | 610756
2022-09-25 10:44:12 [D] 100171fd9d <= Local0 | {'switch': 'off', 'startup': 'off', 'pulseConfig': {'pulse': 'off', 'switch': 'off', 'pulseWidth': 500}, 'sledOnline': 'on', 'tempUnit': 0, 'timeZone': 3, 'sensorType': 'AM2301', 'currentTemperature': '9.8', 'currentHumidity': '92.8', 'autoControlEnabled': 0, 'fwVersion': '1.0.2', 'rssi': -68} | 610757
2022-09-25 10:44:17 [D] 100171fd9d <= Local0 | {'switch': 'off', 'startup': 'off', 'pulseConfig': {'pulse': 'off', 'switch': 'off', 'pulseWidth': 500}, 'sledOnline': 'on', 'tempUnit': 0, 'timeZone': 3, 'sensorType': 'AM2301', 'currentTemperature': '9.8', 'currentHumidity': '92.8', 'autoControlEnabled': 0, 'fwVersion': '1.0.2', 'rssi': -58} | 610758
2022-09-25 10:44:22 [D] 100171fd9d <= Local0 | {'switch': 'off', 'startup': 'off', 'pulseConfig': {'pulse': 'off', 'switch': 'off', 'pulseWidth': 500}, 'sledOnline': 'on', 'tempUnit': 0, 'timeZone': 3, 'sensorType': 'AM2301', 'currentTemperature': '9.8', 'currentHumidity': '92.8', 'autoControlEnabled': 0, 'fwVersion': '1.0.2', 'rssi': -66} | 610759
2022-09-25 10:44:27 [D] 100171fd9d <= Local0 | {'switch': 'off', 'startup': 'off', 'pulseConfig': {'pulse': 'off', 'switch': 'off', 'pulseWidth': 500}, 'sledOnline': 'on', 'tempUnit': 0, 'timeZone': 3, 'sensorType': 'AM2301', 'currentTemperature': '9.8', 'currentHumidity': '92.8', 'autoControlEnabled': 0, 'fwVersion': '1.0.2', 'rssi': -69} | 610760
2022-09-25 10:44:32 [D] 100171fd9d <= Local0 | {'switch': 'off', 'startup': 'off', 'pulseConfig': {'pulse': 'off', 'switch': 'off', 'pulseWidth': 500}, 'sledOnline': 'on', 'tempUnit': 0, 'timeZone': 3, 'sensorType': 'AM2301', 'currentTemperature': '9.8', 'currentHumidity': '92.8', 'autoControlEnabled': 0, 'fwVersion': '1.0.2', 'rssi': -67} | 610761
2022-09-25 10:44:37 [D] 100171fd9d <= Local0 | {'switch': 'off', 'startup': 'off', 'pulseConfig': {'pulse': 'off', 'switch': 'off', 'pulseWidth': 500}, 'sledOnline': 'on', 'tempUnit': 0, 'timeZone': 3, 'sensorType': 'AM2301', 'currentTemperature': '9.8', 'currentHumidity': '92.8', 'autoControlEnabled': 0, 'fwVersion': '1.0.2', 'rssi': -62} | 610762
2022-09-25 10:44:38 [D] 100171fd9d <= Cloud3 | {'online': True} | None
2022-09-25 10:44:38 [D] 100171fd9d <= Cloud3 | {} | None
? Device has no local status True
leading to incoming data ignored during Cloud outage. Is it so ?
Maybe ewelink app works better with zeroconf (mDNS) than python library.
Does anything in here help? https://developers.home-assistant.io/docs/network_discovery/ Are you already using that? Or am I misreading it and it doesn’t apply here?
Have you tried to reboot Hass or even host server? Missing data is also "normal situation". Because without cloud connection and local IP - device marked as unavailable.
Have you tried to reboot Hass or even host server? Missing data is also "normal situation". Because without cloud connection and local IP - device marked as unavailable.
Just updated HA OS 8.4->8.5->9.0. Will monitor and let You know if notice smth new/changed.
So far we have this special situation "with no local IP", but actually locally online devices sending data - may be special handling possible to accept from Local0 incoming data also with no Cloud online/connection... ?
P.S. Hope local control of these exceptional devices will be fixed too, sometimes. But let's focus on received data from sensors for now.
Thanks AlexxIT for your great job!
Pls correct if my assumptions is wrong.
In ewelink\local.py
see what host
property is an IP address and Integration use IP addresses to construct URL' s to connect to devices.
Wondering why... IMHO one of the ideas of zeroconf is to use name resolution, thus to use in application/etc. and leave resolving to IP for zeroconf library !
3.2 Translation between Host name and IP Address
A zeroconf name resolution protocol allows users to refer to their
devices by name rather than IP address. Host names are more user
friendly than IP addresses and host names have a greater chance of
remaining unchanged over time.
Just tried on HA OS:
➜ ~ wget https://ewelink_100171fd9d.local:8081
--2022-09-25 15:03:48-- https://ewelink_100171fd9d.local:8081/
Resolving ewelink_100171fd9d.local (ewelink_100171fd9d.local)... 192.168.1.217, fe80::7a21:84ff:feba:d7fc
Connecting to ewelink_100171fd9d.local (ewelink_100171fd9d.local)|192.168.1.217|:8081... connected.
For me it means: it working fine while using names. IMHO Integration must use names and do not care about IP.
I think problem similar https://github.com/AlexxIT/SonoffLAN/issues/1130#issuecomment-1489902555 Should be fixed in latest master version
No new data from THR316D appears in HA after eWelink app is closed. After eWelink app started - new data appears in HA as soon see changes in app.
THR316D added after upgrade to 2022.8.0, so no idea how it works on previous Core versions
sonoff-a0656de0df0bb579aa4ece0459ab70e2-sTH OverHang-a9d3a7d4bf9eb492b9dbe427bfb4f40c.json.txt
Unfortunately no debug available - #936. .
As well no thermostat created for THR316D, as for TH16R2, f.e.