Hi Emile,
Welcome onboard!
If you’re still not sure please upload another log file and I’ll take a look.
The log file that you uploaded has a lot of communication errors, it looks like the transmit isn’t working reliably. Having said that, there are a lot of checks put in before it declares powerlink so I assume that it’s OK now.
Hi Dave, thanks again.
OK I think I have fixed the issue of it not starting up reliable. The problem is when you open my USB serial adaptor, there is about 50bytes of garbage random data somewhere in the buffers, unfortunately this happens to contain 0xD’s and 0xA’s, thus the message state machine gets in to a state where is misses the next valid message.
I have put a hack in so there is a flag ‘firstCmdSent’ which init is False, gets set to True just before the first message is sent. The data_received checks this flag and throws away data while it is False, thus discarding the bad data.
This fixed it for me, let me know if I can help if you want any more info.
Cheers
Hi Rob,
I cannot read the markings on my USB adapter, here is a picture of the front side:
as you can see the markings appear to have been deleted, I remembered that I bought it in Ebay, so I searched my purchase history and found my original order, this is the title to the Purchase:
USB TTL Converter Adapter Module pl2303 UART rs232 Arduino pl2303hx
It is no longer active but I searched for a similar product and found this:
https://www.ebay.com/itm/AU-USB-To-TTL-UART-RS232-Chip-PL2303HX-Auto-Converter-Adapter-Module-for-Arduino/153351104159?epid=1739263533&hash=item23b470269f:g:DooAAOSwsUJbXui8
I think my chip is the PL2303HX, the Note to the RXD line in the datasheet is different:
(2) - Tri-State, CMOS Input/Output Pad with level shifter. Level and Driving Capability decided by VDD_325.
https://prolificusa.com/app/uploads/2018/02/ds_pl2303HXD_v1.6.0.pdf
But I don’t know what that means, If my adapter is incompatible with my panel I’m willing to buy another one that might work.
What it means is the logic levels on the PL2303HX are defined by the voltage on pin 4 of the chip. I’m pretty sure it’s connected to the on-chip 3.3 volt regulator. That, and the fact that the input maximum is 3.3 volts means you shouldn’t try to drive it with your alarm panel.
I wouldn’t risk over-stressing your panel, or worse, using the adapter. If it were me, I’d get a proper USB adapter, one with a 2m cable and compatible with a 5 volt logic signal on the Rx interface.
Like the TTL-232R-RPi cable you sugested?
Yes. I’ve spoken with a manufacturer’s rep from FTDI, and he said it’ll work with 5 volt logic. It also says it in the data sheet.
- 5V safe TTL inputs make the TTL-232R easy to interface to 5V MCU’s.
FYI: There’s only one input–the Rx line. FYI: MCU is a microcontroller unit in RS-232 parlance.
I’ve provided a link to the European distributors in a previous post. Mouser had stock and good unit quantity pricing, but one Rpi supplier had the FTDI product as well. You might want to check with the shop where you got yours.
Addendum:
The FTDI technical representative said the cable was 1.8 meters in length. The datasheet says 1 meter. Assuming you will have a working RS-232 port, you can always get a USB extension cable if needed.
I found a physical store that sells the TTL-232R-RPi at 25,83 € taxes incl, near my home here in Lisboa, Portugal, I think I will get it.
Yes I noticed the specs say the cable length is 1.0m.
OK tested a bit more and now is rock solid going into Powerlink mode after HA reboots.
This is the small fix I needed:
Might only be needed for my cheapo USB serial adapter and raspberry Pi.
2 Likes
Hi Rob,
I picked up the TTL-232R-RPi cable today, but I still need some help.
I have already instaled, via HACS, the Visonic Custom Component,
As far as I understand I have to connect the USB port of the cable to my HassIO Raspberry Pi, and then the Yellow cable (RX) to the second Pin from the left of my Panel (TX), the Orange cable (TX) to the third Pin from the left of my Panel (RX) and the Black Cable to the fourth Pin (GND), right?
The Cable Adapter was detected by the HassIO as:
/dev/serial/by-id/usb-FTDI_TTL232R-3V3_FTFMEY0R-if00-port0
I added the following to my Configuration.yaml:
visonic:
device:
type: usb
path: '/dev/ttyUSB0'
motion_off: 120
language: 'EN'
force_standard: 'no'
sync_time: 'yes'
allow_remote_arm: 'yes'
allow_remote_disarm: 'yes'
exclude_sensor: [2,3]
exclude_x10: [1]
# force_numeric_keypad: 'yes'
# override_code: '1234'
# download_code: '9876'
# arm_without_usercode: 'yes'
Is this correct?
as far as I can see it’s not working, but then agiain I don’t know how to check if it’s working or not.
Assuming the right colors, that looks correct.
Looks good.
It’s a reasonable starting point. If you want, you can comment out the ‘exclude_sensor’ and ‘exclude_x10’ lines by prepending a ‘#’ in front of them.
You need to set up debug. Put the following in your configuration.yaml file:
logger:
default: critical
logs:
custom_components.visonic: debug
custom_components.visonic.pyvisonic: debug
custom_components.visonic.alarm_control_panel: debug
custom_components.visonic.binary_sensor: debug
custom_components.visonic.switch: debug
custom_components.visonic.__init__: debug
Then check your configuration, reboot the system, and check you system log.
I need to be somewhere. More when I return later.
To check configuration:
Go to ‘Configuration’ > ‘Server Control’ and click the ‘Check Config’ button. Look for ‘Configuration valid!’ If not validated, you should try to fix it using the provided diagnostic information.
To reboot the system:
Go to ‘Hass.io’ > ‘System’. On the ‘Host system’ card, click REBOOT. Wait for the system to shake itself awake and pull up the Overview page.
For logging, you can check in two places. The first place is under ‘Hass.io’ > ‘System’. The second place is to navigate to ‘Configurator’, click the folder icon and look for ‘home-assistant.log’. The file will have the debug information.
If bits are being sent to the RS-232 adapter, you should see lots of entries with ‘[custom_components.visonic.pyvisonic]’ in them. If you have communication, you should see the acknowledge messages: ‘Ack Received data = 43.’
A good indicator of success is to go to ‘Developer Tools’ > ‘States’. You should be able to find ‘alarm_control_panel.visonic_alarm’ in the entities column. The corresponding area on the right in the ‘Attributes’ column should be populated with alarm attributes. ‘Mode’ should show a state, e.g. ‘Standard’ or ‘Powerlink.’
In the future, most changes of configuration can be realized by going to ‘Configuration’ > ‘Server Control’ and in the ‘Server management’ card, clicking ‘RESTART.’
Hi Rob,
I’ve done everything you sugested, but I’m not seeing the ‘Ack Received data = 43.’ in the logs anywhere.
here is an exemple of my logs:
2019-11-20 11:56:55 INFO (SyncWorker_19) [custom_components.visonic.pyvisonic] Initialising Protocol - Component Version 0.3.3.4
2019-11-20 11:56:57 INFO (SyncWorker_19) [custom_components.visonic.pyvisonic] Setting key MotionOffDelay to value 120
2019-11-20 11:56:57 INFO (SyncWorker_19) [custom_components.visonic.pyvisonic] Setting key PluginLanguage to value EN
2019-11-20 11:56:57 INFO (SyncWorker_19) [custom_components.visonic.pyvisonic] Setting key ForceStandard to value False
2019-11-20 11:56:57 INFO (SyncWorker_19) [custom_components.visonic.pyvisonic] Setting key AutoSyncTime to value True
2019-11-20 11:56:57 INFO (SyncWorker_19) [custom_components.visonic.pyvisonic] Setting key EnableRemoteArm to value True
2019-11-20 11:56:57 INFO (SyncWorker_19) [custom_components.visonic.pyvisonic] Setting key EnableRemoteDisArm to value True
2019-11-20 11:56:57 INFO (SyncWorker_19) [custom_components.visonic.pyvisonic] Setting key ResetCounter to value 0
2019-11-20 11:56:57 INFO (SyncWorker_19) [custom_components.visonic] Visonic Connection Device Type is OrderedDict([('type', 'usb'), ('path', '/dev/ttyUSB0'), ('baud', '9600')])
2019-11-20 11:57:55 INFO (MainThread) [custom_components.visonic.pyvisonic] [Connection] Connected to local Protocol handler and Transport Layer
2019-11-20 11:57:55 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [ClearList] Setting queue empty
2019-11-20 11:57:55 INFO (MainThread) [custom_components.visonic.pyvisonic] [Start_Download] Starting download mode
2019-11-20 11:57:56 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Resetting expected response counter, it got to 0 Response list before 0 after 1
2019-11-20 11:58:15 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Sending Command (Exit) raw data 0d 0f f0 0a waiting for message response ['0X2']
2019-11-20 11:58:15 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Command has a wait time after transmission 1.5
2019-11-20 11:58:19 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Sending Command (Stop) raw data 0d 0b f4 0a waiting for message response ['0X2']
2019-11-20 11:58:19 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Command has a wait time after transmission 1.5
2019-11-20 11:58:19 DEBUG (MainThread) [custom_components.visonic.alarm_control_panel] code format called *****************************
2019-11-20 11:58:19 DEBUG (MainThread) [custom_components.visonic.alarm_control_panel] code format number *****************************
2019-11-20 11:58:22 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Sending Command (Initializing PowerMax/Master PowerLink Connection) raw data 0d ab 0a 00 01 00 00 00 00 00 00 00 43 06 0a waiting for message response ['0X2']
2019-11-20 11:58:22 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Command has a wait time after transmission 8.0
2019-11-20 12:02:47 WARNING (MainThread) [custom_components.visonic.pyvisonic] [Controller] ********************** Download Timer has Expired, Download has taken too long *********************
2019-11-20 12:02:47 WARNING (MainThread) [custom_components.visonic.pyvisonic] [Controller] ************************************* Going to standard mode ***************************************
2019-11-20 12:02:47 INFO (MainThread) [custom_components.visonic.pyvisonic] [Standard Mode] Entering Standard Mode
2019-11-20 12:02:47 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [ClearList] Setting queue empty
2019-11-20 12:02:47 INFO (MainThread) [custom_components.visonic] Exclude sensor list = [] Exclude x10 list = []
2019-11-20 12:02:47 INFO (MainThread) [custom_components.visonic] Visonic update event 7
2019-11-20 12:02:47 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Resetting expected response counter, it got to 181 Response list before 0 after 1
2019-11-20 12:02:47 INFO (SyncWorker_18) [custom_components.visonic.alarm_control_panel] alarm control panel received update event
2019-11-20 12:02:47 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Sending Command (Exit) raw data 0d 0f f0 0a waiting for message response ['0X2']
2019-11-20 12:02:47 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Command has a wait time after transmission 1.5
2019-11-20 12:02:47 DEBUG (MainThread) [custom_components.visonic.alarm_control_panel] code format called *****************************
2019-11-20 12:02:47 DEBUG (MainThread) [custom_components.visonic.alarm_control_panel] code format number *****************************
2019-11-20 12:02:49 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Sending Command (Stop) raw data 0d 0b f4 0a waiting for message response ['0X2']
2019-11-20 12:02:49 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Command has a wait time after transmission 1.5
2019-11-20 12:02:50 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Sending Command (Initializing PowerMax/Master PowerLink Connection) raw data 0d ab 0a 00 01 00 00 00 00 00 00 00 43 06 0a waiting for message response ['0X2']
2019-11-20 12:02:50 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Command has a wait time after transmission 8.0
2019-11-20 12:02:57 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [Controller] ****************************** Response Timer Expired ********************************
2019-11-20 12:02:57 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [ClearList] Setting queue empty
2019-11-20 12:02:57 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Resetting expected response counter, it got to 0 Response list before 0 after 2
2019-11-20 12:02:58 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Sending Command (Getting Status) raw data 0d a2 00 00 00 00 00 00 00 00 00 00 43 1a 0a waiting for message response ['0XA5', '0X2']
2019-11-20 12:03:07 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [Controller] ****************************** Response Timer Expired ********************************
These are the Filter Attributes to the [alarm_control_panel.visonic_alarm] entity:
code_format: number
changed_by: null
code_arm_required: true
PluginVersion: 0.3.3.4
Comm Exception Count: 0
Mode: Standard
Watchdog Timeout: 0
Download Timeout: 1
Panel Last Event: None
Panel Alarm Status: None
Panel Trouble Status: None
Panel Siren Active: No
Panel Status: Unknown
Panel Status Code: -1
Panel Ready: No
Panel Alert In Memory: No
Panel Trouble: No
Panel Bypass: No
Panel Status Changed: No
Panel Alarm Event: No
Panel Armed: No
Power Master: No
Model: Unknown
friendly_name: Visonic Alarm
As far as I understand my HassIO is trying to communicate with the panel but is not getting any response, maybe the RX and Tx wires are switched?
Possibly. Go ahead and swap them.
My fingers are crossed.
Another thought. Try disconnecting the phone line.
I switched the TX and RX, nothing changed, disconnected the phone line the same result.
I didn’t restart HassIo, should I restart it after every change?
Yes, a server restart between hardware configuration changes is not a bad idea. We don’t want to miss a test case that might work. Even a panel restart might help. From Dave’s readme page:
- Restart the panel: Restart your Visonic panel by going in to and out of installer mode. Do not do any panel resets, the act of exiting installer mode is enough.
Since you disconnected the telephone line, try going in and out of installer mode, if possible.
Dave, thanks for taking the time and trouble to reply regarding the apparent freezing of the serial to ethernet module.
I’m struggling to get time to sit down and go through the suggestions & set logging up and it’s clear that the issue is not as simple as I thought eg module appears to communicate, HA sees everything but automation don’t work. Clearly it needs a more thorough probing.
Are you still having problems with freezing of the Ethernet module? In a prior post, I notice you have RTS/CTS hardware flow control selected. If not already, I think this needs to be disabled. I don’t expect any effects to automations.
Hi Rob,
I have done as you suggested (flow control from RTS/CTS to None).
Before doing this all flags were showing in HA, giving impression (to me) that all was well but eg opening a door did not change flag icon and Telegram automation, X10, etc did not work - HA graphic essentially frozen even though ethernet module was showing Tx and Rx packets. In the past this has necessitated hard reset of module and HA on RPi.
Immediately I’ve changed the flow control to ‘None’ all functionality has returned to HA so your suggestion looks to have worked.
As always with these things time will tell, but many thanks for pointing me towards that.
1 Like