Any tried/tested the V3 firmware of the SmartCom? Seems to have been released this month
Daniel,
Many thanks for this wonderful addon, well worth the panel upgrade from the old premier panel and especially with the issues with the 0.115 release and BWAlarm that I used to use.
I can confirm the following.
Installed from Supervisor.
Running on PI 4, booting from SSD with 03/09/20 EEPROM bootloader and running 64bit OS 5.2.
Working flawlessly.
Hi Daniel,
I’ve been tinkering around tying to find out why zone types set at “Latch Key” with attributes “Monitor Only” are not reporting the zone states using your code.
I use this zone type for external perimeter sensor and doorbell so that they can be used as chimes on the panel and light automations in HA…
After setting the log to 0 here’s the result from your log:
2020-09-27 11:21:31 - PANEL: Monitored Alarm (Areas: 1) (Parameter: 5) (Group: 3)
2020-09-27 11:21:31 - DEBUG: Publishing to texecom2mqtt/1002125/log: {"type":"MonitoredAlarm","description":"Monitored Alarm","timestamp":"2020-09-27T10:21:31.346Z","areas":[1],"parameter":5}
2020-09-27 11:21:35 - INFO: Kitchen/BreakfasPIR status changed to Active
2020-09-27 11:21:35 - DEBUG: Publishing to texecom2mqtt/1002125/zone/kitchenbreakfaspir: {"name":"Kitchen/BreakfasPIR","number":3,"areas":[1],"status":1,"type":"Guard"}
2020-09-27 11:21:39 - INFO: Kitchen/BreakfasPIR status changed to Secure
2020-09-27 11:21:39 - DEBUG: Publishing to texecom2mqtt/1002125/zone/kitchenbreakfaspir: {"name":"Kitchen/BreakfasPIR","number":3,"areas":[1],"status":0,"type":"Guard"}
2020-09-27 11:21:40 - PANEL: Monitored Alarm (Areas: 1) (Parameter: 5) (Group: 3)
2020-09-27 11:21:40 - DEBUG: Publishing to texecom2mqtt/1002125/log: {"type":"MonitoredAlarm","description":"Monitored Alarm","timestamp":"2020-09-27T10:21:40.462Z","areas":[1],"parameter":5}
This shows the Kitchen/BreakfastPIR zone which is a “guard” type zone and publishes it’s Active and Secure states as normal.
The zone which is “Latch Key” type, “monitor only” attributes, publishes to “texecom2mqtt/1002125/log” without the zone name or state etc…
Anyway could it be changed in your code? That would make it perfect for me!
PS love the time sync and other automations you did aswell!
Thanks for looking into it.
I’m happy to update the code but I’m not sure how to make it work in a generic way. The panel seems to generate a log event but doesn’t give the current status of the zone.
The parameter attribute should refer to the zone number so you should be able to use the log event to trigger an automation:
- alias: 'Latch Key'
trigger:
- platform: mqtt
topic: "texecom2mqtt/1002125/log"
condition:
- condition: template
value_template: '{{ trigger.payload_json.type == "MonitoredAlarm" && trigger.payload_json.parameter == 5 }}'
Thanks Daniel,
It’s strange that the panel doesn’t output the current state for this. Texecom themselves suggest this zone type for this type of sensor.
The previous integration I used with home assistant used the Crestron protocol and it did output the active and secure state for this zone. I guess your code uses the Connect Protocol?
The Texecom Connect app does report this this zone as a notification and it can also show the state in the “Rooms” or “Security” tabs, so I wonder how they do it?
As you say, the log event could be used, but this only seems the be published if I set your log to debug. The other downside to this is that it will show active but not secure states…
I wonder if the output is fixed on a later firmware version. I’m only on V5.00.02LS1 but dont want to update unless I know it will fix it…
It does indeed. I’ll have a try this week settting up a zone in the same way on my panel and seeing if I can get it working.
The log events are published to MQTT no matter what log setting you have 
Thanks Daniel, I’ve posted a quick message to Texecom also…
Sorry for the delay - I have finally taken the time to transfer over my configuration to the add-on. This was surprisingly quick and works flawlessly! Thanks for updating to support 64-bit
1 Like
Hi Daniel,
I didn’t get any reply from Texecom regarding the Connect protocol output with “Latch Key” type zone. Texecom seem to be ignoring me at the moment.
My post in their forum is here: https://texecom.websitetoolbox.com/post/texecom-connect-protocol-11100083?pid=1319459268
I did get a reply from a nice other member with a work around which I could use as a last resort, but it’ a little bit messy.
Another idea would be to publish the panel outputs as I already mimic the relevant zones to output to my NVR. Are you planning to implement panel outputs with your code in the future? If that’s possible?
Finally I did notice another small problem when using your code, When an area is time armed, the Area entity sticks on “Pending”. If I disarm or rearm manually then status is shown perfectly.
Any ideas on that one?
Cheers.
Thanks for the feedback. I am planning to add support for panel outputs quite soon and it should be possible with the Connect API.
Can you enable the debug log and send me the output when an area arms via the time armed function? I suspect tat the panel sends a different event which isn’t being handled yet.
Here’s the bit from the log when it “Auto Arms”. Sorry I explained it wrongly as “time armed” before.
2020-10-02 22:19:01 - INFO: Detached Garage status changed to In Exit
2020-10-02 22:19:01 - DEBUG: Publishing to texecom2mqtt/1002125/area/detached_garage: {"name":"Detached Garage","number":2,"status":"in_exit"}
2020-10-02 22:19:01 - PANEL: Exit Started (Areas: 2) (Parameter: 11) (Group: 16)
2020-10-02 22:19:01 - DEBUG: Publishing to texecom2mqtt/1002125/log: {"type":"ExitStarted","description":"Exit Started","timestamp":"2020-10-02T21:19:01.366Z","areas":[2],"parameter":11}
2020-10-02 22:19:11 - PANEL: Auto Open/Close (Areas: 2) (Parameter: 0) (Group: 6)
2020-10-02 22:19:11 - DEBUG: Publishing to texecom2mqtt/1002125/log: {"type":"AutoOpenClose","description":"Auto Open/Close","timestamp":"2020-10-02T21:19:11.394Z","areas":[2],"parameter":0}
Thanks for looking at this!
Hi there. Thank you so much for the integration! Works wonderfully.
I have one question though. I’m using the SmartCom over WiFi and your middleware likes to reconnect a lot. Is this normal? Sometimes it’ll reconnect quite a few times and then it’ll be fine for a few hours. Any idea what could be causing this? Thanks again for your hard work.
Are you using the Texecom connect app as well as home-assistant/texecom2mqtt? One thing I can think of is that the communicators (e.g. SmartCom) can only handle one concurrent connection so it might be dropping the texecom2mqtt connection if it’s also getting connections from Texecom connect.
I used to however I disabled it in the ARC for now. Unless somehow the app on my phone is doing something in the background, I’ll uninstall it and see if it helps with anything.
Hi Daniel,
Here’s the response from Texecom regarding the “Latch Key” type zone problem:
"It has been noted and ticketed that the Moment / Latch keys no longer trigger the event when using integration solutions.
Temporarily, if the zones are only necessary for monitoring, they can be placed into an additional area that cannot be armed, and programmed as any other type such as entry/exit or guard so the event is sent to the integration solution."
For now I used mostly your idea to read the log event and trigger an automation which updates the zone status. Here’s my working automation…
trigger:
platform: mqtt
topic: texecom2mqtt/xxxxxx/log
condition:
- condition: and
conditions:
- condition: template
value_template: '{{ trigger.payload_json[''type''] == ''MonitoredAlarm'' }}'
- condition: template
value_template: '{{ trigger.payload_json[''parameter''] == 73 }}'
action:
- service: mqtt.publish
data:
topic: texecom2mqtt/xxxxxx/zone/drive_beam
payload: '{"name":"Drive Beam", "number":"73", "areas":"[1]", "status":"1",
"type":"Latch Key"}'
retain: true
- delay: 00:00:01
- service: mqtt.publish
data:
topic: texecom2mqtt/xxxxxx/zone/drive_beam
payload: '{"name":"Drive Beam", "number":"73", "areas":"[1]", "status":"0",
"type":"Latch Key"}'
retain: true
Has any else tried v3 firmware for the SmartCom?
Just installed my SmartCom, I can connect with the Texecom Connect app, however in HA I see the below:
2020-10-09 15:27:26 - INFO: Connected to alarm, sleeping for 0.5 seconds...
2020-10-09 15:27:27 - INFO: Connection ready
2020-10-09 15:27:27 - INFO: Fetched serial number: xxxxxx
2020-10-09 15:27:27 - INFO: Logging in
2020-10-09 15:27:27 - INFO: Successfully logged in
2020-10-09 15:27:27 - ERROR: Unhandled rejection - Error: Connection refused: Not authorized
UDL is correct (which needed to be in single quotes) as if I change it to something I know is wrong, I do not get ‘Successfully logged in’
Panel Type: Elite 24
Firmware Version: 5.02.01
Smartcom Version: 03.00.16
Ah ha - looks like perhaps it does not like a * in the MQTT password, tried adding quotes and it seemed to remove them. So I remove the * from the MQTT password, then restarted MQTT
I mistakenly added, in quotes
discovery: ‘true’
Entities did not show up in homeassistant, correcting to the below they did:
discovery: true
Just like to add, really happy with this - job well done. Even passed the Wife Acceptance Factor!
Hi @dchesterton,
Just coming back to this after working with the code for a while. I think there is no delay from texecom2mqtt, but perhaps more of an environmental thing with HA.
I noticed that whenever the sensors become “unavailable”, if I publish an “online” payload to texecom2mqtt/<serial_number>/status everything comes back alive.
Maybe it is something to do with my MQTT retention? In my mind (and my basic understanding) if texecom2mqtt was sending an “online” update to the status, i.e. every time it publishes the panel voltage, this would fix my issue - and act as a kind of “heartbeat” to HA.
But it seems it only sends it when the container starts up and connects to the panel the first time.