Sensor update delays and unavailable.

[rainepretorius]

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.

[willie-breedt]

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
Source: custom_components/olarm_sensors/olarm_api.py:689
Integration: Olarm Sensors (documentation, issues)
First occurred: 3:58:05 PM (1 occurrences)
Last logged: 3:58:05 PM

Your api key has been temporarily blocked due to too many request. Increase your scan interval

It's currently set to 50 seconds?

[rainepretorius]

Here is Olarm's response to my email. Hopefully, they can complete the MQTT integration within a reasonable timeline.

[willie-breedt]

Even when I make my interval 20 seconds (Which it was before the issues started) I still get the API being blocked. They requested that you send them a list of the users experiencing the issues to investigate.. Would mind sending mine? If not - I'll DM you my email address.. I don't want to publish on this forum :-)

Thanks for your awesome work on this - I've grown to used to using HA to manage my Olarm, I can't go back to using their App..

[rainepretorius]

Ok Cool. @willie-breedt . You can just pop me an email at [email protected] .

[rainepretorius]

Here is Olarm's response to my email. Hopefully, they can complete the MQTT integration within a reasonable timeline.

I have not sent them email addresses as I deem it to be personal info. You can send me an email if you want me to forward your email address to Olarm.

[Vlerrie]

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.

[blindeslakkie]

Hi All

First of all, thank you Raine for putting this great add-on together for HA.

I think it would be best if everyone who experiences this issue log a ticket with Olarm. This will show them how many users use this add-on and would hopefully then either put more resources to creating the MQTT/HomeKit/Google Home connectivity, or enough hardware/network resources to handle the amount of API calls coming in.

Before they allowed us to get an API, I got frustrated with them as they have been saying that HomeKit integration has been coming since last year. I then started to log a ticket for them every week, after that I got API access.

On one the thread below I let users know to do the same.
https://community.home-assistant.io/t/olarm-integration/384560/99

[rainepretorius]

Hi All

First of all, thank you Raine for putting this great add-on together for HA.

I think it would be best if everyone who experiences this issue log a ticket with Olarm. This will show them how many users use this add-on and would hopefully then either put more resources to creating the MQTT/HomeKit/Google Home connectivity, or enough hardware/network resources to handle the amount of API calls coming in.

Before they allowed us to get an API, I got frustrated with them as they have been saying that HomeKit integration has been coming since last year. I then started to log a ticket for them every week, after that I got API access.

On one the thread below I let users know to do the same.
https://community.home-assistant.io/t/olarm-integration/384560/99

If each user logs a ticket they will also be able to investigate each users scenario and see why they are recieving errors.

[blindeslakkie]

Hahaha, I don't think they have the "resources" to investigate every ticket, but really hope that they resolve the issues...

ps logged ticket - ##88231##

[willie-breedt]

What I found quite interesting is that this morning, I decided to delete my old integration (which failed the whole time) set it up from scratch again and magically, my Olarm is connecting again... So @rainepretorius - thanks for helping with this, you're an yster...

I'd love to know how they plan ons going with the MQTT messaging.. I just whish they would take some learning from people that have been using HA for a while to make it as good as it can be..

[rainepretorius]

Pleasure. I would also love to integrate with them via MQTT as the updates would be real-time.

[rainepretorius]

Hahaha, I don't think they have the "resources" to investigate every ticket, but really hope that they resolve the issues...

ps logged ticket - ##88231##

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.

[narensankar0529]

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)
2:51:35 PM – (WARNING) Olarm Sensors (custom integration) - message first occurred at 12:57:51 PM and shows up 127 times
Olarm Sensors: self.devices_json is empty, skipping update
2:50:34 PM – (WARNING) Olarm Sensors (custom integration) - message first occurred at 1:03:49 PM and shows up 8 times
Your refresh interval is set too frequent for the Olarm API to handle
2:50:34 PM – (ERROR) Olarm Sensors (custom integration) - message first occurred at 1:03:49 PM and shows up 8 times
Your api key has been temporarily blocked due to too many request. Increase your scan interval
2:50:34 PM – (ERROR) Olarm Sensors (custom integration) - message first occurred at 1:03:49 PM and shows up 6 times

[blindeslakkie]

Received this mail from Olarm Support:

_Hi Carl,

The problem could be that for every poll you are making 3 requests

2023/11/13 13:38:25:904 | API | GET | 200 | /api/v4/devices
2023/11/13 13:38:26:030 | API | GET | 200 | /api/v4/devices/f12d9dc1-f90c-4dfe-8ca3-ac370d651e84
2023/11/13 13:38:31:151 | API | GET | 200 | /api/v4/devices/f12d9dc1-f90c-4dfe-8ca3-ac370d651e84/actions

