Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write with ism7mqtt not possible #57

Closed
rooneyaut opened this issue May 1, 2023 · 87 comments
Closed

Write with ism7mqtt not possible #57

rooneyaut opened this issue May 1, 2023 · 87 comments

Comments

@rooneyaut
Copy link

rooneyaut commented May 1, 2023

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!

@zivillian
Copy link
Owner

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.

@rooneyaut
Copy link
Author

rooneyaut commented May 4, 2023

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:

ism7config-win-x64>ism7config.exe -i 192.168.178.159 -p mypassword
2023-05-04 07:43:42.6494|INFO|LuCon.WebPortal.StandaloneService.NetworkConnector|Try IP-resolve for host:192.168.178.159
2023-05-04 07:43:42.7298|INFO|LuCon.WebPortal.StandaloneService.NetworkConnector|Try connect destination server -> 192.168.178.159:9092, Timeout:1000 ms
2023-05-04 07:43:47.8594|ERROR|LuCon.WebPortal.StandaloneService.NetworkConnector|DoConnect
Unhandled exception. LuCon.Common.Declarations.BusinessServiceException: Die Verbindung zur Anlage kann nicht hergestellt werden. Aktualisieren Sie die Anlagenliste und versuchen Sie es nochmal.
   at LuCon.WebPortal.StandaloneService.NetworkConnector.DoConnect(String server, IPAddress localIp, Int32 port, String password, IStreamHandler streamHandler)
   at ism7config.Program.Main(String[] args) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7config/Program.cs:line 120
   at ism7config.Program.<Main>(String[] args)

ism7config.log

@zivillian
Copy link
Owner

It looks like something else is already connected to your ISM. Are you sure you stopped ism7mqtt and the Smartset application?

@rooneyaut
Copy link
Author

rooneyaut commented May 6, 2023

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".
My ISM7 Firmware version is 2.10, does a firmware upgrade maybe help?

Thanks

@zivillian
Copy link
Owner

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)?

@rooneyaut
Copy link
Author

rooneyaut commented May 7, 2023

Is the Smartset application still able to connect?

Yes

Does the old ism7mqtt version still work (except writing values)?

Yes it still reads the values from the ISM7 and publish them to my MQTT broker.

@zivillian
Copy link
Owner

And if you stop the old version, and run ism7config you still get the error from above?

@rooneyaut
Copy link
Author

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.
Maybe my password on the ISM7 is the problem, because it contains a callsign '!'.
You can find my test (cmd output) attached. I've waited for the ISM7 Status at the webinterface to be changed to "Portal connected" from "Portal+Direct connected" before I ran ism7config.
cmd.log

@zivillian
Copy link
Owner

That's interesting...

Can you try the original Wolf Mobile App (Android or iOS)?

I'm pretty sure that your password isn't the problem - the log shows that ism7config tries to connect to the correct IP, but it doesn't get a response from your ISM within one second.

@rooneyaut
Copy link
Author

Can you try the original Wolf Mobile App (Android or iOS)?

The App works, because I use it now to set my gas boiler to heat mode if needed.
You can find screenshots attached.
I just recognized that the new ism7mqtt does also having problems to connect to my ISM7, it was connected for just a second and then I got an error.
ism7mqtt_new.log
Screenshot1
Screenshot2
Screenshot3

@zivillian
Copy link
Owner

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.

@rooneyaut
Copy link
Author

The new ism7mqtt is having problems, because the paramter.json is different - that's why you need to run ism7config.

Oh, that makes sense.

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.

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.

@zivillian
Copy link
Owner

I've increased the timeout to 10 seconds - can you try the binaries from the cgs-2l branch?

@rooneyaut
Copy link
Author

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".
Then I tried it 5 times with the new version without an delay between each ism7config run and then my ISM7 crashed.
It restarted and connected to the portal again, so it is useable again.
I think my ISM7 is to slow for the new ism7config or the timeout delay must be higher than 10 seconds. The wifi signal at the gas boiler behind the BM-2 is not the best, but I still get about 50ms response time to it.
ism7crash

@zivillian
Copy link
Owner

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.

@rooneyaut
Copy link
Author

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.
This time I tried the linux version.
Screenshot_20230507-203910

@zivillian
Copy link
Owner

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

@zivillian
Copy link
Owner

zivillian commented May 7, 2023

it's not the GatewayContext.ReadTimeoutMs - this is by default 60s.

The error message ERROR|LuCon.WebPortal.StandaloneService.NetworkConnector|DoConnect also indicates, that it's not the TcpClientConnectTimeoutMs of the NetworkConnector.

