my pleasure. I bumped the version #.
I updated to 0.1.4.6, but arm_away is still sending a disarm message. So there must be something else wrong with it besides the bug that I caught. Iâll keep looking.
@haruny
I think I found it. There are two instances where an assignment operator (=) is being used instead of a comparison operator (==). I submitted another PR.
haha! nice catch.
It works now!
@haruny
So Iâm having another issue. Iâm not getting the correct alarm status from alarm_control_panel. But prior to updating to your version that includes ST, I was getting status correctly. Now it always says disarmed
regardless of the true state.
I think it has something to do with the retain flag being set. Previously, the code had "retain":"true"
and you correctly changed it to "retain":true
. However, this could mean that the retain flag was never being set prior to your change. And when I updated the retain flag was set to true while the alarm was disarmed. Now that value is stuck in my mqtt db and the retained value of disarmed
is always being displayed. Iâm trying to troubleshoot.
Iâm stumped. I still canât figure out why the state is now always displaying âdisarmedâ. This behavior only started within the last day, which was when I last updated prior to this morning.
I just did a fresh pull, flushed mqtt and tested it out. It works alright for me. I also tried disarming via hassio.
All the state
topics need to be "retain":"true"
., all the cmd
topics need to be "retain":"false"
.
Try flushing mqtt by sending ( mosquitto_pub -h <your_mqtt_ip> -t "<your_mqtt_topic>" -r -n
"
Yeah, itâs not the code. I believe for some reason the component is failing to communicate with my mqtt broker. It will send the GET urls to arm and disarm, but nothing else. My zones are not reflected correctly anymore (just closed), and alarm state stays at Unknown now. Iâve gone as far as starting from scratch and renaming the alarm_control_panel and topics (in my config and matching them in the ADT addon) to see if that would force different mqtt database entries, if possible. But no-go.
One thing that you may be able to comment on is that whenever the ADT addon restarts, in the log after displaying the ADT webpage source code and just before displaying Syncing status, I get an error:
::TypeError: Cannot read property '1' of null
2018-7-24 10:16:12 Pulse.Sync: Syncing 88182-74-0
2018-7-24 10:16:17 Pulse.Sync: Syncing 88182-74-0
2018-7-24 10:16:22 Pulse.Sync: Syncing 88182-74-0
Any idea what the error means?
I have a guess where this error is appearing. Do you have couple of lines before this?
I also suggest to create a new username/password for the pulse portal to use with the component. Double logins creates issues for me.
No lines before it. Just the source code to the adt pulse login webpage. Iâll try creating a new login for the component. Thanks.
I havent checked since the update but i know before the update. The arm away would beep the console but would not set it at all.
Also would suggest to add Arm_Stay instant. I was going to start looking into it just havent had time. Just another option to arm.
Also is there a way to change the Status report. Instead of devStatOK to Say Open/Closed? Also i have 2 cameras with ADT⌠any way to add thatâŚ
Another thing i noticed. When you install it on Ubuntu Hassio you get the Http response: unknown during authentication. But on Pi it doesnt happen. Maybe something to look into also.
The code was updated and now âarm awayâ and âarm stayâ work.
Yea i assumed they would now, i will check when i get home.
For the states, i tried using Binary_sensors but it doesnt recognize my settings.
- platform: template
sensors:
sensor.garage_door:
friendly_name: âGarage Doorâ
value_template: >-
â{{ is_state(âsensor.garage_doorâ, âdevStatOKâ) }}â
Closed
â{{ is_state(âsensor.garage_doorâ, âdevStatOpenâ) }}â
Open
Iâm back up and running. I used a different user, maybe that fixed it. But I also commented out all instances of reference to the component and its parts. I fully rebooted my Ubuntu server, then flushed MQTT, then proceeded to re-install the addon with new user, and added needed areas back to config and restarted HA. Not sure what got me back up, but itâs working beautifully.
Thatâs where device_class comes into play. I see that you said that it doesnât work for you above. It doesnât work for sensor, but it should for binary_sensor.
- platform: mqtt
name: "Z1 Entry Doors"
device_class: door
state_topic: "adt/zone/Z1 Entry Doors/state"
payload_on: "devStatOpen"
payload_off: "devStatOK"
value_template: '{{ value_json.status }}'
@Ben_Ellis
Re: Cameras, I donât have cameras so I donât know whatâs available to scrape in the portal.
Anything you can tell me? Maybe take an html copy of the page? (you can place it in https://gist.github.com/)
Happy to try and pull in images etc.
commented out all instances of reference to the component and its parts
which files/lines? you mean in the configuration.yaml?