Write to Fuel Stream not working

#1

1) Give a description of the problem
The piston triggers, says it’s writing to the fuel stream, but nothing shows up

2) What is the expected behavior?
Emit the wine fridge’s power consumption to a fuel stream

Expected logic:
Emit power usage of the wine fridge power consumption to a fuel stream to be capable of graphing usage over time

3) What is happening/not happening?
The piston runs, but nothing shows in the fuel stream

4) Post a Green Snapshot of the pistonimage

winefridgefuelstream
winefridgefuelstream.png1178×394 64.6 KB

From Fuel Stream (after piston runs)

fuelstream
fuelstream.png1348×72 5.86 KB

5) Attach any logs (From ST IDE and by turning logging level to Full)
12/29/2018, 11:54:03 AM +126ms
+ 1ms ╔Received event [Wine Fridge].power = 4.1 with a delay of 273ms
+142ms ║RunTime Analysis CS > 20ms > PS > 68ms > PE > 53ms > CE
+144ms ║Runtime (36784 bytes) successfully initialized in 68ms (v0.3.109.20181207) (142ms)
+145ms ║╔Execution stage started
+154ms ║║Cancelling statement #3’s schedules…
+176ms ║║Executed virtual command writeToFuelStream (16ms)
+179ms ║╚Execution stage complete. (34ms)
+181ms ╚Event processed successfully (181ms)

#2

I would add a single line of code below line 20… Something like:
Log to console 'Outlet 2's power'

The fuel streams can only handle pure numbers… I suspect there is a w (watts) or v (volts) added to the end of yours. Logging to console will show you exactly what your hub sees.

#3

Thanks for the response. I added a log line and it’s emitting a decimal value, such as 10.75 and 4.17, but no alpha characters.

#4

Well, for what it’s worth, the fuel streams have been unreliable for the past two months. Some of my fuel streams shows the full 7 days worth of data, and some only show a couple of days. (even though they have been running smoothly for the past year)

I suspect there is simply too much data coming in to ady’s server to capture all of it efficiently. For instance, take your example above. This piston could theoretically be writing a new number 10+ times a second. (since power is constantly fluctuating) Ten times a second is nearly a million hits each day! Now imagine if all of us here had a piston coded like this…

My hunch is:
Users have unintentionally created too much spam for the server to handle, and instead of reprogramming their piston to write to the fuel stream less often, they just leave it running constantly in the background… Thereby making the problem even worse.

I hate to say it, but I have stopped relying on fuel streams. :cry:

#5

I totally understand. That was going to be a separate question… Best way to measure usage over time. In my business we batch aggregated metrics to the time series DB every 15 seconds. It’s still a ton of data. I was trying to figure out the best way to push data to the fuel streams efficiently. Polling every minute only gives instantaneous value but missed everything that happened in between. Pushing every time the power is reported could be a ton and maybe not easily graphable as there is no consist time period (I haven’t seen how a fuel steam is captured, so I’m not sure what the data out of it looks like).

Thanks for the effort to help, though. I do really appreciate it! I wonder if there would ever be an option to deploy WebCoRE to one’s own ecosystem… A private EKS with a containered WebCoRE would be really nice.

#6

I think we should focus on sending the rapid fire ‘spam’ data to a local server, so as not to overwhelm ady’s server. I just bought a $39 Raspberry Pi to capture, store, and give me access to all that data… but I haven’t finished setting it up yet.

I suspect I will use something local like Influxdb/grafana. A few examples can be found here.

#7

Yup, totally agree. For now I’ll disable the piston. It’s not helping anything or doing anything as it is :stuck_out_tongue:

#8

My streams stopped working again. Last data for most was March 10th. And the last for 1 was March 8th.

Shame because I used the data to monitor PC temps.

#9

Sometimes the server is down for a day or two, but it’s still up from my end…

temp
temp.jpg678×672 21.4 KB

I would check your logs in the piston that is supposed to be writing to that fuel stream.

#10

Logs are recoding the events but plotting isn’t working.

#11

If (for any reason) a non-number write was attempted (for example, a string or the word null), then the graph will not be visible for that datastream due to corruption.

Usually, after 7 days of 100% numbers, the graph will return to normal.