Niko Home Control

Mherwege · July 9, 2020, 5:41am

@wars I looked at a few old log files again. It is unlikely I can get the sensor values in OH. The only thing you would be able to get is the actions triggered on thresholds in the NHC controller.

wars · July 9, 2020, 7:12am

thx for checking! I will try some stuff with actions and conditions.

I’m still planning the switch to NHCII, but I hoped with the introduction of the ‘hobby api’, we could read everything via api or mqtt. But that doesn’t seem to be the case?

extric99 · August 10, 2020, 7:00pm

Just out of interest why would you switch to homecontrol II? What would be the benefits of this, are there things you can not achieve with openhab and the binding/rules/plugins?

wars · August 11, 2020, 7:00am

I don’t think there’s a real benefit in the OpenHAB point of view. But NHC I will not receive any feature updates anymore and other build integrations will probably be expanded in the future for NHC II. I’m also interested in the hobby API, so I would like to play with that.
I even have the first generation of controller, so no connected controller, but it works.

fcela · November 19, 2022, 10:33am

Hi Mark,
You have done excellent work here and I have managed quite nice integration using your NHC I binding → Openhab → Google Home (GA) in OH 3.2.0 for my NHC I installation (using NHC IP module).

It works nicely, usually when creating binding from scratch it is even quite responsive (approx. 1 sec).
Unfortunately, sometimes, and it seems it is even worse over time, the responsiveness of the items is really awfull. It doesn’t seem the issue is at GA side, as you can see in the logs below.

NHC binding switched to the debug mode for the purpose:
openhab> list -s | grep niko
436 x Active x 80 x 3.2.0 x org.openhab.binding.nikohomecontrol
openhab> log:set DEBUG org.openhab.binding.nikohomecontrol

I can share my logs as follows:
Item changed using GA, reported in the events.log:
2022-11-19 11:07:29.392 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘svetlostrophostovska_Power’ received command OFF
2022-11-19 11:07:29.393 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘svetlostrophostovska_Power’ predicted to become OFF
2022-11-19 11:07:29.394 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘svetlostrophostovska_Power’ changed from ON to OFF

response in the binding after 21 seconds, openhab.log:

2022-11-19 11:07:50.115 [DEBUG] [handler.NikoHomeControlActionHandler] - handle command OFF for nikohomecontrol:onOff:440e003a2369:27:switch
2022-11-19 11:07:50.116 [DEBUG] [ol.internal.protocol.nhc1.NhcAction1] - execute action Off of type RELAY for 27
2022-11-19 11:07:50.116 [DEBUG] [l.nhc1.NikoHomeControlCommunication1] - send json {“id”:27,“value1”:0,“value2”:0,“value3”:0,“mode”:0,“overrule”:0,“overruletime”:“”,“cmd”:“executeactions”,“event”:“”}
2022-11-19 11:07:50.117 [DEBUG] [l.nhc1.NikoHomeControlCommunication1] - received json {“cmd”:“executeactions”, “data”:{“error”:0}}
2022-11-19 11:07:50.117 [DEBUG] [l.nhc1.NikoHomeControlCommunication1] - execute action success

another try:

2022-11-19 11:09:05.325 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘svetlostrophostovska_Power’ received command ON
2022-11-19 11:09:05.326 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘svetlostrophostovska_Power’ predicted to become ON
2022-11-19 11:09:05.327 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘svetlostrophostovska_Power’ changed from OFF to ON

the response in the binding after 1 minute:

2022-11-19 11:10:06.059 [DEBUG] [handler.NikoHomeControlActionHandler] - handle command ON for nikohomecontrol:onOff:440e003a2369:27:switch
2022-11-19 11:10:06.059 [DEBUG] [ol.internal.protocol.nhc1.NhcAction1] - execute action On of type RELAY for 27
2022-11-19 11:10:06.059 [DEBUG] [l.nhc1.NikoHomeControlCommunication1] - send json {“id”:27,“value1”:100,“value2”:0,“value3”:0,“mode”:0,“overrule”:0,“overruletime”:“”,“cmd”:“executeactions”,“event”:“”}
2022-11-19 11:10:06.061 [DEBUG] [l.nhc1.NikoHomeControlCommunication1] - received json {“cmd”:“executeactions”, “data”:{“error”:0}}
2022-11-19 11:10:06.061 [DEBUG] [l.nhc1.NikoHomeControlCommunication1] - execute action success

