NIBE Heatpump widget

[supersjel (Michel)]

Widget (and rule) for a NIBE heatpump (using the NIBE uplink binding). It shows current status (heating, cooling, hotwater etc) and details for the heat exchangers. Several items can be pressed to show a popover with a day value graph. Possibly it’s a good starting point for other heatpumps. It they have similar items you can select them in the widget. Default only setting the NIBE group/equipment item is enough to get it working.

Installation
The widget requires a some things to work that can’t be installed automatically. Detailed instructions (and manual) can be found in my github project. In short:

• Add the required widget images to the html folder in your openHAB configuration
• Install the NIBE uplink binding
• Install the java scripting engine.
• Create a new rule, move to code tab and replace content with the timertick rule.
• Create a new rule, move to code tab and replace content with the heatpump rule.
• Configure widget & rule (easiest way by using group name, check github docs for more details)

Screenshots

Changelog

Version 1.7

• fixed: issues for OH 4.x (% pump speed incorrect, tested on 4.02 & 4.03)
• added: var for openhab URL in rule (used in first time run to init cached history)

Version 1.6

• fixed: bug in cooling detection (if you’re on 1.5, only rule needs to be updated)

Version 1.5

• added: Made it official, moved code to github (previous versions were on forum topic)
• added: Change to standard rule using helper methods
• fixed: openHAB Marketplace bug (replaced all default props with formula)

Version 1.4

• added: Calculate rolling sum of minutes active in each mode in last 3 hrs

Version 1.3

• added: Calculate rolling sum of minutes active in each mode in 24 hrs

Version 1.2

• added: Estimate ground temperature (lowest brine-in in 24 hrs)
• added: Added brine, boiler, heat/cool temperature popup

Version 1.1

• added: temperature graph popup

Version 1.0

• added: Reads heatpump raw data and derives what’s it is doing (nothing, active heating, passive heating, cooling, boiler heating)
• added: Write result in new item mode (automatic added if needed)
• added: Store temporary items in cache (that survives rule init/sate) with reset item (added if needed)

Resources

https://raw.githubusercontent.com/supersjellie/openhab-nibe-heatpump/main/widget/widget.yaml

[JustinG]

It’s great to see the continuing work on this this, thanks.

However, you’re running up against the limitations of the marketplace. By making the resource link a link to a repo and not just to widget file, users cannot install this widget through the MainUI marketplace screen; they will get an error. Right now, there’s just not really a good way to bundle widgets and rules together via the marketplace. In the past, I’ve resorted to posting separate widget and rule marketplace topics and then making sure there are links between them. That way the widget can be installed via the widget marketplace and the rule via the rule templates installation.

If you really want users to go through the repo because of all the config documentation there, then I suggest just moving this back to its original topic and not having it in the marketplace. But then they will have to cut an paste the code in still. The only way to get the marketplace installation to work will be to split it up into different topics.

[supersjel (Michel)]

I did not know that. So under resource the yaml itself must be put? How about the necessary images? Same issue? Than my code for a Daalderop fan(also rule and widget) has the same issue I fear.

[JustinG]

@supersjel

So under resource the yaml itself must be put?

There are two options. Either have the actual widget yaml in code fences under the resource heading or have a link directly to the yaml file (e.g., github raw view link). The MainUI marketplace code can then extract the yaml code for direct installation. As of right now, there are no other mechanisms that work.

@supersjel

How about the necessary images? Same issue?

These will still have to be manually downloaded and installed by the user. Complex widgets like this are just always going to have slightly more complex installations.

You’ve got all the images as pngs, if you created those pngs from svg or recreated the images as svgs, then you could use something like this system to directly incorporate the images into the widget. That is a lot more work, however.

[supersjel (Michel)]

Wow, if I understand right I would have to create three items in the marketplace (one for the widget and two more for the rules). Users would have to install all three of them and still have to download the images (the SVG option is cool, but looks like a lot of work indeed).

Sounds like almost the same amount of manual actions if one uses the installation instructions in GitHub. Maybe the first suggestion, just continue in the original post and link that to the GitHub isn’t that bad? I should probably delete this one in the marketplace because it can’t work and could confuse people?

[JustinG]

@supersjel

Wow, if I understand right I would have to create three items in the marketplace (one for the widget and two more for the rules). Users would have to install all three of them and still have to download the images

Correct

@supersjel

Sounds like almost the same amount of manual actions if one uses the installation instructions in GitHub. Maybe the first suggestion, just continue in the original post and link that to the GitHub isn’t that bad?

