OakTerm help and discussion

[PeterF]

The hosting for the current OakTerm is github - hence the rawgit.com bit (so free and permanent as long as kh and github want it to be!). There is also a short url http://digistu.mp/oakterm which may be better to bookmark if you have concerns of it moving. Or you could just download / clone the Github repo at https://github.com/kh90909/OakTerm/, as it should be a standalone app.

There are two other handy short URLs for the Oak - http://digistu.mp/oakconfig for the configuration app (which you could also download /clone from https://github.com/digistump/OakSoftAP/) and http://digistu.mp/dashboard for the digistump dashboard (source downloadable from https://github.com/digistump/OakDashboard).

[PeterF]

Hey kh, have you noticed anything strange going on with OakTerm lately? Twice today I have logged in (on two different computers in different locations) and when I initially opened it the device drop-down list was empty, and I needed to either refresh the page, or hit the green refresh button on the oakterm screen to populate the list. First time I've seen that happen.

Also (either something I did wrong or maybe related?)... it doesn't seem to be filtering particle messages by device at the moment... When testing the serial upload stuff earlier, I swapped away from and back to an Oak, and then noticed in the output that it was displaying messages from both Oaks??? Do I need to give my web browser a good hosing or is there something goin' on here?

Code: [Select]

[17:43:50] Device change: Oak2
[17:43:51] Device change: Oak4
[17:44:34] Event: spark/status - online
[17:44:43] Event: spark/status - offline
[17:44:44] Event: spark/status - online
[17:44:56] Event: oak/userrom/startup - Blink v0.3 <-- everything till now has been Oak4
[17:45:14] Event: spark/status - online
[17:45:26] Event: ubidots_tempC - 23.31 <-- but this is Oak2, and so probably is the previous line???
[17:46:27] Event: spark/status - offline
[17:51:19] Event: spark/status - offline
[17:51:19] Event: spark/status - online
[17:51:28] Event: spark/status - offline
[17:51:29] Event: spark/status - online
[17:51:41] Event: oak/userrom/startup - Blink v0.3 <-- Oak4 again, and previous 4 messages probably from it also...
[17:55:15] Event: spark/status - online
[17:55:19] Event: ubidots_tempC - 23.31 <-- Oak2 again!!!
[17:56:20] Event: spark/status - offline
[18:05:06] Event: spark/status - online
[18:05:19] Event: ubidots_tempC - 23.31 <-- Oak2 again!!!
[18:06:20] Event: spark/status - offline


[kh]

I used it last night and didn't have this issue or other problems, but I'll take a look again this evening. I was using Chrome 52, so I'll check Firefox too.

Which browser and version were you using?

There shouldn't currently be a way to view events from multiple devices, so I doubt you did anything wrong. Either the browser failed to stop the event subscription when changing devices, or there's something up with the Particle Cloud. If it happens again, take a look at the JavaScript console (F12). OakTerm prints some debugging and error messages there that might give a clue to what's going on.

[PeterF]

It was playing up in the same browser - Chrome, currently Version 52.0.2743.116 m. I just tried Firefox (v48) and it was fine... so I'll try clearing out browser baggage. Edit: I did that - and it seems to be working again in Chrome on my main machine. I cleared out all cookies, cached files, hosted app data, etc. Edit2: Didn't last for long. Incognito mode works fine, so thinking an extension was causing the problem I went and disabled them all, but did didn't do anything for me. I also noticed that  "start_pollers(): Starting pollers." isn't output to the console when OakTerm is misbehaving, so I suppose that has to stuff things up a bit! Looks like I'll use firefox for OakTerm for now.

When the page plays up (loading from http://rawgit.com/kh90909/OakTerm/master/index.html), this is all I see on the console (assuming I just need look at the console tab?) is the below three entries, the device list doesn't list any devices (just "--") and refreshing the page doesn't do anything. List only populates when I click the refresh button on the OakTerm app.

Code: [Select]

The provided value 'ms-stream' is not a valid enum value of type XMLHttpRequestResponseType.
The provided value 'moz-chunked-arraybuffer' is not a valid enum value of type XMLHttpRequestResponseType.
restoring settings: Object {autoscroll: "onEvent", lineends: "\r", scrollbars: "false", show-devadm: "true", show-event: "true"…}


[kh]

I tested again this evening with Chrome and Firefox. Still no problems.

Your console messages look fine. I hadn't seen the ms-stream and moz-chunked errors before, but I get them now too. They originate from the linked Particle JS API code. Most likely, there was some change in Chrome that triggers these, but I suspect they're harmless. If I had to guess, I'd say they're related to testing for or providing compatibility with Internet Explorer (ms) and Firefox (moz).

When OakTerm starts, the device list starts out as --, and then is populated with the results of a Particle API call that gets a list of your registered devices. It might be that this API call is failing for some reason. This is consistent with you not seeing the start_pollers message - the pollers (timers which update the list of devices, variables, functions, etc.) only get started when there is at least one device. But, come to think of it, the list of devices poller should run all the time, in case a device gets added to the account. That should also compensate if the initial API call fails...it will get repeated 10 seconds later. I'll make that change when I get a chance and let's see if that solves your issue in Chrome.

[PeterF]

I wonder if it has anything to do with the rate limiting changes they made a few days ago or some other recent otherwise seemingly benign change? The folks at Particle have been busy fiddling with things since the 1st of August...  there certainly seems to be have been some unexpected instabilities, as there is an unreported build outage (which was documented on the forum), and also some major latency issues. Anyway, since it seems to come and go based on deletion of cache files, etc, I suspect something is still a bit wonky on my end.

[DrJFM]

I have two Oaks running at most times -- not coding much at the moment but am interested in reliability etc.  My recent experience with constant hardware and working sketches suggests that many times when things get in the ozone, it is the Particle cloud that is the culprit.  Obviously, they are also trying to evolve their system, but a couple multi-hour outages do not bode well for critical apps.

To that point and why I am commenting here on Oak Term is to suggest that you consider implementing a rolling counter and a couple buttons.  These would allow us to indicate two choices:
1) My Oak is connecting and maintaining connection as usual. OTA programing works

