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.