No automation. I am using it for heating boost after vacation or when switching from heating in the stove. Or when I want to boost climatization start…
1 Like
I changed it to
[0-9]+:-?[0-9,]+
Apart from that discussing about setting degree minutes manually there are other channels where negative values are valid.
I am planning on migrating from Nibe Uplink REST API Binding, but understood that the ‘Mode’ channel (‘Away’, ‘Normal’, ‘Vacation’) might still be missing. Would you be willing to add that?
To check if it was there, I was looking for the source code, but could not find anywhere, did I miss it?
Thanks for the hard work!
@mvandamn I have created a PR towards @AlexF’s GitHub repo to implement this, he just needs time to review it and then it can hopefully be merged and a new build created. But at least on my system, there seems to be a bug on Nibe’s end, even if I have set the mode (and can verify on the heatpump itself that it is activated) the API always reports the mode as “default”.
1 Like
Any update on writing to Number channels?
The change has been merged, so it’s just about creating a new build. If you are impatient you can download the code and build the binding yourself, but it requires some development tools set up (at least a jdk and maven).
That’s great news! Thanks
checking the Swagger UI for my heatpump F1245-PC. Lot’s of data, but it seems to be old and not refreshed so often (5 minutes?). Anyone notices the same? Or is this a kind of cache on the “swagger” app/testing?
edit: created a “direct” curl command, same result. Delay is more than 30 minutes now…
That depends on how often the heatpump sends data to the servers. Was the same before with the old Nibe uplink.
@pacive . Read that too, depends on model heatpump but no more info on the nibe site. Before the upgrade (so the old uplink site) it was about every minute. Maybe problems with the site yesterday? Maybe it waits for a significant change before it sends a value to save bandwidth? Will run a script today to check if this improves …
Mine has always worked that way. E.g., temperature parameters only updates when it has changed > 0.5 °C, others have other thresholds. What’s changed with the new API however is that settings sent to the heatpump gets received immediately, and not the next time the heatpump checks in with the server (which could be up to 15 minutes with the old uplink).
Took a shower so the heatpump had to work 
. This confirms my suspicion, myuplink is (at least for the F1245) a huge step back in service compared to the old uplink. The old uplink had a refresh of about a minute. Myuplink increases this to 5 minutes at least. So the refresh interval/lag for reading is increased so much making it kind of useless. Below a graph of powerusage (10 second refresh) and the NIBE brine pump speed showing the lag. Startup, 6 minutes late. Shutdown a minute. Of course more testing is needed but on this I assume it works with fixed 5 minute intervalls (unless you update a setting but that’s not my usecase).
.
I guess it won’t help much; but I had the same with my pump on the old NIBE-Uplink. First couple of months I had 1 minute interval update on the data. After some random reboot, this dropped down to 5 minutes. I would also see the little indicator go yellow in the old interface.
And as a real Heisenbug, if I started packet captures, or kept pinging the machine, it would keep updating every minute 
I was hoping the new firmware will fix this.
@mvandamn . It was years back since I upgraded the firmware, so could be my issue. What kind of ping did you send? I regular ping on your own network OR the ping that is in the swagger API (I think that’s for checking the API service). Since I got a script running, I could try and add a ping and see what happens …
edit: looking at the outside temperature @pacive is also right on the delta. No regular interval but all changes are steps of 0.5 C. You would expect a pump turning on to count as a trigger to sent an update but maybe Nibe forget to implement that. Or didn’t think it would be relevant.
When I logged into nibeuplink.com, the pump was showing the usual signs;
Now I am pinging the device from my desktop, just ping 192.168.x.x and it shows a consistent green check-mark over over last couple of minutes.
Are you sure that’s the cause? Because it seems that Nibe had implemented something that let the heatpump know you were logged in to Nibe uplink, and send more frequent updates as long as you had the page active in the browser. As soon as the mark turned green it kept that way until you logged out. My guess is that the point was to enable faster changing of settings, the heatpump checked in more frequently once it got indication that there was an active user session. Since the old Nibe uplink binding used the same internal API, this might have led to more frequent updates if the page was polled in regular intervals, emulating a logged in user.
Ah, I was wondering what you meant with green/yellow indicator. It’s the old uplink site. I think I remember the old makes a difference between “not watching” and “watching”. That’s why I used the “screenscraping binding”. That one kept watching active.
As for the new myuplink it doesn’t seem to make a difference. I pinged the heatpump, opened the browser to myuplink and opened the app on the phone. Even with all this activity the update policy remains the same.
I looked closer at the data this morning, and all sensor readings changed at the same moment. Maybe the heatpump only watches a few temperature items for change. So the pump active was no trigger, it waited untill the brine and supply temperature changed enough to send all data.
Maybe it’s a setting within the heatpump. I saw a new homeautomation option, maybe that should be activated? Or some other setting to let the thing know you’re interested in readings?
edit/update 1: Don’t know if Nibe is open to this but put in a support request to change this behaviour (at least for pump speed items).
edit/update 2: Second measurement today (warm water cycle), the start was picked up in 1 minute but the end was missed by 3 minutes.
Edit/update 3. Nibe responded, my message is forwarded to the back office, they will look into it and contact me. So, excellent service and maybe a solution.
Edit/update 4. Response, it a known bug that probably will be fixed in a future release. But no exact date … So for the moment it is what it is.
2 Likes
OK so since I am apparently more impatient than I initially thought, where’s the repo at? 
Thanks. I built it on 4.2.2-SNAPSHOT and can confirm that writing to Number channels does indeed work with your commit applied. I see there is some discussions on how this should be done long-term, but this is very useful for me short term. So thanks again @AlexF and and to you as well @pacive for your contribution!