I already had this problem during the solution phase for issue #112 (see https://github.com/zivillian/ism7mqtt/issues/112#issuecomment-2276403954). Now it occurred again. I think it has nothing to do at all with ism7mqtt. But maybe someone can help to figure out the root cause.

My problem: My ism module (Wolf Link Home) stops propagating data to ism7mqtt after some time (first time it was after a few hours after start, this time 2 days after start). The output of ism7mqtt does not state any issue. It is up and running. Restarting ism7mqtt does not solve the issue. When restarting with debug flag I can see that none of the data request is responded to (also not the initial “pull” request). But the keep alive works and logs every 60 seconds. So at least the ism module connection is not dead.

When restarting the ism module and restarting ism7mqtt after that, everything works fine again.

I had this issue two or three times since the two weeks my heat pump is installed. As the connection to the Wolf portal also causes other issues with the local connection to ism7mqtt (see comment https://github.com/zivillian/ism7mqtt/issues/112#issuecomment-2283534245) it might be the best candidate as being the root cause. Unfortunately I need the Smartset cloud app at present for setting my time programs. So I do not want to turn off the cloud connection at present.

If someone ever had the problem and solved it, or if someone has an idea what I can test (despite cutting cloud connection ;-)) it is welcomed input for me.

Testing will be ugly as I have to wait at least a week after every change. But it is what it is. My current plans:

Disabling Access Point as parallel connections seems to be a general problem for the ism module (my ism is connected via LAN cable)
Switch to Docker instead of local Linux service (will most likely not help… but I want to switch to the master-Docker image anyhow as the Linix service was only an intermediate solution)
???

Cheers Volker

Why die you remove "When restarting the ism module via browser and local IP address"? if this works, one could automate the restart this way.. Not a solution, but viable workaround...

As you may have already observed: I tend to write way too much to describe something. ;-)) I just thought that the sentence might be easier to read without the information how I restarted the ism module. But yes, restarting automatically by browser emulation might be the last resort if nothing else helps.

I already changed yesterday evening both, step 1 and 2. So my ism7mqqt runs in a Docker container now (:master image) and the access point is disabled. My hope is that point 1 solves the issue. I will report...

It happened again tonight. :-\ This time 16 hours after start. I have no idea what to test anymore either than disabling Smartset portal which I do not want to miss at present.

At least I found out how a reboot of the ism7 can be initiated automatically. You have to send a HTTP POST call to following URL:

http://<YOUR_ISM_MODULE_IP>/protect/reboot.htm

with payload

name=reboKickoff
rebo=init

The URL is hidden behind a .htaccess authentification (user: admin, password: your ism module password).

So I will maybe implement a check whether a few of the most chatty sensors aren't updated for a longer time and than initiate the reboot POST call via curl from my raspberry. Not ideal though. Finding the root cause would be a lot more satisfying.

P.S. A manual reboot via clicking a button in the browser works from this URL: http:///protect/reboot.htm

Perhaps you should deactivate the ism7mqtt to find out the reason and only run the Wolf Smartset on the PC with a similar scope when retrieving data. If it stops there, Wolf will have to take over. If not, the ism7mqtt queries are the cause, as there are various differences in the XML...

Letting the Smartset PC app run for multiple days is nothing I'm really in a mood for. Especially as I cannot use ism7mqtt during that time. But maybe I have to go that way.

Beforehand I will execute another test. I observed, that in case you do not explicitly set an interval parameter, the is attribute is removed from the xml by ism7mqtt. The Smartset PC app is always sending it. So I will add the interval parameter and set it to standard value 60.

Yes, the first step, of course, should be to create XML that is as identical as possible. This also includes the namespace attributes in the rbreq element, which do not appear in the original XML, but probably the deviations in the attributes (bn, ae) or the lack of such (is) are the issue.

In order for an regular update of my CHA07 i had a technician of wolf at home today. I reported the problem and he confirmed that developers of wolf investigate in it since several month now. So i guess we have no chance till an update of ism. Best way is restart ism automatic if errors in communication occur.

For me nothing worked. I disabled wolf portal, i reduced observed parameters a bit (not much at all, but verry often updated an useless ones, like time of BM2).

The technician confirmed also, that only the mqtt api is involved. The ism is rechable by webinterface and Wolf Smartset Portal at all times. I noticed serveral errors in communication a day, not everytime the result is a data loss. If a data loss occur it is enough to restart ism Module, no need in reboot ism7mqtt oder Homeassistant.

This are my errors:

