Channels not showing in UI... what have I missed?

I’ve been trying to port the OH2.5 Eagle 200 binding to OH3. The Eagle 200 is a device that lets you read the current values of your SmartMeter, and having that in openhab (and also persisted to influx/grafana, via openhab) is really handy.

I’m way out of date on Java and the tool chain has been a struggle, but the code itself is good. Thomas Hentschel, the original author, wrote nice clean code and I haven’t had any trouble understanding it, just trying to get Eclipse and the build tools to do things like include a module. The OSGI environment is large and complex and I’ve spent a lot of time lost at sea in it.

I’ve finally got the whole system running, all of the errors cleared up and all but a handful of the warnings. My test system is cheerfully chugging along, talking to my device and noticing the data updates.

At least, according to the log files it’s noticing the updates. I’m seeing two issues that I haven’t been able to untangle yet.

This may be more useful for me to find out: I also don’t know the best way to share a chunk of code with people here to let them look at it in larger chunks and see if they can spot the thing I’m missing. What’s the preferred method? I can fork the openhab-addons on Github and check my changes in there, which is probably the simplest way to let people look at the whole binding. Is there a preference?

This module works by using a bridge Thing that talks to the Eagle 200 device, and then creating each item the Eagle 200 knows about as a Thing connected to that bridge. Pretty straightforward.

The Eagle 200 doesn’t know what values the devcies it shares will offer, and different power meters offer different values. So the binding doesn’t try and have a fixed set of channels for the meters. It has a generic “numeric” one and a generic “string” one, and when the meter Thing is created it updates the channel list by querying the device. As data comes in, it updates the channels it created.

First problem:

When the device is discovered and added as a Thing, I can see in the log it creates the channels, and then I can see data being added to them. If I use the Felix console in Eclipse and run “openhab:things show” on the electric meter thing, I can see all channels listed there.

But the UI never shows those channels anywhere. I can’t see them on the Thing, and I can’t add them to an Item. The REST interface does not see them listed.

Is this just a reload issue in the UI, or have I missed something to make a channel visible?

Second problem:

If I shut down the program and restart it, it re-creates the bridge Thing and the meter Thing, but the channels are never being created on the meter Thing.

Watching the initialization run, the code finds the channel already exists, so does not create it, but if you show the Thing with openhab:things show, no channels are defined.

Somehow it’s checking and thinking they’ve been persisted, but then they don’t show in the system.

Where can I go to get more technical advice on what I’m seeing here?

It would be better to point to your code on github, so we can have a look at it.

1 Like

One of the changes you need to make when porting an add-on from OH 2.5 to OH 3 is to rename src/main/resources/ESH-INF to src/main/resources/OH-INF. Otherwise the framework will not be able to find all the thing/channel type info. You may also want to check if the XML files use in their namespace URLs.

1 Like

Well, make sure you use proper binding coordinates for your thing and channels. It might happen that thing you declared comes from binding “x” and channel type definitions by mistake come for binding “y”. Then, even if everything compiles and does not report issues within runtime definitions are misaligned.

1 Like

You are completely right, @hmerk, and that became clearer the more I thought about it.

I’ve got a fork on github at and my current code checked into the lwe_eagle200 branch. As you would expect, all the interesting stuff will be in openhab-addons/bundles/org.openhab.binding.eagle200

The code compiles and runs. I’m not seeing channels in the UI even when they show via REST or the shell in Eclipse.

@wborn, I created a new binding with and then created new classes and filled code in from the 2.x binding to make sure that I didn’t miss things just like this. That being said, I still could have messed up the XML files. I’ve just checked and they do use the schemas instead of the eclipse.smarthome ones.

@splatch How can I verify that? When I create the channels, I create them with a type defined in this module’s constants and created as new ChannelTypeUIDs.

It would not surprise me if I’ve missed a 2.x → 3.x change in channel creation. The device discovery had at least one sort of subtle change I had to make before it worked properly, which I found in the docs. This one has eluded me so far.

Looking at code - seems you have wrong argument for channel types constructed in binding constants:

First argument is binding id as channels are grouped by binding and can be reused across all things this binding defined.

1 Like

I think that was my error. After changing that, and doing some other little cleanups, channels started showing in the UI.

I think the channel types had been persisted or cached and I don’t know how to get the test framework to reset its caches and restart clean. I changed the names of the channel types - which were slightly incorrect anyway - and when new channels were created they showed in the UI and binding Items to them works as expected!

Thank you so much. I’d never have found it.

I had copied that value from the old binding; did this change between OH2.x and 3.x, or was this binding just always a little incorrect there?

I’m not seeing any string values being set into the system, but there’s more debugging I can do into that before I’m stuck.

I may have spoken too soon. Things are healtier when the item is created, but if you stop and restart the system the channels no longer appear. The debug code says they are not created because they already exist, but then they never show or apparently get any data.

There are different ways to work with channels. Some handlers rely on dynamic list, some other on static one. If you have a static list of channels then you can rely on ChannelUID created by you.
You are right that channel instances are cached. When discovery is moved from inbox to the system there is a process which copy channels from definition to json storage where it remains. When your ThingHandler is about to be created you receive a Thing instance with channel list which you can enumerate and operate upon (ie. launch some specific logic). If you start traversing sources you will find there are ThingType and ChannelType elements which directly represent XML or runtime contents. If needed, they might be created by ThingTypeProvider or ChannelTypeProvider, bypassing the need to create XML section for each and every channel you might work with.
For strings - make sure your channel and item definition are inline and both work with StringType which is getting pushed from handler itself.