Using local time for processing always lead to issues it seems…
Perhaps there is a way to work internally only with UTC timestamp or Unix timestamp ?
To convert exactly from local time to UTC time, you can use pytz with is_dst=None (pytz - World Timezone Definitions for Python — pytz 2014.10 documentation) but for that you need the exact local time with the timezone specified: 2022-04-05 21:47:00+01:00 (and not only 2022-04-05 21:47:00).
Hi Everyone,
I’ve just released version 0.7.0.2 to github.
This minor release takes account of time changes when the clocks change twice per year (in some countries across the world). There are now 2 times used within the integration, UTC time is used for interval timing and local time is used for time-stamping zone and siren times. This ensures that interval timing cannot be corrupted by the local time suddenly changing (twice per year).
There are also 2 further minor changes.
- The service calls have been updated but there’s no API or functional change.
- The manifest, hacs and readme files have been updated.
The minimum Home Assistant version is now 2022.3.3
After googling I think I’ve got it sorted although we’ll see whether it works for everyone the next time the clocks change. For local time I continue to use the same python call datatime.now(), for UTC time I call datetime.utcnow(). I have split the use in the pyvisonic.py panel interface file.
1 Like
Thanks Dave, to be able to test in real condition, I suppose I’ll have to wait until next year and try to pay attention during this special day 
Another issue I have found; but perhaps this is due to my configuration.
Yesterday, I forgot to enter the disarm code when coming back and the alarm was triggered:
To my surprise I didn’t receive a notification.
I have set up Home Assistant to send an email when the Panel Alarm Status is different from None:
- alias: Alarm Triggered
initial_state: true
trigger:
- platform: state
entity_id: sensor.visonic_panel_alarm_status
condition:
condition: template
value_template: '{{ trigger.to_state.state != ''None'' }}'
action:
- service: notify.email_notify
With the sensor defined as this:
sensor:
- platform: template
scan_interval: 5
sensors:
visonic_panel_alarm_status:
value_template: "{{ state_attr('alarm_control_panel.visonic_alarm', 'Panel Alarm Status') | title }}"
friendly_name: 'Panel Alarm Status'
I didn’t set the trigger directly on the siren, because I also wanted to be notified in case of Flooding (and the siren is not triggered in case of Flood).
Looking at the logs, it seems that Home Assistant got somehow confused because it receives several Panel Alarm Status at the same time ?
How could I reliably trigger an automation/notification in case of any change in Panel Alarm Status then ?
Thanks a lot in advance,
On one hand you are correct, on the other hand you should be doing it a different way.
You are correct, the attribute that you use Panel Alarm Status represents the last panel status and in your case the panel sends multiple states in a single message, as such the intruder status gets lost and I’ll take a look to see if I can make it more robust.
However, to get the alarm state you should be doing it a different way. The entity alarm_control_panel.visonic_alarm state changes between the following states:
- disarmed
- pending
- triggered
- arming
- armed_home
- armed_away
There are 3 built in states that I do not use: armed_night, armed_custom_bypass and disarming. I use the built in HA entity Alarm Control Panel as a base entity.
You can use these in an automation like this, using the triggered state when the siren is sounding.
- alias: 'Alarm Siren Triggered Action'
initial_state: true
trigger:
- platform: state
entity_id: alarm_control_panel.visonic_alarm
to: triggered
Another way to do this…
I also generate an event in HA when the siren is sounding, this can be used as per the example on the wiki here. See the example 'Alarm Siren Triggered Action'.
If you use the event it contains a lot of data about what caused the alarm that you can use in a notification or an email for example. All the events that I generate are described on the wiki here
Then create multiple automations, look for the flood sensor itself being triggered.
EDIT: or if you want the same action then have multiple triggers in the same automation, 1 trigger from the alarm_control_panel.visonic_alarm being triggered and the other from the sensor itself e.g. binary_sensor.visonic_z02 being set to on
I’ve been running the Visonic Integration successfully on HA using a RPi and SSD for a few years.
Lately I’ve had increased instances of unexplained outages where HA cannot be reached / has crashed.
A bit of forum investigation leads me to suspect memory creep so I’ve been logging the Rpi memory use. It would appear that every time the Visonic alarm is set the memory use jumps by a few % and stays at that level. When the alarm is disarmed the memory use jumps again, but not by as much.
This is the trace showing the alarm set last evening then again around 10am this morning, returning shortly before 4pm (the dip is because I have the system reboot at 1am every morning whilst I try to track down the problem). As you see there are jumps corresponding to setting & unsetting.
I’d be interested if anyone can explain why this happens as it contributes to my high memory usage.
TIA
When panel events occur then I create a data package and an Event on the HA Event Bus. I then drop the data that I create so only HA should have a reference to it. I assume that HA provides the garbage collection for unused data. I must admit that I haven’t updated HA to the latest version as I always wait a few weeks for those initial bug fixes to get ironed out.
Speaking of which, it may be a general problem with the latest HA version as defined in these recent links:
I’m not going to do anything at the moment, let’s see what happens with the HA Core first.
Another way to do this…
I also generate an event in HA when the siren is sounding, this can be used as per the example on the wiki here. See the example 'Alarm Siren Triggered Action'.
If you use the event it contains a lot of data about what caused the alarm that you can use in a notification or an email for example. All the events that I generate are described on the wiki here
Thanks ! But if I understand correctly, the above will only work if the detected flood is triggering the siren. My panel is configured as not sounding the siren in case of flood (perhaps I’ll change this setup in the future, but for the moment I’d prefer to receive only a notification in case of flood).
As I have several flood detectors, I wanted to use a general ‘flood’ trigger instead of referencing each sensor (or creating a new sensor based on the others).
Based on your proposal, I am currently testing with:
- alias: Alarm Triggered
initial_state: true
trigger:
- platform: state
entity_id: sensor.visonic_panel_alarm_status
- platform: state
entity_id: sensor.visonic_panel_trouble_status
- platform: event
event_type: visonic_alarm_panel_state_update
event_data:
condition: 3
condition:
condition: or
conditions:
- condition: template
value_template: '{{ trigger.platform == ''state'' and trigger.to_state.state != ''None'' }}'
- condition: template
value_template: '{{ trigger.platform == ''event'' }}'
Not sure if this is a really dumb idea to still use the sensor.visonic_panel_alarm_status to find out about flooding instead of the sensors, but it seems to work.
Do you think I should directly reference all flood sensors ? There is no more ‘elegant’ way ?
Thanks a lot
Hi,
I was hoping someone could give some tips on visonic logs/errors. I’ve configured the logger in configuration.yaml and can see the normal HA logs.
I’ve been through the whole Wiki and configured a Wemos D1 (actually two of them as I was unsure if I had an issue with one after hours of trying to get comms working. I have ESPhome installed and can see the output from it, it shows HA connecting to it and me switching the LEDs etc in debug output.
I’ve connected tx to rx and rx to tx in the powermaster panel (and GND), but for the life of me cannot ever get it to detect being connected to the panel and sync. I’ve tried the troubleshooting and connected tx to rx on the board directly to try to get some kind of loopback in the error logs too.
I keep seeing “Visonic Plugin has suspended all operations, there is a problem with the communication with the panel (i.e. no data has been received from the panel)” but I ‘think’ there is some detection going on in the logs, does this make sense to anyone please?:
I have tried various combinations of options, but currently the integrations is set up all as default ( port 10077 and the only thing checked is auto enroll).
Thanks to anyone with any suggestions on where im going wrong!
I used to have this panel connected to a Vera with the rs232 add in and serial to usb converter (the rs232 addon is currently not connected), but not managed to get HA recognising it yet.
And did the loopback work? Please connect Rx to Tx on the Wemos, can you show me a log file of the loopback please. The integration includes a loopback test, if it detects a loopback is outputs log messages for a counter as a test.
Next things to check:
- Baud rate, have you set the baud rate correctly for your panel in the esphome config?
- Voltage levels, what visonic panel do you have?
These 2 things are the only things that could be a problem when the loopback test works (apart from getting the wiring wrong). How are you powering the Wemos? Can you take a photograph of the wiring and upload it?
Hi Dave,
Thanks for any guidance.
Here are the images of the connections:
As a new user I can only post one embedded image, so on the IP port at the top (its hard to see in one image) there is an empty pin, my 3 connections and then one more empty pin.
I have a Powermaster 30
baud set to 9600 (This is what I had it set with the RS232 to USB and vera integration)
I have the Wemos connected by the round DC port, spliced into the 12v power supply on the panel.
I’ve just:
Removed the visonic intruder alarm integration
restarted HA
Powered off the Wemos, reconnected the tx and rx together and then powered back on
Installed the Visonic integration.
Log output from that is:
Regards,
Darryl.
Hi,
Lots to go at here…
First of all, the fact that you have a PM30 may indicate that you need to change the Baud rate, depending on the firmware version in the panel. Is there anywhere on a panel label that tells you the firmware version?
EDIT: Could you try it with the baud set to 38400, it will mean reflashing the wemos
Secondly, for the loopback test you have the port set wrong
In your original post the port is 10077 and in the recent log it’s 1077 and it fails to connect. Can you please redo it and upload another loopback test. I assume it’s a typo as you redid the integration in HA.
Thirdly, as you are powering the Wemos from the panels 12v supply then you do not need to connect the Gnd wire from the Wemos to the panel,looks like your grey wire.
And lastly, I can’t quite see from the photograph but the orange wire should be on the centre pin of the 5, is it
I assume so from your description and so if you remove the grey wire then the orange and yellow should be correct.
Hi Dave,
Oops, typo on the port that time. I had GND connected, only because nothing was working and someone else trying to get one of these boards working found that adding GND fixed it… Thats now removed again.
The connections much clearer are now here:
No clear way to find the FW without removing that panel off the wall in the hope it might be there.
I’ve reflashed to 38400 to try that baud rate.
Connected TX and RX and loopback successful - see:
Along with these highlighted warnings:
[handle_msgtype0F] LOOPBACK TEST SUCCESS, Counter is 1
19:48:41 – (WARNING) Visonic Intruder Alarm (custom integration) - message first occurred at 19:48:30 and shows up 3 times
[data receiver] Received Unknown PDU 0x24
19:48:33 – (WARNING) Visonic Intruder Alarm (custom integration)
[data receiver] Warning : Construction of incoming packet unknown - Message Type 0X24
19:48:33 – (WARNING) Visonic Intruder Alarm (custom integration)
Integration removed and then HA restarted.
TX connected back to RX and vice versa
Integration readded with all defaults except auto-enroll and download code 5650 selected.
Then this type of result again:
Hope that helps!
Darryl.
It does help me but it means that I won’t be able to help you much more. The 0X24 related warnings are nothing to worry about and happen as part of the loopback test. In the loopback test the counter is incrementing correctly so it looks OK. That means that the integration is connecting to the Wemos correctly and the Wemos is setup correctly (apart from maybe the baud rate).
When the loopback test works there’s a problem somewhere between the Wemos and the panel itself. It’s likely to be one of the following, working our way from the Wemos to the alarm panel:
- Baudrate. The loopback test will work with any baudrate setting, try it back at 9600. As long as the Tx and Rx on the Wemos are the same (which they always are), then the loopback will work
- A broken cable. Try the loopback test with the orange and then the yellow cables to make sure they both work
- The cables aren’t making a good contact with the pins (on the panel)
- Voltage levels. On a PM30 the voltage levels are 3.3volts (I believe). The Wemos is probably 5volts (I believe) and so you may need a voltage level shifter. Some people seem to have issues with voltage levels but many don’t so it is unlikely to be this, but it could be
- As you’re using 12v power from within the panel you shouldn’t need to connect the Gnd cable, but try it just in case
- Lastly, it could be that the panels interface is busted
Do you have the ability to connect it back up to a Vera and try it?
Can you try iy with the gadget that you used with Vera instead of the Wemos?
I know this is a long shot but do you have an oscilloscope or logic analyser to analyse the Tx and Rx signals on the panel?
Keep me updated
Hi Dave,
OK, so I reflashed to 9600 baud
changed the TX/RX cables for new, and ensured good connections
Connected GND
Result:
Visonic - new tx rx cables, GND connected and baud 9600 - Pastebin.com
I cant easily reconnect to Vera, I deleted all the integration from there (I have a CO sensor that due to the age of the visonic plugin, caused comm exceptions and occasional luup reloads as the plugin didn’t recognise it)
No Oscilloscope, but for times like this I wish I had.
Any more suggestions?
I’ve ordered one of these meanwhile → https://www.amazon.co.uk/AZDelivery-Bi-directional-Converter-Raspberry-including/dp/B07V1FY9W5
Update: Ive ordered an second ebay visonic panel, to rule out some board issue.
Regards,
Darryl.
So a small update. I got another panel and connected it up. First try it connected straight away, allowed arm/disarm etc and even asked me about B0 parameter enabling, and I thought the issue was solved. I opened the panel up to power off and connect the phone line, but once powered back up again, no combination of trying powering or removing/adding the panel integration will get any comms from the panel again. I tried a 5->3v signal step down and just got weirdness (I think it was the component. The logs showed detected a powermax (its powermaster) and things like this:
2022-04-28 21:28:59 WARNING (MainThread) [custom_components.visonic.pyvisonic] [data receiver] Warning : Construction of incoming packet unknown - Message Type 0X46
2022-04-28 21:28:59 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [data receiver] Dumping Current PDU 0d 46 3c 2e 51 72 49 8c b2 ef ef d6 9b ac 16 c7 29 2a 63 96 dc df fd f2 39 9b c4 19 72 be b1 e6 e9 c8 2e fc b9 de 0e e1 38 cd d8 be f9 de 91 87 e1 70 14 ec f6 9d ff cf 7e e2 58 36 53 9f 65 91 66 6b 97 2f bf 81 dc d5 bf 6c 9f e7 f9 d0 a9 fa ae bc 83 62 ca 5c 1a a9 0e c3 2e 26 e1 b2 95 ed d3 aa fd 1d b6 e7 85 42 f7 9f a9 5f 7d 76 f2 16 c9 5d 35 7a fe f1 e1 97 b9 b1 9e ca e1 00 2e cc 7f c4 be e7 df 25 de 7f a7 69 79 19 cf 24 b1 8b 51 bf 3b e7 f5 d2 8c 0d e3 8f 5d f7 37 3d dc 3e d6 26 76 57 da bb 80 9c 4b e3 c7 57 4d e6 3e fb c6 eb e7 f9 a0 d9 18 23 33 24 fd 92 b9 4a c3 13 e9
So after trying multiples of everything, i’ve seen reports from someone in the thread that an ESP8266 nodemcu has worked for them. I’ve ordered one of those and hopefully will make more progress (although never programmed one of those before).
Darryl.
Quick question, did you try disconnecting the phone line?
The info is on my wiki here although it wasn’t me that did this.
EDIT: Although the wiki may be out of date for version numbers of software
Hi to all. I tried to connect to my powermaster 10 but I always have connection error. I do not know witch port I have to use. Maybe 30000 is wrong. I do not have admin pwd because I do not install it. But the installer told me that I didn’t change default port.
Can I have another port to try?
Hi djeghe, the wiki says the port is 10077
Hi Dave,
Yes, I disconnected the line.
I have the nodemcu installed but getting no data in the console (followed the wiki info to get this working, the only not 100% clear part was whether I need to add the visonic intruder integration or just copy/paste the visonic device info into configuration.yaml, i’m thinking the latter and using port 23 as displayed on the device?
. Starting to think the voltage in the wemos might be damaging the interface in the visonic panels, so i have a completely different panel on the way i’m going to try connecting only the nodemcu to, thus ruling that out too
Darryl
I wish I could help you, but my experience is with a USB serial adapter communicating with the panel. My experience ends at the text in the product manuals for the WiFi devices. I expect Dave or someone else will eventually show up and offer some suggestions.
The best thing I can tell you is to be mindful of what logic voltage levels appear at your panel versus your interface (whether it’s a WiFi-to-serial converter or a USB adapter). If they are different, the proper solution is to use a logic level translator. I have described this on the original forum page for Dave’s integration in several posts starting at this one:
https://community.home-assistant.io/t/visonic-powermax-and-powermaster-component/55949/351
There are several other posts regarding getting the WiFi-to-serial devices to work properly. The additional detail may be useful. Just scroll through the posts and you’ll see them.
Good luck.