self.loop_wait = True

[Fisherijus]

could you please explain what is the reason of this self.loop_wait = True in the loop of checking statuses...? cause with the value set to true, i get check about every 10th second and miss lots of events that where triggered...if i disable this waiting, i receive every event...

[jpbarraca]

We must poll the label periodically otherwise we will get disconnected. Also, some data is only available through the status obtained in that loop. The update interval should be as large as possible. I think some panels support 30s but others require more frequent updates.

What panel are you using?

[Fisherijus]

Evo 192. yesterday i did not spend too much time analyzing the code what was happening behind the scenes in that loop, but noticed that loop interval was ~10-20sec. and if any of my pirs where triggered in between that period i missed that... so, what would your suggestion be to increase the possibility to get most of the events from triggered zones?

[jpbarraca]

That is strange because activity in zones triggers events that are not handled by that loop. Actually, the loop will create issues if it is too frequent.

Can you please debug this?

[Fisherijus]

later when i am home i will play with the code deeper, but when i try to understand what was going on looking at the code i i understand it that way:

if i make self.loop_wait = false this method is not called in the loop self.send_wait(None, timeout=min(time.time() - tstart, 1))

so the only place i see that event can come from is this method panel.handle_status(reply) => self.process_properties_bulk(properties, vars.address)

[Fisherijus]

if i comment this piece of code in the loop

logger.debug("Befor wait")

        # cfg.Listen for events
        #while time.time() - tstart < cfg.KEEP_ALIVE_INTERVAL and self.run == STATE_RUN and self.loop_wait:
            #self.send_wait(None, timeout=min(time.time() - tstart, 1))

everything works fine. with this code not commented i get big delays between zone events and usally even miss them

[jpbarraca]

What connection are you using? Serial, Direct IP, SITE ID?

[Fisherijus]

I donwgraded my ip150 to 1.xx abd now connect via direct ip

[jpbarraca]

You did this because the SITEID was not working, or you just preferred the direct connection?

EDIT: Can you please send a debug log? If you post it here, please use keybase at https://keybase.io/encrypt#jpbarraca

[Fisherijus]

i dont have siteid and yes i preferre direct ip connection.

[yellowonblack]

It is the same reason I'm trying to get zone status update directly from serial port as I'm mostly interested in getting the PIR status in real-time.

IP connection with siteID works quite stable with my IP150 v.4.30 but there is a quite big delay between the moment one zone triggers and the MQTT message is published and sometimes the event is not even published on MQTT topic (because of the 10 seconds delay between two readings). I was planning to downgrade IP150 to 1.xx but if @Fisherijus has the same problem, I think I will hold it for the moment.

[jpbarraca]

We changed the way changes propagate and many things are no longer tied to the status update loop. Which changes are slow to propagate?

[yellowonblack]

The zone status change from open-to-close and reverse, but as I only used it through IP siteID connection might be also the Paradox cloud delay. @Fisherijus mentioned that he downgraded his IP150 in order to use direct connection and he has the same delay issues.

[jpbarraca]

Those changes should be captured through event messages, without delay. I will investigate.

[yozik04]

I have almost 0 delay on EVO192. IP150 module.

[yellowonblack]

Just did a test using IP150 v4.30 with online SiteID account with the setting in pai.conf

MQTT_PUBLISH_RAW_EVENTS = True

Result: I get no messages on paradox/events topic, but only on the paradox/states/# and of course at approx 10 seconds and for short PIR changes no message is sent.

[yozik04]

I have just measured. Around 1.5 seconds from PIR led is lid to MQTT message.

[yozik04]

In asyncio branch less than a second.

[yellowonblack]

I have just measured. Around 1.5 seconds from PIR led is lid to MQTT message.

But you are using the IP150 direct IP connection, right? Or the siteID like me?

[yozik04]

Direct, yes.

[yellowonblack]

That means the delay is caused by Paradox cloud or could be something else?

[yozik04]

I am sure it is Paradox cloud.

[yellowonblack]

Then, the only solutions for me are:

1. Remove the IP150 completely and monitor the serial port with PAI in serial mode
2. Downgrade the IP150 to v1.xx and use it with PAI in IP direct connect mode
3. Use IP150 v4.XX and hook up on Tx + GND pins and use it in a full passive mode if the feature could be added in PAI: https://github.com/jpbarraca/pai/issues/63

I would prefer option 3, as this offers the highest flexibility.

[yozik04]

What do you use from Paradox software that you want to keep V4.XX ?

[yellowonblack]

I have no particular interest in Paradox software, I was looking for the easiest solution to read zones status in real-time but also to be able to arm/disarm partitions remotely and all those without the risk of bricking IP150. So, I will try first option 1 and only then go for option 2.

[yozik04]

Can we close it? We have #63 for passive mode

[yellowonblack]

From my side can be closed.