spenceme

12 hours ago, DeVille said:

 

Any chance you have a device for sale, as complete as possible? For an Aidon meter. Thanks. 

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.

9 hours ago, cpu22 said:

There have been several wrongs from roarfred's original AmsToMqttBridge in this thread. What software is the people using now? What is recommended to use if I need to update my HAN ESP8266 card.

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

On 20/01/2020 at 22:20, surkål said:

For å overvåke kåkens strømforbruk tenkte jeg å lage til en sak i sikringsskapet, en ESP8266 og en fotoresistor som teller pulser fra LED på strømmåleren som er der i dag, 

1000 pulser = 1kwh

Esp'en skal kjøre ESPhome som igjen snakker med Home Assistant.

https://esphome.io/components/sensor/pulse_counter.html

I mitt hode bør dette være så "non-intrusivt" som mulig, fotocellen kan jeg tape rett på strømmåleren.

meeen..

bør ha et hull i sikringsskapet da det sikkert er dårlig wifi dekning der inne og ESP'en bør være ett sted på utsiden, er det fy-fy å ta et lite hull i sikringskapet til formålet? 

 

Er det noen andre som har laget en slik?

 

Jeg kunne jo ha kjøpt en Tibber pulse, men det er jo ikke like morro

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

7 hours ago, ArnieO said:

@spenceme made the electrical design and PCB based on some of my initial ideas. The documentation is on his Github: https://github.com/dakarym/AmsToMqttBridge

 

I have not checked but believe/assume the attached schematic corresponds to the KiCAD files on his Github.

schematic.pdf 117.27 kB · 1 download

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.

4 hours ago, nicbra said:

Is there a place we can follow your progress, like github? Or do you wait to publish your work when the project is finished?

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.

5 hours ago, nicbra said:

Is there a place we can follow your progress, like github? Or do you wait to publish your work when the project is finished?

(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

2 hours ago, tronde said:

Have you tried to increase the value of the resistor between pin 4 (RIDD) and ground on the TSS521? This resistor determines the constant current drawn from the meter. We don't need a constant current, and 1.5 mA is signifcant part of the available energy from the Kamstrup meter. The datasheet says RIDD max 80k, but I would try even more and see if the circuit becomes unstable.

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.  

31 minutes ago, tronde said:

Yes, of course you are correct. Maybe time for bed...

 

Do you have any idea about how large the current spikes you talk about are? It seem from the available documentation that a slave talking to the host will increase the current by 15 mA. Since Kamstrup says  four slaves at 1.5 mA it should give some 21 mA before the transmitter shuts off for short pulses. I assume only one slave is allowed to talk at the same time.

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

31 minutes ago, tronde said:

Found something interesting in the datasheet for NCN5150 which is a replacement for TSS721A.

 

https://www.onsemi.com/products/connectivity/wired-transceivers-modems/ncn5150

 

It can be programmed to draw up to six unit loads, and feed most of it to the slave's circuitry.

At four unit loads (6 mA) it can feed 5.4 mA. This is only 10% loss. Maybe we only get 4.8 mA, but it is still good.

 

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.

On 15/10/2019 at 08:43, ArnieO said:

Great work, @spenceme!

Other issues in life took me this year, preventing me from moving forward with my prototyping. But after only a short look at your schematic, I see you have come farther than I would have been able to.

And I confirm I am very interested in your work, and would like to test your design on my Kamstrup.

I would be very happy if I could buy a PCB from you (and any difficult-to-source component on it)!

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.

On 15/10/2019 at 09:01, DeVille said:

 

I like the idea of open source projects, but sometimes there are more great projects than time permits for. So I would not mind being on your list for a complete device, or pcb with programmed device.

 

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?

11 hours ago, ArnieO said:

There might be an issue with short current spikes consumed by the slave, as indicated in the Tibber blog post linked above.

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.  

12 hours ago, DeVille said:

 

Yes! Would you be selling turn key devices, ie complete hardware & software ready to plug in? 

 

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.

5 hours ago, tronde said:

Found something from Tibber about Aidon and current on the Han port.

 

https://blog.tibber.com/no/den-fulle-historien-om-tibber-pulse-aidon/

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?  

On 05/08/2019 at 19:23, nicbra said:

 

 

 

 

That's cool! Have you tested it yet?

Instead of removing the PF function completely, maybe you could use it to trigger a modem sleep or light sleep in the ESP?

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.

5 hours ago, gskjold said:

This is pretty cool, looking forward to build one when I have time. No mbus chip on your board? 

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

16 minutes ago, xibriz said:

Nice work! I'm verry interrested in trying this on Kamstrup. If you could ship me a PCB with the SMD components (excluding the ESP) I could take care of the rest.

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.  

3 minutes ago, tronde said:

 

Have you seen the updated info from Aidon?

https://www.nek.no/wp-content/uploads/2019/02/Aidon-HAN-Interface-Description-v11A-ID-34331.pdf

 

They suggest a current limiter and a blocking diode just to avoid discharging the capacitors.

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

On 21/02/2019 at 17:43, ArnieO said:

@spenceme & @antonkristensen

(Jeg antar du leser norsk, @spenceme)

Jeg kom hjem for noen dager siden fra tre lange uker på jobbreise - og begynner å nærme meg å få jobbet videre med dette.

 

I mellomtiden har DC/DC buck converter modulen ankommet fra Kina:

Dessverre er ikke strømbegrensningsdioden D2 ankommet ennå, kanskje jeg lager en breadboard uten.
 

 

 

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.

On 15/01/2019 at 22:16, ArnieO said:

Utlegg av PCB med buck converter begynner å nærme seg klart - bortsett fra den "detaljen" at jeg ikke har breadboardtestet det ennå. ?

 

Skjema: AMS_HAN_ESP_Buck.sch.pdf

Jordplanet er ikke lagt på ennå, alt annet skal være rutet.

 

 

 

Jeg blir bortreist ifm jobb neste 3 uker, skal forsøke å teste dette på breadboard før jeg drar.

Men selv om det skulle være lite debugging (kryss fingre!) vil det realistisk sett ta minst en måneds tid før jeg får bestilt PCBer.

 

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.