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.
And then of my openHAB Cloud account.
Do a systematic analysis:
- what are the ways that are enabled to get into the network is it
a) reverse proxy ?
b) myopenhab ?
Use e.g. shodan.io to check if your DNS entry or IP can be found listed with open ports there.
Check your nginx logs. Mine e.g. show entries like
34.244.xxx.xxx - - [11/Mar/2023:14:48:49 +0100] "POST /rest/items/Rule_Pforte HTTP/1.1" 200 0 "-" "-"
34.244.xxx.xxx - - [11/Mar/2023:14:48:49 +0100] "GET /rest/items/Rule_Pforte HTTP/1.1" 200 206 "-" "-"
when a rule is executed via Alexa routine.
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.
Correct.
Niko has a weird check if you have a short on the bus when it starts
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.
[/quote]
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.
Any rules that could be the root cause ?
In case you use rules that do not use logging add logging to them.
Even better, use the Karaf console or edit log4j2.xml to set the openhab.event.RuleStatusInfoEvent logger to INFO. This will add RUNNING/IDLE log statements to events.log every time a rule runs. Even if the rule blows up before it can log youāll still know the rule at least tried to run. And the rule running events will be inline with the Item events in question so it should be easier to tell whether rules are involved here or not.
1 Like
The only rules I have at the moment are monitoring the status of the OpenWeatherMap and Buienradar bindings. They listen to updates of the Thing status and set a Switch Item state accordingly.
I enabled INFO log level for the openhab.event.RuleStatusInfoEvent logger.