The PaperUI shows “Items”. To remove those you also need to delete the items. If persistence is activated those items still show old values even if openhab is restarted because last value from persistence is used.
Hi @AlexF,
sorry, that was my fault - I thought I have already deleted these items…
Next time I have to double check that. 
Regards
Jonathan
is now merged into openhab master. Next milestone version should then contain all changes which are currently available in my DEV version.
1 Like
Hi @AlexF,
I just found out, that channel general#47011 is also available for the F730 models:
My heating offset is set to 1 at the display unit of my heat pump - this value is not visible in the online monitoring (maybe in the paid part…).
Edit: channel airsupply#47260 is also available on F730 with the same values given for F750.
Regards
Jonathan
Hello all,
I receive a communication error since a day.
When I update the binding in paperui or restart in console The log says
2019-05-04 09:51:48.535 [hingStatusInfoChangedEvent] - ‘nibeuplink:vvm320:mynibe’ changed from OFFLINE (COMMUNICATION_ERROR): Total timeout 120000 ms elapsed to OFFLINE (COMMUNICATION_ERROR): Max requests queued per destination 1024 exceeded for HttpDestination[https://www.nibeuplink.com]@1a98073,queue=1024,pool=DuplexConnectionPool@bb2a7e[c=2/2,a=2,i=0]
this is the log after i restart the binding from the console:
2019-05-04 12:05:32.461 [hingStatusInfoChangedEvent] - ‘nibeuplink:vvm320:mynibe’ changed from UNKNOWN: waiting for web api login to UNINITIALIZED
2019-05-04 12:05:32.486 [hingStatusInfoChangedEvent] - ‘nibeuplink:vvm320:mynibe’ changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2019-05-04 12:05:35.793 [me.event.ThingUpdatedEvent] - Thing ‘nibeuplink:vvm320:mynibe’ has been updated.
2019-05-04 12:05:35.827 [hingStatusInfoChangedEvent] - ‘nibeuplink:vvm320:mynibe’ changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
2019-05-04 12:05:35.845 [hingStatusInfoChangedEvent] - ‘nibeuplink:vvm320:mynibe’ changed from INITIALIZING to UNKNOWN: waiting for web api login
I can log in to the NIBE uplink webpage and see, that my NIBE systems sends regularly data.
An idea how to resolve this, or where to start looking for the cause? Thanks
SOLVED: A reboot of the rasPi openhab is running on resolved the issue. A restart of the openhab service did unfortunately not solve the problem. (Annoying that services and rules stop suddenly working on an openHAB system and require restarts)
Hi all and thanks for a great integration.
Is it possible to block additional electrical heating via paid API subscription?
I’m looking into the possibility to reduce power usage on cold nights when I would like to use as much power as possible for charging a EV.
I know there might me a solution to schedule blocking, but that’s done hard on the unit itself.
/t
Hi folks,
I am pretty new here, so sorry if I missunderstand sth…
I own a Nibe Heatpump sold by Alpha Innotec here in Switzerland since 1 week, and realized, that I could possibly link it to my openhab2. Only thing is in Switzerland the Alpha-Version of the HP uses not www.myuplink.com, but an exact copy named www.myupway.com
I believe it would be easy to include some variable in the binding where one could choose the portal where the Data comes from, no?
if that would be possible, all Alpha Innotec Owners of the Nibe-Manufactured HP could use the binding as well… the Controller is the same as the SMO-40 from Nibe, ist simply rebranded and named NP-CS40.
thanks for help on this, really appreciated!
Mark
FYI, I had Alpha Innotec install the NIBE firmware explicitly because of API support not being available (at least officially) from AI. Works, apart from the fact that I now somehow have to figure out the values for my F2120 (alias NP-AW 20-16).
1 Like
Hi, thats interesting. I had one call with them, and they said its not possible… could you maybe direct me in the direction how to fix this? and why do you need to figure out the values - are they different from the ones of NP-AW 20-16? I have the same pump… would be cool to get one step forward here…
thx!
This is easy to implement but currently I do not have a lot of time and of course I cannot test it.
1 Like
I created a test version which now uses www.myupway.com but this is hardcoded so just a test version. You can find it here: http://friese-de.eu/openhab2/myupway/
1 Like
Hi Alex,
sorry for the late reply… i tried it, but somehow did not get it to work properly… due to little time i will give it another try asap.
but the good thing is: NIBE / AIT will anyway change my firmware to the SMO-40 one, so I can use the official API and fetch and maybe also alter data via their API… so at the end I wont need the feature.
but it might anyway be a good option for someone stuck with the Alpha Innotec Version?
Best, mark
Hi Alex,
great job with this Binding, thx a lot!
I currently use it with a Nibe SMO-40 master unit and an outside F2120-16 slave unit, would that be possible to add as a supported device? Most of the channels from the F1145 as well as the VVM320 are identical and work, but I would love to add some more, and also define the divider & value correct…
thx, Mark
Hi there,
I just improved the custom channels a little bit:
- There is support for 16 instead of 8 custom channels
- Scaling for custom channels can now be applied via configuration instead of using rules.
This is currently only availble in the DEV version. I will create a PR as soon as this has been tested for a while.
1 Like
Would love to test that. Do you have a link to the Dev. version? can I just install it over the existing one?
best regards
Mark
I have backported the changes to 2.4 as the 2.5 SNAPSHOT version is no longer compatible with 2.4.0 release of openhab.
2.4 backport: http://friese-de.eu/openhab2/org.openhab.binding.nibeuplink-2.4.0-SNAPSHOT.jar
2.5 snapshot: http://friese-de.eu/openhab2/org.openhab.binding.nibeuplink-2.5.0-SNAPSHOT.jar
Hi @AlexF, i hope you’re doing well after all this time.
i’m still a heavy and very happy user of your binding since the first beta version. now so glad it made its way through the official distrib.
I’m writing to you as, as you have probably noticed, the nibeuplink API itself has been suffering up and downs recently. i’ve been suffering its impact on the system after not being able to get records for relatively long periods, or even not having the machine able to push new measurements, in turn leaving the binding to return invariable measurements for long periods of time. In order to mitigate that, i’ve been looking for some measure of the reliability of the measurements themselves, even though the binding reports the thing ‘online’ where at the end it effectively is, but without taking into account the fact that the nibe itself may not be able to refresh the measurements on the API. For instance i’ve implemented a check that verifies whether the API point is responding over http (i.e. a pure connectivity test) and whether the nibe thing is effectively online (it means it could connect/authenticate), and that has already allowed me to implement appropriate measures for when typically the internet connectivity suffers problems or when the API does not accept logins. This is however proving not to be enough, as recently the API looks healthy and the binding is itself on-line and functioning but the measurements do not get updated or very sporadically.
On this, I remember from the times when i had implemented myself an interface with the API, that the date of the last update from the equipment is also published through the API. In fact, i guess it is what is being used by the nibeuplink web page to report on the on-line/off-line status of the equipment. Looking back at my old code, i was getting that info from the /api/v1/systems/ interface in the ‘LastActivityDate’ element of the returned JSON.
I thought it could be an idea to publish this date through the binding in a new generic channel (of type DateTimeType). I know it’s a bit of a ‘nice to have’ wrt to all what the binding already offers, but it would solve this last point about reliability, at least for me.
WHat do you think about this and could it be something you’d be willing to support in the binding?
cheers
Hi @AlexF!
I’m working on updating the nibe uplink binding to be able to use the official Nibe Uplink REST API. So far I have managed to get authentication working and some other calls to the api that can be used for thing discovery (and also implemented a discovery service, so things are addedd to the inbox once the bridge is set up). I have quite a bit of more work to do to implement more functionality and make it more stable, but I’m going to need your help in integrating it into the existing binding.
My work is currently done as a separate binding because it made it easier for me to learn all the internal workings (it’s my first attempt at creating a binding), but I hope it can be integrated with the existing one. My work so far is available at github. Do you have any idea what would be the easiest approach to integrate it? (I’m sorry if my code is a bit of a mess, I most noteably need do document it better 
)
Sounds to me more like it would actually be a replacement.
Is there any difference in features between REST and webinterface?
There are some differences. I wrote a short summary in this post.
If I would replace the current binding some users might lose functionality, most notably to change settings, so I’d rather just add it as a separate bridge to the existing binding.
But it can be hard to work with someone else’s code, especially since I’m not very experienced. That’s why it’s currently a separate project.