@jokydee, thanks for the testing.
Actually i have never tried arming with the keypad. It is a high probability that i missed some parts on the code regarding that. I will try to fix it.
@jokydee, I just checked v0.27, if you skip the ācodeā in config; it turns to the keypad and the keypad is sending the keys fine. 2 questions though:
- Is your Disarm working with typing the code in the keypad on HA?
- Can you Arm Away with typing the code and pressing enter on Crow Runner keypad?
Because both Disarm and Arm Away sends the same keys you typed in if you didnāt entered code in config.yaml:
KEYS XXXXE/r/n
If the question 2 above is a āNo, you canātā, then i believe you have to check crow alarm settings P4E if your user can āCode can Arm Areaā.
- No, nothing happens when I type in the code on the keypad, both when itās armed or not armed. It doesnāt seem to be working at all.
- I can.
I might try just adding my code to the config and bypassing the keypad altogether.
Something else of note; HA seemed to have lost itās connection with the IP module. I donāt know why it lost connection in the first place, since HA and the IP module were both left running. Of course, once the IP module decides to drop its connection, its game over until itās power cycled. This was only after 12 or so hours of being on. HA did however successfully reconnect after I left it for 4 days of being disconnected (IP module on, but having dropped its connection 4 days earlier), then power cycled the IP module while HA was still running. So HA works well to attempt to retry connecting, but still a mystery as to why the connection was dropped by the IP module in the first place. I might try dropping back to the previous version to see if it happens again, as I never experienced this before in earlier versions, even after running for weeks.
@jokydee, Please excuse me for asking this; but are you pressing Disarm or Arm Away on HA alarm card after you enter the code? Because the way the card working is that you have to press disarm or arm away after you enter the code, like an enter button.
@febalci Thanks for clarifying that - thatās what I was doing wrong. When I type in the code, and then press Disarm or Arm Away it work. I will do some more testing on it, as I still seem to get some slightly unexpected behviour with what gets Armed Away or Stay Armed, but I think I might need to play around with some settings on my alarm panel. I think if I want to independently arm only one Area I might be able to do it with different codes that are assigned with each area, although not sure if itās possible to do that. Does your code utilise the Quick Arm Area A and B commands?
@jokydee, i am afraid i havenāt fully tried Area A and B issue since i am only using Area A. It should work with different codes for arming Area A and B tough but i do not think Quick Arm Area A or B is there in the code since i never bothered to work on Areas.
@febalci No problem. For now I will try using different codes
About the dropping of connection, this morning I noticed the same thing happen on v0.27; the IP module dropped its connection with HA again. HA was on the whole time, so should have been pinging the alarm module, meaning there isnāt a good reason for the IP module to have disconnected. But this is the second time this has happened on v0.27. I skipped a few versions when I changed to v0.27 so Iām not sure if itās to do with v0.27. Is anyone else running v0.27 with connection issues? There is a possibility its something to do with my network, so will keep investigating.
Hi Febalci,
I got the D-LINK cable, could you email me the correct firmware please? Mine is incorrect.
Sounds like a network issue if you ask me; mine is (0.27) working rock stable. But other guys can confirm if it is a problem with the component or not.
@febalci going back earlier in this thread about the 2X5 way crossover cable. After looking a while at your original photo of the loom you made:
Besides the lack of crossover, and besides the cable exiting in a different direction from the diagram; as long as the red wires are in the same location, i.e. on the left side of the key when looking at the key on both sides of the loom - which is what is shown in this photo; I donāt think it should have burned the resistors. Just having TX/RX the wrong way around shouldnāt have burnt anything. I can only guess you changed the cable from what is shown in this picture above, is that correct?
I cut one of the interface and put another one making a crossover also. But the problem was to my idiocy i looked at the picture upside down and the 12v on the pin probably went to the wrong pin and then the smoke came out 
Anyway i changed the whole panel and gave up on this and continue using the D-link cableā¦
Iāve been incredibly busy (arenāt we all!) but Iāve been seeing the same lockup of the IP Module.
When it happens the lights on the IP Module are blinking as expected, but I canāt even ping the module. If youāre technical, it isnāt even presenting an ARP response to the network.
It was crashing randomly, sometimes after a few hours, sometimes a week.
A week (and eight minutes) ago I removed the grey āloomā cable (used for alarm system programming over IP) between the IP Module and main board (leaving the ARR14 keypad bus connection cable).
I have my fingers crossed this has resolved it, time will tell. In some ways I could understand if this custom firmware has issues with the grey LOOM cable for IP programming as that wasnāt the core purpose of this firmware.
I donāt suppose you also have the grey loom cable plugged in? If so that would definitely give credence to the theory that this firmware has issues with the grey LOOM cable (or alternatively the grey LOOM cable is randomly presenting something over TELNET that is unexpected and causes as issue).
@mish I havenāt had the serial cable that you are talking about connected previously.
Remember that it is a feature of the IP Module that if nothing talks to it within a few minutes, it will completely drop off the radar and wonāt be able to be connected to without power cycling it. I read that somewhere in the documentation. At least that is what is the case with mine. Although its weird cos I never noticed this before, but it is certainly true now. In other words, if I update my HA version, it will be down for a few minutes - and that can be enough to lose connection with the IP Module, and once that happens I need to power down the alarm panel, then power it back up.
EDIT: turns out this behaviour is not normal, and was being caused by the IP module being unhappy with something else about my network. My solution was to isolate the IP module on its own VLAN.
May i ask you guys about the values of ākeepalive_intervalā and ātimeoutā in config.yaml? Mine is 60 and 25 respectively.
keepalive_interval: 60
timeout: 20
Interesting that yours is 25 for the timeoutā¦
I grabbed these values from your sample configuration here: https://github.com/febalci/ha_pycrowipmodule/blob/fe3d519ffb8fee9fd02b93f6178ba37f1347b3a1/sample_configuration.yaml
@jokkydee
I donāt think mine stops responding when there is no connection.
Iāll test that next time I have a chance.
Just for reference, here is what the IP Control Interface says
When a new connection is established the automation system should query the Inter-face with a STATUS command which will return the current panel status information. To keep the connection alive the automation system should poll with a STATUS com-mand at least once every minute, if the interface does not receive a message for more than 5 minutes the connection will be terminated. In this manner the connec-tion can be maintained and the automation system can be kept updated on the alarm panels status.
What seems strange is that Iāve noticed recently that this can happen suddenly, not just after 5 minutes. For example, I wanted to play around with the upload download software, so I needed HA to drop itās socket connection (actually since it uses port 5002, and upload/download uses 5001 - maybe this isnāt true and I can connect to both at the same time). Anyway I powered down HA, might have unplugged and plugged in another PC on the network switch, and in less than 30 seconds, I couldnāt talk to the IP Module at all. This has happened various times in different circumstances. It generally seems to happen when other devices are connected or disconnected to the same network as the IP module. And the only way I can talk to it again is a power cycle on the alarm panel.
Wait a second, Iām fairly sure you canāt use the upload download software over IP without the grey LOOM cable connecting the IP MODULE and main boardā¦ Are you sure you donāt have two cables connected to the IP MODULE?
(These two):
keep_alive interval is the number of seconds HA sends a STATUS request to the IP Module. Also IP Module does not allow 2 connections to the same telnet port at the same time.
@mish Sorry let me clarify. Only up until very recently did I add in the serial cable - mine is 2X5, i.e. 10 Way ribbon cable that plugs into where the DLink usually goes. But I was noticing all of this before this was attached.
@febalci keep_alive_interval is 60, timeout is 20
I thought that was the case about two connections at the same time. So the different port number is for some other reason I guess. By the way, just tested out the cable I made - works! 
I can now use the upload/download software over the network. I must say I was a bit scared after your horror story.