Anyway the MQTT integration is the connection between your Home Assistant and our API - it is faster and more efficient then polling as we can push down state updates as soon as they happen.

We are trying our best to get it finishes as soon as we can.

Apologies for the inconvenience,

Regards,

Robert_

How or were can I see if I'm making 3 requests per poll?

[rainepretorius]

Received this mail from Olarm Support:

_Hi Carl,

The problem could be that for every poll you are making 3 requests

2023/11/13 13:38:25:904 | API | GET | 200 | /api/v4/devices 2023/11/13 13:38:26:030 | API | GET | 200 | /api/v4/devices/f12d9dc1-f90c-4dfe-8ca3-ac370d651e84 2023/11/13 13:38:31:151 | API | GET | 200 | /api/v4/devices/f12d9dc1-f90c-4dfe-8ca3-ac370d651e84/actions

Anyway the MQTT integration is the connection between your Home Assistant and our API - it is faster and more efficient then polling as we can push down state updates as soon as they happen.

We are trying our best to get it finishes as soon as we can.

Apologies for the inconvenience,

Regards,

Robert_

How or were can I see if I'm making 3 requests per poll?

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.

[blindeslakkie]

Thank you Raine for your time and effort spent on this. Everyone that use your integration really appreciates it.

[blackbasilisk]

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..

[rainepretorius]

Webhooks will not work. I have been collecting the data that their webhook sends, and it only sends area actions. When the area state changes (armed disarmed, stayed, sleeped, triggered). See the attatched file. Webhooks whould have worked pretty well if they sent all the data.
View sent data here.

[keith1981king]

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

[rainepretorius]

There is no update on this thusfar. Still waiting for Olarm to contact me back.

[parautenbach]

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).

[blindeslakkie]

I'm willing to go down the route of adding myself to a list.

At this stage they are not at all helpful with any feedback, only when you start mailing them a few times a day do you get a "we will escalate this" but nothing ever happens.

[parautenbach]

I've taken a first stab at this: https://docs.google.com/spreadsheets/d/1in3u-KxIQ_xzucQN2y1YtN5reLR-_0x1xEYhBVQkdj4/edit#gid=0.

The document is world editable.

[JeremyJvR]

[JeremyJvR]

Awesome! Thank you. Sorry for the stupid question, but the back up I have of my HA is about 2 weeks old and I don't want to loose my latest changes. Is there a way to only roll back Olarm via previous back ups?

[rainepretorius]

It is a change made in Home Assistant itself and not the Olarm Integration. Thus it can only be temporarily fixed by rolling back the home assistant changes. I will see if I can create an update before the end of this week if I can find the relative error.

[JeremyJvR]

Ok awesome, thank you so much for the quick response and great work. I think we all appreciate the work you are doing! I will wait for your update (no rush, it's not that important) before I do the rollback

[rainepretorius]

I looked at the code and I am unable to get the above-mentioned error. Even with the most up-to-date version of Home Assistant.

[JeremyJvR]

I am wondering if it might not be my HA installation that is causing the error. I am getting this when I am trying to upgrade Supervisor. And I am not too sure what it mean.

Error updating Home Assistant Supervisor: Update of Supervisor failed: Can't install ghcr.io/home-assistant/amd64-hassio-supervisor:2024.01.1: 500 Server Error for http+docker://localhost/v1.42/images/create?tag=2024.01.1&fromImage=ghcr.io%2Fhome-assistant%2Famd64-hassio-supervisor&platform=linux%2Famd64: Internal Server Error ("Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io: no such host")

[parautenbach]

I received this update today regarding a local MQTT interface:

We are busy testing internally and will make an announcement when it ready.

[blindeslakkie]

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. 

[parautenbach]

Oof, would you mind cleaning up your reply here on GitHub? It's a bit ineligible. I guess you replied to the issue via email. Might be good to turn off HTML mode for such replies. :-)

[blindeslakkie]

Apologies, yes replied via mail.
It is fixed now.

[parautenbach]

Thanks a mil. :-)

[blindeslakkie]

HI All

Has anyone had an update regarding MQTT access for the Olarm app/device?

[parautenbach]

Nope, only another promise in March.

[blindeslakkie]

-->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.

[zAAmpie]

Checked in again with Olarm support:

It is still in development, but we are unable to provide any sort of timeline for this as yet.

I suspect it's fairly low on their priority list. Possibly due to limited interest or product differentiation from a general consumer level.

[zAAmpie]

Yeah, could definitely be. In which case pinging every few months might just remind the person to pick it up a bit again :)

[boereworswizard]

Checked in again with Olarm support:

It is still in development, but we are unable to provide any sort of timeline for this as yet.

I suspect it's fairly low on their priority list. Possibly due to limited interest or product differentiation from a general consumer level.