and

2) My Oak is NOT connecting and maintaining connection as usual. OTA programing fails.

A third control or display could list the resultant counts for   Cloud OK vs Cloud messed up for three time periods??  last 2(3? 4?) hours, Last 8 hours, last 24 hours or such.

I have spent too much time checking and assuring my system(LAN, Oaks etc) is OK when it is the Particle interface/cloud that is messing me up. 

Oak Term would be a great place to log status and alert us to Particle based issues.  If several people are having issues, I will go away since stuff that dies on one day runs fine the next.

If not Oak Term, maybe this tally could be implemented in the forum somehow??

Aug 6 was a big Particle blow out for example....  and yesterday the stuff that is working again today was not connecting/ OTA flashing etc.

Or am I the only one with Particle issues?

James

[emardee]

@ Peter

Yeah. I haven't experienced this problem with my Oaks personally, but I had been wondering if this might be being caused by some sort of "blacklisting" by Particle on a per device basis, (possibly due to rate limits being breached or some other threshold breached?). The reason they might randomly start working again of their own accord might then be due to that blacklisting being dropped / expired.

Basically we're guessing with this... but it might be worth someone with the problem asking the questions in the particle thread, in case it helps them track it down in their logs.

Mike

[PeterF]

@James FWIW, they do have a status page that is supposed to tell you of stability and outages (which you can subscribe to if you want update emails), but from my experience (and their own admissions on the forums) it doesn't catch everything, so occasionally omits downtime events in the logs.

To get more reliable Oaks, I'd firstly make sure the Oaks are in Manual (safe) mode (instead of in Default mode) so they don't auto-reboot into safe mode all on their own-some, and also consider using the SYSTEM_MODE(SEMI_AUTOMATIC) run-time mode in sketches which you want to be less Particle-dependent, as you can then control when the Oak does and doesn't need Particle access.

@Mike I would have through the same, but this isn't device specific, this is just on the first load of OakTerm on Chrome... and it fixes itself every time once you hit the refresh button in the app (in the app, NOT the browser refresh). That plus none of the Oaks are posting data more frequently than 1 event per fives minutes (bar the test unit, but even that one hasn't been an issue), so they have no excuses on why they should be blocked.

[kh]

To that point and why I am commenting here on Oak Term is to suggest that you consider implementing a rolling counter and a couple buttons.

One of the challenges here is that OakTerm doesn't have a direct line to your Oak - everything goes through the Particle Cloud - so it can't tell the difference between your sketch crashing, your Oak losing power (intentionally or unintentionally), or a problem with the Particle Cloud. In most cases, the Particle Cloud API doesn't go down, it just reports the Oak as offline or doesn't pass on any events it generates. Also, OakTerm doesn't communicate with the Arduino IDE, so unless the Particle Cloud indicates an attempt to flash, OakTerm won't know.

So, I think the metrics we could reasonably monitor and display are:

• The number and duration of times the Particle Cloud reports the Oak as offline
• Number and duration of times the Cloud API went down (i.e. OakTerm doesn't get a response from the cloud) [rare, in my experience]
• Number of times the firmware flashing started, but failed [it's also been rare in my experience for flashing to fail after the Particle Cloud reporting it started] 
  

Can't promise anything due to other time constraints, but I'll see what I can do.

Oak Term would be a great place to log status and alert us to Particle based issues.  If several people are having issues, I will go away since stuff that dies on one day runs fine the next.

OakTerm runs entirely in your browser. There's no server-side component, so it would require signficant changes to add one to collect statistics from multiple users. It could be tricky from a privacy perspective too - it would definitely have to be opt-in.