Hmm yeah not sure how to check there, probably a way but I don’t know how.
Is there a way to manually install the library? If PIP is needed for the normal install routine then I do have an older version.
I really want to migrate away from Hass.io and it’s limitations but now isn’t the time. Still digging.
Hass.io uses pip under the covers, but I think things are in docker? So Home Assistant is running in a docker container which has pip installed. You would need to be able to connect to the command line of that docker container in order to manually install or install with pip. What version of HA are you running? It is possible that the custom component isn’t working anymore because the way the file layout changed in recent version.
Can you download this and extract it over your current custom components? https://drive.google.com/open?id=1MxPB9NXwMrBRZPWLiioEkYHpYaJ_ZF55 This is using the new file structure so it might fix it. Also if you watch the logs you should see it try to install pyeconet.
I have the same issue with this in the log:
2019-04-22 07:16:13 ERROR (MainThread) [homeassistant.helpers.entity] Update for water_heater.heat_pump_water_heater_gen_4 fails
Traceback (most recent call last):
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity.py”, line 220, in async_update_ha_state
await self.async_device_update()
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity.py”, line 379, in async_device_update
await self.hass.async_add_executor_job(self.update)
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/homeassistant/components/econet/water_heater.py”, line 210, in update
self.water_heater.update_state()
File “/usr/local/lib/python3.7/site-packages/pyeconet/equipment/water_heater.py”, line 123, in update_state
for equipment in vacation.get(“participatingEquipment”):
AttributeError: ‘str’ object has no attribute ‘get’
My pyeconet version is:
pyeconet==0.0.10
@bwoodworth thanks, looks like that should be fixed with the beta version if you want to give it a shot. I’ll try to get this officially added some time this week.
I am on version 91.4 The new file is loaded and running. I also removed the water_heater directory under custom components, right? Fingers crossed. Thanks for your help.
Correct, deleted the water heater directory.
It has been working OK so far except for one time the command to change modes didn’t work. I went to the unit and observed it go to eco mode, as commanded, then immediately back to off mode. I cycled thru off mode command followed by eco mode and it worked. I’ve not seen any “unavailable” entity states so far, YAY!
I did see
2019-04-23 17:30:48 ERROR (SyncWorker_15) [pyeconet.api] State not accepted. 503
when the failure occurred.
Okay good deal sounds like it’s working better. Not sure what the state error was about seems a bit strange but could have just been a service issue on there end?
Day 3 and zero failures !!! Dare I try updating to v92.0? I’m attempting to resolve some zigbee issues.
Glad to hear it should be able to get this officially pushed this weekend. The 92 update shouldn’t be an issue for this, not sure on zigbee. What issues you having? I am still on 90.1 because it’s so stable with all my zigbee stuff.
The v92.0 seems to have gone smoothly so far. Upgrades here seem to be more risky than most software.
I have mostly zigbee lights. They are somehow being forgotten and go unavailable. Sometimes just manually cycling the power on the light gets it working again. Sometimes it takes a “re-learn” Of course, Murphy’s Law dictates the lights stop working at the worst time possible.
I get the feeling HA is rethinking some of the standards and are adjusting things to allow for future expansion. Hopefully it will be worth it in the long run. Exciting times we will look back on and laugh.
Sadly, my failures are back. Nothing in the log.
Latest errors now from log
2019-04-30 07:00:48 ERROR (MainThread) [homeassistant.helpers.entity] Update for water_heater.hw fails
Traceback (most recent call last):
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity.py”, line 220, in async_update_ha_state
await self.async_device_update()
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity.py”, line 377, in async_device_update
await self.hass.async_add_executor_job(self.update)
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/homeassistant/components/econet/water_heater.py”, line 208, in update
self.water_heater.update_state()
File “/config/deps/lib/python3.7/site-packages/pyeconet/equipment/water_heater.py”, line 123, in update_state
for equipment in vacation.get(“participatingEquipment”):
AttributeError: ‘str’ object has no attribute ‘get’
Looks like it isn’t loading your custom component again.
I thought the same. I downloaded from your google page and copied it into custom components overwriting the existing files. No difference. If anything it is now worse in that it goes unresponsive much more frequently.
v92 made no difference on my other issues as well. I think tomorrow I may try and go back to 91. I may just give up on Econet. Time is tight.
I opened the MR and it was merged in so hopefully in 93 this will be officially added and things get better for you. I do think something related to how custom components loads was changed in 0.92 so could be something with that.
So downgrading to 91 and waiting for 93 seems to be the best path.
Thanks again for your help.
No problem, let me know how it goes.
The downgrade to v91.4 went smoothly. Water Heater has yet to fail, something that would have happened at least 3 times by now. I’m confident it will be fine. My Wake-On-Lan function is back, it was also broken with v92. My Zigbee issue is the same but not as bad as it was on v92.
All things considered, someone will need to confirm water heater works with any future version before I jump again.