@zivillian
Copy link
Owner

I've pushed a new version, which hopefully logs the original exception. Can you try the new binaries and post the output?

@rooneyaut
Copy link
Author

I've pushed a new version, which hopefully logs the original exception. Can you try the new binaries and post the output?

Output:
Screenshot_20230507-214614

@zivillian
Copy link
Owner

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?

@rooneyaut
Copy link
Author

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 :)
But for some reason, the new ism7mqtt version is crashing if I try to start it with the paramter "--hass-id=Wolf" with the following error:

System.FormatException: Input string was not in a correct format.
   at System.Number.ThrowOverflowOrFormatException(ParsingStatus , TypeCode )
   at ism7mqtt.HomeAssistant.HaDiscovery.GetDiscoveryProperties(ParameterDescriptor descriptor)+MoveNext()
   at ism7mqtt.HomeAssistant.HaDiscovery.GetDiscoveryInfo(String discoveryId, RunningDevice device) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/HomeAssistant/HaDiscovery.cs:line 79
   at ism7mqtt.HomeAssistant.HaDiscovery.<>c__DisplayClass2_0.<GetDiscoveryInfo>b__0(RunningDevice x) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/HomeAssistant/HaDiscovery.cs:line 21
   at System.Linq.Enumerable.SelectManySingleSelectorIterator`2.MoveNext()
   at ism7mqtt.Program.PublishDiscoveryInfo(Ism7Config config, IMqttClient mqttClient, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/Program.cs:line 174
   at ism7mqtt.Ism7Client.LoadInitialValuesAsync(CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/Ism7Client.cs:line 307
   at ism7mqtt.ResponseDispatcher.DispatchAsync(IResponse response, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/ResponseDispatcher.cs:line 32
   at ism7mqtt.Ism7Client.ReadPipeAsync(PipeReader source, `CancellationToken` cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/Ism7Client.cs:line 213

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:

received mqtt with topic 'Wolf/192.168.178.159/BM-2_0x35/set/1x_Warmwasser/text' 'Ein'
> <?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>
< <?xml version="1.0" encoding="utf-8"?><tbres bn="10117" gw="5227" st="ER" emsg=""></tbres>
< <?xml version="1.0" encoding="utf-8"?><tbres bn="10117" gw="5227" st="ER" emsg=""></tbres>

@zivillian
Copy link
Owner

Can you share your new parameter.json?

@rooneyaut
Copy link
Author

Sure:
parameter.zip

@zivillian
Copy link
Owner

zivillian commented May 9, 2023

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.

@rooneyaut
Copy link
Author

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.
The ism7proxy test failed, because if ism7mqtt is connected to my ISM7i, I can't set any values in the app.
After a restart of the android app, the Wolf gas boiler was offline inside the app.
You can find the ism7proxy log attached.
ism7mqtt_hass-id_linux.log

Wolf_App
ism7proxy.log

Thanks

@rooneyaut
Copy link
Author

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.

Ok, now I got it. I didn't knew that the mobile app can also do a direct connection.
Here is the ism7proxy logfile:
ism7proxy_android_local.log

@zivillian
Copy link
Owner

The android log shows, that the ba (BusAddress) is incorrect. Now I need to find out, when it's different for reading and writing (as implemented) and when it's the same (like in your setup).

@zivillian
Copy link
Owner

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...

@zivillian
Copy link
Owner

zivillian commented May 10, 2023

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.

@zivillian
Copy link
Owner

@IgitBuh welcome - can you share the debug log, while setting the value via mqtt?

@zivillian
Copy link
Owner

@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

@IgitBuh
Copy link

IgitBuh commented Jul 16, 2023

It seems like I got confused while testing for the past three hours and running up and down the stairs to check the results...
I was indeed testing with /set/ as described in the readme, but posted the paths where I expected the result to take place. Sorry.

Most of my testing went into Wolf/192.168.178.212/CHA_0x8/(set/)Warmwassersolltemperatur where I expected the result to take place. But this never updated anything. I apparently mistakenly assumed this was the right topic to view and change the value.

Wolf/192.168.178.212/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt/350009 did update Wolf/192.168.178.212/WWSystem_BM-2_0x35/Warmwassersolltemperatur_eingestellt/350009 but not Wolf/192.168.178.212/CHA_0x8/Warmwassersolltemperatur. What I missed is that it also did update it on the BM2. So actually everything does work. Actually, even Wolf/192.168.178.212/CHA_0x8/(set/)Warmwassersolltemperatur gets updated after about 2-3 minutes, I was just never patient enough to wait that long.

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 350009 and 350014.

@zivillian
Copy link
Owner

@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 parameter.json. Please be aware, that Wolf/192.168.178.212/WWSystem_BM-2_0x35/Warmwassersolltemperatur_eingestellt/350009 will change to Wolf/192.168.178.212/WWSystem_BM-2_0x35/Warmwassersolltemperatur_eingestellt if you remove 350014.

@LuckyLukeSkywalker
Copy link

LuckyLukeSkywalker commented Dec 2, 2023

Hello, I'm using the latest version 0.0.15 with my Wolf CGB-2 with BM-2 FW 3.2.
Reading over MQTT of the parameters of my heating works fine. But I'm not able to write any parameter.
Do you have an idea, what's wrong?

Here an example:

received mqtt with topic 'Wolf/192.168.0.124/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt/' '45'
> <?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="8" gw="1" ae="true" ty="write"><iwr se="" ba="0x30" in="19" dl="0xC2" dh="0x01" /></tbreq>
< <?xml version="1.0" encoding="utf-8"?><tbres ts="2023-12-02T13:30:07" bn="19" gw="1" st="ER" emsg=""></tbres>
< <?xml version="1.0" encoding="utf-8"?><tbres ts="2023-12-02T13:30:07" bn="19" gw="1" st="ER" emsg=""></tbres>

@alexkno79
Copy link

alexkno79 commented Dec 4, 2023

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)

@Eba-M
Copy link

Eba-M commented Dec 5, 2023

I would like to set a new value for "Sollwertkorrektur" for my Wolf CHA 10, my parameter.json start with
{
"Devices": [
{
"ReadBusAddress": "0x00",
"DeviceTemplateId": 190000,
"Parameter": [
190001,
190003,
if i set a new value via smartset-App for the "Sollwertkorrektur" i receive
{"Sollwertkorrektur":{"340026":-2,"340031":-2}}
What topic do i have to use to set the new value via MQTT?

Wolf//_/set//...

Where can i find the values for
and /

if found 340026/340031 here:
{
"ReadBusAddress": "0x35",
"DeviceTemplateId": 340000,
"Parameter": [
320014,
340004,
320016,
340006,

@alexkno79
Copy link

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

@Eba-M
Copy link

Eba-M commented Dec 5, 2023 via email

@Eba-M
Copy link

Eba-M commented Dec 5, 2023

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}}

it works thanks to all

@LuckyLukeSkywalker
Copy link

LuckyLukeSkywalker commented Dec 10, 2023

No chance. I´ve tried out everything. Nothing works. Reading data works fine, writing not.
The BM-2 is running with firmware 3.2. Could this be the reason?

received mqtt with topic 'Wolf/192.168.0.124/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt' '45'
> <?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="8" gw="1" ae="true" ty="write"><iwr se="" ba="0x30" in="19" dl="0xC2" dh="0x01" /></tbreq>
< <?xml version="1.0" encoding="utf-8"?><tbres ts="2023-12-10T18:12:07" bn="19" gw="1" st="ER" emsg=""></tbres>
< <?xml version="1.0" encoding="utf-8"?><tbres ts="2023-12-10T18:12:07" bn="19" gw="1" st="ER" emsg=""></tbres>
received mqtt with topic 'Wolf/192.168.0.124/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt/350009' '45'
> <?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="9" gw="1" ae="true" ty="write"><iwr se="" ba="0x30" in="19" dl="0xC2" dh="0x01" /></tbreq>
< <?xml version="1.0" encoding="utf-8"?><tbres ts="2023-12-10T18:13:53" bn="19" gw="1" st="ER" emsg=""></tbres>
< <?xml version="1.0" encoding="utf-8"?><tbres ts="2023-12-10T18:13:53" bn="19" gw="1" st="ER" emsg=""></tbres>

This is the log message after the temperature has been set directly on the heater to 54:

publishing mqtt with topic 'Wolf/192.168.0.124/WWSystem_BM-2_0x35/Warmwassersolltemperatur_eingestellt' '54'
< <?xml version="1.0" encoding="utf-8"?><tbres bn="5" gw="1" st="OK" ts="2023-12-10T18:34:54" emsg=""><irs se="0" ba="0x8" in="13" dl="0x1C" dh="0x1" st="OK"/><irs se="0" ba="0x8" in="14" dl="0xF4" dh="0x1" st="OK"/><irs se="0" ba="0x8" in="22" dl="0x1B" dh="0x1" st="OK"/></tbres>

@alexkno79
Copy link

alexkno79 commented Dec 10, 2023

Strange...working fine here. I am also using BM2 firmware 3.2 on a CGB-2-14

received mqtt with topic 'Wolf/192.168.178.64/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt/350009' '51'
> <?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="6" gw="1" ae="true" ty="write"><iwr se="" ba="0x30" in="19" dl="0xFE" dh="0x01" /></tbreq>
< <?xml version="1.0" encoding="utf-8"?><tbres bn="6" gw="" st="OK" ts="2023-12-10T18:43:50" emsg=""><iac se="0" ba="0x30" in="19" dl="0xFE" dh="0x1" st="OK"/></tbres>
publishing mqtt with topic 'Wolf/192.168.178.64/WWSystem_BM-2_0x35/Warmwassersolltemperatur_eingestellt/350009' '51'
publishing mqtt with topic 'Wolf/192.168.178.64/WWSystem_BM-2_0x35/Warmwassersolltemperatur_eingestellt/350014' '51'

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.
Just one thing: did you also try with something like 50 as value? Maybe you set in parameters lowest temp to above 45?

@LuckyLukeSkywalker
Copy link

Yes, I also tried other values.

@alexkno79
Copy link

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

@manison
Copy link

manison commented Jan 2, 2024

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.

parameter.json

@manison
Copy link

manison commented Jan 2, 2024

You can use #92 to test setting parameters depending on number of subscriptions. Just set the variable ISM7_SUBSCR_LIMIT to 147 or experiment with the value and see whether the write request comes through or fails.

@LuckyLukeSkywalker
Copy link

LuckyLukeSkywalker commented Jan 3, 2024

@manison:
Manison you are right. I have reduced the number of subscriptions in my parameter.json to148. Now I am able to change "Warmwassersolltemperatur_eingestellt".
My ISM firmware version is 2.10.

Juhu :-)

@LuckyLukeSkywalker
Copy link

@manison:
How did you have reduced the number of subscriptions in the parameter.json? Which one did you have deleted?
Yesterday I have just deleted subscriptions in the block "ReadBusAddress": "0x8". Everything worked fine.
Today I have deleted for me unimportant subscription in the whole file. The most subscription in the block 0x8 are still in my parameter.json. The number of all is under 148.
With such a file I´m not able to set values. The same fault as before. Just by reducing the number of subscriptions in block 0x8 works.

@manison
Copy link

manison commented Jan 5, 2024

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.

@rooneyaut
Copy link
Author

For me the limit is way lower, but if I remove a lot of points in my parameter.json I can write values too.
I tried at first remove some points for 0x8, then I removed it completely, but I still couldn't write values.
While testing my ISM7 Module crashed two times and restarted with relogon on the Wolf Portal.

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

@manison
Copy link

manison commented Jan 5, 2024

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?

@rooneyaut
Copy link
Author

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.

@LuckyLukeSkywalker
Copy link

@manison my device is CBG-2. The connection to the portal doesn´t matter. I have try out both ways, with and without.
I am using Home Assistant. I´ve found many subscriptions under 0x8 in my parameter.json, that were not to find in Home Assistant. So I´ve deleted them first.
In the next step I will reconfigure my Home Assistant. I want to use just the MQTT connection.

@manison
Copy link

manison commented Jan 5, 2024

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.

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.

@manison my device is CBG-2. The connection to the portal doesn´t matter. I have try out both ways, with and without.
I am using Home Assistant. I´ve found many subscriptions under 0x8 in my parameter.json, that were not to find in Home Assistant. So I´ve deleted them first.
In the next step I will reconfigure my Home Assistant. I want to use just the MQTT connection.

Very well, please share the results with us.

@alexkno79
Copy link

alexkno79 commented Jan 23, 2024

Just as headsup:

I have following config:

Device: CGB2-14 (FW of control unit: 2.2)
BM2: fw 3.2
ISM7 FW: 3.00.412 HW: 3.0 (Wolflink Home)
Ism7mqtt v0.0.15 running on raspi pi arm64 in docker container
ISM7 is connected local (to ism7mqtt) and to smartest portal.
Connection is via LAN (WiFi deactivated)
I receive ca 192 data points via ism7mqtt and have no issues when writing values using mqtt set option (I mainly use 1xWarmwasser, Warmwassertemperatur and party and holiday mode).

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...

@BRT4321
Copy link

BRT4321 commented Jun 25, 2024

Was anybody already successful in writing parameters belonging to the "Fachmannebene"?
I have a CHA and would (for instance) change the value of "Freigabe EHZ Warmwasserbetrieb" to 0 or 1...

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants