Adds a link back to the main page from the Graph and Graph+ pages. Makes the device name (default IotaWatt) a hyperlink. Not sure you saw it or not or what your current plan for PRs is, as there is an even older one there. I saw this issue: #278 and, since I wanted it fixed, I created the PR for it.
I guess I was kind of ignoring that issue, but probably shouldn’t have closed it suggesting a PR. TBH, as someone who has to explain to a growing user base why things work the way they do and not how they think it should work, I hate to go down this road. You might think “What could be simpler?”. The answer is that nothing is simple. Take a look at this StackOverflow “discussion” on the subject:
Everyone has a valid point of view, but the solutions are mutually exclusive. The basic question is do you want to go back or do you want to go forward to the config app? It makes a difference. With the forward to the config app method, if you press your browser back key after returning to the config app, you go to Graph+.
In another scenario, if you linked to Graph+ directly from somewhere else, clicking the “link-back” takes you to the config app rather than where you launched from.
There is support in Graph+ to launch with a specified saved graph in a frame. If imbed isn’t specified, the viewer could click the “back” link and be sent to the config app. If the authorization is “user”, as it should be in a public facing display, that will cause an admin password request. These are the infamous unintended consequences.
So it’s not actually a link-back, it’s a link to the config app. Browsers have clickable back button, and many hotkey the backspace button to “go back”. It is unambiguous.
When it comes to user interface, I’m a minimalist. Less to explain, less to defend, less to go wrong. I asked for it, and it’s not that big a deal, so I’ll merge it, Like arguing with an umpire, it’s not for this call it’s for the next one.
You bring up good points. I did think about them, which is why I didn’t create an actual “back” button. I created an easy way to get to the home page of the iotawatt. Think of this like link at the top of this page that goes (not necessarily back) to the main page of the community. There are times that I wanted it to go back to the store page (http://iotawatt.com/), but as you said, “that’s not the way it works.”
What I really don’t like is that there is not a way to provide a nice link to the status page. That is the page that I want 99.9% of the time, but I always have to click once to get to where I really want to go. I haven’t looked at the code closely, but I suspect it should be possible to have URL parameter that specifies open the status tab (and/or make that the default). You might have reasons that you don’t want to do that. If I really want it badly enough, I can figure out how to do it.
If you are interested, I have influxdb set up with 2.0 and have started looking at what it would take to support it. This looks like it requires building the FW to try out. I don’t have a spared IotaWatt, but I do have several esp8266 based boards that I could use. Do you have an easy way to mock the additional HW?
I haven’t been following the releases. As I recall @tim_influx had said that the OSS version, when released, would provide compatibility with version 1, at least at the write level. Not sure the status of the last entry queries, but that can probably be reworked pretty easily. The big issue was https which is not supposed to be a requirement for the OSS version.
The OSS edition is out and it does NOT require HTTPS. It works just fine with HTTP, which should be okay for a trusted local network. The issue is that it uses a very long token that contains characters that are not allowed for the password.
I expected to alter the authorization. I believe it uses JWT or something similar. The current authorization is BASIC. Should not be a huge problem (with respect to Murphy) but will require that I spend some time to come up to speed.
To help you with that. Here are some pointers. It still uses a post and you can simulate it like this:
curl --request POST "http://localhost:8086/api/v2/write?org=YOUR_ORG&bucket=YOUR_BUCKET&precision=s" \ --header "Authorization: Token YOURAUTHTOKEN" \ --data-raw "mem,host=host1 used_percent=23.43234543 1556896326"
It does allow gzip encoding but is not required. The token appears to be 89 characters long and ends with double equals ‘==’ and contains mixed case alpha numeric with underscore and dash. There might be other characters allowed. I didn’t find a spec on it, but didn’t look for one either.
from a fresh ubuntu 20.04 install, I did the following:
apt-get update apt-get upgrade apt install curl curl https://dl.influxdata.com/influxdb/releases/influxdb-2.0.2_linux_amd64.tar.gz -O
I then followed steps B and C from the devconnected link above.
I did this in an LXC container, but a VM would work fine too, or a physical device.
I am currently using the 1.8 version which also supports Flux queries and works as is with IotaWatt.
I’d love to be able to gzip but there is no codex for esp and would require a lot of heap.
The token is probably 64 bytes and what you see is base64 encoding. That’s easy. IoTaWatt has a function for that.
The actual measurement line looks the same.
The big issue is the query used to determine where measurements leave off for seamless restarts. @tim_influx said it’s implemented differently now and I need to guess the lower bound for the query. That’s not a big problem, but will require additional queries for a big gap. Also, I think the query format is changed.
You are probably correct about the encoding, but that is what is provided by the influxdb UI, so IotaWatt just needs to be able to accept it from the UI.
This is a flux query that works:
from(bucket: "iotawatt/autogen") |> range(start: -100y) |> filter(fn: (r) => r._measurement == "iotawatt" and r.channel == "MainA" ) |> last()
I don’t have a lot of data in there yet, but the query is quick right now. I suspect that it will stay quick even with a years worth of data in there. Since this check is only done when the service starts up, it will probably be okay.
There is a VS Code plugin for Influxdb that makes it really easy to try out flux queries, much better that the influx cmdline implementation.
With 5 second intervals, a year is 6.3 million entries. So maybe slow down a little?
Well, once per measurement. I used to just look for the latest entry associated with the first tag, but that was problematic, so switched to querying each measurement. Not 100% on flux, but it looks like your two IoTaWatt demo uses measurements in the same bucket, so discrete queries should be needed to insure one IoTaWatt doesn’t restart after the last post of another.
That said, once one measurement yields a last value, the remaining searches can begin there.
I think I would be conservative and use a short look-back window of maybe a day. If that returns nothing, then I might go back a week or a month, etc. I also know the start date of current log, which would be the earliest practical start.
So now step away from straight conversion, and take a minute to imagine what, if anything, version 2 would enable that is not covered by the version 1 service.
To be clear, I haven’t found anything that Flux in 1.8 can’t do, yet. I hear they are/might be different versions and the newer version (in 2.0) has support for real months (as opposed to using 30 day intervals).
The big thing I wanted was the ability to aggregate the usage across legs/phases. Since I have two IotaWatt devices, I decided to have one measure one leg A and the other measure leg B. Because I have a lot of infrequent usage of high power devices, I needed more than 14 channels. Even with 28, I don’t have enough for everything. I had noticed that the legs were not the same voltage at various points in time. Now that I have measurements for over a year, I can say that they differ by varying amounts, but that is highly correlated with the difference in load on each leg. Which is what you had predicted. I am going to see if I can do math on the two voltages to see the difference and then compare that to the two currents. That might give a decent indication of the impedance of the neutral line to the transformer.