Closed jakesie1309 closed 1 year ago
Hi @jakesie1309 ,
How many sensors does your alarm have? I have 32 zones and all is still in order for me.
Hi @rainepretorius
I do not know if this can be the problem, but i have two olarm's units. In total i would say have around 48 zones (24 on each)
@rainepretorius, tried again this morning. Delete the integration, re-generate new API key. Setup, works for a few seconds and then: The api returned text instead of JSON. The text is: Too Many Requests
Hi @jakesie1309 ,
It might be that it can cause the issue. I only currently have one Olarm device, so I will not be able to precicely say that the two device might be the issue. I am thinking about getting a second Olarm for my electric fence and hopefully then I might be able to test multi device support and issues better.
@rainepretorius, thanx for the quick reply. I notice even when only setting up one of the olarm entities, it complaints about "api_key" waiting for olarm to come back and see if they increase / assist with the refresh rate.
will try one more time to set the refresh rate to 60s. way to long, but just to test. thanx again for the help and building this out
Hi @jakesie1309 ,
It is my pleasure. Let me know if that test works. If it does, I will see if I can implement something to fix it.
@rainepretorius , nope the same for me :-( Will play around and see what happens if hard program this.
For time being to make the alerts work, i have setup the webhooks in Olarm, at least this will give me the last message and event state. also adjust the refresh to 60s, but still gets block even with enable only one instance. will keep you posted if olarm can icrease my limit
@rainepretorius, also forgot to ask, i manually setup this through yaml to test, but never figured out how to manually create a alarm entity as what your integration does. do you have an example of the yaml on how you got the alarm panel work through the manual yaml process.
@rainepretorius, also forgot to ask, i manually setup this through yaml to test, but never figured out how to manually create a alarm entity as what your integration does. do you have an example of the yaml on how you got the alarm panel work through the manual yaml process.
The integration or the panel?
@rainepretorius , the alarm panel
I get the error: "Could not get JSON data. Your api key has been blocked due to too many frequent updates. Please regenerate the api key"
This is after reinstalling the service with a newly generated API key. What is odd, is that I can do that get request in my browser (or Postman) and I do get the result and not an error. So I don't actually understand how this error is occurring.
Looks like this is not going to work any longer, webhook implementation is probably the only way forward.
Some more supporting info:
ing the service with a newly generated API key. What is odd, is that I can do that get the request in my browser (or Postman)
I have also been getting this since yesterday. I got no response from Olarm or their CTO about this current issue.
That is interesting. I will have a look at why version 2.0.4 works but not 2.1.1
Thanks for the updates @rainepretorius, but just the setup of all the sensors etc causes the API key to be blocked for too many requests (using the 30 sec interval and 2.1.4).
Clearly Olarm have now screwed over the polling idea...even 30 sec update interval becomes problematic, as it's not particularly real-time at that point.
I maintain that webhooks are the answer, then, only actions/commands will need to be sent (and probably initial initialization) to the Olarm API.
I've tried again (reset the API key again) and it seems like it's working now.
I was deliberately careful to to test the actions right after setup, that seemed to have helped this time around.
Thanks for the updates @rainepretorius, but just the setup of all the sensors etc causes the API key to be blocked for too many requests (using the 30 sec interval and 2.1.4).
Clearly Olarm have now screwed over the polling idea...even 30 sec update interval becomes problematic, as it's not particularly real-time at that point.
I maintain that webhooks are the answer, then, only actions/commands will need to be sent (and probably initial initialization) to the Olarm API.
I am in the process of talking with them to implement a websocket API as it would solve all the above issues and be realtime. I have a physical meeting with them next week.
Thanks for all the work on this. A software dev responded to my query saying that they instituted a polling rate limit.
Let us know if you need any info or testing @rainepretorius. Happy to support. My 7 olarm subscriptions hold significantly less value without this integration.
Thanks for all the work on this. A software dev responded to my query saying that they instituted a polling rate limit.
Let us know if you need any info or testing @rainepretorius. Happy to support. My 7 olarm subscriptions hold significantly less value without this integration.
Thanks @mikesierra555 . All your support and patience us very much appreciated and I am glad to have helped.
Thanks for the updates @rainepretorius, but just the setup of all the sensors etc causes the API key to be blocked for too many requests (using the 30 sec interval and 2.1.4). Clearly Olarm have now screwed over the polling idea...even 30 sec update interval becomes problematic, as it's not particularly real-time at that point. I maintain that webhooks are the answer, then, only actions/commands will need to be sent (and probably initial initialization) to the Olarm API.
I am in the process of talking with them to implement a websocket API as it would solve all the above issues and be realtime. I have a physical meeting with them next week.
Through you current integration can you monitor zone troubles (ie low battery [for beam], etc)? If not, when you have your meeting with them, please ask them to implement. I have been asking for years through their App
Thanks for the updates @rainepretorius, but just the setup of all the sensors etc causes the API key to be blocked for too many requests (using the 30 sec interval and 2.1.4). Clearly Olarm have now screwed over the polling idea...even 30 sec update interval becomes problematic, as it's not particularly real-time at that point. I maintain that webhooks are the answer, then, only actions/commands will need to be sent (and probably initial initialization) to the Olarm API.
I am in the process of talking with them to implement a websocket API as it would solve all the above issues and be realtime. I have a physical meeting with them next week.
Through you current integration can you monitor zone troubles (ie low battery [for beam], etc)? If not, when you have your meeting with them, please ask them to implement. I have been asking for years through their App
I will see how we could implement all the app features and maybe more when using the new API.
@rainepretorius , thanx for the effort. also receive the below from Olarṁ support:
"Unfortunately we have made changes to our rate limiting as some home assistant integrations are hitting our API multiple times per second.
If you do are getting 429 errors then you are hitting much faster then once every 20 seconds or are sending multiple requests at once.
We recommend using webhooks instead of polling our API."
@rainepretorius , i have webhooks setup, but does not give all the detail that the api gives. hopefully if we work all together and push them a little they will assist their community :-)
Hi. Upgrades to the latest version but see is still gives the same error. Even tried to set the seconds to 300
This error originated from a custom integration.
Logger: custom_components.olarm_sensors Source: custom_components/olarm_sensors/olarm_api.py:547 Integration: Olarm Sensors (documentation, issues) First occurred: 22:04:10 (2 occurrences) Last logged: 22:04:11
Could not get JSON data. Your api key has been blocked due to too many frequent updates. Please regenerate the api key
Only managed to win once. But it only setup the update button and alarm
@rainepretorius , i have webhooks setup, but does not give all the detail that the api gives. hopefully if we work all together and push them a little they will assist their community :-)
@jakesie1309 , A webhook that gives the same amount of information as the api would definitly be awesome. Olarm's websocket API for their app is proprietary knowledge. We can potentially request an enhancement for a public websocket the community can use but I am unsure if that is feasible. I am meeting up with their Chief Technical Officer on Tuesday and I will bring the request to his attention.
Only managed to win once. But it only setup the update button and alarm
That is great news. Mine does not even load anything. I am strugging with this sothat we can at least arm and disarm the alarms, but that even gets blocked.
Good luck with the meeting, I really hope they come to the party. Olarm has been promising HA integration for years. Now the community (@rainepretorius) has essentially built it for them, the least they can do is provide us with a proper API and webhooks that can drive this HA integration. Proper, real-time HA integration will certainly add value to their product, as it is already doing for users of this integration.
EDIT: forgot why I actually came here - I also can't get the integration to init, new API key gets blocked immediately. I have 1 device with 2 partitions. It was working fine but I had to restart HA core a couple times in a short timeframe, which I presume blocked the key. Now can't get it to init at all.
Hi @rainepretorius . Tnx so much for the app... Quick question, it was working great till yesterday, then there was an update.. and now i only have 1 entity? Am I doing something wrong? Thank you in advance.
Hi @rainepretorius . Tnx so much for the app... Quick question, it was working great till yesterday, then there was an update.. and now i only have 1 entity? Am I doing something wrong? Thank you in advance.
There is a current issue on the API that causes the integration to stop working. I am working on a fix for this and will keep you updated.
Hi @rainepretorius . As the rate-limiting which Olarm recently began enforcing on the API appears to be the issue, might adding delays between the API calls made during init / setup mitigate things? Initial setup would take much longer, I know, but might reduce the likelihood of an API key being blocked.
Hi @rainepretorius,
An idea to consider in the meantime: why not cache the API responses of GETs for a short time so that during setup or reload at least it won't trigger the rate limiting.
I've done a basic implementation on my fork, see PR. I can successfully setup the integration, although initially it fails to create all the entities, simply needs a reload of the integration.
This might not work correctly for users with multiple devices, I only have 1 so can't test.
Thanks @MrPrisoner, unfortunately for me it made no difference.
Removed integration, updated to new version and installed, generated new API key and setup integration again.
Thanks @MrPrisoner, unfortunately for me it made no difference.
Removed integration, updated to new version and installed, generated new API key and setup integration again.
Try reloading the integration (where you added it on Settings > Devices and Services). With first setup it hits the API a couple of times and gets the "Too many requests" response, then if you reload it should work. At least it did with me.
Hi @rainepretorius,
An idea to consider in the meantime: why not cache the API responses of GETs for a short time so that during setup or reload at least it won't trigger the rate limiting.
I've done a basic implementation on my fork, see PR. I can successfully setup the integration, although initially it fails to create all the entities, simply needs a reload of the integration.
This might not work correctly for users with multiple devices, I only have 1 so can't test.
Thanks for the fix. I can confirm that it doesn't work for my instance with 6 devices.
Thanks for the fix. I can confirm that it doesn't work for my instance with 6 devices.
We'll have to wait until we can implement a proper solution, my "fix" was more a bypass of the API limiter by caching responses which I played around with to get my instance working. Certainly not ideal, but not really much we can do until Olarm gives us a proper way to init/reload the integration as well as some webhooks so we don't continuously poll the API and overload it.
Thanks for the fix. I can confirm that it doesn't work for my instance with 6 devices.
We'll have to wait until we can implement a proper solution, my "fix" was more a bypass of the API limiter by caching responses which I played around with to get my instance working. Certainly not ideal, but not really much we can do until Olarm gives us a proper way to init/reload the integration as well as some webhooks so we don't continuously poll the API and overload it.
I talked with their CTO just now, and they are busy working on a new endpoint for the integration that wont overload the API.
Since this might take a while, here is a solution in the meantime for those interested.
Note that you'll have to make your HA instance reachable from the internet, thus at the very least, get your public IP and port forward to the IP address of your HA instance (this is for the webhook to work).
Create an automation with webhook trigger:
You'll have to create two text input helpers: input_text.alarm_state
, input_text.alarm_message
alias: Olarm Webhook
description: ""
trigger:
- platform: webhook
allowed_methods:
- POST
- PUT
local_only: false
webhook_id: "<ID>"
condition: []
action:
- service: input_text.set_value
data:
value: "{{trigger.json.eventState}}"
target:
entity_id: input_text.alarm_state
- service: input_text.set_value
data:
value: "{{trigger.json.eventMsg}}"
target:
entity_id: input_text.alarm_message
mode: single
Not shown here but you can use the input_text.alarm_state
in conditions for example. State has values like: "countdown", "arm", "disarm".
Then you'll have to create this in configuration.yaml:
You'll need to get your device ID here: https://apiv4.olarm.co/api/v4/devices?accessToken=
rest_command:
olarm_action:
url: https://apiv4.olarm.co/api/v4/devices/<DEVICE_ID>/actions
method: POST
headers:
authorization: 'Bearer <API_KEY>'
accept: 'application/json, text/html'
payload: '{"actionCmd": "{{ actionCmd }}","actionNum": {{ actionNum }}}'
content_type: 'application/json; charset=utf-8'
verify_ssl: true
Then you'll be able to create two scripts to arm/disarm the alarm:
alias: Alarm Arm
sequence:
- service: rest_command.olarm_action
data:
actionCmd: area-arm
actionNum: 1
mode: single
icon: mdi:shield-lock-outline
alias: Alarm Disarm
sequence:
- service: rest_command.olarm_action
data:
actionCmd: area-disarm
actionNum: 1
mode: single
icon: mdi:shield-lock-open-outline
You can then add something like this to your dashboard:
Hi Guys,
I implemented the new API endpoint for Olarm and replaced the setup calls with just one call to prevent the key from getting blocked during setup.
Hello,
Thank you! I can confirm the latest version worked. Had to hard reboot the device. Standard restart didn't work.
Hello,
Thank you! I can confirm the latest version worked. Had to hard reboot the device. Standard restart didn't work.
I tried this. Can't seem to crack it.
This error originated from a custom integration.
Logger: homeassistant.config_entries
Source: custom_components/olarm_sensors/olarm_api.py:514
Integration: Olarm Sensors (documentation, issues)
First occurred: 8:40:35 AM (1 occurrences)
Last logged: 8:40:35 AM
Error setting up entry Olarm Sensors for olarm_sensors
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 387, in async_setup
result = await component.async_setup_entry(hass, self)
File "/config/custom_components/olarm_sensors/__init__.py", line 90, in async_setup_entry
await coordinator.update_data()
File "/config/custom_components/olarm_sensors/coordinator.py", line 73, in update_data
devices = await self.api.get_all_devices()
File "/config/custom_components/olarm_sensors/olarm_api.py", line 514, in get_all_devices
olarm_resp = await response.json()
File "/usr/local/lib/python3.10/site-packages/aiohttp/client_reqrep.py", line 1104, in json
raise ContentTypeError(
aiohttp.client_exceptions.ContentTypeError: 0, message='Attempt to decode JSON with unexpected mimetype: text/plain; charset=utf-8', url=URL('https://apiv4.olarm.co/api/v4/devices')
Hello, Thank you! I can confirm the latest version worked. Had to hard reboot the device. Standard restart didn't work.
I tried this. Can't seem to crack it.
This error originated from a custom integration. Logger: homeassistant.config_entries Source: custom_components/olarm_sensors/olarm_api.py:514 Integration: Olarm Sensors (documentation, issues) First occurred: 8:40:35 AM (1 occurrences) Last logged: 8:40:35 AM Error setting up entry Olarm Sensors for olarm_sensors Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/config_entries.py", line 387, in async_setup result = await component.async_setup_entry(hass, self) File "/config/custom_components/olarm_sensors/__init__.py", line 90, in async_setup_entry await coordinator.update_data() File "/config/custom_components/olarm_sensors/coordinator.py", line 73, in update_data devices = await self.api.get_all_devices() File "/config/custom_components/olarm_sensors/olarm_api.py", line 514, in get_all_devices olarm_resp = await response.json() File "/usr/local/lib/python3.10/site-packages/aiohttp/client_reqrep.py", line 1104, in json raise ContentTypeError( aiohttp.client_exceptions.ContentTypeError: 0, message='Attempt to decode JSON with unexpected mimetype: text/plain; charset=utf-8', url=URL('https://apiv4.olarm.co/api/v4/devices')
Hi @mikesierra555 , Does it work now with version 2.1.7?
Hi @rainepretorius
Still getting the same error after reinstall with new API key and device reboot. Maybe an issue with my specific installation if nobody else is reporting the problem.
Hi @rainepretorius
Still getting the same error after reinstall with new API key and device reboot. Maybe an issue with my specific installation if nobody else is reporting the problem.
You have 6 devices right? Might still trigger the API limiter even though @rainepretorius has optimised the initialisation because it needs to do a call per device if I'm not mistaken. 1 or 2 devices are fine, 6 not.
Hi @rainepretorius Still getting the same error after reinstall with new API key and device reboot. Maybe an issue with my specific installation if nobody else is reporting the problem.
You have 6 devices right? Might still trigger the API limiter even though @rainepretorius has optimised the initialisation because it needs to do a call per device if I'm not mistaken. 1 or 2 devices are fine, 6 not.
Yes, I thought this might be a problem so deleted devices from my profile. The integration still detects the deleted devices, even ones that have been temporarily shared to my profile. Need to figure out how to only call one device.
I had similar issues, @mikesierra555, and the only thing that finally worked for me was deleting the Olarm Sensors integration (Settings->Devices and Sensors), rebooting the HA host (a full reboot), and then adding the integration back again with a new API key. Everything went smoothly after that, and I didn't need to recreate any of my custom dashboards (YMMV)
Hi Rain
Thanx for the update. All works fine, but after a few seconds the API gets blocked: "Your refresh interval is set too frequent for the Olarm API to handle. Please set it to a higher duration and regenerate your API key as it has been blocked."
Changed the refresh rate but nothing helps. Have a logged a call with Olarm. Do you experience the same?