Please what could be the issue?
I am using the integration for managing the garage gate and main gate as well and response in minutes is quite frustrating. I can provide more logs if necessary.

Thanks for any hint regarding this and your work and support as well.

fcela · November 19, 2022, 12:08pm

I have tried the following to reset the long delay between openhab and the binding:

clean cache using openhab-cli
restart opehab
stop / start binding using console
install extended beta version of the binding + MQTT dependency (NHC binding v 3.3.0):
openhab> list -s | grep niko
276 x Active x 80 x 3.3.0.202204221547 x org.openhab.binding.nikohomecontrol

and nothing helped till now.

UPDATE:
Finally restart of the whole system helped.
What does it mean? Lack of resources?

Thanks once more.

Mherwege · November 19, 2022, 4:38pm

I would indeed think there is some lack of resources. Looking at the logs, it looks like the binding does process quickly, but it takes a lot of time before the event even triggers the binding to be called. Look at the logs for what else is happening at that time. Monitor cpu load and heap usage. You could use the systeminfo binding for that.

fcela · November 19, 2022, 6:29pm

So I couldn’t see any lack of CPU nor MEMORY resource, and after several hours, the delay is back:

2022-11-19 19:22:51.209 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘svetlostrophostovska_Power’ received command OFF
2022-11-19 19:22:51.210 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘svetlostrophostovska_Power’ predicted to become OFF
2022-11-19 19:22:51.211 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘svetlostrophostovska_Power’ changed from ON to OFF

delay 12 sec:

2022-11-19 19:23:03.818 [DEBUG] [handler.NikoHomeControlActionHandler] - handle command OFF for nikohomecontrol:onOff:440e003a2369:27:switch
2022-11-19 19:23:03.819 [DEBUG] [ol.internal.protocol.nhc1.NhcAction1] - execute action Off of type RELAY for 27
2022-11-19 19:23:03.819 [DEBUG] [l.nhc1.NikoHomeControlCommunication1] - send json {“id”:27,“value1”:0,“cmd”:“executeactions”}
2022-11-19 19:23:03.820 [DEBUG] [l.nhc1.NikoHomeControlCommunication1] - execute action success
2022-11-19 19:23:03.945 [DEBUG] [l.nhc1.NikoHomeControlCommunication1] - event execute action 27 with state 0
2022-11-19 19:23:03.945 [DEBUG] [econtrol.internal.protocol.NhcAction] - update channel state for 27 with 0

resources:
LOAD
cpu
MEM

Just to note, this is not an standalone OPENHAB deployment, there is NAS service and another docker image runing in the background as well. But definitelly not an resource issue I think.

and OPENHAB is using the most of the VIRT MEM:

Any hint? Thanks.

fcela · November 19, 2022, 7:20pm

I do not think i did anything, but response is ok now again :-\ :

2022-11-19 20:17:32.514 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘svetlostrophostovska_Power’ received command ON
2022-11-19 20:17:32.515 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘svetlostrophostovska_Power’ predicted to become ON
2022-11-19 20:17:32.516 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘svetlostrophostovska_Power’ changed from OFF to ON

response:

2022-11-19 20:17:32.519 [DEBUG] [handler.NikoHomeControlActionHandler] - handle command ON for nikohomecontrol:onOff:440e003a2369:27:switch
2022-11-19 20:17:32.520 [DEBUG] [ol.internal.protocol.nhc1.NhcAction1] - execute action On of type RELAY for 27
2022-11-19 20:17:32.520 [DEBUG] [l.nhc1.NikoHomeControlCommunication1] - send json {“id”:27,“value1”:100,“cmd”:“executeactions”}
2022-11-19 20:17:32.520 [DEBUG] [l.nhc1.NikoHomeControlCommunication1] - execute action success
2022-11-19 20:17:32.605 [DEBUG] [l.nhc1.NikoHomeControlCommunication1] - event execute action 27 with state 100
2022-11-19 20:17:32.605 [DEBUG] [econtrol.internal.protocol.NhcAction] - update channel state for 27 with 100

