Wemos D1 - set pin D7 as HAN-port

[robwiklu]

I have an SlimmeLezer (https://github.com/zuidwijk/dsmr), which uses pin D7. Is it possible to set it somehow? When I try do configure it in the web interface it only shows the GPIO pins. It would be nice if this could work, as the SlimmeLezer is prebuild and cheap.

[ArnieO]

You need to look up the mapping from the D-numbering used on Wemos D1 mini pins to GPIO pins on its ESP8266. For instance this illustration: https://electronilab.co/wp-content/uploads/2017/02/WeMos-D1-Mini-WiFi-ESP8266-Pinout.jpg

You will see that D7 is GPIO13

[snauth]

For a moment I hoped this would teach the SlimmeLezer to speak Norwegian AMS, but I do not even get esptool to do anything at all with the SlimmeLezer's esp8266 ("no connection" and sometines "wrong packet"). Anybody having more luck?

[ArnieO]

I don't know the SlimmeLezer at all, but I don't think you can expect it to read a Norwegian AMS meter. Norwegian meters deliver an MBUS signal on an RJ45 connector while other countries use an other interface standard. I have not studied that one in detail, but it uses an RJ12 plug - which is what you see here: https://www.zuidwijk.com/product/slimmelezer/ If you want a reader for Norwegian meters you might want to check out my webshop: https://amsleser.no/

[gskjold]

You could try flashing with a lower baud rate, ex "-b 74880" (https://github.com/espressif/esptool#baud-rate)

[gskjold]

If you have the same "D1 mini" as pictured on the link, this is a counterfeit device which may not be as well built as the original.

[snauth]

Tried lower bitrates already to no avail and yes, it is definitely no original device. There is a reset button which sometimes yields the "wrong packet" error and then crashes the flash command. My preliminary diagnosis is that the device does not switch into flashing mode triggered by the flashing procedure and that some pulling up (or was it down?) of GPIOs is needed which is kind of difficult in an esp8266 which is soldered onto another board.

And I guess ArnieO might be right that the smart meter systems are to different anyways. I will move this question to the SlimmeLezer support.

[gskjold]

@robwiklu Did you manage to make it work?

[robwiklu]

Sorry, no. I did not get it to work. I've tested so much the last month, different solutions. Flashed it more times than I can remember. I managed to get data from another solution, but the data stream often cut of so it did not get the whole package. From what I've heard, the Aidon meters in Sweden that does not follow the interface standard yet, will get an update maybe in the end of the year. @ArnieO - Does your Pow-U solution work with Swedish Aidon meters not following the standard?

[ArnieO]

I do not have full overview over Swedish meters yet. As far as I know, some power companies follow the Norwegian standard (24/12 V MBUS signal with RJ45 plug) and on those meters the Pow-U should work. I might consider introducing a version for meters with the RJ12 plug this winter, providing I find good documentation of the interface and some people that can help me doing the testing.

[robwiklu]

@ArnieO It would be much appreciated if you could work on it. Here are some documentations about the HAN interface: https://www.skekraft.se/wp-content/uploads/2021/03/Aidon_Feature_Description_RJ12_HAN_Interface_EN.pdf The data is sent inside an HDLC frame.

Here is a link to another project on Github which might have some good information: https://github.com/aviborg/esp-smart-meter. With this project I managed to get some data, but it kept cutting off before everything was read, so the data was corrupted. But the format to read the data is handled correctly in this project for the type of meter I have (see the .pdf above). But probably there is a buffer issue that cut off reading the packets before it is finished.

I am interested in testing if you'll work on it.

[ArnieO]

@robwiklu Great - thank you for the documentation!

This would be a relatively straightforward adaptation of the Pow-K design. The only new thing is the Data request input, which is not used in the "Norwegian standard"; our meters are set to push data frames each x seconds (2,5 sec for Aidon and Kaifa, 10 sec for Kamstrup). Data request input is 5V logic, so needs to be translated from 3,3V logic from the MCU. Data output is open collector - so that is straightforward. I'll order some RJ12 connectors for PCB mounting, and some short cables - and start fiddling with a layout when I find time.

Thank you for proposing to do testing - please contact me by email on post@amsleser.no!

@gskjold : Could you take a look at the data frame format as described in the Aidon interface description linked by @robwiklu and see if it is compatible with current AmsToMqttBridge firmware?

[ArnieO]

I see now that the Data request input signal is easy to manage. According to https://github.com/aviborg/esp-smart-meter the it can be hardwired to 5V, causing the meter to push data continuously.

According to this document para 3.1, a list will then be pushed every 10 seconds: https://www.skekraft.se/wp-content/uploads/2021/03/Aidon_Feature_Description_RJ12_HAN_Interface_EN.pdf.

So providing the frame format is identical to the other known HAN-ports so that AmsToMqttBridge can be used as is, this boils down to doing a relayout of the Pow-K design to make a RJ12-dongle. And with 1,25 W available from the 5V HAN port power supply (250 mA), the supercapacitor in that design is no longer needed.

[robwiklu]

Hi!

Thank you for the update! Glad to hear that it won't need so many changes. AmsToMqttBridge needs though to be able to read the Swedish, as of writing, non-compliant protocol. Maybe around New Year, or a bit after, Aidon will probably push out a new firmware making it compliant.

Thank's! Have a nice day!

Robert 27 september 2021 17:54:54 +02:00, skrev ArnieO @.***>:

I see now that the Data request input signal is easy to manage. According to https://github.com/aviborg/esp-smart-meter the it can be hardwired to 5V, causing the meter to push data continuously. According to this document para 3.1, a list will then be pushed every 10 seconds: https://www.skekraft.se/wp-content/uploads/2021/03/Aidon_Feature_Description_RJ12_HAN_Interface_EN.pdf.

So providing the frame format is identical to the other known HAN-ports so that AmsToMqttBridge can be used as is, this boils down to doing a relayout of the Pow-K design to make a RJ12-dongle. And with 1,25 W available from the 5V HAN port power supply (250 mA), the supercapacitor in that design is no longer needed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gskjold/AmsToMqttBridge/issues/110#issuecomment-928007125, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIGMHOUBZWLNJCDRWXOCT43UECHU5ANCNFSM5CSWSX7Q. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[gskjold]

I have looked at the message format, and it is no problem to implement. As soon as you have some hardware, I can provide a test version

[ArnieO]

@gskjold That is good to hear!

AmsToMqttBridge can run on ESP32, so it seems like a good choice here instead of ESP8266, as it facilitates reading of hourly prices from ENTSOE API. Or do you see any disadvantages using ESP32 in stead of ESP8266?

And if ESP32, which version? I have some ESP32-WROOM-32D lying around, but I see here that it is not recommended for new designs; the latest version seems to be ESP32-WROOM-32E - and as far as I can see they are pin compatible, so I should be able to use my old modules.

I have ordered RJ12 plugs and short RJ12 cables, so it could be possible to have a board ready for testing by @robwiklu within 4-8 weeks from now.

Edited: Added link to 32D datasheet

[gskjold]

I cant see any disadvantage in using ESP32. I have used Lolin D32 with a MBUS adapter in testing from the beginning without problems, and every version gets tested on this card before release.

As for versions I am not too familiar with any of them. If it is anything like the ESP8266 lineup, 32E probably has some improvements over 32D, but has identical interface.

[robwiklu]

Awesome! :)

I have ordered RJ12 plugs and short RJ12 cables, so it could be possible to have a board ready for testing by @robwiklu within 4-8 weeks from now.

[robwiklu]

I have looked at the message format, and it is no problem to implement. As soon as you have some hardware, I can provide a test version

Great! :) Hopefully then with the new hardware and you updating the software, we can get a really nice working solutions for the uncompliant Aidon meters here in Sweden. I know many have struggled.

