Unable to Create (or View?) Fuel Streams Over Extended Period in New Instance

[puk]

I just want to preface this with: I did do a search and found various fuel stream problems, some of which sound like mine, but none of which has been active lately. Since mine has been consistent on this instance (see below) for a while, I’m making a new thread. Hope that’s okay!

1) Give a description of the problem
No matter what I do, including just having a piston manually create a stream of 0s, I get the message ‘Sorry, you have no fuel streams yet. Please create one by using the “Write to fuel stream” task.’ This is a new instance, which I first tested several months ago and am trying to follow up on now. I have several streams that should be adding data, and are logging properly. Some have been running continuously for several months. I’ve tried to access the streams at least 3 times over the last few months, and they’ve always been empty.

I heavily automated my old home w/WebCoRE (thanks you so much for an amazingly powerful tool), and had a lot of fuel streams tracking my old house. That instance appears to still be okay; the streams are visible and data is still being added to the few streams whose pistons are still triggering (most are not because the house is rented and the hub is disconnected).

The problem is in a brand new instance for my new house. Both instances are visible in my browser.

Many thanks for any help and hopefully fixing my face.!

2) What is the expected behaviour?
Fuel streams w/data. See above for details.

3) What is happening/not happening?
Fuel streams w/data. See above for details.

4) Post a Green Snapshot of the piston!
I have several, but here’s one that’s been running and logging for quite a while.

5) Attach logs after turning logging level to Full
12/15/2019, 4:26:50 PM +447ms
+2ms ╔Received event [Entryway].illuminance = 16 with a delay of 147ms
+116ms ║RunTime Analysis CS > 23ms > PS > 45ms > PE > 48ms > CE
+118ms ║Runtime (37621 bytes) successfully initialized in 45ms (v0.3.110.20191009) (115ms)
+119ms ║╔Execution stage started
+125ms ║║Comparison (integer) 16 changes = true (1ms)
+126ms ║║Condition #4 evaluated true (3ms)
+127ms ║║Condition group #3 evaluated true (state did not change) (5ms)
+129ms ║║Cancelling statement #1’s schedules…
+165ms ║║Executed virtual command [Entryway].writeToFuelStream (29ms)
+170ms ║║Executed virtual command [Entryway].writeToFuelStream (1ms)
+175ms ║║16
+176ms ║║Executed virtual command [Entryway].log (1ms)
+179ms ║║Condition group #7 evaluated true (state did not change) (0ms)
+180ms ║╚Execution stage complete. (62ms)
+181ms ╚Event processed successfully (181ms)
12/15/2019, 3:26:43 PM +224ms
+1ms ╔Received event [Entryway].illuminance = 68 with a delay of 136ms
+109ms ║RunTime Analysis CS > 21ms > PS > 39ms > PE > 48ms > CE
+111ms ║Runtime (37624 bytes) successfully initialized in 39ms (v0.3.10c.20190522) (109ms)
+112ms ║╔Execution stage started
+119ms ║║Comparison (integer) 68 changes = true (0ms)
+120ms ║║Condition #4 evaluated true (4ms)
+121ms ║║Condition group #3 evaluated true (state did not change) (5ms)
+123ms ║║Cancelling statement #1’s schedules…
+144ms ║║Executed virtual command [Entryway].writeToFuelStream (15ms)
+150ms ║║Executed virtual command [Entryway].writeToFuelStream (1ms)
+157ms ║║68
+159ms ║║Executed virtual command [Entryway].log (1ms)
+162ms ║║Condition group #7 evaluated true (state did not change) (0ms)
+165ms ║╚Execution stage complete. (52ms)
+166ms ╚Event processed successfully (166ms)
12/15/2019, 2:43:28 PM +84ms
+0ms ╔Received event [Entryway].illuminance = 118 with a delay of 145ms
+204ms ║RunTime Analysis CS > 38ms > PS > 123ms > PE > 44ms > CE
+206ms ║Runtime (37629 bytes) successfully initialized in 123ms (v0.3.10c.20190522) (205ms)
+207ms ║╔Execution stage started
+213ms ║║Comparison (integer) 118 changes = true (0ms)
+214ms ║║Cancelling condition #4’s schedules…
+215ms ║║Condition #4 evaluated true (4ms)
+216ms ║║Cancelling condition #3’s schedules…
+217ms ║║Condition group #3 evaluated true (state changed) (6ms)
+219ms ║║Cancelling statement #1’s schedules…
+241ms ║║Executed virtual command [Entryway].writeToFuelStream (16ms)
+246ms ║║Executed virtual command [Entryway].writeToFuelStream (1ms)
+251ms ║║118
+252ms ║║Executed virtual command [Entryway].log (1ms)
+255ms ║║Condition group #7 evaluated true (state did not change) (1ms)
+257ms ║╚Execution stage complete. (50ms)
+258ms ╚Event processed successfully (259ms)

[WCmore]

A few observations… (not sure if any of these will apply to you though)

(1) Fuel Streams are currently working:

(2) Normally, data gathered in one instance is also visible in another instance.

(3) If a dataPoint gathers bogus data (or an error, or null) even one time, then that dataPoint will be corrupt for the next seven days, and be unavailable until then. Once a week has passed, the bad data vanishes, and the stream should start working again. (until another bad data point comes in)

(4) I just tested all three of my instances, and two of them are working (with identical dataPoints), but for the first time, I noticed that my third instance (my newest) is actually showing the same error as you.

For the record, I have never used Fuel Streams in this third instance…

[puk]

Many thanks! Three follow-ups:

1. If you don’t mind contaminating your newest one, could you check what happens if you create a stream? It’s possible that one’s legitimately empty. And no worries if you’d rather not; I still whine to myself about not being able to delete streams, at least as of the last time I really worked with them.

2. A clarification question–if a dataPoint is corrupt, what gets corrupted and becomes unavailable–just that one point, that one stream, the container, or all streams?

3. Finally, how is data from one instance visible in another? I may be misusing or misunderstanding “instances.” For my new place, I created a completely new WebCoRE installation in SmartThings for the new house, and added both on the web dashboard (using “Register Instance”). I can now select which one I want from the top-left of the dashboard, but they appear to be completely separate with no shared data. (Of course, since fuel streams aren’t working, maybe that data would be shared…)

[WCmore]

(1) I already tested this before my last post. Well, to clarify, I created a one line piston in the non-working instance, that sent an integer to a Fuel Stream dataPoint that already exists. (it did not resolve it)

(2) I believe only that single dataPoint is corrupt

(3) From what I have seen in the past, any fuel stream created in one instance should appear exactly the same way in another. Maybe it is tied to the ST account??

[ipaterson]

@ady624, any ideas to see what is going on with fuel streams for this account?

[puk]

FWIW, I’m happy to just create a new instance and see if that fixes it, but I’m also not in any real rush, so I’m happy to take some time and try to track it down/help debug it.