OK so I’ve added this to 0.13.0.39, there will be _keypad added to the entity name(s)
I have left 0.13.0.38 on HACS so users can go back to this release if required, or you can restore from a backup.
I doubled up the main alarm panel entity and doubled up the partitions, so if you use 3 partitions you’ll get 8 alarm panel entities
I’ve just created a Pre-Release 0.13.0.41. Can you create any questions, problems etc about this in discussion 2 Alarm Panel Entities: one that always shows a keypad, and another that follows the existing rules · davesmeghead/visonic · Discussion #276
The main reason that I’m doing this is to address the lack of user based security in Home Assistant. So you can now use 1 of the entities (keypad) in your displays next to your front door. The other (normal, without keypad) you can use on the dashboard on your mobile phone.
Breaking Change - The way the Alarm Panel Entity uses Keypads and usercodes.
This is currently only used and available when you ask for Powelink Emulation Mode with a Direct connection. It will be extended to Cloud use in upcoming releases.
This simplifies the combinations for when a keypad is shown to arm and disarm a panel/partition, this simplifies and replaces the wiki note 7 here:
The Force Keypad setting has been removed. You can now optionally create 2 Alarm Control Panel Entities per panel and per partition. There is a configuration setting (go through Reconfigure) “Create Extra Alarm Panel Entities with Keypads” that defaults to the old Force Keypad setting. So potentially, if you use 3 partitions in a PowerMaster Panel you will get 8 Alarm Control Panel Entities.
There are 2 user “arm without usercode” user settings, 1 for the Normal Entity and 1 for the Keypad Entity.
- “Arm Normal Alarm without User Code (not supported by all panels)”
- “Arm Keypad Alarm without User Code (not supported by all panels)”
In any Alarm Control Panel Entity, if you set the usercode in the entity settings then that gets used to Arm and Disarm the panel. You can of course set these differently e.g. with user code 1 and user code 2 from your panel so you can tell the difference.
The 1st (Normal) Entity uses the Achieved Emulation Mode (Powerlink/StdPlus or not). If Powerlink/StdPlus then no keypad else show a keypad. In other words, achieving Standard Mode means that both generated entities do the same (you can set the usercode in the Entity settings)
The 2nd (Keypad) Entity always shows the keypad (unless the usercode is set in the Entity).
Hey all, hoping someone’s seen this recently.
I’ve got a PowerMax Complete. This has been rock solid for months but in the last few days my HA Core has started fully crashing and restarting itself multiple times a day (via the Supervisor watchdog). No config changes that I’m aware of. Though I’ve exposed the Alarm to HomeKit via a Bridge.
What I’m seeing: every crash is preceded by a burst of these in the log, right when the alarm goes into “Arming” (or flaps quickly between states):
ERROR (MainThread) [pyhap.characteristic] SecuritySystemTargetState: value=1 is an invalid value.
ERROR (MainThread) [homeassistant.helpers.event] Error while dispatching event for alarm_control_panel.visonic_alarm to <Job track state_changed event ['alarm_control_panel.visonic_alarm'] HassJobType.Callback <bound method HomeAccessory.async_update_event_state_callback ...>>
and later:
ERROR (MainThread) [pyhap.characteristic] SecuritySystemCurrentState: value=1 is an invalid value.
Checked my alarm’s history against the timestamps and it lines up exactly with “Arming” / “Pending” states, plus one instance where it went Disarmed → Armed away twice within about 12 seconds. So it looks like HomeKit’s SecuritySystem characteristic is choking on states it doesn’t know how to map (transitional states aren’t part of HomeKit’s model), and each failed dispatch seems to leak something — because eventually it snowballs into:
OSError: [Errno 24] No file descriptors available
ERROR (MainThread) [homeassistant] Fatal error '[Errno 24] No file descriptors available' raised in event loop, shutting it down
…which kills Core outright and Supervisor restarts it.
Been running Visonic + HomeKit Bridge together for months with zero issues, so something must have changed recently. Anyone else seen this in the last week or two?
Assuming it’s more HASS/Homekit related but worth the question I thought?
Thanks
HI, I have an old powermax+ with a J7 (14 pin) on the back and getting a bit confused and was hoping for some guidance. I was under the impression I could connect my alarm panel to an esp32 (wifi) and then add my esp32 to my HA espHome integration, setup the yaml, install Dave’s integration to HA, add my esp32 to the integration, enrol the esp32 within the visonic and then control my visonic alarm.
So if this is correct then I need some help on the pins, I thought I could connect,
J7 pin 4 (5v) to the esp vin pin
J7 pin 9 (gnd) to esp gnd pin
J7 pin 5 (RX) to esp 17 (TX2) pin
J7 pin 6 (TX) to esp 16 (RX2) pin
I did some multimeter checks and J7 pins 4/9 provide 5v so this should be ok as my esp will step this down to 3.3v but J7 pin 6 (TX) & J7 pin 9 (gnd) is registering at 12-13v ! … I could step this down but I think I may have the wrong pins
Does anyone know if,
A) I can just use a simple esp32 to bridge between my powermax+ and my HA (no more hardware needed) and …
B) what are the correct the pin specs for the powermax+ J7
Hi,
A) Yes you can use an ESP32 and a few wires. I suggest you use serial_proxy, look at the visonic_esphome_serial_proxy.yaml file as an example for what you’ll need for ESPHome.
B) Have you read through the hardware guide on the github wiki? Hardware Setup · davesmeghead/visonic Wiki. I will just reiterate what I say on the wiki “But I don’t have a Powermax+ panel so I would not know if this works or breaks the panel so use with caution.”