spenceme

I have all the parts and can build one for you. Haven't looked at this much for the last year since mine has been running perfectly since 2019. I'll send you a message.

I would suggest https://github.com/gskjold/AmsToMqttBridge. Gskjold is actively improving and bug fixing.

I ran exactly this for months. It works okay. Mine was battery powered which needed recharged each month. I've moved to measurements as reported by the meter and powered through the HAN interface. You will get faster and more accurate data. What meter type do you have? https://github.com/dakarym/AmsToMqttBridge

That should be the current schematic.

I've forked the gskjold repository and updated the best I could tonight with the latest design and some of my thoughts. @nicbra, this would be the best place to follow for the latest. Although all the design details are there, I suggest to wait a little before building much to give us a chance to debug on other meters. https://github.com/dakarym/AmsToMqttBridge @ArnieO, I updated the sketch on my repository with the sketch I am running today for the changes needed. I'm not sure if the gskjold fork runs the other Kamstrup and Kafia meters 100%, but it runs the Aidon I have perfectly. Hopefully it is okay.

I don't have a github for this. Perhaps I might here in the coming couple days. Basically @ArnieO mentioned the current status. There is not really something secretive...its basically the schematic I've posted up the other week. My thoughts were to test with @ArnieO and work out some bugs before putting up the design files, maybe it's time to put them up. @nicbra I know you want one, so just give us a little more time. I'll build you one here before too long.

(see below for the reply to this) On another note, does anyone with a Kafia meter want to test? I have a board ready to send out for testing. The best would be if you have an oscilloscope for debugging if needed.

Others noticing this integration fails today? Mine has been working perfectly for months, then last night it starts with this error. Due to the time change we end up with 25 hours in today instead of 24. I notice the length of newData and the prices is hard coded to only 24. It should correct at midnight and only happen once a year (although I wonder when we have a 23 hour day). Maybe we could adjust the handling of the data lists to be able to hold these special days. 2019-10-27 20:49:01 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up platform nordpool Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 150, in _async_setup_platform await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT) File "/usr/local/lib/python3.7/asyncio/tasks.py", line 442, in wait_for return fut.result() File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run result = self.fn(*self.args, **self.kwargs) File "/config/custom_components/nordpool/sensor.py", line 52, in setup_platform add_devices([Nordpool(name, currency, region, offset)]) File "/config/custom_components/nordpool/sensor.py", line 87, in __init__ self.fetchNewData(_TODAY) File "/config/custom_components/nordpool/sensor.py", line 194, in fetchNewData newData[row] = round(float(price) / 10, 3) IndexError: list assignment index out of range

Yes, i'm running 82k, that change alone saves ~0.6ma. I've made some small changes that look good today with quick testing. I think the peak current consumption is down to ~6.5ma now. If we limit the messages sent in the code I believe it should be no problem to go lower too. I need to verify some of this over the weekend and hopefully get a setup to measure currents with a scope put together...then I can answer some of your more detailed questions. Regardless, after this weekend I want to test on a kamstrup.

Ignoring the initial charge current of the input caps, I see a peak current of ~14ma when the dc-dc is switching at 12v.

It is pulling 6ma of current at ~24v, and providing 5.4ma at 3.3v. That's 12% efficiency. In contrast, the buck I'm using can provide ~35ma at 3.3v with the same 6ma input (80% efficiency). The buck itself runs at 90% efficiency, but the TSS721 consumes ~.6ma.

Sure, no problem...it's birthed from your concept anyhow! Let me work a bit building a modification into it this weekend to reduce the current draw when at the 12v low state. I need to build up a second unit to test with. It is all surface mount 0805 package size with a few smaller IC's and transistors, so you will need a fine tip iron to build or I can build you one. I'll send you a message to coordinate. Right now it needs testing from people with different meters who are open to a troubleshooting period. If it gets to the point of plug and play, then I'll let you know. What type of meter do you have? Their wording of microseconds has me nervous. Is there any way to tell what version of FW your meter has on it? My meter reports 'AIDON_V0001' on its list 2. I'm curious if that means it's a version 1 firmware?? Maybe someone else has a report of _V0002? My simulations don't predict worrisome current spikes in that level, but if it is indeed that fast in triggering an overcurrent I would be impressed. I don't have access to a high speed current probe at this time. The best in-amps I have drop off to gains of ~20db at 1Mhz...not super useful.

I was not thinking to sell turnkey devices. This is really an open source project after all. Mainly I want to know if people are interested then I’ll continue further to refine the constant current draw . I do have enough hardware to build a few of these units now. I’d sell those for the cost of the materials. I can program it and share my current firmware. I can’t guarantee it will work perfectly on your meter out of the box, as I have only tested on my meter. Thanks! This is interesting. I wonder what firmware my meter has on it. I know mine has current spikes, but they are below the 30ma Aidon lists as maximum. Most interesting is to have a current probe measurement between the HAN and Tibber pulse. This article makes me wonder if they are adhering to the constant current protocol. Also it gives more hope in that the kamstrup and kafia are more tolerant.

