I have pre paid electricity, like quite alot of users.
Was wondering if there is a way to calculate how much units we have left and display it somewhere?
My meter is in the Garage, not a big deal just to walk there every now and again to check what we have left, but it would be nice if somehow it can by display somewhere base on monthly purchase - et112 reading.
Idea is to manual entre the current reading and then it automaticly deduct what is being used.
On the prepaid meter there is a small LED that flashed as you consume energy, most of them are 1000 flashes per 1 kWh.
With an LDR and esp8266, you could count the flashes and then deduct them from what your current units are. It should be fairly close to what the meter shouws.
Yeah, I made an Android app (or rather, I fixed one up from someone else… someone who stubbornly refused to answer my emails when I asked if it was okay ) that uses the camera of the device to count the LED blinks and calculate it for you. I went as far as making the app keep the phone alive, with the idea of later adding some logging to it. You could then, in theory, mount an old phone to your prepaid meter to do a bit of logging.
Shortly afterwards I discovered that my conlog meter has a feature: Type #1# on the keypad, and it shows you the current consumption on the LCD. Lost interest in the Android app after that.
Someone contacted me once and asked if they can use the app for some project in their country. I said yes, but ask the original author. CCed him in the mail. Still no response. I’m pretty sure he intended the code to be public domain (since he put it up for download without an explicit license), so… here it is. It is positively ancient by now
Thanks for all the great feedback.
I was more wondering in the lines of useing the “from Grid” values in VRM to calculate the remaining units left on the prepaid meter.
But i quest i can use a webscraper and excell to calculate that.
Unless, if possible, to build in a extra menu into venus os that you can manually type in your existing units, and then it will automatically deduct the “from Grid” units as they are being used.
But then, i quest it will be easier to just walk once or twice a month to check what is left!
I have NOT done this so can’t help with tech support but for anyone who wants to tinker. One option to explore (depending on what else may still need to be purchased) is an Efergy CT Clamp+Transmitter, a RTL-SDR (USB type receiver that has many “off-label” uses) and home assistant.
The Efergys transmit their measurement on 433Mhz and you can pick that up with a RTL dongle, decode it and via mqtt probably get it into something like home assistant. Even if getting all of this to work it will not be 100% accurate (Efergy sends measurement at most every 6 seconds and also does not measure, voltage so power “measurement” is dependent on your programmed voltage).
Some links for anyone wanting to dive down the SDR rabbit hole
SDR general info
Efergy + SDR 123
For those like @plonkster with a very wide interest you can even use these RTL based receivers to receive and decode satellite signals (even I managed to get a weather satellite image - so it is doable).
Back to topic sort of : → The CBI nanoview energy monitor communicates via UART and the technically inclined should find all they need about the protocol etc. here if wanting to use these measurements in something like home assistant (again don’t ask me for tech support - I must still figure out what an unsigned integer is… ). The nanoview should give a more accurate reading since it also measures voltage but you will now run into the problem of getting that measurement from the garage (or wherever) to anywhere else. The fact that the nanoview is probably more expensive than an ET112 is beside the point (but you can measure multiple different circuits if necessary with the nanoview…)
Actually, I have another little story I can tell here.
So every single CAN-bms battery maker defines the Ah rating of the battery as a signed 16-bit integer, with one decimal. This is how the protocol developed ever since someone started it and everyone copied it, so that today it is a kind of defacto standard.
Signed 16-bit integer means it can represent numbers from -3276.8 Ah to -3276.7Ah.
First, the idea of negative Amp-hours is completely nonsensical. Second, I don’t think I’ve ever seen anyone use the decimal point that is provided for. And third… the battery makers don’t actually follow this spec to the letter. They send an unsigned 16-bit integer (which makes a little more sense).
A 16-bit unsigned integer scaled to have one decimal has a range of 0 to 6553.5Ah.
Now as you might imagine, there are now a few battery banks in the world with a capacity of more than 3276Ah. And the moment that happened… yup… the number showed up as negative on the other end
Now if you are a C (or C++) programmer and you are going for an interview, there will always be that one question: How large is an integer.
The answer (as indicated in @plonkster’s answer) is that it depends. If you are on a 16bit CPU the integer is 16 bits (2 power of 16 cause a bit or switch can be either On or Off)
A 32bit CPU will have an integer as 32bits. And 64bit for the new guys.
Other types tend to be fixed, but integer is suppose to be the most effecient size, thus matching the CPU.
It is because of this story that 64bit OS and 64bit apps works, but you can’t run 64bit apps on a 32bit OS. Most od the OS and drivers are still build on C/C++ or derivatives so you find this everywhere.
ERROR:dbus.service:Unable to append (10000000000,) to message with signature v: <class 'OverflowError'>: Value 1410065408 out of range for Int32
So python2 has both a long (64-bit) and an int (32-bit). Python3 has only an int which can do everything. The dbus library has a bit of code that checks what kind of int it is working with, and then uses the correct C-type to send it over the IPC bus.
In the old code, it first checked if it was an int or a long. If it was a long, it would go through a long switch statement, and finally default to int64.
But now in python3, everything is an int. So now it executes the other default, which is to turn all unknown numbers into an int32. Causing errors.
So even in python land, this bites you in the arse every now and then…