very strange, i do not understand.

Mherwege · November 20, 2022, 3:56pm

What other bindings do you have running? Sending the command to NHC is done from a thread started from the thinghander threadpool. The default size of the threadpool is 5. That should not be a problem (things may get queued for a moment), but if some binding holds on to a number of threads for a very long time, it may temporarily block commands going through.
I think it is possible to increase the threadpool size by putting:
threadpool:ThingHandler=10
where 10 is the new threadpool size in the services.cfg file in the conf/services folder. To see if this is the cause, one would have to dump the java state and analyze that. But I am not an expert on this.
Also, I am not running NHCI anymore, so my abilities to debug are limited.

fcela · November 20, 2022, 6:08pm

Hi Mark,

these are my bindings right now:

so 5 bindings, but 93 Things in total.

I am assuming you are talking about:
/etc/openhab/services/runtime.cfg (not services.cfg)

My threadpool size is 5 now:
openhab> config:list
----------------------------------------------------------------
Pid: org.openhab.threadpool
BundleLocation: null
Properties:

discovery = 5*
safeCall = 10*
service.pid = org.openhab.threadpool*
thingHandler = 5*
----------------------------------------------------------------

I added the following at the end of runtime.cfg:
org.openhab.threadpool:ThingHandler=10

→ changed to 10 now.

Thank you very much, will let you know.

fcela · November 25, 2022, 12:58pm

It seems it is working without a hassle till now
Thanks Mark again for “Threadpool” hint.

fcela · December 16, 2022, 8:24am

Unfortunatelly the issue of late responding is back. I have changed nothing, the " ThingHandler=10" .
Very strange. I have doubled RAM ( 8 → 16) just to be ready for future requirements.
Anyway it is strange. The only thing that helps is OH restart.
Should I increase the “thingHandler” settings even further?
Thanks

fcela · December 16, 2022, 8:46am

Sorry, something has changed, load is above average:

Using top I have found nothing, CPU usage below 5%:

But If I remember correctly, i have installed Flash2Ram for my OMV instance 2 days before, as I am running from SSD NVME high performance disk:

Thanks once more.

extric99 · December 20, 2022, 10:17am

Hello @Mherwege

I updated my OpenHab instance from 2.5 to 3.4 as the SD card in my rPi died so moved everything to a virtual machine on Proxmox.

Is it possible that the behaviour for blinds has changed and that state of the blind is not reported anymore? In the logs I only see the value changing from 0 to 100 or 100 to 0 when pressing up or down and never the value of state when the blind was stopped. In the below example the blind was open and i closed it on third by clicking stop on the openhab app. The value of the blind is set directly from when pressing up or down.

I also have issues with homekit now where the blind stops responding if if I try to close a certain %.
This was working fine on Openhab 2.5
FYI I am using a NHC 1 instance.

Thanks
C

Mherwege · December 20, 2022, 10:36am

@extric99 The change is not intentional, but there have been a lot of changes in the binding. I may have inadvertently introduced a bug with NHC I. Few people are still on NHC I, so feedback is slow.
Can you switch on TRACE logging and see if some extra info appears?

extric99 · December 20, 2022, 10:53am

See attached
It would appear that the state is visible with TRACE on

extric99 · December 20, 2022, 1:11pm

I think there might be other issues

Using the niko buttons
Closing the blind a little updates the state from 100 to 9 while I would expect the opposite.

Opening the blind completely changed the state from 9 to 0 (while we started at 100)

Using the openhab app lists some errors

wars · December 20, 2022, 4:57pm

I’m also still on nhc I and did not yet update to 3.4. But I only use simple actions for lights and scenes. So hopefully no issues

Mherwege · December 20, 2022, 7:27pm

@wars What version are you on? @extric99 is on 2.5, which is pretty old.
@extric99 Can you remove and recreate your blinds? Also check if there is an invert flag on the rollershutter direction. I remember there was big debate about the right sense of movement for blinds. In the end, I did put in an invert flag to satisfy everyone.