INIM API for Home assistant

This document contains my findings on accessing the INIM alarm panel through local internet by
using Home Assistant’s http request functionality. I used Wireshark with the filter set to “ip.addr ==
192.168.1.92”, the local address of my INIM alarm panel. I tested the commands and checked their
json output with Postman. The findings basically mimick the functionality of the panel’s local
webserver, when a SmartLAN-G board is present. My panel’s webserver address is
192.168.1.92:5050. There is an installation manual to set up the two versions of this board
SmartLAN-G and SmartLAN-SI. I own the G version and have therefore not experimented with the SI
board. The documentation says the SI board does not have a local webserver.

How to execute alarm arming scenario’s

Execute an http command (POST) to the following url:

192.168.1.92:5050/cgi-bin/web.cgi?user=xxx&pass=yyy&code=zzz

With the following parameters:

user=yourusername; pass=yourpassword; code=yourcode
One user reported that a (session) key “tk” must also be provided, but also said that the key does
not ever change. Another key he mentioned was “qindex”, always being zero.
I have a system acquired in 2014 that does not require these two keys. If you need the key, you need
to get it through Wireshark.

The command for executing an arming scenario is “do_sce”, followed by the additional parameter
“par” for the relevant scenario (I have five arming scenarios):

mod par Scenarion name

do_sce 0 Name of scenario 0: e.g. “All off”
do_sce 1 etc
do_sce 2
do_sce 3
do_sce 4

The response from the server is OK 200 and a json file:

{"do_sce":"0"}

With these data I created 5 restfull commands in HA to

execute the five alarm scenarios, for example, see on the
right:

Then I created scripts that execute these restful

commands. This is because restful commands
cannot be called directly from the Lovelace front-
end, only by way of a script. I added a 100 milisecs
delay to the script to show the “on” image when
the script executes. See next.

1
For the front-end I created a picture elements card with
the relevant tap actions. Key is adding the script as an
entity so that on and off states in state_image can be
used. I created two different PNG images for the button
in ON and OFF state. When the button is pressed, the
image briefly changes colour.

Create sensors for alarm scenario setting

To find out which alarm scenario is currently set, I use the following parameters:

mod par Action

sce now Provides the name of current alarm setting in json
file

The response is a json file:

{
"lb": "Alles uit ", "id": "2"
}
“lb” is the label of the current scenario. “id” is the id number of the scenario that is currently on.

I used this response to create 5 binary_sensors in NodeRed with the on/off status of each alarm
scenario. I ensured that if one status goes “on” the others are set to “off”. Depending on the
required response speed you can update these sensors every 10 – 60 secs or so.

Template switch for arming scenarios

With scenarios to turn on and off and sensors for current state of each snenario done, we can now
create template switches for setting and reading the alarm scenario’s in Home Assistant as follows:

Reading alarm output states

The webserver’s second screen is “commands”. Commands are the panel’s defined outputs, for
example siren (for signalling alarms), flasher (for signalling silent alarms) and blinker (to signal that
the alarm is armed). In addition, the INIM hardware allows defining customized outputs. I have

2
created two outputs which connect to a relay disconnecting the power of the SmartLAN-G board (5
secs) and the power to my OpenSprinkler system. In both cases to resolve their regular LAN/wifi
disconnection issues.

I have five outputs defined, that when “on” perform the following functions:
• “Siren sounding” Alarm is tiggered, alarm is ringing
• “Blinking” One of the alarm arming scenarios is on
• “Flashing” Silent alarm indicating panel faults and errors
• “LAN” interrupt” Output interrupting INIM internal LAN pwr supply for a 5 sec reset
• “OpenSprinkler reset” Output interrupting OpenSpinkler pwr supply for a 5 sec reset

To get the output state for each of the “commands” I used “mod=cmd” as parameter for the restful
request:

mod Action
cmd Command status

Response in json is:

