Problem with discovery, but manual creation of thing works

I’m developing a binding, so I add and remove the same thing very often. I currently face a problem that the discovery stopped working. I can add the thing manually and it works as expected. I confirmed that the devices (4 AC units) are responding to the discovery query - I have a standalone python script for that.
I suspect there are some “leftovers” in the openhab config that are blocking the discovery. It’s a guess only.

I didn’t change the discovery code, there is nothing suspicious in the log, yet it doesn’t work

What I tried:

  1. update of the binding (I do it every 5 minutes anyway)
  2. uninstalling and re-installing the binding
  3. removing anything (things, points) from openhab GUI related to my binding
  4. purged all orphaned links related to my binding
  5. Edit: I’m compiling for the 4.1.3 now, after removing ~/.m2 maven cache
  6. I added logger entries everywhere in the discovery class and I see some activity, but there is nothing happening beside this
    22:10:03.938 [DEBUG] [scovery.MHIairconDiscoveryParticipant] - MHI Air Conditioner getSupportedThingTypeUIDs 22:10:04.594 [DEBUG] [scovery.MHIairconDiscoveryParticipant] - MHI Air Conditioner getSupportedThingTypeUIDs 22:10:04.602 [DEBUG] [scovery.MHIairconDiscoveryParticipant] - MHI Air Conditioner getSupportedThingTypeUIDs 22:10:04.611 [DEBUG] [scovery.MHIairconDiscoveryParticipant] - MHI Air Conditioner getSupportedThingTypeUIDs 22:10:04.620 [DEBUG] [scovery.MHIairconDiscoveryParticipant] - MHI Air Conditioner getSupportedThingTypeUIDs 22:10:04.620 [DEBUG] [scovery.MHIairconDiscoveryParticipant] - MHI Air Conditioner getServiceType 22:10:04.631 [DEBUG] [scovery.MHIairconDiscoveryParticipant] - MHI Air Conditioner getServiceType 22:10:09.620 [DEBUG] [scovery.MHIairconDiscoveryParticipant] - MHI Air Conditioner getSupportedThingTypeUIDs
System info:###############################################################################
###############  openhabian  ##################################################
###############################################################################
##        Ip = 192.XXX.XXX.XXX
##   Release = Raspbian GNU/Linux 11 (bullseye)
##    Kernel = Linux 6.1.21-v8+
##  Platform = Raspberry Pi 4 Model B Rev 1.5
##    Uptime = 5 day(s). 22:39:45
## CPU Usage = 1.11% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
##  CPU Load = 1m: 0.16, 5m: 0.05, 15m: 0.01
##    Memory = Free: 1.83GB (49%), Used: 1.92GB (51%), Total: 3.75GB
##      Swap = Free: 2.99GB (100%), Used: 0.00GB (0%), Total: 2.99GB
##      Root = Free: 47.32GB (84%), Used: 8.55GB (16%), Total: 58.28GB
##   Updates = 29 apt updates available.
##  Sessions = 2 session(s)
## Processes = 133 running processes of 32768 maximum processes
   openHAB 4.1.3 - Release Build

My code is based on 4.2.0 and it’s here (WARNING, use gloves, DIRTY code)

I had some compilation problems (and git management problems as well) - I’m not sure how compiling for different version affects the discovery. It was working OK on 4.3.0, so I guess 4.2.0 should be fine.

Any suggestions what might be wrong?

I moved this to a more appropriate category so hopefully the right people will see it.

1 Like

Thank you! I guess I need to spend some more time on the forum and less time with vim and mvn :nerd_face:

More info. Binding compiled for 4.1.3. After installation is shows Installes State instead of Active, but update (with the same jar!) changes is to Resolved. Can someone help me to understand what’s happening? Both classes in the diag message are present in the code.

openhab> la -l|grep -i mhi
openhab> install file:/usr/share/openhab/addons/org.openhab.binding.mhiaircon-4.1.3.jar
Bundle ID: 286
openhab> la -l|grep -i mhi
286 │ Installed │  80 │ 4.1.3                  │ file:/usr/share/openhab/addons/org.openhab.binding.mhiaircon-4.1.3.jar
openhab> diag 286
openHAB Add-ons :: Bundles :: Mitsubishi Heavy Industries Binding (286)
-----------------------------------------------------------------------
Status: Installed
Unsatisfied Requirements:
osgi.service; filter:="(objectClass=org.openhab.binding.mhiaircon.internal.MHIairconDynamicStateDescriptionProvider)"; effective:="active"
osgi.service; filter:="(objectClass=org.openhab.binding.mhiaircon.internal.MHIairconHttpClientFactory)"; effective:="active"
Declarative Services


openhab> update 286 file:/usr/share/openhab/addons/org.openhab.binding.mhiaircon-4.1.3.jar
openhab> diag 286
openhab> la -l|grep -i mhi
286 │ Resolved │  80 │ 4.1.3                  │ file:/usr/share/openhab/addons/org.openhab.binding.mhiaircon-4.1.3.jar

Hello Przemo,
Discovery results might be cached, also you rely on MDNS discovery participant interface which might result in different behavior.
I’d advise checking if org.openhab.core.config.discovery.mdns.internal.MDNSDiscoveryService#scan is called at all.

1 Like

I’ll do it as soon as I learn how to do it :slight_smile: [Knowledge loading in progress…] Thank you!

You can pull sources into IDE of your choice and make a breakpoints across methods there. This way you can check if “scan” click within main ui results in interaction with discovery service.

1 Like

Thanks! I guess I need to get into Eclipse. I use vim + syntastic, so setting breakpoints is not an option.

My guess about some leftovers was right. I can’t even see my bingin after nstallation, so:

  1. I compiled another binding (daikin) - works fine, is Active
  2. renamed all files and relevant parts of the code in my binding from mhiaircon to mhiairconditioning
  3. Compiled and installed as I always did and:
openhab> la -l|grep -i mhi
287 │ Resolved │  80 │ 4.1.3                  │ file:/usr/share/openhab/addons/org.openhab.binding.mhiaircon-4.1.3.jar
289 │ Active   │  80 │ 4.1.3                  │ file:/usr/share/openhab/addons/org.openhab.binding.mhiairconditioning-4.1.3.jar

The binding is visible, scan works (I didn’t even have to start it, 4 units added to the inbox immediately)

So somewhere in the guts of my OH4 installation is corrupted information about mhiaircon binding. Is there a database somewhere inside? :nerd_face: I might have to do a surgery…

Thank you very much for the help, suggestions and the admin work!