Description
Python package to control G90-based alarm systems.
Many manufacturers sell such systems under different brands - Golden Security, PST, Kerui and others. Those are cheap low-end systems, typically equipped with WiFi and possible GSM interfaces for connectivity, and support different range of peripherals:
Wired and wireless sensors
Relays (switches)
… and probably others
The package implements asynchronous I/O over most of code paths using asyncio.
Disclaimer
The author has no affiliation or any relationship to any of the hardware vendors in question. The code has been created upon many trial and error iterations.
Motivation
The primary motivation creating the code is the comfort of using the security system - the mobile applications provided by the vendor, called “Carener”, is slow and crashes sometimes. Instead, it would be awesome to have the system integrated into larger ecosystems, like Home Assistant, HomeKit and such. Hence, the code has been created to interact with the security system using Python, and it opens up a way for further integrations.
Supported hardware
It might not be possible to list every system supported by the package due to manufacturers naming the products differently. Here is the list of hardware known to work with the package:
And the list of sensors, actual set of device should be notable larger as many of other manufacturers produce similar items. The names in parenthesis are taken from the alarm system documentation, for example, Home Alarm GB90-Plus.
Wired PIR sensors
Wireless PIR sensors (WPD01, WMS08)
Door/window sensors (WDS07, WRDS01)
Water leak sensors (LSTC01)
Smoke sensors (WSD02)
Gas sensors (WGD01)
Switches/relays (JDQ)
Basically, the alarm system uses 433 MHz communications for the wireless devices using EV1527, PT2262 protocols. The mobile application also mentions some devices using 2.4GHz, although details of the protocols haven’t been identified as no such hardware has been available for experimentation.
Known caveats
Wireless shutter sensor (WRDS01) doesn’t send anything on sensor closed, only when opened. In contrast, WDS07 wireless door sensor does both.
Wireless relays (at least JDQ) use same RF code for switching on and off, when configured in toggle mode. That means a RF signal repeater will make controlling such relays unpredictable, since the code will be sent more than once.
Low battery notifications for wireless sensors (at least for WDS07 and WSD02) are often missing, either due to the sensors not sending them or the device doesn’t receive those.
Wired sensors toggle on line state change, i.e. those aren’t limited to have normal closed (NC) or normal open (NO) contacts only. Best used with NC contact sensors though, since an intruder cutting the line will trigger the alarm.
Due to an apparent bug in certain panel firmware versions, loading CID or SIA configuration periodically (seems in range of 10-20 iterations) leads to paginated commands timing out afterwards. Hence, such configurations are loaded only once and then reused during G90Alarm lifetime, or when cache is bypassed (by passing force=True to corresponding G90Alarm methods). For unification, other configuration objects are cached for 10 minutes as well, to reduce load on the panel.
Device notifications
Local notifications
There is a hidden device capability to send protocol notifications over the WiFi interface, thus called local. The notifications are done using broadcast UDP packets with source/destination ports being 45000:12901 (non-configurable), and sent when the device has IP address of its WiFi interface set to 10.10.10.250. That is the same IP the device will allocate to the WiFi interface when AP (access point is enabled). Please note enabling the AP is not required for the notifications to be sent, only the IP address matters. Likely the firmware does a check internally and enables those when corresponding IP address is found on the WiFi interface.
Depending on your network setup, ensuring the 10.10.10.250 IP address is allocated to the WiFi interface of the device might be as simple as DHCP reservation. Please check the documentation of your networking gear on how to set the IP address allocation up.
For the local notifications to be enabled the G90Alarm.use_local_notifications() needs to be called upon constructing an instance of G90Alarm class, then G90Alarm.listen_notifications() to start processing those coming from the panel - the code fragment below demonstrates that though being incomplete since callbacks (e.g. G90Alarm.on_armdisarm()) should be set for the actual processing of the notifications.
from pyg90alarm import G90Alarm
# Create an instance of the alarm panel
alarm = G90Alarm(host='10.10.10.250')
# Enable local notifications
await alarm.use_local_notifications()
# Start listening for notifications
await alarm.listen_notifications()Cloud notifications
The cloud protocol is native to the panel and is used to interact with mobile application. The package can mimic the cloud server and interpret the messages the panel sends to the cloud, allowing to receive the notifications and alerts. While the protocol also allows to send commands to the panel, it is not implemented and local protocol is used for that - i.e. when cloud notifications are in use the local protocol still utilized for sending commands to the panel.
The cloud protocol is TCP based and typically interacts with cloud service at known IP address and port, which could be customized. To process the cloud notifications all the traffic from panel towards the configured IP address service needs to be received by the node where the package is running.
Please see the section for further details on the protocol.
The benefit of the cloud notifications is that the panel no longer required to have 10.10.10.250 IP address.
The package could act as:
Standalone cloud server with no Internet connectivity or cloud service required at all - good if you’d like to avoid having a vendor service involved. Please note the mobile application will show panel as offline in this mode
Chained cloud server, where in addition to interpreting the notifications it will also forward all packets received from the panel to the cloud server, and pass its responses back to the panel. This allows to have notifications processed by the package and the mobile application working as well.
The code fragments below demonstrate how to utilize both modes - please note those are incomplete, since no callbacks are set to process the notifications.
Standalone mode
from pyg90alarm import G90Alarm
# Create an instance of the alarm panel
alarm = G90Alarm(host='<panel IP address>')
# Configure cloud server address the panel should use - the host running the
# package.
await alarm.set_cloud_server_address(
cloud_ip='<host IP address running the package>', cloud_port=5678
)
# Enable cloud notifications
await alarm.use_cloud_notifications(
# The host/port the package will listen on for the cloud notifications,
# should match ones above.
cloud_ip='<host IP address running the package>',
cloud_port=5678,
cloud_local_port=5678,
upstream_host=None
)
# Start listening for notifications
await alarm.listen_notifications()Chained mode
from pyg90alarm import G90Alarm
# Create an instance of the alarm panel
alarm = G90Alarm(host='<panel IP address>')
# Configure cloud server address the panel should use - the host running the
# package.
await alarm.set_cloud_server_address(
cloud_ip='<host IP address running the package>', cloud_port=5678
)
# Enable cloud notifications
await alarm.use_cloud_notifications(
# The host/port the package will listen on for the cloud notifications,
# should match ones above.
cloud_ip='<host IP address running the package>',
cloud_port=5678,
cloud_local_port=5678,
# Upstream cloud server address the package should forward the
# notifications to.
upstream_host='47.88.7.61',
upstream_port=5678
)
# Start listening for notifications
await alarm.listen_notifications()Quick start
pip install pyg90alarmDocumentation
Please see online documentation for details on the protocol, its security, supported commands and the API package provides.
1 maintainer
Metadata
1 maintainer
Release files for pyg90alarm 3.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| pyg90alarm-3.1.0.tar.gz | 134.1 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| pyg90alarm-3.1.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 258.5 kB
Release files / pyg90alarm-3.1.0.tar.gz
| Download URL | pyg90alarm-3.1.0.tar.gz |
|---|---|
| Size | 134.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
1a1f53b758c72d14586261d062bfae3def1f280eecea6d25648fecc60132dbb0
|
|
BLAKE2b-256 checksum How to use checksums |
ec006ba2e462e51e14f9745df88cd029ab348c824a297e3858fdb19a4712d697
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 13, 2026.
Transparency logRelease files / pyg90alarm-3.1.0-py3-none-any.whl
| Download URL | pyg90alarm-3.1.0-py3-none-any.whl |
|---|---|
| Size | 124.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
1bb9e7f324a53152caafd494a86e53f8674698822c57c94093d05cb1acfa71af
|
|
BLAKE2b-256 checksum How to use checksums |
4b271208d6f46bcb5f21206e96f9105848b0b366df8b14ecafe419ed6296f45c
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 13, 2026.
Transparency log
