21

According to the Sharky 775 manual it seems the default address id is 0x2F (or 47).

I would not go any higher than 164, a brief look at the emonhub mbus interfacer code starting from L61 and working backwards, all the values used when that line is called are hardcoded except for one, the address. Since bytes can only be 0-255 (I’ve no idea why the later error line says 0-256?) and that address is summed with a hardcoded 0x5B (91) immediately prior to line 61, it can only really be 0-164 or it will become higher than 255 and not fit the data frame.

Is that just three values you’ve tried 0, 256 and 80? And that 80 is what the unit shows as “primary address”?

From the manual

2.6 Addressing
The meter can be addressed using two addressing variants: with a logic address (primary address)
or by using a filter via its ex works identification (secondary address)

the latter “ex works identification” being the “MBus ID = 0x2F” I’d presume.

I don’t use MBus and I haven’t read the whole manual as I don’t own a Sharky 775, so please forgive me if my suggestion of trying address = 47 fails or indeed if you have already tried that.

22

I’ve tried address = 0, 1, 80 (which the unit shows as primary address), 254/255/256 all cause lots of errors, I’ve just tried 47 and 164 which also produce the data : none error.

I’ve tried changing the polarity of the MBus connection (although the sharky suggests that it auto corrects polarity)…

23

Unless the meter is secondhand or you have changed the id yourself, set the address = 47 in emonhub and leave it as that whilst you try other things like polarity. Unless you have reason to believe the address isn’t 47, we have no reason to not believe the manual and stick with that (for now!).

Do you have the sdm120 usb adapters connected? Have you deleted the modbus interfacer whilst testing the Mbus? Focus on one at a time and keep the other well out of the frame.

