Sensor update delays and unavailable. #85
Replies: 14 comments 24 replies
-
Hi Raine, I just updated my Olarm integration and obviously also get the same error as mentioned above. Have they agreed on an acceptable Scan Interval that could be used as my API key has been blocked by them.: Logger: custom_components.olarm_sensors Your api key has been temporarily blocked due to too many request. Increase your scan intervalIt's currently set to 50 seconds? |
Beta Was this translation helpful? Give feedback.
-
Here is Olarm's response to my email. Hopefully, they can complete the MQTT integration within a reasonable timeline. |
Beta Was this translation helpful? Give feedback.
-
I upped my scan to 20s. I've got 3 areas that need arming and when my automations want to arm or disarm I usually hit the request limit so I also add delays in the automations to help with that part. Wish we had a way to hit the device from LAN instead of the round trip api to olarms. Thank you Raine for the efforts you put into this project. |
Beta Was this translation helpful? Give feedback.
-
Yes, I think their support staff is limited. I have been waiting for my ticket to be resolved. My Olarm stopped functioning and it is 6 months old. So waiting for them to resolve the issue. |
Beta Was this translation helpful? Give feedback.
-
Just installed for the first time and set the scan interval to 60. Got the API blocked message right away and none of the areas or sensors load at all. Directly accessing the API end point with my key via Safari returns data correctly and shows my system. I have tried changing the update interval to 25, 50 and then 60s and all with the same result. But HA logs are filled with the following - Olarm has no saved history for device (Home) |
Beta Was this translation helpful? Give feedback.
-
There are three requests per update. Considering that the execution time might vary depending on the system size, it makes sense that some devices experience issues while others do not. I will implement delay logic in this update to try and prevent this issue. For context: The first request, /api/v4/devices, retrieves all the devices associated with your account. The second one, /api/v4/devices/f12d9dc1-f90c-4dfe-8ca3-ac370d651e84, fetches all the information about a specific device. Lastly, the /api/v4/devices/f12d9dc1-f90c-4dfe-8ca3-ac370d651e84/actions request obtains all the actions for the current device, such as who changed the state of the system and at what time. |
Beta Was this translation helpful? Give feedback.
-
Would webhooks not solve the polling issue? I saw on the api key page it’s available. Of course I didn’t see any documentation for this and MQTT would be way more reliable, but it’s an option at least.. |
Beta Was this translation helpful? Give feedback.
-
Hi, Is there any update regarding the MQTT integration? The current one works awesome!!!. It would be nice to have more of a real-time update on the sensors etc. Thanks |
Beta Was this translation helpful? Give feedback.
-
I've been pondering for a long time to get an Olarm, a Konnected, a HYYP module for my IDS X64, replacing the panel e.g. with a Paradox (expensive) or a custom-built ESP32 (which I'm capable of doing, but don't have the time for). Today I took the plunge and I'm hoping to use your integration once it's installed. The alternatives, except for a custom ESP, all suck more than the Olarm, so it is one of the best options available. One reason I held off for so long, is that I was hoping to have also local control over the device. I was in conversation over email with them for several months a few years ago (starting Feb 2021, with my last follow-up in Sep 2022 without further response). There were already talks of an MQTT interface back then. I even chatted with one of their tech staff over the phone at the time and they seemed very keen. I see MQTT has been mentioned here too. Note that I don't mind paying for a monitoring subscription, but for the purposes of home automation it is far more efficient to have local access. My preference is still MQTT, but even local API access would help (although I'd prefer pushing updates over polling updates, as far as possible). To poll every 10s is still way too slow for most applications: I can't trigger lights based on that, for example. Perhaps we, as a community, can offer some assistance? As a company, I can imagine they have many priorities and that this will seem like a minor use case for power users like us. It often comes down to having enough hands to do the job. Instead of contacting them individually, perhaps we can draft a list of users and I'd be happy to try and continue the previous conversation – or if anybody else feel up to the task. EDIT: I'd take a webhook too, but that will only help for updates. Still need API calls to arm and disarm, for example (anything that's a control command). |
Beta Was this translation helpful? Give feedback.
-
I have just done an update and received the following error. I assume it is because of the same issue discussed above? It has been working like a dream up to now though. Is there a way to roll back the update?
|
Beta Was this translation helpful? Give feedback.
-
I received this update today regarding a local MQTT interface:
|
Beta Was this translation helpful? Give feedback.
-
Hi All I received something similar.
From Olarm Support:
We are busy testing internally so hopefully won't be too much longer. It is difficult to give an accurate timeline to when it will be production ready.
|
Beta Was this translation helpful? Give feedback.
-
HI All Has anyone had an update regarding MQTT access for the Olarm app/device? |
Beta Was this translation helpful? Give feedback.
-
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
-->This is the new ticket ref nr: [##111411##]It might be a good idea if as many people as possible log a ticket for the same again. From: Pieter Rautenbach ***@***.***>Date: Thursday, 30 May 2024 at 09:14To: rainepretorius/olarm-ha-integration ***@***.***>Cc: blindeslakkie ***@***.***>, Comment ***@***.***>Subject: Re: [rainepretorius/olarm-ha-integration] Sensor update delays and unavailable. (Discussion #85)Nope, only another promise in March.—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Even if you set your scan interval to 10 seconds per device, your API key and IP are being blocked by Olarm as they only want their users to use their app at the moment as there is no response from them on when an official Home Assistant, Google Home or Apple Homekit integration will be available. They said they are working on a MQTT integration but did not specify a timeframe.
Beta Was this translation helpful? Give feedback.
All reactions