`System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.MoveNext(Thread threadPoolThread)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.MoveNext()
   at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(IAsyncStateMachineBox box, Boolean allowInlining)
   at System.Threading.Tasks.Task.RunContinuations(Object continuationObject)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at MQTTnet.Client.MqttClient.SubscribeAsync(MqttClientSubscribeOptions options, CancellationToken cancellationToken)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.ExecutionContextCallback(Object s)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.MoveNext(Thread threadPoolThread)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.MoveNext()
   at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(IAsyncStateMachineBox box, Boolean allowInlining)
   at System.Threading.Tasks.Task.RunContinuations(Object continuationObject)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetExistingTaskResult(Task`1 task, TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(TResult result)
   at MQTTnet.Client.MqttClient.SendAndReceiveAsync[TResponsePacket](MqttBasePacket requestPacket, CancellationToken cancellationToken)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.ExecutionContextCallback(Object s)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.MoveNext(Thread threadPoolThread)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.MoveNext()
   at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(IAsyncStateMachineBox box, Boolean allowInlining)
   at System.Threading.Tasks.Task.RunContinuations(Object continuationObject)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetExistingTaskResult(Task`1 task, TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(TResult result)
   at MQTTnet.PacketDispatcher.MqttPacketAwaitable`1.WaitOneAsync(TimeSpan timeout)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.ExecutionContextCallback(Object s)
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.MoveNext(Thread threadPoolThread)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.ExecuteFromThreadPool(Thread threadPoolThread)
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
   at System.Threading.Thread.StartCallback()
--- End of stack trace from previous location ---
   at System.Net.Sockets.TcpClient.CompleteConnectAsync(ValueTask task)
   at ism7mqtt.Ism7Client.ConnectAsync(CancellationToken cancellationToken) in /app/ism7mqtt/ISM7/Ism7Client.cs:line 64
   at ism7mqtt.Ism7Client.RunAsync(String password, CancellationToken cancellationToken) in /app/ism7mqtt/ISM7/Ism7Client.cs:line 51
   at ism7mqtt.Program.Main(String[] args) in /app/ism7mqtt/Program.cs:line 145
Unhandled exception. System.Net.Sockets.SocketException (101): Network unreachable
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, Boolean forAsyncThrow)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ConnectAsync(Socket socket)
   at System.Net.Sockets.Socket.ConnectAsync(EndPoint remoteEP, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
   at System.Net.Sockets.TcpClient.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
   at ism7mqtt.Ism7Client.ConnectAsync(CancellationToken cancellationToken) in /app/ism7mqtt/ISM7/Ism7Client.cs:line 64
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine& stateMachine)
   at ism7mqtt.Ism7Client.ConnectAsync(CancellationToken cancellationToken)
   at ism7mqtt.Ism7Client.RunAsync(String password, CancellationToken cancellationToken) in /app/ism7mqtt/ISM7/Ism7Client.cs:line 51
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine& stateMachine)
   at ism7mqtt.Ism7Client.RunAsync(String password, CancellationToken cancellationToken)
   at ism7mqtt.Program.Main(String[] args) in /app/ism7mqtt/Program.cs:line 145
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.ExecutionContextCallback(Object s)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.MoveNext(Thread threadPoolThread)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.MoveNext()
   at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(IAsyncStateMachineBox box, Boolean allowInlining)
   at System.Threading.Tasks.Task.RunContinuations(Object continuationObject)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at MQTTnet.Client.MqttClient.SubscribeAsync(MqttClientSubscribeOptions options, CancellationToken cancellationToken)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.ExecutionContextCallback(Object s)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.MoveNext(Thread threadPoolThread)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.MoveNext()
   at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(IAsyncStateMachineBox box, Boolean allowInlining)
   at System.Threading.Tasks.Task.RunContinuations(Object continuationObject)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetExistingTaskResult(Task`1 task, TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(TResult result)
   at MQTTnet.Client.MqttClient.SendAndReceiveAsync[TResponsePacket](MqttBasePacket requestPacket, CancellationToken cancellationToken)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.ExecutionContextCallback(Object s)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.MoveNext(Thread threadPoolThread)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.MoveNext()
   at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(IAsyncStateMachineBox box, Boolean allowInlining)
   at System.Threading.Tasks.Task.RunContinuations(Object continuationObject)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetExistingTaskResult(Task`1 task, TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(TResult result)
   at MQTTnet.PacketDispatcher.MqttPacketAwaitable`1.WaitOneAsync(TimeSpan timeout)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.ExecutionContextCallback(Object s)
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.MoveNext(Thread threadPoolThread)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.ExecuteFromThreadPool(Thread threadPoolThread)
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
   at System.Threading.Thread.StartCallback()
--- End of stack trace from previous location ---
   at System.Net.Sockets.TcpClient.CompleteConnectAsync(ValueTask task)
   at ism7mqtt.Ism7Client.ConnectAsync(CancellationToken cancellationToken) in /app/ism7mqtt/ISM7/Ism7Client.cs:line 64
   at ism7mqtt.Ism7Client.RunAsync(String password, CancellationToken cancellationToken) in /app/ism7mqtt/ISM7/Ism7Client.cs:line 51
   at ism7mqtt.Program.Main(String[] args) in /app/ism7mqtt/Program.cs:line 145
   at ism7mqtt.Program.<Main>(String[] args)
/run.sh: line 26:   235 Aborted                 (core dumped) /app/ism7mqtt $ISM_ARGS
       236 Done                    | ts
ism7mqtt unexpectedly quit with return code 134 `

Last try: im going to connect my ism7 per Ethernet (LAN) Not WLAN anymore. I‘ve heard that this could be a problem.

In order for an regular update of my CHA07 i had a technician of wolf at home today. I reported the problem and he confirmed that developers of wolf investigate in it since several month now. So i guess we have no chance till an update of ism. Best way is restart ism automatic if errors in communication occur.

For me nothing worked. I disabled wolf portal, i reduced observed parameters a bit (not much at all, but verry often updated an useless ones, like time of BM2).

The technician confirmed also, that only the mqtt api is involved. The ism is rechable by webinterface and Wolf Smartset Portal at all times. I noticed serveral errors in communication a day, not everytime the result is a data loss. If a data loss occur it is enough to restart ism Module, no need in reboot ism7mqtt oder Homeassistant.

This are my errors: System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext(Thread threadPoolThread) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext() at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(IAsyncStateMachineBox box, Boolean allowInlining) at System.Threading.Tasks.Task.RunContinuations(Object continuationObject) at System.Threading.Tasks.Task.FinishContinuations() at System.Threading.Tasks.Task1.TrySetResult(TResult result) at MQTTnet.Client.MqttClient.SubscribeAsync(MqttClientSubscribeOptions options, CancellationToken cancellationToken) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.ExecutionContextCallback(Object s) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext(Thread threadPoolThread) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext() at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(IAsyncStateMachineBox box, Boolean allowInlining) at System.Threading.Tasks.Task.RunContinuations(Object continuationObject) at System.Threading.Tasks.Task.FinishContinuations() at System.Threading.Tasks.Task1.TrySetResult(TResult result) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.SetExistingTaskResult(Task1 task, TResult result) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.SetResult(TResult result) at MQTTnet.Client.MqttClient.SendAndReceiveAsync[TResponsePacket](MqttBasePacket requestPacket, CancellationToken cancellationToken) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.ExecutionContextCallback(Object s) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext(Thread threadPoolThread) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext() at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(IAsyncStateMachineBox box, Boolean allowInlining) at System.Threading.Tasks.Task.RunContinuations(Object continuationObject) at System.Threading.Tasks.Task.FinishContinuations() at System.Threading.Tasks.Task1.TrySetResult(TResult result) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.SetExistingTaskResult(Task1 task, TResult result) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.SetResult(TResult result) at MQTTnet.PacketDispatcher.MqttPacketAwaitable1.WaitOneAsync(TimeSpan timeout) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.ExecutionContextCallback(Object s) at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext(Thread threadPoolThread) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.ExecuteFromThreadPool(Thread threadPoolThread) at System.Threading.ThreadPoolWorkQueue.Dispatch() at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart() at System.Threading.Thread.StartCallback() --- End of stack trace from previous location --- at System.Net.Sockets.TcpClient.CompleteConnectAsync(ValueTask task) at ism7mqtt.Ism7Client.ConnectAsync(CancellationToken cancellationToken) in /app/ism7mqtt/ISM7/Ism7Client.cs:line 64 at ism7mqtt.Ism7Client.RunAsync(String password, CancellationToken cancellationToken) in /app/ism7mqtt/ISM7/Ism7Client.cs:line 51 at ism7mqtt.Program.Main(String[] args) in /app/ism7mqtt/Program.cs:line 145 Unhandled exception. System.Net.Sockets.SocketException (101): Network unreachable at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, Boolean forAsyncThrow) at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ConnectAsync(Socket socket) at System.Net.Sockets.Socket.ConnectAsync(EndPoint remoteEP, CancellationToken cancellationToken) at System.Net.Sockets.Socket.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken) at System.Net.Sockets.TcpClient.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken) at ism7mqtt.Ism7Client.ConnectAsync(CancellationToken cancellationToken) in /app/ism7mqtt/ISM7/Ism7Client.cs:line 64 at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine& stateMachine) at ism7mqtt.Ism7Client.ConnectAsync(CancellationToken cancellationToken) at ism7mqtt.Ism7Client.RunAsync(String password, CancellationToken cancellationToken) in /app/ism7mqtt/ISM7/Ism7Client.cs:line 51 at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine& stateMachine) at ism7mqtt.Ism7Client.RunAsync(String password, CancellationToken cancellationToken) at ism7mqtt.Program.Main(String[] args) in /app/ism7mqtt/Program.cs:line 145 at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.ExecutionContextCallback(Object s) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext(Thread threadPoolThread) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext() at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(IAsyncStateMachineBox box, Boolean allowInlining) at System.Threading.Tasks.Task.RunContinuations(Object continuationObject) at System.Threading.Tasks.Task.FinishContinuations() at System.Threading.Tasks.Task1.TrySetResult(TResult result) at MQTTnet.Client.MqttClient.SubscribeAsync(MqttClientSubscribeOptions options, CancellationToken cancellationToken) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.ExecutionContextCallback(Object s) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext(Thread threadPoolThread) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext() at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(IAsyncStateMachineBox box, Boolean allowInlining) at System.Threading.Tasks.Task.RunContinuations(Object continuationObject) at System.Threading.Tasks.Task.FinishContinuations() at System.Threading.Tasks.Task1.TrySetResult(TResult result) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.SetExistingTaskResult(Task1 task, TResult result) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.SetResult(TResult result) at MQTTnet.Client.MqttClient.SendAndReceiveAsync[TResponsePacket](MqttBasePacket requestPacket, CancellationToken cancellationToken) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.ExecutionContextCallback(Object s) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext(Thread threadPoolThread) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext() at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(IAsyncStateMachineBox box, Boolean allowInlining) at System.Threading.Tasks.Task.RunContinuations(Object continuationObject) at System.Threading.Tasks.Task.FinishContinuations() at System.Threading.Tasks.Task1.TrySetResult(TResult result) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.SetExistingTaskResult(Task1 task, TResult result) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.SetResult(TResult result) at MQTTnet.PacketDispatcher.MqttPacketAwaitable1.WaitOneAsync(TimeSpan timeout) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.ExecutionContextCallback(Object s) at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.MoveNext(Thread threadPoolThread) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.AsyncStateMachineBox1.ExecuteFromThreadPool(Thread threadPoolThread) at System.Threading.ThreadPoolWorkQueue.Dispatch() at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart() at System.Threading.Thread.StartCallback() --- End of stack trace from previous location --- at System.Net.Sockets.TcpClient.CompleteConnectAsync(ValueTask task) at ism7mqtt.Ism7Client.ConnectAsync(CancellationToken cancellationToken) in /app/ism7mqtt/ISM7/Ism7Client.cs:line 64 at ism7mqtt.Ism7Client.RunAsync(String password, CancellationToken cancellationToken) in /app/ism7mqtt/ISM7/Ism7Client.cs:line 51 at ism7mqtt.Program.Main(String[] args) in /app/ism7mqtt/Program.cs:line 145 at ism7mqtt.Program.<Main>(String[] args) /run.sh: line 26: 235 Aborted (core dumped) /app/ism7mqtt $ISM_ARGS 236 Done | ts ism7mqtt unexpectedly quit with return code 134

The technician confirmed also, that only the mqtt api is involved.

I don't think Wolf cares about a mqtt api.. did you mean: that only the ism7<->Wolf Smartset App (not Portal!) part of the ism7 is involved..?

@CEXC

You seem to have a different problem than me (or at least a different behavior of the same problem). In case my ism module stops sending I do not have any error in the log, ism7mqtt is up an running and even receives the keep-alive messages.

Also the Smartset portal cloud is not receiving any data anymore.

It feels a bit like the ism is sending the data to a not anymore existing connection.

P.S. My ism module is connected via LAN from the very first beginning (with WLAN disabled). So at least for me LAN does not help.

It feels a bit like the ism is sending the data to a not anymore existing connection.

But there are keep alive messages, or aren't they? So the connection is fine..

It feels a bit like the ism is sending the data to a not anymore existing connection.

But there are keep alive messages, or aren't they? So the connection is fine..

For me it could be the solution. After i changed the setup to LAN i‘ve noticed that my server has already a static ip, but the homeassistant vm in VirtualBox does‘nt. So i set a static one in WebGUI of HomeAssistant. Since yesterday i had no problems with the datadelivery.

(I have still exceptions in the log like:

IOException: Connection reset by Peer
InvalidDataException: Timeout )

But the watchdog is able to handle that now..

It feels a bit like the ism is sending the data to a not anymore existing connection.

But there are keep alive messages, or aren't they? So the connection is fine..

Yes the keep alive do still arrive. Today after two days I had the problem again. :-/

In the log file nothing special happens before only the keep alive message do arrive. The only thing I observe is, that it mostly seems to happen after one of the "normal" network Exceptions lead to a restart of ism7mqtt. Not directly after that. But some 2 to 10 hours.

The next thing I will test is disabling the portal connection. But I have to wait for that until mid or even end of September for some reason.

Nothing more I can do at this point. :-/ Maybe restarting the module once a day via curl when I find time.

My ism7mqtt runs with debug flag enable since a few days. It might be that the "stop sending" problem always happens a few hours after the "typical" IOException problem (not sure yet). Therefore I tried to analyze the exceptions a bit in the log file. The Exception always occurs in my log when the data point kesseltemperatur_2 (in=12376, CTID=270044) was send as last value before. Always. That seems not to be a coincidence.

I even do not know what the attribute is for. It is not shown on the BM-2 module itself. Only the "normal" kesseltemperatur (CTID=270006) is show there. So I will remove kesseltemperatur_2 from parameter.json and see whether something changes.

I do not have a lot hope that this will change anything. But who knows...

@krusta4711 can you share the debug log?

can you share the debug log?

Sure. I put the whole file with 6 days logs. I tried to anonymize it. I hope I did not miss anything.

The last time the ism module stopped sending but keep alive messages are still logged was Aug 23 12:26:48

Regarding the IOException I found one occurrence were the kesseltemperatur_2 was not the very last data point but at least it was in the last message.

edit: The file was removed by me for privacy reasons after zivillian downloaded it

After looking at your log, the proxy log of the latest smartset app and its behaviour and https://github.com/zivillian/ism7mqtt/issues/57#issuecomment-1874103810 I'm pretty sure, that the portal connection and amount of parameters is the root cause.

I've pushed some updates to automatically remove duplicate telegrams and empty parameters, but that may not be enough.

It looks, like your parameter.json contains everything generated by ism7config. Can you try to removing unused parameters like PRELOAD_Firmware?

If you still get timeouts and errors with the latest version, I'd like to see how the official app behaves - so you'll need to run ism7proxy and connect the app to the proxy instead of the ism.

Unfortunately I need the Smartset cloud app at present for setting my time programs.

Maybe it's a better idea to look into your root cause. Is #83 the reason, or do you have a different problem?

Thanks for the work, zivillian. :-)

It looks, like your parameter.json contains everything generated by ism7config. Can you try to removing unused parameters like PRELOAD_Firmware?

I already removed a bunch of parameters (e.g. the whole ism module). But I'm currently still at 249 properties. So yes, I will do another - and this time more drastically - cut down.

For what it is worth: I do not have any problems writing data, which was the main issue in #57.

If you still get timeouts and errors with the latest version, I'd like to see how the official app behaves - so you'll need to run ism7proxy and connect the app to the proxy instead of the ism.

I will do. My plans are:

Let run my current test setup (removal of kesseltemperatur_2 ) until it fails or succeeds. Might need another one or two days to know the outcome.
Cut down the number of parameters and use your latest version
If problems still occur: connect app to proxy

Maybe it's a better idea to look into your root cause. Is #83 the reason, or do you have a different problem?

83 does not seem to have anything in common with my problem. I saw the times when I started with ism7mqtt (so they were send) but removed them from properties because I do not need them. All parameters I want to see are there and writing works too. So my root cause is simply that the ism module stops sending data completely.

So my root cause is simply that the ism module stops sending data completely.

I've closed #112. I just asked, because in your initial post you stated:

So I do not want to turn off the cloud connection at present.

Do you still have the cloud connection on? If yes, I'd suggest to turn it of as it is known to cause problems.

For what it is worth: I do not have any problems writing data

Great - this means we have another issue. So regarding your plan:

I don't think this is the cause, but give it a try
- if it is, we should look into this
even if this works, this is not a permanent solution. I've looked through your parameter list and I would like to see most of the CHA parameters, which is more than 50%
I've looked at the app again, and for my setup I only see a reduced set of values - so this may result in the same like 2. This would also mean to let run the mobile app for multiple days to be able to repoduce the problem (which is not easy). I've also seen, that each parameter has a flag, which says how often the value should be fetched:
- once during startup
- subscribe (as ism7mqtt does)
- only on gateway request (whatever this means)
- they can also have an individual interval (I also found some code which fetches parameters once per day)
So as number four we can look further into this.

Thank you again, @zivillian for the time you are investing. :-) I do not take it as granted!!

Do you still have the cloud connection on? If yes, I'd suggest to turn it of as it is known to cause problems.

Yes it is still on. I cannot turn it off until late September (meanwhile maybe even October) for some external reasons which would take too long to explain here. It is what it is and I take it as "opportunity" to test different scenarios with cloud connection enabled. Older FW/HW of the ism module works fine with cloud connection enabled (beside the IOExceptions which do not really harm). Maybe we find the reason why the new FW/HW behaves different. If we do not find any way to resolved the "total stop of sending data" until October, turning off the cloud connection will be something I'm very happy to test.

So regarding your plan:
1. I don't think this is the cause, but give it a try

Yes, I also mentioned before the test that I doubt that it will help. But as it already ran more than 24 hours fine, I wanted to give it a try instead of stopping the test. Every information gathered might be helpful. Spoiler: we are both right. It did not help ;-P. For more information read below the first line.

2. even if this works, this is not a permanent solution. I've looked through your parameter list and I would like to see most of the CHA parameters, which is more than 50%

Yes you are right again. I did a quick check yesterday and most of the values of the CHA are important. I guess I can cut down a lot of the Controls (home assistant wording) for writing data . But the Sensors are definitely needed long term. On the other hand, if it would work well with less parameters, it would of course be a better situation missing some information than what I have now.

4. So as number four we can look further into this.

That would be a tough path. But yes, maybe that is something to be done in the end. I would still do the other tests beforehand as they are easier. The testing is ugly anyhow. I need to wait days before I know the outcome of any change.

That said... here is what happened lately:

My ism module stopped again sending data (current test scenario: removal of parameter kesseltemperatur_2). This time 28 hours after start. What was different this time: I did not recognized the issue and so did not intervene manually for the very first time. The problem started 26th August at 17:00. On 27th at 5:00 in the morning, an IOException occurred, ism7mqtt was restarted by Linux and the ism module was sending data again.

That is a new insight, as until now when I restarted ism7mqtt manually it did not help. Even when restarting 2 or 3 hours after the problem occurred. The data was still not send. So I always had to restart the ism module itself. It seems - when waiting long enough - there is at least some kind of self-healing. Ok, ok, 12 hours are a lot. But nevertheless... better than not-self-healing at all as I thought it is.

But this was not the end. The ism module stopped again sending data at 15:00 today (10 hours after the automatic restart in the morning). At 15:35 an IOException occurred and after the automatic restart everything was fine. So this time it was self-healing after 35 minutes.

I will let run this test at least for another day. I am too curious to see what happens from now on. How frequent will the issue occur after the first two occurrences behaved totally different time-wise? Will it stop self-healing? Or will the problem maybe even disappear at all after hick-ups? Very unlikely... but who knows. ;-P

@zivillian Another observation of mine is, that the keep alive messages got a bit strange after two days. I guess that is normal but I try to think in any direction and at least want to mention it:

At the beginning it looked like this:

ism7mqtt[799092]: >
ism7mqtt[799092]: !
ism7mqtt[799092]: <
ism7mqtt[799092]: !

...and later like this:

ism7mqtt[1831789]: >         !
ism7mqtt[1831789]: <         !
ism7mqtt[1831789]: >         "
ism7mqtt[1831789]: <         "

I guess it is a normal behavior with the short value counted up and maybe even TCP standard. But maybe the new ism module FW has problems with some white-space characters?

