If you discover that one of the passwords you tried actually work on Inim Prime Studio, but not in the library, it is very likely that the Onboard LAN handles encryption differently from the PrimeLAN.
Regarding your questions:
If I specify a wrong password in the config.yaml, panel does not respond and closes the connection.
It is possible that password derivation might differ between OnboardLAN and PrimeLAN. If that is the case, I would try to unplug my PrimeLAN to see if I can make the library work with the OnboardLAN as well.
There is no handshake that needs to be established in order to communicate with the panel, apart from the TCP socket opening. The panel communicates through independent frames that are validated at an higher level. I am able to actually perform communication with the panel. For example, I am able to run get_partition_names using repl.py and get the actual names of my panel's partitions.
I contacted my installer and got the correct connection password. I confirmed it works via Prime/STUDIO. Despite using the correct password, I ran get_partition_names from repl.py directly and got the same result: frame sent successfully, panel accepts the TCP connection but returns no response (silent timeout after 20s). This rules out any issue with my test setup.
It seems confirmed that Onboard LAN handles encryption differently from PrimeLAN. Would you be willing to investigate this? I could provide a Wireshark capture of a Prime/STUDIO session if that would help identify the difference.
Hi everyone. Thank you for digging all this information. I am using the Minim integration, with a few tweaks of my own, for extra info. I have an old 1050 panel, so not a lot of things work. I have started getting errors lately, at a specific time, 4.53pm local time, quotas exceeded. They persist until 3am, and then the integration returns to normal. During this, I cannot connect even to the official app. Increasing the polling interval doesn't change anything. Does anyone have a similar experience?
Hi! I've been experiencing something similar recently. It seems like Inim has tightened their API rate limits lately, as this kind of quota issue wasn't as common before.
Once you hit the limit, it blocks all connections for several hours including the official app, which confirms it's server-side.
I managed to improve the situation by increasing the polling interval. In minim/const.py there is a DEFAULT_SCAN_INTERVAL variable — I set it to 120 (seconds) and it reduced the frequency of the issue significantly.
I am wondering why this doesn't work for me. I've set it to 15 minutes, and I still get the errors. I'll check my modified minim version in case I (claude) has introduced a bug
First of all, a massive thank you for your incredible work on this native library! Thanks to your foundation, I have successfully achieved a 100% local, bidirectional, and lightning-fast integration with my Inim Prime panel.
I wanted to share my setup and some technical solutions I implemented, which might be helpful to you and others in the community:
My Setup:
Central: Inim Prime 60 (PR060) on firmware 3.11.
Connection: Local TCP port 6004 (with use_outer_frame=False and the default connection password "pass").
Integration: Custom local Home Assistant Add-on (Docker/Alpine 3.18) running a persistent Python daemon.
How I implemented it (Inim to MQTT Bridge):
MQTT Discovery: The Python daemon publishes the Home Assistant MQTT Auto-Discovery payload. Home Assistant automatically creates a native alarm_control_panel entity. I limited supported_features to ["arm_home", "arm_away"] to keep the UI clean, showing only Disarm, Arm Home (Perimeter), and Arm Away (Total).
Solving Asyncio/Thread Conflicts: Initially, when triggering commands from HA, I got the "Event loop is already running" error. Since Paho MQTT runs callbacks in a background network thread, calling loop.run_until_complete() inside the callback clashed with the main async polling loop. I resolved this by setting up an asyncio.Queue. The MQTT on_message callback safely puts incoming commands into the queue using loop.call_soon_threadsafe, and the main loop processes them sequentially before resuming the polling. This completely resolved the crash and warnings!
PIN Fallback & UX: I configured code_arm_required: false in the discovery payload. When arming from HA, the UI doesn't ask for a code, and the Python script automatically falls back to a secure pin_utente stored inside the Add-on options. When disarming, HA automatically prompts the user for the PIN on the screen.
Stabile 5s Polling: Keeping the socket open (async with Protocol) and polling get_partition_statuses every 5 seconds is extremely lightweight. It uses virtually 0% CPU on the PrimeLAN card, keypad response is instant, and there are absolutely no disconnections from the official Inim Cloud app.
Everything is incredibly responsive and has been running rock-solid. Thank you again for making this possible!
I am so happy that you were able to use my protocol implementation!
It is indeed in a very early stage, but I plan to implement more commands, and eventually create a complete home assistant integration. If you find any bug or if you have any suggestion, reach me on DM or via GitHub issues!