The [WARN ] [ore.io.rest.auth.internal.AuthFilter] - Unauthorized API request: Error while processing JWT token error and Yes I checked the /var/log/openhab/events.log, I have now updated my first post accordingly, Thanks.
When I had this strange behaviour my password was weak.
Now when I have everything secured I se this error once in a time. This means that someone is trying to get into my system, but has no access.
I am reopening this old thread as apparently this MQTT issue seems to be the culprit of random lights and Sonos speaker going on at 100 % at random times, at least in our installation.
I’m not using MQTT explicitly, but the Niko Home Control binding is.
I think my Niko Home Control hobby API token expired, resulting in MQTT disconnect events. A couple seconds later almost all Items get 100% commands: lights, blinds and a Sonos speaker.
Do you have any ports forwarded on your router? First thing would be to close these and see if it still happens.
How did you do the fresh install? Copy the SD? Or install OH again and just copy over the configuration?
I used to have 1 port forwarded but I did not yet reinstall the nginx reverse proxy on my Raspberry Pi. I however have fail2ban installed and have a jail for sshd.
It was a brand new openHABian install on a new microSD card. I did not use any backup, I rather picked some parts of my old configuration.
By the way, here’s another similar event from tonight:
2023-03-12 01:26:12.478 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Volume' received command 100
2023-03-12 01:26:12.484 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'SYMFONISK_Bookshelf_Kitchen_Volume' predicted to become 100
2023-03-12 01:26:12.500 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Volume' changed from 56 to 100
2023-03-12 01:26:15.002 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Media_Control' received command PLAY
2023-03-12 01:26:15.005 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'SYMFONISK_Bookshelf_Kitchen_Media_Control' predicted to become PLAY
2023-03-12 01:26:15.017 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Media_Control' changed from PAUSE to PLAY
2023-03-12 01:26:15.096 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Current_Track' changed from VRT Klara Continuo to VRT Klara Continuo - ZPSTR_CONNECTING
2023-03-12 01:26:15.319 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Current_Track' changed from VRT Klara Continuo - ZPSTR_CONNECTING to VRT Klara Continuo - ZPSTR_BUFFERING
2023-03-12 01:26:17.586 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Current_Track' changed from VRT Klara Continuo - ZPSTR_BUFFERING to VRT Klara Continuo
2023-03-12 01:26:18.549 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Current_Track' changed from VRT Klara Continuo to VRT Klara Continuo - Johann Sebastian Bach
2023-03-12 01:26:22.623 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Current_Track' changed from VRT Klara Continuo - Johann Sebastian Bach to VRT Klara Continuo - Concerto in c voor 2 piano's, strijkers en b.c. BWV1060
2023-03-12 01:26:42.541 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Current_Track' changed from VRT Klara Continuo - Concerto in c voor 2 piano's, strijkers en b.c. BWV1060 to VRT Klara Continuo - David Fray (piano) Emmanuel Christien (piano) Strijkers van het
2023-03-12 01:27:02.594 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Current_Track' changed from VRT Klara Continuo - David Fray (piano) Emmanuel Christien (piano) Strijkers van het to VRT Klara Continuo - Johann Sebastian Bach
2023-03-12 01:27:23.606 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Current_Track' changed from VRT Klara Continuo - Johann Sebastian Bach to VRT Klara Continuo - Concerto in c voor 2 piano's, strijkers en b.c. BWV1060
The only events reported in. syslog are state updates being pushed to InfluxDB at the same time of the events reported above.
Maybe there’s an issue with tne controls of the Sonos/Symfonisk speaker due to humidity in the kitchen?
always during night and never happens during the day ?
Volume changes and control changes ( play, next, previous ) ?
Aren’t that too many coincidences ?
The only port you opened is a redirect to your nginx reverse proxy ?
Did you check the nginx log files for entries in access log as well as in error log file ?
The reverse proxy asks for a password ?
This does not always happen at night. As a matter of fact, it just happened again a couple minutes ago.
And… now I think I know where the problem might originate from, since the blinds that were lowered out of the blue are managed by Niko Home Control binding. It’s either the Niko Home Control binding or somebody is trying to connect to our NHC installation.
Here’s a log of the most recent incident (with my updates on the Sonos volume control):
2023-03-12 18:39:11.856 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Rolluik_1KN_Rollershutter' received command DOWN
2023-03-12 18:39:11.860 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Rolluik_1KN_Rollershutter' predicted to become DOWN
2023-03-12 18:39:11.876 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Rolluik_1KN_Rollershutter' changed from 0 to 100
2023-03-12 18:39:12.076 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Rolluik_1KN_Rollershutter' changed from 100 to 0
2023-03-12 18:39:13.304 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Rolluik_1KN_Rollershutter' received command DOWN
2023-03-12 18:39:13.306 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Rolluik_1KN_Rollershutter' predicted to become DOWN
2023-03-12 18:39:13.310 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Rolluik_1KN_Rollershutter' changed from 0 to 100
2023-03-12 18:39:13.508 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Rolluik_1KN_Rollershutter' changed from 100 to 0
2023-03-12 18:39:20.174 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Volume' received command 100
2023-03-12 18:39:20.176 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'SYMFONISK_Bookshelf_Kitchen_Volume' predicted to become 100
2023-03-12 18:39:20.185 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Volume' changed from 34 to 100
2023-03-12 18:39:21.954 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Current_Track' changed from VRT Klara Continuo - Anima Eterna Brugge o.l.v. Jos van Immerseel to VRT Klara Continuo - Joseph Haydn
2023-03-12 18:39:33.505 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Rolluik_1KN_Rollershutter' changed from 0 to 100
2023-03-12 18:39:42.001 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Current_Track' changed from VRT Klara Continuo - Joseph Haydn to VRT Klara Continuo - Symfonie nr.45 in fis Abschied: 2.Adagio
2023-03-12 18:40:02.958 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Current_Track' changed from VRT Klara Continuo - Symfonie nr.45 in fis Abschied: 2.Adagio to VRT Klara Continuo - Anima Eterna Brugge o.l.v. Jos van Immerseel
2023-03-12 18:40:19.205 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Volume' changed from 100 to 28
2023-03-12 18:40:23.005 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Current_Track' changed from VRT Klara Continuo - Anima Eterna Brugge o.l.v. Jos van Immerseel to VRT Klara Continuo - Joseph Haydn
2023-03-12 18:40:42.956 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SYMFONISK_Bookshelf_Kitchen_Current_Track' changed from VRT Klara Continuo - Joseph Haydn to VRT Klara Continuo - Symfonie nr.45 in fis Abschied: 2.Adagio
I think I should update the access credentials to the NHC Hobby API.
in case you use openHAB cloud account what is the purpose of the reverse proxy then ?
In case nginx is use for openHAB then it is not required.
Bindings normally either connect to local hardware to control the hardware or access an API that is provided by the vendor via accessing the vendors hosts on the internet.
This time it is your Niko Home Control before it was your Sonos. One binding cannot control the other ( as long as it is not completely hacked … ).
For openHAB cloud account I would expect that also your registered email address needs to be known plus the password.
My original setup (old SD card) had access through openHABCloud and via reverse proxy (nginx). I now no longer need the reverse proxy since the mobile openHAB app manages access to openHAB3. That’s the reason why I ditched the reverse proxy in my current ‘new’ deployment.
For the reverse proxy to funciton, I had one port being forwarded. I deactivated that port forwarding now. Only SSH is allowed for a single user, and access attempts are logged at system level and with fail2ban.
I used to have NodeJS integration as well, but I didn’t deploy it yet on my new deployment.
I no longer use nginx but the erratic behaviour still occurs. I deactivated port forwarding just to be sure.
Indeed. That’s why I ditched nginx on the new deployment.
There is a link from my Niko Home Control installation to the Sonos speaker without involving openHAB. So both devices are operated through Niko Home Control.
Of course this may be pure coincidence. So I’ll keep having an eye open for random actions.
This all looks very strange to me, and I can’t imagine how the Niko Home Control binding can cause all this.
The binding does not do anything with the Sonos link in NHC.
While the binding uses the MQTT transport, that is not directly linked to events on the event bus, so all events you see can only be caused by MQTT messages coming from NHC through the API to the binding causing a state update or from commands given through the binding resulting in MQTT messages to the API… The command event in the log indicates something is triggering this on OH side. The binding does not create commands, it passes commands coming from items. And these get commands mainly from UI’s or rules.
You could switch on DEBUG logging for the binding. That will show in detall all messages send and received. The sent ones are the interesting part.
Maybe also try changing your password for your NHC account. After all that is what the NHC app uses to remote control your system. If someone has that password, they can do anything with the NhC app.
I’m also clueless. Oddly, I see no weird activity in the system logs or in the openHAB logs.
I see.
I set the log level to DEBUG for all active MQTT bundles and for the Niko Home Control bindng:
$ openhab-cli console
openhab> bundle:list -s | grep -i mqtt
240 x Active x 80 x 1.2.2 x com.hivemq.client.mqtt
256 x Active x 80 x 3.4.2 x org.openhab.core.io.transport.mqtt
openhab> log:set DEBUG org.openhab.core.io.transport.mqtt
openhab> log:set DEBUG com.hivemq.client.mqtt
openhab> bundle:list -s | grep -i niko
255 x Active x 80 x 3.4.2 x org.openhab.binding.nikohomecontrol
openhab> log:set DEBUG org.openhab.binding.nikohomecontrol
When I press a wall switch, I now get messages in the log such as:
2023-03-13 10:02:00.211 [DEBUG] [l.nhc2.NikoHomeControlCommunication2] - setting action 1da4f726-836e-4892-a228-8e26573a705d internally to ON
Do you mean the mynikohomecontrol account or the Hobby API token?
I mean the mynikohomecontrol account. That one gives access to using NHC through the NHC app, and also allows you to retrieve the API token. So resetting the API token when the mynikohomecontrol account is compromised will not help at all.
I’m also clueless. Oddly, I see no weird activity in the system logs or in the openHAB logs.
I see.
From the openHAB console I enabled DEBUG logging for MQTT services and for the NHC binding:
openhab> bundle:list -s | grep -i mqtt
240 x Active x 80 x 1.2.2 x com.hivemq.client.mqtt
256 x Active x 80 x 3.4.2 x org.openhab.core.io.transport.mqtt
openhab> log:set DEBUG org.openhab.core.io.transport.mqtt
openhab> log:set DEBUG com.hivemq.client.mqtt
openhab> bundle:list -s | grep -i niko
255 x Active x 80 x 3.4.2 x org.openhab.binding.nikohomecontrol
openhab> log:set DEBUG org.openhab.binding.nikohomecontrol
Note: this does not work without the ‘-s’ argument.
That password has been generated with a password manager. Updating that password has some implications if not done carefully: First, I have to make sure that all active sessions have been logged out. Otherwise my account will be locked.