To “delete” the modbus interfacer (or any other interfacer), just add a hash (#) to the line that defines the interfacer Type eg

[[SDM120]]
    #Type = EmonHubSDM120Interfacer
    [[[init_settings]]]
        device = /dev/ttyUSB0
        baud = 2400
    [[[runtimesettings]]]
        pubchannels = ToEmonCMS,
        read_interval = 10
        nodename = SDM120

if any interfacer config is minus a Type it is ignored, it’s much easier than deleting or commenting out the whole section each time.

Can you execute this command

printf 'alias lsser="ls -la /dev/{tty{ACM,AMA,S,USB},serial}* 2>/dev/null"\n' >> ~/.bash_aliases && source ~/.bashrc

from here on in you can check the serial and usb device addresses with just a lsser command.

pi@RedPi:~ $ lsser
lrwxrwxrwx 1 root root          5 Jan 26 14:17  /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root          7 Jan 26 14:17  /dev/serial1 -> ttyAMA0
crw-rw---- 1 root dialout 204, 64 Jan 26 14:48  /dev/ttyAMA0
crw-rw---- 1 root dialout   4, 64 Jan 26 14:48  /dev/ttyS0
crw-rw---- 1 root dialout 188,  0 Feb  3 19:42  /dev/ttyUSB0

if you can check to see what devices we have, with just the Mbus connected do you have USB0? If not, start again by rebooting the Pi without the adapter, run lsser then plug in the usb mbus adapter and check again, USB0 should hopefully pop up on the 2nd run.

With the device /dev/ address confirmed and the id address = 47, try again, if no luck, reverse the 2 wires and try again.

I was in the process of posting a similar reply to you on the modbus thread, but now my pasta’s cooked I must disappear for a bit of food without finishing. If I don’t nod off immediately afterwards, I will try and get back.

24

Ok - so I’ve run the lsser command - the sdm120 adapter is unplugged (I have been trying the ‘one at once’) and also removed the code.

I get

lsser
lrwxrwxrwx 1 root root          7 Feb  3 20:11  /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root          5 Feb  3 20:11  /dev/serial1 -> ttyS0
crw-rw---- 1 root dialout 204, 64 Feb  3 20:12  /dev/ttyAMA0
crw-rw---- 1 root dialout   4, 64 Feb  3 20:11  /dev/ttyS0
crw-rw---- 1 root dialout 188,  0 Feb  3 20:14  /dev/ttyUSB0

/dev/serial:
total 0
drwxr-xr-x  4 root root   80 Feb  3 20:11 .
drwxr-xr-x 15 root root 3540 Feb  3 20:11 ..
drwxr-xr-x  2 root root   60 Feb  3 20:11 by-id
drwxr-xr-x  2 root root   60 Feb  3 20:11 by-path

Repeating this with the polarity reversed (and rebooting in between for good measure) produces exactly the same result (albeit with a different time!)

25

Do you mean the lsser command returns the same? It would to. And reversing the wires will not effect this test. Sorry I should have been clearer.

With the address confirmed with lsser (done, it’s USB0) and the id address set in emonhub to 47, try emonhub, check emonhub.log, restart emonhub (or delete and recreate the interfacer by adding a hash, saving and removing the hash) if needed. If no joy, reverse the wires and retry emonhub again. Is there any change? Either to what you’ve seen before or to each other?

26

OK - I’ve tried that (and rebooted the whole thing in between for good measure!) but still just get the

DEBUG    MBUS       Decoded MBUS data: None

at all times

27

I’m not sure I can help further as I have no mbus experience or mbus device to play with, but I’ll though a couple of ideas your way whilst you wait for Trystans help.

Try multiple pages eg pages = 0,1

The reason I say this is because looking at the interfacer code, if you have only one page, it tries once, then retries after 0.2s and then gives up.

whereas if you have multiple pages defined, it seems to retry 10x and looks significantly different to the single page attempt, it uses a different data request and a different frame layout.

however, the number of sleeps suggests this may have been “tuned” to the device Trystan is using, I have no idea how many different devices he has tested with.

if there is only one page or you only want to access the one page use the same page number twice eg pages = 0,0 perhaps? It certainly works differently if there are a list of pages rather than a single item because of this

Beyond that I would need to get you to add some more debug log lines to the emonhub source code to work out where it’s falling over, that can be slow and messy. Hopefully Trystan will have some better ideas.

This is worrying!

Unless the Sharky has some form of short circuit protection, doing that might cause physical damage to the outputs as the voltages involved are not low (24 VDC if IIRC) and that 3rd pin is a ground connection.

Can you please confirm you are currently using the 2 furthest right terms on the top edge of the pcb as pictured in post 18 and NOT the “two nearest the centre of the board”?

Much like my advice in the other (modbus) thread, I think some direct comms via a simple script is needed to confirm the device is alive and connected correctly. Unfortunately, whilst i do have modbus experience and devices (just time is a bit thin), I have no mbus experience nor devices. Sorry.

As a side note here, I have glanced through the manual for the Sharky and also the MBus protocol documentation (Documentation – M-Bus) and I’m rather glad I was never tempted by the promises of a simpler protocol, I see nothing simple about mbus at all!!! Long live modbus I say!

28

The sharky leaflet says there is

Configurable telegram, according to EN13757-3, data reading and parametrization via 2 wires
with polarity reversal protection, auto baud detect (300 and 2,400 baud)

So I assume polarity at least is protected,

Correct. The board I have has the labels hidden by the terminal block which caused initial confusion.

I’ve tried all sorts of various pages syntax to no avail so far.

There’s a communications data sheet available Here. Most of it is over my level (which isn’t hard!!) but I notice this…

3.2 Request response
The following command must be sent to obtain a response from the meter SHARKY 775: REQ_UD2 10 7B AA CS 16 RSP_UD

Is this something different to the Sontex? I’m really wishing I insisted Stockshed sold me the Sontex now!!

Thank you again for your help with everything

29

Hello @richardsmith99 how frustrating! Id be happy to try to help via a remote access connection using dataplicity if that would be helpful? You can setup an account and link your pi using the instructions on dataplicity here https://www.dataplicity.com, you just need to copy a single command onto the pi and it installs everything for you. If you choose a username and password that you dont use for anything else and are happy to PM me the details I can login and try and get this talking for you. You can then change the password on the dataplicity account once Im done so that I no longer have access. Shall I give you a ring and we can chat this over? If you can send me a private message (PM) on here with your number and a convenient time I will give you a ring.

30

Done :+1: Thank you

1 Like
31

Im pleased to say that we’ve found the main issue with @richardsmith99’s MBUS reader. It turns out that the new programmer in the shop has it’s orientation flipped, and the picture of the programmer in the guide shows the SMT components on the top, whilst with the new programmer the SMT components should be on the underside. The main issue being that I had not put a GND label on the MBUS reader board to indicate the right connection orientation.

This is what the orientation should be for the new programmer:

mbus_new_usb_uart_reader
mbus_new_usb_uart_reader800×796 316 KB

After that I needed to update the emonhub MBUS interfacer to expand the variable types it supported. I have written the MBUS interfacer as a relatively minimal implementation of a full mbus decoder without needed external dependencies.

Using rSCADA - Raditex control systems and GitHub - ganehag/pyMeterBus: Pure Python implementation of the Meter-Bus (M-Bus EN13757-3) protocol. I cross check what the full set of readings should be for a given attached MBUS meter and then add the required fields to the emonhub MBUS interfacer.

Im not 100% sure that this is the right approach in the long term. It may be better to just use the pyMeterBus library and have full frame decoding support. Something I may revisit.

The EmonHub MBUS interfacer now supports reading the following values from the Sharky 775:

  • Cumulative Energy in kWh
  • Cumulative Volume in m3
  • Power in Watts
  • Flow temperature in Celsius
  • Return temperature in Celsius
  • DeltaT in Kelvin

Flow rate is also available but I haven’t quite managed to decode this one properly yet.

1 Like
32

A candidate for the FTDI Programmer Guide, methinks. Shall I send an update request to Gwil?

33

Yes It would be a good idea to review what is said/shown where and update to reflect it if needed. I will try and have a look as well.

34

Basically, a couple of lines and that image.

35

Aha, I hadn’t seen that guide, that’s great! I see what you mean now.

36

Is that a new OEM system wide usb programmer, not just mbus? ie does this info also apply to all emon devices when using a 2021 OEM usb programmer. If so are there distinguishing marks between a recent programmer and a new programmer?

Is this latest one built on a FTDI chip? Which one? Does it have an eeprom?

Great job getting @richardsmith99 sorted :+1:

[Edit} Ok just looked it up myself in the shop and then the ftdi website, did I miss an announcement on this?

from the datasheet

8.2.1 Programming the MTP memory over USB
The MTP memory on all FT-X devices can be programmed over USB. This method is the same as for the EEPROM on other FTDI devices such as the FT232R. No additional hardware, connections or programming voltages are required. The device is simply connected to the host computer in the same way that it would be for normal applications, and the FT_Prog utility is used to set the required options and program the device.
The FT_Prog utility is provided free-of-charge from the FTDI website, and can be found at the link below.
The user guide is also available at this link.
Utilities - FTDI
Additionally, D2XX commands can be used to program the MTP memory from within user applications.
For more information on the commands available, please see the D2XX Programmers Guide below.
http://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer’s_Guide(FT_000071).pdf

This is really good news for users that want to serially connect multiple emonTx’s eg a 3ph install with 3x emonTx.

37

Seconded! I’m eternally grateful!

2 Likes
38

The new FTDI programmer has been on sale since the beginning of this year. Looking back through the forum, I can’t see an announcement of this - that was a mistake, sorry.

Very many thanks to @Robert.Wall for all his work on updating the documentation for both the old and new programmer.

1 Like
39

New Sharky 775 owner here.

My meter came with channel/address 25 as default.

Which was shown on the display as
Pri_Adr 1
(menu rotation 3)

As detailed in the manual.

Rest of EmonHub config…

[[MBUS]]
    Type = EmonHubMBUSInterfacer
    [[[init_settings]]]
        device = /dev/ttyAMA0
        baud = 2400
    [[[runtimesettings]]]
        pubchannels = ToEmonCMS,
        read_interval = 10
        validate_checksum = False
        nodename = mbus
        [[[[meters]]]]
            [[[[[sharky775]]]]]
                address = 25
                type = standard

image
image1194×791 34.2 KB

Hope that helps someone out if they get stuck.

[edit by Mod - added file directly]

SHARKY_775_IOM.pdf (2.8 MB)

1 Like
40

Thanks @Zarch !

1 Like