Migration from OH 2.5 to 4.1

[sherif (Marcin)]

Hi guys
After more or less 6 years I have decided to migrate my old platform to new ones, as my part of bidding was not working properly and was outdated. I have also changed platform from Pi2 to Pi3 with the newest Openhabian.
Unfortunately I forgot most of syntax and my complex config , also to he honest I thought that most of config will work on 4.1. My previous config was based on OH1, migrated/exteded to OH2. Now I spend a lot of time and it looks it working in ca 70%, but still I can not undestand or solve few problem. If you can help I will will be very gratefully, especially that I cound not find answer on community.

1. As I understand all binding concept is new now. Previously I can do config via web but it was inline with my text files. Now system ignored my binding config from items file, but when I config it via UI I do not see any text configuration, so where UI keep config like things, bridges, etc ?

2. I have following warn:
   Item 'GWC_Auto_time' needed for rule 'went-1' is missing. Trigger '1' will not work.

while:
items file:

Switch GWC_Auto_Time "Załączenie na noc" (Wentylacja)

and rules with rule no1:

rule "Enabling GWC"
when	
	Time cron "0 0 19 * * ?" or
	Item GWC_Auto_time changed from OFF to ON
then	
	if (GWC_Auto_Time.state == ON) {
		postUpdate(GWC, ON)
	}
end

It was working under OH2.

3. Contact items, I have plenty of items which I read from alarm system (Satel binding) like door or window status (open/close) OR from GPIO input. Now I can not assign as those binding do see only switches. Why ? Contact items are not longer supported.

4. WARN from Logs, which I have no idea how is it connected with config:

[WARN ] [pache.cxf.jaxrs.sse.SseEventSinkImpl] - There are still SSE events the queue which may not be delivered (closing now)

5. Also I have read that some types was changed, is it a problem with types ?

[ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'went-3' failed: Could not cast NULL to org.openhab.core.library.types.DecimalType; line 32, column 28, length 39 in went

rule "Went_Fun nawiew update"
	when
		Item Went_Fun_Nawiew received update or
		Item Went_Mode changed or
		Item Went_Flow changed
then
	{
	if (Went_Fun_Nawiew.state !== NULL) 
	{
		postUpdate(Went_Fun_Nawiew_V, 10 * (Went_Fun_Nawiew.state)as DecimalType / 4095)
		val int c_Nawiew =10 + (((Went_Fun_Nawiew_V.state)as DecimalType -2) * 14.2857).intValue
		postUpdate(Current_Nawiew, c_Nawiew)
	}
	
	}
end

Number Went_Fun_Nawiew (Wentylacja) //{channel="modbus:data:went:Fans:Naw:number"}
Number Went_Fun_Wywiew (Wentylacja) //{channel="modbus:data:went:Fans:Wyw:number"}
Number Went_Fun_Nawiew_V "Napięcie wentylator nawiewu [%.1f V]" <fan> (Wentylacja)
Number Went_Fun_Wywiew_V "Napięcie wentylator wywiewu [%.1f V]" <fan> (Wentylacja)
Number Went_Mode "Tryb pracy" <program> (Wentylacja) 
Number Went_Flow "Zadana wydajność [%d]%" <fan> (Wentylacja)

[rlkoshak (Rich Koshak)]

@sherif

Unfortunately I forgot most of syntax and my complex config

Sounds like a good reason to gradually migrate to configuring through the UI. There is no syntax (or very very little) that you have to remember there.

@sherif

As I understand all binding concept is new now. Previously I can do config via web but it was inline with my text files. Now system ignored my binding config from items file, but when I config it via UI I do not see any text configuration, so where UI keep config like things, bridges, etc ?

OH 2 introduced a whole new architecture for bindings that enables automatic discovery of devices. So it’s not new. What is new is as of OH 3 support for OH 1 style add-ons was dropped. You must configure and use 2.x style bindings in 2.x style ways which means Things, Channels, Links and Items.

If you still have some OH 1.x style configs in your .items files, you’ll have to replace those with the creation of a Thing and linking the Item to a Channel on that Thing.

@sherif

I do not see any text configuration, so where UI keep config like things, bridges, etc ?

All managed configs (i.e. those done through the UI, REST API, or Karaf Console get saved to the JSONDB. This is located at /var/lib/openhab/jsondb.

You should not edit this file directly except under extreme circumstances and while OH is not running.

@sherif

I have following warn:
Item 'GWC_Auto_time' needed for rule 'went-1' is missing. Trigger '1' will not work.

The error is pretty clear. GWC_Auto_time doesn’t exist…

@sherif

while:
items file:

Notice it’s defined as GWC_Auto_Time. Case matters.

@sherif

It was working under OH2.

I doubt it. Case has always matter in Item names.

@sherif

Contact items, I have plenty of items which I read from alarm system (Satel binding) like door or window status (open/close) OR from GPIO input. Now I can not assign as those binding do see only switches. Why ? Contact items are not longer supported.

It was a choice made by the binding authors who may or may not have been the same authors who wrote the 1.x bindings you were using. You can apply a transform profile between the Channel and the Item to map ON to OPEN and OFF to CLOSED and link these Channels to a Contact Item if you need to. Or just change your Contact Items to Switch Items.

There really isn’t a sharp separation between Contacts and Switches any more as you can define a Switch as read only which essentially makes it a Contact in how it behaves.

@sherif

3. WARN from Logs, which I have no idea how is it connected with config:

[WARN ] [pache.cxf.jaxrs.sse.SseEventSinkImpl] - There are still SSE events the queue which may not be delivered (closing now)

It’s not related to your config. This is a problem that occurred in the SSE stream between a web browser showing an openHAB UI and the server. Ignore this for now but be sure to pay attention to the status of your machine, in particular the system load, free memory and swap. If the load goes up or the system load goes up you might be having out of memory problems which can cause problems like this. An RPi 3, we are seeing, is probably not sufficient to run OH 4 unless it’s a modest configuration with little else running on the machine.

@sherif

Also I have read that some types was changed, is it a problem with types ?

You’ve cut off the full error so .

In general, it’s better to cast a Number Item’s state to Number instead of DecimalType. Your parens are a little odd though. And it’s better to use the postUpdate function on the Item where possible. Also avoid primitives and forcing the types of variables in Rules DSL unless necessary.

    Went_Fun_Nawiew_V.postUpdate(10 * (Went_Fun_Nawiew.state as DecimalType) / 4095)
    val c_Nawiew = 10 + ((Went_Fun_Nawiew_V.state as DecimalType) - 2) * 14.2857
    Current_Nawiew.postUpdate(c_Nawiew)

Make sure to review the Getting Started Tutorial and, since you are coming from basically OH 1.x (even if you were running 2.x you were still using 1.x bindings) review the migration tutorial. Migration from openHAB 1.x to openHAB 2 | openHAB

[laursen (Jacob Laursen)]

@rlkoshak

An RPi 3, we are seeing, is probably not sufficient to run OH 4 unless it’s a modest configuration with little else running on the machine.

What would you consider a modest configuration? I’m planning to migrate my production system to a RPi 5 8 GB (hopefully) soon, but currently I’m running openHAB 4.1 on a RPi 3. I have 30 bindings, 143 Things, 730 items and 207 rules (DSL and JavaScript). I don’t know if that is modest, but so far it’s been running smoothly. I think my memory configuration is modest:

EXTRA_JAVA_OPTS="-Xms192m -Xmx384m -XX:+ExitOnOutOfMemoryError"

I only have Mosquitto also running on the machine. I guess it also depends on which bindings one is running, some might be more demanding than others. Some may even contain memory leaks/performance issues.

[rlkoshak (Rich Koshak)]

@laursen

I don’t know if that is modest, but so far it’s been running smoothly.

That’s really impossible to answer. It’s a multidimensional problem. For example, you could have 10000 Things and 20 Items. Will memory be a problem? . What if I have 20 Things and 10000 Items?

If it works smoothly for you, great! If not then you’ve exceeded the capabilities of an RPi 3. But I can’t tell you the max number of Items, Things, and Rules to stay under to keep it working.

The problem is rarely OH configs anyway. It’s usually because there are too many other third party services running like Mosquitto, InfluxDB, Grafana, zigbee2mqtt, etc.

I can’t give a rule that says “keep under this too be safe on an RPi 3”. The best I can do is say if you have problems (e.g. rules take a long time to trigger, clock send to be off in cron triggers, etc) look at your system stats. If the 15 minute load > 1, free RAM is low, or swap it’s in use, you’ve exceeded the capabilities of the machine. Something needs to be moved to a different machine. CPU is almost never going to be the limiting factor though, it’s going to be RAM.

@laursen

Some may even contain memory leaks/performance issues.

This does occur from time to time but it’s usually quickly found, not always quickly fixed though. But indeed, even the amount if RAM a Thing consumes is going to vary from one binding to the next.

[sherif (Marcin)]

@rlkoshak

OH 2 introduced a whole new architecture for bindings that enables automatic discovery of devices. So it’s not new. What is new is as of OH 3 support for OH 1 style add-ons was dropped. You must configure and use 2.x style bindings in 2.x style ways which means Things, Channels, Links and Items.

If you still have some OH 1.x style configs in your .items files, you’ll have to replace those with the creation of a Thing and linking the Item to a Channel on that Thing.

Thanks Rich !
Thas what I missed when I read manuals. Maybe I was wrong and thought that there were two methods of config, and when I did via web, text file was updated. Now is clear, as I got lost with bindings and confg files.

@rlkoshak

Notice it’s defined as GWC_Auto_Time. Case matters.

Ahh, yes. Thats correct. Probably it was NO working last years, but OH4 warn me about it

@rlkoshak

It was a choice made by the binding authors who may or may not have been the same authors who wrote the 1.x bindings you were using. You can apply a transform profile between the Channel and the Item to map ON to OPEN and OFF to CLOSED and link these Channels to a Contact Item if you need to. Or just change your Contact Items to Switch Items.

Thats strange that idea of bindings was changed. I have switched all contacts to switches, but then I lost proper icons visibility. Where I can find “build-in” icons ? In /openhab/icons/classic I cannot find different version ie doors (open, close) which now I need to change to on/off. I mean all that can be find here: Icons | openHAB with certain variants.

@rlkoshak

An RPi 3, we are seeing, is probably not sufficient to run OH 4 unless it’s a modest configuration with little else running on the machine.

Thats interesting, so do you mean that during those years OH is now such hardware performance demented ? I had RPI2 vB with 1G and it works great with OH2.5. Now I have deployed the newest RPI3 4GB for OH 4.1 (60 rules, 310 items). The rest config is same, influxdb, OpenVPN server.
Yesterday I got ca 20 similar notification, but Today they gone … also I noticed that sometimes UI and basic interface are not responding or refreshing need some time. Never has such issues with OH1/2.

@rlkoshak

In general, it’s better to cast a Number Item’s state to Number instead of DecimalType. Your parens are a little odd though. And it’s better to use the postUpdate function on the Item where possible. Also avoid primitives and forcing the types of variables in Rules DSL unless necessary.

I solved all of those by changing to Number.
I also noticed some problem with command execution, different time syntax and notification syntax.
It took long time to find out all of those.
I still could not solve a problem with rule that restart openhab process. I have read Beginner's guide to an openHABian reboot/shutdown switch
and it works for system reboot, but I am not able to do it with OH process:
executeCommandLine("service", "openhab", "stop")
with SUDO or without it doesnt work.
EDIT: I forgot about Exec binding, after I added commands works.

[rlkoshak (Rich Koshak)]

@sherif

Thats strange that idea of bindings was changed.

Well, keep in mind that it took a complete rewrite of the binding to go from OH 1.x style to OH 2.x style and the OH 2.x style opens a huge number of new opportunities. Couple that with the fact that the author of the 1.x binding was often not the same person who implemented the 2.x style binding it should be no surprise there are differences.

@sherif

Where I can find “build-in” icons ?

They are, as the name implies, “built in”. They are buried in a jar file which in turn is buried in a kar file somewhere in userdata. But if you are looking to create a custom set, you can download them from Icons | openHAB and change them so they work with ON/OFF instead of OPEN/CLOSED. See. Items | openHAB.

But also note that as OH OH 4.0 icons from multiple sources are supported (e.g. F7, material, iconify), not just custom and built in icons. See Items | openHAB.

And, like I said above, you don’t have to change the Items to be Switches. You can use a profile to change them to Contacts.

1. Install the Map Transform
2. Under Settings → Transformaions click + and create a new Map transform that maps ON to OPEN and OFF to CLOSED
3. Navigate to the Link between the Item and the Channel (you can get to it from either the Channels page of the Thing or the Item’s page.
4. Under “profile” choose “Map” and select the transform you created in 1

@sherif

Thats interesting, so do you mean that during those years OH is now such hardware performance demented ?

It’s more Java that seems to be the cause. Java 17 just seems to cause OH to consume more RAM and even with OH 2.5 and 3.0 1 GB RAM for OH with all the other stuff people like to run was right at the edge of supportable. Java 17 pushed it over the edge.

Note that 64-bit consumes even more RAM.

[sherif (Marcin)]

@rlkoshak

Well, keep in mind that it took a complete rewrite of the binding to go from OH 1.x style to OH 2.x style and the OH 2.x style opens a huge number of new opportunities. Couple that with the fact that the author of the 1.x binding was often not the same person who implemented the 2.x style binding it should be no surprise there are differences.

Yes, it is clear.
From user point of view, can I delete all/old bindings files in /services ?

@rlkoshak

They are, as the name implies, “built in”. They are buried in a jar file which in turn is buried in a kar file somewhere in userdata. But if you are looking to create a custom set, you can download them from Icons | openHAB and change them so they work with ON/OFF instead of OPEN/CLOSED. See. Items | openHAB.

Yes, I have seen those. I can download, but just one stage of the icon. Ie Window under things on icon webpage. It is just icon of closed stage. Same with others …

@rlkoshak

But also note that as OH OH 4.0 icons from multiple sources are supported (e.g. F7, material, iconify), not just custom and built in icons. See Items | openHAB.

Yes, I read it, but it is not my level yet . First I must fix all issues after migration.

@rlkoshak

It’s more Java that seems to be the cause. Java 17 just seems to cause OH to consume more RAM and even with OH 2.5 and 3.0 1 GB RAM for OH with all the other stuff people like to run was right at the edge of supportable. Java 17 pushed it over the edge.

Note that 64-bit consumes even more RAM.

Yes, I read about 64-bit, so I just based on 32-bits. From performence it looks really got up to know, when I check directly on proc, memory resources.

Now I have found out that I have new issue with persistence. InfluxDB was installed, configured and migrated. OH do not report any issues. In deamon.log I do see POST items send by OH towards InfluxDB, but since few days there are no new measurements when I check via Grafana in InfluxDB.
Files with persists I keep same, is it correct ? Or do I need to re-edit it ?
From docs I look without change …

[rlkoshak (Rich Koshak)]

@sherif

From user point of view, can I delete all/old bindings files in /services ?

If you plan on reinstalling them and configuring them through the UI, definitely. Even if you plan on configuring through the services files, you probably want to remove the old ones and let the add-on create a new one, just in case there are significant differences from what’s there.

@sherif

Yes, I have seen those. I can download, but just one stage of the icon. Ie Window under things on icon webpage. It is just icon of closed stage. Same with others …

It used to open a little dialog with all the versions of the icon when you click on it. At least I thought they used to. I haven’t use the build in icons in a very long time.

@sherif

Yes, I read it, but it is not my level yet .

If you think you are going to head that direction, it’ll be less work to figure that out than it will be to create your own custom classic icons.

@sherif

Files with persists I keep same, is it correct ? Or do I need to re-edit it ?

I don’t think anything has changes in .persist files beyond the addition of some new features (i.e. filters such as “don’t persist values above a threshold value”) and support to configure the persistence strategy in the UI.

You should not need to reedit it. But you should also see that file being loaded in openhab.log during OH startup (it says something like ‘loading model influxdb.persist’.

You can put the InfluxDB add-on into debug or trace level logging (Settings → InfluxDB → Add-on log settings) and see all the add-on’s activities.

Also look at the logs for InfluxDB. If OH isn’t complaining about connection timeouts and dropping values in the logs that means it’s successfully connecting to InfluxDB and InfluxDB isn’t rejecting the data OH is posting.

If you’ve a new and old instance of InfluxDB running, make sure OH is connected to the one you want.

[sherif (Marcin)]

@rlkoshak

It used to open a little dialog with all the versions of the icon when you click on it. At least I thought they used to. I haven’t use the build in icons in a very long time.

It doesn’t, based on following link: Icons | openHAB

@rlkoshak

You can put the InfluxDB add-on into debug or trace level logging (Settings → InfluxDB → Add-on log settings) and see all the add-on’s activities.

Thats the other story. I have no events.log, so I have added refence in log file to xml:

org.ops4j.pax.logging.log4j2.config.file=${karaf.etc}/log4j2.xml

Events appeared, but openhab.log file stop reacting for changing log level from UI. When I delete above link to xml it again works, but events.log stopped again. Is it any method to have it both ?

@rlkoshak

If you’ve a new and old instance of InfluxDB running, make sure OH is connected to the one you want.

No I have just one Influx instance (v1.8). I backuped old DB from other RPi and restored on new. Then configured to use same db with current OH 4.1 (same user, db name, etc).
I got following in log:

Loading model 'influxdb.persist'
InfluxDB persistence service started

I have set strategy everyminute for new item (Temp_CPU) and it appered as measurement in Influx,but it is empty …
Now with DEBUG log I can see following:
[DEBUG] [rnal.influx1.InfluxDB1RepositoryImpl] - query returned no series
but every 2 minutes.
Does it mean that it is some connection error ?
It is strange as Influx do not report any issues.

[sherif (Marcin)]

It is really strange with InfluxDb, from OH it looks ok (connected, persitence set). Trace provide a lot of confirmation about DB storage:

2024-01-09 11:56:38.551 [TRACE] [.influxdb.InfluxDBPersistenceService] - Queued InfluxPoint{measurementName='Temperature_CPU', time=2024-01-09T10:56:38.550947843Z, value=52.6, tags={item=Temperature_CPU}} for item Temperature_CPU (Type=NumberItem, State=52.6, Label=Temperatura CPU, Category=temperature, Groups=[CPU_temp, System])

2024-01-09 11:56:38.753 [TRACE] [.influxdb.InfluxDBPersistenceService] - Wrote 3 elements to database

and when I checked in Influx it is empty:

> show measurements
name: measurements
name
----
Energy_Day
..
Temperature_CPU
Total_Energy_Prod
Voltage_L1
Voltage_L2
Voltage_L3
openhabCpuPercent
> use openhab_db
Using database openhab_db
>  SELECT * FROM Temperature_CPU WHERE time > '2024-01-01 22:00:00'

no result …
I have just one openhab_db in Influx

[rlkoshak (Rich Koshak)]

@sherif

Thats the other story. I have no events.log, so I have added refence in log file to xml:

org.ops4j.pax.logging.log4j2.config.file=${karaf.etc}/log4j2.xml

Events appeared, but openhab.log file stop reacting for changing log level from UI. When I delete above link to xml it again works, but events.log stopped again. Is it any method to have it both ?

There is something wrong with your logging config then. Is this the stock OH 4 log4j2.xml file or are you still carrying around an old 2.5 logging config?

The file org.ops4j.pax.cfg should have the following contents and nothing else:

org.ops4j.pax.logging.log4j2.config.file=${karaf.etc}/log4j2.xml

The file log4j2.xml should have the following contents: https://raw.githubusercontent.com/openhab/openhab-distro/eeae65415204f8f8d887cdcb8219776b58b64216/launch/app/runtime/log4j2.xml

But any debug logging is going to appear in openhab.log. events.log only has the event bus events, and not even all of those.

When you change the logging level through the UI, a new line gets added to log4j2.xml. For example:

<Logger level="INFO" name="org.openhab.binding.honeywellhome"/>

@sherif

Does it mean that it is some connection error ?

No, a connection error would be a different error. It’s connecting to something. I think you need logs from the InfluxDB side.

In order to see the logs you are seeing on the OH side of things, OH has to have successfully connected to an InfluxDB and it maintaining that connection. Writes are done as a transaction so you won’t see “Wrote 3 elements to database” unless In fluxDB has acked that write.

Above you say the new Item is Temp_CPU. I only see Temperature_CPU in the list of measurements.

[sherif (Marcin)]

@rlkoshak

There is something wrong with your logging config then. Is this the stock OH 4 log4j2.xml file or are you still carrying around an old 2.5 logging config?

The file org.ops4j.pax.cfg should have the following contents and nothing else:

When I migrated from OH2, first thing what I did it was backup/restore function. Maybe that file was included.
My log4j2.xml seems same like my.
Thanks for hint, I will delete the rest of content in org.ops4j.pax.cfg and will test it.

@rlkoshak

In order to see the logs you are seeing on the OH side of things, OH has to have successfully connected to an InfluxDB and it maintaining that connection. Writes are done as a transaction so you won’t see “Wrote 3 elements to database” unless In fluxDB has acked that write.

I can not force Influxdb to output logs to the file. In concole I got something like follows:

Jan 09 18:00:00 openhabian influxd-systemd-start.sh[5095]: [httpd] 127.0.0.1 - openhab [09/Jan/2024:18:00:00 +0100] "GET /query?db=openhab_db&epoch=ms&q=SELECT+%22value%22%3A%3Afield%2C%22>
Jan 09 18:00:03 openhabian influxd-systemd-start.sh[5095]: [httpd] 127.0.0.1 - openhab [09/Jan/2024:18:00:03 +0100] "POST /write?db=openhab_db&rp=autogen&precision=n&consistency=one HTTP/1>
Jan 09 18:00:06 openhabian influxd-systemd-start.sh[5095]: [httpd] 127.0.0.1 - openhab [09/Jan/2024:18:00:06 +0100] "POST /write?db=openhab_db&rp=autogen&precision=n&consistency=one HTTP/1>
Jan 09 18:00:09 openhabian influxd-systemd-start.sh[5095]: [httpd] 127.0.0.1 - openhab [09/Jan/2024:18:00:09 +0100] "POST /write?db=openhab_db&rp=autogen&precision=n&consistency=one HTTP/1>
Jan 09 18:00:12 openhabian influxd-systemd-start.sh[5095]: [httpd] 127.0.0.1 - openhab [09/Jan/2024:18:00:12 +0100] "POST /write?db=openhab_db&rp=autogen&precision=n&consistency=one HTTP/1>
Jan 09 18:00:15 openhabian influxd-systemd-start.sh[5095]: [httpd] 127.0.0.1 - openhab [09/Jan/2024:18:00:15 +0100] "POST /write?db=openhab_db&rp=autogen&precision=n&consistency=one HTTP/1>

and similar on OH site:

2024-01-09 18:00:00.908 [TRACE] [.influxdb.InfluxDBPersistenceService] - Queued InfluxPoint{measurementName='Gaz', time=2024-01-09T17:00:00.907958797Z, value=94221.14457619283, tags={item=Gaz}} for item Gaz (Type=NumberItem, State=94221.14457619283, Label=Gaz, Category=gas)
2024-01-09 18:00:02.642 [TRACE] [.influxdb.InfluxDBPersistenceService] - Queued InfluxPoint{measurementName='Temperature_CPU', time=2024-01-09T17:00:02.642527416Z, value=54, tags={item=Temperature_CPU}} for item Temperature_CPU (Type=NumberItem, State=54, Label=Temperatura CPU, Category=temperature, Groups=[CPU_temp, System])
2024-01-09 18:00:03.230 [TRACE] [.influxdb.InfluxDBPersistenceService] - Wrote 3 elements to database
2024-01-09 18:00:05.659 [TRACE] [.influxdb.InfluxDBPersistenceService] - Queued InfluxPoint{measurementName='Temperature_CPU', time=2024-01-09T17:00:05.658791942Z, value=54.5, tags={item=Temperature_CPU}} for item Temperature_CPU (Type=NumberItem, State=54.5, Label=Temperatura CPU, Category=temperature, Groups=[CPU_temp, System])
2024-01-09 18:00:06.236 [TRACE] [.influxdb.InfluxDBPersistenceService] - Wrote 1 elements to database

@rlkoshak

Above you say the new Item is Temp_CPU. I only see Temperature_CPU in the list of measurements.

It was typo in message, persistence was set:
Temperature_CPU : strategy = everyMinute, everyChange, restoreOnStartup
This item was new and added in OH4. So OH add properly measurement, thats why it is on the list when I checked via Influx CLI, but it is empty. Even if OH report to store there.

Today I have delete all DB, reinstalled InfluxDb via openhabian-config. All seems to be working well. New data appeared on charts, so I wanted to restore old data. Influxdb blocked restore data to same db Back up and restore data in InfluxDB v1.8 | InfluxDB OSS v1 Documentation
I tried to use workaround describe there but it did not worked. I have found diff syntax to copy measurement one by one:
> SELECT * INTO openhab_db..Total_Energy_Prod FROM temp..Total_Energy_Prod group by *

It copied all data, but two times system return me I/O error. I have restarted system and error gone and I was able to copy all data.
After that old data appeared on charts/DB but new ones dissappered . Now of course again OH store items in DB, but they are not there …
I tried to reconfig Influxdb via openhabian-config, adding existed db info, but same result.
I am out of ideas where is a problem …

[rlkoshak (Rich Koshak)]

@sherif

In concole I got something like follows:

That’s showing that OH is successfully connecting to InfluxDB and successfully getting data and posting updates.

All signs so far point to either a misunderstanding on how OH stores data in InfluxDB or something wrong in InfluxDB. I haven’t used InfluxDB in years so I probably won’t be too much more help on that front. As soon as OH started to support adequate charting, I jumped back to rrd4j so I could remove two services (InfluxDB and Grafana) from my systems.

@sherif

I am out of ideas where is a problem …

It’s possible that over the years how OH stores data in InfluxDB has changed, meaning there might be some steps that you need to perform on the old InfluxDB data to make it compatible with how data is stored in OH now. Look through the announcements and release notes (Announcements category) for all the 3.x and 4.x releases to see if there is anything discussed about InfluxDB and breaking changes.

You might search the forum too. I know there has been a lot of swirl around InfluxDB over the years, mostly concerning the massive changes they made between versions 1 and 2, and again between 2 and 3.

[sherif (Marcin)]

@rlkoshak

It’s possible that over the years how OH stores data in InfluxDB has changed, meaning there might be some steps that you need to perform on the old InfluxDB data to make it compatible with how data is stored in OH now. Look through the announcements and release notes (Announcements category) for all the 3.x and 4.x releases to see if there is anything discussed about InfluxDB and breaking changes.

You might search the forum too. I know there has been a lot of swirl around InfluxDB over the years, mostly concerning the massive changes they made between versions 1 and 2, and again between 2 and 3.

Thanks for hints.
However this DB is quite straight forward. It store time stamp and data under measurement.
Once again I have re-installed it, restored data and configure OH. All ok, but no data. I have delete db via Influx CLI + open new one and is same time measurements appeared.
Then again I have deinstalled it, clean folder, installed via apt-get, configured via OH. It was working ok. Once gain I tried with restoring by I got I/O error and then I recognized that recent data dissappeared.
Then another clearing+deinstallation. I restored measurement one by one checking if it works. First few was ok: I can see recent results and old one (restored). Then I did same with following ones but imported only main measurements. Additional I have add retention policy and time condition:

> SELECT * INTO openhab.autogen.Total_Energy_Prod FROM openhab_db..Total_Energy_Prod WHERE time < '2024-01-06 22:00:00' group by *

Still I do not know where it was a problem. Maybe it was some file system issue, maybe internal DB error.

[rlkoshak (Rich Koshak)]

@sherif

However this DB is quite straight forward. It store time stamp and data under measurement.

The data is but it gets more complicated with retention policies and stuff like that.

I do know early on OH didn’t support retention policies very well and later on maybe they made it so you have to have one.

[sherif (Marcin)]

Maybe you are right … now I can see that OH4.1 put data with item/meausrement name, while recovered items are without it:

name: Energy_Used_D
time                item          value
----                ----          -----
1704150008390000000               1820.1797540875
1704236401585000000               0.8362655892
1704322801416000000               0.326976216
1704841200712000000 Energy_Used_D 62.2411639429
1704927600650000000 Energy_Used_D 69.337

Anyway it looks that my 4th careful restore is still working well