{"cmd": [
{"lb": "LAN interrupt ", "st": "0", "id": "10"},
{"lb": "OSprinkler reset", "st": "0", "id": "11"},
{"lb": "Sirene ", "st": "0", "id": "0" },
{"lb": "Knipper aan ", "st": "0", "id": "1" },
{"lb": "Siren Flasher ", "st": "0", "id": "2" }]

st=status: 0=off, 1= on

Switching the outputs (sirens, relays) on/off:

mod par act Action

do_cmd 11 1 Switch output 11 on (OSprinkler reset)

par = relevant output id (see aboven json output)

act=action; 1=on; 0=off

Getting partition status

mod=part

3
The json response for partition states is:
{"part": [
{"lb": "Keuken (60 sec) ", "am": "4", "st": "1", "mm": "0", "id": "0"},
{"lb": "Kelder/beg grond", "am": "4", "st": "1", "mm": "0", "id": "1"},
{"lb": "Studeerkamers ", "am": "4", "st": "1", "mm": "0", "id": "2"},
{"lb": "Ouder slaapkmr ", "am": "4", "st": "1", "mm": "0", "id": "3"},
{"lb": "24 uurs zone ", "am": "4", "st": "1", "mm": "0", "id": "4"}]}

am = arming code: 1=away, 2=stay, 3=instant, 4=disarm, 5=reset

mm = alarm has been tripped 1=yes; 0=no
st= alarm type 0=Tamper (not sure, not tested)
1=OK (no movement)
2=Movement detected (or no device connected)
3 or higher =Tamper (not sure, not tested)
id = partition id
0=partition 1, 1=partition 2, ………..4=partion 5

Changing the partition arming states

Normally changing the partition arming state is done by executing arming scenario’s. But if you
would like to set individual partitions, for instance to run tests, do so as follows:

mod par act Action

do_part 0 1 Changes the partition arming

par = relevant partition id (see above json output)

act= arming code: 1=away, 2=stay, 3=instant, 4=disarm, 5=reset

A reset is necessary to remove the alarm status from the partitions and zones when an alarm has
been triggered.

Getting individual zone states

mod=zone

mod par act Action

zone Gets zone states

4
The json response is:
{"zone": [
{"lb": "Keuken ","st": "1","mm": "0","by": "1","id": "0"},
{"lb": "Kelder voor ","st": "1","mm": "0","by": "1","id": "1"},
……
{"lb": "Waterpomp ","st": "1","mm": "0","by": "1","id": "14"}]}

id=zone number 0-15 The call takes about 20 secs

mm = alarm ringing 1=yes, 0=no
by = zone enabled 1=yes, 0=no
st= alarm type 0=tamper?; 1=none; 2=movement detected or no device;
3=tamper?

Enabling/disabling a zone

mod=do_zone

mod par act Action

do_zone 2 0=reset Disable or reset zone with their id
1=disable

Other useful http calls

mod par act Action Output field Output type

fau Get errors and battery voltage fau Error code
vcc System voltage
gsm Get GSM info vcc GSM voltage
fwv Nexus Firmware
version
gop Provider name
gpw Signal power
cre Credits remaining
log 10 Get alarm log with 10 lines,
other numbers tested up to the
max of 500

Issues executing http request calls for INIM states from NodeRed
I found it easiest to execute http request calls from NodeRed. This is because when responses
contain a large amount of data, in NodeRed it is easy to navigate to the data one is interested in,
much easier than doing this in Home Assistant. I recommend taking this route, unless you have the
problem described next.
NodeRed has become pickier in error checking the responses from the INIM system, at least in my
case, with 2014 firmware, which cannot be updated. Apparently, one of the response headers is in
the wrong order. NodeRed generates an error (Postman does not). None of the workaround I tried in
NodeRed worked.

Two workarounds
I created two command_line sensors in Home Assistant as follows, one form scenario states and for
alarm states:

5
I then poll these HA sensors in NodeRed to set the scenario and alarm states. Command_line sensors
can only contain less than 255 bytes. So if the response from the INIM server contains more data,
the command_line sensor cannot be used.

For these situations I created a second workaround by creating two “rest” sensors, using the “rest”
integration (note, this is different than “restful”!!) in a “rest.yaml” file as follows. Including
json_attributes ensures the data are stored in “zone” and “part” attributes, without quantity
limitation:

By polling these two sensors in NodeRed it is easy to navigate to the data you need.

6
Getting the alarm log (10, 20, 60 lines) and showing it in Home Assistant

This is the most difficult part. It required learning quite a few new nodes in NodeRed and some
javascript.

A description of the above example NodeRed flow follows below:

• The first 5 nodes are triggers for initiating a new alarm report;
• The node “Get # lines” checks an input_number slider in the front end for the number of
report lines for the report. My range is 10-60 in steps of 1. The output goes into “msg.lines”;
• We then call a HA shell command that downloads the alarm report from INIM and saves it as
a json file to disk in the /share/inim directory. The shell command in the
“shell_command.yaml” file is:

save_inim_alarm_report_to_disk_as_json: >
'curl -k "http://192.168.1.92:5050/cgi-bin/web.cgi
?mod=log&par={{states("input_number.inim_report_lines")}}&
user=xxx&pass=yyy&code=zzz" -o "/share/inim/output_from_inim_as_json.txt" '

• We then delete the previous version of the report in the (local) destination directory
• We read the json formatted report from disk and format it as proper json.
• The next node reverses the line sorting to get the most recent alarm line on top; the results
is put in “msg.payload”;
• The output goes into a “moustache” html template to create a simple html table;
• The next function node creates a filename, that is used to write the output to an html file on
the /share/inim directory (NodeRed is not allowed to write directly into the /config/www
directory);
• The next function node generates a random number between 1 and 10.000 which gets
added to the directory+filename string. The output from the /share/inim is then copied to
/local, using this filename with random number. A lovelace (iframe)webpage can only be
read from a /local directory (which is equal to “/config/www/”).
We need to add a random number because the frontend needs to see a file with a new
name each time the file changes. Otherwise it just shows what is in the browser cache. I
have not found a way to easily flush the browser cache from HA.
• The filename string with random number gets stored in a HA entity for use in the frontend.
• You can find the NodeRed code for this flow in pastebin.com

7
 And don’t forget to add to the “configuration.yaml” file the authorization (for NodeRed) to write
to the /share directory:

homeassistant:
allowlist_external_dirs:
- /config
- /share

Frontend programming
The frontend uses the “browser_mod” add-on package to create a popup for the alarm report when
the button gets pressed. It also uses the “config-template-card” that adds templating functionality to
Lovelace cards. This is necessary to be able to call the html page with the random number in the file
name, to ensure we get a new page whenever the alarm report changes.

The Lovelace set up looks like this:

type: vertical-stack
title: Alarm report
cards:
- type: entities
entities:
- type: custom:slider-entity-row
entity: input_number.inim_report_lines
name: Aantal regels
hide_state: false
icon: none
- entity: sensor.alarm_report_filename_random
name: Filename
icon: none
show_header_toggle: false
- show_name: true
show_icon: true
type: button
entity: input_number.inim_report_lines
icon: mdi:receipt
icon_height: 50px
name: Get latest
tap_action:
action: fire-dom-event
browser_mod:
service: browser_mod.popup
data:
title: Latest alarm report
size: wide
autoclose: false
content:
type: custom:config-template-card

8
 variables:
FILE_NAME: states['sensor.alarm_report_filename_random'].state
entities:
- sensor.alarm_report_filename_random
card:
type: iframe
url: ${'/local/alarm/html/'+ FILE_NAME}
target:
device_id:
- yyyyyyyyyyyyy # get these from the browser_mod integration
- xxxxxxxxxxxxx
show_state: false
show_name: true

The alarm report output for the screen looks as follows:

9
API parameters summary

mod par act Description Comments

sce now Get current scenario
setting
do_sce scenario# Execute arming scenario#
cmd Get output/command
states
do_cmd output# action# Set output on or off action#:
1or 0 1=on
0=off
part Get partition states
do_part partition# Armingcode# Set partition arming code Armingcode#
1-5 1=away
2=stay
3=instant
4=disarm
5=reset
zone Get zone states About 80 zones!
do_zone zone# 0 or 1 Enable or disable a zone Act:
0=reset (enabled)
1=disabled
log 10 Get alarm log with 10 lines 10-500 allowed
fau Get error# and system
voltage
gsm Get gsm info from Nexus

10