Small update if some are interested. I've got the new board built with a voltage supervisor and it works well. Once programmed, you simply plug it in and it powers up. Turn on of the ESP happens around 3.25V and it disables around 2.65V. I added a couple lines of code to wait for the vcc to reach 3.3V before booting up. At first I was confused by how much current the TSS521 consumes (~1.2ma on my inital build), then I read into the HAN protocol. Slaves are supposed to consume a fixed amount of current as they modulate their current to communicate with the master. Obviously with the buck on the input this design does not conform. Input currents on my design range from 0.5ma (TSS521 only, idle buck), to 7.5ma (when bucking from 24 to 3.3), and 15ma (when bucking from 12 to 3.3). This said, I'm not sure how critical the constant current draw is for this application. I've had such a system running on my han for the last several months without issue. However, I guess they could update the FW on the meter and it could develop problems. I'm slowly working on a method for solving this (current sense feedback into a amplifer to burn the extra current). If others have clever ideas here I'm all ears. This said it runs okay on my Aidon meter with 2.5second messages. I'm averaging ~5.5ma of current consumption from the HAN port. With the slower message speeds of the Kamstrup I think it will consume less. I'll need to put a voltage divider on the run pin of the buck controller so it only pulls power when at the 24V level. Is there still any interest of others for such a device?

No, it hasn't been tested just calculations/simulations for the hysteresis. I reconnected back the power fail pin to GPIO14. My reader was running for over 2 weeks without issues only powered via the HAN port. It froze this weekend and needed a restart....the 3.3V looked to be <1.4V, so I suspect something caused it to draw too much power and brownout. I'm hoping it would have been automatically reset and recovered by the voltage supervisor. I ordered the new PCB tonight, its a bit smaller than the first board. Should be built and tested around the end of next month. I'll order a few extra components to build a couple spares maybe for others to test.