Alas, I think that’s true in this case. The ability to bundle marketplace contributions has been requested but I don’t know if there is any movement on this issue yet.

@supersjel

I should probably delete this one in the marketplace because it can’t work and could confuse people?

I don’t think you have permission to do so now that there are other posts here. You would have to ask a moderator to do that.

The good news is that you haven’t added the published tag to the topic so that right now it will only be visible in the marketplace to users that have the Show Unpublished Entries option selected in their settings.

As the contents of this topic are displayed in the marketplace view, you could just add a block at the top with a quick explanation and a link to the repo there. That people who do find it through the marketplace can quickly get to the install instructions.

[jlikonen (Jari Likonen)]

Many thanks for this nice widget. I will get my Nibe S1255 ground source heat pump some time during summer time so I will install this widget then. Any ideas whether it will work under OH4?

[supersjel (Michel)]

@JustinG

As the contents of this topic are displayed in the marketplace view, you could just add a block at the top with a quick explanation and a link to the repo there. That people who do find it through the marketplace can quickly get to the install instructions.

This sounds like a good compromise. I like that it can be found in openHAB and whatever I do it needs a bit explaination and manual actions. I’ll try/test the raw GitHub link to the widget code in de resource section

[supersjel (Michel)]

@jlikonen

Any ideas whether it will work under OH4?

I’m running in the production 3.4.3. Just to be safe, it runs a lot of things in my home and more important… to keep the support of my wife who hates any issues

So I’m not sure. But the code of both the widget and rules is pretty standard, I expect it to run also on OH4.

[jlikonen (Jari Likonen)]

@supersjel

I’m running in the production 3.4.3. Just to be safe, it runs a lot of things in my home and more important… to keep the support of my wife who hates any issues

So I’m not sure. But the code of both the widget and rules is pretty standard, I expect it to run also on OH4.

OK, thanks for the info. I’m also still on OH3.4 but may install OH4 some time during summer time.

[supersjel (Michel)]

@JustinG . I removed the widget from my openHAB. And tried to reinstall it using the marketplace. But I can’t get the marketplace install button to work. It shows an error message. With either a raw github link, a code block with the yaml. Even not with code ‘borrowed’ from another widget to be sure. Do you have any hints? Or does it take some time for the openHAB server to process changes I made in this page?

Update/edit: found an error in the log. I use the default property in the properties. Maybe the marketplace install doesn’t accept that one? If so, that would be a bug since it’s allowed in widget code. I’ll check what happens if I remove that.

2023-05-05 11:13:35.859 [ERROR] [munity.CommunityUIWidgetAddonHandler] - Unable to parse YAML: Unrecognized field "default" (class org.openhab.core.config.core.dto.ConfigDescriptionParameterDTO), not marked as ignorable (22 known properties: "readOnly", "max", "limitToOptions", "groupName", "name", "stepsize", "context", "defaultValue", "min", "label", "filterCriteria", "verify", "type", "description", "options", "required", "advanced", "unit", "multipleLimit", "pattern", "multiple", "unitLabel"])
 at [Source: (StringReader); line: 7, column: 18] (through reference chain: org.openhab.core.ui.components.RootUIComponent["props"]->org.openhab.core.config.core.dto.ConfigDescriptionDTO["parameters"]->java.util.ArrayList[0]->org.openhab.core.config.core.dto.ConfigDescriptionParameterDTO["default"])
2023-05-05 11:13:35.861 [ERROR] [munity.CommunityUIWidgetAddonHandler] - Widget from marketplace is invalid: Unable to parse YAML

Edit/update. Yeah that’s it. A bug in the marketplace installer. It doesn’t know/accept the default property. Mmm, the widget needs them for easy/flexible installation by group or custom items. First let’s see how to put in OH bugs (and check if it’s already reported).

    - context: item
      default: _current_speed
      description: Item with speed
      label: Fan speed
      name: speed
      required: false
      type: TEXT

edit/update. Found it. https://github.com/openhab/openhab-core/pull/3334. It suggests I should replace default with defaultValue and that should do the trick.

edit/update: Well it can work, but it’s quite a bad workaround. When using defaultValue in the widget it will fail. That property isn’t supported. Funny thing, if saved and reopened it’s changed back to “default” again and the widget will work. After some testing … change to “defaultValue” in github will allow installing through the marketplace. And during the proces it’s changed back to “default” again resulting in a working widget. Why it’s bad … this means while developing it it will be “default”. And before publishing to github you have to use an editor like notepad++ to replace it to “defaultValue” again/every time. Reading the workaround this should become ‘normal’ again in OH4.

edit/update: Bummer, it will install. code seems the same, but is broken. So this trick may work in some case, but not in mine. I have to refactor to remove the default values to get this to work.

[JustinG]

@supersjel

Yeah that’s it. A bug in the marketplace installer. It doesn’t know/accept the default property.

This has been fixed in the 4.0 milestones, but the fix will not be backported for any 3.4 versions.

At this point, I tend to try and avoid setting default values for the the properties and just include them in the expressions themselves. Up until now, it’s been more stable that way and gives me a little more flexibility incase the default value also needs to be dynamic.

If you just replace props.propName with (props.propName || someDefaultValue) in the relevant expressions then the problem goes away. It makes really long expressions even more complex, but otherwise has no side effects.

[supersjel (Michel)]

@JustinG

I tend to try and avoid setting default values for the the properties and just include them in the expressions themselves

Exactly doing that, testing now because easy to make typos in the proces. Should have know that before but you’re never to old to learn.

update/edit:

Done. Used formulas like example below. This restores my original intent. Easiest option is just selecting group/equipment item. Since the props for the other detail items are empty is uses the string. And everything works by just selecting one item. In case you have a different heatpump or didn’t take the default names the other option is selecting all the detail items. In this case the group/equipment items is ignored and just the detail prop is used.

items[props.mode==null ? props.heatpump+'_Mode' : props.mode].state

Installed it using the marketplace and by just copying the code in an empty new widget. Both options work now. Tried to minimize risk by using search-replace in notepad++. Will check it (have to wait for various heatpump modes to activate). If all’s ok I’ll add the published tag. Done the same for my other widget for a ltho daalderop fan that suffered the same issue. So @JustinG thanks for reporting this issue!

[supersjel (Michel)]

Hi, it’s summer and hot over here. So the heatpump started cooling but the widget didn’t show that correctly. I made a mistake when converting the rule to ECMA2021. This caused the old degree minutes to be undefined and undefined!=0 So the heatpump_mode was not set to 4 (=cooling) and the widget used that. Fixed, since it’s only a rule modification updating the rule is enough (widget is same).

old/wrong:
var degreeMinOldValue=Number.parseFloat(degreeMin.previousState).toFixed(1)

new:right:
var degreeMinOldValue=Number.parseFloat(degreeMin.history.previousState()).toFixed(1);

[jlikonen (Jari Likonen)]

My Nibe S1255 heat pump was installed ~3 weeks ago and I’m gradually integrating it to OH. It seems that the Nibe uplink binding doesn’t work with S-series pumps so I have started to use Modbus instead. I can easily read the Modbus registers with OH. I’m wondering whether this widget will work in my case.

[supersjel (Michel)]

Well, the widget let’s you choose between using the equipment/group item. If you can’t use the uplink binding this will probably fail. But you can also use all the items seperate that you need. This might work with modbus. Biggest problem will be the rule, it uses hard coded items using the equipment/group. Something on my todo list (that is quite long I fear).

But maybe good news for the future, I bought the electronics (esp with modbus adapter) to switch to the modbus setup (to increase update frequency).

A new version is also on the way … It seems openHAB 4.x also breaked some code (number/% items to be specific). This causes issues in the widget not displaying “OFF” and the right pump speed.

[jlikonen (Jari Likonen)]

OK, many thanks for the info. Perhaps I’ll wait for the 4.x version of the widget then because I’ll upgrade my OH3.4 to OH4 at some point.

[supersjel (Michel)]

@jlikonen Hi Jari, got around to it. Changes made and tested on OH 4.03. So whenever you do the upgrade the widget is ready for it!

To get you started on the rule for the modbus. All of it is vars you can change as needed.

• Problably the modbus binding also makes a group/equipment item. Put that in var group=“NibeF1145”;
• The rule create/inits a cache on first run (to keep day totals for the headpump stats): Put your root url of OH in var openHabUrl=“http://hal9000:8080”;
• That’s the default config you have to do anyway. Now your modbus binding probably makes different items the heatpump. But it will of course still have a brine pump speed. Look in the rule for var brinePump=searchFirstItem(group,“EP14GP2BrinePumpSpeed”); and change the “EP14GP2BrinePumpSpeed” to whatever the modbus binding generates for the item. Same for the others.

That should get you one the way. Good luck and if you have questions just as them!

[jlikonen (Jari Likonen)]

Great, many thanks. It may take a while before I will upgrade from OH3.4 to OH4.0.3 but I will try the Nibe widget then.