@overeasy
Hi Bob
Id like to put together a lotawatt at my office which has three phase but will need to know where to get a PCB and components from.
I’m also quite happy to set you up a VPN also to help you with development.
Regards
Dave
Dave, There should be some complete units available in 6-8 weeks through OEM. Possibly some shop built units before that. Are you saying you would rather build your own? That’s OK with me, but understand I’m pretty busy getting this ready for prime-time and won’t be much help if you get bogged down with problems.
Hi Bob
Buying pre made is easier, I didn’t know where you were with the development?
I’ll wait until there’s units available. 
Regards
Dave
Bob - I am in the US also. It is a bit costly to order items from OEM due to the added shipping costs and the transaction fees for foreign currency.
Will you have units available for sale on this side of the ocean?
Thank you! Jon
Short answer is that I’m not in a position to retail something like this. OEM has built a nice infrastructure to disseminate the technology and support the resulting community. That’s what attracted me to them. They will final assemble, test, and deal with the various regulatory requirements.
I’ve encouraged OEM to look into doing fulfillment here in the USA, and would help them identify resources and set it up, but that’s way ahead of where we are now.
when you get to this part I’d be happy to help.
@overeasy: i saw that you updated the code to finish the secure eMonService.
Could you tell me what crypto.h you used? i’m getting a compile error that it’s missing and google is giving multiple options…
I wanted to check if the “problem” with the connection to a synology running emon is solved with your new code
I compiled it with the one here:
and it compiled ok. The upload works to my synology server, but i increased the timeout because it seemed to be a bit short.
I couldn’t find if this affects the readings, but i suppose not?
Since the samples per AC cycle and AC cycles sampled/second stay in the same ballpark (765 and 30 a 31)
I was just about to send you the link. These libs seem a cut above and
more comprehensive than others. I’m also doing some development with
the Ed25519 signature libraries to sign the OTA updates.
Are you using the secure post with the latest OEM changes or just the
recoded GET with HTTPclient? In either event, increasing the timeout is
only a minor issue. For the record, the timeout seems to apply only to
reading the response, so transactions can still take a long time if the
server takes awhile to respond. Typically, I see times like 300-400ms
for a complete transaction where the server is on the other side of the
Atlantic ocean (about 50ms ping).
The software blocks for the duration of the transaction, so no sampling
takes place during that period. That’s not as bad as it sounds. When
no sampling takes place it only means that changes won’t be recognized,
the power level will remain at that of the last sample.
If you want to mitigate the effects of blocking during data
transactions, you can use the bulk send parameter to aggregate several
transactions and send less frequently. There is no danger of losing
anything. How is that thing working anyway?
I tested it with the normal “non” secure send, since that’s is what i am running on my synology.
I tried to increase the timeout to 500, but it seems that 1000 is working properly. (seems that my server is relatively slow…)
I haven’t been running the IotaWatt so much since i’m waiting for some parts to arrive from ebay (china) (a smaller NodeMcu and some things to make a second one - hopefully they arrive soon).
On the second one i’ll try to upgrade the pcb to the new design (i’ll have to cut 2 traces and use some wire). Not so clean, but it’s such a waste to trow them away 
I have been a bit busy making a 3d printed case (DIN rail mounted) so i can install it properly.
I’m still not sure about the bulk since it gives less recent data in the local emoncms, but i’ll try it out when the whole thing is installed.
I forgot about that. You may be interested to know that all of the connections are on right side (looking with the usb port toward you). Except for the redundant 3.3V and GND pins on the other side, none of the left pins are used. So if you plug that wide nodemcu into the right side only, and you have tied your power and gnd to either of the two on the right, it should work fine, albeit dangling off the other side.
That’s the downside if you are doing a real-time display, but then again you can get that data directly from the IotaWatt on the local LAN.
Now that you mention it…I hadn’t noticed it yet that they were redundant (i hadn’t looked at the schematic since i changed it to trough-hole). That’s a nice backup-plan if it should’n arrive soon! (only problem is that it wider and a bit longer…so it’s sticking out about 5mm)
What I did to test the RC circuit on the old board was to remove the .1uf decoupling cap on the RTC and solder the 10uf cap and 1K resistor “tombstone” style to the two pads. Then I lifted the Vcc pin of the RTC and connected that to the tops of those two components. That way, there was no need to cut any traces, which never turns out like you want it to. I realize you are thru-hole, but the technique should work on that too.
The changes for the extra resistor next to the RTC is quite easy, i had something in mind you described 
The changes for the introduction of the ACBIAS is more difficult since the trace with BIAS runs from the LM358 through my VT connections to the CT3-8 
. So i have to cut the portion between the VT’s and reconnect the CT line to the LM358.
Would this mean a great improvement?
Has nothing to do with accuracy. The issue is that the common bias can get pulled low when a CT is connected or disconnected, causing an interruption in the normal rhythm of the software and transient weirdness. It’s not much of a problem with the CT channels, but the basic heartbeat of the main loop is driven by the AC cycle. So since I had an extra unused channel on the LM358 dual op-amp anyway… I elected to dedicate it to the AC channel and insulate it from the CTs. In your case, with two additional VTs, you may elect to bias all three voltage channels separately, or none at all. As long as there is no plugging and unplugging while the device is running, there is no difference.
13 posts were merged into an existing topic: Homebrew IoTaWatt issues
Hi Bob,
I have been recently looking for a power monitoring solution for my house after installing solar and came across IoTaWatt and I have to say this is by far the best solution I have seen. The work you have done on this is impressive, making it much more than most hacked solutions I have seen.
My use case is a little different than what IoTaWatt provides, and so I have been trying to understand the hardware so I can consider making my own board with some changes.
Do you mind if I ask a few questions about its design as I am trying to understand it as best I can but am a software engineer by trade and so a little slow with the hardware side of things?
I am basing these questions on the 4.3 schematic from github (revision c0bb95f096adf0cbdddb9c2e1ff9c784bcd33448).
The questions I have are:
-
Why is the fixed voltage shunt/reference required (Attached to C0 of MCP3208-0)
Also, the schematic labels it as 2V5 but from reading the spec of ADR510 I thought this should be 1V -
Did you try using the AC vref in as a power source for the circuit as well as sampling it?
I was considering rectifying and regulating this AC source to power everything in addition to sampling its voltage, but not sure what impact this will have on the quality of the AC voltage reference and wonder if you have measured/quantified what impact this might have?
The idea of needing two power sources is a slight deterrent for me -
Why is the RTC required?
-
Why is the separate ACBIAS and CT BIAS required?
-
Why are the LED’s connected to GPIO16 and GPI0 (ADCCS1)?
I don’t understand this logic (compared to just GPIO16 + GND, assuming GPIO supports current to drive 2x LEDs) unless is is something ESP8266 specific or some trick I don’t know about.
Ultimately the change I would like to make for my usage is to be able to use the same board to monitor pulse sensing for LED pulses from smart meters, and reed switch pulses from gas and water mains and I don’t require quite so many CT sensors
I figured I could still make use of the ADC for this job and just change how I provide the voltage ref for the ADC (an ADC is a little overkill for pulse monitoring but should work).
I was thinking of using a simple jumper on the board to configure the type of input sensor attached (unless I find a better solution). This would convert a given ADC input channel from measuring a CT sensor to measuring light using a phototransistor or output of a reed switch. I would then just rig up a 3.5mm plug to my appropriate sensor.
There are a few other changes I would consider as well but not as important to me (depending on what smart meter gets installed by my grid provider):
- Look into using the single AC vref as a power supply
- Expose one GPIO + SPI lines for a potential SPI colour sensor (not sure if this will work)
Some meters use green/red LED to show import/export instead of two separate red LEDs
Looking at the design it seems like you are out of GPIOs so would need to sacrifice something or add more complexity to do this. I really DONT want to do this if possible
I just want to say, thanks again for the amazing work you have done on this!
Hi Brendon, believe it or not I’m a software engineer as well. When I used to work for a computer manufacturer, I had a department full of hardware engineers that built everything for me. Now I had to come up to speed and do it myself. It’s not as hard as it looks, kinda like legos, just plug them together. What’s harder is manufacturing and regulatory compliance. Fortunately Glyn Hudson is very good at it.
I’ll try to answer some of your questions.
So you don’t have to calibrate things. It’s very accurate. With the shunt, the ADCs are calibrated so we know the supply voltage, the bias voltage, and can measure the CT output very accurately.
That’s a mistake. I use a 2.5V shunt, but someone else built their own and used the ADR510. You can specify the reference voltage in the config file, so he did that and it’s working fine with the 1V shunt. No impact on accuracy. I think the 2.5V cost less though.
There are electrical issues with trying to do that. It has to do with the the ground and being able create a DC bias for the reference voltage into the ADC. The Emon product that uses the AC for power has a half-wave bridge. That won’t provide enough power for the radio. Anyway, for the cost of building (or buy) a decent 9V AC to 5VDC power supply on board, you can get a good 5V wall pack. The more you move off to commodity the better off you are.
The thing is basically a datalogger. It stores data at regular intervals with a timestamp. It needs to know what time it is. The time is available from NTP severs, and IotaWatt sets the RTC from there and corrects the RTC periodically, but it needs to be able to run without WiFi.
Long story. Basically they are not required. There can be issues with noise on the CT bias line and since the LM358 is a dual op-amp, I elected to fire up the other one and dedicate it to the AC reference.
As you point out later, I’m out of pins. The LED is a bicolor LED and unlike some that have two inputs and a ground, this one works by being red with forward current and green with reverse current. So High/Low and Low/High. Ground won’t do it.
That’s a different thing. You could use the ADCs, but it would require some changes in the software to sample each of those channels once between each current sample cycle. So you could check them 30 or so times per second in a 60Hz world, and 20 or so in a 50Hz world.
In an early version of IotaWatt, I had an SPI 16 channel GPIO chip. It not only would do this job, but can be setup to capture state changes and interrupt. To add something like that, you would need a pin. It’s possible to get another pin by switching to an SPI RTC. It’s doable, but not in the short term.
offhand I think you could probably do it with ADCs as is. on/off definitely. Measuring light intensity (as opposed to light/dark) I would think you need an ADC somewhere anyway.
The GPIO is a problem, but the SPI can support plenty of slaves.
I’ve had great success measuring usage/import/export of PV systems. Accuracy has been less than +/- 1% of the reported generation of Solar Edge inverters and requires only one CT on the inverter output. Depending on your power system you need one or two more CTs on the panel mains - voila. The sum of the 7 days reported bythe inverter is exactly the same - 293.1.
This house is also measuring their HeatPump, AirHandler with Electric Backup, HotTub (I know), HeatPump Water Heater, Refrigerator, an dthere are still three CT inputs unused.
About the gpio’s: i read that you could use gpio10, but only as an input. (gpio9 is unusable)
Maybe you could also use the ADC0 pin?