[ArnieO]

The key difficulty lies in the firmware, and I can assure you that the term "many have struggled" applies to AmsToMqttBridge as well!

The development started in 2017, in this thread that now has more than 2000 (!) postings. Sadly, @roarfred who started the work passed away in 2019. Fortunately, @gskjold was on the sideline (I think) and took over the maintenance - and has made significant improvements and contributions to making the firmware what it is today.

My work has been on the hardware part, where I have finally found a way to pull all the needed power from the MBUS port, which was a challenge (maximum 144 mW). You can see my initial struggles in this thread. Finding the right buck converter was one key. An other key was to abandon the TSS721 M-bus transceiver chip. This chip is the "normal" component for interfacing with an MBUS signal, but quite complicated to use - and is bidirectional (which we do not need).

Just to give you some glimpses of my hobby-work over the last 2-3 years!

The beauty of the "Swedish" RJ-12 interface is the 5V supply line where "infinite" power can be drawn ("infinite" here meaning 1,25W :smile: )

[ArnieO]

The PCB for a new "Pow-S" is coming together. The 'S' is for Sweden, I assume that is OK - or is the RJ12 version used in other countries?

Design features are:

• ESP32-WROOM-32x microcontroller, enables reading energy prices from internet
• The usual RGB LED: Blue pulses signify incoming data, R and G channels used by microcontroller
• Voltage divider resistors to enable microcontroller to read Vcc on GPIO35
• Header pins for external voltage (used during initial programming and later debugging)
• Staggered holes for FTDI adapter, just push in a header pin row, and you'll have good contact for programming.
• Probe test points for GND, 3.3V, 5V, HAN

