Strategy Reversal and Irregular Notifications

General support questions and discussions.

Strategy Reversal and Irregular Notifications

Postby cmot » Sat Jan 10, 2015 12:37 am

I have:

Xboard Relay
Sensor at Pins 3
Mydooropener Code - Version 2.4 (latest, with web server status working)
Push notifications via Prowl:
Normally Open Strategy (at present).

Two issues:

1. I have been testing all of this by simply using a wire to short from GND to Sensor Pin 3. When I had the code in the "default" - STATUS_STRATEGY_NORMALLY_CLOSED - the web status and the app status showed GREEN or CLOSED when the short was not connected and RED or OPEN when the short was in place. This seemed to be the opposite of what one would expect. So I changed the code to STATUS_STRATEGY_NORMALLY_OPENED and now when I short the GND to Pin 3 I get GREEN/CLOSED and when I remove the short I get RED/OPEN. So it seems to work, but I worry something is wrong that I am missing. Particularly given the next issue. So what am I missing, or is this behavior what I should expect and normal?

2. I have Prowl notifications "working" in that when I power up the xboard and remove the short, I get a notification saying the door has been opened. Then, if I leave the short off, 10 minutes late I get a notification saying the door has been opened for more than 10 minutes (the value I set). However, I DO NOT get any further notifications if I just ignore the message and leave the short off. Shouldn't it nag me? (if not, could we create a "nag" mode?). More worrisome is that if I "close" the door by connecting the GND-Pin 3 short, the status changes correctly, but when I then remove the short (again status changes correctly) I never get another Prowl message telling me either that the door has been opened or that it is still open. This is analogous to using the physical door switch to open or close the door and not the MDO relay control. In any case, shouldn't any close read - caused by MDO or by a physical switch - reset the open states in the code so that it will notify upon the next open read?

Any help is appreciated. I think I am close, but functionality is greatly reduced if I can't get it to notify me after my initial open cycle!

Thanks, Mike
cmot
 
Posts: 8
Joined: Wed Jan 07, 2015 11:36 pm

Re: Strategy Reversal and Irregular Notifications

Postby support » Sat Jan 10, 2015 10:35 am

Hi Mike,

For item #1, this is normal. Or should I say it's legacy. We haven't re-inverted this so that people that have that setup don't require
to change their config. It's been inverted since day one and this is why we haven't changed it. This shouldn't have any negative side effects.

For item #2, it's normal that it doesn't nag you. It should only report the first WATCHDOG event, until the door closes. What's not normal
is that when the door closes, it doesn't reset and never fires again. Are you reproducing this systematically? To test, reset your Arduino
and try the scenario again. Once the door closes, it should fire again.

Are only WATCHDOG notifications not being fired or are also regular OPEN notifications impacted?
support
Site Admin
 
Posts: 384
Joined: Thu Aug 22, 2013 7:30 pm

Re: Strategy Reversal and Irregular Notifications

Postby cmot » Sat Jan 10, 2015 11:51 am

Thanks for the fast response.

1. Legacy code. Ah! Okay. Might be useful to have a comment in the code mentioning this inversion. People might be puzzled when the default doesn't work, or continue to worry even after moving to the alternate. :-)

2. No further push fires. Yep, I have tried restarting my Xboard many times. Each time, there is one good Door Open notification and one good Door Open watchdog notification 10 minutes later (which is what I set it to). The nothing. I short out the GND and Pin 3 for a bit to simulate the door closed. It shows green in the app and closed in the web browser. Then I remove the short and...nothing. No notifications. This is very consistent. Again, when I remove the short, the app and browser shift to the closed state, then to open state, so the code is getting the state change, but something somewhere is not getting NULL/reset/etc so that the notifications can be sent again. I poked around a bit, but couldn't see where in the code that might be. So no "resets" for notifications post the first one. And it is for both standard open events and watchdog events. Nothing.

Again, thanks for your help.

Best, Mike
cmot
 
Posts: 8
Joined: Wed Jan 07, 2015 11:36 pm

Re: Strategy Reversal and Irregular Notifications

Postby cmot » Sat Jan 10, 2015 2:30 pm

I haven't looked closely at the code or tested this yet, but it looks like the openDetected variable may not get set correctly. It can only be set to true at the end of the two notification handlers. This might be correct, but it seems that it should really be set at the moment the server detects an Open event.

(and once)

mike
cmot
 
Posts: 8
Joined: Wed Jan 07, 2015 11:36 pm

Re: Strategy Reversal and Irregular Notifications

Postby support » Sun Jan 11, 2015 10:31 am

That's strange because nobody else has reported this problem (yet). We use the NOTIFICATIONS_OPEN notification and it's working fine for us. We're not using an X-Board
and we're also not using the NOTIFICATIONS_WATCHDOG_MINUTES notification though.

Can I suggest you try enabling only NOTIFICATIONS_OPEN and see if that works. Then try enabling only NOTIFICATIONS_WATCHDOG_MINUTES and see if that works.

Isolating each notification type individually will help identify which is failing (or both) ...

Thanks,
support
Site Admin
 
Posts: 384
Joined: Thu Aug 22, 2013 7:30 pm

Re: Strategy Reversal and Irregular Notifications

Postby support » Sun Jan 11, 2015 10:38 am

After looking at the code, another question comes to mind ... What do you have on lines #90 and #99 ?

Code: Select all
uint8_t relayPins[] = { 7, 8 }; // select if using DFRobot XBoard Relay

Code: Select all
uint8_t statusPins[] = { 3, 4 }; // select if using DFRobot XBoard Relay

If you're not actually controlling/sensing two devices, edit those lines and remove the unused pins. This could also be
the source to your problem ...
support
Site Admin
 
Posts: 384
Joined: Thu Aug 22, 2013 7:30 pm

Re: Strategy Reversal and Irregular Notifications

Postby cmot » Sun Jan 11, 2015 12:45 pm

Oy. That fixed it. I had left Pin 4 (and Relay Pin 8) open and running. Checking the status of Pin 3 only made it all work. Thanks much. I sort of feel like a "cookbook" here might be useful. I might try. Things like:

- Now look at which Relay and Status Pins you will be using. Make sure to comment out the default code and replace it with only those Pins you are using.

- Many microUSB cables are charge only. In this case your Arduino/Xboard will be powered up, but you will not be able to communicate with it or upload sketches. Make sure you microUSB is data as well as power (FYI, the cable that comes with the Kindle is both power and data).

- The Xboard is now shipped with relay test code already uploaded. This will cause your relays to repeatedly fire once a second as a test. Your Xboard is NOT broken. Simply upload a sketch and this behavior will cease.

etc.

I may work on adding some "nag" code as an option...

best and much thanks, Mike
cmot
 
Posts: 8
Joined: Wed Jan 07, 2015 11:36 pm

Re: Strategy Reversal and Irregular Notifications

Postby support » Mon Jan 12, 2015 8:01 am

Thanks for reporting back Mike. Glad all has worked out for you. Your cookbook idea is a nice one. We might add that to our next documentation.

PS: Please provide feedback on the Apple App Store. Thanks for doing so.
support
Site Admin
 
Posts: 384
Joined: Thu Aug 22, 2013 7:30 pm


Return to Support



cron