Free@Home System Access Point Firmware Update 3.3.1 not supported #190
Comments
|
I can't confirm at the moment but will wait with the update. Thank you for the hint. |
|
I have the same problem. I didn't even notice the SysAp update. First everything worked great but after a HA restart I was not able to connect to f@h. I even removed the integration entity and tried to configure F@H again but it doesn't work. |
|
Unfortunately, I am also affected by this problem. |
|
Are there any errors/exceptions in the logs? Posting as much info as you have is the best way to get support. |
|
|
@oliverlinsenmaier , looks like the SysAP is changing the format of the XML document being fetched by this integration. Looks like @jheling already attempted to clean-up the XML in previous versions. Here's the offending code. # Ugly hack: Some SysAPs seem to return invalid XML, i.e. duplicate name attributes
# Strip them altogether.
config_without_names = self.clean_xml(config)
root = ET.fromstring(config_without_names)I'm not sure if it's possible, but if someone would provide me with the XML coming from the SysAP I could attempt a fix. I don't want to upgrade my system if it's going to break it. :) |
|
Side note and completely unrelated. Xml is a pain to work with in Python (and maybe other languages too). It would be great if this integration could move to the local api which uses a JSON response and would have to adhere to JSON standards. And it's much easier and native to work with in Python (and it's local). I realize that's not an easy task. Looks like this has been in discussions for quite some time. #80 |
|
@kingsleyadam: How do I get the XML? Can I provide it to you via PM or something? I'm not sure if I want to share that with everybody... And I would love to change this integration to the local API, since from other services I know that this brought great speed improvements. I don't think this is really required here, since speed isn't an issue, but if it would make the integration more stable, this would really be great as well... Unfortunately, I'm not of great help in coding... |
|
@oliverlinsenmaier , you should be able to follow the instructions under debugging in the README. Looks like others have shared it via their own GitHub repo, or via issues like this, but I agree, not sure I'd want to share that whole file publicly. |
|
@oliverlinsenmaier, you can find me on Discord with the same name if you want to send it that way. Then I can try to reproduce it locally. |
|
When I change the "2" parameter in the getAll call in pfreeathome.py to "1" it seems to work again. |
Thank you very much. :) |
|
@ikorb / @kap46248 Can you provide the whole line? My changes didn't help at all... |
I assume they're talking about this line: https://github.com/jheling/freeathome/blob/master/custom_components/freeathome/fah/pfreeathome.py#L628 Try to update it to look like: my_iq = await self.send_rpc_iq('RemoteInterface.getAll', 'de', 1, pretty_value, 0)I've been doing some digging around to try and figure out what exactly that argument is, but with no luck. I assume it's somewhere in the ABB documentation which I can't find much of for this interface. |
|
I'm not sure what the difference between the two is, but with 1 the tag has a type attribute of "getAll" while 2 has a type of "debug". My guess is that type 2 is not used by the original software but only by the developers when something goes wrong, so they don't notice immediately when something is wrong with it. Type 2 seems to be a lot more verbose, so it's probably optimized for human-readability. |
|
I can't use the component since the a new authorization doesn't work for me. |
Interesting, I tested both and If it's true that
@oliverlinsenmaier , can you give more information? Maybe some logs or screenshots? It's hard to help triage issues with no info to go on. |
|
Hi everybody, can someone confirm, that the updated parameter fixes the issue and the component is running with firmware 3.3.1? |
|
When I do the parameter change - running with firmware 3.2.4 - I get the following error in the logs |
@derjoerg , this seems to be unrelated to the above. Once of the devices has a parameter value that's not an integer. Or at least it's a value that can't be converted to an int. Here's an example of some device parameters for one of my devices. <parameters>
<parameter i="pm0000" optional="false">
<value>1</value>
</parameter>
<parameter i="pm0001" optional="false">
<value>100</value>
</parameter>
<parameter i="pm0002" optional="false">
<value>100</value>
</parameter>
<parameter i="pm0003" optional="false">
<value>60</value>
</parameter>
</parameters>We'd need to know which parameter value that's causing the conversion issues on your system to figure out what's going on. You can do a configuration dump using the instructions in the README.md (note this should be done in Home Assistant, not the SysAP): https://github.com/jheling/freeathome/?tab=readme-ov-file#1-dumping-freehome-configuration Then you can sift through the |
|
OK, |
|
So, Nevertheless, I also understand that I don't find a non-integer/number value as the problem only comes up, when I change the parameter to 1 (but then I can't do a dump anymore). |
|
@derjoerg, Looks like I was pointing you to the wrong value, the conversion is taking place on the Here's what one of mine looks like.
To test the values you can do a simple check in a Python console window if you have Python installed. Bring up Python console python3Run the following Python code parameter_id="00ED"
print(int(parameter_id, 16))Output Or use an online interpreter like: https://www.online-python.com/ 
That'll help nail down which device and parameter id that's giving problems. |
|
So, |
Without having the config and being able to run it through the code it's hard to tell. But this code is only being used for Thermostats, so if you don't have thermostats you could remove the |
My only other guess is that when the Python code is running |
This is not an option :) |
Now I get the following error: |
|
I solved it in a bit ugly way, only fighting the symptoms and not the root-cause: |
That works. I did run your config through the code and I wasn't able to replicate it locally. The only time this condition was true was for The only other time this code was hit was for You can add more logging to your code to know exactly what the value is that's failing. You'll have to update the entire function because they used a protected keyword def get_parameter_by_parameter_id(xmlnode, parameter_type, parameter_id):
"""Returns output parameter by parameter id."""
for parameter in xmlnode.find(parameter_type).findall('parameter'):
LOG.info(f"channelId: {xmlnode.get('channelId')}; parameterId: {parameter.get('parameterId')}; type: {type(parameter.get('parameterId'))}")
if int(parameter.get('parameterId'), 16) == parameter_id:
return parameter.get('i')
return None |
This makes sense, there's a parameter somewhere in your config file that doesn't have the
I don't see that in the config file you attached though, which is odd. So the fix as I see it, if the parameter doesn't have a parameterId then it should be ignored. |
|
I just encountered, that I uploaded the dump with the parameter in getAll set to 2, here is the updated dump with the parameter set to 1. I implemented your above suggested line and I "only" have now a problem with one temperature controller (out of 10 I have) [ABB700DB2FFB]. |
So it seems setting the "debug" value to 1 removes some other bit of information. This has been quite the slog to triage between the code and the XML file formats. You may have to setting the debug value back to 2 and figure out what XML issues there are. |
|
Ok, so at the moment I will stay with 2 and will not update the firmware to 3.3.1. I don't understand why only one of my roomtemperaturecontrollers have such a problem and all the others are good. I don't see much difference comparing the xml of similar devices. |
|
@derjoerg May I ask if some of them have a temperature correction and some do not have any correction? It might be that the behaviour has changed and if no correction is present the controller return none value instead of 0? |
|
@steffenaxer I also thought about that and went in the Web-GUI of the SysAp and for each controller I changed the "temperature correction" to 0.5 saved it and returned to 0.0 and saved it. |
Is this a current freeathome dump with the new firmware? @derjoerg |
No! I'm still on 3.2.4. I heavily rely on my freeathome integration in HA so for now I don't do the update |
|
Could anyone who has 3.3.1 installed upload his backup from the freeathome backup service? |
|
I've closed my PR for now as it doesn't seem to be a valid solution. |
|
Hi, I just had a conversation with someone in the Busch-Jäger community and this guy upgraded to 3.3.1 and everything is still working Sorry it is in german |
|
I updated now also to firmware 3.3.1. HA runs fine for me, even after a restart of the HA core. |
|
Thanks to @steffenaxer for the support enabling a custom debugging on my side and fixing the issue with the XML available. This is really awesome - Thank you! |
What was the problem and the resolution? |
|
I will provide a PR within next minutes. The problem are again duplicated attributes delivered in the xml. |
|
Thanks to @steffenaxer ! Had the described issue after the update and the fix worked for me. |
|
Sorry, but where do I have to place the code? |
|
@Triple5soul89ny : See here https://github.com/jheling/freeathome/pull/192/files It tells you which file and what to change. The changes can be made with a simple editor. |
|
Thank you very much @steffenaxer for this bugfix. |
|
Have updated SysAP to 3.3.2 and updated free@home Integration in HACS to the new Version 1364e7e. Everthing works for me. |
|
Same for me |
|
Hi all, new here. I have a fresh docker setup of Home Assistant (2024.7.4) running on a PI4, have added the freeathome integration (manual install in custom_components) to it now (most recent pull). My SysAP has version 3.3.2 Rev. 12875. When i try to add the free@home integration (it is autodetected as well in HA), it hangs at the setup screen forever. No errors in HA debug logs or docker logs are displayed (even with debug mode in HA). tcpdump shows that when I hit on setup, a settings.json is requested from SysAP and it is also provided back to HA. However, after that, everything seems to come to a halt somewhere. Seems that i can't connect to the SysAP... I came across this thread - hope you guys can help me? |
|
Sorry, without any stacktrace or log we can not debug anything. Have you tried installing it via HACS? |
|
This can be closed, thanks to @steffenaxer and @derjoerg |
Hi all,
Can somebody confirm that 3.3.1 is not working with Home Assistant and this component? Is there a possibility to downgrade the system access point?
The text was updated successfully, but these errors were encountered: