Closed cliffjao closed 3 years ago
I watched the logs as I loaded zmNinja on my phone and saw the following that looks suspicious:
CONSOLE DBG-2:2020-10-24,19:20:50 PARENT: ---------->onConnect START<--------------
CONSOLE DBG-1:2020-10-24,19:20:50 PARENT: got a websocket connection from 192.168.1.1 (2) active connections
CONSOLE DBG-2:2020-10-24,19:20:50 PARENT: ---------->onConnect STOP<--------------
CONSOLE DBG-2:2020-10-24,19:20:50 PARENT: ---------->onConnect:handshake START<--------------
CONSOLE DBG-1:2020-10-24,19:20:50 PARENT: Websockets: New Connection Handshake requested from 192.168.1.1:46334 state=pending auth, id=1603592450.41553
CONSOLE DBG-2:2020-10-24,19:20:50 PARENT: ---------->onConnect:handshake END<--------------
CONSOLE DBG-2:2020-10-24,19:20:50 PARENT: ---------->onConnect msg START<--------------
CONSOLE DBG-2:2020-10-24,19:20:50 PARENT: Comparing using bcrypt $2a$10$qKn.d9Qc1cdXAX0x0fwvVOmtapWfuhzxu/hnJNyoNa4Kqk2Bq.dgS to $2a$10$qKn.d9Qc1cdXAX0x0fwvVOmtapWfuhzxu/hnJNyoNa4Kqk2Bq.dgS
CONSOLE INF:2020-10-24,19:20:50 PARENT: Correct authentication provided by 192.168.1.1
CONSOLE DBG-2:2020-10-24,19:20:50 PARENT: ---------->onConnect msg STOP<--------------
CONSOLE DBG-2:2020-10-24,19:20:50 PARENT: ---------->onConnect msg START<--------------
CONSOLE DBG-2:2020-10-24,19:20:50 PARENT: JOB: token matched but connection did not
CONSOLE DBG-1:2020-10-24,19:20:50 PARENT: JOB: Duplicate token found: marking ...HAUpkTFk_G to be deleted
CONSOLE DBG-2:2020-10-24,19:20:50 PARENT: JOB: connection matched but token did not. first registration?
CONSOLE DBG-1:2020-10-24,19:20:50 PARENT: JOB: Storing token ...HAUpkTFk_G,monlist:-1,intlist:-1,pushstate:enabled
CONSOLE DBG-2:2020-10-24,19:20:50 PARENT: SaveTokens called with:monlist=-1, intlist=-1, platform=android, push=enabled
CONSOLE DBG-2:2020-10-24,19:20:50 PARENT: ---------->onConnect msg STOP<--------------
As best I can tell, it works initially but at some point onConnect happens and the monlist gets nuked. This explains why I thought it was originally fixed.
Could you try with the latest master and post logs?
So far so good after a few hours, but I haven't seen the onConnect function run yet either. I'm not sure what causes that to happen. I'll keep this running with logs for a day or so and report back.
I think it happens if you start zmNinja.
That doesn't seem to be the case every time for some reason. I've tried Force Stop and then starting zmNinja, and I've also rebooted my phone and then starting. Both didn't trigger onConnect.
onConnect triggers every time zmNinja makes a websocket connection to the ES (when it first starts). If you are not seeing onConnect in ES when zmNinja first starts, zmNinja can't reach the ES via port 9000 or the ES is disabled in zmN
Interesting. For some reason, zmeventnotification.pl from master doesn't actually listen on port 9000 despite no error messages suggesting otherwise:
CONSOLE DBG-2:2020-10-25,11:43:36 PARENT: About to start listening to socket
CONSOLE INF:2020-10-25,11:43:36 PARENT: Secure WS(WSS) is enabled...
10/25/20 11:43:36.909780 zmeventnotification[1077].INF [main:968] [PARENT: Secure WS(WSS) is enabled...]
CONSOLE INF:2020-10-25,11:43:36 PARENT: Web Socket Event Server listening on port 9000
10/25/20 11:43:36.911392 zmeventnotification[1077].INF [main:968] [PARENT: Web Socket Event Server listening on port 9000]
CONSOLE DBG-2:2020-10-25,11:43:37 PARENT: ---------->Tick START<--------------
CONSOLE DBG-2:2020-10-25,11:43:37 PARENT: There are 0 active child forks...
CONSOLE DBG-2:2020-10-25,11:43:37 PARENT: checkEvents() new events found=0
CONSOLE DBG-2:2020-10-25,11:43:37 PARENT: There are 0 new Events to process
CONSOLE DBG-2:2020-10-25,11:43:37 PARENT: ---------->Tick END<--------------
cjao@cjao-mbp ~ % telnet eagle 9000
Trying 192.168.1.190...
telnet: connect to address 192.168.1.190: Connection refused
telnet: Unable to connect to remote host
Running the original zmeventnotification.pl from dlandon/zoneminder docker container (6.0.5) results in port 9000 opening fine:
cjao@cjao-mbp ~ % telnet eagle 9000
Trying 192.168.1.190...
Connected to eagle.cliffjao.com.
Escape character is '^]'.
Yes, master does listen on 9000. I am running it. You probably have other processes listening on 9000, or have configured a different port in your master zmeventnotification.ini
This change on zmeventnotification.pl seems to make the difference for me:
107c107
< DEFAULT_ADDRESS => '0.0.0.0',
---
> DEFAULT_ADDRESS => '[::]',
With this change, it connects and results in the following:
CONSOLE DBG-2:2020-10-25,12:22:43 PARENT: ---------->onConnect START<--------------
CONSOLE DBG-1:2020-10-25,12:22:43 PARENT: got a websocket connection from 192.168.1.1 (2) active connections
CONSOLE DBG-2:2020-10-25,12:22:43 PARENT: ---------->onConnect STOP<--------------
CONSOLE DBG-2:2020-10-25,12:22:43 PARENT: ---------->onConnect:handshake START<--------------
CONSOLE DBG-1:2020-10-25,12:22:43 PARENT: Websockets: New Connection Handshake requested from 192.168.1.1:37014 state=pending auth, id=1603653763.03107
CONSOLE DBG-2:2020-10-25,12:22:43 PARENT: ---------->onConnect:handshake END<--------------
CONSOLE DBG-2:2020-10-25,12:22:43 PARENT: ---------->onConnect msg START<--------------
CONSOLE DBG-2:2020-10-25,12:22:43 PARENT: Comparing using bcrypt
CONSOLE INF:2020-10-25,12:22:43 PARENT: Correct authentication provided by 192.168.1.1
10/25/20 12:22:43.130452 zmeventnotification[1532].INF [main:972] [PARENT: Correct authentication provided by 192.168.1.1]
CONSOLE DBG-2:2020-10-25,12:22:43 PARENT: ---------->onConnect msg STOP<--------------
CONSOLE DBG-2:2020-10-25,12:22:43 PARENT: ---------->onConnect msg START<--------------
CONSOLE DBG-2:2020-10-25,12:22:43 PARENT: JOB: new token matched existing token: (HAUpkTFk_G <==> HAUpkTFk_G) but connection did not (192.168.1.1:37014 <==> undefined)
CONSOLE DBG-1:2020-10-25,12:22:43 PARENT: JOB: Duplicate token found: marking ...HAUpkTFk_G to be deleted
CONSOLE DBG-2:2020-10-25,12:22:43 PARENT: JOB: connection matched (192.168.1.1:37014 <==> 192.168.1.1:37014) but token did not (HAUpkTFk_G <==> ). first registration?
CONSOLE DBG-1:2020-10-25,12:22:43 PARENT: JOB: Storing token ...HAUpkTFk_G,monlist:3,4,5,6,7,intlist:0,0,0,0,0,pushstate:enabled
CONSOLE DBG-2:2020-10-25,12:22:43 PARENT: SaveTokens called with:monlist=3,4,5,6,7, intlist=0,0,0,0,0, platform=android, push=enabled
CONSOLE DBG-2:2020-10-25,12:22:43 PARENT: ---------->onConnect msg STOP<--------------
You can change the ip in the config instead of code. https://github.com/pliablepixels/zmeventnotification/blob/59f2368a8e910a201fcb5eed77ce9f55fd92f110/zmeventnotification.ini#L42
The logs look good to me.
And after that onConnect, here's some output from the monitor I was having problems with:
CONSOLE DBG-2:2020-10-25,12:31:20 |----> FORK:Street (8), eid:74261 rules: Checking rules for alarm caused by eid:74261, monitor:8, at: Sun Oct 25 12:31:20 2020 with cause:[a] detected:dog:71
% Motion Street
CONSOLE DBG-1:2020-10-25,12:31:20 |----> FORK:Street (8), eid:74261 rules: No rules found for Monitor, allowing:8
CONSOLE DBG-1:2020-10-25,12:31:20 |----> FORK:Street (8), eid:74261 Matching alarm to connection rules...
CONSOLE DBG-1:2020-10-25,12:31:20 |----> FORK:Street (8), eid:74261 Checking alarm conditions for token ending in:...qUKvS8tTMD
CONSOLE DBG-1:2020-10-25,12:31:20 |----> FORK:Street (8), eid:74261 should NOT send alarm as Monitor 8 is excluded
CONSOLE DBG-1:2020-10-25,12:31:20 |----> FORK:Street (8), eid:74261 Checking alarm conditions for token ending in:...HAUpkTFk_G
CONSOLE DBG-1:2020-10-25,12:31:20 |----> FORK:Street (8), eid:74261 should NOT send alarm as Monitor 8 is excluded
CONSOLE INF:2020-10-25,12:31:20 |----> FORK:Street (8), eid:74261 Event 74261 for Monitor 8 has finished
It appears that both of my tokens properly registered as excluded, which is great.
I'll keep this setup running for the rest of the day and report back.
Seems to have been good all day. Thanks for the fix!
I previously reported that this was fixed in https://github.com/pliablepixels/zmeventnotification/issues/321 but it turns out I'm still getting the issue - sorry about that. Attaching some debug logs:
Note that I have 2 devices that both have the same set of monitors selected. Here is my tokens.txt file:
Both have the same monlist that excludes monitor 8. However, relevant lines in debug log above shows that it was excluded for 1 but not the other: