I ran 0.1.5 in my docker container without any other configuration, and standard mode is working now.
Maybe some pollution in my rpi hassio config files (or custom components files) were causing the issue. I’ll start migrating from hassio step by step, but your component is working fine :).
So i finally got my USR-TCP232-E2.
Configured everyting, hooked it up, and bingo.
I believe I was in powerlink mode since I could see the zone names etc.
I could not arm without code so i added “arm_without_usercode: ‘yes’” to my config.
Rebooted HA and now I did not get in powerlink mode again. Now I just get in standard mode:
********************** Download Timer has Expired, Download has taken too long *********************
Any suggestion?
I have tried the “Full Restart Sequence for Powerlink” serveral times.
Should I wait and try again tomorrow? If I get powerlink working again, will I not be able to reboot HA in the future to keep powerlink?
Many thanks for the great component, I hope we can solve my powerlink issue.
Edit: I have the debug log available.
Before I upload, is there some sensitive information in it that I should leave out?
Edit2: Some additional info.
I have:
Powermaster 30, panel version 16
Home assistant version 0.91.3, running in a docker container on a Synology NAS
Component version 0.1.5
Good evening Dave,
I have the component working perfectly, but I have increased my HA instance, adding other movement and door sensors of the XIAOMI brand.
Do you know any way that those sensors can be added to the established alarm system?
Maybe adding the entities in some configuration file?
I believe the Xiaomi sensors are ZigBee devices. As far as I know, Powermaster 30 use PowerG sensors, and as such, they operate at a different frequency and use a different communication protocol. Are you expecting to pair the sensors with the alarm system, or are you expecting somehow to make the alarm system aware of the sensor state?
I’m pleased you got it working so quickly, well done
That may not be true as you get zone names in Standard mode too.
That is the big question. In my experience it’s tricky to keep it in powerlink. I believe the issue to be related to the timing of the messages. Most of the time when I run the test program from the command line it goes in to powerlink. When run from HA it strongly depends on what you have in your config setup, HA tries to do things in parallel (using asyncio, so not truly parallel) which messes with the timing of things.
Some notes:
It does repeat the ip address and port number in the log file
When it is in powerlink mode I do not include any sensitive data like user codes etc. However, if you include all the 0x33 messages that come as part of the EPROM download, then in theory and given a lot of knowledge you could work out where the user codes are in the download.
When in standard mode, if you try to arm/disarm the system then you could find the usercode that you have entered (either manually or in the components configuration) in the log file
If you want to be certain, then change the installer and user codes for testing purposes and only put them back when you have it working to your satisfaction.
If you want to upload your log file then zip it and either upload it here in the forum or PM me with it
Well then I guess I never was in powerlink mode, because then I should be able to arm without code with the standard alarm panel?
Do I miss anything by using standard mode?
I regularly update and change my configuration, so restarting HA is pretty common, and if it’s a pain to go in powerlink mode then maybe I should just settle with standard mode
@davesmeghead
I have a number of USB devices connected to my Ubuntu/Docker/Hass.io setup. The Visonic Powermax Pro is connected via a VSB to RS232 connector and works well. I’ve created symbolic links based on the attributes of the USB devices so as to be able to identify USB devices by name rather than the order in which they resolve to the system. To that effect I’ve got a symbolic link created at bootup pointing at the USB to which the visonic connects called
/dev/USB_Visonic -> ttyUSB0
I then map it in the configuration.yaml using;
visonic:
device:
type: usb
path: '/dev/ttyUSB0'
when I change that to
visonic:
device:
type: usb
path: '/dev/USB_Visonic'
it no longer recognises it. Any clues at to why that might be? For all my other USB devices the symbolic link is accepted and works (Conbee, RFXtrx433 etc). Thanks.
I should have said when booted with the latter config, the log file looks like
2019-04-17 12:11:35 INFO (SyncWorker_10) [custom_components.visonic.pyvisonic] Setting key EnableRemoteArm to value True
2019-04-17 12:11:35 INFO (SyncWorker_10) [custom_components.visonic.pyvisonic] Setting key EnableRemoteDisArm to value True
2019-04-17 12:11:35 INFO (SyncWorker_10) [custom_components.visonic.pyvisonic] Setting key OverrideCode to value [Redacted]
2019-04-17 12:11:35 INFO (SyncWorker_10) [custom_components.visonic.pyvisonic] Setting key ResetCounter to value 0
2019-04-17 12:11:35 INFO (SyncWorker_10) [custom_components.visonic] Visonic Connection Device Type is OrderedDict([('type', 'usb'), ('path', '/dev/USB_Visonic'), ('baud', '9600')])
then reports no further activity (that’s with full logging on).
It is the 3rd parameter “port” that is what comes from the config file directly as “path” e.g.
‘/dev/ttyUSB0’, I don’t change it. It looks like the serial_asyncio library can’t handle symbolic links, sorry.
Is it a hard or soft symbolic link? It may be that it needs a hard symbolic link.
@davesmeghead thanks for the quick response. For the moment I’ve backed it out, but left the link defined because it quickly and easily allows me to see what has been mapped to where following a reboot. I’ve subsequently discovered that the deconz add-on also doesn’t operate in exactly the ‘normal’ mode, so maybe I was being too ambitious. That said the RFXtrx add on works without fault, no idea why. I’ve used udevadm to create the link (not sure if that’s soft or hard, sorry), it just seemed like it might solve the issue. Thanks again and also for the work on the brilliant add-on, much appreciated.
Would that not mean that the link is not refreshed at reboot? because that’s the problem I was trying to fix i.e. assign a label to devices which sometimes change port. I’ll keep looking. Thanks.
Did some more digging and it turns out that there is a symbolic link already created by the system, but from the other direction. i.e. /dev/serial/by-id//dev/serial/by-id/usb-FTDI_UC232R_FTYNWOMP-if00-port0 points at /dev/ttyUSB0
I’ve used that in the definition
visonic:
device:
type: usb
path: '/dev/serial/by-id/usb-FTDI_UC232R_FTYNWOMP-if00-port0'
and it works fine and solves the issue of permanence.
Just in case this can help anybody, I tried this component a couple of months ago with a USR-WIFI232-A module, and it never worked. Tried everything in the settings (with @davesmeghead kind help) but ended up giving up. I thought my Powermax 10 had some sort of limitation on the TX/RX communication. Out of curiosity, I ordered a USR-WIFI232-T, (it appears to be the newest and tiniest version of the module, it fits perfectly inside the Powermax case with the wifi antenna hanging out), and go figure: it worked right away. I only had to change the baud rate, control flow, parity and stop bit, as indicated in the instructions, I left the default port to 8899 and gave it a static IP.
I can arm and disarm, and motion detectors show up with their friendly name. It does not connect in Powerlink mode, even after a Full Restart Sequence. But standard mode seems to work fine.
My only question is, should motion detectors (sensors) show motion events when the panel is disarmed? I can only see “last_tripped_time” events when the alarm has been set off by a motion detector.
Also, the alarm shows up in HomeKit but you can’t input the arm/disarm code from there, so I guess I’ll have to use “override_code” if I want to use it in the Home app or with Siri. Btw, in HomeKit it shows options for Home, Away, Night and Off. In HA it only shows Arm Home and Arm Away.
Anyway, thanks a lot to @davesmeghead for his work and his help through PM (also to @Hombre for helping with the pinout) and to anybody who is going to try this, do not buy an early version of the WiFi232 module, go for the latest.
Hello again, I’m really pleased that you got it connected, now let’s see if I can help a little
Yes. In HA can you go to “developer tools” and select “states”. Find one of the sensors (e.g. binary_sensor.visonic_z01) and look at it’s attribute details, there sould be several state attributes including: device_tripped, zone open. Does device_tripped change value at all? zone open is used for doors/windows, device_tripped will initially indicate a tripped state but if it is left open the tripped goes back to False and zone open is set to ‘Yes’
I assume that “Off” means Disarmed. “Night” is not something that my panel can do but it does appear in the Visonic Powermax interface definition so it is possible with some panels!
And you’re very kind to say about my help, you’re very welcome
Edit: Also if you want to post or PM your log file (after setting it to show debug data) I can take a look through
First of all thank you very much for your work in this custom component for the comunity!!
I’m trying to install it on a Fresh Homeassistant install (version 0.91.4) in Ubuntu 18.04.2 with python virtual environment version 3.6.7, and use an ESP8266 with esp-link firmware as serial transparent bridge between PowerMax Pro and HA. I’ve been fighting several days with the custom component (multiple test, reinstallation of homeasistant virtual env, installing dependecies manually, checking with the ‘hello_state’ custom component …) but i have a problem with the inizialization of visonic component. I have this error on HA when it tries to init it and don’t know what else to try. The error is this:
File “”, line 994, in _gcd_import
File “”, line 971, in _find_and_load
File “”, line 955, in _find_and_load_unlocked
File “”, line 665, in _load_unlocked
File “”, line 678, in exec_module
File “”, line 219, in _call_with_frames_removed
File “/root/.homeassistant/custom_components/visonic/init.py”, line 14, in
import custom_components.visonic.pyvisonic as visonicApi # Connection to python Library
AttributeError: module ‘custom_components’ has no attribute ‘visonic’
I would be very grateful if you can tell me some help about what I can test of what may be hapenning
Thank you very much for your time. Regards: Diego Maroto
Just for anyone who’s interested, I am running this component but using a raspberry pi and ser2net.
so my HA (hassio btw) runs in a docker container on an ubuntu server, and the visonic panel is connected with a USB TTL cable to my raspberry pi which runs ser2net server.
my /etc/ser2net.conf:
10628:raw:600:/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700eRHw-if00-port0:9600 8DATABITS NONE 1STOPBIT
This implies that the component is not installed correctly. It looks like you have the “visonic” directory as a sub-directory of the custom_components directory, can you please check. If so, then is there a pyvisonic.py file in the visonic directory? If not then you’ve unpacked the component incorrectly, if there is then I don’t know what you should do. It would then be a python/install problem that python is not finding the import libraries in the library path, but HA should be setting this.
It also looks like you’re running it as user ‘root’, you might want to consider creating a dedicated HA user on your system. Not that I think that is what is wrong with your setup.