RC12 ultrasonic heat meter via M-Bus

Einklappen
X
 
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
  • kunszabo
    Azubi
    • 25.10.2024
    • 3

    #1

    RC12 ultrasonic heat meter via M-Bus

    Hi,

    Has anybody managed to use RC12 ultrasonic M-Bus heat meters with the Loxone M-Bus extension? The extension finds the meter but after that I cannot read out the registers because Loxone says the meter is offline (which is not true... the meter works fine).

    Contacted Loxone support but they were not able to provide me a solution for this problem.

    BR,
    Zsolt
  • ivi
    Azubi
    • 08.05.2025
    • 3

    #2
    Hi Zsolt
    have you managed to integrate your meter using the M-Bus extension?
    I have exactly the same issue with heat and water meters from ISTA.

    Kommentar


    • kunszabo
      kunszabo kommentierte
      Kommentar bearbeiten
      Hi,

      No, unfortunately it is still not working. I was in contact with the Loxone support as well but they were not able to give me a solution. They suspected that the meter is probably running in master mode and the M-Bus extension is only able to communicate with slaves. But I think the meter is not a master (that would be anyway wierd for a battery powered device...and I think the m-bus search would also not find the masters), I also tried to contact the manufacturer with the hope I could get a detailed m-bus protocol implementation document from them regarding their meter but I haven't even received any response. SItuation is quite annoying.I also hoped that sooner or later one of the loxone updates would solve the problem but this is still not the case, I am running the latest version and I still have the same problem. If you manage to find a solution let me know please.
  • ivi
    Azubi
    • 08.05.2025
    • 3

    #3
    Same here, Loxone even provided me an alpha version with the option to search for primary addresses because certain meters could not be found. But the meters went offline as soon as I tried to use one of the values. Loxone then stated that the length field in the telegram is wrong but I checked that and the length field is correct. For me it looks like there is a lack of knowledge regarding m-bus and not enough pressure from customer side, so they don't invest in this currently. My next step is to try the following device https://www.solvimus.de/de/produkt/m...0m-mbus-ge80m/ . Solvimus told me their gateway is working with loxone in other projects.

    Kommentar


    • brownbug
      brownbug kommentierte
      Kommentar bearbeiten
      Hi ivi,

      thanks for sharing your experience, unfortunately it fully matches ours.

      Yes, Solvimus might work technically, but at 700–750 EUR it is simply not a reasonable solution in this context. At that price point it is often cheaper to replace the meters themselves.

      On top of that, adding another gateway into the system:
      - increases complexity
      - adds another potential point of failure
      - adds another device to configure, maintain and debug

      All of this just to work around a limitation in the Loxone M-Bus implementation.

      The core problem is not the availability of expensive third-party gateways, but the fact that the Loxone M-Bus Extension cannot reliably handle extended M-Bus telegrams, and this limitation is neither fixed nor clearly documented.

      Without proper documentation, customers keep investing into hardware that cannot work by design, and are then pushed towards costly external workarounds.

      At this point the situation is technically disappointing and architecturally unnecessary.
  • kunszabo
    Azubi
    • 25.10.2024
    • 3

    #4
    Hi,

    Let me know if you manage to read those meters using de solvimus+loxone combo. I am curious to see whether that would work. Anyway, if the Solvimus device can read the meters then we could approach loxone with this message proving them something is wrong at their side.

    BR,
    Zsolt


    Kommentar

    • ivi
      Azubi
      • 08.05.2025
      • 3

      #5
      we managed to integrate the ISTA-meters using the solvimus-gateway. In our case I think it is the telegram size wich is to big for the loxone m-bus gateway.

      Kommentar

      • brownbug
        Azubi
        • In den letzten 2 Wochen
        • 2

        #6
        Hello,

        I would like to escalate an issue that is clearly reproducible and already confirmed by multiple users.

        Setup:
        • Loxone Miniserver + M-Bus Extension
        • RC12 ultrasonic heat meter (also confirmed with ISTA heat and water meters)
        • Standard M-Bus wiring, correct addressing, meter detected during scan

        Observed behavior:
        • The M-Bus Extension successfully detects the meter during scan
        • As soon as any value is requested, the meter goes offline in Loxone
        • The meter itself continues to operate normally and can be read by other M-Bus gateways

        Facts:
        • The meters are EN1434 compliant and use standard M-Bus slave mode
        • The issue is NOT wiring, NOT addressing, NOT baud rate
        • Loxone support already tested alpha firmware versions
        • Loxone stated that the telegram length is problematic
        • External gateways (e.g. Solvimus M-Bus gateways) read the same meters without any issue
        • When using Solvimus and forwarding data to Loxone via Modbus TCP, everything works

        Conclusion:
        This strongly indicates a limitation in the Loxone M-Bus Extension regarding:
        • Extended / long M-Bus telegrams
        • Proper handling of large data frames

        This is not a device-side issue.
        It is a protocol implementation limitation on the Loxone side.

        Request:
        • Please confirm whether extended M-Bus telegrams are fully supported
        • If not, please document this limitation officially
        • Or provide a firmware update that correctly handles large M-Bus frames

        At the moment, the Loxone M-Bus Extension cannot be used with several widely deployed heat and water meters, which is a serious practical limitation.

        Best regards
        Barna

        Kommentar

        • kunszabo
          Azubi
          • 25.10.2024
          • 3

          #7
          Hi,

          Just to let you know what was the disappointing outcome of my discussion with the official Loxone support... I explained them everything and they said to open a formal change request but in the same message they also said the M-Bus extension is "not a priority" for them at the moment... nice support... I also told them to explain the limitations in the official documentation as the currently published documentation is simply misleading customers. Needless to say, documentation still has not been updated to explain such functional limitation and I have no feedback about the change request whatsoever.

          BR,
          Zsolt

          Kommentar


          • brownbug
            brownbug kommentierte
            Kommentar bearbeiten
            Hi Zsolt,

            thanks for the update. Unfortunately I can fully confirm your experience.

            I also burned a serious amount of money and time on this. If this limitation had been documented properly, I would have chosen a completely different solution from the beginning.

            The most frustrating part is not even the technical limitation itself, but the attitude:
            - known issue
            - confirmed by multiple users
            - confirmed indirectly by support
            - “not a priority”
            - and still zero transparency in the official documentation

            As a result, users keep buying the M-Bus Extension in good faith, only to discover later that it is unusable for many real-world meters.

            Out of pure frustration I already started commenting under every official Loxone YouTube video related to the M-Bus Extension, warning others that in these cases it is basically unusable and a waste of money. At this point it feels like the only way to prevent others from running into the same wall.

            What makes it worse is the feeling that this is simply being ignored.

            Thanks for documenting this publicly. At least now it’s clear we are not alone and not doing something wrong.

            Best regards
        • brownbug
          Azubi
          • In den letzten 2 Wochen
          • 2

          #8
          Hi everyone, especially Loxone team members,

          thanks for the previous replies. I would like to address this specifically to any Loxone employee or developer who can escalate product feedback internally.

          We are facing a clear, reproducible issue with the Loxone M-Bus Extension when used with real-world heat and water meters such as RC12 ultrasonic meters (also confirmed on ISTA meters). The Extension detects the meter, but fails to read any registers — reporting offline even though the meter continues to respond on the bus.

          Important technical points:
          • The meters are EN1434 compliant M-Bus slaves.
          • Scan finds the device successfully.
          • The problem occurs when reading extended telegrams (large data frames).
          • Third-party gateways such as Solvimus read the same meters without any issue.
          • This strongly suggests a limitation in the Loxone M-Bus firmware/protocol handler, not in the meters or wiring.

          This limitation is not documented anywhere in the official specs, and as a result customers spend time and money on hardware that cannot work with their meters.

          We also found this official Loxone YouTube video about the M-Bus Extension:


          We plan to leave a comment under the video pointing out this incompatibility unless there is official clarification from Loxone, so that other users are aware before buying.

          For transparency and community support, please clarify:
          1. Does the M-Bus Extension fully support extended M-Bus telegrams (large data profiles)?
          2. If not, can you provide a clear list of supported telegram sizes and/or incompatible meter types?
          3. Is there any timeline for a firmware fix or documentation update?

          We, and many others in this thread, are happy to provide packet logs if needed.

          Thank you.

          Kommentar

          Lädt...