by:
I’m guessing that’s the app code then. i’ll give it a go.
Had an occurrence of it myself this evening running 1.0.35, which caused the add-on to stop:
/snapshot/app/dist/texecom/texecom.js:95
throw new Error(`CRC is invalid, message: ${thisMessage.toString("hex")}`);
^
Error: CRC is invalid, message: 744d088919180088
at Texecom.parseBuffer (/snapshot/app/dist/texecom/texecom.js:95:19)
at Socket.<anonymous> (/snapshot/app/dist/texecom/texecom.js:246:26)
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)
Let me know if you want me to try to get it to happen with debug mode or any other additional changes, and I’ll be happy to do so.
Hi…sorry for the very late reply… see below for a log snippit leading up to the error…
2021-03-08 20:23:36 - INFO: Starting texecom2mqtt v1.0.35…
2021-03-08 20:23:36 - INFO: Connected to alarm, sleeping for 0.5 seconds…
2021-03-08 20:23:36 - INFO: Connection ready
2021-03-08 20:23:36 - INFO: Fetched serial number: XXXXXXXX
2021-03-08 20:23:36 - INFO: Logging in
2021-03-08 20:23:36 - INFO: Successfully logged in
2021-03-08 20:23:37 - INFO: Connected to MQTT
2021-03-08 20:23:37 - INFO: Fetched panel info: Premier Elite 640 (V5.00.02LS1)
2021-03-08 20:24:28 - INFO: Fetched Zone 65: Front Door (Type: Entry/Exit 1; Areas: 1A)
2021-03-08 20:24:32 - INFO: Fetched Zone 66: Back Door (Type: Guard; Areas: 1A)
2021-03-08 20:24:32 - INFO: Fetched Zone 67: Playroom PIR (Type: Guard; Areas: 1A)
2021-03-08 20:24:33 - INFO: Fetched Zone 68: Livingroom PIR (Type: Guard; Areas: 1A)
2021-03-08 20:24:33 - INFO: Fetched Zone 69: Dining Room PIR (Type: Guard; Areas: 1A)
2021-03-08 20:24:33 - INFO: Fetched Zone 70: Conservatory PIR (Type: Guard; Areas: 1A)
2021-03-08 20:24:34 - INFO: Fetched Zone 71: Kitchen PIR (Type: Guard; Areas: 1A)
2021-03-08 20:24:34 - INFO: Fetched Zone 72: Landing PIR (Type: Guard; Areas: 1A)
2021-03-08 20:24:34 - INFO: Fetched Zone 73: Hall (Type: Guard; Areas: 1A)
2021-03-08 20:24:35 - INFO: Fetched Zone 74: SummerHouse PIR (Type: Guard; Areas: 1A)
2021-03-08 20:24:35 - INFO: Fetched Zone 75: SummerHouse Door (Type: Guard; Areas: 1A)
2021-03-08 20:24:39 - INFO: Fetched Zone 76: Conservatory IPQ (Type: Guard; Areas: 1A)
2021-03-08 20:24:39 - INFO: Fetched Zone 77: Dining Room B/G (Type: Guard; Areas: 1A)
2021-03-08 20:24:39 - INFO: Fetched Zone 78: Cold Water Meter (Type: Guard; Areas: 1B)
2021-03-08 20:24:40 - INFO: Fetched Zone 79: Shoe Cupboard (Type: Guard; Areas: 1B)
2021-03-08 20:24:40 - INFO: Fetched Zone 80: Stair Vibration (Type: Guard; Areas: 1B)
2021-03-08 20:25:26 - INFO: Fetched Zone 129: Smoke Detectors (Type: Fire; Areas: 1A)
2021-03-08 20:25:26 - INFO: Fetched Zone 130: Ensuite PIR (Type: Guard; Areas: 1A)
2021-03-08 20:25:27 - INFO: Fetched Zone 131: Attic PIR (Type: Guard; Areas: 1A)
2021-03-08 20:25:30 - INFO: Fetched Zone 132: Pond Water Level (Type: Custom; Areas: 1B)
2021-03-08 20:25:40 - INFO: Fetched Zone 153: Downstairs Flush (Type: Guard; Areas: 1B)
2021-03-08 20:25:41 - INFO: Fetched Zone 154: Bathroom Flush (Type: Guard; Areas: 1B)
2021-03-08 20:25:41 - INFO: Fetched Zone 155: Ensuite Flush (Type: Guard; Areas: 1B)
2021-03-08 20:25:41 - INFO: Fetched Zone 156: Heating Boiler (Type: Guard; Areas: 1B)
2021-03-08 20:25:41 - INFO: Fetched Zone 157: GV Video Lost (Type: Guard; Areas: 1B)
2021-03-08 20:25:42 - INFO: Fetched Zone 158: GV Input 2 (Type: Guard; Areas: 1B)
2021-03-08 20:25:42 - INFO: Fetched Zone 159: GV Input 3 (Type: Guard; Areas: 1B)
2021-03-08 20:25:42 - INFO: Fetched Zone 160: RFID Door Lock (Type: Guard; Areas: 1B)
2021-03-08 20:25:43 - INFO: Fetched Zone 161: GV CAM 1 (Type: Guard; Areas: 1B)
2021-03-08 20:25:43 - INFO: Fetched Zone 162: GV CAM 2 (Type: Guard; Areas: 1B)
2021-03-08 20:25:43 - INFO: Fetched Zone 163: GV CAM 3 (Type: Guard; Areas: 1B)
2021-03-08 20:25:44 - INFO: Fetched Zone 164: GV CAM 4 (Type: Guard; Areas: 1B)
2021-03-08 20:25:44 - INFO: Fetched Zone 165: GV CAM 5 (Type: Guard; Areas: 1B)
2021-03-08 20:25:44 - INFO: Fetched Zone 166: GV CAM 6 (Type: Guard; Areas: 1B)
2021-03-08 20:25:44 - INFO: Fetched Zone 167: GV CAM 7 (Type: Guard; Areas: 1B)
2021-03-08 20:25:45 - INFO: Fetched Zone 168: GV CAM 8 (Type: Guard; Areas: 1B)
2021-03-08 20:25:45 - INFO: Fetched Zone 169: GV CAM 9 (Type: Guard; Areas: 1B)
2021-03-08 20:25:45 - INFO: Fetched Zone 170: GV CAM 10 (Type: Guard; Areas: 1B)
2021-03-08 20:25:46 - INFO: Fetched Zone 171: GV CAM 11 (Type: Guard; Areas: 1B)
2021-03-08 20:25:46 - INFO: Fetched Zone 172: GV CAM 12 (Type: Guard; Areas: 1B)
2021-03-08 20:25:46 - INFO: Fetched Zone 173: GV CAM 13 (Type: Guard; Areas: 1B)
2021-03-08 20:25:47 - INFO: Fetched Zone 174: GV CAM 14 (Type: Guard; Areas: 1B)
2021-03-08 20:25:47 - INFO: Fetched Zone 175: GV CAM 15 (Type: Guard; Areas: 1B)
2021-03-08 20:25:47 - INFO: Fetched Zone 176: GV CAM 16 (Type: Guard; Areas: 1B)
2021-03-08 20:25:47 - INFO: Fetched Zone 177: Hot Water Meter (Type: Guard; Areas: 1B)
2021-03-08 20:25:48 - INFO: Fetched Zone 178: Gas Meter (Type: Guard; Areas: 1B)
2021-03-08 20:25:48 - INFO: Fetched Zone 179: Water Alarm (Type: 24Hr Audible; Areas: 1A)
2021-03-08 20:25:48 - INFO: Fetched Zone 180: Header Tank Lvl (Type: Guard; Areas: 1B)
2021-03-08 20:25:49 - INFO: Fetched Zone 181: Cld Wtr Tank Lvl (Type: Guard; Areas: 1B)
2021-03-08 20:25:49 - INFO: Fetched Zone 182: GV CAM 17 (Type: Guard; Areas: 1B)
2021-03-08 20:25:49 - INFO: Fetched Zone 183: GV CAM 18 (Type: Guard; Areas: 1B)
2021-03-08 20:25:50 - INFO: Fetched Zone 184: GV CAM 19 (Type: Guard; Areas: 1B)
2021-03-08 20:26:02 - INFO: Fetched Zone 201: Office PIR (Type: Guard; Areas: 1A)
2021-03-08 20:26:02 - INFO: Fetched Zone 202: Cinema PIR (Type: Guard; Areas: 1A)
2021-03-08 20:26:02 - INFO: Fetched Zone 203: Garage PIR (Type: Guard; Areas: 1A)
2021-03-08 20:26:06 - INFO: Fetched Zone 204: Andy’s Bedroom (Type: Guard; Areas: 1A)
2021-03-08 20:26:06 - INFO: Fetched Zone 205: Bathroom PIR (Type: Guard; Areas: 1A)
2021-03-08 20:26:07 - INFO: Fetched Zone 206: Master Bedroom (Type: Guard; Areas: 1A)
2021-03-08 20:26:07 - INFO: Fetched Zone 207: Sarah’s Bedroom (Type: Guard; Areas: 1A)
2021-03-08 20:26:07 - INFO: Fetched Zone 208: Down Toilet PIR (Type: Guard; Areas: 1A)
2021-03-08 20:26:08 - INFO: Fetched Zone 209: Utility Room CO (Type: 24Hr Gas; Areas: 1A)
2021-03-08 20:26:08 - INFO: Fetched Zone 210: Utility Room PIR (Type: Guard; Areas: 1A)
2021-03-08 20:26:08 - INFO: Fetched Zone 211: Workshop PIR (Type: Guard; Areas: 1A)
2021-03-08 20:26:08 - INFO: Fetched Zone 212: Breakfast Rm PIR (Type: Guard; Areas: 1A)
2021-03-08 20:26:09 - INFO: Fetched Zone 213: Garage Door (Type: Guard; Areas: 1A)
2021-03-08 20:26:09 - INFO: Fetched Zone 214: Shed Door (Type: Guard; Areas: 1A)
2021-03-08 20:26:39 - ERROR: Unhandled rejection - RangeError [ERR_OUT_OF_RANGE]: The value of “offset” is out of range. It must be >= 0 and <= 0. Received 8
Hope that is of some help…it never progresses beyond zone 214, of of interest is Network 4, Expander 3, zone 6 - same error each time.
Regarding concurrent connections, I posted a solution for providing access to multiple COM ports over WiFi, using an ESP32: Texecom Alarm panel.
This lets you have a variety of software (Wintex, Android App, etc) connecting on one COM port, as well as the texecom2mqtt integration permanently connected on a different one, without any conflict.
1 Like
hello, new to HA and saw the integration so thought i would give it a go 
i seem to have got it hocked up ok to texecom
but not seeing anything in HA its self, sure i have missed a step
config is
texecom:
host: 192.168.1.55
udl_password: xxxxx
port: 10001
mqtt:
host: 192.168.1.79
port: 1883
username: damon
password: xxxxxxxxx
client_id: texecom2mqtt
keepalive: 30
retain: true
retain_log: false
qos: 2
homeassistant:
discovery: true
prefix: home-assistant
areas:
- id: downstairs
full_arm: armed_away
part_arm_1: armed_home
zones: - id: office_pir
name: Office Motion Sensor
device_class: motion
Here’s my own config, which might help you to work out your own:
texecom:
host: <smartcom IP address>
udl_password: <UDL password>
port: 10001
mqtt:
host: <MQTT broker ip address>
port: 1883
username: <mqtt username>
password: <mqtt password>
client_id: texecom2mqtt
homeassistant:
discovery: true
areas:
- id: house
name: House Alarm
full_arm: armed_away
part_arm_1: armed_night
part_arm_2: armed_home
code_arm_required: true
code_disarm_required: true
code: '<disarm code>'
zones: []
I could then add alarm_control_panel.house_alarm to lovelace and see the alarm set status (for example).
(Tip - when posting config use 3 x backwards ticks - key to the left of the 1 on your keyboard - before and after code to format it properly)
Doesn’t look like any of your clients are connecting to your mqtt broker. Probably something wrong there.
For reference my MQTT looks like the below. You are meant to create HA users, but I don’t I add them locally here.
logins:
- username: '!secret mqtt_nodered_username'
password: '!secret mqtt_nodered_password'
- username: '!secret mqtt_ring_username'
password: '!secret mqtt_ring_password'
- username: '!secret mqtt_zwave_username'
password: '!secret mqtt_zwave_password'
- username: '!secret mqtt_texecom_username'
password: '!secret mqtt_texecom_password'
anonymous: false
customize:
active: false
folder: mosquitto
My T2MQTT looks like this:
texecom:
host: 192.168.1.xxxx
udl_password: 'xxxxxxxx'
mqtt:
host: 'mqtt://192.168.1.xxx'
username: texecom
password: xxxxxxxxxxx
client_id: texecom2mqtt
keepalive: 30
homeassistant:
discovery: true
areas:
- id: house
full_arm: armed_away
part_arm_1: armed_home
zones:
- id: inner_doors
device_class: door
- id: external_bell
device_class: sound
log: debug
Worth you wrapping your config pastes in quotes using the option in the tool panel </>, so it shows as above. It then keeps the indenting so it is easier for others to check it for errors.
got a feeling my issue is related to this
ERROR: Can’t setup Home Assistant service mqtt
which I found this on the forum
Mosquitto Broker error on startup · Issue #1901 · home-assistant/addons · GitHub
as mine is a new install i dont have a snapshot of an early version of mosquitto, is there a was to tell add-on to use a different version?
Hi - I’ve recently setup a HA with RPI and stumbled across this excellent application. Through trial and error (I’m very much a learner) I’ve got the app working to my Texecom Elite 24 running ver 4.00.24. I have a Smartcom for the Tex APP and reused the wifi card as the dedicated access for this Tex2mqtt. I’ve been keeping up to date with the releases with Tex2mqtt and now on ver 1.0.38.
In my logs I have an increasing number of:-
21-03-14 11:54:27 WARNING (MainThread) [supervisor.addons.options] Unknown option ‘Port’ for texecom2mqtt (c15a2434_texecom2mqtt)
21-03-14 12:05:52 WARNING (MainThread) [supervisor.addons.options] Unknown option ‘Port’ for texecom2mqtt (c15a2434_texecom2mqtt)
Should I be worried? Any idea what could cause this? My perception is its increased in frequency with 1.0.38. Also if I look at the Tex2Mqtt log I can now see
INFO: Updating system power… repeating every ~50 seconds, is this a keepalive and just been made visible on the latest version?
Thanks in advance for your help and support.
That would suggest you haven’t configured the add-on correctly (so I’m surprised it work). Either look at one of the configs shown as working above, or post your here (appropriately redacted) so we can comment. I’d guess you have the port parameter set wrong somehow.
Hi
The T2Mqtt works perfectly - I can see all my sensors and can use then to trigger switching on lights etc. An extract from the Texecom2mqtt log:-
2021-03-14 13:05:10 - INFO: dining_kitchen_pir status changed to Active
2021-03-14 13:05:13 - INFO: dining_kitchen_pir status changed to Secure
2021-03-14 13:05:22 - INFO: hall_pir status changed to Secure
2021-03-14 13:05:24 - INFO: dining_kitchen_pir status changed to Active
2021-03-14 13:05:25 - INFO: hall_pir status changed to Active
2021-03-14 13:05:27 - INFO: Front Door Exit status changed to Active
2021-03-14 13:05:27 - INFO: dining_kitchen_pir status changed to Secure
2021-03-14 13:05:33 - INFO: Front Door Exit status changed to Secure
From the system log a periodically get an amber warning the:-
Unknown option ‘Port’ for texecom2mqtt (c15a2434_texecom2mqtt).
From portainer logging:-
2021-03-14 13:05:33 - INFO: Front Door Exit status changed to Active
2021-03-14 13:05:36 - INFO: hall_pir status changed to Secure
2021-03-14 13:05:36 - INFO: Front Door Exit status changed to Secure
2021-03-14 13:05:47 - INFO: Updating system power…
2021-03-14 13:06:37 - INFO: Updating system power…
2021-03-14 13:07:27 - INFO: Updating system power…
2021-03-14 13:08:17 - INFO: Updating system power…
Again, could be my perception but the system log “port” is increasing in frequency and I definitely don’t remember seeing the number of “updating system power…” events.
I’m just wondering if the amber system logs are OK? And if the new “updating system power” are new to ver 1.0.38?
I haven’t tied it down yet but reloading the supervisor and maybe the Tex2Mqtt has an impact to the official Tex V1 APP, in that the alerts are delayed, sometimes by hours. I’ve now started (rightly or wrongly) doing a RESET DIGI from the keypad after reloading Supervisor or the T2Mqtt app, that seems to work best.
Thanks for your help.
It could be it still works but that you have port configured in the wrong place, it will default to 10001 for accessing the alarm anyway. I noticed it updates System Power very often, I’m not sure why, I think Daniel would need to comment on that. To get rid of the port errors, compare your config to know good configs as I suggested above 
That’s correct. It’s meant to be a debug message but I accidentally changed it to INFO in the latest version. I’m pushing a fix now as it does tend to clog up the logs a bit.
It looks like you might have capitalised ‘Port’ in your config.yml?
I highly recommend running texecom2mqtt on a dedicated connection. Each ComIP or SmartCom only allows one connection at a time so if you’re also running the official app, you will have issues.
If the panel doesn’t receive a message at least once a minute it force closes the connection so the app fetches system power periodically to keep the connection alive. It was every 30 seconds but the latest update changes it to 50 seconds and it now doesn’t send the command if another command has been sent (e.g. arm/disarm) so it should send it a lot less.
Thanks for the info. I have found my connection to be unstable with my SmartCom going offline regularly, so I have a permanent ping running against it which seems to have stabilised it. I suspect the issue is do do with my WiFi since a Pi that I have on the same SSID also drops as well. To be honest the connectivity issue went bad when I updated the Smartcom from 2.x to 3.x (which was meant to improve wifi according to the release notes).
Unfortunately I can’t separate connectivity to different devices, my small board can only take the SmartCom. The guy installing it tried to configure up a port to continue using the ComWiFi, but he couldn’t get it to work. I have a Premier Elite 12 if anyone has any bright ideas and thinks I should be able to have both devices enabled.
Hi
I’ve updated to 1.0.39 and as per your notes the “Updating system power” has now stopped. Thank you.
As for the “Port” warning. I’ve checked my config as the only reference is to port is for the panel setup:-
texecom:
host: 192.168.1.xxx
port: 10002
udl_password: ‘xxxxxxxxx’
As you see my port isn’t capitalised and I’ve chosen to use 10002, keeping it away from the Texecom standard 10001 as deployed on their solutions.
I noticed when I loaded 1.0.39 and the addon restarts (I also restarted the supervisor) I get 2 x the “Port” events. I restarted at approx. 16:09, then at 16:22 and 16:36 I recorded the following amber alerts on the supervisor:-
21-03-14 16:22:24 WARNING (MainThread) [supervisor.addons.options] Unknown option ‘Port’ for texecom2mqtt (c15a2434_texecom2mqtt)
21-03-14 16:36:51 WARNING (MainThread) [supervisor.addons.options] Unknown option ‘Port’ for texecom2mqtt (c15a2434_texecom2mqtt
Does this suggest the App is restarting? The app logs have wrapped so I can’t see if there is a restart taking place. I think I’ll disable watchdog and see if the app stops and report back if OK?
It will be whenever the add-on restarts. It would be worth you posting your full config using the preformatted text option in the toolbar basically three backquotes either side of your text, so it retains the indentation.
Had an interesting one last night. Home Assistant wouldn’t disarm the alarm - and the following was in the logs:
2021-03-15 00:06:21 - INFO: Kitchen status changed to Active
2021-03-15 00:06:22 - INFO: Kitchen status changed to Secure
2021-03-15 00:06:24 - INFO: Kitchen status changed to Active
2021-03-15 00:06:27 - INFO: Kitchen status changed to Secure
2021-03-15 00:06:31 - INFO: Kitchen status changed to Active
2021-03-15 00:06:32 - INFO: Kitchen status changed to Secure
2021-03-15 00:06:33 - INFO: Kitchen status changed to Active
2021-03-15 00:06:34 - INFO: Kitchen status changed to Secure
2021-03-15 00:06:35 - INFO: Kitchen status changed to Active
2021-03-15 00:09:10 - INFO: Remotely disarming House Alarm
2021-03-15 00:09:10 - WARNING: Could not disarm House Alarm
2021-03-15 00:09:18 - INFO: Remotely disarming House Alarm
2021-03-15 00:09:18 - WARNING: Could not disarm House Alarm
2021-03-15 00:09:32 - INFO: Remotely disarming House Alarm
2021-03-15 00:09:32 - WARNING: Could not disarm House Alarm
2021-03-15 00:10:40 - INFO: Remotely disarming House Alarm
2021-03-15 00:10:40 - WARNING: Could not disarm House Alarm
2021-03-15 00:10:51 - INFO: Remotely disarming House Alarm
2021-03-15 00:10:51 - WARNING: Could not disarm House Alarm
2021-03-15 00:11:02 - INFO: Remotely disarming House Alarm
2021-03-15 00:11:02 - WARNING: Could not disarm House Alarm
I restarted the integration and retried and it worked first time:
2021-03-15 00:14:50 - INFO: Remotely disarming House Alarm
2021-03-15 00:14:50 - INFO: House Alarm status changed to Disarmed
No other errors logged (I assume the integration would log any more serious failures - it seems to do for other stuff) and the integration appeared to be receiving events from the alarm. This is running on a SmartCom dedicated to this integration - I’ve disabled Texecom Connect to avoid conflict and is using the latest (1.0.39) version of the integration.
First time this has happened in the last week or so of testing, but will keep an eye out and will up the logging if it happens again.
Updated to latest Current version: 1.0.39 and after a while all that I am getting in the logs is the system power.
At first I thought the application had frozen as the zone status were not being published / updated.
I then realized It hadn’t crashed as the watchdog was active and it had not restarted.
Only on restart did it start behaving again, this is the second time since updating to 1.0.39
2021-03-15 16:36:02 - DEBUG: Updating system power...
2021-03-15 16:36:02 - DEBUG: Publishing to texecom2mqtt/1184708/power: {"battery_charging_current":9,"battery_voltage":null,"panel_current":540,"panel_voltage":null}
2021-03-15 16:36:52 - DEBUG: Updating system power...
2021-03-15 16:36:52 - DEBUG: Publishing to texecom2mqtt/1184708/power: {"battery_charging_current":9,"battery_voltage":null,"panel_current":540,"panel_voltage":null}
2021-03-15 16:37:42 - DEBUG: Updating system power...
2021-03-15 16:37:42 - DEBUG: Publishing to texecom2mqtt/1184708/power: {"battery_charging_current":9,"battery_voltage":null,"panel_current":540,"panel_voltage":null}