Write with ism7mqtt not possible about ism7mqtt HOT 86 OPEN

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.

from ism7mqtt.

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

from ism7mqtt.

Changing values works for me:

from ism7mqtt.

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

from ism7mqtt.

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

from ism7mqtt.

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.

from ism7mqtt.

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?

from ism7mqtt.

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.

from ism7mqtt.

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

from ism7mqtt.

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

from ism7mqtt.

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

from ism7mqtt.

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

from ism7mqtt.

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.

from ism7mqtt.

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

from ism7mqtt.

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

from ism7mqtt.

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.

from ism7mqtt.

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

from ism7mqtt.

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.

from ism7mqtt.

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.

from ism7mqtt.

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

from ism7mqtt.

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

from ism7mqtt.

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.

from ism7mqtt.

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.

from ism7mqtt.

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

from ism7mqtt.

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

from ism7mqtt.

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

Output:

from ism7mqtt.

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?

from ism7mqtt.

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>

from ism7mqtt.

Can you share your new parameter.json?

from ism7mqtt.

Sure:
parameter.zip

from ism7mqtt.

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.

from ism7mqtt.

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

from ism7mqtt.

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

from ism7mqtt.

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

from ism7mqtt.

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.

from ism7mqtt.

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?

It didn't work :(
you can find the debug.log and parameter.json (created with this version under windows) attached:

ism7mqtt_write.log
parameter.zip

from ism7mqtt.

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.

You can find the debug.log and parameter.json attached (created with this linux-arm version).
This version didn't crashed with the hass-id paramter:
parameter.zip
ism7mqtt_hass-id_debug.log

from ism7mqtt.

I found the error in the HA Discovery - I only tested this on Windows and there it silently parses 0.1 as 1 instead of crashing. I switched to invariant number parsing so this should fix Cannot parse MinValueCondition '0.1' for PTID.

Regarding the write error - I was wrong that the BusAddress is the issue - maybe I stared to long at strange XML dumps. Can you try to modify another parameter on another device like Warmwassersolltemperatur or Typ_Pumpenregelung?

The only difference I can see is the empty se attribute, but this wasn't needed in any other setup:

ism7mqtt:
<iwr se="" ba="0x30" in="10117" dl="0x01" dh="0x00" />

android:
<iwr se="A;142" ba="0x30" in="10117" dl="0x01" dh="0x00" />

from ism7mqtt.

I found the error in the HA Discovery - I only tested this on Windows and there it silently parses 0.1 as 1 instead of crashing. I switched to invariant number parsing so this should fix Cannot parse MinValueCondition '0.1' for PTID.

Nice :)

Regarding the write error - I was wrong that the BusAddress is the issue - maybe I stared to long at strange XML dumps. Can you try to modify another parameter on another device like Warmwassersolltemperatur or Typ_Pumpenregelung?

The only difference I can see is the empty se attribute, but this wasn't needed in any other setup:

ism7mqtt:
<iwr se="" ba="0x30" in="10117" dl="0x01" dh="0x00" />

android:
<iwr se="A;142" ba="0x30" in="10117" dl="0x01" dh="0x00" />

I've tried to change 'Warmwassersolltemperatur_eingestellt' and 'Programmwahl' of DHK_BM-2 using you binaries from build #159 with linux-arm, but nothing was changed:
ism7mqtt_testing_write.log

from ism7mqtt.

The log shows, that it's the same problem, but I still don't understand why. Maybe we should try a firmware update of your BM - if I'm correct you are still on 2.4, but this is a wild guess. Another option would be to try to just send either something random or try to reverse what to actually use as se.

I'll try to build a new version which uses random for the se attribute tomorrow...

from ism7mqtt.

The log shows, that it's the same problem, but I still don't understand why. Maybe we should try a firmware update of your BM - if I'm correct you are still on 2.4, but this is a wild guess.

I'm on FW Version 3.0, I see that FW 3.2 is available but I can't find any changelogs.

from ism7mqtt.

If you're already on 3.0 I'd say this is a dead end.

If pushed a new version which hardcodes the se attribute to the observed value A;142. It would be great if you could test to change 1x_Warmwasser and one of the other parameters - I want to find out if the actual value is relevant or if it just needs to have a value.

from ism7mqtt.

If you're already on 3.0 I'd say this is a dead end.

If pushed a new version which hardcodes the se attribute to the observed value A;142. It would be great if you could test to change 1x_Warmwasser and one of the other parameters - I want to find out if the actual value is relevant or if it just needs to have a value.

Unfortunately this version does not work either

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="A;142" ba="0x30" in="10117" dl="0x01" dh="0x00" /></tbreq>
< ?<?xml version="1.0" encoding="utf-8"?><tbres ts="2023-05-12T22:52:07" bn="10117" gw="5227" st="ER" emsg=""></tbres>
< ?<?xml version="1.0" encoding="utf-8"?><tbres ts="2023-05-12T22:52:07" bn="10117" gw="5227" st="ER" emsg=""></tbres>

