Chart won't show all data

  • Platform information:

    • Hardware: RPi3
    • OS: openhabian
    • Java Runtime Environment: 1.8.0_152
    • openHAB version: openHAB 2.3.0 Release Build
  • Issue of the topic:
    My Charts only show a fraction of the data. The hourly chart seems to be fine but the daily chart is already missing the last 2 hours and the weekly charts only show about 1,25 days worth of data. The persistence service has been running for 2 days. I tried to delete all the storage files in hope that it would fix the problems … with no effect … I already had multiple days of data but with the same result.
    I also reinstalled rrd4j …

here is a compilation of screenshots:

And here is my configuration:
home.items

Group gTH01_Sensors
Number SonoffTH01_T "Temperatur Serverraum [%.1f °C]" <temperature> (gTH01_Sensors) { mqtt="<[broker:tele/SonoffTH01/SENSOR:state:JSONPATH($.AM2301.Temperature)]" }
Number SonoffTH01_H "Feuchtigkeit Serverraum [%.1f %%rF]" <humidity> (gTH01_Sensors) { mqtt="<[broker:tele/SonoffTH01/SENSOR:state:JSONPATH($.AM2301.Humidity)]" }

home.sitemap

                Text label="Chart TH10" icon="chart" {
                        Switch item=Day_Period label="Chart Period" icon="time" mappings=[0="Hour", 1="Day", 2="Week", 3="Month", 4="Year"]
                        Chart item=gTH01_Sensors period=h refresh=60000 visibility=[Day_Period==0]
                        Chart item=gTH01_Sensors period=D refresh=60000 visibility=[Day_Period==1]
                        Chart item=gTH01_Sensors period=W refresh=60000 visibility=[Day_Period==2]
                        Chart item=gTH01_Sensors period=M refresh=60000 visibility=[Day_Period==3]
                        Chart item=gTH01_Sensors period=Y refresh=60000 visibility=[Day_Period==4]
                }

rrd4j.persist (already played around with this one … a lot!)

// persistence strategies have a name and a definition and are referred to in the "Items" section
Strategies {
// for rrd charts, we need a cron strategy
        everyDay : "0 0 0 * * ?"
        everyHour : "0 0 * * * ?"
        everyMinute : "0 * * * * ?"
        default = everyUpdate
}


/*
 * Each line in this section defines for which item(s) which strategy(ies) should be applied.
 * You can list single items, use "*" for all items or "groupitem*" for all members of a group
 * item (excl. the group item itself).
 */
Items {
        // persist all items once a day and on every change and restore them from the db at startup
        gTH01_Sensors*,gSonoffB_Sensors*: strategy = everyUpdate, everyMinute, everyHour, everyDay, restoreOnStartup
        gOctoTemp*:  strategy = everyUpdate, restoreOnStartup
        gRSSI*: strategy = everyUpdate, everyMinute, restoreOnStartup
        gReachable*: strategy = everyUpdate, everyMinute, restoreOnStartup
}

rrd4j.cfg (I configured it once, then read that it isn’t needed)

# please note that currently the first archive in each RRD defines the consolidation
# function (e.g. AVERAGE) used by OpenHAB, thus only one consolidation function is
# fully supported
#
# default_numeric and default_other are internally defined defnames and are used as
# defaults when no other defname applies

#Sensors.def=GAUGE,90,0,U,30
#Sensors.archives=AVERAGE,0.5,1,365:AVERAGE,0.5,7,365
#Sensors.items=SonoffB13_T1,SonoffB13_T2,SonoffB13_T3,SonoffB13_T4,SonoffB13_T5,SonoffTH01_T,SonoffTH01_H,OctoprintPrinterBedTempTarget,OctoprintPrinterBedTemp,OctoprintPrinterHotEndTempTarget,OctoprintPrinterHotEndTemp

I already rebooted openhab a couple of times …
Thank you for your help :slight_smile:

I have similar setup, no issues, except I’m using a RPi2. Comparing what I have against what’s posted, the only difference is … In persistence you have default = everyUpdate. I have default = everyChange and my items below, are all on a separate line. I never changed my rrd4j.cfg so maybe setting it back to default would help. Hope this helps.

I renamed my rrd4j.cfg and then uninstalled rrd4j and reinstalled it again. I also changed my rrd4j.persist to “everyChange” even though I don’t thank that’s the problem.

I also deleted all of my existing *.rrd files. Will keep you posted :slight_smile: Thanks for the reply :slight_smile:

Try this:

  1. Stop OH if it is running.
  2. Delete the contents of /var/lib/openhab2/cache and /var/lib/openhab2/tmp. For manual installations these folders are in your OH home folder under userdata. DO NOT DELETE THE FOLDERS THEMSELVES, JUST THE CONTENTS.
  3. Start OH.

The above is quoted from rlkoshak and pertains to numerous possible issues. I guess sometimes, you have no choice but to take the trash out and hope the smell goes away :face_with_raised_eyebrow:

1 Like

This didn’t work btw :slight_smile:

Trying this one now. I need 24 hourse to verify :slight_smile: I will keep you posted :slight_smile:

It didn’t work.

but I got a new bright idea. Instead of trying to persist gReachable* (which is not a number but “ON” or “OFF”) I decided to not do that. Maybe that fixes the problem :slight_smile:

I was hoping we could find a quick solution, but I’m still new and learning everyday.
I sent an invite to vzorglub, hopefully he wont mind taking a look. I’ve done a ton of reading and vzorglub is one of those guys that has a solution more often than not.

Good luck, keep me posted.

I had to go file digging but I found some of my old configs.
for Items:

yGroup Home_Sensor_Chart (Office, Charts)
//Number Home_Sensor_Chart_Period "Period" (Office)
//Number Home_Temp_Office "Office Temperature [%.1f °F]" <temperature> (Home_Sensor_Chart) { channel="exec1:command:officeTemp:output" }
//Number Home_Humid_Office "Office Humidity [%.1f %%]" <humidity> (Home_Sensor_Chart) { channel="exec1:command:officeTemp:output" }

// Output of command line execution
//String Home_Temp_Office { channel="exec1:command:officeTemp:output" }
//String Home_Humid_Office { channel="exec1:command:officeHumid:output" }

For Things:

