I think there might be an issue with your mapping, I’ve just noticed you posted it before as
homeassistant:
discovery: true
areas:
house_alarm:
mapping:
full_arm: armed_away
part_arm_1: armed_night
part_arm_2: armed_home
I think house_alarm should be area_a in your case?
Is that config underneath homeassistant? It should be:
homeassistant:
discovery: true
areas:
area_a:
mapping:
full_arm: armed_away
part_arm_1: armed_night
part_arm_2: armed_home
My apologies - yes it is, I’ll try posting again
homeassistant:
discovery: true
areas:
area_a:
mapping:
full_arm: armed_away
part_arm_1: armed_night
part_arm_2: armed_home
log: 0
Thanks. Can you try updating to the latest version of the add-on? You might need to remove it and re-add it.
So i was following your instructions my area a is called House Alarm and was following this convention…is that not right
areas:
# This can either be the area number (A = 1, B = 2, etc.) or the name of the area lowercased and with
# spaces replaced by underscores (e.g. Summer House = summer_house)
house:
mapping:
# Required: mapping of Texecom arm types (full_arm, part_arm_1, part_arm_2, part_arm_3) to Home Assistant arm types (armed_away, armed_home, armed_night)
# Omit any which are not relevant
If you’ve called it ‘House Alarm’ on the panel, then the config should be house_alarm.
It is house alarm but you just told me it should be area_a in the config…I’m getting quite confused now
Yes, I have uninstalled and installed again then rebooted. The problem is still there.
I’ll try removing the repository and re-adding it first.
Kind thoughts,
Andrew
That did it! I had uninstalled and reinstalled 3 times since your update this evening but removing the repository and re-adding it before installing a fourth time did the trick.
It also enabled debug messages for the first time.
Thank you for the addon, it fills a big gap for me and you have made it very easy to use.
Kind thoughts,
Andrew
Where does alarm_control_panel.mqtt_alarm come from? Is that one you’ve created yourself?
There should be no need to create a manual alarm. If you want a keypad for the alarm you just need to pass the additional options in the add-on config, e.g.
homeassistant:
areas:
house_alarm:
options:
code: 1234
code_arm_required: true
code_disarm_required: true
Whilst I haven’t got my panel firmware upgraded yet to install the smartcom, I am eternally grateful for folks such as yourself doing this development for ‘tinkerers’ such as myself. I’m fully aware i’m on the bleeding edge of my technical knowledge so am relying on those with more. This will suddenly open up a window into the the whole state of my house from the sensors already installed! It’s motivated me to get cracking and get the hardware sorted.
Thank you 
Right I see the logic now…had a real battle with mqtt discovery as well…but its all a learning curve…Thank you ever so much for your help…got there in the end…
You need a thankyou page to buy you a beer or a coffee !!
@dchesterton
This is awesome! It’s made everything I’ve wrote obsolete. It’s great that it’s possible to do so without needing dedicated hardware to read the serial data. Thanks.
@dchesterton is there anyway to implement the code in the texecom2mqtt configuration so that !secret works. I am having a problem with hiding sensitive data for the following fields. Or is there a better way to do it ?
mqtt:
host: 'mqtt://192.168.0.50:1883'
username: !secret mqtt_username
password: !secret mqtt_password
and
homeassistant:
discovery: true
areas:
house_alarm:
mapping:
full_arm: armed_away
part_arm_1: armed_night
part_arm_2: armed_home
options:
code: !secret alarm_code
code_arm_required: true
code_disarm_required: true
I think it should work automatically if you enclose the secret in single quotes. e.g.
mqtt:
host: 'mqtt://192.168.0.50:1883'
username: '!secret mqtt_username'
password: '!secret mqtt_password'
I did try that combination but this is the log code in texecom2mqtt
2020-09-15 13:16:49 - INFO: Connected to alarm, sleeping for 0.5 seconds…
2020-09-15 13:16:50 - INFO: Connection ready
2020-09-15 13:16:52 - ERROR: Unhandled rejection - Error: Could not fetch serial number
and now I have this error trying to restart the add on. I have rebooted HA and still the same.
## Failed to start addon
403 Client Error: Forbidden ("endpoint with name addon_c15a2434_texecom2mqtt already exists in network hassio")
I have tried to uninstall TEXECOM2MQTT and reinstall it but I still have the same error.
update I have restarted the OS and it appears to be a bug in docker. As that has reset it…So no sure what flipped it over the edge, it must have been something to do with me changing the variables to get !secret working and it didn’t like it
Hi @MarkB1 ,
I’ve just had my panel updated (Elite 24 firmware 5.02.01, Smartcom v02.02.02 in COM1 and COM2, ComIP in COM3) and interestingly I’m facing the exact same issues as you’ve been having!
INFO: Logging in
DEBUG: Executing command 1
ERROR: Unhandled rejection: RangeError [ERR_INVALID_OPT_VALUE]: The value "NaN" is invalid for option "size"
This is rather annoying as everything “seems” to be set up as per the instructions on the docker hub page:
The only other thing I can think of is an issue with my config.yml:
texecom:
host: 192.168.1.17
udl_password: 1234
mqtt:
host: "mqtt://192.168.1.222:1883"
homeassistant:
discovery: true
zones:
front_door:
name: "Front Door Contact Sensor"
...
areas:
area_a:
mapping:
full_arm: armed_away
part_arm_1: armed_night
part_arm_2: armed_home
log: 0
20-09-17 14:25:32 INFO (SyncWorker_3) > [supervisor.docker.interface] Pull image dchesterton/texecom2mqtt tag latest.
20-09-17 14:25:34 ERROR (SyncWorker_3) [supervisor.docker.interface] Can't install dchesterton/texecom2mqtt:latest -> 404 Client Error: Not Found ("no such image: dchesterton/texecom2mqtt:latest: No such image: dchesterton/texecom2mqtt:latest").
20-09-17 14:25:34 INFO (SyncWorker_3) [supervisor.docker.interface] This error is often caused by not having enough disk space available. Available space in /data is: 49.3 GiB
For this, I’m wondering if you (like me) are using the arm64 image of HASSIO? Looking at the Arch section of the texecom2mqtt-hassio config, this can be either amd64 or armv7. My guess here is that the arm64 HASSIO is identifying at armv8 and therefore not finding the image.
@dchesterton, do you have any further insight to these?
Just wanted to say thanks to @dchesterton.
I have a Premiere Elite 48 and have just bought and installed a Smartcom, which was easy, and then installed the Add-On version of the code. No issues. Remarkably easy.
Did amend the device class in the config as initially it didn’t identify the class of my zones correctly. I.e. my “Porch PIR” wasn’t automatically identified as a motion sensor. I updated the add-on config and rebooted HA, and all was well.
discovery: true
zones:
porch_pir:
device_class: motion
name: Porch Motion Sensor
utility_pir:
device_class: motion
name: Utility Room Motion Sensor
Am running HASS OS on the standard VM image on Virtualbox on a Core i5.
Please add a donate button somewhere and I’ll happily buy you a beer or two.
Pete
I checked and double checked everything in communication options, i deleted the gateway and left everything else as default
Nothing set in ARC.1 / 2 / 3 / 4 or 5
Yes running 64bit with SSD, could not get it to install on with HA supervisor.
I installed it on a standalone PI2 and it works flawlessly.
So in one week I learned some basic Linux, Docker and Portainer and over the moon with the results, you will get there.
Regards,