Edit: the last keep alive messages before a problem seems to be different each time. So this might not be something to investigate after all.

I will let run this test at least for another day.

Or maybe two or three...

keep alive messages got a bit strange

What you see is the "printable" part of a binary message - I was too lazy to make it look useful so what you see is "something" to be sure that keepalive is still working

Intermediate result of my current test:

Life is strange. :-P

Since the last period of missing data, everything works like a charm. Since nearly 54 hours I have neither any IOExceptions nor the "total stop of sending data" issue. I never had such a long period without any issue before . So maybe the solution is just waiting and sit it out :-D

I even started today clicking around on the Wolf Smartset mobile phone app, just to force the cloud connection to connect and to force problems.

The timeline of my current - still ongoing - test looks following:

ism7mqtt was started on August 25 at 13:00
after 28 hours the Wolf ism module stopped sending data on 26th August at 17:00 until 5 o'clock in the morning on 27th August (= for ~ 12 hours)
an IOException forced an automatic restart of ism7mqtt. The data was send again by the ism module.
At 15:00 the same day the ism module stopped sending data again (ca. 10 hours after previous restart)
35 minutes later an IOException forced another restart and the data was send again immediately
Since then (27th August 15:35) until now: No issue at all.

Just to emphasize it: when I restarted ism7mqtt manually in case the "total stop of sending data" problem occurred, it did not help. I had the reboot the ism module. So just waiting for an automatic restart of the ism7mqtt seems to have a self-healing effect.

I will have a deeper look into the log files at the weekend to see whether there are differences in the communication before and after the self-healing.

I will let run this test a few more days as long as no issue occurs.

After that I will try the new newest version of ism7mqtt on master and after that a reduced set of properties. So I split my point 2) of my original test plan (see https://github.com/zivillian/ism7mqtt/issues/115#issuecomment-2309574995) into 2a and 2b. That is more effort but I think it is the cleaner way to find the root cause (not mixing up two changes in one test).

P.S. I like to give the "total stop of sending data" problem a shorter name. How about TSSD? ;-P

The timeline of my current - still ongoing - test looks following:

* ism7mqtt was started on August 25 at 13:00
* after 28 hours the Wolf ism module stopped sending data on 26th August at 17:00 until 5 o'clock in the morning on 27th August (= for ~ 12 hours)
* an IOException forced an automatic restart of ism7mqtt. The data was send again by the ism module.
* At 15:00 the same day the ism module stopped sending data again (ca. 10 hours after previous restart)
* 35 minutes later an IOException forced another restart and the data was send again immediately
* Since then (27th August 15:35) until now: No issue at all.

Newest information:

On 30th August at 13:30 (ca. 70 hours after the last issue) I had and Exception in the log and an automatic restart of ism7mqtt. Everything worked fine before and after the restart, though.

The Exception type was a new one to me. I have never seen it before in my log file. Instead of the "typical" IOException, it was this one:

 < <tbres bn="7" gw="1" st="ER" ts="2024-08-30T13:28:10" emsg="timeout"/>
 System.IO.InvalidDataException: timeout
    at ism7mqtt.Ism7Client.OnPushResponseAsync(IResponse response, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/Ism7Client.cs:line 275
    at ism7mqtt.ResponseDispatcher.DispatchAsync(IResponse response, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/ResponseDispatcher.cs:line 35
    at ism7mqtt.Ism7Client.ReadPipeAsync(PipeReader source, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/Ism7Client.cs:line 213

I checked it in my log file and it was also the very first time I have an st="ER". So at least I have something new. :-P. As long as I do not get the TSSD, I do not really mind. So I will still let run my current test for a few days.

I will have a deeper look into the log files at the weekend to see whether there are differences in the communication before and after the self-healing.

I do not see big differences between the first start (15 hours of not sending data) and the third start (70 hours without any issue). I just observed slightly changed dl attribute for some datapoints. For example for in="10195" (PTID="220103", "Außentemperatur"):

<irs se="A;11" ba="0x35" in="10195" dl="0xC8" dh="0x0" st="OK"/>
<irs se="A;11" ba="0x35" in="10195" dl="0xFF" dh="0x0" st="OK"/>

According to the code dl means "DBLow" and seems to be used for extracting the value of the datapoint? The values are there and look correct though.

I will send you the log file via e-mail.

I also had another quick look into my old log file of the Smartset PC app. There it looks like the pull and push requests are handled sequentially. So the PC app sends a request for one single device, waits for the response and only after the response sends the next request.

ism7mqtt seems to send at least the pull requests in parallel. But as the ism module is responding to all messages I do not think that it is an issue.

Today I stopped my current test run. No other issue occurred. So the ism module healed itself after the first two TSSD and ran 122 hours without any further stop of sending data. I hope that the self-healing was no coincidence täbut happens every time. ;-)

A few minutes ago I started test 2a) of my test plan: Trying out the new ism7mqtt version from @zivillian which was build last week (with changes like removing duplicates and xml declaration from the requests).

I did not reduce the amount of parameters yet. So let's wait what happens. :-)

Since i had changed the connection of ism to LAN and setup a static ip to home assistant running in Virtual Box plus Wolf updated my cha (outside device, no update to BM2 or ISM7) i had only one failure of transmitting the data. My Cloud Portal is deactivated and i have already reduced the Parameters. Nevertheless i have still multiple errors a day in the logs, mostly these timeouts, but the watchdog does his Job, so there are not resulting in failures of transmitting data.

By the way, just for my interrests, maybe it has nothing to do with this behavior: I noticed that my router, wich shows all connected devices, even wlan-devices, do not show the Mac and IP of my ism Module. Is it possible to block this in low OSI-Layers? I can reach the Wolf Configuration Website and be able to ping the ism7 too.

I noticed that my router, wich shows all connected devices, even wlan-devices, do not show the Mac and IP of my ism Module

My Router is showing everything of the ism module (IP, MAC and even client name ("Espressif Inc")). My ism module is configured to use DHCP but with a static address configured in the router.

Intermediate result of my current test (I hope I do not get on your nerves ;-)):

Since I started my test "2a" (= newest main-branch version from zivillian with some optimizations) on 1st of September, I did not have any problem of "total stop of sending data (TSSD)". I even had none of the IOException again I really had a lot (which - again - do not bother me because after an automatic restart of ism7mqtt everything works fine again).

But I had two other Exceptions leading to automatic ism7mqtt restarts instead since 1st of September:

An "InvalidDataException" I already had before (but rarely):

System.IO.InvalidDataException: timeout
   at ism7mqtt.Ism7Client.OnPushResponseAsync(IResponse response, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/Ism7Client.cs:line 244
   at ism7mqtt.ResponseDispatcher.DispatchAsync(IResponse response, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/ResponseDispatcher.cs:line 35
   at ism7mqtt.Ism7Client.ReadPipeAsync(PipeReader source, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/Ism7Client.cs:line 191
System.Net.Sockets.SocketException (125): Operation canceled
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError, CancellationToken)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16)
   at ism7ssl.Ism7SslStream.ReadAsync(Memory`1 buffer, CancellationToken cancellationToken)
   at ism7mqtt.Ism7Client.FillPipeAsync(PipeWriter target, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/Ism7Client.cs:line 145

And a SocketException I did not ever observed before:

System.Net.Sockets.SocketException (104): Connection reset by peer
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError, CancellationToken)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16)
   at ism7ssl.Ism7SslStream.ReadAsync(Memory`1 buffer, CancellationToken cancellationToken)
   at ism7mqtt.Ism7Client.FillPipeAsync(PipeWriter target, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/Ism7Client.cs:line 145
System.Net.Sockets.SocketException (104): Connection reset by peer
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError, CancellationToken)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16)
   at ism7ssl.Ism7SslStream.ReadAsync(Memory`1 buffer, CancellationToken cancellationToken)
   at ism7mqtt.Ism7Client.FillPipeAsync(PipeWriter target, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/Ism7Client.cs:line 145
   at System.IO.Pipelines.Pipe.GetReadAsyncResult()

To emphasize it again and again: These Exceptions are no problem for me at all . You only "lose" data for 10 seconds and we might never get rid of the timeouts as long as you are connected to the Wolf cloud and Wolf does not provide a better firmware for the ism7 module.

The problem that let me create this issue was the "total stop of sending data" of the ism7 module which could only be healed by rebooting the module.. This did not happen anymore since the first self-healing of the problem. I'm not sure whether any of the changes I tried are responsible for the now smooth running ism7 module... or whether the "self-healing" of the ism7 module changed anything in the module itself to let it run relatively smooth now (e.g. omitting a problematic data point).

Regarding my next test "2b" (cutting down attributes) I had another look: I do not find a lot attributes I will not need in a long term. So as long as @zivillian is not too curious to see what happens with a drastically reduced set of parameters, I would let the current test run until the TSSD happens again.

P.S. @allcoolusernamesaregone ask me in issue #112 where I found the other users with the same TSSD problem. I did not found the link anymore back then. But yesterday a user stated here in a German community, that he has the same problem:

https://www.photovoltaikforum.com/thread/183019-erfahrungen-mit-der-wolf-cha/?postID=3923295#post3923295

He is even not using ism7mqtt at all and has an older HW of the ism7 module than me. So as I already assumed in the first paragraph of this ticket: the problem seems to have nothing to do with ism7mqtt at all.

And another user was posting, which also has the problem. SO at least I do not feel alone ;-): https://www.photovoltaikforum.com/thread/183019-erfahrungen-mit-der-wolf-cha/?postID=3926936#post3926936

Intermediate result of my current test (I hope I do not get on your nerves ;-)):

Since I started my test "2a" (= newest main-branch version from zivillian with some optimizations) on 1st of September, I did not have any problem of "total stop of sending data (TSSD)". I even had none of the IOException again I really had a lot (which - again - do not bother me because after an automatic restart of ism7mqtt everything works fine again).

But I had two other Exceptions leading to automatic ism7mqtt restarts instead since 1st of September:

An "InvalidDataException" I already had before (but rarely):
System.IO.InvalidDataException: timeout
   at ism7mqtt.Ism7Client.OnPushResponseAsync(IResponse response, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/Ism7Client.cs:line 244
   at ism7mqtt.ResponseDispatcher.DispatchAsync(IResponse response, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/ResponseDispatcher.cs:line 35
   at ism7mqtt.Ism7Client.ReadPipeAsync(PipeReader source, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/Ism7Client.cs:line 191
System.Net.Sockets.SocketException (125): Operation canceled
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError, CancellationToken)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16)
   at ism7ssl.Ism7SslStream.ReadAsync(Memory`1 buffer, CancellationToken cancellationToken)
   at ism7mqtt.Ism7Client.FillPipeAsync(PipeWriter target, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/Ism7Client.cs:line 145
And a SocketException I did not ever observed before:
System.Net.Sockets.SocketException (104): Connection reset by peer
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError, CancellationToken)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16)
   at ism7ssl.Ism7SslStream.ReadAsync(Memory`1 buffer, CancellationToken cancellationToken)
   at ism7mqtt.Ism7Client.FillPipeAsync(PipeWriter target, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/Ism7Client.cs:line 145
System.Net.Sockets.SocketException (104): Connection reset by peer
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError, CancellationToken)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16)
   at ism7ssl.Ism7SslStream.ReadAsync(Memory`1 buffer, CancellationToken cancellationToken)
   at ism7mqtt.Ism7Client.FillPipeAsync(PipeWriter target, CancellationToken cancellationToken) in /home/runner/work/ism7mqtt/ism7mqtt/src/ism7mqtt/ISM7/Ism7Client.cs:line 145
   at System.IO.Pipelines.Pipe.GetReadAsyncResult()
To emphasize it again and again: These Exceptions are no problem for me at all . You only "lose" data for 10 seconds and we might never get rid of the timeouts and as long as you are connected to the Wolf cloud and Wolf does not provide a better firmware for the ism7 module.

The problem that let me create this issue was the "total stop of sending data" of the ism7 module which could only be healed by rebooting the module.. This did not happen anymore since the first self-healing of the problem. I'm not sure whether any of the changes I tried are responsible for the now smooth running ism7 module... or whether the "self-healing" of the ism7 module changed anything in the module itself to let it run relatively smooth now (e.g. omitting a problematic data point).

Regarding my next test "2b" (cutting down attributes) I had another look: I do not find a lot attributes I will not need in a long term. So as long as @zivillian is not too curious to see what happens with a drastically reduced set of parameters, I would let the current test run until the TSSD happens again.

These two exceptions are pretty common. You can reproduce it by running a ism7mqtt session and than restart the ism7 module. So maybe your module itself or something else is going to restart the ism7, wich also prevent the tssd error. For me my device worked great also until yesterday. Now i have these tssd at least two times a day :-/.

@zivillian @b3nn0 would it be possible to build a new version of the experimental homeassistant addon?

The experimental version always points to the latest master docker image. If you want to update it, I think you just need to hit the button to rebuild the container.

For me my device worked great also until yesterday. Now i have these tssd at least two times a day :-/.

So most likely the problem will come back to me too. :-|

Did you try to "sit it out" and wait for 12 hours or more? Since I did not intervene manually during the last two TSSD, I did not have the problem again. The last time it occurred on 27th August. But most likely that is only luck and it will occur again.

As I have written above: There is a user having TSSD but is not using ism7mqtt or a local connection at all. He only uses the Smartset phone app and the portal. So I doubt that there is anything we can do to solve the problem. Maybe we can just reduce the frequency or execute an automatic ism module reboot when TSSD occurs..

Did you try to "sit it out" and wait for 12 hours or more? Since I did not intervene manually during the last two TSSD, I did not have the problem again. The last time it occurred on 27th August. But most likely that is only luck and it will occur again.

I can’t try, because my module ist not working for hours until i reboot it by myself. Im trying the new version of ism7mqtt now. I noticed, but this is just a feeling, that if i have a browser in front with window focus on my homeassistant dashboard wich showing the datagraphs the TSSD error occurs much less frequently.

I can’t try, because my module ist not working for hours until i reboot it by myself.

Mine did self-heal after over 12 hours. So maybe it is worth a try waiting longer.

I can’t try, because my module ist not working for hours until i reboot it by myself.

Mine did self-heal after over 12 hours. So maybe it is worth a try waiting longer.

I tested it out with the newest version of ism7mqtt and with a reduced parameterset also. The TSSD occured again and didnt self healed, even after waiting more than 62 hours now, no data is updated unless i reboot my ism7 device.

I had two TSSD myself this week. The fist one I had to solve by manual restart because I needed contact to the heat pump for some configuration (I had no time to wait for self-healing). The second one was self-healing after 15 hours.

With the information from CEXC that a reduced set of attributes does not work either and with the information that there are even users not using a local connection at all but nevertheless get TSSDs, I'm pretty sure we cannot do anything against the root cause. :-\ It is most likely just bad ism module HW or SW.

So the next step for me: If you cannot fight the root course, find a workaround.

I will try out this weekend whether it is possible to restart the ism module per HTTP call (should be). If yes I will write me an automation to restart the ism module in case a chatty sensor did not change for a longer time. Not ideal, but it is what it is.

I have to say: I've never had this problem by now, but my ISM7 has been running via LAN for about 10 days only, portal connection is also active. Firmware version 4.40.1. Running as a service on 64 bit Debian with /opt/ism7mqtt/ism7mqtt -m 192.168.1.x -i 192.168.1.x -p abc123 -t /opt/ism7mqtt/parameter.json -s -d --retain

At the beginning I had other problems, no LAN connection at startup (no DHCP address received) or loss of LAN connection during operation. Of course, this also resulted in errors for all connections. Now with static IP and with 15m cable on an old Fritzbox and on another LAN port of the Fritze, 1GBit instead of 100MBit, this no longer happened. Has been running for 3 days in a row without any problems since the last start of ism7mqtt. Also in the days before I never got this issue.

Yesterday the Wolf Cloud was no longer updated, old temperatures etc. were visible. But commands via the app arrived at the IDU/BM2 and were processed. About 6 hours after the cloud issue I got a connection failure System.Net.Sockets.SocketException (104): Connection reset by peer the ism7 had probably closed all connections, ism7mqtt then restarted automatically, cloud is working again. I would hope, without this restart of the ism7mqtt service, i would have 4 days now.

I'm using a self compiled version of ism7mqtt from a checkout from github, code is equal to release v0.0.17.

I only have the CHA7 for heating with one heating circuit and a BM2. Wolf config 11. No additional AM, no MM, no warm water configuration. My parameter.json is quite small therefore (I think, see json - not a valid json with the comments... ).

But if this would occur, I would use the parameter 220032/Uhrzeit to automatically reboot if the mqtt topic would not be updated for some minutes. Not the nicest thing, but sufficient, I think.

{
  "Devices": [
    {
      "ReadBusAddress": "0x00",
      "WriteBusAddress": "0x00",
      "DeviceTemplateId": 190000,
      "Parameter": [
        190000,
        190001,
        190002,
        190003,
        190004,
        190007,
        190011,
        190012,
        190014,
        190015,
        190016,
        190019,
        190020,
        190021
      ]
    },
    {
      "ReadBusAddress": "0x35",
      "WriteBusAddress": "0x30",
      "DeviceTemplateId": 220000,
      "Parameter": [
        220032, // Uhrzeit
        220033, // Datum
      ]
    },
    {
      "ReadBusAddress": "0x35",
      "WriteBusAddress": "0x30",
      "DeviceTemplateId": 340000,
      "Parameter": [
        340001, //  Gemittelte Aussentemperatur
        340004, //  Anforderung Heizkreis
        340005, //  Heizkreis Status
        340011, //  Vorlauftemperatur
        340012, //  Sockeltemperatur Heizkurve
        340013, //  Startpunkt Heizkurve
        340014, //  Normaussentemperatur Heizkurve
        340015, //  Vorlauftemperatur Heizkurve
      ]
    },
    {
      "ReadBusAddress": "0x8",
      "WriteBusAddress": "0x3",
      "DeviceTemplateId": 270000,
      "Parameter": [
        270004, // Kesselsolltemperatur
        270005, // Aussentemperatur
        270006, // Kesseltemperatur
        270009, // Ruecklauftemperatur
        270010, // Aktuelle Leistungsvorgabe Verdichter
        270011, // Heizkreispumpe
        270012, // Zubringer-/Heizkreispumpe
        270016, // E-Heizung
        270017, // Verdichter
        270020, // E-Heizung Phase 1
        270021, // E-Heizung Phase 2 und 3
        270025, // Verdichterstarts
        270026, // Netzbetriebsstunden
        270027, // Betriebsstunden Verdichter
        270028, // Heizkreisdurchfluss
        270029, // Sammlertemperatur
        270030, // Anlagendruck
        270035, // Drehzahl ZHP
        270036, // Anzahl Netz Ein
        270038, // Betriebsstunden E-Heizung
        270040, // Zulufttemperatur
        270041, // Heissgastemperatur
        270042, // Sauggastemperatur
        270043, // Ablufttemperatur
        270044, // Kesseltemperatur 2
        270046, // Heizleistung
        270047, // Drehzahl Ventilator
        270048, // Verdichterfrequenz
        270049, // Leistungsaufnahme (WP + EHZ)
        270050, // Betriebsart Heizgeraet
        270051, // Verdichterstatus
        270052, // Status E-Heizung
        270058, // Aktuelle Sekundaerleistung
        270059, // Energiemenge HZ
        270063, // P_Heissgas
        270064, // P_Sauggas
        270065, // EEV HZ
        270075, // Soll-Spreizung
        270076, // Hysterese Heizbetrieb
        270081, // Freigabe Spreizungsregelung
        270134, // Energie VT (el.)
        270135, // Energie VT (th.)
        270136, // Energie VT (TAZ)
        270137, // Energie HP (el.)
        270138, // Energie HP (th.)
        270139, // Energie HP (JAZ)
        270140, // Energie VJ (el.)
        270141, // Energie VJ (th.)
        270142, // Energie VJ (JAZ)
        270144, // Status Nachtbetrieb
        270160, // Verbrauch aktueller Tag
        270161, // Erzeugte Waermemenge aktueller Tag
        270162, // Verbrauch aktueller Monat
        270163, // Erzeugte Waermemenge aktueller Monat
        270164, // Verbrauch aktuelles Jahr
        270165, // Erzeugte Waermemenge aktuelles Jahr
        270166, // Verbrauch Vorjahr
        270167, // Erzeugte Waermemenge Vorjahr
        270168, // Verbrauch Vorvorjahr
        270169, // Erzeugte Waermemenge Vorvorjahr
        270170, // TAZ aktueller Tag
        270171, // MAZ aktueller Monat
        270172, // JAZ aktuelles Jahr
        270173, // JAZ Vorjahr
        270174, // JAZ Vorvorjahr
        270175, // Verbrauch Vortag
        270176, // Erzeugte Waermemenge Vortag
        270177 // TAZ Vortag
      ]
    }
  ]
}

it is possible to restart the ism module per HTTP call (should be)

it is, yes. you could curl the url with the needed authentication admin/ism7 password.

I managed to restart the ism module from home assistant. :-) My HA runs on a raspberry PI, so I used the curl command for executing HTTP POST requests. I created an automation that checks every hour, whether one of the chatty CHA sensors did not change for more than 90 minutes. If that is the case, the ism module will automatically be rebooted.

In case the ism module reboots, my ism7mqtt also reboots automatically and works again out of the box. So I do not need to stop or start ism7mqtt in the HA automation. I'm pretty sure that this is also true in case an TSSD happens (at least for my system). If not, I would additionally have to stop my ism7mqtt beforehand.

My _shellcommand action to execute the curl command to reboot the ism module:

shell_command:
  restart_ism7_module: "curl -u 'admin:<YOUR_ISM_PASSWORD>' -d 'name=reboKickoff' -d 'rebo=init' http://<YOUR_ISM_IP_ADDRESS>/protect/reboot.htm"

My automation to check whether the ism module is in TSSD state and to trigger the reboot:

- id: '1726311555555'
  alias: Restart ism7 in case of TSSD
  description: ''
  trigger:
  - platform: time_pattern
    hours: /1
  condition:
  - condition: template
    value_template: >
      {% set secondsSinceLastChange = (as_timestamp(now()) - as_timestamp(states.sensor.wolf_cha_0x3_270043_ablufttemperatur.last_changed)) %}
      {% set maxWaitInSeconds = 60 * 90 %}
      {{ secondsSinceLastChange > maxWaitInSeconds }}
  action:
  - action: shell_command.restart_ism7_module
    data: {}
  mode: single

I'm curious to see what happens during the next TSSD. ;-)

But if this would occur, I would use the parameter 220032/Uhrzeit to automatically reboot if the mqtt topic would not be updated for some minutes. Not the nicest thing, but sufficient, I think.

The Uhrzeit/time would of course be the most predictable attribute. But I do not want to have this attribute in my parameters. The "Zuluft" and "Abluft" temperature parameters are chatty enough for me at present. Normally they change every minute. Only in the night they are stable sometimes for a maximum of 30 Minutes. That is enough for me at present.

But if I want to react faster in the future, the Uhrzeit/time is a good idea. 👍

Since my last TSSD, wich is very disappointing, im running on the same setting right now.

I‘ve added an automation, if Uhrzeit/Time not updated for 5 Minutes, than reboot ISM7. Thank you @krusta4711 for the example of the shell_command, works great.

I also use the very shortened Parameter.json of @allcoolusernamesaregone except 3 additional values i need.

Until now.. no TSSD at all.

Für die, die's interessiert: hier noch meine rein manuelle (ohne Auto Discovery) Config für Homeassistant für o.a. Parameter..

mqtt:
  binary_sensor:

    - name: "Status Heizkreispumpe"
      unique_id: "wolf.cha7.status.heizkreispumpe"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Heizkreispumpe/value"
      device_class: "running"
      payload_on: 1
      payload_off: 0
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Status Zubringerpumpe"
      unique_id: "wolf.cha7.status.zubringerpumpe"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Zubringer-_Heizkreispumpe/value"
      device_class: "running"
      payload_on: 1
      payload_off: 0
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Status Heizstab"
      unique_id: "wolf.cha7.status.heizstab"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/E-Heizung/value"
      device_class: "heat"
      payload_on: 1
      payload_off: 0
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Status Heizstab P1"
      unique_id: "wolf.cha7.status.heizstab.p1"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/E-Heizung_Phase_1/value"
      device_class: "heat"
      payload_on: 1
      payload_off: 0
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Status Heizstab P2P3"
      unique_id: "wolf.cha7.status.heizstab.p2p3"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/E-Heizung_Phase_2_und_3/value"
      device_class: "heat"
      payload_on: 1
      payload_off: 0
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Status Verdichter"
      unique_id: "wolf.cha7.status.verdichter"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Verdichter/value"
      device_class: "heat"
      payload_on: 1
      payload_off: 0
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Status Tagbetrieb"
      unique_id: "wolf.cha7.status.Tagbetrieb"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Status_Nachtbetrieb/value"
      device_class: "sound"
      payload_on: 0
      payload_off: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

  sensor:
    - name: "Temperatur Vorlauf"
      unique_id: "wolf.cha7.temperatur_vorlauf"
      state_topic: "Wolf/192.168.3.3/DHK_BM-2_0x35/Vorlauftemperatur"
      unit_of_measurement: "°C"
      state_class: "measurement"
      device_class: "temperature"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Temperatur Aussen gemittelt"
      unique_id: "wolf.cha7.temperatur.aussen.gemittelt"
      state_topic: "Wolf/192.168.3.3/DHK_BM-2_0x35/Gemittelte_Aussentemperatur"
      unit_of_measurement: "°C"
      state_class: "measurement"
      device_class: "temperature"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Temperatur Aussen"
      unique_id: "wolf.cha7.temperatur.aussen"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Aussentemperatur"
      unit_of_measurement: "°C"
      state_class: "measurement"
      device_class: "temperature"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Temperatur Kessel Soll"
      unique_id: "wolf.cha7.temperatur.kessel.soll"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Kesselsolltemperatur"
      unit_of_measurement: "°C"
      state_class: "measurement"
      device_class: "temperature"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Temperatur Kessel IDU"
      unique_id: "wolf.cha7.temperatur.kessel.idu"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Kesseltemperatur"
      unit_of_measurement: "°C"
      state_class: "measurement"
      device_class: "temperature"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Temperatur Kessel ODU"
      unique_id: "wolf.cha7.temperatur.kessel.odu"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Kesseltemperatur_2"
      unit_of_measurement: "°C"
      state_class: "measurement"
      device_class: "temperature"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Temperatur Ruecklauf"
      unique_id: "wolf.cha7.temperatur.ruecklauf"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Ruecklauftemperatur"
      unit_of_measurement: "°C"
      state_class: "measurement"
      device_class: "temperature"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Temperatur Sammler"
      unique_id: "wolf.cha7.temperatur.sammler"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Sammlertemperatur"
      unit_of_measurement: "°C"
      state_class: "measurement"
      device_class: "temperature"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Temperatur Luft zu"
      unique_id: "wolf.cha7.temperatur.zuluft"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Zulufttemperatur"
      unit_of_measurement: "°C"
      state_class: "measurement"
      device_class: "temperature"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Temperatur Heissgas"
      unique_id: "wolf.cha7.temperatur.heissgas"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Heissgastemperatur"
      unit_of_measurement: "°C"
      state_class: "measurement"
      device_class: "temperature"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Temperatur Sauggas"
      unique_id: "wolf.cha7.temperatur.sauggas"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Sauggastemperatur"
      unit_of_measurement: "°C"
      state_class: "measurement"
      device_class: "temperature"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Temperatur Luft ab"
      unique_id: "wolf.cha7.temperatur.abluft"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Ablufttemperatur"
      unit_of_measurement: "°C"
      state_class: "measurement"
      device_class: "temperature"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Temperatur Spreizung Soll"
      unique_id: "wolf.cha7.temperatur.spreizung.soll"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Soll-Spreizung"
      unit_of_measurement: "°C"
      state_class: "measurement"
      device_class: "temperature"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Temperatur Hysterese"
      unique_id: "wolf.cha7.temperatur.hysterese.hz"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Hysterese_Heizbetrieb"
      unit_of_measurement: "°C"
      state_class: "measurement"
      device_class: "temperature"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Leistung Heiz"
      unique_id: "wolf.cha7.leistung.heiz"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Heizleistung"
      unit_of_measurement: "kW"
      state_class: "measurement"
      device_class: "power"
      suggested_display_precision: 2
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Leistung Aufnahme"
      unique_id: "wolf.cha7.leistung.aufnahme"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Leistungsaufnahme_(WP___EHZ)"
      unit_of_measurement: "kW"
      state_class: "measurement"
      device_class: "power"
      suggested_display_precision: 2
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Leistung Heiz Sekundaer"
      unique_id: "wolf.cha7.leistung.heiz.sek"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Aktuelle_Sekundaerleistung"
      unit_of_measurement: "kW"
      state_class: "measurement"
      device_class: "power"
      suggested_display_precision: 2
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Leistung Vorgabe"
      unique_id: "wolf.cha7.leistung.vorgabe"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Aktuelle_Leistungsvorgabe_Verdichter"
      unit_of_measurement: "%"
      state_class: "measurement"
      device_class: "power_factor"
      suggested_display_precision: 0
      icon: "mdi:label-percent-outline"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Anzahl Verdichterstarts"
      unique_id: "wolf.cha7.anzahl.verdichterstarts"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Verdichterstarts"
      unit_of_measurement: "x"
      state_class: "total_increasing"
      suggested_display_precision: 0
      icon: "mdi:counter"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Anzahl Betriebstunden Netz"
      unique_id: "wolf.cha7.anzahl.betriebsstunden.netz"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Netzbetriebsstunden"
      unit_of_measurement: "h"
      state_class: "total_increasing"
      suggested_display_precision: 0
      icon: "mdi:update"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Anzahl Betriebsstunden Verdichter"
      unique_id: "wolf.cha7.anzahl.betriebstunden.verdichter"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Betriebsstunden_Verdichter"
      unit_of_measurement: "h"
      state_class: "total_increasing"
      suggested_display_precision: 0
      icon: "mdi:timelapse"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Anzahl Netzzuschaltungen"
      unique_id: "wolf.cha7.anzahl.netz.ein"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Anzahl_Netz_Ein"
      unit_of_measurement: "x"
      state_class: "total_increasing"
      suggested_display_precision: 0
      icon: "mdi:counter"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Anzahl Betriebsstunden Heizstab"
      unique_id: "wolf.cha7.anzahl.betriebsstunden.heizstab"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Betriebsstunden_E-Heizung"
      unit_of_measurement: "h"
      state_class: "total_increasing"
      suggested_display_precision: 0
      icon: "mdi:timelapse"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Heizkreis Durchfluss"
      unique_id: "wolf.cha7.heizkreis.durchfluss"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Heizkreisdurchfluss"
      unit_of_measurement: "L/min"
      state_class: "measurement"
      device_class: "volume_flow_rate"
      suggested_display_precision: 2
      icon: "mdi:waves-arrow-right"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
         - "wolfcha7"

    - name: "Frequenz Verdichter"
      unique_id: "wolf.cha7.frequenz.verdichter"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Verdichterfrequenz"
      unit_of_measurement: "Hz"
      state_class: "measurement"
      device_class: "frequency"
      suggested_display_precision: 0
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Drehzahl Zubringerpumpe"
      unique_id: "wolf.cha7.drehzahl.zubringerpumpe"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Drehzahl_ZHP"
      unit_of_measurement: "%"
      state_class: "measurement"
      suggested_display_precision: 0
      icon: "mdi:reload"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Drehzahl Ventilator"
      unique_id: "wolf.cha7.drehzahl.ventilator"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Drehzahl_Ventilator"
      unit_of_measurement: "U/min"
      state_class: "measurement"
      suggested_display_precision: 0
      icon: "mdi:reload"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Uhrzeit"
      unique_id: "wolf.cha7.time"
      state_topic: "Wolf/192.168.3.3/BM-2_0x35/Uhrzeit"
      icon: "mdi:clock-outline"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Druck Anlage"
      unique_id: "wolf.cha7.druck.anlage"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Anlagendruck"
      unit_of_measurement: "bar"
      state_class: "measurement"
      device_class: "pressure"
      suggested_display_precision: 2
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Druck Heissgas"
      unique_id: "wolf.cha7.druck.heissgas"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/P_Heissgas"
      unit_of_measurement: "bar"
      state_class: "measurement"
      device_class: "pressure"
      suggested_display_precision: 2
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Druck Sauggas"
      unique_id: "wolf.cha7.druck.sauggas"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/P_Sauggas"
      unit_of_measurement: "bar"
      state_class: "measurement"
      device_class: "pressure"
      suggested_display_precision: 2
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Energiemenge Heizung gesamt"
      unique_id: "wolf.cha7.energie.hz.total"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Energiemenge_HZ"
      unit_of_measurement: "kWh"
      state_class: "total_increasing"
      device_class: "energy"
      suggested_display_precision: 0
      icon: "mdi:heat-wave"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Heizkreis Anforderung ID"
      unique_id: "wolf.cha7.heizkreis.anforderung.id"
      state_topic: "Wolf/192.168.3.3/DHK_BM-2_0x35/Anforderung_Heizkreis/value"
      state_class: "measurement"
      icon: "mdi:state-machine"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Heizkreis Anforderung Text"
      unique_id: "wolf.cha7.heizkreis.anforderung.txt"
      state_topic: "Wolf/192.168.3.3/DHK_BM-2_0x35/Anforderung_Heizkreis/text"
      icon: "mdi:format-quote-open"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Heizkreis Status ID"
      unique_id: "wolf.cha7.heizkreis.status.id"
      state_topic: "Wolf/192.168.3.3/DHK_BM-2_0x35/Heizkreis_Status/value"
      state_class: "measurement"
      icon: "mdi:state-machine"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Heizkreis Status Text"
      unique_id: "wolf.cha7.heizkreis.status.txt"
      state_topic: "Wolf/192.168.3.3/DHK_BM-2_0x35/Heizkreis_Status/text"
      icon: "mdi:format-quote-open"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Heizgeraet Betriebart ID"
      unique_id: "wolf.cha7.heizgeraet.betriebsart.id"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Betriebsart_Heizgeraet/value"
      state_class: "measurement"
      icon: "mdi:state-machine"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Heizgeraet Betriebart Text"
      unique_id: "wolf.cha7.heizgeraet.betriebsart.txt"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Betriebsart_Heizgeraet/text"
      icon: "mdi:format-quote-open"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Status Heizstab ID"
      unique_id: "wolf.cha7.heizstab.status.id"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Status_E-Heizung/value"
      state_class: "measurement"
      icon: "mdi:state-machine"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Status Heizstab Text"
      unique_id: "wolf.cha7.heizstab.status.txt"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Status_E-Heizung/text"
      icon: "mdi:format-quote-open"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Status Verdichter ID"
      unique_id: "wolf.cha7.verdichter.status.id"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Verdichterstatus/value"
      state_class: "measurement"
      icon: "mdi:state-machine"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "Status Verdichter Text"
      unique_id: "wolf.cha7.verdichter.status.txt"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Verdichterstatus/text"
      icon: "mdi:format-quote-open"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "AZ TAZ aktuell"
      unique_id: "wolf.cha7.taz.heute"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/TAZ_aktueller_Tag"
      state_class: "measurement"
      icon: "mdi:multiplication"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "AZ TAZ gestern"
      unique_id: "wolf.cha7.taz.gestern"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/TAZ_Vortag"
      state_class: "measurement"
      icon: "mdi:multiplication"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "AZ MAZ Monat"
      unique_id: "wolf.cha7.maz"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/MAZ_aktueller_Monat"
      state_class: "measurement"
      icon: "mdi:multiplication"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "AZ JAZ aktuell"
      unique_id: "wolf.cha7.jaz.aktuell"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/JAZ_aktuelles_Jahr"
      state_class: "measurement"
      icon: "mdi:multiplication"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "AZ JAZ Vorjahr"
      unique_id: "wolf.cha7.jaz.vorjahr"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/JAZ_Vorjahr"
      state_class: "measurement"
      icon: "mdi:multiplication"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "AZ JAZ Vorvorjahr"
      unique_id: "wolf.cha7.jaz.vorvorjahr"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/JAZ_Vorvorjahr"
      state_class: "measurement"
      icon: "mdi:multiplication"
      suggested_display_precision: 1
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "kWh el. Tag aktuell"
      unique_id: "wolf.cha7.kwh.el.tag.aktuell"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Verbrauch_aktueller_Tag"
      unit_of_measurement: "kWh"
      state_class: "total"
      device_class: "energy"
      suggested_display_precision: 0
      icon: "mdi:transmission-tower"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"
    - name: "kWh th. Tag aktuell"
      unique_id: "wolf.cha7.kwh.th.tag.aktuell"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Erzeugte_Waermemenge_aktueller_Tag"
      unit_of_measurement: "kWh"
      state_class: "total"
      device_class: "energy"
      suggested_display_precision: 0
      icon: "mdi:radiator"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "kWh el. Tag gestern"
      unique_id: "wolf.cha7.kwh.el.tag.gestern"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Verbrauch_Vortag"
      unit_of_measurement: "kWh"
      state_class: "total"
      device_class: "energy"
      suggested_display_precision: 0
      icon: "mdi:transmission-tower"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"
    - name: "kWh th. Tag gestern"
      unique_id: "wolf.cha7.kwh.th.tag.gestern"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Erzeugte_Waermemenge_Vortag"
      unit_of_measurement: "kWh"
      state_class: "total"
      device_class: "energy"
      suggested_display_precision: 0
      icon: "mdi:radiator"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "kWh el. Monat"
      unique_id: "wolf.cha7.kwh.el.monat"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Verbrauch_aktueller_Monat"
      unit_of_measurement: "kWh"
      state_class: "total"
      device_class: "energy"
      suggested_display_precision: 0
      icon: "mdi:transmission-tower"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"
    - name: "kWh th. Monat"
      unique_id: "wolf.cha7.kwh.th.monat"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Erzeugte_Waermemenge_aktueller_Monat"
      unit_of_measurement: "kWh"
      state_class: "total"
      device_class: "energy"
      suggested_display_precision: 0
      icon: "mdi:radiator"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "kWh el. Jahr aktuell"
      unique_id: "wolf.cha7.kwh.el.jahr.aktuell"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Verbrauch_aktuelles_Jahr"
      unit_of_measurement: "kWh"
      state_class: "total"
      device_class: "energy"
      suggested_display_precision: 0
      icon: "mdi:transmission-tower"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"
    - name: "kWh th. Jahr aktuell"
      unique_id: "wolf.cha7.kwh.th.jahr.aktuell"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Erzeugte_Waermemenge_aktuelles_Jahr"
      unit_of_measurement: "kWh"
      state_class: "total"
      device_class: "energy"
      suggested_display_precision: 0
      icon: "mdi:radiator"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "kWh el. Vorjahr"
      unique_id: "wolf.cha7.kwh.el.vorjahr"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Verbrauch_Vorjahr"
      unit_of_measurement: "kWh"
      state_class: "total"
      device_class: "energy"
      suggested_display_precision: 0
      icon: "mdi:transmission-tower"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"
    - name: "kWh th. Vorjahr"
      unique_id: "wolf.cha7.kwh.th.vorjahr"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Erzeugte_Waermemenge_Vorjahr"
      unit_of_measurement: "kWh"
      state_class: "total"
      device_class: "energy"
      suggested_display_precision: 0
      icon: "mdi:radiator"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

    - name: "kWh el. Vorvorjahr"
      unique_id: "wolf.cha7.kwh.el.vorvorjahr"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Verbrauch_Vorvorjahr"
      unit_of_measurement: "kWh"
      state_class: "total"
      device_class: "energy"
      suggested_display_precision: 0
      icon: "mdi:transmission-tower"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"
    - name: "kWh th. Vorvorjahr"
      unique_id: "wolf.cha7.kwh.th.vorvorjahr"
      state_topic: "Wolf/192.168.3.3/CHA_0x8/Erzeugte_Waermemenge_Vorvorjahr"
      unit_of_measurement: "kWh"
      state_class: "total"
      device_class: "energy"
      suggested_display_precision: 0
      icon: "mdi:radiator"
      device:
        name: "Wolf CHA7"
        manufacturer: "Wolf"
        model: "CHA7"
        identifiers:
          - "wolfcha7"

Ergibt dann:

This morning I had the first TSSD with my new reboot automation. It worked well! :-)

The curl command - and so the automation - ends in an error messageq because the dumb ism module is not responding to the reboot HTTP request but directly shutting down. But that is no problem at all.

As my warm water circulation did not start this morning because of the TSSD, I might switch to the approach of taking the Uhrzeit/time as trigger for being able to react faster. ;-)

... ich hatte meinen ersten überhaupt auch gestern. Warum auch immer, war nicht mal 1 Stunde nach einem gelegentlich vorkommenden Connection reset und autom. ism7mqtt Serviceneustart. Ich monitore ein paar Topics in einem Smarthome Eigengebräu auf Java Basis und nach 90 Sekunden ohne Update wird neu gestartet, das ist ja schmerzlos. Der ism7mqtt Service startet dann auch automatisch neu wegen Verbindungsverlust. Daher für die, die's ggf. interessiert oder nützt:

  static void rebootISM7() {
    try {
      String urlParameters = "rebo=init&name=reboKickoff";
      URL url = new URL("http://IP/protect/reboot.htm");
      HttpURLConnection conn = (HttpURLConnection) url.openConnection();
      conn.setRequestMethod("POST");
      conn.setDoOutput(true);
      conn.setRequestProperty("Authorization",
        "Basic " + new String(Base64.getEncoder().encode("admin:PASSWORT".getBytes())));
      conn.setRequestProperty("Content-Length", Integer.toString(urlParameters.length()));
      conn.connect();
      OutputStreamWriter writer = new OutputStreamWriter(conn.getOutputStream());
      writer.write(urlParameters);
      writer.flush();
    } catch (Exception e) {
      log.error("Could not reboot ISM7", e);
    }
  }

... ich hatte meinen ersten überhaupt auch gestern. Warum auch immer

Wir haben dich angesteckt. ;-p

My workaround with automatically restarting ism module in case od f a TSSD works perfectly. I hat a around 5 TSSD last week and all were discovered and healed by a reboot. Today I changed the discovery from parameter Ablufttemperatur to parameter 220032/Uhrzeit for being able to react faster.

I'm done with this topic for now. I think the problem is not fixable in ism7mqtt and this issue can be closed for now. If someone has new insides we can reopen it.

In version fw 3 the url for reboot is http://IP/reboot.htm, the payload for POST is the same

zivillian / ism7mqtt

ISM module stops sending data although ism7mqtt is still alive #115