Reading from a SDM120 meter using EmonHub

Late joiner to the party here - exciting progress. Having been looking for a robust approach to sub meter multiple high load circuits on OEM, v. much appreciate the efforts . We’ve just had to plunge into a full house rewire so have spec’d x5 sdm120’s as part of it. Hoping I can contribute to some testing re: modbus daisychaining in the near future.

1 Like

Hello @thedawnbefore great to hear.

Perhaps a relevant note, not sure, but having got the SDM120 to work here using MBUS rather than modbus, I’m going to use the MBUS versions going forward for my own heat pump monitoring related development. I can then use the same MBUS reader to do both the electricity and heat meters on the heat pump. If you need to do any heat metering using MBUS it might be worth considering speccing MBUS SDM120 meters instead…

Thank you that’s v. helpful @TrystanLea. I certainly intend to implement the OEM heat pump monitor in line with the recommended MBUS heat meter interface so would love to be able to make use of the same reader.

Have you had any luck reading from multiple meters yet?

Trying to find some affordable SDM120-MBUS units but they seem rarer and more pricey - were you able to find a good UK distributor for them? Thanks again.

Great, Im almost there with the code for multiple MBUS meters, should have it done by the end of the week. I bought my SDM120-MBUS meter from:
SDM120-MBUS-MID — Innon Energy LTD (£35.44 ex VAT)

V. helpful, thank you, sir. Excited to get this going and help test.

Hello @thedawnbefore I’ve put together a blog post here discussing using EmonHub to read from multiple MBUS meters, including a bit on the latest version of the heat pump monitor :slight_smile: Reading from multiple MBUS meters with the EmonHub MBUS interfacer

1 Like

@TrystanLea, nice topic about MBUS! Any ideas about possible progression on the daisy chained modbus meters? I started a topic ’ Publish to mqtt broker of emoncms’ so that I might use my own Python-script that already can read daisy chained modbus meters. But at the moment I don’t have any progression on that either. Unfortunately: too many questions, too less answers…

1 Like

Very nice, thank you @TrystanLea. Looking forward to working my way through this and will certainly join the queue for one of those Mbus heat pump base boards - just need to get that ASHP fired up now!

Thanks @m2ts I havent had a chance to look at the Modbus interfacer yet, but hopefully some of what I’ve done on the MBUS interfacer is now transferable.

Thanks @thedawnbefore, great will have one here with your name on it.

1 Like

Plans for my OEM Heat Pump board have been thwarted as the ASHP provider have confirmed they need to fit both a Modbus Heat Meter and electric meter (SDM630) as part of their own system. As much as I was hoping to implement the new OEM Heat Pump solution, seems I’m going to have to find a work around with Modbus (assuming it’s possible for two devices to read a Modbus device on the same circuit?).

I wondered if there had been any further progress in the multiple modbus front if so? Ta

I think you will have a big problem there. Modbus works by having just one controller on the bus, and all the other devices are slaves. Only the controller can initiate any action, the slaves can only respond. If you do have a second controller, you are likely to get conflicts and corrupted commands or data. That happened and was raised on this forum relatively recently - maybe even in this topic.

Drat… and thank you (and apologies to have missed earlier coverage on this issue). Sounds like the best route is to stick with plan A and an Mbus SDM120 in series with the utility company’s Modbus meter.

Seems Ofgem’s MMSP monitoring intiaitve is compelling certain ASHP installers (in my case Igloo) to put in connected (albeit proprietary) heat and energy monitoring system in order to secure the rebate - and while it seems a shame to have to duplicate on the hardware, appears this will be the only way to get quality ASHP data into emonCMS. I see another community user has been exploring ways to benefit from the MMSP and emon overlap.

Can you get any more info? The need for metering heat and elec consumption is probably for RHI. That requirement doesn’t insist the meters are modbus or able to talk to each other. Whilst I cannot rule it out I doubt the ASHP will be the modbus master, therefore I suspect there will be another device, I suspect that may just be a TCP modbus adapter to enable remote readings and monitoring.

With modbus TCP you can have many “master” devices as they access over TCP and each request is handled independently, without knowing where the query is originating as long as it is authenticated. So you may not need any workaround if you can get the required access info from the installer.

Fingers crossed :grinning:

