hassio lockout

[scooper1]

on 110b3 release complete none start of hassio - not even recovery system had to start a docker bash prompt and use vi to remove the ecowit: configuration from configuration.yaml

can you please test on lastest beta and post how to fix installed via hacs thanks

[garbled1]

Did you get any messages from ecowitt in the logs, if so, could you post them? Also, did you have your device setup to send messages to the instance? (this should not impact, just wondering)

I don't run hassio.. not sure how to test unless you can post logs?

[scooper1]

I run a standard home assistant supervisor docker image on a hp i5 pc The problem occurs after restart to start component listening to port I had not yet configured ecowit device to talk to custom endpoint There were no relevent logs in log file at default warning level did not try debug It looks like it got to initialising the custom components and froze at your component

[scooper1]

You do hint at this because you say that about long startup on slow updates from ecowit I would not find a integration that has to have data from external device to allow rest of system to boot as usable

[garbled1]

The way it's setup right now it might not start without the device connecting. I'll dig in and see if I can rewrite it slightly to do so.

[scooper1]

I don't really have a problem if it just took out that integration but to stop the whole system starting is not good I will try again when I got time and configure the ecowit device first

[scooper1]

having configured the ecowitt weather station to send requests to the server the system does startup

some minor improvements

get the following logs 2020-05-20 01:08:33 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type maxdailygust 2020-05-20 01:08:33 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type hourlyrainin 2020-05-20 01:08:33 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type totalrainin

it would make finding sensor quicker if you added an instance name to start of sensor name ie "sensor.ecowit_totalrainin" this makes it easy to understand where data is coming from

for some reason the sensors do not show in the unused entity list in Lovelace - which makes adding them a lot more difficult for some users -EDIT they do show up after some time - note in readme would be helpful

[garbled1]

Can you tell me the make/model of your system, just curious. I'll add those sensor types when I look at the code to try to fix the startup, also, will note in readme. thx.

[scooper1]

Wh3000se

Sent from Mail for Windows 10

From: Tim Rightnour Sent: 20 May 2020 14:19 To: garbled1/homeassistant_ecowitt Cc: scooper1; Author Subject: Re: [garbled1/homeassistant_ecowitt] hassio lockout (#2)

Can you tell me the make/model of your system, just curious. I'll add those sensor types when I look at the code to try to fix the startup, also, will note in readme. thx. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[peetipablo]

I'm having the same issue where HA will not start when ecowitt is listed in configuration.yaml, however I can't tell the cause. I have configured the ecowitt wifi gateway as instructed prior to adding 'ecowitt' to configuration.yaml. Installed the component from HACS.

arch	x86_64
chassis	vm
dev	false
docker	true
hassio	true
host_os	HassOS 4.8
installation_type	Home Assistant
os_name	Linux
os_version	5.4.43
python_version	3.7.7
supervisor	226
timezone	America/New_York
version	0.110.4
virtualenv	false

I'm getting this in the log when I start HA:

2020-06-03 10:13:32 ERROR (MainThread) [aiohttp.server] Error handling request
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/aiohttp/web_protocol.py", line 418, in start
    resp = await task
  File "/usr/local/lib/python3.7/site-packages/pyecowitt/ecowitt.py", line 181, in handler
    weather_data = self.convert_units(data_copy)
  File "/usr/local/lib/python3.7/site-packages/pyecowitt/ecowitt.py", line 117, in convert_units
    data["temp1c"] = self._ftoc_(data["temp1f"])
AttributeError: 'EcoWittListener' object has no attribute '_ftoc_

[garbled1]

Oops, there was a bug in pyecowitt regarding one of the temperature conversions.. I'll need to publish a new pyecowitt version with that fix.. will try to do later tonight.. sorry!

[peetipablo]

Oops, there was a bug in pyecowitt regarding one of the temperature conversions.. I'll need to publish a new pyecowitt version with that fix.. will try to do later tonight.. sorry!

No trouble at all. Please don't apologize, I appreciate you working on this custom component!!

[garbled1]

Fix for the ftoc problem should be in master, try that please.

[peetipablo]

Looks like that worked! It would be great if an issue w/ this integration didn't prevent the whole home assistant application from starting, but I understand you are already looking for a way to do that. Thanks a lot!

[vlat0101]

Having the same non start issue with HASS.io. Happy to help if you point me to the logs you need.

[garbled1]

Anything that says "ecowitt". Also, did you configure your ecowitt to start sending data to your hass instance prior to restarting?

[vlat0101]

home-assistant.log tcpdump and docker.txt

Included log output and also tcpdump and docker ps.

I can see packets coming in to docker host running hassio but then not sure if hassio is seeing the packets as it is not listening on port 4199.

[Entropy512]

I have an ecowitt GW1004 kit on the way (should arrive later this week).

I'm trying to wrap my head around some of the details of the Home Assistant API - a lot of things are very unclear/not very well documented (such as being able to find any details on async_load_platform), but I did have one question:

Where is the requirement to fire off async_load_platform() within async_setup() stated? Or was this requirement assumed/determined by experimentation?

I'm guessing hassio is hanging waiting for async_setup() to complete - so why not fire off the async_load_platform() discovery event on the first execution of _async_ecowitt_update_cb() instead of within async_setup()?

[garbled1]

Hrmm.. Good question.. Maybe I'll just try that? I don't recall anymore if I found that was absolutely required or not. I'll give it a go this weekend.

[Entropy512]

I might take a look myself this weekend if I don't have family visiting. (But I probably will.)

I took a look through the MQTT integration code to see how they do dynamic discovery... And they don't seem to use any of the load_platform calls for discovery? I might take a look at the ZHA integration for some hints/learning experience next since that also does automatic discovery.

[Entropy512]

As a side note, what's your workflow for keeping your home assistant custom_components folder synced while you are developing? A symlink from config/custom_components/ecowitt to custom_components/ecowitt in a git repo elsewhere on the filesystem, or is there another easier trick?

There are a couple of features I'd like to take a crack at adding (ability to set the force_update property, virtual dewpoint sensor similar to what Tasmota does in https://github.com/arendst/Tasmota/blob/development/tasmota/support.ino#L642 ) in addition to taking a look at this issue here.

[garbled1]

Yeah, I usually just do the symlink trick.. the hacs tree format makes it harder than if it's just a flat directory.

[garbled1]

The only thing I know of that does a similar thing to what I'm doing here, is the greeneye_monitor integration. It also sets up a listener, which is sort of the key here. In it's case, what it does is require the config to be filled out manually in the file, so it doesn't have to wait for the device to tell it what objects it has... I was trying to avoid that..

[garbled1]

I think this fixes it? I'm just not sure if it works for a system the very first time we hook up an ecowitt. It works fine for mine with existing entities.