Novelan Heatpump Binding doesn't reply useful values for state, extended_state and massflow

Dear openhab community,

I am currently trying to get some measurements from my Novelan heatpump done with openhab, influxdb and grafana.
All usual temperature values are being read out from Novelan and stored successfully in influxdb, however I can not get useful data from the following items:

  • state
  • extended_state
  • massflow

This is what is stored in influxdb:


select * from “HeatPump_State”
1544126940057000000 Wärmepumpe läuft: 00:00:00


select * from “HeatPump_State_Ext”
1544127060100000000 Heizbetrieb: 00:00:00


select * from “HeatPump_Massflow”
1544127120052000000 0

Bear in mind that the results above are logged every minute.
Here is my items file:

Number HeatPump_Temperature_Outside   "Wärmepumpe Außentemperatur [%.1f °C]"   <temperature> (gHeatpump) { novelanheatpump="temperature_outside" }
Number HeatPump_Temperature_Supplay   "Vorlauf [%.1f °C]"  <temperature> (gHeatpump) { novelanheatpump="temperature_supplay" }
Number HeatPump_Temperature_Return   "Rücklauf [%.1f °C]"  <temperature> (gHeatpump) { novelanheatpump="temperature_return" }
Number HeatPump_Temperature_Reference_Return   "Rücklauf Soll [%.1f °C]" <temperature> (gHeatpump) { novelanheatpump="temperature_reference_return" }
Number HeatPump_Temperature_Servicewater   "Warmwasser Ist [%.1f °C]"   <temperature> (gHeatpump) { novelanheatpump="temperature_servicewater" }
Number HeatPump_Temperature_Reference_Servicewater   "Warmwasser Soll [%.1f °C]"  <temperature> (gHeatpump) { novelanheatpump="temperature_servicewater_reference" }
String HeatPump_State   "Status [%s]"   <temperature> (gHeatpump) { novelanheatpump="state" }
String HeatPump_State_Ext   "Status [%s]"   <temperature> (gHeatpump) { novelanheatpump="extended_state" }
Number HeatPump_Massflow    "Massenstrom [%.1f L/h]" <energy> (gHeatpump) { novelanheatpump="massflow" }

and the persistence:

Strategies {
everyMinute : “0 * * * * ?”
everyHour : “0 0 * * * ?”
everyDay : “0 0 0 * * ?”

Items {
WeatherInformation_Temperatur : strategy = everyChange, everyMinute
HeatPump_Temperature_Outside : strategy = everyChange, everyMinute
HeatPump_Temperature_Supplay : strategy = everyChange, everyMinute
HeatPump_Temperature_Return : strategy = everyChange, everyMinute
HeatPump_Temperature_Reference_Return : strategy = everyChange, everyMinute
HeatPump_Temperature_Servicewater : strategy = everyChange, everyMinute
HeatPump_Temperature_Reference_Servicewater : strategy = everyChange, everyMinute
HeatPump_State : strategy = everyChange, everyMinute
HeatPump_State_Ext : strategy = everyChange, everyMinute
HeatPump_Massflow : strategy = everyChange, everyMinute

I have seen some blogs where massflow and state had some more reasonable values.
If anyone has an idea, I’d be more than welcome.

Thanks so much in advance

what is the actual state of these 3 Items within openHAB2?
How many entries do you have in InfluxDb for these 3 Items? (only 1 or more?)

Use the console and:

items list |grep HeatPump_Massflow

By the way: since you already have all Items in a group, you can persist the members of the Group:


Strategies {
	everyMinute : "0 * * * * ?"
	default = everyChange

Items {
	gHeatpump* : strategy = everyChange

Tip: You don’t really need anything more than everyChange to persist. That’s enough. everyMinute is redundant if you capture everyChange.

Imagine the following scenario:
T=0 Temp Item changes at Time=0 from NULL to 20 °C (at OH2 startup)
T=0 Change is persisted. Value of 20 °C enters in InfluxDB
T=1 One min after T=0 you persist again the same value (20 °C)
T=2 Two mins after T=0 you persist again the same value (20 °C)
T=3 Temp Item changes at from 20 °C to 22 °C. Change is persisted. Value of 22 °C enters in InfluxDB
T=4 One min after T=3 you persist again the same value (22 °C)
…so forth

Result: You will have “bogus” data in your Database since when T=1, T=2 & T=4: you don’t have an actual reading of the Temperature… you just persist again and again the same value that is stored in the Item state.

Also: If the Temp sensor goes AWOL you will still persist every minute the temperature and you will think that all is ok :slight_smile:

I got this tip from @rlkoshak. I need to find the original post where he taught me this :slight_smile:
edit: Found it here

Ps: How to use code fences

thanks for your swift response. The shown results are just an example. I have plenty of lines with the same value. I will first of all follow your hints and see if this changes anything.

Why I did the everyMinute presistence? I thought if nothing changes but I still want a clean and correct line in grafana, then maybe grafana would destroy the layout of the graph. I hope you understand what I mean.

Grafana will plot just fine the data that it finds in the DB

See example with only everyChange:

openhab> items list |grep HeatPump_Massflow
HeatPump_Massflow (Type=NumberItem, State=0, Label=Massenstrom, Category=energy, Groups=[gHeatpump])

Thanks for the grafana hint. Just changed it and will give it a try.

This is your problem.
The Item state is not getting updated from the binding
You need to troubleshoot the binding config/connection
Go over again and maybe put the binding in DEBUG log level to see why you are not getting any readings for these 3 Items

openhab> items list | grep HeatPump_State_Ext
HeatPump_State_Ext (Type=StringItem, State=Heizbetrieb: 00:00:00, Label=Status, Category=temperature, Groups=[gHeatpump])

Same here. The time stamp doesn’t get filled and it is always in “Heizbetrieb”. Could it be a SW issue with the Novelan. I will try to get through the binding description but jI did exactly the same as for the working ones like supplay and return.

1 Like

Yeah… if the Item doesn’t get its state updated correctly from the Binding: you will persist zeros :slight_smile:

from the console, check the full name of the (bundle) binding with:

bundle:list -s|grep -i novelan

and then increase the log level on it:

log:set DEBUG org.openhab.binding.novelanheatpump //check this name

remember to set it back to

log:set INFO ...

to avoid log spam in openhab.log

log:set DEBUG org.openhab.binding.novelanheat

did it. Where do I see the output now. Openhab logviewer?

yes (if you are using frontail)

or from the linux console:

tail -f /var/log/openhab2/*.log

or from the openhab console:


Thanks. Do I need to restart openhab to get the log level changes activated?

no, they are immediate

ok, in that case no further details yet from the logfile.

I don’t know if I can help you any more
i don’t use this specific binding and I don’t know what could be the root-cause of your problem (3 out of 9 Items not getting state updates from the binding…) :frowning:

no worries. You already helped me a lot. Maybe there is someone who has stumbled upon the same issue. Thanks so much again!!

1 Like

what is the version of the firmware on the Novelan/Luxtronic heat pump?

I checked on and I didn’t find any open issue for this binding (maybe you want to create a new issue about this)

I found some info that the massflow and many others require firmware > 1.3

another crazy idea:
since these 3 Items are the last ones in your Items file, try the following:
remove them from the current items file, create a new items file and place these 3 alone there making sure they are typed correctly.
Maybe a strange character or something is creating a problem with your existing file.

that was a very good idea. Tried to outsource it to another file. Removed the “umlauts” as well but nothing helps. Still all set to 0. Will follow your advice and open an issue at github.


1 Like

That appears to be incorrect. It should be org.openhab.binding.novelanheatpump

1 Like

Thanks. You are right. Just set it to DEBUG now but no further infos. Will continue an issue at Github:

  1. Your DB shows Massflow of 0, which matches your event log output:
2018-12-09 22:52:00.055 [vent.ItemStateChangedEvent] - HeatPump_Massflow changed from NULL to 0
  1. Where in your configuration are the strings Wärmepumpe läuft and Heizbetrieb defined?
  2. Turns out this binding is severely lacking in good debug output.

Try installing this build and setting the output level to TRACE instead.
You should see some additional output:

item 'W': publishing state 'X' for type 'Y'


Values read from heatpump:
[...] [...]