Also with port 10077 HA told me impossible to connect
Hi,
Let’s start from the beginning:
- What is the device that you are using, are you using Wemos with ESPHome installed
- Have you tried to “ping” the hardware devicewith the IP address, most devices respond to a ping?
- How are you powering the device?
Happy to help
Hi All,
I’m interested in adding a sensor status in HA for when keyfob or wireless siren batteries are low.
If you’re willing to help, the next time that you get a battery low indication from a keyfob or wireless siren then please capture a log file with debug settings and paste it to pastebin with a link here. I can then take a look to see if there are specific messages for it. If you’re really keen then you can help me add the capability and experiment with it to get it working.
Keep smiling
Dave
Hi All,
Tip for the day…
If you have a keyfob with programmable buttons like the Visonic MCT-237 has as buttons A and B. These buttons can be set up in your panel to turn off/on X10 devices. You may not have any X10 devices but as X10 is a 1-way protocol your panel doesn’t know that.
For example:
- Create an X10 device using your panel
- Assign button A on the keyfob to the X10 device using your panel. This can be set to off/on or toggle. I turn a dummy X10 device on for 5 seconds and then off again
- Restart HA and the integration will pick up the X10 device as a Switch
When you press button A the X10 switch in Home Assistant is turned on/off. You can use it in HA for whatever you like.
Hi all, Dave,
I own a Visonic PowerMax Pro alarm. This week, I successfully integrated the alarm to HA using the visonic component by Dave (excellent work by the way, and many thanks for this !). My alarm is a french type 4 visonic Powermax Pro with automatic powerlink detection. The powerlink module is emulated by an ESP01 with ESP-link configured as suggested in the wiki. Everything worked flawlessly for several days until yesterday, where the connexion was lost. The journal seems to indicate that the visonic plugin kept trying to reach the alarm but the alarm don’t accept. After restarting HA, everything is back to normal. It seems weird to me to have to restart HA to recover connection. Is there anything I could do to improve the reliability of the alarm <> HA link?
The link is WIFI and I will not be able to replace it by ethernet cable.
Hi and welcome.
It sounds like the ESP01 had its ip wifi lease renewed from your router and lost it’s connection. I had a similar problem when I had a wifi connection, every so often the connection would drop so I changed mine to wired. The best thing I can suggest is to add an Automation in HA to detect the drop-out and re-connect. It does mean that when this happens you lose the sensor states for a little while for it to detect it and restart. Create an Automation like this.
alias: Restart Visonic on Problem
description: ''
trigger:
- platform: state
entity_id:
- alarm_control_panel.visonic_alarm
to: Problem
attribute: Panel Mode
condition: []
action:
- service: visonic.alarm_panel_reconnect
data: {}
mode: single
You need the latest version of the Integration for this, it’s 0.7.0.3.
This only retries once, you could create an Automation that re-connects every say 5 minutes until it connects.
If you want to wait until the integration itself has tried to reconnect automatically then try this
trigger:
- platform: state
entity_id:
- alarm_control_panel.visonic_alarm
to: unknown
The service visonic.alarm_panel_reconnect keeps the integration running and just tries to reconnect the panel connection itself. If you want to restart the whole integration then try this service
- service: homeassistant.reload_config_entry
data: {}
target:
entity_id: alarm_control_panel.visonic_alarm
Remember that these are just suggestions and I haven’t tried all of them, also this is all case sensitive.
1 Like
Thanks a lot Dave for your explanations and suggestions. I will try this.
Only one of the four sensors I have attached for now are fully detected by the system. After restarding HA, I found the following lines in log identifying the sensor numbers.
2022-05-27 17:33:51 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [Process Settings] pmPanelTypeNr 4 (4) model PowerMax Pro Part
2022-05-27 17:33:51 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [Process Settings] Processing settings information
2022-05-27 17:33:51 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [Process Settings] Processing settings - panel code index 045C
2022-05-27 17:33:51 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [Process Settings] i=0 : VisonicSensorRef=0x95 zoneInfo=0x7 ZTypeName=Perimeter Chime=Off SensorType=Magnet zoneName=Back door
2022-05-27 17:33:51 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [Process Settings] i=1 : VisonicSensorRef=0x97 zoneInfo=0x8 ZTypeName=Perimeter-Follow Chime=Off SensorType=Magnet zoneName=Front door
2022-05-27 17:33:51 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [Process Settings] i=2 : VisonicSensorRef=0x74 zoneInfo=0xc ZTypeName=Interior Chime=Off SensorType=Motion zoneName=Custom 1
2022-05-27 17:33:51 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [Process Settings] i=3 : VisonicSensorRef=0x74 zoneInfo=0xc ZTypeName=Interior Chime=Off SensorType=Motion zoneName=Play room
0x95 is already in your database (MCT-302), 0x97 is also a MCT-302 and the last two (0x74) are Next Plus K9-85 (868) MCW FR motion sensors. Surprisingly, the ZTypeName of the 0x97 MCT-302 is set to Perimeter-Follow instead of Perimeter. I don’t know if it’s important. I hope it will be useful for you to add more sensors in pyvisonic.py
Hi,
Perimeter – Normal alarm zone which will activate if triggered during the AWAY or HOME mode.
Perimeter Follow – Access zone that will trigger during AWAY and HOME modes but allow customers to walk through if a delay zone is triggered first.
I’ve added the sensors to the list, thanks
Edit: Withdrawn from here. It’s not related to the Visonic integration; it’s something wrong with the evaluation of templates.
Hi,
The first time I ran python -m esphome .\visonic.yaml run, I was given these options-
Found multiple options, please choose one:
[1] COM7 (USB-SERIAL CH340 (COM7))
[2] Over The Air (192.168.1.9)
I chose [1] and everything seemed to work. Got this message-
Hard resetting via RTS pin…
←[32mINFO Successfully uploaded program.←[0m
←[32mINFO UART logging is disabled (baud_rate=0). Not starting UART logs.←[0m
I then unplugged from computer, plugged in to 5V, and re-ran yaml. This time, I got the following error-
←[32mINFO Successfully compiled program.←[0m
←[32mINFO Connecting to 192.168.1.9←[0m
←[31mERROR Connecting to 192.168.1.9:8266 failed: [WinError 10061] No connection could be made because the target machine actively refused it←[0m
I can see the Wemos on my network. Any ideas why it won’t connect?
Thank you
Hi Dave,
Yesterday, I experienced a new network connection loss of the ESP01. Few days after your answer, I implemented the automation you suggested after upgrading to 0.7.0.3. The alarm has been reconnected automatically. Today I was able to arm and disarm the alarm but I discovered that the sensor status feedback was no longer being sent to HA since the disconnection.
I put below the debugging log, could you please take a look at it and tell me if you see something that could explain why the detectors do not return their status despite the re-connection?
Sensors information is no longer returned even after restarting HA. The only solution I found to go back to normal is to fully re-install the integration.
By the way, I found out that 0x96 corresponds to a MCT-320 in my installation. It is detected as a MCT-302 (320 is a smaller version of the 302). Maybe the same code is used for different sensors.
I’ve run HA and the Visonic integration in its various developments for a few years but by no means am I an expert.
Normally if the Visonic and HA lose touch a reboot of one or the other or both has sorted it.
Recently they stubbornly refuse the talk.
It seemed to coincide with my being unable to get HACS to install properly. I’m wondering if this means I have a superceded version of the Visonic integration with no way of updating. I don’t even know what version I’m on, or how to tell!
1 Like
I’m not an ESPHome expert, perhaps you could start again and give it a try or perhaps ask on the ESPHome forum page
I think you must be correct as I have the MCT-302 and my system says its 0x96
I’ve taken a look through the log file and I can see that the alarm has started spewing A5 … 04 messages one after another. I’m not exactly sure why the panels sometime do this but I suspect they think they’re being tampered with. Have you had any more problems? I actually need the lines after the last line of the log file to make any more sense so another log file when it happens again would be good please.
Instead of using my service to reconnect (as per your log file) maybe try restarting the integration as per the other service call I suggested.
Have you got it sorted?
As per one of the other discussions, you can automate this
If you mean the visonic integration, then look at the entity using developer tools, states and look for alarm_control_panel.visonic_alarm. Then look for the attribute Client Version.
Thanks for your reply, Dave.
HACS:- Not sorted. Been through the install process - copying code to Github,etc - got the ‘Successfully Installed’ (or similar) message but the Integration has a red box around it and throws up a load of log errors which has been suggested (by my son who is more IT literate than me) refer to there being a previous version’s files somewhere. Have tried removing any trace of an old install but no further on.
Rebooting:- I noticed the automation earlier and will incorporate but at present no amount of HA and/or Visonic reboot is restoring comms. On HA start up I’m getting
This error originated from a custom integration.
Logger: custom_components.visonic.client
Source: custom_components/visonic/client.py:180
Integration: Visonic Intruder Alarm (documentation, issues)
First occurred: 10:16:38 (1 occurrences)
Last logged: 10:16:38
Failed to connect into Visonic Alarm. Check Settings.
Version:- This is the screenshot of Developer Tools/States. As you see there is no client version. The automation shows things were working up to 9th June, around the time the HACS issue surfaced.
I’m convinced that my problem is due to HACS not installing properly. The trouble with being convinced by something is that you miss other things, hence my post.
The other thought I had is that it could be the USR-TCP232-E2 interface with my Unify Dream Machine Router. Since day 1 the router has refused to show the USR-TCP232-E2 as a client (luckily its a fixed IP and is processed, but not reported by, the router) so if there’s a fault with the module it won’t show up. Is there a newer, better module that I should use?
Have you considered trying my loopback test documented here. Simply disconnect Rx and Tx from your panel. Then, with a single wire, connect Tx to Rx on the USR-TCP232-E2 gadget. Look in the HA log file for LOOPBACK TEST SUCCESS, Counter is X where X should be a counter that increments.
Thank you for the loopback test suggestion.
Wiring and rebooting I get a series of log errors as well as the LOOPBACK TEST SUCCESS
In chronological order I’m getting the Log messages below (I’ve just copied the summary line at this stage).
My take on it is that the first 2 can be discounted as its a test.
The counter then seems to be OK for a while before the connection is disconnected by the USR-TCP232-E2 gadget.
I’m not sure about the last one.
Seems the USR-TCP232-E2 could be the problem? Do you agree or am I chasing my tail? Its years since I set it up so I’ll need to try and re-access it and check the settings.
Is there a new better module that is recommended these days?
The only other thing I can think of is that the Unify Router has taken a dislike to the module and disconnects it!
Logs:-
First occurred: 10:37:22 (5 occurrences)
Last logged: 10:51:16
[data receiver] Warning : Construction of incoming packet unknown - Message Type 0X24
First occurred: 10:37:22 (5 occurrences)
Last logged: 10:51:16
[data receiver] Received Unknown PDU 0x24
First occurred: 10:37:16 (290 occurrences)
Last logged: 11:02:50
- [handle_msgtype0F] LOOPBACK TEST SUCCESS, Counter is 140
First occurred: 10:38:45 (5 occurrences)
Last logged: 11:18:35
ERROR Connection Lost : disconnected because the Ethernet/USB connection was externally terminated
First occurred: 10:38:45 (5 occurrences)
Last logged: 11:18:35
- ERROR Connection Lost : disconnected due to exception [Errno 104] Connection reset by peer
- ERROR Connection Lost : disconnected due to exception [Errno 113] Host is unreachable
Yes
I don’t think it is the settings in the E2 itself if it has been working well in the past. Something has changed and I assume you haven’t changed these settings for a long time.
It’s something in the Ethernet connection “chain” that breaks after a period of working OK Is this consistent, is the time period consistent?
You have 2 hardware options I think:
- buy a new USR-TCP232-E2. As far as I know there isn’t a new version but I’m not sure. The downside of this is if it’s your router then you’re not proving anything. Can you bypass your router? Can you try a different port on the router? Can you remove the E2 from your panel and power it from somewhere else (using the loopback test still) to see if it’s the cable?
- consider buying a Wemos D1 R2 as they’re relativelly cheap and setting it up with ESPHome as on the wiki here. I know this is wifi but it makes a difference for your router as well so may be a better test. You also have to be confident at setting up ESPHome and the Wemos though so consider your options here.
Let me know what you decide and how you get on
Its taken a few days to try and track down what could be the issue but I think the Ethernet connection on the UDM is the problem.
Firstly I’ve set going a continuous ping of the module, when the HA has lost touch with the panel, whilst I investigate because I can see when/if the state changes.
2 night ago I thought it was an issue with the battery pulling down the voltage of the power supply since everything started up fine when I forgot to re-connect the battery. But then it worked fine with just the battery and then both!
Today it happened again. Again with pinging running whilst I took a look it was clear that the connection state light (green) was intermittent - indeed hardly lit at all. Contact cleaner has restored it to continuous and the Panel & HA are talking again, hopefully for good.
Of course I could be kidding myself 