I saw this a few times and have rolled back to 1.0.36 which, providing the watchdog is running, is very reliable and I’ve not had any issues setting/unsetting with this version
Is there a way to find out why this happens? I’m not getting much from app logs.
Did you try turning on debug logging to see if anything shows up?
yes I have debug enabled and no errors showing up on the supervisor logs… just this in the app log:
2021-04-23 10:03:53 - INFO: Remotely arming Area A to Part Arm 1
2021-04-23 10:03:53 - WARNING: Could not arm Area A
Yeah, not very helpful for fixing your problem, but if you scroll back you’ll see I had exactly the same problem as well. I’m now running 1.0.36 which seems absolutely fine and hasn’t done this on me yet.
I had something similar occur the other night when I went to set the alarm, I’d upgraded to 1.0.40 earlier that day I think.
Previously I’d just rolled back using an HA snapshot and doing a partial restore, however is there another way to install based on the docker tag? Looks like it might be possible with ‘ha addons install’ if a version can be specified?
I see 1.0.36 is still listed, but don’t immediately see a way to specify the tag/version in HA i.e which one it should fetch.
https://hub.docker.com/r/dchesterton/texecom2mqtt/tags?page=1&ordering=last_updated
EDIT: Doesn’t look like it’s possible to specify a version with ‘ha addons install/update’:
Flags:
-h, --help help for update
Global Flags:
--api-token string Home Assistant Supervisor API token
--config string Optional config file (default is $HOME/.homeassistant.yaml)
--endpoint string Endpoint for Home Assistant Supervisor (default is 'supervisor')
--log-level string Log level (defaults to Warn)
--no-progress Disable the progress spinner
--raw-json Output raw JSON from the API
It doesn’t appear to accept ‘-o version=x.x.x’ as you can for HA itself.
EDIT2: Seems not:
Does anyone have a way to manage failed sets with their alarm? I don’t have a physical keypad for my Elite, just Texecom2MQTT and Wintex - so at present, when there is a failed set, I have to go and reset the alarm via Wintex.
Just to add to this, I was slightly incorrect. With just the Smartcom installed I could connect T2MQTT via IP, and Wintex via Smartcom, and use the App. However, the panel wasn’t then sending notifications for logins/etc.
Today I’ve installed a Comport+ which adds Com Port 3 to the panel, set it to ComIP module and connected my old Com Wifi to the Comport+. This now allows me to point T2MQTT at the Com Wifi IP and allow the Smartcom to do everything else. Notifications are now sent out correctly.
Comport+ are about £10 for 5, I now have some spares…
I’ve released a new version 1.0.41 which should fix the recurring issue where the app crashes but doesn’t restart properly.
I’ve also changed the MQTT topic structure to remove the serial number, so where the topic would have been texecom2mqtt/[serial]/zone/... it will now be texecom2mqtt/zone/... This should fix issues some people are having where the app doesn’t find the correct serial number meaning you end up with multiple alarms in Home Assistant.
Unfortunately you will have to manually delete these topics (where ‘12345’ is your serial number):
texecom2mqtt/12345/*homeassistant/binary_sensor/texecom2mqtt-12345/*homeassistant/alarm_control_panel/texecom2mqtt-12345/*
The easiest way is to use an app like MQTT Explorer.
Doesn’t that mean with multiple alarms they’ll get merged ?
Saw a bunch of the below, after upgrading to 1.0.41:
2021-05-16 08:36:12 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform mqtt does not generate unique IDs. ID 1013672.zone.living_room already exists - ignoring binary_sensor.living_room
2021-05-16 08:36:12 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform mqtt does not generate unique IDs. ID 1013672.zone.landing already exists - ignoring binary_sensor.landing
2021-05-16 08:36:12 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform mqtt does not generate unique IDs. ID 1013672.zone.entry_door already exists - ignoring binary_sensor.entry_door
2021-05-16 08:36:12 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform mqtt does not generate unique IDs. ID 1013672.zone.garage already exists - ignoring binary_sensor.garage
2021-05-16 08:36:12 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform mqtt does not generate unique IDs. ID 1013672.zone.garage_door already exists - ignoring binary_sensor.garage_door
Tried trashing the entire MQTT topic, but still they seem to remain - texecom2mqtt log shows it talking to the alarm, just HA not happy with the entities.
UPDATE: Ah, probably need to trash the homeassistant/ MQTT topics, noted above. Although I seem to have caused myself a few other issues, arse. Rolling back for now.
UPDATE 2: Ok, fixed the above, deleted the right MQTT entries, but my ‘alarm_control_panel.area_a’ shows as an ‘Unknown’ state and the only option is ‘Disarm’ in the UI - which shows ‘Remotely disarming Area A’ but the state does not update/correct.
With the latest changes all my entities became unavailable. It appears that the MQTT discovery isn’t working at the moment for the new entities.
Also, rolling back to the previous release did not seem to restore the entities
My bad, didn’t notice the note about delete all the old topics. Would it be possible to add the release notes to wherever Supervisor looks for the changelog?
Thanks again for a great add-on/integration
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