Niko Home Control

@Mherwege : i’ve installed the 2.1 version. I can add the blinds as item/thing and it will show up in the UI, but it cannot be controlled. I’ve also executed commands to the blinds via the standard NHC buttons and app to show the actions in the log. For testing purposes i only added one blind as a thing, the rest do show up in the inbox.

You will see in the logs that i added and removed the blind a few times, i wanted to see the difference of having OH add it trough ‘simple mode’ vs creating the item/thing manually.

Find the log here : http://pastebin.com/684wH5Jt

1 Like

@Denethor thank you for the log. A quick browse showed commands from the switches to fully open and fully closed. Is this what you did? Did you try starting and or stopping when opening/closing?
I would still like to get a wireshark capture when controlling the blind from the Niko app. I don’t know yet how the app sends commands, especially up/down and start/stop. At the moment I can only assume it sends a percentage value, but I am not sure. I will see if I can implement the percentage value over the next week or so.

@Denethor I had another look at this. The binding currently does not do anything with UP/DOWN or STOP commands from OH. And that is what you have used in testing from OH. It does pass through the commands if you give it a percent value. My assumption is that the command then passed to NHC has the same structure as a dimmer command, but I can be very wrong on this. Can you try this? If this does not work, I would expect an error being returned from NHC in the log file. Also, when you control the blinds from the NHC side, is their state correctly reflected in OH? I would expect this to be the case.
I do expect NHC has some specific treatment for UP/DOWN and STOP and would like to program that. But as I do not have blinds, I cannot figure out what these commands are. I do require a wireshark trace.

Hello,

With an old version of android app, when you create a debug report, it contains all commands send to controller.
Here is the NHC log when I use my rollershutter :

to open :
SOCKET-OUT: {“cmd”:“executeactions”,“value1”:253,“id”:52,“endValue”:100}
SOCKET-IN: {“cmd”:“executeactions”, “data”:{“error”:100}}

to close :
SOCKET-OUT: {“cmd”:“executeactions”,“startValue”:100,“value1”:254,“id”:52}
SOCKET-IN: {“cmd”:“executeactions”, “data”:{“error”:100}}

to stop:
SOCKET-OUT: {“cmd”:“executeactions”,“startValue”:91,“value1”:255,“id”:52}
SOCKET-IN: {“cmd”:“executeactions”, “data”:{“error”:100}}

listactions :
{“cmd”:“listactions”,“data”:[ {“id”:52,“name”:“Volet”,“type”:4,“location”:6,“value1”:100,“value2”:27,“value3”:27},{“id”:53,“name”:“Volet”,“type”:4,“location”:8,“value1”:0,“value2”:27,“value3”:27}]}

ID 52 is open, ID 53 is close.

the complete log here blindlog.json (17.3 KB)
rename .json to .txt

regards.
Benoit

@Benoit_Krings Many thanks for this info. Sorry for the late reply. I have not had time to work on this the last few weeks.
I have used your info to implement an initial version of rollershutters in the binding.
@Denethor I noticed there is a difference in action type between the log from you and @Benoit_Krings. I suspect this may be because your smartphone action is attached to different physical button setups. You can define the action in NHC either with a specific motor control or a double push button. I don’t know which one is which. I now implemented the same logic for type 5 (as with @Denethor) and type 4 (as with @Benoit_Krings).
If you have a chance, can you test this new version? I would like to have a full debug log and clear comments on the action taken and position of the rollershutter/blind at each point in the sequence. Are you able to stop the rollershutter when it is opening or closing?
I have put the binding in the same dropbox folder as always.

Hi Mark,
was trying using the last .jar and it is almost done as described below:

down - works as down (this one works as expected)
stop - works as UP
up - works as STOP
exact value (percentage) - not working (I thins this one was not implemented yet)

Great work, just exchange those two actions :slight_smile:
BR.
Marek.

Hi Mark,

one more problem have been found, not related to the latest version of the .jar.
All the things (except the bridge) are unitialized, error message:
Status: UNINITIALIZED - HANDLER_INITIALIZING_ERROR java.math.BigDecimal cannot be cast to java.lang.Integer

BR.
Marek.

Marek, thanks for testing. I will post when I have been able to update the binding. Any chance you could get me a full debug log for the error you see above?

I loaded a new version with stop and up switched. Please test. I did implement percent, but assumed some commands to the controller that may not work. I need more debug info.

For all that try out rollershutters or blinds, please do a full debug log with everything you do and send post it. I don’t feel like this is perfect just yet, although it looks like it works for @fcela.

Hi Mark,

unfortunately it works as before, no change. The new version of the binding has been uploaded and the openhab service restarted:

.
Don`t know what could be the source of the problem.
I will post the full debug log later, i am quite busy now, sorry.
Thank you very much.
Marek.

Hi Mark,
i could not get any more details when switching org.openhab.binding.nikohomecontrol into DEBUG level.

I am attaching the karaf console log as screenshot, where you can find more details. Is it possible to redirect the karaf console output to file anyhow?

If you need more details, just let me now.
Thanks.
Marek.

Hi Mark,
please find the debug log for up and down (rollershutters ) from karaf console:

I had to remove and add the item first, it was unitialized before (problem reported in the previous post)

BR.
Marek

@fcela What version of openHAB are you running? When did the error appear? You stated before you were able to make the rollershutters work (although inverted). That is unlikely when the handlers did not get initialized, as in this error. So I suspect that error was not there before. Any other strange behaviour you see with other binding?
Also, you are not running the latest version of the binding, but still the old one. Look at the exception. It shows a binding version from March 22nd, while the latest one I uploaded is from March 27th. Here is the link again. It is that one that has the rollershutter direction inverted.
The logging and exceptions should be in the openhab.log file, see here. Location is dependent on your installation type. That doc page also explains how to turn on debug logging. Best is to turn on debug logging and just extract the Niko Home Control pieces from the openhab.log file.

[EDIT] I was typing while you were. So the error is gone when you add the items back in. This may because changes in the default naming of the things and items I did earlier. Keep an eye out for the error appearing again. Can you check again what version of the binding you are running (in the Karaf console, type bundle:list and look for the Niko binding).

Hi Mark,
the bundles screenshot:


I will try to replace NHC binding later, i was sure I have the last one.
Thanks.
Marek.

@fcela bundle:unistall 186 and bundle:restart 187 in the karaf console should do the trick.

Hi Mark,
up and down working as expected, thank you very much.
I would like to report the following:
Unfortunately all the things are still uninitialized even after restarting the openhab/server.
I have to remove/readd all of them :frowning:
Do you need any debug log yet?
The typing of the percentage value is not working as well.

Thank you once more.
Marek.

@fcela Hi Marek,
Thank you for the positive note on rollershutters up and down now working. I am not surprised the percentage value is not working. I would like to see more wireshark logs using the rollershutters from the app. If there is some direct method in there, I can implement it, otherwise I may have to go for some woraround (using up and down combined with stop after some time). Again, ideally I would have rollershutters myself. That would make it easier.
I full debug log on the initialization problem would still be helpful. I see the error in your screenshot, but do not have the same error myself. Things get initialized properly. I have noticed initialization may take a while. So in a few cases I saw it stuck initializing but getting initialized somewhat later. However, none of this was with the error you see. Also, what build of OH2 are you running? Wondering if there is something else in some build impacting this.
Again, thank you for testing.
Mark

Hi Mark,
the version in the meantime i will get the full debug log:

BR.
Marek.

@fcela I may have found the reason for the errors you were seeing. While it was working in my live environment, I now saw similar error in my development IDE. After some guidance from the reviewer on my PR, I think I may have solved this. Can you try the new version I have uploaded.
Beyond this, there are quite a few changes to improve code quality. It should not impact functionality, but I would appreciate if you let me know if anything is broken.

Hi Mark,
i have replaced the last version of the binding and restarted the service.
I don’t know why all the things remain unitialized after then although I could see the items online in the event.log (check https://www.dropbox.com/s/h3xbk0frigzk3a5/events.log?dl=0). I have tried to refresh the web gui several times, nothing has changed

After then I removed one item and readd the one again. All the items are online now, don’t understand what could happened.
Maybe I had to wait i little bit more, really don’t now.
Anyway, all the things are online.
Thank you very much.