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?
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!
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!!
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.
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:
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.
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.
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?
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.
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.
And as another new Sharky 775 owner (thanks to those already using, and reporting on their implementation), my meter came with address 76 already selected.
[BTW, I misread Mick’s message above as saying the parameter “Primary Address” was set to the value “1”, and I was about to message asking how that related to address being 25. Doh!
He is of course actually saying the parameter “Primary Address 1” has a setting of 25, as will appear in menu rotation 3. Becomes more sensible when you appreciate the M-bus concept of a device having two addresses on which it will respond. I know that now.]
Another Sharky 775 snippet for folks that get stuck.
The mbus connections only work one way around. You can’t flip these as you won’t get any data.
I found this after having it all working on my desk, then having it stop reading when I recabled it when putting it in into the final destination. A bit of head scratching and then flipping the mbus connections at one end sorted that.
Thank you
