New version of the app is ready for testing.
Hi Edwin, can you please take a look what is going on, if you will have time ? All my thermostat are offline, but original app works fine. Diag. code : 59f3006a-fd0d-4219-8582-a3fe60f6898f
Note : tried restarting app, re-authorizing, page https://id.senzthermostat.nvent.com is working fine and is accessible, no changes as per Changelog - RestAPI ā¦
Hi Sharkys, there has been a maintenance on the SENZ WIFI server today, and there has been a need to restart the server. Not all thermostats are back online yet, but this issue should be resolved within no time.
Patrick
Thank you Patrick, it was actually strange as in the official app I see everything online but in the Homey app all is offline. So good to know, thank you that you are actively tracking also forum here Appreciate.
Yes I try to monitor this. In principle all thermostats should be back online now.
I confirm, they are. Good to know it might take longer next time Thank you.
Hi, is the Raychem Senz Wifi identical to Microtemp WiFi MWD5-1999? Would it be possible to include support for this thermostat in Homey, or install the Raychem firmware on the Microtemp to be compatible with your app?
Hi Sigurd,
I donāt know if this is possible. You can try and install the app, and try it out.
If you do, please let me know if it fully works.
I think @Patrick_Hendrickx can provide more information about the possibilities.
ā Edwin
Hi Sigurd, Edwin,
The Microtemp WIFI MWD5-1999 is not compatible with the nVent RAYCHEM SENZ WIFI app nor with the nVent RAYCHEM SENZ WIFI API. It would require a new development (if the API is available for the Microtemp) to integrate this in Homey.
Patrick
Hello, I have been using your excellent app for a while and got the Ā«rate limitedĀ» situation from time to time.
After upgrading my Homey Pro (late 2019) to fw 8.0.1 a few days ago the situation is turned and both my regulators are reporting rate limited constant - except from a low number of hours a day.
I created a flow to test for connectivity and restart the app every 10 minutes, when the connectivity-test fail, hoping that this would bring some aid, but it seemes to have no effect. The senz-wifi -app does not report any issues.
I have of course used the Ā«try to repairĀ» routine several times.
I have not tried to delete and reconnect the regulators.
What am I missing here?
Best, Bernt
Iām using counter based on trigger āconnectivity lostā and checking that counter every 10 min if>1 to restart the app.
Anyway, this was in my case caused by specific WiFi connectivity issues and Iām not having any issues currently, even not with fw version 8.0.1
Anyway, probably you would like to report diagnostic code to evdpol to see if you donāt have other issue.
I will hook up my thermostat and see if I can find any irregularities.
If it happens again, please do send a diagnostic report.
Thank you for taking a closer look at this. I converted the original flow to advanced and somehow this solved parts of the problem. Now only one of the regulators is affected by the problem. The controller does not have the warning flag set as before, and I have access to the settings, but when I send commands, such as Set temp, mode, etc., I always get the warning āRate limitedā. The controller works as usual in the Senz app.
Thanks again!
Diag. code: 09f6c35f-6675-42b5-96ba-c2cd045358dd
Hi @Sharkys,
I took a closer look, but my thermostat does seem to detect that my device is online.
I can see the wireless connection icon on the device, but it is striked through.
The API also says the device is offline.
When I set the temperature on my device, I do get a notification message from the nVent API, so it is actually online. When I enabled boost mode, the device shows the correct state, and the API returns also an online state.
It seems the device itself doesnāt register the online / offline state correctly. Not sure what is going on there.
@Patrick_Hendrickx Maybe you know what is going on with the online / offline state?
Hi @Bernt_Brundtland ,
I took a look at your diagnostic report, and it looks like you have a of devices, at least that the temperature changes alot?
You are making rather many request, as when your temperature changes, Homey receives a notification and will get the data of the thermostats. Thatās why you hit the rate limit.
I am renewing the app as we speek, so I will develop a setting where you can set the main refresh interval, so when you hit the rate limits, you can increase the interval so less requests are made to the nVent API.
ā Edwin
Thanks again for looking into this. I calculate the temperature with a formula based on the outdoor temperature. The calculations are performed and the temperature is indeed set each time the flow is triggered.
The previous flow was triggered every 10 seconds. Current flow is triggered by a change in room temperature or room humidity (or by PoTH-estimated consumption limit). This has obviously led to a lower number of API requests. Your explanation therefore makes good sense, and the problem actually ceased a day or two after I redesigned the flow from using constant time triggers to sensor triggers.
I rightly assumed that my own flow was the cause of the problem, but I wasnāt able to reveal the cause and why it suddenly occurred.
Itās great that you add the ability to counteract this form of saturation. For my part, there is still some tuning left in terms of the threshold for temperature at high humidity, but I think that the flow now has a relatively robust logic that provides a reasonably good climate in my basement under all weather conditions all year round.
āBernt
Hi Edwin, thank you, but actually exactly this is how I double-check my Wifi thermostat is connected - when Senz-Wifi App reports itās disconnected, actually in 99% the official app also reports strike trough wireless connection icon. But really in my case it was always because I was playing with my Wifi APs (usually because of tuning up the 802.11r roaming) and since then itās working just nice. But - when thermostats get disconnected as per Homey Senz-Wifi App , I have to restart the app to get the connection back, so thatās why Iām using counters. My point is that this disconnections are happening now quite rarely and itās working great for me.
Disconnected counter per each thermostat
Restart
Itās kind of safety mechanism only at this moment because as I mentioned, luckily I somehow identified the right AP Wifi connection parameters.
Hi Edwin,
The rate limit is set at 50 API requests per second, 750 API requests per 30 minutes, 20.000 per 12 hours and 250.000 per 7 days.
If the user is attempting to do more than these calls, then he will hit the limit, and restarting the app would not help. When the limit is hit, it will need time to get unlocked again.
These limits have been set in the API calls to avoid misuse of the API, so when building flows, it is important for the user not to hit these limits.
The limits are set as a combination of CLIENT and user. The client in this is the Homey App and the use in this case would be @Bernt_Brundtland .
Note that there is a rate limit as well as a burst limit.
The burst limit, is limiting the number of API callās over a short period of time, the rate limit is set to 250.000 calls per month.
I hope this helps understand the issue.
If you have other remarks/questions, donāt hesitate to contact me.
Patrick
Hi @Sharkys,
I am surprised that you need to restart the APP when a thermostat looses connection. When I, for instance turn off a thermostat (to simulate a connection lost), then the APP is giving me a warning (connection lost), but when I switch ON the thermostat again, I get a connection restored message from the Homey App after about 30 seconds to 1 minute (the time needed by the thermostat to restore the connection with the server).
So I think that restarting the APP is not really needed. Did you really need to restart the app, or is that something you did because you had issues in the past.
Kind regards,
Patrick
I will disable the restart check, to see what will happen, but in the past I know that the thermostats were pinging, API was accessible as well yet the thermostat were offlineā¦ Iām suspicious itās caused by the roaming between different APs.