I did not include a temperature sensor, as I do not see the need for it.

[robwiklu]

Thank you for the background, @ArnieO! Sad to read about @roarfred, but I'm sure that he's happy that you and @gskjold took over the work, continuing his legacy.

The design is looking good! The RJ12 port is also used in meters in Netherland (and very probably in other countries as well), so perhaps it should be more neutral if you are targeting other countries, too? The Swedish non-compliant Aidon meters is a mix of the Netherlands standard and the Norwegian as I understand it.

I found a fork of a project here with some tips also. Especially the firmware part can be interesting there as his code apparently work with the Aidon 6442SE meters from Tekniska Verken (the currently uncompliant ones). https://github.com/forsberg/esphome-p1reader/tree/branschrekommendation-1.2-tekniska-verken

Thank you for the good work! Have a nice weekend!

[ArnieO]

Thank you for the link! What exactly do you mean by «uncompliant»? It would be useful to have a link to whatever is the standard. What I have seen so far is the Aidon documentation, but there must be a written and published standard from relevant Swedish authorities?

Maybe you have a similar situation to Netherlands, where they talk about non-compliance to Dutch Smart Meter Requirements (DSMR)? See this link: http://domoticx.com/p1-poort-slimme-meter-hardware/

[robwiklu]

Well, uncompliant was maybe not the right word, but as I understand it is a mix. Yes, it like the Netherlands. I found this link today: https://www.tekniskaverken.se/siteassets/tekniska-verken/elnat/aidonfd-rj12-han-interface-sv-v16p-210517.cleaned-1.pdf There it mentioned what I had heard, that they will update their meters maybe in Q4 to the standard 62056-21.

[ArnieO]

Thank you again, and it seems like this document is the base for the data format on Swedish meters: https://www.energiforetagen.se/globalassets/energiforetagen/det-erbjuder-vi/kurser-och-konferenser/elnat/branschrekommendation-lokalt-granssnitt-v2_0-201912.pdf

The ultimate standard to be used in Sweden seems to be ASCII-based according to IEC62056-21:2002 Mode D , with data Transmitted at 115200 baud.

The board I’m working on would handle it, no problem. But as far as I can see, it would need significant work on the firmware. I will leave it to @gskjold to consider if such a significant update is within the scope of his intentions for AmsToMqttBridge.

[robwiklu]

Thank's! Well, I guess we'll have to wait until @gskjold have a look at it. I understand it will need some work. Have a nice weekend everyone!

[gskjold]

I also see that it says ASCII in that last document, but the format is the same as described in https://www.skekraft.se/wp-content/uploads/2021/03/Aidon_Feature_Description_RJ12_HAN_Interface_EN.pdf which states that it is wrapped in a HDLC frame, same as Norwegian standard. I think this is straight forward. If it turns out it is something completely different, I'm sure we'll find a solution for it.

[ArnieO]

Great! I’ll proceed with PCB order then, so we have something to play with. Maybe Pow-RJ12 is a better name? Or Pow-E (for Europe)?

[robwiklu]

Hi! Great you both will continue forward with this! The naming, I'm unsure. It will probably be difficult if different countries in EU have different standards, or picking parts of standards and making their own. Perhaps RJ12 is better, but then again, it could be different software needed because some does not follow the standard.

[ArnieO]

I decided to keep the "S" (it is not really that important, and I'd like to proceed with one letter). So I ordered PCBs now. Based on previous experience, they will arrive before the RJ12 connectors, which is the only part I do not have on stock.

[robwiklu]

Great you have them ordered :) Hope they'll arrive soon. Thank's for the update!

[ArnieO]

PCBs arrived now. https://twitter.com/amsleser/status/1450423882763153409?s=20

[ArnieO]

Except for some minor issues with the silkscreen (some text is not there, and +/- on Vext plug are in wrong positions) - the prototype board is now ready. It is possible that we will need to invert the data signal, which there is currently no option for in the code - and @gskjold has confirmed it is a minor thing to add in a firmware update.

And I just remembered the data rate must also be changed; the HAN-signal is 115 200 baud. I'm sure @gskjold will manage that too quite easily.

I now just need to wait for the silicon glue blob to cure before I can send it (tomorrow probably) to you @robwiklu for testing. If firmware upgrade is needed after I ship, it is easy to upload new code to it from the the GUI.

[robwiklu]

Very nice! Looking forward to testing :) Great job!

[robwiklu]

Hej!

Då testar jag i afton. Tack!

Mvh,

Skickat från min iPhone

25 jan. 2022 kl. 12:38 skrev Gunnar Skjold @.***>:

 Closed #110.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.