-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2.0 MdnsHostname issue #83
Comments
ok , the issue here is that the hub is no longer emiting station data in its JSON payload, they must have upgraded it recently.... Two methods therefore barfed (hubname and macaddress). What Ive done is modded them slightly to return a dummy value for now, specifically the getHutName returns the model identifier. Can you test it by pulling the patched python I think (from within your docker environment if needed) @msp1974 This is used in config_flow.py/test_connection, is it actually needed? or can we hard code a value there? |
mmmm not sure, this worked... edit |
Its very weird, this works now in my Development environment but in my production env its weird. For some reason Config Flow doesnt allow me to choose "WIser" (not there in the list) but if I use config params it works fine.. I need to get to work now (already 2hrs overdue!), but can people check the new library? if so then I'll release the new lib as 1.0.7.2 and release 2.1 so that it forces a new library pull |
I'll have a look at this later today. I am getting the same error as @Fulch has reported but it is loading fine in prod. Hub version is 2.46.0-bdf6fc5032 and it is showing station info in network - need to check json is not different. HA verison is 107.7. |
@asantaga Can see in add integrations also. Have you done a browser cache refresh on your prod? |
@asantaga ok think I have found the issue. There is a typo in line 203 of the api just a small caps v lowercase issue but that's why we love linux!!! ;-) Will send a PR to fix this and put back the macAddress and hub name functions then look at the config flow issues. |
I looked at the network response using postman and I couldnt see network data, but yeah dont we love typo's.. Im on VPN now for work so I cant check my lost hub (version etc) but from what I can see there is no longer a network section... |
Have sent you a PR to fix the typo. This will make it look like no data is being returned from the hub for network. If no longer a network section then i have made it return something that will ensure it does not error. I think 2.46 is the latest version as sure mine was on 2.45 not that long ago. Be sure you are using the /data/network/ path in postman. |
This will be because it does not run this code if you already have a config generated by config flow. If we fix this erroring then should be fine. |
I did update this morning before work and it fell over. removed my config from HA config.yaml and tried the integration and got a unknown error. Sorry I can not give you any more useful information as I was going to try again after work. |
Ok, have fixed the typo in my local copy of the api and can confirm no more error messages on startup. Can also confirm no obvious firmware updates on my hub in the last month ( 2.46 currently ) as I have a json dump from back then. "ActiveSystemVersion": "2.46.0-bdf6fc5032", |
I also ran into the stacktrace ending in I locally tested asantaga/wiserheatingapi#19 with 36a96b8 of this repo, and it works now again. Thank you all! |
Great. Thanks for testing and letting me know. Also on the areas issue too. |
Have had same issue. Happy to test fix here too if it helps but will need to know how to install patch on RPi HASS.IO. Otherwise, I will wait until new release is available. Thanks to all for a great component! Looking forward to the new features in this 2.0 release. |
Merged base api fix |
Ive tested this out and all looks fine now.. Ive created a new Release R2.1_beta1and if all is ok We'll simply make it R2.1 |
Still broke for me Traceback (most recent call last): |
yeah.. I forgot to up the version of the api in wiser component (although I could have sworn I did it, but obviously not) (beta) R2.1_beta2 released (whilst you can fix it by manually upgrading the library , best to try the release) Leaving this issue open until people confirm its fixed. |
This is what happens when you outsource dev work to.your kids! :-) |
More like when you work hard during the day, look after the kids and then think ahh yeah its 11pm time to do X,Y,Z... |
You went wrong by working hard! 😆 |
Yeah during the day we deployed a huge software release to a Eurpoean customer.. thankfully they have a proper testing department.. note to self, tear down, test, tear down , test.. release...........fix... |
I'll wait 24hrs before making it a prod release on HACS |
Forgot I have cloud access opps. While I'm working very hard at work "cough" "cough". Updated to beta 2 and all working fine. The devices are in the integration page and love the battery sensors. Great Job 👍 |
lol
…On Tue, 31 Mar 2020 at 11:29, djashjones ***@***.***> wrote:
Forgot I have cloud access opps. While I'm working very hard at work
"cough" "cough". Updated to beta 2 and all working fine. The devices are in
the integration page and love the battery sensors. Great Job 👍
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAWN2QD3TYL3XI7RC7JL4EDRKHAYZANCNFSM4LWMWPBQ>
.
--
Angelo
|
thanks now working |
Quick question. If I delete my config settings in the yaml file and use the integration settings. Where are my settings stored exactly if that makes sense? |
dont actually know, I was looking at the docs https://developers.home-assistant.io/docs/config_entries_config_flow_handler and it doesnt say. Im guessing its stored in the DB file |
The wiser config settings are in a file called core.config_entries, which is in the hidden .storage folder inside the config folder. |
well ya find something out every day! Well this 2.1 Release seams to be ok.. Release it as production? |
It’s all good my end |
f9c6f67 works for me |
resolved in 2.1 |
it appears that 2.0 release is broken
Breaks on two systems I have control of
It broke on startup - maybe insists on config flow via integrations page - No warning in release notes to convert yaml to config flow
it maybe to do with the latest superviser release changing to internal DNS server
returned back to 1.91 all is ok again
error for 2.0 is
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/aiohttp/web_app.py", line 458, in _handle
resp = await handler(request)
File "/usr/local/lib/python3.7/site-packages/aiohttp/web_middlewares.py", line 119, in impl
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/real_ip.py", line 39, in real_ip_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 72, in ban_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 127, in auth_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 123, in handle
result = await result
File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 163, in post
return await super().post(request, flow_id)
File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 50, in wrapper
result = await method(view, request, *args, **kwargs)
File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 92, in post
result = await self._flow_mgr.async_configure(flow_id, data)
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 130, in async_configure
result = await self._async_handle_step(flow, cur_step["step_id"], user_input)
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 172, in _async_handle_step
result: Dict = await getattr(flow, method)(user_input)
File "/config/custom_components/wiser/config_flow.py", line 72, in async_step_user
ip=user_input[CONF_HOST], secret=user_input[CONF_PASSWORD]
File "/config/custom_components/wiser/config_flow.py", line 44, in _test_connection
return await self.hass.async_add_executor_job(self.wiserhub.getWiserHubName)
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/local/lib/python3.7/site-packages/wiserHeatingAPI/wiserHub.py", line 228, in getWiserHubName
return self.wiserNetworkData.get("Station").get("MdnsHostname")
AttributeError: 'NoneType' object has no attribute 'get'
Discovered by @scooper1
The text was updated successfully, but these errors were encountered: