Closed CoMPaTech closed 4 years ago
@CoMPaTech I think we should investigate a bit more before we push this update. I'm thinking the reported problem is not normal, maybe it is due to a misconfiguration, maybe it can be fixed by a factory reset of the Anna in question?
Not sure, but finding it by tag
makes more sence to me (in hindsight) as 'what if' they decide to rename it. A name
as such is somethings thats changeable/language, that's why I think it makes sense to use the tagfinder instead of name. IIRC thats also the original route @laetificat took.
I looked at your code-change and noticed the fall-back :) I still think the Anna in question should be rebooted, or something similar, to see whether that remedies the issue. What is the firmware version on your Anna? Mine is 3.1.6. Is yours really 3.1.8?
Let's close this issue, it's fixed I think?
I was thinking when looking at this issue again, the problem is, when there is no name for the schedule(s), as in w2ckers-case, other stuff will not work. We might have fixed this particular error but there will be other errors.
@CoMPaTech I think this Issue can be closed. I mean, w2cker tested my new code. The weekschedule that he has created is properly detected. And there were no errors in his log. I'd say your fixes are working!
Totday I updated HA to version 0.102.0. I get the following error now in the log: "File "/usr/local/lib/python3.7/site-packages/haanna/haanna.py", line 197, in get_rule_id_by_template_tag rule.find("template").attrib["tag"] KeyError: 'tag'". Anna integration not working anymore. :-(
Please let us know the firmware-version of your Anna, and please post the contents of
http://[you smile ip]/core/domain_objects
on pastebin.com.
This will help us to find what is causing the issue.
Domain Objects here: https://pastebin.com/pduQDyz6
Firmware version is 1.8.20.
I think you have to add the legacy statements then ... see https://www.home-assistant.io/blog/2019/11/20/release-102/#read-more on breaking changes. See https://www.home-assistant.io/integrations/plugwise/ on setting legacy_anna
After changing this, I got a new error:
File "/usr/local/lib/python3.7/site-packages/haanna/haanna.py", line 373, in get_schedule_temperature return float(measurement) TypeError: float() argument must be a string or a number, not 'NoneType'
Any change I can update to a higher version?
I looked at the various codes, I can't find anything obviously wrong at the moment. But, I added detection for the reported fault. This specific fault should be gone. Can you please test the updated haanna-code for me? Let's see where that leads us.
Replace in the file /homeassistant/components/plugwise/manifest.json on your system:
"requirements": ["haanna==0.13.5"]
by
"requirements": ["https://github.com/bouwew/haanna/archive/master.zip#haanna==0.13.6"]
and let me know the result.
I created it as custom component (I'm on Hass.io) but with this change it's working again. But... setpoint and presets have disappeared.
Can you reproduce the fault in the custom component with haanna 0.13.5?
I'm at a bit of a loss, it's working fine in my system (3.1.7) and it's working on someone else's legacy Anna. I've compared your XML-data to this persons XML-data, basically they are the same. So I don't understand why it's not working for you. The value is present in your XML but somehow the Haanna-code doesn't find it, very strange.
What do you mean with "reproduce the fault in the custom component with haanna 0.13.5"? And to make it even better: I have two Anna's (also one upstairs). Both ain't working well.
You have created a Plugwise custom component, correct? And you've made the change in the file manifest.json as I asked? Now I'm asking you to revert the change you made to this file and try again. Does this result in the same error?
You write you have two Anna's, do you have these both "connected" to Home Assistant? How? Via 2 separate climate instances in HA? You must have 2 Smiles then?
Can you show me how your Anna climate device(s) looks like in Developer Tools --> States?
I have this:
I think I have found what is causing the error. Not sure how to solve it yet. And I see you have more issues: state and hvac_modes also don't work.
I will not be available for the coming 2-3 weeks, I'm moving to a different city, 2 hrs drive away. I will let @CoMPaTechknow what I have found, maybe he has time to fix the reported error.
I could not let this go yet :)
I have made a haanna-simulator in which I imported the XML-data that you put on Pastebin.
In the simulator, the schedule_temperature
is found correctly, there is no error.
So, I think there is something wrong with your HA-system, maybe the haanna-version on your system is outdated, or something went wrong with the 0.102 update.
After updating your HA-system, you've made Plugwise into a custom component, you wrote. How have you done that? Which files were put where? And please show the contents of the file manifest.json of your custom component.
@fwestenberg, another user reported the same problem as you have found. According to his information the fault happens when there is a week-schedule present but it's not activated. The fault disappears when the week-schedule is activated. Is your situation the same? Do you have a week-schedule present but it's not activated?
My week-schedule is empty. I deleted it because I don't need it. I will create one and see if this solves the problem.
Can you first create another XML-dump? That might help us to find a solution.
It looks like it's all working as it should?
But where is the setpoint adjustment?
But seems you are right. This card works well, also setpoint adjustment.
Where are these pictures from?
Can you please check in Developer Tools --> States? It should be there.
@fwestenberg, can you please copy the files climate.py
and manifest.json
from here:
https://github.com/bouwew/anna-ha to your Plugwise custom_component?
I've tried to fix the issues related to not having a week-schedule. Please test this with and without a week-schedule being defined (please make sure to delete the schedule).
@bouwew Thanks for all your effort. I created a git repository with the files I used for testing with custom component. https://github.com/fwestenberg/plugwise_dev
The pictures I sent are from the Home Assistant dashboard. But when I check the Anna data now, I see the following:
The thermostat "climate.thermostaat_overloop_test" has no schema present. Setpoint is set at 18 degrees. -> https://pastebin.com/cxVQhyQV The thermostat "climate.thermostaat_woonkamer_test" has a schema present. Setpoint is set at 20 degrees. -> https://pastebin.com/5SEx9WJ2
I just found out you also have a custom_component repository for Anna. https://github.com/bouwew/anna-ha Are you sure the requirements in the manifest.json gets installed for the custom component?
Ok, the github helps. You don't need to copy the haanna-files, they will be automatically installed by Home Assistant. I see you did copy the climate.py file from my github. Also, you need to copy (the contents of) the manifest.json file from my github. And then restart HA. Then it should work, I hope.
Yes, I'm sure, I have been using this method for quite some time now. It's also described in the HA documentation somewhere.
Exactly the same result with your library, but I discovered something interesting... For some reason my two thermostats always got the same values, And when the thermostat with schedule gets loaded (seems random) the setpoint is there. But when the thermostat without schedule gets loaded, no preset is possible. So adding a schedule solves the problem, but the main problem to me is how to handle two Anna's ;-) .
How does you configuration look like? You have 2 Anna's each connected to its own Smile? Or are the both connected to the same Smile? And you have 2 config-entries in configuration.yaml?
Ok, time to get ready for the movers, I'm going off-line soon...
I have 2 Anna's with 2 Smile's. And also 2 config entries. But I just found out the statics in haanna.py are what causes the trouble. :) Please check out my pull request #28.
@fwestenberg What do your climate entries look like when you have loaded your improved haanna-code?
As you can see, the values are supplied correctly and different for each thermostat.
@fwestenberg can you please upload a new capture of the XML of your upstairs Anna?
@fwestenberg can you please upload a new capture of the XML of your upstairs Anna?
The thermostat without schedule (upstairs): https://pastebin.com/DZfQeiB4 The thermostat with schedule (downstairs): https://pastebin.com/fYn2BVpL
Also, I created pull request #28. Any idea when this will be merged?
Thanks! I'll have a look later. To what kind of heating system is your upstairs Anna connected?
Also, I've included your pull request in my haanna testing repository, working fine in my HA system.
@fwestenberg can you please upload an xml-capture of the overloop-Anna when the heating is on/active?
I looked at both XML-captures, the one of downstairs has the central_heating_state
key that the software is looking for, but that key is not present in the XML-capture of the upstairs-Anna. This causes hvac_modes
to be null
-state in HA.
I think this also is related to the connected heating device.
I wonder if maybe the key is shown in another location? Can you please provide XML-captures of the following four locations: http://[your smile ip]/core/domain_objects http://[your smile ip]/core/locations http://[your smile ip]/core/appliances http://[your smile ip]/core/rules
Sorry to be asking for so much data, but that will be my only way to find out what is going on.
You can download the files from WeTransfer
By the way: my thermostat downstairs is OpenTherm connected with the heating system. The upstairs thermostat is connected with On/Off. So this might also result in different value sets?
Thanks!
Yes, that is what I expect is going on.
I just found a typo in the endpoint of my latest PR. Now it setting the preset from the thermostat downstairs seems to be all working here. But still the thermostat upstairs has no presets.
Is there any chance to get the presets translated? Anna (v1) just has 8 language files available, so it's easy to get the translations from there.
If you check the available translated presets, you'll see "vacation", "asleep" and "no-frost" are missing in the translations:
https://github.com/home-assistant/home-assistant-polymer/tree/master/translations
You can create your own pull-request towards the translation :)
Or use the Simple Thermostat card, you can configure the names of the presets to anything you like.
Modify (and test!) if searching for "a rule that has a
template_id
tag containingzone_setpoint_and_state_based_on_preset
and hasactive
set totrue
" instead of what is currently implemented in haanna.py (lines 62/63):As reported in https://github.com/home-assistant/home-assistant/issues/26520