It has a mbus chip. I used the tss521 instead of the tss721 due to availability. Here is my full schematic. @nicbra was asking for it anyways. However, I wouldn't build it again without a voltage supervisor. I'm working on that this week. HAN_ESP_TSS521.pdf *Edit: I put together the voltage supervisor piece today. I'm attaching the schematic with _VS for it. Main changes are to add the TPS3808 supervisor, additional manual reset button for the CH_PD pin, removal of the PF function from the TSS to the ESP. I'm also bringing out the 3.3V to the header (i don't use a standard ftdi programmer) HAN_ESP_TSS521_VS.pdf

I have bare PCB's and some extra SMD parts. Mounting the SMD's takes me about 2 hours plus the cost of the components. The easiest is to send you the PCB pictured. It has everything mounted plus some debug stuff. The main difference is it only has 11.7mF on the output instead of 1F. It has single pin contacts instead of an rj45...easy enough to cut a cable to connect to. First to check should be the current to charge the output cap. Right now I think it pulls ~8ma @24V (~15ma @12V) to build the 3.3V supply. We would need to bring this down to ~6ma to get started. Its a simple 0805 resistor change. I can probably make/test this change here in the coming few days. Second is to make sure the previous change still can provide enough average current to run the program. Do you know the average current consumption of the ESP when acquiring from a Kamstrup? I think your list 1 is only every 10s? This could help compared to the Aidon.

I have a design running without an external power supply, see the other thread here: It has been running on Aidon for several days now without any issues. I believe it will work as is with Kafia meters too. I fear it will draw too much on Kamstrup, but cannot tell for sure. If there is someone with a Kamstrup meter willing to try we can (even better if in the Stavanger area). You'll need to provide a 1F capacitor however, as I don't have an extra one.

I'm not sure if ArnieO has moved forward with this, but for those wondering I'll give an update from my efforts. After a little bit of troubleshooting, I now have a self-powered solution up and running this week. I'm running on an Aidon meter from Lyse. It seems to be running with no problems, and the power supply for the ESP is stable. :) My circuit is very similar to that ArnieO posted in the bigger thread. Rather than the LTC3639, I went with the LTC3642. I found it to be a bit simpler to implement, and the simulations showed it to be slightly more efficient. I'm using the latest sketch in the GSKJOLD repository, and measured the ~average current consumed to be ~25-30ma (there is some uncertainty here that I need to measure). I chose 620k for the Rset of the 3642, which should support a maximum load current of 30-35ma. In testing the DC-DC, it was stable up to ~38ma. Above 38ma, it started to drop in output voltage. I went with a 220uH SSR6603 inductor...it is tiny. Attached is a picture of my prototype board...it has some extra wires, no RJ45 jack and extra caps stuck on. The DC-DC is the bottom left corner. I've got a second board cleaner without all the mods and a RJ45 mounted that is running currently. Also attached is my schematic for the DC-DC supply. Challenges: Input voltage to the converter during transmission Originally I had a 15ma current limiter (NSI45015) instead of the 20ma. During the low bits at 12V, the converter needs ~15-16ma on the 12V line. the NSI45015 was clamping the voltage and causing the 3642 to go unstable. It would not recover without a clean power cycle. Because of the design of the DC-DC, it cuts voltage to the inductor at the programmed level. This seems to limit the maximum current draw from the HAN port by itself. The only reason for the NSI45020 is to limit the inrush current charging the input capacitors when plugged in. This seems no problem for the Aidon meter, but depending on the sensitivity of the Kamstrup this may be a problem as the currents needed at the 12V level are too high. Maybe we could increase the 33uF input capacitor so currents are only drawn during the 24V periods of the HAN signal? ESP startup power draw The ESP pulls ~70ma with peaks of ~2ms of ~150ma during transmission/acquistion. We knew this would require energy storage to support. Once fully started and configured, the ESP can stay alive with ~10mF of capacitance on the 3.3V supply. I'm not sure what voltage it dips to on transmission, but >2.6V I believe. During startup the ESP draws long periods (several seconds) of ~70ma current. This requires a 1F capacitor to maintain voltage during the startup without modifying the firmware. I went with the DGH105Q5R5, a 5.5V 1F supercapacitor. ESP brownout on powering up The 1F cap causes a very slow ramp of the 3.3V, taking well over 15 sec (probably 1min?...i didn't measure). This slow ramp of the 3.3V does not let the ESP start cleanly. At best it simply does not start even as the voltage gets to 3.3V. Worse it can go into a brownout condition and draw current such that the DC--DC can never make it to 3.3V. I've modified my firmware to include a Vcc check on boot, and the device goes into deep sleep if the input voltage isn't close to 3.3V. I've also put similar calls into the wifi and mqtt connect sections so that the esp will not brownout if there is a problem connecting to either...it will instead go into sleep cycles waiting for the voltage to recover. We need to implement a voltage supervisor circuit into the design to ensure a clean boot during a power cycle. Due to the input voltage drop from the supercap, we need a supervisor with a large hystersis. Something like an MIC2778 (http://ww1.microchip.com/downloads/en/DeviceDoc/mic2778.pdf) should work, but I will instead go with one that has a manual reset function included. Maxim makes a bunch, TI has a paper on how to program additional hystersis, etc. More work here is needed. As for now, I have to manually reset the esp when the voltage gets above ~2.4V. From there it takes care of itself waiting for the voltage to reach the 3.3V level before fully starting up. I've measured the average current consumption on the HAN line at ~4.9-5ma averaged over several minutes. In principal it seems possible to build one close to meeting the 6ma limit of the Kamstrup. For the Aidon and Kafia meters, this should work mostly as is. If someone wishes to prototype from here themselves, I have extra bare PCB's.

TPSM84203 would also be possible with minor changes to your pcb layout, no inductor to mess with, only input/output caps. 75% efficiency at 6ma/24V. free samples from ti too.

Extra difficult given we know so little about the buck. Is the overcurrent behavior of the Kamstrup documented? For the Aidon it will go into overcurrent and restart in 1 min. It seems like something here is restarting at 5hz. The input caps on the DC/DC will likely cause overcurrent on the han even with the NSI45020 for Kamstrup. Adding a diode wouldn't affect this, but the RC you mentioned will. Might be difficult to find the right R value to protect the startup surge while not having too much voltage drop for the DC/DC under load. You could try to charge initially through the R then disconnect the R after startup, and try applying load to the output. Or implement the current limit circuit in the datasheet.

I've glanced through that, but missed that point. Good to see, and confirms my thoughts. Thanks!

ArnieO, Have you been able to test these buck converters? I suspect we might want to put a blocking diode to prevent discharging the input caps into the HAN port during the low period. I'm running a different power supply, but in my simulation it was needed. I've also put a delay onto my dc/dc startup to ensure the input caps are sufficiently charged, otherwise it was dropping the input rail at startup and reseting the power supply.

ArnieO, Any updates to this work? This looks really interesting, but I was hoping to avoid starting from scratch. Are your kicad project files on github anywhere? I was hoping to use an LMZM23601 as the 3.3 supply (smaller footprint and more efficient, but requires reflow assembly). I have my own custom code running on a esp currently using light sleep and interrupts to reduce power consumption. Its down to ~15ma average, which I think is dominated by leds on the photodiode addon board...definitely seem possible to reduce further.