I want to share a Custom Component for Securitas Direct Alarm systems (AKA Verisure for EU and LATAM, not USA)
It is based on API mobile so is fast and reliable enough.
to make more and more speed: Call “securitas” without parameters get the “supposed” alarm state without the need of consult the alarm for the state.
to be HA alarm component states compatible. The input are now the states in HA: armed_away, armed_home, armed_night and disarmed, and the output is a direct json.
hide user and password from command-line parameters (ps listing process).
etc…
Now, I am working in configure an alarm_manual component that “sync” with real “Securitas” alarm: If you change in HA, change the Securitas alarm, and if you change the Securitas" alarm (with real panel, keys, remotes…), change the state of the HA alarm.
I have created a command line sensor that every minute get the state of the Securitas Alarm, and a shell_command for arm/disarm (call to “securitas armed_away”). But my problem now is that incredibly, HA lacks to get the output of the shell_command, so you cannot known if secuence was really completed.
I’m not using hassio, but I ended in this post time ago looking for a python script or something to integrate Verisure, IFTTT and Alexa everything together.
This uses the Mobile App API, so it’s quite fast (it actually has a limit rate of 1 second between calls, as the API complains if you throw too much requests).
Uaaauuuuh Xavi, best new about this… now it’s too late. Tomorrow I write ideas about. The mobile api is faster and probably better than my reverse engeniereD Web script .
I think we could build an alarm custom component around this.
Have you tried get the log from mobile api? As securitas hasn’t websoctets services, polling needs to be implemented to sync HA alarm and securitas alarm… so probably log access is faster than ask for state (I.e. every minute ).
Hi @segalion, I’ve added a new function called log() and modified all the outputs so it actually dumps a full json of the API response instead of just the status codes.
@segalion Well, the ID is tagged as “iPhone” as it seems Securitas is doing some kind of “check” on the beginning of the string, as I’m just adding at the end the date and time whilst the App does some kind of hash. I guess you can just swap iPhone for Android in the ID string it will work anyway.
I got the API reverse engineering the Mobile App, just proxying the requests and doing a man in the middle SSL attack. In this way, I’ve been able to just press buttons in the App and see what the App was doing. All the rest has been trial and error, as the App sends other stuff (I guess for logging and debugging) like the App version, iPhone Version … but that it doesn’t seem “mandatory” to make the API answer the requests.
I guess Securitas will keep this working with maybe minor changes, as the mobile apps need the API anyway, and doing major changes would require refactoring both the mobile apps and the API itself. I would expect less changes than in the webpage, so seems easier to maintain compared with your screen scrapping script (I tried at first your approach as well, but using Selenium, and it was ridiculously slow).
A completely different story is that maybe they detect that we’re using the API directly, making them harden the log-in process with two factor authentications and the likes. This would obviously kill any integration option.
Just for reference, I got as well the list of available API methods decompiling the Android APK. Unfortunately I just managed to get the strings, as the code is obfuscated and therefore quite tricky to figure out the actual code for the API interaction.
I haven’t debugged all of them to see the required parameters and expected outputs, but you can get an idea of the potential.
@Cebeerre
If you “RE” the Mobile App, more incredible and valuable work!!! (not everyone appreciates the great work that reverse engineering takes).
I think the first step could be create a custom component based on alarm panel enity, I thing the first aprox is to replicate the verisure (USA version) component here
just create a directory /home/homeassistant/.homeassistant/custom_components/verisure_spain/alarm_control_panel/
The verisure.py need to change proper calls for yours, and init the component with proper reading config yaml parameters (username, password, installation, country_code). You can see an example in my custom_component (as sensor) here
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/urllib3/contrib/pyopenssl.py", line 453, in wrap_socket
cnx.do_handshake()
File "/usr/local/lib/python3.7/dist-packages/OpenSSL/SSL.py", line 1915, in do_handshake
self._raise_ssl_error(self._ssl, result)
File "/usr/local/lib/python3.7/dist-packages/OpenSSL/SSL.py", line 1647, in _raise_ssl_error
_raise_current_error()
File "/usr/local/lib/python3.7/dist-packages/OpenSSL/_util.py", line 54, in exception_from_error_queue
raise exception_type(errors)
OpenSSL.SSL.Error: [('SSL routines', 'tls_process_ske_dhe', 'dh key too small')]
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 600, in urlopen
chunked=chunked)
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 343, in _make_request
self._validate_conn(conn)
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 841, in _validate_conn
conn.connect()
File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 344, in connect
ssl_context=context)
File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 344, in ssl_wrap_socket
return context.wrap_socket(sock, server_hostname=server_hostname)
File "/usr/lib/python3/dist-packages/urllib3/contrib/pyopenssl.py", line 459, in wrap_socket
raise ssl.SSLError('bad handshake: %r' % e)
ssl.SSLError: ("bad handshake: Error([('SSL routines', 'tls_process_ske_dhe', 'dh key too small')])",)
[....]