I rolled back I’m afraid - I didn’t try a full restart of the entire system though, I ran out of time in my ‘Patch Sunday’ maintenance window before people started waking up 
ha ha, I rolled back for the same reason!
Since the last update to 1.0.41 I have found the reliability not so good. I keep getting this scenario.
And only stopping the app and restarting it again seems to clear it. I deleted all the old entries to MQTT and also did a clean install of texecom2mqtt. I just keep getting null values after a period of it running normally
2021-05-17 17:33:31 - DEBUG: Publishing to texecom2mqtt/power: {“battery_charging_current”:9,“battery_voltage”:null,“panel_current”:585,“panel_voltage”:null}
2021-05-17 17:34:20 - DEBUG: Updating system power…
2021-05-17 17:34:20 - TRACE: Executing command 25
2021-05-17 17:34:21 - TRACE: Received data chunk of length 7
2021-05-17 17:34:21 - DEBUG: Publishing to texecom2mqtt/power:
I’ve pushed an update (1.0.42) which fixes a couple of small bugs from the last release. Please can you pull this version if you were having issues with the previous version and let me know if it fixes them.
2 Likes
Thanks Daniel…I’ve just downloaded 1.0.42 I’ll let you know how I get on later. I have also noticed another issue that is giving me some problems, and that is a lag in the latest version of Mosquitto MQTT. I am noticing a few problems with it working with the latest version of Tasmota. Having read the forums Mosquitto Broker 5.1.1 is giving people a lot of problems and is awaiting a fix
Thanks Daniel. 1.0.42 installed here with no fuss (after deleting the old MQTT topics) and seems to be working ok so far after a couple of hours. Will update again in a few days with comments on longer-term stability as I’d been using 1.0.36 due to later versions being a bit unreliable.
So far, so good!
(Texecom Elite 48 running V5.04.01 LS1)
@dchesterton That latest update has definitely worked for me…I was getting a couple of other errors from automations that use the mqtt to detect status etc and they were logging errors every reboot…they’ve now gone now too…Thanks once again
1.0.42 seems to fix my issues - can confirm the old MQTT topics also automatically removed. I did have to restart HA, for it to rediscover the entities.
I bought a Smartcom mostly because of Daniel’s work - many thanks!
I’m loving that I can use my alarm PIRs as general motion sensors in HA. They’re a bit noisy though: on for a fraction of a second, off for a second, on again… as I move by. It’s great that they can be so responsive, but can anyone suggest the best way to reduce this hysteresis if I don’t need this time granularity? I’m having problems with long-running scripts being triggered several times in a couple of seconds as I walk past.
A statistics sensor, perhaps, to measure the degree of my presence over the last few secs? Or an input boolean that is turned on by the first occurrence and off 5s after the last? I can think of a few solutions, but am wondering which is the best.
Suggestions gratefully received!
Quentin
.Just had the App freeze up on me and had to restart it manually
version 1.0.42
On Docker
and the logs…
2021-05-21 13:00:22 - DEBUG: Publishing to texecom2mqtt/zone/lounge_rear_motion_sensor: {"name":"LOUNGE REAR Motion Sensor","number":3,"areas":["A"],"status":0,"type":"Guard"}
2021-05-21 13:00:22 - DEBUG: Command 25 timed out (attempt 1, id: 32).
2021-05-21 13:00:22 - INFO: KITCHEN Motion Sensor status changed to Secure
2021-05-21 13:00:22 - DEBUG: Publishing to texecom2mqtt/zone/kitchen_motion_sensor: {"name":"KITCHEN Motion Sensor","number":5,"areas":["A"],"status":0,"type":"Guard"}
2021-05-21 13:00:23 - PANEL: Output state changed digi: 255
2021-05-21 13:00:26 - INFO: LOUNGE REAR Motion Sensor status changed to Active
2021-05-21 13:00:26 - DEBUG: Publishing to texecom2mqtt/zone/lounge_rear_motion_sensor: {"name":"LOUNGE REAR Motion Sensor","number":3,"areas":["A"],"status":1,"type":"Guard"}
2021-05-21 13:00:26 - DEBUG: Command 25 timed out (attempt 2, id: 32).
2021-05-21 13:00:26 - PANEL: Output state changed digi: 251
2021-05-21 13:00:29 - DEBUG: Command 25 timed out (attempt 3, id: 32).
2021-05-21 13:00:30 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":99,"battery_voltage":13.42,"panel_current":990,"panel_voltage":13.63}
2021-05-21 13:01:09 - DEBUG: Updating system power...
2021-05-21 13:01:09 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":99,"battery_voltage":13.42,"panel_current":990,"panel_voltage":13.63}
2021-05-21 13:01:59 - DEBUG: Updating system power...
2021-05-21 13:01:59 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":99,"battery_voltage":13.42,"panel_current":990,"panel_voltage":13.63}
2021-05-21 13:02:49 - DEBUG: Updating system power...
2021-05-21 13:02:49 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":99,"battery_voltage":13.42,"panel_current":990,"panel_voltage":13.63}
2021-05-21 13:03:39 - DEBUG: Updating system power...
2021-05-21 13:03:39 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":99,"battery_voltage":13.42,"panel_current":990,"panel_voltage":13.63}
2021-05-21 13:04:29 - DEBUG: Updating system power...
2021-05-21 13:04:29 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":99,"battery_voltage":13.42,"panel_current":990,"panel_voltage":13.63}
Following my earlier message, this UDL related issue is still present for me. I’ve tried many versions of Texecom2mqtt but still see the same error in the logs. it happens literally seconds after this addon goes online. I have a dedicated COMIP on com 3 i use for Texecom2mqtt (with a smartcomm on comms 1 & 2). As i mentioned previously if i have wintex running (connecting via smartcom) then i do not see this error, however if wintex is closed i see the error below in my logs and it Texecom2mqtt goes offline. prior to this issue occurring (literally stated overnight one day) i used Texecom2mqtt successfully for many months.
I have tried to disable smartcom (i just set comms 1 & 2 to ‘no function’) i still get this issue. if i don’t have Texecom2mqtt running, i don’t get a UDL fault on my alarm panel (if i do have it running without wintex loaded, i see UDL faults).
Logs below, any tips would be very gratefully received.
2021-05-22 11:53:29 - INFO: Application ready
2021-05-22 11:54:19 - DEBUG: Updating system power…
2021-05-22 11:54:19 - DEBUG: Publishing to texecom2mqtt/power: {“battery_charging_current”:18,“battery_voltage”:13.84,“panel_current”:414,“panel_voltage”:13.91}
2021-05-22 11:55:09 - DEBUG: Updating system power…
2021-05-22 11:55:09 - DEBUG: Publishing to texecom2mqtt/power: {“battery_charging_current”:18,“battery_voltage”:13.77,“panel_current”:459,“panel_voltage”:13.91}
2021-05-22 11:55:59 - DEBUG: Updating system power…
/snapshot/app/dist/texecom/texecom.js:132
throw new Error(Expected command ID ${command.command} for sequence ${sequence}, got ${commandType}); ^
Error: Expected command ID 25 for sequence 33, got 1
at Texecom.parseBuffer (/snapshot/app/dist/texecom/texecom.js:132:31)
at Socket. (/snapshot/app/dist/texecom/texecom.js:32:18)
at Socket.emit (events.js:315:20)
at addChunk (_stream_readable.js:295:12)
at readableAddChunk (_stream_readable.js:271:9)
at Socket.Readable.push (_stream_readable.js:212:10)
at TCP.onStreamRead (internal/stream_base_commons.js:186:23)
@MarkB1 @dchesterton
I am getting the same results as Mark. After the app has been running for several hours. The app seems to lock up. The power is still reported via MQTT every 50 seconds although the voltage and current etc remain the same value and do not change and the alarm still appears online but there is no other sensor information sent via MQTT, if you trigger a door contact or PIR etc nothing shows up. Sometimes I have seen a triggered contact showing up as triggered and doesn’t clear. (Frozen)
I have the same log output as Mark in his post. I’ve been monitoring it now for a couple of days and it’s always the same thing. Only stopping and restarting the app seems to send it on its merry way again until the next lockup.
2021-05-24 13:06:25 - DEBUG: Updating system power...
2021-05-24 13:06:25 - TRACE: Executing command 25
2021-05-24 13:06:26 - TRACE: Received data chunk of length 7
2021-05-24 13:06:26 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":36,"battery_voltage":14.05,"panel_current":558,"panel_voltage":14.19}
2021-05-24 13:07:15 - DEBUG: Updating system power...
2021-05-24 13:07:15 - TRACE: Executing command 25
2021-05-24 13:07:16 - TRACE: Received data chunk of length 7
2021-05-24 13:07:16 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":36,"battery_voltage":14.05,"panel_current":558,"panel_voltage":14.19}
2021-05-24 13:08:05 - DEBUG: Updating system power...
2021-05-24 13:08:05 - TRACE: Executing command 25
2021-05-24 13:08:06 - TRACE: Received data chunk of length 7
2021-05-24 13:08:06 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":36,"battery_voltage":14.05,"panel_current":558,"panel_voltage":14.19}
2021-05-24 13:08:55 - DEBUG: Updating system power...
2021-05-24 13:08:55 - TRACE: Executing command 25
2021-05-24 13:08:56 - TRACE: Received data chunk of length 7
2021-05-24 13:08:56 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":36,"battery_voltage":14.05,"panel_current":558,"panel_voltage":14.19}
2021-05-24 13:09:45 - DEBUG: Updating system power...
2021-05-24 13:09:45 - TRACE: Executing command 25
2021-05-24 13:09:46 - TRACE: Received data chunk of length 7
2021-05-24 13:09:46 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":36,"battery_voltage":14.05,"panel_current":558,"panel_voltage":14.19}
2021-05-24 13:10:35 - DEBUG: Updating system power...
2021-05-24 13:10:35 - TRACE: Executing command 25
2021-05-24 13:10:36 - TRACE: Received data chunk of length 7
2021-05-24 13:10:36 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":36,"battery_voltage":14.05,"panel_current":558,"panel_voltage":14.19}
2021-05-24 13:11:25 - DEBUG: Updating system power...
2021-05-24 13:11:25 - TRACE: Executing command 25
2021-05-24 13:11:26 - TRACE: Received data chunk of length 7
2021-05-24 13:11:26 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":36,"battery_voltage":14.05,"panel_current":558,"panel_voltage":14.19}
2021-05-24 13:12:15 - DEBUG: Updating system power...
2021-05-24 13:12:15 - TRACE: Executing command 25
2021-05-24 13:12:16 - TRACE: Received data chunk of length 7
2021-05-24 13:12:16 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":36,"battery_voltage":14.05,"panel_current":558,"panel_voltage":14.19}
2021-05-24 13:13:05 - DEBUG: Updating system power...
2021-05-24 13:13:05 - TRACE: Executing command 25
2021-05-24 13:13:06 - TRACE: Received data chunk of length 7
2021-05-24 13:13:06 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":36,"battery_voltage":14.05,"panel_current":558,"panel_voltage":14.19}
2021-05-24 13:13:55 - DEBUG: Updating system power...
2021-05-24 13:13:55 - TRACE: Executing command 25
2021-05-24 13:13:56 - TRACE: Received data chunk of length 7
2021-05-24 13:13:56 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":36,"battery_voltage":14.05,"panel_current":558,"panel_voltage":14.19}
2021-05-24 13:14:45 - DEBUG: Updating system power...
2021-05-24 13:14:45 - TRACE: Executing command 25
2021-05-24 13:14:46 - TRACE: Received data chunk of length 7
2021-05-24 13:14:46 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":36,"battery_voltage":14.05,"panel_current":558,"panel_voltage":14.19}
Hey,
Firstly, great work on this project! I’ve had it running for a couple of weeks now, and it mostly works brilliantly!
I’m running the latest version (1.0.42), but i’ve noticed a couple of issues that i’ve not been able to find anyone else already mention (apologies if there is and i’ve just missed it)
-
I have a number of circuits wired directly into wired keypads (panic buttons and switches for part arming), but they don’t seem to show up in zone list. Has anyone else tried this? They do appear in the Texecom app.
-
I use a switch to enable part arming at night (via a Latching Keyswitch circuit type), but most of the time when I set the alarm in this method, Home Assistant shows those areas as “in exit” and never changes to one of the defined part set options I’ve defined in the config file, and the log shows the staus changing to “Part Armed undefied”. The log entry is below:
2021-05-24 06:39:50 - PANEL: Keyswitch - Latching (Areas: A, C, B; Parameter: 75; Group: 6)
2021-05-24 06:39:50 - DEBUG: Publishing to texecom2mqtt/log: {"type":"LatchKey","description":"Keyswitch - Latching","timestamp":"2021-05-24T06:39:50Z","areas":["A","C","B"],"parameter":75}
2021-05-24 06:39:50 - INFO: Home status changed to Part Armed undefined
2021-05-24 06:39:50 - DEBUG: Publishing to texecom2mqtt/area/home: {"id":"A","name":"Home","number":1,"status":"part_armed_undefined"}
2021-05-24 06:39:50 - INFO: Garage status changed to Part Armed undefined
2021-05-24 06:39:50 - DEBUG: Publishing to texecom2mqtt/area/garage: {"id":"B","name":"Garage","number":2,"status":"part_armed_undefined"}
Weirdly, sometimes it work’s fine, but i’d say 95% of the time it goes back to this undefined error.
I’d be grateful for any suggestions on what to try next. 
Not a very helpful post, as I didn’t have debug logging available at the time, but have had a single incident of the app stopping producing data since updating to 1.0.42 a few days back. Everything looked to be working from the HA UI, but the log had stopped updating and no alarm updates were appearing in the UI. A restart of the app resolved it immediately.
I’ll enable debug logging, but I suspect I’m seeing exactly the same as the others reporting this above.
I don’t use these, but if I get a second I’ll wire one up temporarily to test and will let you know what it does.
I assume you’ve got the keypad inputs properly mapped to zones in the alarm? (ref. page 80 of https://www.texe.com/uk/uploads/INS176-15_Premier_Elite_Series_Installation_Manual_2.pdf)
I have been using this to replace my alarm keypad with a tablet running lovelace - Unfortunately it seems that if the alarm goes off, it cannot be reset through the UI. Do you know if this is a bug or a limitation of the connect protocol?
Thanks
Hello, I’m so glad I’ve come across this add-on. I’ve been looking to integrate my Texecom alarm into HASS for a while!
The base set-up is up and running, and pulling in all the sensors okay. However when I try to add in my part-arms, it doesn’t seem to be working. Nor does arming the alarm. Where am I going wrong?
Here’s the configuration in the add-on itself:
texecom:
host: host.IP.here
mqtt:
host: core-mosquitto
homeassistant:
discovery: true
areas:
- id: house
name: House Alarm
full_arm: armed_away
part_arm_1: Dog_Home
part_arm_2: Bedtime
part_arm_3: Doors_Only
code_arm_required: true
code_disarm_required: true
code: 'codehere'
zones: []
log: debug
Here’s some detail from the logs:
2021-05-28 15:07:23 - WARNING: Unknown command ARM_AWAY for area House
…and…
2021-05-28 15:11:57 - WARNING: Unknown command ARM_HOME for area House
Maybe other useful detail from the logs:
2021-05-28 15:23:07 - INFO: Fetched Area A: House
2021-05-28 15:23:07 - INFO: Fetched Area B: Area B
Thanks for looking into this. Yeah, the keypads are all mapped across correctly, and work fine otherwise on the alarm.
Area ID in Lower case, change to House which matches your logs
A working example for you, my areas are house and workshop and this is my code (I don’t have a code in HA, could remove it to see if that is causing your issue?)
areas:
- id: house
full_arm: armed_away
part_arm_2: armed_night - id: workshop
full_arm: armed_away
zones: []
Fantastic, thanks for sharing that example.
I think the capital H on house was the problem!
Interestingly, since correcting that, I’ve had intermittent issues with data from the alarm system feeding into HA. When I look at the add-in logs, it’s ‘receiving’ the data (e.g. people walking around the house etc) however it doesn’t seem to be publishing it to Mosquitto.
This morning, I manually set the MQTT server details (host, port, user and password) even though MQTT was hosted locally. Since then (touch wood!) I’ve consistently been receiving data from the system