received mqtt with topic 'Wolf/192.168.178.159/DHK_BM-2_0x35/set/Programmwahl/text' 'Standby'
> <?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="5" gw="1" ae="true" ty="write"><iwr se="A;142" ba="0x30" in="10100" dl="0x00" dh="0x00" /></tbreq>
< ?<?xml version="1.0" encoding="utf-8"?><tbres ts="2023-05-12T22:53:42" bn="10100" gw="5227" st="ER" emsg=""></tbres>
< ?<?xml version="1.0" encoding="utf-8"?><tbres ts="2023-05-12T22:53:42" bn="10100" gw="5227" st="ER" emsg=""></tbres>

ism7mqtt_build162.log

from ism7mqtt.

Maybe the bn is the problem:

ism7mqtt:
<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="A;142" ba="0x30" in="10117" dl="0x01" dh="0x00" /></tbreq>

android:
<tbreq bn="1099" gw="1" ae="true" ty="write"><iwr se="A;142" ba="0x30" in="10117" dl="0x01" dh="0x00" /></tbreq>

On the android app bn="1099", on ism7mqtt bn="4"

from ism7mqtt.

Now we both run out of ideas - I think it's more likely that the additional namespace is the problem, but anyways... I've pushed a new version, which always uses 1099 as bn. So let's see if this solves the problem.

from ism7mqtt.

I've looked at the Wolf binaries and as far as I can tell, they also just autoincrement the bundleId (bn):

private int GetNextBundleId(int mainBundleId, BundleQueueWorker.SubscriptionBundle bundle)
{
  if (!bundle.Chunks.Any<TelegrBundleRequest>())
  {
    return mainBundleId;
  }
  return int.Parse(bundle.Chunks.Last<TelegrBundleRequest>().BundleId) + 1;
}

So the android app most probably uses 1099 because it sent 1098 requests before.

from ism7mqtt.

I've pushed another version which also removes the xml namespace - if this also doesn't work we need to diff the traces again.

from ism7mqtt.

I've pushed another version which also removes the xml namespace - if this also doesn't work we need to diff the traces again.

The error still exists, the only diff I can see now is the encoding

ism7mqtt:
<?xml version="1.0" encoding="utf-16"?><tbreq bn="1099" gw="1" ae="true" ty="write"><iwr se="A;142" ba="0x30" in="10117" dl="0x01" dh="0x00" /></tbreq>

android:
<?xml version="1.0" encoding="utf-8"?><tbreq bn="1099" gw="1" ae="true" ty="write"><iwr se="A;142" ba="0x30" in="10117" dl="0x01" dh="0x00" /></tbreq>

ism7mqtt_build164.log

from ism7mqtt.

Then let's try utf-8 encoding...

https://github.com/zivillian/ism7mqtt/actions/runs/4968377750

from ism7mqtt.

Then let's try utf-8 encoding...

https://github.com/zivillian/ism7mqtt/actions/runs/4968377750

It doesn't work...
Something must be wrong with my setup, I will try to update my BM-2 to FW version 3.2 tomorrow.
ism7mqtt_build165.log

from ism7mqtt.

After looking at the android trace again, I saw that the app is subscribing to this exact parameter before via push so this cannot be the problem:

<?xml version="1.0" encoding="utf-8"?><tbreq bn="1000" gw="1" ae="true" ty="push">
  [...]
  <ird se="A;142" ba="0x35" in="10117" is="60" />
</tbreq>

But I also see that the app subscribed to ErrorStateRead before the first push:

<?xml version="1.0" encoding="utf-8"?><tbreq bn="3" gw="1" ae="false" ty="push"><erd se="3" li="0x8,0x35" /></tbreq>

I've added the subscribe for erd during the initialization, but I guess you must wait until you get the response for this request before you can publish values (same bn).

from ism7mqtt.

I've added the subscribe for erd during the initialization, but I guess you must wait until you get the response for this request before you can publish values (same bn).

Same error again. The FW version of the BM-2 is still 3.0, I need to buy an microSD card for the update.
ism7mqtt_build166.log

from ism7mqtt.

I've updated my BM-2 firmware to version 3.20 today and tried the latest your latest test build again, but I can't write any value to my ISM7.
I also tried the paramter --interval=180, because sometimes if ism7mqtt is running my ISM7 was crashing and rebooted, but it doesn't change anything (I thought that my ISM7 is to slow for the 60 seconds interval).
ism7mqtt_build166_bm2_fw320.log

from ism7mqtt.

Regarding the interval: the android app also uses an interval of 60s for the push messages - so this can't be the error.

from ism7mqtt.

To get this any further my next step is to extend the logging to the raw binary (or hex encoded) messages for ism7proxy and ism7mqtt - we already found out, that there are differences between my windows env and your runtime and my guess is, that there might be a subtle difference at the binary level.
Hopefully this will show the difference...

