Gateway webinterface becoming unresponive

[J.sim]

issue with the gateway becoming unresponsive when an iButton is badged on an authentication node.

gateway has 2 zones on A1 and A2, 1 x authentication node connected via shielded 2 pair data cable for RS485 connections. all connected devices seem to work fine with no apparent issues. webinterface is working fine and now set to a fixed ipaddress, mqqt server and i can see it connect on the logs of the mosquitto server.

however once i badge a ibutton to the reader on the authentication node - and it seems to be regardless of whether it is armed or disarmed it will cause the web interface to drop out. it is still on the network and i can ping it on its ip address. the fault in the browser is ERR_CONNECTION_REFUSED. it looks like that it timeouts in mqtt at a similar time with the faults

1510419045: Client OHS has exceeded timeout, disconnecting.
1510419045: Socket error on client OHS, disconnecting.

i will confirm the timing of that event.

i can set up a remote access via my onsite pi if that will help.

[vysocan]

This should not happen for sure.

Have you uploaded the firmware without errors? You can try to flash it again. Do you maybe have some strange symbols on web interface? Try to investigate, and also include some screen shoot from debug and web interface. Also can you look if MQTT is reporting group state changes, like:

OHS/[group name]/state pending
OHS/[group name]/state armed_away

Group publish is new function, but authentication works for long long time. Group publish can be disabled in Network tab.

If we cannot find the cause then I can remote access, no problem.

[J.sim]

Ok, so I managed to do the firmware upgrade as per your instructions, bar some stuffing around getting my windows laptop to do the right thing. I had a funny issue to that once I had sent a command with avrdude I was getting the out of sync error till I unplugged the ftdi and then replugged it in. however I finally got it to load with no errors and the output looked identical to your instructions one.

 

There are no strange symbols floating around and whenever I have looked at the web interface I haven’t seen anything unusual. However I keep on getting locked out so I cant look at the debug very easily either.

 

 

From: vysocan [via OHS] [mailto:[hidden email]]
Sent: Monday, 13 November 2017 8:19 PM
To: J.sim <[hidden email]>
Subject: Re: Gateway webinterface becoming unresponive

 

This should not happen for sure.

Have you uploaded the firmware without errors? You can try to flash it again. Do you maybe have some strange symbols on web interface? Try to investigate, and also include some screen shoot from debug and web interface. Also can you look if MQTT is reporting group state changes, like:

OHS/[group name]/state pending
OHS/[group name]/state armed_away

Group publish is new function, but authentication works for long long time. Group publish can be disabled in Network tab.

If we cannot find the cause then I can remote access, no problem.

---

If you reply to this email, your message will be added to the discussion below:

http://ohs.561.n8.nabble.com/Gateway-webinterface-becoming-unresponive-tp26p28.html

To unsubscribe from Gateway webinterface becoming unresponive, click here.
NAML

[J.sim]

Logs from mosquito mqtt server

 

From: vysocan [via OHS] [mailto:[hidden email]]
Sent: Monday, 13 November 2017 8:19 PM
To: J.sim <[hidden email]>
Subject: Re: Gateway webinterface becoming unresponive

 

This should not happen for sure.

Have you uploaded the firmware without errors? You can try to flash it again. Do you maybe have some strange symbols on web interface? Try to investigate, and also include some screen shoot from debug and web interface. Also can you look if MQTT is reporting group state changes, like:

OHS/[group name]/state pending
OHS/[group name]/state armed_away

Group publish is new function, but authentication works for long long time. Group publish can be disabled in Network tab.

If we cannot find the cause then I can remote access, no problem.

---

If you reply to this email, your message will be added to the discussion below:

http://ohs.561.n8.nabble.com/Gateway-webinterface-becoming-unresponive-tp26p28.html

To unsubscribe from Gateway webinterface becoming unresponive, click here.
NAML

[J.sim]

I have gone back to the house and rebooted the gateway. It ran for 10 minutes and I took screens shots of the debug till it refused connections. I was just going back to refresh the log page when it refused the connection.

 

See the screen shots attached. There is a log shot in the middle and you can sse the time it started on the start time shot of the home page. It stopped taking connections at 9 pm.

 

I haven’t figured out the full mqtt thing yet. However I had just enabled mqtt publish when it went on the blink so maybe that had something to do with it.

 

You can see that in a few minutes it times out of the mqtt server as well.

 

Maybe we are best to just reload the firmware???

 

From: vysocan [via OHS] [mailto:[hidden email]]
Sent: Monday, 13 November 2017 8:19 PM
To: J.sim <[hidden email]>
Subject: Re: Gateway webinterface becoming unresponive

 

This should not happen for sure.

Have you uploaded the firmware without errors? You can try to flash it again. Do you maybe have some strange symbols on web interface? Try to investigate, and also include some screen shoot from debug and web interface. Also can you look if MQTT is reporting group state changes, like:

OHS/[group name]/state pending
OHS/[group name]/state armed_away

