Custom Component: Crow Runner / Arrowhead AAP 8/16 Alarm IP Module

febalci · November 9, 2020, 7:21am

If the Developer Tab shows the latest condition, it seems like there is no problem with the custom component. The thing is, for whatever reason, your badges stuck with the sensor condition from 3 weeks ago. Which version of HA are you using?

I tried sensors on the badges and it is working fine on my installation (HA v.0.117.4). If you go to your Overview page where the Sensor badges stay; go to three dots on right top corner, select “Edit Dashboard”, then select “Raw Configuration Editor” from the three dots again.

Check your “badges:” part:

views:
  - badges:
      - person.feb
      - person.dib
      - person.dib
      - sun.sun
      - sensor.moon_phases
      - sensor.ev
      - sensor.is
      - binary_sensor.giris_pir

check mine; the last entity is the PIR sensor. Make sure yours reflect an active PIR binary_sensor too. If it is OK, try deleting this sensor line, save it, and go back to edit dashboard and create it again.

Or, create a entity card with all your crow sensors in it. Check if all these sensors reflect the sensor statuses correctly. So that we can understand if the problem is with the badges only or a general problem.

Crumpy10 · November 9, 2020, 11:26am

Hi, Thanks for the info. I am running version 0.116.4 so only a little behind you.

So I restarted HA and all the sensors (badges) appear to be working ok and they are showing a state history which is good.
To be honest I am on the other side of the world to my install at the moment but the family are home and I have remote access, so I can do things and see what happens when they are triggered etc…

Strange that the sensors stopped responding 3 weeks ago… I cant figure out why.

I checked in the RAW editor and I can see my sensors all fine. I will create an entity card and monitor whats going on.
I will let you know if and when they stop responding again.

Thanks for your advice and time, keep safe.

Crumpy10 · November 19, 2020, 5:22am

OK, So an update on my sensors.
@febalci they all seemed to work fine up until about 4 days ago and then the badges stopped updating and the history of each sensor became unavailable.
Not being a code guru, where do I start to figure out whats going on?

Cheers

Simon

febalci · November 19, 2020, 8:15am

Is IP module connected with a LAN cable or wifi via a network bridge? I feel like there is something wrong with the network. When you mean “History of each sensor”, i understand that the under Developer-States part, the binary_sensors of the alarm shows “unavailable” ? You better check the statuses from the Developer-States part always, not on Dashboard-Badge history.

Also, does IP Module have static IP Address or DHCP? (You can check it from AAP IP Module settings page, not from HA).

Also is there anything on HA logs related to this component??

Crumpy10 · November 19, 2020, 8:44am

Thanks for the reply.
The IP module is connected via LAN cable and has static IP address assigned. I get the same feeling about the network but its pretty robust. I use Ubiquiti USG and AP which has been really good since I upgraded.
I mean when I click the sensor badges, it gives me the sensor history and when the sensors detected movement and when they cleared.
I will keep an eye on when they fail next and check from the developer states. I had a quick look at the logs but nothing obvious about the integration. I have restarted HA, so this could have cleared a lot of messages.

Crumpy10 · November 19, 2020, 8:48am

OK, So I just rechecked the logs and found this?

AlarmControlPanel is deprecated, modify CrowIPModuleAlarm to extend AlarmControlPanelEntity
6:16:41 PM – Alarm control panel (WARNING)
SwitchDevice is deprecated, modify CrowIPModuleOutput to extend SwitchEntity
6:16:41 PM – Switch (WARNING)
BinarySensorDevice is deprecated, modify CrowIPModuleBinarySensor to extend BinarySensorEntity
6:16:41 PM – Binary sensor (WARNING)

Any ideas?

febalci · November 19, 2020, 8:58am

I also use Ubiquiti USG and APs. Although i use wifi bridge for IPmodule (non Unifi bridge), it is pretty robust. Did you made the static IP from the USG or the IP Module web settings page? I made it thru IP Module web settings page. The messages in the log should not cause an issue; although it reminds me to correct the deprecated components.

Check out this for Log file backups for HA restarts. So that your log will be backedup automatically during restarts and you will not lose any warnings and errors. Backing up home-assistant.log file on restarts

febalci · November 19, 2020, 9:12am

Corrected the deprecated components to reflect Entity type on github. It should not give any more warnings (I hope…)

Crumpy10 · November 19, 2020, 8:37pm

Yep, good work. All the errors are gone when I rebooted.
Will see what happens next time the sensors fall over.

Crumpy10 · November 20, 2020, 8:44pm

I managed to remote desktop into my install ( I am away from home) and looked at the IP address in the IP module. Thats set correcty as it shows in the UBNT web gui. What I did notice was the gateway was not set for some reason. So I set this and also noticed the DNS wasnt set.
What do you have set in this?

Cheers

febalci · November 21, 2020, 10:52am

That’s my IP module Network Settings:

Crumpy10 · November 21, 2020, 10:50pm

Thanks for this, yes mine looks very similar. Well it does now there is an IP address in the Pri.Gateway.

Time will tell now.

mish · December 3, 2020, 2:28am

Thank you for the great work, I purchased the IP Module for my Arrowhead alarm based on your work here!

One issue, I’ll do some debugging soon, but if I “Arm” and then “Disarm” before arming is complete, it takes a while for “Pending” to disappear in Home Assistant, any thoughts?

febalci · December 3, 2020, 9:42am

Welcome to our tiny Arrowhead Users community @mish

Its been quite some time and i barely remember the contents of this component code (because i am old, lol), but in fact both ‘Arm Away’ and ‘Disarm’ sends the same code ‘KEYS XXX E’. And waits for the acknowledgement from IP module, and then once it gets the ack, it corrects that on the HA.

Would it be possible if you can try that to see the latency is still there; Press ‘Arm Home’ instead of ‘Arm Away’ and then press ‘Disarm’ before arming is complete. Is it the same latency as your problem? ‘Arm Away’ is converted to ‘KEYS XXXX E’ instead of using ‘ARM’ command since one of the users is having a problem but ‘Arm Home’ is still using ‘STAY’ command; i want to make sure the problem is not from sending 2 same ‘KEYS’ commands once in a row.

And unfortunately, i don’t believe i am competent enough to go in detail in debugging, especially on the HA side…

mish · December 3, 2020, 10:25am

Thank you again @febalci for your work here. I purchased this house a few months ago and your work has saved me from having to replace the entire alarm system. Arrowhead should pay you a commission on IPMODULE sales!

It doesn’t matter which method I use to arm, the same issue occurs, I can disarm fine from Home Assistant, but it takes 30-60 seconds for the disarm to be display.

I recorded it on YouTube: https://youtu.be/8f12bMT6Hog

I’ll do some deeper debugging over the weekend. Let me know if you have any tips.

febalci · December 3, 2020, 12:11pm

Yeah, that seems like the component issue, not HA. Will try to find the cause.

febalci · December 3, 2020, 5:40pm

I think a temporary solution would be to change “keep_alive” in configuration.yaml to a lower value. The default 60 in keep_alive is send “STATUS” request to IP Module every 60 seconds. If i remember correctly (I am not sure…) when you send an ARM or STAY request, you get back a valid response either ‘AA’ or ‘SA’ to remind Area A Armed or Area A Stay Armed. This comes instantly. I think the ‘DA’ response that should come as a response to Disarm doesn’t come back since there is no DISARM command, it is simply KEYS XXXX E, than it only sends back ‘OK’ so the component should wait for the next STATUS update.

As summary, when you press Disarm just after a STATUS Update you wait 60 seconds for the next update. If you press it 50 seconds after a STATUS Update then you wait 10 seconds for the update. If you lower that “keep_alive” value to let’s say 15 that means you will wait considerably less for the ‘Pending’ to return to ‘Disarmed’. that will create more traffic but i don’t believe it will create much problems.

Minimum is 15 seconds, i don’t know why i made it that way. Maybe to prevent too much traffic. You can lower it on Line 72 of “init.py”:

vol.Optional(CONF_CROW_KEEPALIVE, default=DEFAULT_KEEPALIVE): vol.All(
             vol.Coerce(int), vol.Range(min=15)
         ),

mish · December 3, 2020, 9:09pm

That’s fantastic. Thanks for the workaround!

So if I understand correctly…

Maybe I can change the code so… (Pseudo code follows as I’m on my phone):

disarm_alarm()
{
   send "KEYS XXXX E"
   sent_disarm_time = (datetime(now))
}

Then change the event code so if it sees a “OK” within maybe one or two seconds of sent_disarm_time it treats it as a disarm OK and sets the state correctly?

febalci · December 3, 2020, 9:56pm

In fact, we have to see what is the response of IP Module. In order to see this, you can make a telnet connection to IP Module to port 5900 (when ha crow component is not working, since ip module allows one connection at a time), then enter those commands in order:

STATUS

KEYS XXXX E(To Arm Away)

KEYS XXXX E(To Disarm)

You might need to put a blank key at the end after E on KEYS, if this doesnt give a proper response.
The response of these commands will make it clear if we are on the right path. If we are, maybe we can solve it in only the parse response section of the code and a global boolean variable.

Or forget telnet and try in configuration.yaml:

logger:
  default: warning
  logs:
    custom_components.crowipmodule: debug
    pycrowipmodule: debug

And press arm then disarm as usual and copy log file and send me.

Crumpy10 · December 4, 2020, 7:15am

Hi Again,
OK @febalci, I have returned home and am more able to sort out the sensor issue I am having.
Again, my badges, with the PIR sensor status have frozen on ‘ON’ (Running Man), and the status in Dev Tools is also ‘ON’.
I checked in the History tab and it appears to have happened at 1.45am, which I then cross referenced in the logs and nothing is in the logs either side of that time for an hour or so.
Any idea where I go from here?
I am going to have a look in my Ubiquiti web gui next to see if anything strange is there.
This is getting really frustrating to find now.

Cheers
Simon

EDIT: I just noticed that if I trigger the sensors they display closed then open again! So reverse of how they should work??? I just logged into the IP module and changed all my settings to the same as yours apart from the IP address, then restarted the module. The sensors now display correctly in HA.
Does this help to pinpoint anything?