from ism7mqtt.

To get this any further my next step is to extend the logging to the raw binary (or hex encoded) messages for ism7proxy and ism7mqtt - we already found out, that there are differences between my windows env and your runtime and my guess is, that there might be a subtle difference at the binary level.
Hopefully this will show the difference...

How can I get the logs you need?
I really want to use ism7mqtt with my ISM7.

Thanks

from ism7mqtt.

Since I was specifically asked if the "1x Warmwasser" works: It does work for me. See screenshots. The last one is from the WOLF Smartset iOS App

from ism7mqtt.

My BM-2 firmware version is 3.0, btw.

from ism7mqtt.

Hallo

Könnte hier bitte jemand reinschreiben wie man das Addon zum laufen bekommt. Ich habe es im Homeassistenten installiert, den Mqtt Server installiert. Das Addon bringt immer wieder einen Fehler.

Vielen Dank.

s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
++ cd /app
Creating initial configuration /config/ism7-parameters-Wolf.json
++ parameters=/config/ism7-parameters-Wolf.json
++ '[' -f /config/ism7-parameters-Wolf.json ']'
++ echo 'Creating initial configuration /config/ism7-parameters-Wolf.json'
++ /app/ism7config -t /config/ism7-parameters-Wolf.json
2023-06-29 13:22:32.0172|INFO|LuCon.WebPortal.StandaloneService.NetworkConnector|Try IP-resolve for host:192.168.178.84
2023-06-29 13:22:32.0846|INFO|LuCon.WebPortal.StandaloneService.NetworkConnector|Try connect destination server -> 192.168.178.84:9092, Timeout:1000 ms
2023-06-29 13:22:37.3709|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 /app/ism7config/Program.cs:line 120
at ism7config.Program.

from ism7mqtt.

First, you should install an MQTT Broker from the Add-On Store. The preferred one is Mosquitto. Remember to restart HA after the installation. After the restart you go to the Add-On Store again, click on the three dots in the upper right corner and add the repository https://github.com/b3nn0/hassio-addon-ism7mqtt there. Then install the new add-on from the Add-On Store. You probably should restart HA again at this point. Find your ISM7's local IP address (from the router, it advertises itself as "WOLFLINK") and the password from the sticker on your ISM7 set.
Next, enter these values in the configuration tab of the Add-On, give it a unique name and save. Next, in the first tab, start the add-on.
What the protocol - it takes a couple of minutes upon first start, depending on the complexity of your heating setup.
When it's done the devices and entities should appear in the MQTT integration.

from ism7mqtt.

from ism7mqtt.

@wartungsmonteur I'm currently working on a new version, which has an increased timeout (rooneyaut also had problems with the default timeout of 1 second) I'll let you know when it's available

from ism7mqtt.

Vielen Dank für ihre Bemühungen.

from ism7mqtt.

@wartungsmonteurIch arbeite derzeit an einer neuen Version, die ein erhöhtes Timeout hat (Rooneyaut hatte auch Probleme mit dem Standard-Timeout von 1 Sekunde). Ich werde Sie informieren, wenn sie verfügbar ist

Hallo lieber Programmierer

Gibt es schon etwas neues zu berichten ?

Viele Grüße

from ism7mqtt.

Can I join the party? Just for your information (and willing to test the new version once released):
I have a Wolf CHA 10 with BM2 FW 3.00. I'm using openHAB, but that should be irrelevant here.

I can read all values with ism7mqtt, but writing doesn't seem to be possible (I'm currently experimenting with warm water temperature only). I can see and set the updated values with MQTT Explorer but it doesn't get through the actual device.

I've tried writing to the following values, but none of them is applied as the value visible at the BM2 interface (neither directly nor after a device restart):

Wolf/192.168.178.212/CHA_0x8/Warmwassersolltemperatur
Wolf/192.168.178.212/WWSystem_BM-2_0x35/Warmwassersolltemperatur_eingestellt/350009
Wolf/192.168.178.212/WWSystem_BM-2_0x35/Warmwassersolltemperatur_eingestellt/350014

Edit: Just to be complete, the Android Wolf Smartset app works locally without problems. Sending the updated values only takes about a second or two until it's updated in the BM2 UI.

from ism7mqtt.

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

from ism7mqtt.

@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

from ism7mqtt.

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.

from ism7mqtt.

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>

from ism7mqtt.

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)

from ism7mqtt.

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,

from ism7mqtt.

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

from ism7mqtt.

from ism7mqtt.

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

from ism7mqtt.

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>

from ism7mqtt.

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?

from ism7mqtt.

Yes, I also tried other values.

from ism7mqtt.

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

from ism7mqtt.

@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 :-)

from ism7mqtt.

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

from ism7mqtt.

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.

from ism7mqtt.

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

from ism7mqtt.

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.

from ism7mqtt.

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

from ism7mqtt.

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.

from ism7mqtt.

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

from ism7mqtt.