Perhaps listening to modbus or mbus frames as requested by the master could be an option without interfering with the communication in any way. I think it wouldn’t be too hard to repurpose the code in the EmonHub MBUS interfacer to do this, but it’s not something the code supports at the moment in it’s current form. I assume the same would be possible with Modbus?

Hi,

I have set up a local copy of EmonCMS. I am trying to read two modbus meters - SDM230’s. Following the guidance in this thread, I am able to read address 1 or address 2 but not both together as previous folks have discovered. By duplicating the SDM interfacer in emonhub.conf but with a different node name, I can get 2 lots of values to list in the inputs screen but only values update for one address (though i get occasional updates for the other address if i set the read interval to say 9.5 on one and 6.3 on the other). It has been suggested earlier in the thread that the problem lies with requesting modus data from both simultaneously.

I’d like to suggest the addition of a delay variable to emonhub. At 10 second intervals, it ought to be easy to poll address 1, wait for 5 seconds, poll address 2, wait 5 seconds and poll address 1 etc.

It has been a near vertical learning curve for me to get this far and tweaking code is well outside of my abilities but I’m hoping that if i could suggest this to @TrystanLea , I imagine he could implement this in 10 minutes flat. It might not be the prettiest of solutions but it would be a workaround all the same (I think!?).

Regards,
Mark.

As I wrote above, the bus is not designed to have two controllers on it requesting data.

It’s been decades since I did any work on Modbus, but I can imagine that if a controller saw another controller on the bus, it may well generate errors even if you can somehow create a mechanism to interlace the several requests so no actual data collisions happen on the bus.

I think the general solution, if you need the data in two or more places directly from the bus, will be to implement low-level code that listens to requests from the controller, then sniffs the response and processes it.

It means of course that the listening device can never make a request for data, it depends on the bus master making all the requests.

Hi Robert,

Thanks for the reply. When you say controller- is that the two sections I’ve basically duplicated in emonhub? I have one usb to rs485 adapter and have wired both meter modbus terminals to that in parallel. I can successfully get all the data from address 1 or address 2 without rewiring anything, just changing the address in emonhub. I’m not sure what you mean by needing the data in 2 different places either?!

Regards,
Mark.

No, I’m talking physical controllers. One controller should be able to accept a queue of “instructions” to query many devices and obtain their data in turn. The whole idea behind the data bus is that multiple devices can be connected in parallel, the Modbus protocol lays down that there must be only one controller, but there can be many slave devices. Only the controller can initiate a bus transaction - either to issue an instruction that does not need a response, or to request data from a specified slave, whereupon the slave is expected to respond. The controller’s software API should be capable of handling all this, and I would expect the software driving it would be able to send the appropriate instructions in the correct sequence.

Now the disclaimer: I don’t know whether the interfacer is capable of this, nor how to set it up to do it. But looking back up the tread, it would appear Trystan anticipated that putting the two requests into the Interfacer (post no. 105) would work.

I have been trying more things…

with the config as per post 105 i get:

ERROR MainThread Unable to create ‘SDM120’ interfacer: sequence item 0: expected str instance, int found

With the settings as per Trystans post in 112, I had thought it was only reading one meter as that’s all that shows in the inputs. I have noticed in the debug log though that all values from both meters are being read, they just aren’t showing as two separate entries on the inputs tab as there is only one nodename defined I guess.

2022-02-07 12:08:00,673 DEBUG SDM120 1 Values : [246.81, 0.955, -22.4, 235.8, -0.095, 50.049, 2544.823, 592.085, 7.582, 246.9, 3.483, -858.5, 858.7, -1, 50.098, 0.389, 326.029, 0.029]

I think that’s the post I was looking for. I had remembered that some work on multiple devices had been done, but not which Topic and where, and didn’t spot it (for the same reason that you didn’t :wink:).

<wish-list> Clearly, there’s a bit more work needed by @TrystanLea to create a general multiple-device Interfacer, because there’s an obvious problem if you have multiple non-identical devices on the bus.</wish-list>

There’s an obvious work-around - treat the two as one Node, and give each item a name that reflects its source - ‘M1-’ or ‘M2-’ say. It’s not ideal, but it’ll get you going, and if Trystan does come up with the goods, you can replace it and send to the same feeds.

1 Like