Write with ism7mqtt not possible #57
Comments
|
it tries to set the value: <?xml version="1.0" encoding="utf-16"?>
<tbreq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" bn="4" gw="1" ae="true" ty="write">
<iwr se="" ba="0x30" in="10117" dl="0x01" dh="0x00" />
</tbreq>but the CGS-2L returns an error: <?xml version="1.0" encoding="utf-8"?>
<tbres ts="2023-05-01T13:04:36" bn="10117" gw="5227" st="ER" emsg=""></tbres>Can you try the binaries from the TGB-2 branch? This version no longer depends on the Smartset database and reads the configuration directly from the ISM by using the updated binaries from the android app. If we're lucky this already fixes your problem. Please be aware, that this version uses a different parameter.json - so you need to re-create it with the new ism7config tool. The details can also be found in #43. |
It can't connect to the Wolf CGS-2L: |
|
It looks like something else is already connected to your ISM. Are you sure you stopped ism7mqtt and the Smartset application? |
Yes. On the ISM7 web interface the Status shows only "Portal connected" otherwise it would show "Portal+Direct connected". Thanks |
|
I don't think a firmware update will help. You already got it running with the old version, so something has to be different so that ism7config is unable to connect to your ism. Is the Smartset application still able to connect? Does the old ism7mqtt version still work (except writing values)? |
Yes
Yes it still reads the values from the ISM7 and publish them to my MQTT broker. |
|
And if you stop the old version, and run ism7config you still get the error from above? |
Yes, the old version can still connect to my ISM7, but the new ism7config can't. The error is the same. I also tried to restart my ISM7 module by turning my gas boiler off and on again, but still the same. |
|
The App works, because I use it now to set my gas boiler to heat mode if needed. |
|
The new ism7mqtt is having problems, because the paramter.json is different - that's why you need to run ism7config. How long does it take between starting ism7mqtt and the first XML output? Maybe your ISM is too slow and we need to increase the timeout. |
Oh, that makes sense.
Wow... you're right. I tried it 3 times now and the first XML output never came under 7 seconds after starting the old ism7mqtt. The longest time was about 8,5 seconds. |
|
I've increased the timeout to 10 seconds - can you try the binaries from the cgs-2l branch? |
|
Unfortunately it still gets the same error. I ran the new (10 seconds timeout) version over and over and one time I got for less than a second the Status "Portal+Direct connected". |
|
If I'm correct, the android app runs with a timeout of 15 seconds, but I've increased the timeout to 60 seconds for now. Can you try again? Are you sure it's the exact same error? I just found another timeout paramter on the GatewayContext. |
I got an error again. The line mentioned was 120 (same as now) on the 10 seconds version. |
|
Now it get's funny - the timestamps in your screenshots show a timeout after ~6 seconds, but the log shows that we tried to connect with a timeout of 60.000ms |
|
it's not the The error message |
|
I've pushed a new version, which hopefully logs the original exception. Can you try the new binaries and post the output? |
Output: |
|
Wow, that helped - I've pushed another version that increases the hardcoded timeout for the SSL handshake from 5 to 60 seconds. Can you try again? |
It worked now, I tried to connect with the generated parameter.json and it worked :) So I tried to manually set the mqtt value to start the water heater but it seems that this version can't also set values to my ISM7: |
|
Can you share your new |
|
Sure: |
|
Sadly I'm not able to reproduce the crash with the hass-id - can you share a debug log? I know, that this is not related to the writing issue - for this it would be very helpful if you can create a logfile using ism7proxy while changing the parameter from the app. |
You can find the debug log for the hass-id crash attached. This only happens for the linux-arm version under windows it works. Thanks |
Ok, now I got it. I didn't knew that the mobile app can also do a direct connection. |
|
The android log shows, that the |
|
OK, I gave up on finding out how to calculate the correct address and simply added it to the parameter.json with ism7config. Can you try the latest binaries, create a new parameter.json and try to write a value? Next step is to look into your hass-id problem... |
|
If I'm correct the hass-id problem is caused by the system language. The above version already should fix the crash by ignoring the invalid min or max values, but this version should also log the root cause when launched with debug enabled. |
|
@IgitBuh welcome - can you share the debug log, while setting the value via mqtt? |
|
@IgitBuh you seem to use the wrong mqtt topic - the correct one should be one of the following: Wolf/192.168.178.212/CHA_0x8/set/Warmwassersolltemperatur Wolf/192.168.178.212/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt/350009 Wolf/192.168.178.212/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt/350014 |
|
It seems like I got confused while testing for the past three hours and running up and down the stairs to check the results... Most of my testing went into
I'm sorry for the false alert. It's just very confusing to have multiple MQTT topics for the same setting, so testing went into the wrong direction most of the time and the rest got mixed up. Even now I do not know what the difference might be between |
|
@IgitBuh Due to the separate topics, you can check if the value was set by just observing the read topic - so you don't have to run the stairs up and down. I don't know (yet) why there are multiple properties with the same name, but to clear it up for your setup, you can just remove the other ones from the |
|
Hello, I'm using the latest version 0.0.15 with my Wolf CGB-2 with BM-2 FW 3.2. Here an example: |
|
the slash at the end of your topic seems strange. Should likely be Wolf/192.168.0.124/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt or Wolf/192.168.0.124/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt/xxxxx where xxxx is the related parameter (in my case it's 350009) It depends on how the topic you receive the data with is formatted. In my case I have to use Wolf/192.168.178.64/WWSystem_BM-2_0x35/Warmwassersolltemperatur_eingestellt/350009 (But I receive for any reason also Wolf/192.168.178.64/WWSystem_BM-2_0x35/Warmwassersolltemperatur_eingestellt/350014 but to this I cannot send) |
|
I would like to set a new value for "Sollwertkorrektur" for my Wolf CHA 10, my parameter.json start with Wolf//_/set//... Where can i find the values for if found 340026/340031 here: |
|
for me it works with Wolf/192.168.178.64/DHK_BM-2_0x35/set/Sollwertkorrektur/340031 Where of course the IP of my ISM7 is included. |
|
mosquitto_pub -h 192.168.178.54 -t Wolf/192.168.178.90/DHK_BM-2_0x35/set/Sollwertkorrektur/340031 -m -2
{"BUSCONFIG_Sollwertkorrektur":-2}
{"Sollwertkorrektur":{"340026":-2,"340031":-2}}
Great it works
… Am 05.12.2023 um 19:31 schrieb alexkno79 ***@***.***>:
for me it works with
Wolf/192.168.178.64/DHK_BM-2_0x35/set/Sollwertkorrektur/340031
Where of course the IP of my ISM7 is included.
But you may check which topic you receive the values with
—
Reply to this email directly, view it on GitHub <#57 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE4C5SALAIYNG744KVEELD3YH5SBNAVCNFSM6AAAAAAXRVUCD2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBRGM3TSNJWHE>.
You are receiving this because you commented.
|
|
mosquitto_pub -h 192.168.178.54 -t Wolf/192.168.178.90/DHK_BM-2_0x35/set/Sollwertkorrektur/340031 -m -2 {"BUSCONFIG_Sollwertkorrektur":-2} it works thanks to all |
|
No chance. I´ve tried out everything. Nothing works. Reading data works fine, writing not. This is the log message after the temperature has been set directly on the heater to 54: |
|
Strange...working fine here. I am also using BM2 firmware 3.2 on a CGB-2-14 In your case it should. Be only Wolf/192.168.0.124/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt as you receive it that way. As I can see it is like this in your first try. |
|
Yes, I also tried other values. |
|
what seems strange in your case is that the request to change the values has bundleId 8 (bn="8") and 9 while the error message you receive refer to bundleID 19 (bn="19"). I have no clue why, but it seems strange. Two thoughts: a) maybe a simple restart of your wolf system or b) check the parameters via smartset webpage whether there they all look good. Maybe one parameter is out of range or something....just an idea |
|
I think I found something. I have the same problem writing the parameter 10117 (1x warm water) as the OP in my system with CGB-2. I have ISM7 with FW version 2.10 and BM-2 with 3.00 (I don't think BM-2 firmware matters in this case). What immediately struck me when I looked in the communication log were the mismatched responses and there were two of them received at once: For telegram bundle request number 6 <tbreq bn="6" gw="1" ae="true" ty="write">
<iwr se="" ba="0x30" in="10117" dl="0x01" dh="0x00" />
</tbreq>I immediately get two!! identical telegram bundle error responses with mismatched bundle number: <tbres ts="2023-12-26T13:52:01" bn="10117" gw="" st="ER" emsg=""></tbres>One would expect the response having the same bundle number as the request as it is the case with other (successful) request/response exchanges. But the bundle number in this case mysteriously refers to the info number of datapoint being written. I started testing some modifications to ism7mqtt that fixes some obvious differences between ism7mqtt and Smartset applications, like different XML encoding declaration on requests (which is definitely wrong, because encoding on the wire is UTF-8 contrary to declared UTF-16 – not that ISM7 cares anyway), extra namespace declarations etc. until I read this issue in full to find out that all of this has already been tried (#58). I then started suspecting overlapping requests that ism7mqtt sends at once while Smartset sends one request and waits to receive a response before issuing another request. And this seemed like classical source of a race condition. It turned out that this had not been the cause either. I then started to suspect the subscriptions to datapoint changes. Subscribing to the datapoint in question (10117 - 1x warm water) should not itself be a problem since Smartset subscribes to that datapoint too. However by comparing the subscriptions we can see that Smartset subscribes to a fewer points. There is 36 points subscribed to by Smartset in 4 push requests and 180 points subscribed to by ism7mqtt in 2 push requests. I temporarily disabled the subscriptions altogether and voila – the write request now passed. I then experimented with the number of subscriptions and it seems that when there is more than 147 datapoint subscriptions then the ISM7 starts to fail the write requests. The 148th datapoint in my case is 10075 (which I believe is BUSCONFIG_Warmwasserkonfiguration). I assumed this particular datapoint may be the reason for the failures. But when I removed this datapoint from the subscription then datapoint 328 (Type) became the 148th and the write failures still occurred. So I have now reason to believe the factor that leads to write errors is the total number of datapoints the client subscribes to. Sure, there may be also some other factors that affects this, e.g. some dependencies between the subscriptions. Also I don't know yet if the subscription limit applies to the total count of the subscriptions or if there is a limit per device (bus address) – there is 91 (or 102 nonunique, see below) datapoints subscribed on bus address 0x35 and 89 (101) on bus address 0x8 in case of ism7mqtt vs 17 (22) and 19 (21) in case of Smartset. When capping number of subscriptions to 148 the numbers for ism7mqtt are 91 (102) and 45 (46). These are still not "nice round" numbers (powers of two or multiples of ten) that would make me believe the limit is per device. Interesting to note that ism7mqtt subscribes to some datapoints more than once. Smartset also subscribes to some points more than once but the repeated subscriptions are spread among multiple push requests while ism7mqtt subscribes multiple times in single push request. Maybe there should be distinct function while subscribing to data points. I will experiment further and post here. In the meantime can anybody with this problem (@rooneyaut, @LuckyLukeSkywalker) test whether capping number of subscriptions helps in your case? And those with working writes can you post your ISM7 firmware version? Also it would be interesting to find out how Smartset determines the datapoints for subscriptions. |
|
You can use #92 to test setting parameters depending on number of subscriptions. Just set the variable |
|
@manison: Juhu :-) |
|
@manison: |
|
In the experiment I didn't modify the parameter.json file, I limited the subscription count programmatically, see #92. Since ism7mqtt first subscribes 102 points to 0x35 there is room for 46 points for 0x8 before we hit the limit of 148 subscriptions. So maybe the limit is not 148 in total but 45 for 0x8. Try to keep number of parameters for 0x8 in your parameter.json below 45 and see what happens. |
|
For me the limit is way lower, but if I remove a lot of points in my parameter.json I can write values too. Now with 74 points subscribed (I will try to go up higher) I can set values like "Wolf/192.168.178.159/BM-2_0x35/1x_Warmwasser" and it works. @manison thank you for your effort, so we know now that some ISM7 Module can't handle the requests coming from ism7mqtt. My ISM7 firmware version is 2.10 |
|
Could it be that the connection to the Wolf Portal itself decreases the limit of subscriptions? I'm not connecting to the portal. Can you disable the connection to the portal and check out again? What about you, @LuckyLukeSkywalker, are you connected to the portal or not? Also, @LuckyLukeSkywalker, what's your device on 0x8? Mine is CGB-2, @rooneyaut's is CGS-2L, am I right? |
Yeah you are right, but in ism7mqtt all the names are beginning with CGB-2. |
|
@manison my device is CBG-2. The connection to the portal doesn´t matter. I have try out both ways, with and without. |
I looked at Wolf website and it looks like CGS-2L is freestanding CGB with integrated hot water storage tank. It might have the same/similar control unit and therefore it makes sense it identifies as CGB. What identification you see in Smartset? Your parameter.json file is nearly identical to mine, yours only having a few more parameters related to storage tank. I am able to subscribe to all 89 datapoints for 0x8 from my parameter.json and then remaining 58 parameters for 0x35. But once the number of subscriptions reaches 148 the write commands start to fail.
Very well, please share the results with us. |
|
Just as headsup: I have following config: Device: CGB2-14 (FW of control unit: 2.2) Just as another thought: is it possible those having issues are connecting also to Home Assistant? Just to see why some user face this subscription limit... |
|
Was anybody already successful in writing parameters belonging to the "Fachmannebene"? EDIT: I works also! As currently my DHK resp. CHA is in standby due to the weather conditions, published topics are not taken into account immediately. So closeby control for testing always seem to fails. |
I have tried the ism7mqtt to solve my portal disconnects with the Wolf Smartset Cloud.
The software is working, but I only can read the values of my Wolf CGS-2L.
If I am trying to set a value, I can see the correct MQTT topic with MQTT Explorer.
I can also see the debug output
received mqtt with topic 'Wolf/192.168.178.159/BM-2_0x35/set/1x_Warmwasser/text' 'Ein'but ism7mqtt sets nothing to my Wolf CGS-2L gas boiler.You can find the debug output and my smartsetpc.sdf file attached.
debug.log
smartsetpc.zip
Thank you for your help!
The text was updated successfully, but these errors were encountered: