MyImmersun 2.0

I received a mail today from the Immersun team saying that their new MyImmersun platform is available for Beta testing and with a link to the new web portal at https://myimmersun.com/

There’s a new registration procedure requiring a new account to be created. Once that’s done it displays a Dashboard view, initially with no Immersun device(s) connected. In order to on-board an Immersun device to the new platform it needs to be pointed at the new Server by updating the “Cloud IP” (to 136.243.233.046) – which will also remove it from the old MyImmersun platform. Then, with the device sending data to the new platform, the device needs to be “claimed” by the new login account by entering the MyImmersun Username & Password (obtained from the Immersun device menus).

Example of the new MyImmersun web portal Dashboard

The previous “Cloud IP” setting was: 051.052.112.077

Update February 2023: The “Cloud IP” setting has changed again (as of 2023-02-15) – the Immersun Status Page says to use 065.108.159.219

CC BY-SA 4.0 MyImmersun 2.0 by Marsh Flatts Farm Self Build Diary is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

10 thoughts on “MyImmersun 2.0

  1. Hi. Very informative website by the way.
    I’m part way migrated, iLink green-green and unit is acquired by dashboard but no data as yet. I hadn’t seen this move to V2.0 just the my immersun stats falling away so thanks for noticing and posting that. Maybe because I have an original.

    Did this move impact your UDP proxy setup?

    I am looking into building a UDP proxy myself to access the data stream for a Raspberry Pi MagicMirror setup so we can be right on top of when there is spare juice available.
    Any pointers would be most welcome.

    Best regards.

    • Hi Cliff, thanks for the feedback.
      When I first moved to the v2.0 server I took the UDP proxy out of the loop, in case there were any firmware updates or similar which I didn’t think my simple proxy would cope with. I did then put the UDP proxy back but after a few days the iLink lost contact with the server so I removed the proxy again.
      I should probably re-add the proxy and see how stable it is now.
      David

    • I previously implemented my UDP proxy script in Perl but it has some limitations and not sure if those are Perl-specific or not. These days I tend to use Python for scripting instead, so I’m inclined to try to re-write it in Python3 using the same packet decoding logic.
      Happy to share my code if you wish. Would Python work for you too?
      David

      • Hi David
        Yep. I envisage going the python on RPI route at the moment. Being a very long in the tooth IT pro, I’m not one for re-inventing wheels – so, I’ve found a couple of useful python UDP-Proxy examples on git

        I’d be very interested in knowing if your Perl still works and seeing the code… oh, very happy working with you to map it over to Python.
        Should be faster than the Perl too in theory.

        I’ve written some python in the past, incl. threaded streaming code, but I’d prefer to go the asyncio route with this.

        Happy to share all of my code too.
        Once I see your Perl, I’ll look to see what I have that might help the transition to Python and get you that.

        btw. In the background, I’m testing an php REST API server I built on my NAS to provide latest data from MariaDB via http POST. It returns:

        {“immersunData”:{“id”:”15″,”timestamp”:”2022-10-26 14:00:00″,”kwh_imported”:”0.00″,”kwh_generated”:”1.80″,”kwh_consumed”:”0.40″,”kwh_diverted”:”1.30″,”kwh_exported”:”0.10″}}

        I’m testing that with a simple web page.
        Then, test my MagicMirror module delivers it.

        Do you want to move this chat over to email to avoid clutter?
        You can then push to here as you see fit.

        • Hi Cliff,
          Excellent, thanks. Sounds like we’re very much on the same wavelength.
          I’ll dig out my Perl code and email it over and we’ll continue this conversation via email and then update others on here when we have something to report.
          David

  2. Hi, I found your v1 solution to interrogate the data real time from the immersun servers very useful. I can’t connect. To v2. Is it just a new server address. Thanks

    • Hi David,

      Sadly it’s not that simple. The new MyimmerSUN dashboard uses a different software architecture and it’s nothing like as straightforward to scrape the data from the website as with the old site.

      My preference is now to use a different approach and tap into the *outgoing* data packets from the immerLINK unit – which is in some ways more complex but does deliver updates at 5-second intervals and on the local network, rather than via the Internet.

      Cliff (from some earlier comments) and I are working on some new code to support that approach, using Python scripting. There’s a very much work-in-progress set of files at https://github.com/MarshFlattsFarm/immerSUN-Proxy-Server

      David

  3. Following with interest.

    I’ve been taking data from the old myimmersun system for some time to make my own real time monitor but including battery and other data. I’m looking to make that work with the new myimmersun system – potentially by intercepting the outgoing packets as you describe.

  4. Hi
    Further to my comments on github and getting your script working on my raspberry pi.

    i curious have you found a reliable method to sum the immersun data, for daily totals? its tricky due to live nature of data, and might be impossible if timing of packet captures is not consistent, my maths is poor though….

    even the app has different value for total diverted in a day compared to what unit shows e.g. yesterday the app had daily diverted energy total of 1.3kw yet unit recorded 1kw !

    • Hi Andrew,

      Short answer: No. In the past I’ve attempted this (for a different data source) by deriving a cumulative counter based on the latest reading and an assumption on the elapsed time since the last reading, but with mixed results.

      The immerSUN seems to send packets with a consistent 5-second interval, so it should be possible to calculate totals by assuming the latest reading represents the average over the past 5 seconds., with a bit of extra logic in the Python script.

      The other option is to use the power of whatever tools are recording the readings from the MQTT messages. On the GitHub Issue you mentioned you’re using Grafana; are you also using InfluxDB or a similar time-series database? That should have some capabilities to ‘integrate’ real-time readings into totals.

      David

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.