ism7mqtt Unable to read data from the transport connection (Wolf CHA 7 with ISM7 Link Home) #112
Comments
|
Same thing with the addon for home assistant. Is my new Wolf Link Home broken? Testet with smartset app and cloud, both works fine.. https://github.com/b3nn0/hassio-addon-ism7mqtt |
|
I have the same problem with my brand new ism7. I try ism7mqtt the first time today and do not get it running. So I do not know whether it worked before. I tried the debug modus "-d" and it looks the the first login works fine (I get a direct-logon-response) but after 60 seconds the connection is closed. Not sure whether the logged XML after the logon request is a response of the ism7 or is it just the request payload? Environment How I start Output after start Output after another 60 seconds parameter: |
|
I did a cross check:
Outcome the second start: |
|
If it helps for finding the root cause: |
|
For another cross check I installed the Smartset PC application which uses the local connection. That works. So the ism7 provides the data locally. |
|
@CEXC In case the Smartset PC app requests data (here as example cha-7 outside temperature, PTID="270004", in="12"), the XML request body sent to the ism7 it looks like this:
In case is ism7mqtt is requesting the same data it looks like this:
When laying the important parts of the request on top of each other, it looks like this: By adapting these attributes in the code I finally found out that the missing content of the "se=" parameter is the root cause of the exceptions. When adding content to the parameter in the source code, everything works fine (at least I do not get any Exception anymore with my test code and the outside temperature is written to console in debug mode every time it changes). That was the good news. 👍 The not so good news: I have no clue what has to be written into the It would be great to get @zivillian on board. Maybe he has more knowledge about that topic. It might even be that all ism7mqtt installations stop working when they update to newer firmware. P.S. |
|
Can you try to send some static value as Maybe it's also enough to just send an empty |
|
I will try some static values with multiple attributes in the request and see whether one can put anything into the parameter as long its has the syntax "Character;Number". But I'm not sure how and when to handle parameters with multiple numbers (see e.g. An empty The attribute is definitely the root cause. I re-checked it a second ago: Without a value it is causing the IOException. Just changing the code for both, "pull" and "post" TelegramBundelTypes will heal the problem. For example for push:
I will check now if any Character/Number combination is excepted or whether A/B/C has some semantic meaning... |
|
I'm not sure how far I will come time-wise today with testing. It might be that I'm not able to test anymore before Thursday evening. Quick tests:
So this request works: |
|
I did a test with two attributes of the Wolf CHA (PTID 270005 and 270006) and all of the following variants worked well:
So it seems that for the new ism7 FW and/or the new ism7 HW the rules are:
As last check I will test one of the attributes which have multiple numbers (some kind of list?) and sensors of two different device (e.g. cha and ism). But for today I'm done with testing. @zivillian |
Sure, take a look at the github actions dotnet publish -c release -r linux-arm64 -p:PublishTrimmed=True --sc -nowarn:IL2026,IL2104 src/ism7mqtt/ism7mqtt.csproj |
|
I did a night-shift :-P I build the "fixed" code for my raspi and added it as service with a parameter.json consist of 15 entities in one device: The service was running perfectly for 14 hours before I stopped it to do some further tests: I tried to find out how the I just found I do see the value in my home assistant. So it seems to work without taking care of multiple numbers in the After that I started the service in my raspi with nearly all attributes found by ism7config. I now receive some 200 new ism7 entities in home assistant. :-) @zivillian P.S. |
|
I will not create a pull request today as my solution seems unfortunately not to be stable with all parameters added. I let ism7mqtt run on a raspi 5 as systemctl service. The problems I face with my self-compiled solution:
So my ism7 seems kind of stopped sending data to any network (neither cloud nor locally). The data on the BM-2 is correct hence. I do not know whether that would had happend anyhow or whether my change is responsible. I'm counting up the Turning the CHA-7 completely of and on again has healed everything. I will test some changes (not counting up endless, using an dedicated interval) |
|
Hmmm, just saw in debug output that the highest number is just "A;480". The "push" registration for listening to the attributes is only done once at startup. The numbers do not increase anymore after that. So that is not a problem. Not sure what I can check anymore to find out why my ism7 has stopped sending data to the networks. |
|
You could check and try to run with the sane value of se for all requests, e.g. se="A;46"..!? |
|
My comment was a bit misleading. I tried to express that the numbers are not the problem. They do not increase after the startup phase and are smaller than what the Smartset PC app is sending. Meanwhile I found some posts in the internet where users had the same problem: ism7 is not sending any data anymore until a reboot of the Wolf CHA. So maybe my problem had nothing to do with my code changes. I will observe it over the weekend. |
This could be a general issue. As soon as i got my ism7 and set it up, i got a call from Wolf that my CHC/CHA has to be an Update, it is for free and will be dated on August 21. They dont explain the reason. Last Updateservice of my Wolf CHC is only a few month ago, less than a year. Will we be able to get your changes into the homeasistsant addon? In this case i could report if i have the same problem and whats happend after the update of wolf chc/cha. |
Would you share the links to those posts? And I wonder why there are more differences in the XML from here ae="false" vs. ae="true" Maybe @zivillian could share his knowledge about the meaning of each attribute of the xml..? |
|
And about
you could try:
The requested amount of Data/Push information should be nearly the same ... If smartset does work longer than your modified ism7mqtt you could redo the same but with the ism7proxy to compare the XMLs |
|
Current status: @CEXC @allcoolusernamesaregone @zivillian |
|
The addon is basically just a docker container with a shell script that starts ism7mqtt. I will push a new version once it is released. |
|
@krusta4711 , another thought, did you had a reboot of the ism7 (Power Off/On) after the failed connections with unmodified ism7mqtt but before successful using your "patched" Version? maybe there were some Leftovers from the requests without the se attributes in the ism7, I hope you get what I mean.. |
|
Yes, I got what you meant. And no, I did not a reboot after the connection issues with the unmodified version. I just rebooted once after the ism module stopped sending. That was two hours after I started the ism7mqtt the first time with a full set of data. It might be that there have been leftovers from either the unmodified version or one of my million tests before. But my gut feeling is that my issues does not have to do anything with my code changes but with the ism module itself (respectively its FW). It would really be good if others can start testing "my" version to have more information what happens with other ism modules and FWs. P.S. |
|
@krusta4711 I've merged your pr - if someone wants to test there is a new docker image and binaries available |
|
I'm not sure.. HA addons don't have any "beta management" or something, where the user can pick a specific version.. it will be offered as an update to all users. And depending on when they install it, they will receiver a different version (whatever is master at the time of installing), disregarding any proper version management.. Maybe I can copy-paste into a second addon ism7mqtt-experimental or something... |
An experimental version would be great |
|
Done.. Make sure you stop the non-experimental addon before running this. Only one of them can connect at the same time. |
For me it works like a charm since 5 hours, even when i sniff all parameters and request those in a timeintervall of 30 seconds (60 is standard). It is also possible to change parameters and start manualy some functions like warm water. I will report a long term test. Big thanks to all of you guys, especially @krusta4711 |
|
Mine was running for 31 hours before another network IOException occured. As already stated this is no problem to me, as my Linux service is restarting the program automatically. Without looking manually in the output I even would not recognize it. It would nevertheless be interesting whether others also have this issue -> have a look at the console output. |
|
Well, I see the IOExceptions (connection reset by peer) also every once in a while. On my side this seems to happen when the ISM7 looses network shortly (due to router reconnection etc). This seems to happen mainly when the ISM7 is connected to Smartset portal. If then network is lost it seems the ISM7 is forced to close all connections for a moment. I also now run “your” version (I.e the new docker build zivilian linked) for about 24 hours with no issues (read and write work as before on my CBG2-14) |
|
Thanks for the testing and the explanation. That was valuable input. :-) Now I know that it is a "normal" behavior by the ism module (my smartset portal is activated). |
|
I have issue number 2. from my post #112 (comment) again. :-( I think it has neither to with my code changes nor with ism7mqtt at all. Nevertheless I opened a new issue here. Maybe someone of you has an idea what to do/test: |
|
I'm another user of the homeassistant addon with a new Wolf LINK Pro module, FW 4.4.0. Aug 23 10:30:34 < � any ideas? Update: I pulled the power plug from the WOLF Link module, reconnected it and it started working again. |
Thats the same behaviour as it is by us. If you Look into the Protokoll (Logs), you will find IOExceptions and so on. Please be sure to use a static ip for your HomeAssistant (WebGui) |
|
@Dschiii The debug output you posted is the so called "keep alive" message which the ism7mqtt is sending every 60 seconds to the ism module. This output is normal and indicates that ism module and even the connection in general is still alive. Why it stops sending messages is unknown yet. But it seems to be more a problem of the (newer?) ism modules themselves, than ism7mqtt. We are still analyzing the problem in the mentioned issue #115 . |
|
@krusta4711 stated in #115
so I'd close this issue as resolved. Please feel free to reopen if you still have problems with the initial connection. |
System information:
Problem:
While ism7config-win-x64 works fine and generate a properties.json (see attached one) ism7mqtt-win-x64 has success in connection to the ism7 Module, but the remote host is always going to close the connection. Output of windows cmd with debug option is:
C:\Users\Stephan\Downloads\ism7mqtt-win-x64>ism7mqtt -m 192.168.1.2 -i 192.168.1.3 -p XXXXXXXX --mqttuser mqtt_wolf_user --mqttpass "XXXXXXXX" -mqttport 9092 -dOutput:
I've tried many different configurations (with or without mqqt password and special port etc.) and with a very reduced parameter.json too. In every case the error occurs. With debug option all the output ist displayed directly, than it took abaout 30 seconds (maybee timeout) and the error messages append to the output in the cmd.
Protokoll of ioBroker:
parameter.json
Hint: The Smartset portal of Wolf Link home ist deactivated but it was active on first tests..
The text was updated successfully, but these errors were encountered: