[SOLVED] Binding - Nilan Problem

Do you have any kind of heating added to your Nilan Comfort 300LR ? I have thought about it, but I sure would like to know from others with experience before I add it.

@Kim_Andersen

No, but I think I want to add a water based heater :slight_smile:

@rossko57

I have added timeBetweenTransactionsMillis set to 150 to my tcp bridge, lets see how this works :slight_smile:

Thanks for your help :slight_smile:

@Nanna_Agesen Please let me know if you get the heater added. I sure would like to know this Nilan comfort 300LR act with an heater in the cold periods/winter.

I will :slight_smile:

1 Like

@rossko57

The Device failed 3 hours later, but this time it recovered by itself after 4 hours (During the night) -without restart of the gateway.

I haven’t seen that before, and maybe it was a one timer?

Perhaps it doesn’t often get the time to do that, before intervention. I wonder if it was a 256 minute timeout? Not something you can live with, anyway.

I suppose the next step is change from TCP connect/disconnect, to holding a connection open.
That’d be reconnectAfterMillis=60000 or similar in the tcp bridge.

To catch what is really going on is likely to need ethernet monitoring with wireshark or suchlike. That won’t necessarily help, if it’s the gateway messing up, as presumably that’s beyond your control. So trying to find a workaround is a plan.

1 Like

Ill add the reconnectAfterMillis=60000 to my bridge and test.

What do you think about setting up a minimal poll to the affected device
Just polling the Nilan Gateway for 1 or 2 registers?

I’m not sure it’ll prove much. The modbus traffic is pretty simplistic - “send me some registers for this slave”. A simple or complex OH config looks much the same in that respect, but we can control how often the traffic comes.
If there were something wrong with your thing config like bad length, it would show up at each poll.

There’s going to be something random at work here, like mishandling a split TCP packet or something. We’d better establish what version binding you have.

Just a wild guess…
Could the error occure due to polling adresses which is not supported by this specific Nilan system?

When looking through Nanna´s original config, I wonder how come there isn´t any error when the polling goes online. According to the Nilan CTS602 modbus documentation, some of the adresses in Nanna´s config is not for use with the Nilan Comfort 300LR system.
I´d get errors with some of the same registers in Nanna´s config. But I´d get the error when I saved the things file. The only differences is, I´m using serial connection. Beside that, the systems are identical.

@Kim_Andersen That was also my intention to investigate with a minimal configuration - I’ll make a new configuration with a few known working registers.

The CTS602 board is a universal board for many of Nilan’s products, but you set at model number - maybe this locks some of the functions I am polling.

The configuration you posted Kim, are they all supported by the Comfort 300?

@rossko57

Do you mean version of the Modbus binding?

openHAB 2.5.0 Build #1484

237 │ Active   │  80 │ 1.14.0.201812300308    │ org.openhab.action.mail
238 │ Active   │  80 │ 2.5.0.201812302011     │ org.openhab.binding.exec
239 │ Active   │  80 │ 1.14.0.201812300308    │ org.openhab.binding.http
240 │ Active   │  80 │ 2.5.0.201812302011     │ org.openhab.binding.ipp
241 │ Active   │  80 │ 2.5.0.201812302011     │ org.openhab.binding.modbus
242 │ Active   │  80 │ 1.14.0.201812300308    │ org.openhab.binding.mqtt
243 │ Active   │  80 │ 1.14.0.201812300308    │ org.openhab.binding.mqttitude
244 │ Active   │  80 │ 2.5.0.201812302011     │ org.openhab.binding.network
245 │ Active   │  80 │ 1.14.0.201812300308    │ org.openhab.binding.plex
246 │ Active   │  80 │ 2.5.0.201812302011     │ org.openhab.binding.samsungtv
247 │ Active   │  80 │ 2.5.0.201812302011     │ org.openhab.binding.zwave
248 │ Active   │  80 │ 2.5.0.201812302011     │ org.openhab.core.compat1x
249 │ Active   │  80 │ 2.5.0.201812302011     │ org.openhab.io.homekit
250 │ Active   │  80 │ 2.5.0.201812302011     │ org.openhab.io.openhabcloud
251 │ Active   │  80 │ 2.5.0.201812302011     │ org.openhab.io.rest.docs
252 │ Active   │  80 │ 2.5.0.201812302011     │ org.openhab.io.transport.modbus
253 │ Active   │  80 │ 1.14.0.201812300308    │ org.openhab.io.transport.mqtt
254 │ Active   │  80 │ 1.14.0.201812300308    │ org.openhab.persistence.influxdb
255 │ Active   │  80 │ 1.14.0.201812300308    │ org.openhab.persistence.rrd4j
256 │ Resolved │  75 │ 2.5.0.201812302011     │ org.openhab.ui.basicui
257 │ Active   │  80 │ 2.5.0.201812302011     │ org.openhab.ui.habmin
258 │ Active   │  80 │ 2.5.0.201812302011     │ org.openhab.ui.habpanel
259 │ Resolved │  75 │ 2.5.0.201812302011     │ org.openhab.ui.paperui
260 │ Active   │  80 │ 2.5.0.201812302011     │ org.openhab.voice.voicerss

I know the CTS 602 interface is used in many of Nilans products. But when I did the modbus setup I discovered some adresses which was given errors, even though the modbus docs says they are suppose to be Comfort compatible. Second, others of the adresses is for use if you add the hearter features, which means, they´ll only be active when you have made the needed changes in the service menu.

The configuration I posted are adresses not given errors :slight_smile: And mainly those adresses which according to the modbus doc is supported by the Comfort system. Still some of them are reporting wrong values or no values. thats the cleanup part I´m still working on as mentiond earlier. You could give them a try and see what happens. Our systems should be identical, only differences may be the firmware. I can´t recall which version my system is running, and reading from the modbus adress, it doesn´t make much sense. It says:

@rossko57

I added reconnectAfterMillis=60000 to my bridge 4 days ago, and I haven’t had any failure since - Hope that resolves my problem, I’ll wait a few days longer before I address this as the solution :slight_smile:

Best Nanna

Your binding version is reasonably up to date, I do not think any TCP changes incorporated since Dec 18.

I suppose we shall have put it down to gateway getting in some knot when disconnect/reconnect TCP frequently.
What kind of gateway is it? may help others another time.

I have been testing with 2 different gateways, the Moxa 3170 MGate and Planet IMG110T.

Before adding reconnectAfterMillis=60000, I saw this error on both gateways.
I can’t say if the error was more frequent on one or the other.

Feedback on this post.

My Nilan have been running for 1 week without failing - I removed all test parameters and the only difference between the failing and working configuration is: reconnectAfterMillis=60000

I’ll wait a week or so before mark this SOLVED.

Thanks for all your help - really appreciate it :slight_smile:

3 Likes

Thanks @rossko57

I’ll consider the issue with my Nilan HVAC as solved, adding the reconnectAfterMillis=60000 to the bridge - made it stable.

Best Nanna

Odd that it should affect only one of several gateways, maybe that’s down to how the poller things happen to be configured.