Is there a way to let OH show an editable code tab of offline things?
Description:
For now I only used the OH config files for configuring my devices. Now, with a new Homematic IP setup, I want to switch to jsondb to let OH do the necessary creation of most of the things config and save a lot of work.
So, I connected all devices to the Homematic CCU and let OH discover them and create the things.
Due to migration requirements, I can let the Homematic CCU run only for a small amount of time and due to that the bridge thing in OH is mostly offline. This leads to all connected things, like thermal sensors and radiators being also offline.
I want to do some preparations so that at day one I can just switch on the CCU (and fix some bugs for sure ). As I have some more devices, copy&paste would also save much work.
Unfortunately, for offline things there is no code tab where I can change the parameters.
Changing the jsondb file in the filesystem is (apart from being ugly) also no option as the docs clearly state that it is only loaded when OH starts.
This is a key feature of the “legacy” config files: When changing them, they are directly parsed by OH and you see possible errors.
Is there a way to make OH also show the parameters and or even the code tab when a thing is offline?
Furthermore you can create a copy of the Things at the bottom. Though you need to be running 4.3.2 it else you got a bug and it won’t work.
However, if by “offline” you mean defined in a .things file, no, there is no YAML configuration equivalent to an unmanaged Thing.
Assuming what you are trying to do is move an unmanaged Thing to become a managed Thing, the following should work:
1… Navigate to Developer Tools → API Explorer → things
2. GET for your unmanaged Thing and copy the JSON
3. Remove the unmanaged Thing from the .things file
4. PUT the JSON you copied earlier to create the Thing as a managed Thing
5. Repeat as necessary
I was maybe not precise enough. With “offline”, I really mean your first option where I see the red offline label in the UI, so, the status of the thing.
But I definitely have no code tab. See example screenshot:
I just see that the bridge thing itself does have the code tab.
(sorry, this forum does not allow me as “new user” to add more than one image in one post )
Wow…nice.
I just switched the CCU on again. Now the thing shown in the above screenshot is shown as online. And when the page loads, I can see the tabs for some miliseconds. Then they are away. Even with online thing. Strange.
But I am pretty sure I saw parameters for the thing when OH configured it initally.
Things for one device type (radiator) show the tabs. The ones for the wall thermostat do not. But there I can for sure also set parameters in the CCU…so…probably a bug in the binding.
I will do more more testing first before posting here again. Sorry for the noise.
Here my tests and the results.
When writing about things, I only mean the HomematicIP ones in focus.
Starting point:
Radiator things have the tabs
Wall thermostat things do not have the tabs
Homematic CCU is stopped
Process:
Start CCU
Things become all online
Also wall thermostats have now all tabs
Disable/pause brige thing in the UI
Wall thermostats and radiators retain the tabs
Restart openhab
Check jsondb things file org.openhab.core.thing.Thing.json and things config is still there
Things are in NOT YET READY state and do no more have the tabs
Resume bridge thing
Some things become online, some require pausing/resuming as they run into a comm timeout (might be due my poor NAS hardware)
Both wall thermostats and radiators have the tabs
So far no clue why it behaves like that as I cannot see any logic in it.
Caching and after OH restart gathering new data from the CCU could be a scenario. But in this case the old config should be still visible there.
UPDATE: Logs show many of these. Maybe a binding issue. But just WARN messages…
2025-02-01 19:34:19.877 [WARN ] [core.thing.internal.ThingManagerImpl] - A thing handler factory claims to support 'homematic:HmIP-WTH-2' for thing 'homematic:HmIP-WTH-2:f2815def26:000AA0C9A6817D' for more than 120s, but the thing type can't be found in the registry. This should be fixed in the binding.
...
2025-02-01 19:34:22.019 [WARN ] [core.thing.internal.ThingManagerImpl] - Could not normalize configuration for 'homematic:HmIP-eTRV-2:f2815def26:000A20C9A5A4A6' because the thing type was not found in registry.
Hi, which CCU do you use and do you have the specific Homematic IP device names to hand? I might use these too, I have a CCU-3 with around 100 devices in use.
It would also be great if you could post the code section of your CCU from Openhab and the firewall settings from your CCU to rule out any errors. Are you using: useAuthentication: true
The Homematic binding doesn’t have a database of possible devices (and thus a static list of thing types). It builds thing types dynamically based on the data received from the CCU, which means: no CCU, no thing types.
(This approach has two advantages: there’s no need to track a list of HM devices in OH, and it’s possible to support also special devices, such as home-grown ones using AskSinPP)
So that means that there is nothing stored in OH? But as written above, the jsondb still contains the things settings even though the CCU is offline.
I get the advantage you mention. Dynamic creation of thing types and getting also updates automatically is nice.
Still, the huge disadvantage is in my eyes that an offline CCU leads to no more access to any device config inside of OH. I cannot let the CCU run all the time while setting up the devices in OH as my old solution also uses the 868 MHz band for radio communication and both tranceivers active lead to collissions.
And even when leaving this aside, there are use cases where you want to check a config when the CCU is currently not available. Ok, accessing the jsondb file…but thats not a nice way.
What about keeping a copy and sync it when the CCU comes back instead of rebuilding everything?
Did you restart OH after disabeling the bridge? Cause only then the (cached?) thing data/type vanish.
Generally: An easy workaround came into my mind: As I do not yet need real device connectivity, I can just unplug the USB radio stick (physically or virtually in the docker compose definition). Then there are no sending collitions and XML API of the CCU is still reachable.
Does not solve the general situation but is in my case a possible way to go forward (I never have started the CCU without a stick…thingers crossed)
Oh sorry missed that part - maybe I can try it out tomorrow when kids and wife are not at home. Will report back.
But in the meantime let me ask you a question you are transferring your Homematic stuff form something like a RaspberryMatic to a normal CCU? So you should have two bridges? Can’t you just disable them in openhab?
My historical setup consists of eQ3 MAX! components that are controlled via FHEM with a self-made radio transceiver with CUL firmware. FHEM is communicating with OH via MQTT.
These MAX! devices I want to replace with HomeMatic IP. The CCU is a RaspberryMatic as docker image on an RASPI (where other containers are running as well).
The old CUL tranceiver is a breadboard solution , so radio quality is not that good and it is in general very error-prone. Hence, when I run the HMIP CCU with the radio stick attached in parallel, I loose MAX! messages (seems that HMIP always wins) or radiators are doing stupid things…partially in the night in my bedroom. And I need my sleep in a room with less than 24 degrees.
I unplugged the USB stick while the old MAX! solution was still working. That was not a full success as somehow plugging it in again did not lead to the HomeMatic CCU recognizing it. I always had to restart the CCU container.
Finally I just started one day after lunch, powered down the MAX! stuff and integrated the basics of everything important in one shot so that the heating at least starts in the morning before I go out of bed. Was probably a little late with right before midnight…but it worked .
Rest of the integration to OH took even longer, also because settings like max valve opening is not a channel and you can only change it e.g. in a rule via REST call. But this was then no more time critical.
To say also something positive about the dynamic thing type creation: The names of the channels are then the same as in the eQ3 docs which helps a lot. I really like consistent naming .
). As I have some more devices, copy&paste would also save much work.
)
, so radio quality is not that good and it is in general very error-prone. Hence, when I run the HMIP CCU with the radio stick attached in parallel, I loose MAX! messages (seems that HMIP always wins) or radiators are doing stupid things…partially in the night in my bedroom. And I need my sleep in a room with less than 24 degrees. 
.
.