Thing exec:command:officeTemp [
//	command="python /etc/openhab2/scripts/OfficeTemp.py",
//	interval=45,
//	autorun=false,
//	transform="REGEX(Temp=(.*?))(Humidity=(.*?)'%)"]

Sitemap:

sitemap HomeTemp label="Home Office Sensor"
{
	Frame {
		Text item=Home_Temp_Office
		Text item=Home_Humid_Office
	}
	Frame {
		Switch item=System_Temperature_Chart_Period mappings=[0="1h", 1="4h", 2="8h", 3="12h", 4="24h"]
		Chart  item=System_Temperature_Chart period=h   refresh=60000 visibility=[Home_Sensor_Chart_Period==0, Home_Sensor_Chart_Period=="Uninitialized"]
		Chart  item=System_Temperature_Chart period=4h  refresh=60000 visibility=[Home_Sensor_Chart_Period==1]
		Chart  item=System_Temperature_Chart period=8h  refresh=60000 visibility=[Home_Sensor_Chart_Period==2]
		Chart  item=System_Temperature_Chart period=12h refresh=60000 visibility=[Home_Sensor_Chart_Period==3]
		Chart  item=System_Temperature_Chart period=D   refresh=60000 visibility=[Home_Sensor_Chart_Period==4]
	}
}

You may not need a thing item, I was using it to call for the script and transformation. I’m thinking it was also allowing me to have a string and number in my items file? You are getting a reading on your chart so I would try the thing file last.
Do you have Day_Period (from your site map) in your items file? I also notice that my site map has uninitialized at the end if the first chart line for period=h.

BTW ignore the // in the code, I had stopped it from running a week or so back. Loaning sensor to a friend.

I am actually not quite sure yet what my problem is but i don’t think it’s the chart but the datacollection.
I changed my persist file and I now directly list the relevant temperature sensor. I still have groups in it but I also list some item directly now.

I get some odd results from the REST API:

{“name”:“SonoffTH01_T”,“datapoints”:“227”,“data”:[{“time”:1532117160000,“state”:“36.60000000000000142108547152020037174224853515625”},{“time”:1532117370000,“state”:“36.5857142857142889624810777604579925537109375”},{“time”:1532117580000,“state”:“36.55714285714285693984493263997137546539306640625”},{“time”:1532117790000,“state”:“36.5”},{“time”:1532118000000,“state”:“36.4714285714285750827912124805152416229248046875”},{“time”:1532118210000,“state”:“36.41428571428571814294627984054386615753173828125”},{“time”:1532118420000,“state”:“36.5”},

this is just a small sample size but if I transform them into normal timestamps I get this:
1532117160000: Friday, July 20, 2018 8:06:00 PM
1532117370000: Friday, July 20, 2018 8:09:30 PM
1532117580000: Friday, July 20, 2018 8:13:00 PM
1532117790000: Friday, July 20, 2018 8:16:30 PM
1532118000000: Friday, July 20, 2018 8:20:00 PM
1532118210000: Friday, July 20, 2018 8:23:30 PM
1532118420000: Friday, July 20, 2018 8:27:00 PM

With the strategy “everyMinute” I should get a datapoint every minute right?

I changed my rrd4j.persist file and removed the “everyChange” strategy from all Items.

It looks like this now:

// persistence strategies have a name and a definition and are referred to in the "Items" section
Strategies {
// for rrd charts, we need a cron strategy
        everyDay : "0 0 0 * * ?"
        everyHour : "0 0 * * * ?"
        everyMinute : "0 * * * * ?"
        default = everyChange
}


/*
 * Each line in this section defines for which item(s) which strategy(ies) should be applied.
 * You can list single items, use "*" for all items or "groupitem*" for all members of a group
 * item (excl. the group item itself).
 */
Items {
        // persist all items once a day and on every change and restore them from the db at startup
        //gTH01_Sensors*,gSonoffB_Sensors*: strategy = everyChange, everyMinute, restoreOnStartup
        SonoffTH01_T, SonoffTH01_H:  strategy = everyMinute, restoreOnStartup
        SonoffB13_T1, SonoffB13_T2, SonoffB13_T3, SonoffB13_T4, SonoffB13_T5:  strategy = everyMinute, restoreOnStartup
        gOctoTemp*:  strategy =  everyMinute, restoreOnStartup
        gRSSI ,gRSSI*: strategy =  everyMinute, restoreOnStartup
}

hopefully that fixes the problem…


see: The strategy everyMinute (60 seconds) has to be used, otherwise no data will be persisted (stored).

gTH01_Sensors*, gSonoffB_Sensors*, gOctoTemp*, gRSSI*, gReachable*: strategy = everyUpdate, everyMinute, restoreOnStartup

Did you do any change to the rrd4j.cfg?

I do - see my rrd4j.persist file in the previous post

Since I changed it I did a reboot (is that enough to load the new persist file?)

when I look at is through REST API the last 5 entries were from:

1532172390000: Saturday, July 21, 2018 13:26:30 AM
1532172600000: Saturday, July 21, 2018 13:30:00 AM
1532172810000: Saturday, July 21, 2018 13:33:30 AM
1532173020000: Saturday, July 21, 2018 13:37:00 AM
1532173230000: Saturday, July 21, 2018 13:40:30 AM

the last for entries in the events.log regarding the sensor are:

2018-07-21 13:39:58.891 [vent.ItemStateChangedEvent] - SonoffTH01_T changed from 36.3 to 36.2
2018-07-21 13:40:28.895 [vent.ItemStateChangedEvent] - SonoffTH01_T changed from 36.2 to 36.3
2018-07-21 13:44:28.924 [vent.ItemStateChangedEvent] - SonoffTH01_T changed from 36.3 to 36.2
2018-07-21 13:45:29.049 [vent.ItemStateChangedEvent] - SonoffTH01_T changed from 36.2 to 36.3
2018-07-21 13:47:00.415 [vent.ItemStateChangedEvent] - SonoffTH01_T changed from 36.3 to 36.4

It’s still the same problem

I changed it once. Then I removed it and reinstalled the rrd4j addon via paperUI. Since then I haven’t even touched it :slight_smile:

here is the complete content of my rrd4j.cfg file:

# please note that currently the first archive in each RRD defines the consolidation
# function (e.g. AVERAGE) used by OpenHAB, thus only one consolidation function is
# fully supported
#
# default_numeric and default_other are internally defined defnames and are used as
# defaults when no other defname applies

#<defname>.def=[ABSOLUTE|COUNTER|DERIVE|GAUGE],<heartbeat>,[<min>|U],[<max>|U],<step>
#<defname>.archives=[AVERAGE|MIN|MAX|LAST|FIRST|TOTAL],<xff>,<steps>,<rows>
#<defname>.items=<list of items for this defname>

The way rrd4j does save data on your system doesn’t correlate with the expactations from a default .cfg file. Could you raise the log-level to DEBUG for rrd4j and restart. Doing that should show the used .cfg.(Please post those lines)
Not only the timings of saved data, also what is persisted might be caused by that.

for future reference: the command to set the log-level to Debug is:

log:set DEBUG org.openhab.persistence.rrd4j

it is entered in the karaf console :slight_smile:

I rebootet this is the result:

I deleted timestamps to make it a little bit more readable

[org.openhab.persistence.rrd4j ] - BundleEvent STARTING - org.openhab.persistence.rrd4j

[stence.rrd4j.internal.RRD4jActivator] - RRD4j persistence bundle has been started.

[org.openhab.persistence.rrd4j ] - BundleEvent STARTED - org.openhab.persistence.rrd4j

[sistence.rrd4j.internal.RRD4jService] - Created sensors = GAUGE heartbeat = 90 min/max = 0.0/NaN step = 30 2 archives(s) = [ AVERAGE xff = 0.5 steps = 1 rows = 365 AVERAGE xff = 0.5 steps = 7 rows = 365] 11 items(s) = [SonoffB13_T1 SonoffB13_T2 SonoffB13_T3 SonoffB13_T4 SonoffB13_T5 SonoffTH01_T SonoffTH01_H OctoprintPrinterBedTempTarget OctoprintPrinterBedTemp OctoprintPrinterHotEndTempTarget OctoprintPrinterHotEndTemp ]

[sistence.rrd4j.internal.RRD4jService] - Created default_other = GAUGE heartbeat = 3600 min/max = NaN/NaN step = 1 6 archives(s) = [ MAX xff = 0.999 steps = 1 rows = 3600 MAX xff = 0.999 steps = 10 rows = 1440 MAX xff = 0.999 steps = 60 rows = 1440 MAX xff = 0.999 steps = 900 rows = 2880 MAX xff = 0.999 steps = 21600 rows = 1460 MAX xff = 0.999 steps = 86400 rows = 3650] 0 items(s) =

[sistence.rrd4j.internal.RRD4jService] - Created default_numeric = GAUGE heartbeat = 60 min/max = NaN/NaN step = 60 6 archives(s) = [ AVERAGE xff = 0.5 steps = 1 rows = 480 AVERAGE xff = 0.5 steps = 4 rows = 360 AVERAGE xff = 0.5 steps = 14 rows = 644 AVERAGE xff = 0.5 steps = 60 rows = 720 AVERAGE xff = 0.5 steps = 720 rows = 730 AVERAGE xff = 0.5 steps = 10080 rows = 520] 0 items(s) =

[org.openhab.persistence.rrd4j ] - ServiceEvent REGISTERED - {org.openhab.core.persistence.PersistenceService}={Sensors.def=GAUGE,90,0,U,30, Sensors.archives=AVERAGE,0.5,1,365:AVERAGE,0.5,7,365, service.id=336, Sensors.items=SonoffB13_T1,SonoffB13_T2,SonoffB13_T3,SonoffB13_T4,SonoffB13_T5,SonoffTH01_T,SonoffTH01_H,OctoprintPrinterBedTempTarget,OctoprintPrinterBedTemp,OctoprintPrinterHotEndTempTarget,OctoprintPrinterHotEndTemp, service.bundleid=214, service.scope=bundle, service.pid=org.openhab.rrd4j, component.name=org.openhab.persistence.rrd4j, component.id=212} - org.openhab.persistence.rrd4j

[4j.internal.charts.RRD4jChartServlet] - Starting up rrd chart servlet at /rrdchart.png

[org.openhab.persistence.rrd4j ] - ServiceEvent REGISTERED - {javax.servlet.ServletContext}={osgi.web.version=1.12.0, osgi.web.contextpath=/, service.id=339, osgi.web.symbolicname=org.openhab.persistence.rrd4j, service.bundleid=214, service.scope=singleton, osgi.web.contextname=custom} - org.openhab.persistence.rrd4j

[org.openhab.persistence.rrd4j ] - ServiceEvent REGISTERED - {org.openhab.ui.chart.ChartProvider}={service.id=338, service.bundleid=214, service.scope=bundle, component.name=org.openhab.persistence.rrd4j.chartservlet, component.id=213} - org.openhab.persistence.rrd4j

I dont see anything about the .cfg file though …

Danke Jürgen! :slight_smile:

I started a chart from a different sensor to see if everything is working. I changed my time periods to be Hour, 12h, Day, Month and my charts are working. I ran DEBUG to compare with your DEBUG. Here are the results:

2018-07-21 10:51:55.583 [DEBUG] [org.openhab.persistence.rrd4j       ] - BundleEvent STARTING - org.openhab.persistence.rrd4j

2018-07-21 10:51:55.591 [DEBUG] [stence.rrd4j.internal.RRD4jActivator] - RRD4j persistence bundle has been started.

2018-07-21 10:51:55.600 [DEBUG] [org.openhab.persistence.rrd4j       ] - BundleEvent STARTED - org.openhab.persistence.rrd4j

2018-07-21 10:51:55.670 [DEBUG] [sistence.rrd4j.internal.RRD4jService] - Created default_other = GAUGE heartbeat = 3600 min/max = NaN/NaN step = 1 6 archives(s) = [ MAX xff = 0.999 steps = 1 rows = 3600 MAX xff = 0.999 steps = 10 rows = 1440 MAX xff = 0.999 steps = 60 rows = 1440 MAX xff = 0.999 steps = 900 rows = 2880 MAX xff = 0.999 steps = 21600 rows = 1460 MAX xff = 0.999 steps = 86400 rows = 3650] 0 items(s) = []

2018-07-21 10:51:55.677 [DEBUG] [sistence.rrd4j.internal.RRD4jService] - Created default_numeric = GAUGE heartbeat = 60 min/max = NaN/NaN step = 60 6 archives(s) = [ AVERAGE xff = 0.5 steps = 1 rows = 480 AVERAGE xff = 0.5 steps = 4 rows = 360 AVERAGE xff = 0.5 steps = 14 rows = 644 AVERAGE xff = 0.5 steps = 60 rows = 720 AVERAGE xff = 0.5 steps = 720 rows = 730 AVERAGE xff = 0.5 steps = 10080 rows = 520] 0 items(s) = []

2018-07-21 10:51:55.686 [DEBUG] [org.openhab.persistence.rrd4j       ] - ServiceEvent REGISTERED - {org.openhab.core.persistence.PersistenceService}={service.id=4334, service.bundleid=238, service.scope=bundle, component.name=org.openhab.persistence.rrd4j, component.id=267} - org.openhab.persistence.rrd4j

2018-07-21 10:51:56.107 [DEBUG] [4j.internal.charts.RRD4jChartServlet] - Starting up rrd chart servlet at /rrdchart.png

2018-07-21 10:51:56.154 [DEBUG] [org.openhab.persistence.rrd4j       ] - ServiceEvent REGISTERED - {javax.servlet.ServletContext}={osgi.web.version=1.12.0, osgi.web.contextpath=/, service.id=4337, osgi.web.symbolicname=org.openhab.persistence.rrd4j, service.bundleid=238, service.scope=singleton, osgi.web.contextname=custom} - org.openhab.persistence.rrd4j

2018-07-21 10:51:56.174 [DEBUG] [org.openhab.persistence.rrd4j       ] - ServiceEvent REGISTERED - {org.openhab.ui.chart.ChartProvider}={service.id=4336, service.bundleid=238, service.scope=bundle, component.name=org.openhab.persistence.rrd4j.chartservlet, component.id=268} - org.openhab.persistence.rrd4j

I noticed my log did not have the “Created sensors = GAUGE…” only the Created default_other. Not sure if that means anything or not.

Here is a screen shot of weekly and no issues with other time periods.

that is indeed weird.

Here is my rrd4j.cfg file before I reset it a week ago … i also restarted openhab multiple times since then:

# please note that currently the first archive in each RRD defines the consolidation
# function (e.g. AVERAGE) used by OpenHAB, thus only one consolidation function is
# fully supported
#
# default_numeric and default_other are internally defined defnames and are used as
# defaults when no other defname applies

Sensors.def=GAUGE,90,0,U,30
Sensors.archives=AVERAGE,0.5,1,365:AVERAGE,0.5,7,365
Sensors.items=SonoffB13_T1,SonoffB13_T2,SonoffB13_T3,SonoffB13_T4,SonoffB13_T5,SonoffTH01_T,SonoffTH01_H,OctoprintPrinterBedTempTarget,OctoprintPrinterBedTemp,OctoprintPrinterHotEndTempTarget,OctoprintPrinterHotEndTemp

It looks like it is still stored somewhere … but where and how do I change it back?

Run this command: sudo find -name “rrd4j.cfg”
I have 2 locations ./srv/openhab2-conf/services/rrd4j.cfg and ./etc/openhab2/services/rrd4j.cfg
its also list the proc thats running but it’s not a file or directory.

I think this will list all locations of your rrd4j,cfg so you can look and compare.
BTW I checked both locations and they are identical, maybe something in the /srv/openhab2-conf/services/rrd4j.cfg is not #commented out.

would have been cool but unfortunately both files are identical …

maybe I cannot delete the configuration of the “sensors” group I could try and change it to something that gives me a good result?

You can try my set up and to see if it helps. Ignore the setup I originally posted, it was a sensor connected to my Pi, thats running openhab GPIO pins. Bellow is an ESP8266, with Esp-easy firmware, a AM2302 sensor and talking via MQTT. Seems more like the hardware your using.

For site map:

Frame {
		Text item=ESP_Easy_Temp
		Text item=ESP_Easy_Humid
	}
	Frame {
		Switch item=Home_Sensor_Chart_Period mappings=[0="1h", 1="12h", 2="Day", 3="Week", 4="Month"]
		Chart  item=Home_Sensor_Chart period=h   refresh=60000 visibility=[Home_Sensor_Chart_Period==0] //, Home_Sensor_Chart_Period=="Uninitialized"]
		Chart  item=Home_Sensor_Chart period=12h  refresh=60000 visibility=[Home_Sensor_Chart_Period==1]
		Chart  item=Home_Sensor_Chart period=D  refresh=60000 visibility=[Home_Sensor_Chart_Period==2]
		Chart  item=Home_Sensor_Chart period=W refresh=60000 visibility=[Home_Sensor_Chart_Period==3]
		Chart  item=Home_Sensor_Chart period=M   refresh=60000 visibility=[Home_Sensor_Chart_Period==4]
	}

Items:

Group Home_Sensor_Chart (Office, Charts)
Number Home_Sensor_Chart_Period "Period" (Office)
Number ESP_Easy_Temp "Esp8266 Temp [%.1f °F]" <temperature> (Home_Sensor_Chart)
	{ mqtt="<[pibroker:/Esp/DS/Temp:state:default]" }

Number ESP_Easy_Humid "Esp8266 Humid [%.1f %%]" <humidity> (Home_Sensor_Chart)
	{ mqtt="<[pibroker:/Esp/DS/Humid:state:default]" }	

Persistence:

Strategies {
	// for rrd chart cron strategy every minute
	everyMinute : "0 * * * * ?"
	// get data reduced for older values to keep database small
	everyHour : "0 0 * * * ?"
	everyDay : "0 0 0 * * ?"

	default = everyChange
}

Items {
	// additionally persist Items
	LivingRoom_Light_Temp : strategy = everyUpdate, everyMinute
	LivingRoom_Light_Humidity : strategy = everyUpdate, everyMinute
	Home_Sensor_Chart* : strategy = everyUpdate, everyMinute
//	Home_Temp_Office : strategy = everyUpdate, everyMinute
//	Home_Humid_Office : strategy = everyUpdate, everyMinute
	ESP_Easy_Temp : strategy = everyUpdate, everyMinute
	ESP_Easy_Humid : strategy = everyUpdate, everyMinute
}

I had the ESP_Easy_Temp and Humid already in persistence and I assume that is the reason I was able to create the site map, automatically having over a month of readings.

If testing with this I would just comment out what you have, copy paste to a new file or place it below your code. My groups are different so you may need to re-name a few things but keep your SonoffTH01_T and SonoffTH01_H names the same. If you get good results it will rule out an issue with your rrd4j.cfg.

EDIT: Reading over after posting :roll_eyes:
Use what I posted, changing only the ESP_Easy_Temp, ESP_Easy_Humid to SonoffTH01_T and SonoffTH01_H in all places(except Number items that have your MQTT connected to it). You may want to delete LivingRoom_Light_Temp and Humidity items from the persistence file. Should be quick to test doing it this way.