Group publish is new function, but authentication works for long long time. Group publish can be disabled in Network tab.

If we cannot find the cause then I can remote access, no problem.

---

If you reply to this email, your message will be added to the discussion below:

http://ohs.561.n8.nabble.com/Gateway-webinterface-becoming-unresponive-tp26p28.html

To unsubscribe from Gateway webinterface becoming unresponive, click here.
NAML

[J.sim]

After the gateway was refusing connections I armed the group I had set up with an ibutton on the authentication node. It counted down as per normal I think. After that I walked around to see what would happen.

 

PIRs triggered as I still have the blue lights for walk testing turned on. However there was no beeping a the authentication node to signal an entry. And when I tried to disarm it the node beeps with a green flash but then continues to blink red.

 

From: vysocan [via OHS] [mailto:[hidden email]]
Sent: Monday, 13 November 2017 8:19 PM
To: J.sim <[hidden email]>
Subject: Re: Gateway webinterface becoming unresponive

 

This should not happen for sure.

Have you uploaded the firmware without errors? You can try to flash it again. Do you maybe have some strange symbols on web interface? Try to investigate, and also include some screen shoot from debug and web interface. Also can you look if MQTT is reporting group state changes, like:

OHS/[group name]/state pending
OHS/[group name]/state armed_away

Group publish is new function, but authentication works for long long time. Group publish can be disabled in Network tab.

If we cannot find the cause then I can remote access, no problem.

---

If you reply to this email, your message will be added to the discussion below:

http://ohs.561.n8.nabble.com/Gateway-webinterface-becoming-unresponive-tp26p28.html

To unsubscribe from Gateway webinterface becoming unresponive, click here.
NAML

[vysocan]

MQTT messages can be seen if you run following:

mosquitto_sub -h 10.10.10.127 -t OHS/# -v

10.10.10.127 is IP address of my mosquitto server.

You should see something like this:
OHS/Domek/state pending
OHS/Garaz/state pending
OHS/Domek/state disarmed
OHS/Garaz/state armed_away
OHS/Garaz/Sensor/Kvalita vzduchu/Gas/0 751.20
OHS/Garaz/Sensor/Teplota/Temperature/1  12.20
OHS/Garaz/Sensor/Vlhkost/Humidity/1  51.50
...

As from your comments I do not see reason for such behavior.  Can you try to turn Off all MQTT functions on Network tab?

[vysocan]

Jason,

one thought, can you disable all Alerts on Global tab. It is not visible from pdf if you have them On or Off, especially page take long time to process. Here it looks like you have set On for all page alerts.

[vysocan]

Hello Jason,

I have revised Alerts, just to be sure. I found one typo that arm group was wrongly assigned to auto-arm, but functionality is OK. I tried same Alert setting as you have. All working here. I'm including my new test firmware with some extra debug messages. You can try it, and let me know.

main_board.hex

[J.sim]

Thanks Adam,

 

I ended up defaulting my config by resetting to default on the homepage. I left it like that overnight and it is still working ok this morning. So I have loaded the ntp server address, 2 zones and 1 group. Plus the MQTT server has been set and the publish set to on for all options.

 

It is 7.30am now so will wait and see if it is going at lunchtime and add some more then. Hopefully I can find which section is causing the issue.

 

Weirdly though the names I put on the node are still there? Does this not clear with an eeprom clear?

 

From: vysocan [via OHS] [mailto:[hidden email]]
Sent: Tuesday, 14 November 2017 7:23 AM
To: J.sim <[hidden email]>
Subject: RE: Gateway webinterface becoming unresponive

 

Hello Jason,

I have revised Alters, just to be sure. I found one typo that arm group was wrongly assigned to auto-arm, but functionality is OK. I tried same Alert setting as you have. All working here. I'm including my new test firmware with some extra debug messages. You can try it, and let me know.

main_board.hex

---

If you reply to this email, your message will be added to the discussion below:

http://ohs.561.n8.nabble.com/Gateway-webinterface-becoming-unresponive-tp26p36.html

To unsubscribe from Gateway webinterface becoming unresponive, click here.
NAML

[vysocan]

Hello Jason,

that is normal, node name and its configuration is not stored in gateway, but in node itself. The node name and configuration is send to gateway during "registration", initial packet of node.

[J.sim]

Very interesting. So I have had it going most of the day till about 5.30pm and been fiddling around whenever I got a chance and checked it was still working and reporting via mqtt as well..  At about 6 pm so it had operating for nearly 24hrs no probs, I went back and armed by one of the keys programmed in.

 

However this time it just went offline altogether. And the browser gets the error

ERR_ADDRESS_UNREACHABLE

And if I try to ping it there’s nothing there. Annoyingly my mqtt server is playing up and I cant see the logs on that. There is no new states pushed from OHS though. Only the temperature sensor on the authentication node.

 

So I restarted it and it changed to dhcp – my fault I don’t think I set the ip address again after the default. However the keys I had programmed in earlier are no not there…. I literally used one to disarm the one group I have set up when I walked in because the sensor detected me and the node started beeping. After that disarm I restarted it to get the web interface back. At which stage I had to find the address.

 

I am getting a bit confused as to what is going on now. I did load both tags I have and then I have also only used one at about 6pm to arm it and then again at about 8.30 ish to disarm it. But the log shows various dates – and I had cleared it out last night as well.??  See pics attached.

 

Perhaps I am best to reflash the firmware, and clear the eeprom and start all over to clear all my fiddling out. Then we can be clear as to the state of everything to define where this fault lies.

[vysocan]

Hello,

not sure what is going on. Do you receive emails and SMS when arm/disarm? Do you still have it On or you have disabled it as I asked you? Have you created email account at smtp2go? Do you have SIM card in modem?

About dates in log. If the dates are inconsistent(not ordered by date), it means the gateway was restarted unexpectedly, and it did not had chance to save the log pointer. So it starts from last known pointer.

Similar for all configuration, if you enter new key it resides in RAM only. If you restart it you need to enter it again. To keep the configuration you need to manually press "Save all", in order to store it in EEPROM. Then on next restart it is loaded automatically.

This is done on purpose you can for example click "Reset to default", it will clear RAM configuration. Then you can try some setting. But until you press "Save all" you will loose it on reboot. Also similar function, if you do mistakes in configuration, you can go back to last EEPROM saved state by pressing "Load last".

[J.sim]

Ok. That’s good. I have left all the notifications off now, so I didn’t get any of those. However I do have a sim card in, and the email account is set up. Though to start with I made a password that was too long for OHS to use.

 

Log dates, then the battery is for the eeprom only not an rtc as well?

 

Also thanks for the ti[ on the eeprom saving, I guess that’s in your blog somewhere, but it is little things like this I will include in the manual. And then I can explain the method you mention for working with the settings and how to save them permanently.

[J.sim]

To get a clean slate I might upgrade to the latest version that you have made available there Adam with the fix on auto arming and then clear the eeprom and start again, and I will add all the basic settings, including smtp2go email settings, mqtt server, fixed ip address, my 2 zones on group 1, the authentication node, leave all notifications off, and then try to arm and disarm it.

 

If it becomes unresponsive then what is the best thing to do? Shall I try the onboard reset button first?? And then try a repower if that doesn’t work?

[vysocan]

Yes please try.

Log does not need to be cleaned. Only do "Reset to default"  on Home tab, then do configuration what you need and "Save all". Best is to do configuration step by step, so you know what is causing problem.

Repower is same as onboard reset button, but reset is somehow better :)

Just to say, I have 11 zones, 3 authentication nodes, 23 sensors, Android app to control my relays, and all working without restarts. So I think same should be at your place.

[J.sim]

I absolutely agree with the last line. So there must be some little issue somewhere that is causing it. I think what I said in the last post was the minimum I need to create a group for arm and disarm as that cannot be done from the web interface??

 

Basically the bare minimum to set up before doing any testing. After reflashing firmware of course.

 

From: vysocan [via OHS] [mailto:[hidden email]]
Sent: Wednesday, 15 November 2017 9:04 AM
To: J.sim <[hidden email]>
Subject: RE: Gateway webinterface becoming unresponive

 

Yes please try.

Log does not need to be cleaned. Only do "Reset to default"  on Home tab, then do configuration what you need and "Save all". Best is to do configuration step by step, so you know what is causing problem.

Repower is same as onboard reset button, but reset is somehow better :)

Just to say, I have 11 zones, 3 authentication nodes, 23 sensors, Android app to control my relays, and all working without restarts. So I think same should be at your place.

---

If you reply to this email, your message will be added to the discussion below:

http://ohs.561.n8.nabble.com/Gateway-webinterface-becoming-unresponive-tp26p43.html

To unsubscribe from Gateway webinterface becoming unresponive, click here.
NAML

[vysocan]

Yes, start from bare minimum. 1 group, 2 zones, authentication node. Test and slowly go further.

No authentication cannot be done over web interface.

Just maybe thought, some short on wire? Any fuse( there are 6 orange disks on PCB) is hot/warm?

[vysocan]

Hello Jason,

any news?

[J.sim]

Sorry, been a bit busy to get another shot at it. Considering the trouble I was having with my laptop I am going to set up a raspberry pi with the basics of what I need to reflash it so I can make sure there isn’t anything funny going on there.

 

From: vysocan [via OHS] [mailto:[hidden email]]
Sent: Tuesday, 21 November 2017 7:57 AM
To: J.sim <[hidden email]>
Subject: RE: Gateway webinterface becoming unresponive

 

Hello Jason,

any news?

---

If you reply to this email, your message will be added to the discussion below:

http://ohs.561.n8.nabble.com/Gateway-webinterface-becoming-unresponive-tp26p46.html

To unsubscribe from Gateway webinterface becoming unresponive, click here.
NAML