I've sent them an email to give them a gentle nudge.

What is your scan interval set to? I've currently set it to 150 in order to avoid the too many requests issue.

[zAAmpie]

What is your scan interval set to? I've currently set it to 150 in order to avoid the too many requests issue.

Currently set to 30 seconds, which seems to work with my single device. I do want to experiment to see if I can lower that a bit by not making all the requests every time, but not too optimistic.

[rainepretorius]

Checked in again with Olarm support:

It is still in development, but we are unable to provide any sort of timeline for this as yet.

I suspect it's fairly low on their priority list. Possibly due to limited interest or product differentiation from a general consumer level.

hat's a clever approach! By setting a high scan_interval, you prevent frequent polling and avoid unnecessary API calls. Then, by using a webhook to refresh only when needed, you're essentially on-demand updating without the constant background refreshes.

Here's a quick breakdown:

High Scan Interval: Set scan_interval to something like 300 seconds or even higher, depending on your needs. This minimizes background updates.

Webhook Trigger: In Home Assistant, create an automation with a webhook trigger. This gives you a unique URL that, when called, triggers the automation.

Olarm API: On the Olarm API page, add the webhook URL in place of a usual endpoint.

Automation Action: In your Home Assistant automation, use button.press for the Olarm refresh button entity. This will refresh the data whenever the webhook is triggered.

This way, you can control exactly when updates happen without hitting rate limits or flooding with requests.

[parautenbach]

I use the webhook in the package I created (HA YAML config using REST commands and such), but the main issue is that you cannot get zone updates this way. Everything else works though.

[rainepretorius]

I recently explored AdGuard for enhancing network security on my local network and discovered that Olarm already utilizes MQTT for communication. Given this information, there seems to be no technical barrier preventing the development of a native Olarm integration or, at a minimum, allowing users to connect directly to the MQTT server. Given the secure foundation provided by MQTT, enabling direct integration would offer significant benefits and streamline the connection process for users. I believe this enhancement could be implemented efficiently, given the existing communication protocol.

[zAAmpie]

I cannot quite confirm, but based on some packet captures it's likely that they only use MQTT for the alarm state and not the sensors. Basically to avoid any delay when alarm goes off. I think that's also why it's the only state that gets sent through via webhook.

Otherwise it looks like the device is polled/reports every 20 seconds or so, and sensor state only really gets updated once per minute (possibly round robin with events). So it wouldn't matter if we could poll the web API every second, because it would just report the same data for a full minute. Not quite sure about the protocol between the alarm and Olarm, but if they are polling it for info it would likely require some extensive changes to convert everything to local MQTT for things other than the alarm state.

[parautenbach]

and not the sensors

I don't think so, because if you use the app, the zone changes are very fast to display, which isn't typical of a polling setup. Polling is also awfully inefficient.

[rainepretorius]

I think the only way this can work is if you connect to the same broker the Olarm is connecting to, as you'd lose external functionality if you spoofed the Olarm's broker by redirecting the DNS lookup. I think this is what you meant too, but I'm just clarifying to make sure we're thinking the same thing. This would, unfortunately, mean that it will be in the cloud. Granted, it wouldn't be no worse than today, and you'll get real-time updates, but still, I would much rather prefer something local.

I ran a stealth port scan against that host now, and the only open port is 443 – which is interesting, since MQTT's secure port is by default 1883. Of course, it's a common security practice to not use default port assignments, for example, people will often run SSH on a non-standard port.

Since that's the only open port, and we know it's MQTT, I tried to connect to it using my Olarm username and password, but that failed with a "bad username/password error". That means, a connection was successfully established to the broker, because the broker responded with that error. My current guess is that they don't use one's own credentials, but likely has a secure/secret token on each Olarm device (dear god, I hope so, otherwise it's a single shared secret).

I also had to disable certificate validation to be able to connect at all (the connection was refused otherwise, so the server wouldn't even respond).

I checked by creating a spoofed broker. THey are using certificate authentication. SO no username or password. It will only work if the certificate fiel is somehow gotten from the olarm device itself.

[zAAmpie]

Would love for that to be the case, but when I deliberately walked around to change the state of the sensors I saw no immediate traffic between Olarm and their web server... And even polling every 15secs it took almost exactly 1 minute to get the state change. Perhaps they prioritise? If they do do MQTT for all it would make it a lot easier to port locally or to expose that online.

[parautenbach]

I checked by creating a spoofed broker. THey are using certificate authentication. SO no username or password. It will only work if the certificate fiel is somehow gotten from the olarm device itself.

@rainepretorius ok, a client cert actually makes the most sense.

Would love for that to be the case, but when I deliberately walked around to change the state of the sensors I saw no immediate traffic between Olarm and their web server... And even polling every 15secs it took almost exactly 1 minute to get the state change.

@zAAmpie it seems I misremembered. I can confirm: Just did a test too. There's so much one can do if one can get real-time zone updates.

[blackbasilisk]

Rainepretorius/Olarm-Ha-Integration, you currently have slightly more clout than a bunch of random guys. Any chance you can ask if they have an unofficial local MQTT publisher they can make available on the device? If Tasmota can have space for MQTT, I'm sure the Olarm devices can ;) Even if it's read only so we can start using the state changes as triggers! Then we can reduce the API polling and use that for actions only i.e. setting the alarm. I just logged another official ticket asking about MQTT support. We've had our Olarm for 2 years 11 months now and 12 months or more before that there was talk of supporting HA already :( They also upped their sub pricing by 200% after the first year we had it, so I just wish they would prioritize this before another vendor does. There SIA integration which is read only and supports Ajax. We're moving our office away from Olarm and over to Ajax sadly because of lack of integration (and other reasons though) so I'm holding thumbs Olarm comes to the party SOON, Let's all log tickets with Olarm directly and show them how many need support for this! I know we are not the main market, but even some form of read-only unofficial local MQTT would be a big step in the right direction already and help them test the waters perhaps.

…

On Sun, 10 Nov 2024 at 22:00, Pieter Rautenbach ***@***.***> wrote: I checked by creating a spoofed broker. THey are using certificate authentication. SO no username or password. It will only work if the certificate fiel is somehow gotten from the olarm device itself. @rainepretorius <https://github.com/rainepretorius> ok, a client cert actually makes the most sense. Would love for that to be the case, but when I deliberately walked around to change the state of the sensors I saw no immediate traffic between Olarm and their web server... And even polling every 15secs it took almost exactly 1 minute to get the state change. @zAAmpie <https://github.com/zAAmpie> it seems I misremembered. I can confirm: Just did a test too. There's so much one can do if one can get real-time zone updates. — Reply to this email directly, view it on GitHub <#85 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AU2SEOCXYLWKCBUNNRQMDNLZ763NLAVCNFSM6AAAAAA6NLWI2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRQGYZDQOI> . You are receiving this because you commented.Message ID: <rainepretorius/olarm-ha-integration/repo-discussions/85/comments/11206289 @github.com>

-- Sincerely, Dave Coates 084 548 0077

[parautenbach]

Any chance you can ask if they have an
unofficial local MQTT publisher they can make available on the device?

This has been discussed several times, but they haven't committed to anything. Note my post on 9 Jan, for example. I've been in contact with one of their devs about this, but unfortunately nothing's been released.

[blindeslakkie]

I have logged several tickets for this already, get the same feedback as above, that it is in the "pipeline"...

I have logged another ticket today --> ##131528##

They only way that they will maybe do this earlier is if everyone logs a ticket for this, I have also said this earlier in the post timeline...

[boereworswizard]

Got the same response too

"It is on our roadmap, however, currently we are unable to provide an ETA regarding the implementation of this."

[rainepretorius]

I am able to provide the CTO's email address to those who email me at [email protected] with the Subject Justin. I also sent him an email to see if I can figure out where on the projectboard it will lie.

[rainepretorius]

Hi Raine

MQTT integration is unfortunately not possible.

Regards

Justin

Justin Zondagh

CTO

Olarm (Pty) Ltd

[rainepretorius]

Sounds like they're getting tired of our constant MQTT queries 😆

I'm curious though, if Olarm can connect to the serial port and read/write to the panel, can't we build something similar? I guess the complicated bit is the protocol and encryption used in communicating with the panel, just wondering if someone has seen a library or something somewhere that we can load onto an Arduino or similar, and build or own MQTT integration...

For Paradox, it does already exist. It is paradox alarm interface. I am able to build a device that allows telnet serial access to a paradox alarm system. There is also one that uses an ESP32 to interface to a DSC alarms keybus.

[parautenbach]

@MrPrisoner I considered buying a Konnected kit, but it looked like too much of a hassle. They use ESP modules. I think the Olarm has an ESP in it too.

I have an IDS x64 and I was told it's an SA product made by ADT. I suppose one might be able to get the protocols from them. Olarm must've gotten it somehow.

The serie port can also be used to connect it to a computer with a special USB cable. Installers can use that to quickly configure an alarm, but I've never seen an installer use that. They just use the codes.

Perhaps we can pitch in and buy an Olarm just for reverse engineering.

There's just one thing though: My security company monitors my system via the Olarm (i.e. no traditional radio anymore). From this perspective, the most ideal situation would still be if Olarm just opened up the comms.

[blindeslakkie]

I see that there are already a few people using ESP32 devices for this function. The board itself is between R150 - R180 from Communica and Robofactory. Not sure if you need anything else or the board beside a power cable and power brick.

Here are some integrations with HA if someone has en ESP32 lying around.

https://github.com/Dilbert66/esphome-dsckeybus
https://github.com/taligentx/dscKeybusInterface

[parautenbach]

In my case, the ESP is the easy part, actually. What one needs are the protocols. I haven't been able to find it for my IDS x64.

[MrPrisoner]

Same for me on IDS x64 - I have a couple ESPs doing various IoT things, like you say that's the easy part. Can't find anything though on how to read/write to the panel via serial. Olarm probably paid (or still pay) a licensing or royalty fee to IDS to get their hands on the protocol details.

[blackbasilisk]

Unfortunately, it seems Justin just isn’t interested in entertaining the idea and chose to shut it down with no discussion on the topic being a possibility. Perhaps there is some form of security or exposure risk for Olarm which they don’t want to be associated with. Understandable but an explanation would have been nice. Either way, it sounds like Olarm is dead in the water as far as Home Assistant integration goes other than what you’ve developed so far Raine. It’s a shame. You’ve done a great job and there was real promise :( Sincerely, Dave Coates 084 548 0077

…

On Tue, 12 Nov 2024 at 12:23, MrPrisoner ***@***.***> wrote: Same for me on IDS x64 - I have a couple ESPs doing various IoT things, like you say that's the easy part. Can't find anything though on how to read/write to the panel via serial. Olarm probably paid (or still pay) a licensing or royalty fee to IDS to get their hands on the protocol details. — Reply to this email directly, view it on GitHub <#85 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AU2SEOHEIJUBCQCDB2IADX32AHJKLAVCNFSM6AAAAAA6NLWI2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRSGQYTINI> . You are receiving this because you commented.Message ID: <rainepretorius/olarm-ha-integration/repo-discussions/85/comments/11224145 @github.com>

[parautenbach]

I think one legit reason would be authorisation: If they gave customers access to their MQTT broker, you need to secure the topics. While it's possible, it is actually something that might require quite a lot of work, depending on how their topics are currently defined.

[rainepretorius]

Hi everyone,

I’ve started developing a local solution for controlling alarm panels and garage doors. I’d love to hear your ideas and suggestions about features you would value in a device like this. Your input would be greatly appreciated! Here is the Google docs link:
https://docs.google.com/document/d/1LCsMAnFfueXbLIA3WjVQSY-pWMskw-Rb2BPuvcPqx60/edit?usp=drivesd

[Cha0s2nd]

I managed to do a simple rest template to fix this entire api limit issue.
Below is an example with 2 of the sensors, no automations needed and 10 sec intervals work fine.

alarm_control_panel:
  - platform: template
    panels:
      olarm_house:
        unique_id: "alarm_control_panel.olarm_house"
        name: "House"
        value_template: "{{ states('sensor.olarm_area_house') }}"
        code_arm_required: false
        code_format: number
        arm_away:
          service: rest_command.olarm_actions
          data:
             actionCmd: area-arm
             actionNum: 1
        arm_home:
          service: rest_command.olarm_actions
          data:
             actionCmd: area-stay
             actionNum: 1
        arm_night:
          service: rest_command.olarm_actions
          data:
             actionCmd: area-sleep
             actionNum: 1
        disarm:
          - condition: template
            value_template: !secret olarm_code
          - service: rest_command.olarm_actions
            data:
              actionCmd: area-disarm
              actionNum: 1
              
rest_command:
  olarm_actions:
    url: !secret olarm_device_actions_url
    method: POST
    headers:
      User-Agent: Home Assistant
      Authorization: !secret olarm_api_key
    payload: '{ "actionCmd": "{{actionCmd}}", "actionNum": {{actionNum}} }'
    content_type:  'application/json'
    
rest:
  - resource: !secret olarm_device_url
    method: GET
    scan_interval: 10
    headers:
      User-Agent: Home Assistant
      Authorization: !secret olarm_api_key
    sensor:
      - name: "Olarm Area House"
        unique_id: "olarm_area_house"
        value_template: |
            {% if value_json.deviceState.areas[0] == 'notready' %}pending{% endif %}
            {% if value_json.deviceState.areas[0] == 'disarm' %}disarmed{% endif %}
            {% if value_json.deviceState.areas[0] == 'arm' %}armed_away{% endif %}
            {% if value_json.deviceState.areas[0] == 'sleep' %}armed_night{% endif %}
            {% if value_json.deviceState.areas[0] == 'stay' %}armed_home{% endif %}
            {% if value_json.deviceState.areas[0] == 'alarm' %}triggered{% endif %}
            {% if value_json.deviceState.areas[0] == 'fire' %}triggered{% endif %}
            {% if value_json.deviceState.areas[0] == 'emergency' %}triggered{% endif %}
        device_class: enum
      - name: "Olarm Area Triggers House"
        unique_id: "olarm_area_triggers_house"
        value_template: "{{ value_json.deviceState.areasDetail[0] }}"
    binary_sensor:
      - name: "Olarm AC"
        unique_id: "olarm_ac"
        value_template: "{{ value_json.deviceState.power.AC }}"
        device_class: power
      - name: "Olarm Battery"
        unique_id: "olarm_battery"
        value_template: "{{ int(value_json.deviceState.power.Batt) != 1 }}"
        device_class: battery
      - name: "Olarm Zone Kombuis Skuifdeur"
        unique_id: "olarm_zone_kombuis_skuifdeur"
        value_template: "{{ value_json.deviceState.zones[0] == 'a' }}"
        device_class: door
      - name: "Olarm Zone Bypass Kombuis Skuifdeur"
        unique_id: "olarm_zone_bypass_kombuis_skuifdeur"
        value_template: "{{ value_json.deviceState.zones[0] == 'b' }}"
      - name: "Olarm Zone Kombuis"
        unique_id: "olarm_zone_kombuis"
        value_template: "{{ value_json.deviceState.zones[1] == 'a' }}"
        device_class: motion
      - name: "Olarm Zone Bypass Kombuis"
        unique_id: "olarm_zone_bypass_kombuis"
        value_template: "{{ value_json.deviceState.zones[1] == 'b' }}"

[boereworswizard]

I managed to do a simple rest template to fix this entire api limit issue. Below is an example with 2 of the sensors, no automations needed and 10 sec intervals work fine.

alarm_control_panel:
  - platform: template
    panels:
      olarm_house:
        unique_id: "alarm_control_panel.olarm_house"
        name: "House"
        value_template: "{{ states('sensor.olarm_area_house') }}"
        code_arm_required: false
        code_format: number
        arm_away:
          service: rest_command.olarm_actions
          data:
             actionCmd: area-arm
             actionNum: 1
        arm_home:
          service: rest_command.olarm_actions
          data:
             actionCmd: area-stay
             actionNum: 1
        arm_night:
          service: rest_command.olarm_actions
          data:
             actionCmd: area-sleep
             actionNum: 1
        disarm:
          - condition: template
            value_template: !secret olarm_code
          - service: rest_command.olarm_actions
            data:
              actionCmd: area-disarm
              actionNum: 1
              
rest_command:
  olarm_actions:
    url: !secret olarm_device_actions_url
    method: POST
    headers:
      User-Agent: Home Assistant
      Authorization: !secret olarm_api_key
    payload: '{ "actionCmd": "{{actionCmd}}", "actionNum": {{actionNum}} }'
    content_type:  'application/json'
    
rest:
  - resource: !secret olarm_device_url
    method: GET
    scan_interval: 10
    headers:
      User-Agent: Home Assistant
      Authorization: !secret olarm_api_key
    sensor:
      - name: "Olarm Area House"
        unique_id: "olarm_area_house"
        value_template: |
            {% if value_json.deviceState.areas[0] == 'notready' %}pending{% endif %}
            {% if value_json.deviceState.areas[0] == 'disarm' %}disarmed{% endif %}
            {% if value_json.deviceState.areas[0] == 'arm' %}armed_away{% endif %}
            {% if value_json.deviceState.areas[0] == 'sleep' %}armed_night{% endif %}
            {% if value_json.deviceState.areas[0] == 'stay' %}armed_home{% endif %}
            {% if value_json.deviceState.areas[0] == 'alarm' %}triggered{% endif %}
            {% if value_json.deviceState.areas[0] == 'fire' %}triggered{% endif %}
            {% if value_json.deviceState.areas[0] == 'emergency' %}triggered{% endif %}
        device_class: enum
      - name: "Olarm Area Triggers House"
        unique_id: "olarm_area_triggers_house"
        value_template: "{{ value_json.deviceState.areasDetail[0] }}"
    binary_sensor:
      - name: "Olarm AC"
        unique_id: "olarm_ac"
        value_template: "{{ value_json.deviceState.power.AC }}"
        device_class: power
      - name: "Olarm Battery"
        unique_id: "olarm_battery"
        value_template: "{{ int(value_json.deviceState.power.Batt) != 1 }}"
        device_class: battery
      - name: "Olarm Zone Kombuis Skuifdeur"
        unique_id: "olarm_zone_kombuis_skuifdeur"
        value_template: "{{ value_json.deviceState.zones[0] == 'a' }}"
        device_class: door
      - name: "Olarm Zone Bypass Kombuis Skuifdeur"
        unique_id: "olarm_zone_bypass_kombuis_skuifdeur"
        value_template: "{{ value_json.deviceState.zones[0] == 'b' }}"
      - name: "Olarm Zone Kombuis"
        unique_id: "olarm_zone_kombuis"
        value_template: "{{ value_json.deviceState.zones[1] == 'a' }}"
        device_class: motion
      - name: "Olarm Zone Bypass Kombuis"
        unique_id: "olarm_zone_bypass_kombuis"
        value_template: "{{ value_json.deviceState.zones[1] == 'b' }}"

Could you put a quote on how to get this working for us plebs?

[zAAmpie]

Problem again for the sensors is that it does not matter if you query every 10 seconds if the values only change once per minute on the server.

[Cha0s2nd]

Problem again for the sensors is that it does not matter if you query every 10 seconds if the values only change once per minute on the server.

Look it works, using the sensors for anything other than info is useless even if they are real-time, better to get presense sensors for that.
They need too much motion to trigger and don't stay on, triggering a light works but then you have to keep it on for 30min to stay on consistent enough while you are in the room.

I use this purely to see what sensors are causing the alarm to not be ready.

[Cha0s2nd]

I managed to do a simple rest template to fix this entire api limit issue. Below is an example with 2 of the sensors, no automations needed and 10 sec intervals work fine.

alarm_control_panel:
  - platform: template
    panels:
      olarm_house:
        unique_id: "alarm_control_panel.olarm_house"
        name: "House"
        value_template: "{{ states('sensor.olarm_area_house') }}"
        code_arm_required: false
        code_format: number
        arm_away:
          service: rest_command.olarm_actions
          data:
             actionCmd: area-arm
             actionNum: 1
        arm_home:
          service: rest_command.olarm_actions
          data:
             actionCmd: area-stay
             actionNum: 1
        arm_night:
          service: rest_command.olarm_actions
          data:
             actionCmd: area-sleep
             actionNum: 1
        disarm:
          - condition: template
            value_template: !secret olarm_code
          - service: rest_command.olarm_actions
            data:
              actionCmd: area-disarm
              actionNum: 1
              
rest_command:
  olarm_actions:
    url: !secret olarm_device_actions_url
    method: POST
    headers:
      User-Agent: Home Assistant
      Authorization: !secret olarm_api_key
    payload: '{ "actionCmd": "{{actionCmd}}", "actionNum": {{actionNum}} }'
    content_type:  'application/json'
    
rest:
  - resource: !secret olarm_device_url
    method: GET
    scan_interval: 10
    headers:
      User-Agent: Home Assistant
      Authorization: !secret olarm_api_key
    sensor:
      - name: "Olarm Area House"
        unique_id: "olarm_area_house"
        value_template: |
            {% if value_json.deviceState.areas[0] == 'notready' %}pending{% endif %}
            {% if value_json.deviceState.areas[0] == 'disarm' %}disarmed{% endif %}
            {% if value_json.deviceState.areas[0] == 'arm' %}armed_away{% endif %}
            {% if value_json.deviceState.areas[0] == 'sleep' %}armed_night{% endif %}
            {% if value_json.deviceState.areas[0] == 'stay' %}armed_home{% endif %}
            {% if value_json.deviceState.areas[0] == 'alarm' %}triggered{% endif %}
            {% if value_json.deviceState.areas[0] == 'fire' %}triggered{% endif %}
            {% if value_json.deviceState.areas[0] == 'emergency' %}triggered{% endif %}
        device_class: enum
      - name: "Olarm Area Triggers House"
        unique_id: "olarm_area_triggers_house"
        value_template: "{{ value_json.deviceState.areasDetail[0] }}"
    binary_sensor:
      - name: "Olarm AC"
        unique_id: "olarm_ac"
        value_template: "{{ value_json.deviceState.power.AC }}"
        device_class: power
      - name: "Olarm Battery"
        unique_id: "olarm_battery"
        value_template: "{{ int(value_json.deviceState.power.Batt) != 1 }}"
        device_class: battery
      - name: "Olarm Zone Kombuis Skuifdeur"
        unique_id: "olarm_zone_kombuis_skuifdeur"
        value_template: "{{ value_json.deviceState.zones[0] == 'a' }}"
        device_class: door
      - name: "Olarm Zone Bypass Kombuis Skuifdeur"
        unique_id: "olarm_zone_bypass_kombuis_skuifdeur"
        value_template: "{{ value_json.deviceState.zones[0] == 'b' }}"
      - name: "Olarm Zone Kombuis"
        unique_id: "olarm_zone_kombuis"
        value_template: "{{ value_json.deviceState.zones[1] == 'a' }}"
        device_class: motion
      - name: "Olarm Zone Bypass Kombuis"
        unique_id: "olarm_zone_bypass_kombuis"
        value_template: "{{ value_json.deviceState.zones[1] == 'b' }}"

Could you put a quote on how to get this working for us plebs?

You can just copy it to you config and setup the secrets, the zones are the same, just zone[0] is zone 1 on the app so - 1 basically, zone[19] would be 20 and so on same for the areas and devices.

If you need help send me an email.

[blackbasilisk]

Sounds like we need a different approach entirely. We've installed Ajax at one of our homes and at the office. Works so much better than Olarm, but unfortunately no integration to HA yet. It's in the top 3 requested features. Holding thumbs it happens, cause then I'm dumping Olarm as fast as I can.

…

On Sat, 30 Nov 2024 at 20:22, zAAmpie ***@***.***> wrote: Problem again for the sensors is that it does not matter if you query every 10 seconds if the values only change once per minute on the server. — Reply to this email directly, view it on GitHub <#85 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AU2SEOBKDJEG4SSII4XQVC32DH65XAVCNFSM6AAAAAA6NLWI2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNBSGM2DONQ> . You are receiving this because you commented.Message ID: <rainepretorius/olarm-ha-integration/repo-discussions/85/comments/11423476 @github.com>

-- Sincerely, Dave Coates 084 548 0077

[rainepretorius]

What does this mean for our security companies? will they still be able to use the Radio antenna? I am not sure what ports they use to connect to the alarm system, but i would like your device and still have my armed response connected to my alarm as well.

Most alarm companies' radios are triggered via a pgm (programmable output) or the siren activating. It works exactly the same way that the Olarm works when connecting to a panel.

[MrPrisoner]

This sounds amazing, exactly what we always hoped Olarm would be able to do. I'm curious what hardware you're using, and what your approach would be for releasing/selling your solution - open source / software license / complete solution like Olarm?

[parautenbach]

What does this mean for our security companies? will they still be able to use the Radio antenna? I am not sure what ports they use to connect to the alarm system, but i would like your device and still have my armed response connected to my alarm as well.

Most alarm companies' radios are triggered via a pgm (programmable output) or the siren activating. It works exactly the same way that the Olarm works when connecting to a panel.

What about having both this solution and an Olarm connected? The Olarm replaced my old radio – it's been removed – or are you suggesting one removes the Olarm and revert to the old-style radio instead?

[rainepretorius]

What does this mean for our security companies? will they still be able to use the Radio antenna? I am not sure what ports they use to connect to the alarm system, but i would like your device and still have my armed response connected to my alarm as well.

Most alarm companies' radios are triggered via a pgm (programmable output) or the siren activating. It works exactly the same way that the Olarm works when connecting to a panel.

What about having both this solution and an Olarm connected? The Olarm replaced my old radio – it's been removed – or are you suggesting one removes the Olarm and revert to the old-style radio instead?

There can only be one device connected to a Paradox alarm system via the serial port at a time. I am not sure about other alarm systems.

[rainepretorius]

This sounds amazing, exactly what we always hoped Olarm would be able to do. I'm curious what hardware you're using, and what your approach would be for releasing/selling your solution - open source / software license / complete solution like Olarm?

The device will be closed source, but run with all the features, etc, running within the local network. The final hardware has not been finalized yet, but I will probably use esp32's or a small sbc.

[blackbasilisk]

@rainepretorius/olarm-ha-integration ***@***.***> how would you feel about scheduling a meeting with Justin Zondag? I'm sure others in the community would join. Purpose of the meeting would be to discuss what is possible with their tech and what limitations there are to the integration and if there is perhaps a way we (as enthusiasts) can do to help overcome this? I figure if we rather come with the angle of assisting, rather than demanding, perhaps they might be more likely to be open minded. We might then also be able to understand why they are doing what they are doing instead of just bashing our heads against the wall. Thoughts?

…

On Mon, 2 Dec 2024 at 08:28, Dave Coates ***@***.***> wrote: Sounds like we need a different approach entirely. We've installed Ajax at one of our homes and at the office. Works so much better than Olarm, but unfortunately no integration to HA yet. It's in the top 3 requested features. Holding thumbs it happens, cause then I'm dumping Olarm as fast as I can. On Sat, 30 Nov 2024 at 20:22, zAAmpie ***@***.***> wrote: > Problem again for the sensors is that it does not matter if you query > every 10 seconds if the values only change once per minute on the server. > > — > Reply to this email directly, view it on GitHub > <#85 (reply in thread)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AU2SEOBKDJEG4SSII4XQVC32DH65XAVCNFSM6AAAAAA6NLWI2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNBSGM2DONQ> > . > You are receiving this because you commented.Message ID: > <rainepretorius/olarm-ha-integration/repo-discussions/85/comments/11423476 > @github.com> > -- Sincerely, Dave Coates 084 548 0077

-- Sincerely, Dave Coates 084 548 0077