Help in Getting Usage Engine Running

[aesculus]

Need a bit of help.

First I need to verify what the include Plans for winter when it is exactly the same as summer.

Do I just skip it or do I add winter: []
I have the later set right now

Second I am getting a 599 error when trying to access the usage server on the browser

{"Usage Engine Status": "599 Error loading usage engine configuration file (<urllib3.connection.HTTPConnection object at 0x7f2c84f6c450>: Failed to establish a new connection: [Errno 111] Connection refused)."}

[BuongiornoTexas]

Second I am getting a 599 error when trying to access the usage server on the browser
599 Error loading usage engine configuration file

Either the config file is in the wrong place or has a syntax error. You may get more info by checking the docker logs (I say may, as some of the errors thrown by the combo of python, docker and a web service can be pretty opaque - I've done a fair bit to make these more readable, but doubt I've caught everything).

Did you test with the example json file before building your own (the only thing you need to change is the server address)? If this works, the problem is with your input file. If this doesn't work, there is something more complex going on which we'll need to dig into.

First I need to verify what the include Plans for winter when it is exactly the same as summer.
Do I just skip it or do I add winter: []
I have the later set right now

This is possibly the cause of 599. The json needs to be well formed, and if you are missing stuff pwdusage expects, it will fail unceremoniously. From the docs:

Each plan must contain at least one season, and can contain an arbitrary number of seasons.

Seasons are an arbitrary label for breaking your plan into different groups. If you only have one season/grouping, that's all you need. Try deleting the []. Also, check that your json doesn't have any dangling commas at the end of lists or dictionaries (a good language would ignore these, but json is strict),

If you are not having any luck, you can share your config file here - edit out the server ip if needed.

[aesculus]

Thanks for the reply. I dropped back to using the usage.json sample (changing the server ip address) and get exactly the same error. The file is in the tools/usage-service folder and I did get some errors at first using my version that I had fixed.

I am using the default powerwall-extend.yml file where I changed the UID and GID to be the same as my powerwall.yml file.

Here is the log from the container:

INFO: Powerwall-Dashboard usage proxy server [1.0.0] - HTTP Port 9050
INFO: Powerwall-Dashboard usage engine proxy Started
ERROR: Error loading usage engine configuration file.
ERROR: Details: <urllib3.connection.HTTPConnection object at 0x7f3ca2e64790>: Failed to establish a new connection: [Errno 111] Connection refused

I am not sure if this is related to the statement about Open the firewall port, as I am doing this on a local LAN with no firewall.

[BuongiornoTexas]

This error is raised when pwdusage is processing a reload file request triggered from grafana or a webpage:

ERROR: Error loading usage engine configuration file.

Which suggests that the firewall is not the problem and that there is a problem with either the config files and/or the setup.
But the error seems to be related to the http libraries (which I've never seen), which suggests that there is a problem with comms between grafana, pwdusage and influxdb.

So I'm not sure what is happening here. Some random thoughts:

• Is this possibly the QNAP container playing silly buggers again?
• Are you running pwdusage on the same machine as grafana and influx? If not, there might be a firewall problem here? Maybe? The reason I suggest this is that this error is raised on a call to "reload_config", and that will trigger pwdusage to query influxdb.
• The other place this could be raised is by an http send_response passing an "OK/200" message back to the caller. But I'm doubtful of this, as send_response sucessfully returned a 599 in the first version of your file?

I'm sure you have done these steps, but just to fully rule out configuration file issues, for setting up the example file you did the following steps:

• In tools/usage, you copied/renamed example_usage.json to usage_json.
• You edited the usage.json file to set the correct hostname for influxdb, and the correct port (8086 or other if you have changed this).
• You copied pwdusage.extend.yml into the powerwall dashboard folder and renamed to powerwall.extend.yml (note - it is powerwall.extend.yml and not powerwall-extend.yml as you have in your previous comment - dot, not dash).
• You either stopped and restarted the pwdusage container, or did a save and test on the datasource in grafana, or you refreshed the usage_engine web page in your browser (all of these force a reload of the file).

If none of this works, can you please share both config files here?

[aesculus]

So I'm not sure what is happening here. Some random thoughts:

• Is this possibly the QNAP container playing silly buggers again?
  It is possible
• Are you running pwdusage on the same machine as grafana and influx? If not, there might be a firewall problem here? Maybe? The reason I suggest this is that this error is raised on a call to "reload_config", and that will trigger pwdusage to query influxdb.
  Same machine and in same folder structure as Powerwall-Dashboard and loaded at the same time
• The other place this could be raised is by an http send_response passing an "OK/200" message back to the caller. But I'm doubtful of this, as send_response sucessfully returned a 599 in the first version of your file?

I'm sure you have done these steps, but just to fully rule out configuration file issues, for setting up the example file you did the following steps:

• In tools/usage, you copied/renamed example_usage.json to usage_json.
  I hope you mean tools/usage-service, but yes
• You edited the usage.json file to set the correct hostname for influxdb, and the correct port (8086 or other if you have changed this).
  Yes. See attached
• You copied pwdusage.extend.yml into the powerwall dashboard folder and renamed to powerwall.extend.yml (note - it is powerwall.extend.yml and not powerwall-extend.yml as you have in your previous comment - dot, not dash).
  Yes. See attached. Note I changed the format of the port to fit what works in the powerwall.yml file
• You either stopped and restarted the pwdusage container, or did a save and test on the datasource in grafana, or you refreshed the usage_engine web page in your browser (all of these force a reload of the file).
  Yep. Tried them all with the same 599 results.

pwdusage.zip

[BuongiornoTexas]

Hi @aesculus - I've taken the files you sent through, modified the influx_url in the json config and the user info in powerwall.extend.yml and dropped them into my system. At which point pwdusage spat out data as expected.

Given that your config is working fine on my system and I haven't had any similar error reports, I've now got two possible suspects for your issue: First: it may be a QNAP/local system issue. I know you were having problems getting a custom server running on your machine - pwdusage is another python server so may be facing similar problems. As I don't have access to QNAP, I think you are the expert on the ground for testing this.

Second, if it is not QNAP configuration side, then it may be a python/QNAP interaction - unfortunately to debug this, you will need to get into development mode with pwdusage - first of all doing a local python install to see if the problem still exists outside docker - which should also give more useful debugging info (see the docs if you want to try this). If the error appears in this mode, we can try and figure out why QNAP, python and pwdusage aren't getting on. (I also don't know enough about docker to know if the images docker runs emulate the QNAP system or another standard OS - if the latter, then this test may not tell us much.)

If the QNAP config is good and local install works, then my last guess would be a QNAP/docker/python interaction - which I have no idea how to start debugging!

[aesculus]

Thanks for looking into this. I suspect it is something within the QNAP system that is causing this. This is actually quite common since they often have their own versions of programs or are behind releases. For example the default Python is 2.7 and you have to force Python 3, which perhaps is the problem here.

I will poke at this when I have free time and see if I can discover what it might be and perhaps resolve the issues.

[aesculus]

Well trying to get the usage engine running manually I ran into this using pip3 to install pwusage:

Requires-Python >=3.11

At best I can force 3.10 with the QNAP as its standard is 2.7x.

So it looks like I will need to work on getting the python updated or wait another day.

[BuongiornoTexas]

Python is 2.7 and you have to force Python 3, which perhaps is the problem here.

I don't think this would be a problem, as the container could not have been built without python 3 (and pwdusage definitely needs a minimum of 3.11 - I use several features that aren't available at lower versions).

So it looks like I will need to work on getting the python updated or wait another day.

Maybe put a hold on that - I"ve just managed to replicate your error:

ERROR: Error loading usage engine configuration file.
ERROR: Details: <urllib3.connection.HTTPConnection object at 0x7feff129cc90>: Failed to establish a new connection: [Errno 111] Connection refused

I was able to create the error by using an invalid port number (8087) for the influx_url in usage.json. Based on how I have put pwdusage together, this is consistent with the error - I believe the only time an url library should be used is when the configuration file loading process tries to grab some data from the influxdb server (and of course it will be used to get data once everything is working properly). From my limited understanding, the connection is refused because either nothing is listening on port 8087 or 8087 is blocked by the firewall?

Based on this, I'd say that pwdusage is not able to talk to the influxdb server. A couple of simple possible fixes are to check:

• You are using 8086 for your influxdb instance (you may have modified it with the other changes you are doing). This should be specified in your `powerwall.yml' file.
• You are not using https for your setup - if you are, try making the influx_url start with https.

You can also try a loopback ip address: http://127.0.0.1:8086, which may bypass firewall rules?

However, from what you have said already, I don't think either these will apply. At which point, I think you will need to do more digging on why the pwdusage container isn't talking to the influxdb container (which seems very weird given that you have the rest of the stack working, and that absolutely depends on influxdb ...). Maybe there are firewall rules that need to be enabled to allow communication between these two containers, with port 8086 rather than 9050 being the problem?

While it isn't a solution, I think this probably better news than needing to figure out how to get python 3.11 up and running.

[aesculus]

Thank you for the update. Looking at the usage.json I do believe it should be the loopback address of http://127.0.0.1:8086 vs the external address I was using. I had high hopes this would have fixed it.

Unfortunately is still fails the Grafana test.

I did try using the external server IP to try port 9050 and without usage_engine, it complained:

["Invalid page request. ", "Usage engine API URL must be :port/usage_engine.", "Got /."]

So we know the usage server is operating.

[BuongiornoTexas]

@aesculus - Your posts read as if you may be doing two things at once.

Can we put grafana to one side and make sure pwdusage is talking to influxdb properly to first.

From your browser, the error ["Invalid page request. ", "Usage engine API URL must be :port/usage_engine.", "Got /."] will always happen if you use the url http://<pwd server address>:9050. The message is telling you the url is not valid for the service. You should get a more meaningful response if you try:

http://<pwd server address>:9050/usage_engine

If this throws a 599, then take another look at the pwdusage container log (I suspect 127.0.0.1 may have the same problem as the outward facing ip).

[aesculus]

Today I wiped the Powerwall-Dashboard install and started over, this time using Git rather than by hand. They only things I changed in the standard setup besides my PW info was the UID/GID in powerwall.yml. Everything else was out of the box.

For usage.json I used the sample and made one change:

"influx_url": "http://127.0.0.1:8086",

Still getting the 599 error when testing usage_engine from a url and also when adding the data source in Grafana.

[BuongiornoTexas]

When you look at the browser/container log for details, is the error message still the same as the original? (especially the failed to establish connection)

{"Usage Engine Status": "599 Error loading usage engine configuration file (<urllib3.connection.HTTPConnection object at 0x7f2c84f6c450>: Failed to establish a new connection: [Errno 111] Connection refused)."}

From all of the stuff above, this is what I'm expecting. And if it is, I'm at a loss how to proceed - assuming I'm right in the source of the error, the pwdusage container is being blocked from accessing the influxdb container. And I don't know what needs to be done to stop this happening. Especially since the rest of your stack is working properly and is built on the influxdb container.

At this point, the only thing I can suggest is check if either the QNAP firewall or QNAP container manager is limiting access to port 8086 to specific containers/processes. You could also try downloading chrongraph to test if you can access the influxdb container outside the Powerwall-Dashboard stack - if you want to try this, I can add a couple of screenshots to show what needs doing to set this up.

[aesculus]

Here is the error from the container log:

ERROR: Error loading usage engine configuration file.
ERROR: Details: <urllib3.connection.HTTPConnection object at 0x7f53ca0388d0>: Failed to establish a new connection: [Errno 111] Connection refused

Here is the error from the browser http://192.168.1.108:9050/usage_engine

{
Usage Engine Status: "599 Error loading usage engine configuration file (<urllib3.connection.HTTPConnection object at 0x7f53ca08e950>: Failed to establish a new connection: [Errno 111] Connection refused)."
}

And in Grafana here is what is reported when I do the save/test

[BuongiornoTexas]

@aesculus - unfortunately, this is what I was expecting to see. Per my previous post, let me know if you want to try chronograf (I'm not sure it will leave us any the wiser though).

I really have no idea what is going on at this point. The bad news is that debugging will probably require getting into the python weeds. This error is happening in a library called by pwdusage, and I think we would need an interactive debugger session to figure out when the call happens and get more information on why the connection is being rejected (which may well be more effort than it is worth to you!).

Ah - one more thought. Try do the save and test on grafana again, and then take a look at the influxdb container log. Maybe that will tell us something new?

[aesculus]

I have no idea how Docker and Python work together. I am going to learn soon though as I need to add a capability to monitor my HVAC system to the dashboard.

Don't forget I tried to run the usage stack in Python and hit the wall with being less than V 3.11. Could that be the issue here that the library you are calling is one that is your 3.11 stack?

[BuongiornoTexas]

Don't forget I tried to run the usage stack in Python and hit the wall with being less than V 3.11. Could that be the issue here that the library you are calling is one that is your 3.11 stack?

I don't believe so. As I understand it, the docker container includes a full install of python 3.11, and pwdusage can't be installed with version lower than 3.11. (docker configuration and pwdusage config files specify these requirements).

As I understand it, the local version of python you installed isn't shared with the docker container.

[aesculus]

OK.

Forgot to mention that after doing the test the influxdb log had not additional entries. But this Grafana log may shed something interesting:

logger=context traceID=00000000000000000000000000000000 userId=0 orgId=0 uname= t=2023-07-09T00:56:32.012999946Z level=info msg="Request Completed" method=GET path=/ status=302 remote_addr=172.29.4.1 time_ms=1 duration=1.098229ms size=29 referer= traceID=00000000000000000000000000000000

logger=context traceID=00000000000000000000000000000000 userId=1 orgId=1 uname=admin t=2023-07-09T00:56:41.889071175Z level=error msg="Request Completed" method=GET path=/api/datasources/proxy/3 status=599 remote_addr=192.168.1.153 time_ms=7 duration=7.726501ms size=210 referer=http://192.168.1.108:9000/datasources/edit/W6q-3ur4z traceID=00000000000000000000000000000000

The first entry is the data updates that come about every minute. Note the user and org id.

The second entry is our old friend. Not sure why the userid = 1 but maybe you know why.

Also the IP address of 192.168.1.153. That is the IP address of the PC that the Web Browser showing the PWDB. Again you may know why this is in the log.

[BuongiornoTexas]

My grafana knowledge is shallow, but I think that error message is just grafana saying: I got a 599 when I tried to update a datasource, and that update was requested from 192.168.1.153. So no new knowledge.

At this point, I don't have any more suggestions, so I'll go quiet on that part. But I will keep responding to your queries and ideas, and will provide more in depth support when you get to the working in python stage.

[aesculus]

Can you do a bit of a test for me. What address do you have in usage.json for the "influx_url"?

And what happens if you enter that address and port into a web browser?

On my system I get a 404 when trying to access it. That port does not seem to be exposed outside of the internals of Docker.

[BuongiornoTexas]

On my system I get a 404 when trying to access it

I'm assuming that's using http://[influx ip]:8086. That's correct and what I see - it's telling you that there is no web page available on this url:port. There is apparently a web service, but you need to access it using curl. https://archive.docs.influxdata.com/influxdb/v1.2/tools/api/

But, when I've been testing, I've used chronograf. https://www.influxdata.com/time-series-platform/chronograf/

That said, the fact that you are getting a 404 at all says a) it's not being blocked at firewall level and b) something is listening (and if the rest of your stack is working, it must be influxdb).

[aesculus]

OK. You won't believe it but it mysteriously started working. I was fussing with various things in docker but not sure if I really did anything to cause a change. Anyway it passed the test and I am not on to the Grafana Dashboard setup where I am lost.

I went to add a panel and filled out what I could see from your instructions but am lost after setting the data source and metric. BTW I have never seen anything about a Hero panel so maybe I am in the wrong place.

[BuongiornoTexas]

From everything you've posted, it's sounds like the QNAP docker dashboard is a bit of a pig. I suspect you have toggled a switch that allows influxdb to respond to pwdusage. Whatever you have done, nice work on getting it to this point (if you do figure it out, let me know so I can update the docs for other QNAP users).

The fact that the plot shows any data at all means pwdusage is working.

On the dashboard, the easiest thing to get you started is to import the "Usage Summary V2 dashboard.json" into grafana (you can do this at from the dashboards menu). Given your data source is the same name as mine, this may work out of the box, but if not, go the to Power Usage panel (the hero panel for this dashboard), edit it and set the Data source name to "JSON Usage" and the metric to usage.

If this works, you can also try the detail dashboard, which shows how to do multiple panels. The hero panel for this dashboard is bottom left - Power Usage->Grid Import.

[aesculus]

I opted for the Usage Detail dashboard. Not sure what all that Hero stuff was about in the instructions but just importing your dashboards is the easiest. Maybe I missed the obvious in the instructions.

The only physical thing that I did was trying to do the ping test

curl -sl -I localhost:8086/ping

Which resulted in the same attributes as the sample above and then I tried the doing another ping test by creating a new docker instance

docker exec -it grafana /bin/bash
ping influxdb
exit

Then in the browser

http://YOURNASIP:8086/query?db=collectd&q=SHOW%20SERIES

but I did not have a db name but I got that error so I knew it was connecting.

[aesculus]

Now I am off to set my usage.json for my environment. Lets hope I don't break anything in the process.

If I change usage.json can I just redo the data source test to force a reload or do I need to stop the whole dashboard and restart it? I am a bit leary to test fate.

BTW now that we have this working I am going to look into doing something similar with my heat pumps as a dashboard/panel. Stayed tuned.

[BuongiornoTexas]

Hero is just a convenient label for the one panel on a dashboard that makes a direct call to pwdusage - it's the panel with JSON Usage datasource. Every other panel on the dashboard just copies data from this hero panel using the Dashboard data source.

If you try setting up two panels using the JSON Usage datasource on one dashboard, you'll quickly see why you want to do it this way.

[BuongiornoTexas]

If I change usage.json can I just redo the data source test to force a reload or do I need to stop the whole dashboard and restart it? I am a bit leary to test fate.

Should be enough to hit save and test in the datasource - that's how I do my changes. Also, from hard experience, change and test the config in small steps and keep backups.

[aesculus]

@BuongiornoTexas
I have updated the usage.json to reflect (I think) my environment. I might need a bit of tweaking (see below). But I have one major issue. I don't have any reporting for my Shoulder periods.

usage.json.txt

I have a bit of a question on costs. As I reported upstream, my cost and export value are essentially the same. There is one small caveat. I get charged a fee per kWh for any power sent back ($.03). I reflected that in the "SUPPLY_CHARGE": -0.03

So all the other values are the same cost (sign depending on supply or export). I may need two tweak these based on my understanding since I think I am off by the surcharge the wrong way. The prices I have are the actual costs/exchange but the way I configured it I think everything is now $.03 too high. See attached usage.jason.

The other issue is more of a question about your approach to displaying the monetary value. It appears that you treat costs as negative values and exports as positive values. This is OK, especially if at the end of a period you have a greater value than cost. I just need to make sure I understand it. In my case I always end up at the end of the year owing money. From a cost perspective that is a +, but from a life perspective its a -. :-(

[BuongiornoTexas]

Supply charge is meant to handle plans which charge a daily connection fee. So a lot of plans in Australian charge about $1/day to access the grid (regardless of usage). Supply charge is applied to each data point returned from influx db. So if I have a $2.40 per day supply charge and the database is reporting hourly increments, supply charge should be $0.10. Your plan doesn't seem to need it, so you should just delete these lines from the tariffs.

In your case, it sounds as though you need to set your grid export to be $0.03 less than your grid import - e.g. Peak GRID_EXPORT to $0.58273.

pwdusage doesn't care about signs. If you want to reverse your cost and value signs go wild. You can even make them the same sign (but it will be hard to understand what is going on).

Finally, you are not seeing your shoulder data reported because you haven't configured it. It also won't be showing up in the totals/subtotals for the same reason.

Unfortunately, one of the curses of usage plans is there are lots of them. I've built a tool that allows representing many of them. But the consequence of that curse is you have to set up your own custom dashboard to get the reports working. The easiest way to get started is to play with the transforms on an existing plot or table - this will give you an idea of how to add the shoulder data and incorporate it into the totals. See the last two dot points of https://github.com/BuongiornoTexas/pwdusage#grafana-dashboard-setup as well.

[aesculus]

OK. This is all great info as I plod through new territory.

You might want to relabel this thread: Stupid Questions and Answers for Usage Dashboard :-)

[BuongiornoTexas]

Stupid Questions and Answers for Usage Dashboard :

It's mostly telling me that I need to do a bit more documentation. Not enough time and energy now, but I will come back to it in a bit and clarify some stuff based on your questions.

[aesculus]

OK. Dashboard modified to add my shoulder periods. I used the Grafana Inspect-Json for each graph element to make the change and test in real-time. I paralleled that with editing the json file and then also did an export to json when I was all done.

[BuongiornoTexas]

Looks good!

In passing, your system value in the top right should be the sum of the self consumption total and the grid export total - you may be missing some values in the system value?

Are we good to close this issue and #4 now?

[aesculus]

Small mistake where I used kWH as the value instead of $. Now matches. I attached the shoulder usage detail json file in case you want to add it to your distribution.

Usage Detail Dashboard Shoulder.json.txt