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?
I am afraid it will happen again; it is very hard to find the problem. But as i understand, the connection from HA to the IP Module keeps alive but the status is giving reverse results? You can open debug as i mentioned in 2 messages before this; although that will fill up your log file quite a bit (if you are on Raspberry and SD card that will create a problem) until the problem occurs again. But something seems off; since mine and other guys here works without issues (as far as i know). I have like 9 PIRs and 13 magnetic sensors and 2 freewave wireless contacts works without an issue. 3 points are important; Alarm panel, IP module and network connection. Since i assume the alarm panel shows the triggers correctly on its lcd screen, there is nothing wrong with the alarm panel or its configuration. So that leaves us with the IP Module and its network connection. If you have means, please test the network cable in any case. If its OK than the only thing left is the IP Module itself.
If as you said the component connection is working but the messages are reversed; than it is really weird. The component asks every 60 seconds (default) for āSTATUSā both for keeping the connection alive and to check if every entity is displayed correctly in HA. Because especially with PIRs you get the Zone Open messages almost always but sometimes you donāt get back the Zone Closed message; that is a bug with the IP Module. In order to correct this i made this STATUS check every 60 seconds. The response messages are indicated in This file. So whether the IP Module misses a Zone Closed message from PIRs, it should have correct it at the STATUS requests.
Does this happen only on PIRs?
Your PIRās are assigned to the same Zone or different Zones and this problem happens on 1 Zone only or happens on different Zones?
It was easier for me to telnet as Iām still installing Home Assistant and am only testing.
This is weird, any bad commands seem to halt the telnet session for a period of time and with enough bad commands even hangs the module (canāt even ping).
I found this out as on my unit: āKEYS XXXX Eā hangs the unit (note the space between XXXX and E as per your instructions). Without the space it works okay, here is the result:
STATUS
DA
DB
RO
KEYS XXXXE
OKKEYS
EAA
KEYS XXXXE
OKKEYS
I ran through it twice with the same output each time, so this is consistently what it sees.
Sorry my bad,
in KEYS XXXXE there should not be a space; i looked at the code now.
As i suspected,
the first KEYS command returns EAA meaning āArea A Exit Delayā but the second command does not return DA meaning āArea A Disarmedā. The OKKEYS is a headache since while arming this is also the same response.
The change required would most probably have to be handled in crow_base_client.py of pycrowipmodule on github. You see on line 150; this part calls the callback for SIGNAL_UPDATE for Areas:
I am afraid it will happen again; it is very hard to find the problem. But as i understand, the connection from HA to the IP Module keeps alive but the status is giving reverse results?
Correct
(if you are on Raspberry and SD card that will create a problem)
No problem, my HA is running on an old Dell I5
3 points are important; Alarm panel, IP module and network connection. Since i assume the alarm panel shows the triggers correctly on its lcd screen, there is nothing wrong with the alarm panel or its configuration. So that leaves us with the IP Module and its network connection. If you have means, please test the network cable in any case. If its OK than the only thing left is the IP Module itself.
Yep, already checked and double checked all that.
Yes this is happening, it is indeed like HA didnt get the zone cleared message.
No I have one zone of smoke detectors and all the rest are PIRās
All my PIRās are zone doubled. I have 5 PIRās
Thank you for taking the time to write so much in reply. We will get to the bottom of the problem eventually.
So even if IP Module is not sending back Zone Closed message, that should have been corrected in the first STATUS request in a max of 60 seconds.
If it is not corrected there are 2 possibilities:
IP Module is not sending STATUS response right (Which is unlikely unless there is a problem with the hardware or firmware or network)
Connection between IP Module to HA is broken (the component should have been handling this issue)
So, next step of debug is once you have this problem again, restart HA so that it will restart the component itself. After restarting it should have correct all zones within 60 seconds and should go on fine with the new ZO and ZCs. If not, than that problem is definitely with the IP Module or its network connection.
Hi,
So it happened again about 2hrs ago. This time the sensors did not seem to even trigger the reverse action in HA.
I restarted HA and all is fine againā¦
Where next, are we running out of things to check?
EDIT:
So I looked in the supervisor logs and system tab and found this
20-12-06 01:30:31 INFO (MainThread) [supervisor.resolution.check] System checks complete
20-12-06 01:30:31 INFO (MainThread) [supervisor.resolution.evaluate] Starting system evaluation with state CoreState.SETUP
20-12-06 01:30:31 WARNING (MainThread) [supervisor.resolution.evaluations.base] NetworkManager is not correctly configured (more-info: https://www.home-assistant.io/more-info/unsupported/network_manager)
20-12-06 01:30:31 WARNING (MainThread) [supervisor.resolution.evaluations.base] Detected unsupported OS: Ubuntu 18.04.5 LTS (more-info: https://www.home-assistant.io/more-info/unsupported/os)
20-12-06 01:30:31 INFO (MainThread) [supervisor.resolution.evaluate] System evaluation complete
20-12-06 01:30:31 INFO (MainThread) [__main__] Running Supervisor
20-12-06 01:30:31 WARNING (MainThread) [supervisor.core] System running in a unsupported environment!
So I have hopefully corrected this by doing the HA recommended changes in Ubuntu. I have now got rid of the network manager failure. Could this have been the issue?
But I only noticed this because it was preventing me from updating HAā¦ Hmmm
I think this comes with HA 0.118 supervisor; so i donāt expect this to correct anything.
As i understand, the connection between HA and IP Module disconnects for some reason and when that happens all entities reflect the last status they were in, permanently. When you restart HA, the component makes a brand new connection and it is succesful. I thought i put all necessary checks for network disconnection; then the component was supposed to wait and reconnect automatically. And apparently it seems it doesnāt. Since while creating this component (It is my first and only custom component attempt), i based this on a sample component from envisalink integration; i simply copied and changed some parts of the async connection and checks. I am not very hopeful myself, if i can correct that honestly with the knowledge i have on component creation and HA connections. I will try my best but please do not keep your hopes highā¦
Weird thing is, why this happens only on your installation? Something must be off. As i said before, my only hope is that the debug log might give us some tip?
UPDATE: Yeah, looking at the code, now i realized on connection problems the component closes the connection but never retries to connect. Then the only way would be to restart HA. I will try to correct it and send it to you with PM for testing. Please be patient since i need to find some quiet time to concentrate on
Hey no problem, we are all busy. When you get time, see what gives. Its not your full time job to support the component, its a hobby and I couldnt do what you have done.
Iāve been watching the recent developments with interest. A while ago I tried this and I had issue relating to network connection as well; I did post earlier in the thread.
From memory, if the network conenction to the IP module is not available on startup then the entire HA boot process hangs and I did not get a full boot, which caused a lot of troubleshooting. I understand that ideally the network connection should always be up, but for various reasons it might not be and I do not think that should cause the entire HA instance to not boot. Booting an displaying an error message in the logs (and of course component not working) would be much more expected.
I appreciate that this is a custom component and I donāt have enough programming expertise to fix it, so offering this with no expectation! But the networking issues may be related and I am happy to help troubleshoot if required.
Well some sort of good news; i created my perfect debugging media with a docker Home Assistant on my PC, so i do not need to work on the live system or live IP Module anymore. I use PacketSender app to simulate the IP Module also. That means i will be wildy brave on changing the code.
Things to be done:
When connection goes off; change all entities to āunavailableā.
When HA restarts; update all entities just after the connection is established. DONE
Check network disconnects real-time and try reconnects.
ESA to DA waits until STATUS request.
Add the repository to HACS.
I will be at home Thursday to Monday, i will be working on it. Thanks for your patienceā¦
Youāre amazing. I attempted the changes you suggested to get the disarm state to be correct when a user arms and then disarms the alarm but it didnāt work as expected. Iāll keep trying other avenues, let me know if you resolve it with your test platform.
Well either it was easier than i thought, or i am making some big big mistake
So now i need a brave volunteer to try this version; honestly i couldnāt tried it on my live system since there are so many things connected. But the offline debug media tests were succesful. You can find the new version v.0.26 on develop branch of ha_crowipmodule. Honestly the only thing that changed is the version number of pycrowmodule in manifest.json; change 0.25 to 0.26 in manifest.json:
"requirements": [
"pycrowipmodule==0.26"
],
When HA restarts; update all entities just after the connection is established.
On connection_made, the component asks for STATUS immediately so you donāt have to wait for the duration of keep_alive to get all sensor states.
Check network disconnects real-time and try reconnects.
When IP Module closes the connection, the component was was trying every 30 seconds for reconnecting. However when the network connection is gone or the first connection was not available, it was giving error. Now, it tries to reconnect every XX seconds (timeout=XX in configuration.yaml, default 60 seconds). I donāt know what will happen if it tries too many times (Overflow error?) when the connectionis unavailable for a very long time, so i believe you better keep timeout longer.
ESA to DA waits until STATUS request.
Instead of waiting for OKKEYS acknowledge when we press Disarm, i added a STATUS request in Disarm; when we press disarm, it waits for 1 second and sends a STATUS. So according to response of this STATUS, it should correct the Alarm Control Panel in 1 sec. The reason for the wait is that the IP Module will wait for 1 sec to process KEYS command, if that is not enough (Couldnāt try it on live system) i can increase it.
Iāve rushed through some testing (busy myself), but the module still works and youāve fixed both the startup state delay and my issue of the arm/disarm:
Hi All,
So I just changed the 0.25 to 0.26 in that file and restarted HA. It all seems as it should be but my issues arrived after 1 or two days.
Sometimes simple changes make a lot of difference. Thank you.
So the last piece of my setup will be to get Home Assistant to be able to open and close the garage door.
Iāve wired up the ip_module to the correct terminals on the alarm system and executing āRL1ā via telnet opens and closes the door successfully!
Iām not yet familiar with Home Assistant and donāt know how to integrate it, so Iād appreciate ideas?
Since you already have āRL1ā mapped to ārelay_1_onā in pycrowipmodule (and a test bed), it seems the like following modifications would get a lot of the way there:
def relay_1_on(self, relay_type):
"""Public method to activate a relay 1."""
if self._client:
self._client.activate_relay_1(relay_type)
else:
_LOGGER.error(COMMAND_ERR)
def relay_2_on(self, relay_type):
"""Public method to activate a relay 2."""
if self._client:
self._client.activate_relay_2(relay_type)
else:
_LOGGER.error(COMMAND_ERR)
/pycrowipmodule/crow_base_client.py
def activate_relay_1(self, relayType):
"""Public method to activate a relay 1."""
self.send_command('relay_1_on', '')
def activate_relay_2(self, relayType):
"""Public method to activate a relay 2."""
self.send_command('relay_2_on', '')
Iām at a loss to know if Iām on the right track, but thought I should check with you before diving in to this in case itās an easy modification for you to expose ārelay_1_onā to Home Assistant.
@Crumpy10, i guess the only thing left is to enable debug of pycrowipmodule and ha_crowipmodule and see what is going on there; since this very much looks like a disconnection issue and right now i am so clueless whyā¦
Just to understand better, you are talking about the Relays on the IP Board, right? Are they passive relays (Just contact, no power on pins)? Because the outputs of the alarm panel are working in the component already, but i am not so sure about whether they can be passive; they carry 12V power already. Maybe they can be programmed as passive?
EDIT: Maybe āRelay Outā with the jumper setting on alarm panel can be used?? But please do not connect any output from the alarm panel to your garage door since they most possibly carry voltage which may ruin your garage door system. Measure itā¦
Second, as the documentation shows Relay 1 and Relay 2 are used to ābridgeā the power connection to a device such as an ADSL model to restart it in the event of a power failure:
This means it should not naturally carry any voltage, only relay it.
I found this picture that would seem to confirm this:
This shows the relays as supporting up to 1AMP at 30Volts.
This must be a maximum the relay can pass through or it would fry any equipment connected to it.
With the garage door opener wire connected to Relay 1 āNO1ā (Normally Open) and C1, the circuit acts as expected, if I telnet to the IPMODULE and execute āRL1ā, the garage door opens or closes.
All this leads me to believe this is a passive relay.
Iāll test the voltage myself later to confirm if there is a problem, thank you for pointing this out.
Do you have any thoughts on exposing your existing ārelay_1_onā (which triggers the telnet command RL1) to Home Assistant?
