Announcement

Collapse
No announcement yet.

MyEnergi API

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    In post #7 was a 5.20.2.2 update where the IP setup on the Cloud page URL tab is the base IP and a new text box added to specify the endpoint. This was done in relation to supporting the control endpoint that were different than the status endpoint. You should be using the version in post #7.

    The warning in the log indicates an issue with how the Status Graphic tab on the HS Devices page was setup. I believe when you update the plugin version and change the settings as shown in post #7 that this control device will be recreated. If there is still a warning then we can look deeper.

    Since you are able to get data in the debug log I expect this same decoded JSON data to be showing on rows of the Association table. You screenshot shows only the control device row. Are there other rows that are not yet associated with HS device such as I showed in post #7?

    Comment


      #17
      I did another full reset and found the right combination of flags to get the json devices to show up.

      For other's benefit, list of steps (HS4):
      1. Install mcsMQTT plugin (free, from updater)
      2. Download zip file of updates from Michael's website - HS3: http://mcssprinklers.com/MCSMQTT_52022.zip HS4: http://mcssprinklers.com/MCSMQTTHS4_52022.zip
      3. Overwrite cloud.html in the HS4 html folder and the two dlls in the bin\mcsMQTT folder
      4. Start the plugin and check the version matches the updated dlls by going to Plugins->mcsMQTT->MQTT - General tab, top blue banner should show the version number.
      5. Setup up the plugin by going to Plugins->mcsMQTT->Cloud using the settings in "Cloud Settings" below.
      6. Optional - check polling is working, see "Debugging" section below.
      7. Now set up the devices you want to pull into HS4. Plugins->mcsMQTT->MQTT - Associations tab. The plugin reads the json package from the status polling and creates items for association in this tab, but there's a lot of devices. Ensure "Accepted Associations" is unchecked, this should automatically enable the "inbound" and "outbound" checkboxes. I then untick the "outbound" box. Click "show selected associations". I then found I had to click the next button to get to the items. You should see items like "Sub: URL/s1.myenergi.net:GET:Control-:asn" and "Sub: URL/s1.myenergi.net:GET:eddi:01:bsm".
      8. Tick the "a" column for any item you want an HS4 device for. I found the ones without GET:Control in the name gave me the status devices which update on each poll refresh (and they don't update the last updated time unless the value has actually changed).
      9. Go to Devices. You should have a new floor "URL" and room like "s1.myenergi.net"
      10. Each device you added will be here and show the values from your system. You will have to use standard HS4 functionality to then map status numbers to real values. You can find the ranges of the variables and their meaning on the github page here. I added status and graphics for ones like Eddi mode (sta) and Zappi status (sta).
      11. Note that some of the devices have a string value which you'll want to map to something like "EV Disconnected". See Post #22 for Michael's instructions on how to add the variables which come through as strings. Once created with the 1=A;A;A mapping on the MCS device page you will have all the strings and you can replace them with the text you want to see in the normal HS4 device settings page.
      12. To send a command on the control device there's a text box. You need to get the commands from the GitHub page. I have given an example below in "Example Eddi Boost" below.
      13. To send a command via an Event use MQTT action->Send MQTT message and use the syntax: URL/s1.myenergi.net=/cgi-eddi-boost-EXXXXXXXX-10-1-20 Other commands can be found on the GitHub page.

      Cloud settings
      URL: https://sX.myenergi.net
      where X is the last digit of your MyEnergi communications hub
      Poll: 30000
      Polling endpoint: /cgi-jstatus-*
      Protocol: GET
      Authorization: Digest
      Headers - leave blank unless you need to set a timeout due to slow internet then use timeout:15000 (I didn't need this but Michael did)
      Username: Password - use the communications hub serial number (8 digits, ignore the letters at the start) as the username and the password for the communications hub when it was installed (this is not the same as your MyEnergi.net account password) e.g. 12345678:987654

      Debugging
      If you have issues you can check if the polling is working by setting the debug setting on the mcsMQTT General tab ticking the first box which enables general debug. This creates a debug log in \Data\mcsMQTT\mcsMQTT Debug.txt. If working you should see something like this in the log:
      Code:
      05/10/2021 09:56:25 2450639 | ActOnMessageForTrigger QueueSize=0 ,Topic URL/s1.myenergi.net:GET,Payload {"eddi":[{"dat":"05-10-2021","tim":"08:54:23","div":183,"frq":49.89,"gen":886,"grd" :441,"hno":1,"pha":1,"sno":14303630,"sta":4,"vol":2348,"ht1" :"Tank 1","ht2":"Tank 2","tp1":127,"tp2":127,"pri":1,"cmt":254,"rbt":2394,"bsm":1, "che":0.66,"ectp1":183,"ectp2":546,"ectp3":886,"ectt1":"Inte rnal Load","ectt2":"Grid","ectt3":"Generation","fwv":"3200S3.048" ,"dst":1,"hpri":1}
      ]},{"zappi":[{"dat":"05-10-2021","tim":"08:54:23","ectp2":-3,"ectp3":4,"ectt1":"Internal Load","ectt2":"Grid","ectt3":"None","frq":49.89,"gen":886,"g rd":441,"pha":1,"sno":15511519,"sta":1,"vol":2405,"pri":1,"c mt":254,"zmo":2,"tbk":5,"che":0.00,"pst":"A","mgl":50,"sbh": 17,"sbk":5,"ectp4":3,"ectt4":"None","ectt5":"None","ectt6":" None","fwv":"3560S3.142","dst":1,"lck":16,"pwm":5300,"zs":25 6,"rdc":-4,"rac":4,"rrac":-8,"zsh":1}
      ]},{"harvi":[]},{"asn":"s1.myenergi.net","fwv":"3401S3077"}
      Example Eddi boost
      Type this (including leading "/" into the text box on the control device and press submit
      /cgi-eddi-boost-Exxxxxxxx-10-1-20
      xxxxxxxx- replace with your Eddi serial number. NOTE, this is different to your communications hub serial you use as your username/password. For Zappi you need to use the serial number for your Zappi.
      Attached Files
      Last edited by Mack1979; October 13, 2021, 01:28 AM. Reason: Added note about setting up string devices

      Comment


        #18
        What I haven't figured out is how to send a command via an event. I use Alexa heavily so I'd like to set an HS4 device with Alexa and have that trigger sending a command to MyEnergi. I can send a command via the device page but I can't see how to append a string and send a command using the plugin to myEnergi. I'm sure this is easy, I just can't see it yet. Looking for fairly simple workarounds because it's so close using mcsMQTT unless someone with a lot of time can write a lot of this extra functionality into a MyEnergi plugin.

        I'm also struggling with one of the variables (pst) which reports the EV connected status of the Zappi. This returns a string, but in HS4 the device value seems to be set to zero and the status string updates. The MQTT option to store the payload as value doesn't seem to be put the string in the value. The value to string mapping only seems to work for numeric values. At the moment I'm thinking of a series of events to take a status of A and set another variable to EV Disconnected but even they use the value not the status, so may have to have a script running in the background which I've managed to avoid in the main recently.

        Comment


          #19
          A note about the cloud settings.
          MyEnergi is in the process of moving servers around. this will migrate your entry point to the server
          So look at the ASN section of your JSON response. It will show the server name that you are assigned to.
          When this server name is different then you used with you call (probably S18.myenergi.net) then you are migrated and you have to use that new server URL for future calls
          - Bram

          Send from my Commodore VIC-20

          Ashai_Rey____________________________________________________________ ________________
          HS3 Pro 3.0.0.534
          PIugins: ZMC audio | ZMC VR | ZMC IR | ZMC NDS | RFXcom | AZ scripts | Jon00 Scripts | BLBackup | FritzBox | Z-Wave | mcsMQTT | AK Ikea

          Comment


            #20
            Originally posted by AshaiRey View Post
            A note about the cloud settings.
            MyEnergi is in the process of moving servers around. this will migrate your entry point to the server
            So look at the ASN section of your JSON response. It will show the server name that you are assigned to.
            When this server name is different then you used with you call (probably S18.myenergi.net) then you are migrated and you have to use that new server URL for future calls
            Yes, seen this on the MyEnergi forum and GitHub. They talked about sending a call to director.myenergi.net first as the response will give you the server number, but I've not been able to make the director call work. It would be useful to use director to get the server number and then use that in subsequent calls, but I think you'll have to stick with something more basic of finding the right server number and sticking with it, then having an event which compares the actual date against the date from the Eddi status and if they're different reporting to the user that the connection has gone down so they can investigate.

            Comment


              #21
              What I haven't figured out is how to send a command via an event.
              There are several ways to accomplish this. The most natural way is to control Device Feature 1725 in the event action as you do from the HS Devices page. Unfortunately HS has not yet provided for event action control on devices other than for numbers. What does work is
              1. Associate endpoints with HS Device Feature and then control that endpoint with Device Control of Send
              2. Use Send MQTT Message event action
              3. Execute script that does the same thing as the HS Devices page to send the control

              1
              __
              In post #4 the Association table screenshot shows the cmt endpoint being associated with HS Feature 939 and the following screenshot is Feature 939 with a Send Button for control. The equivalent event action then becomes as shown below where the Device is the cmt endpoint 939. Again looking at post #4 Asssociation table for 939 the pub topic is setup to be /cgi-jstatus-.*. In your case the command will be one to achieve the desired control rather than a status request. This approach makes sense when the cmt endpoint has an appropriate type of control. If it does not then a better endpoint would be selected to associate with HS Device Feature.

              Click image for larger version

Name:	Capture.PNG
Views:	300
Size:	16.9 KB
ID:	1500707

              2
              __
              The Send MQTT Message action sends the specified payload to the selected URL. It is the same URL that was setup on the Cloud page. The "=" is used to separate the URL from the Payload. It will start with URL/ so mcsMQTT knows it is a URL vs. MQTT destination.

              Click image for larger version

Name:	Capture4.PNG
Views:	214
Size:	66.5 KB
ID:	1500708

              3
              __
              CAPI control is used to command Device Features. It is run via script so the event action will be to run a script. The same Feature on the HS Devices page (1725 in your case, 933 in my example screenshot of post #4). One example is shown below where the action passes the ref number and command. The script CAPI.vb recognizes that the controlUse property has been set to _Not_Specified (value = 0) and uses this to get the CAPI control object. It puts the parameter passed for control in the ControlString property and then forwards the request via HS to the plugin owning the device for the control action.

              Click image for larger version

Name:	Capture2.PNG
Views:	214
Size:	25.8 KB
ID:	1500709

              Code:
              Sub Main(ByVal Parms as Object)
                Dim arrParm() as String = Parms.split(",")
                Dim dvRef as integer = ctype(arrParm(0),Integer)
                Dim strCommand as string = ctype(arrParm(1),String)
                Dim objCAPIControl As CAPIControl = hs.CAPIGetSingleControlByUse(dvRef,0)
                objCAPIControl.ControlString = strCommand
                If objCAPIControl IsNot Nothing Then
                  hs.CAPIControlHandler(objCAPIControl)
                End If
              End Sub

              Comment


                #22
                I'm also struggling with one of the variables (pst) which reports the EV connected status of the Zappi. This returns a string, but in HS4 the device value seems to be set to zero and the status string updates. The MQTT option to store the payload as value doesn't seem to be put the string in the value. The value to string mapping only seems to work for numeric values. At the moment I'm thinking of a series of events to take a status of A and set another variable to EV Disconnected but even they use the value not the status, so may have to have a script running in the background which I've managed to avoid in the main recently.
                The process you want to leverage is the VSP capability of HS to associate numbers with a text enumeration. The default for a payload received by mcsMQTT that is text is for the Control/Status UI to be set as Text and the payload stored in DeviceString. This can be changed from the Edit tab. Easiest way to get to the tab is to click on the Ref number of the associated topic. It will being up a popup that allows the various properties to be modified. What shows for pst is like the screenshot below, but I have changed the Control/Status UI from Text to the List radio.

                Toward the bottom of the screenshot are the VSP assignments that exist. It will show all the different value for pst that it has observed. Each new one it assigns the next higher number. In my test case I had only "A" received. I manually added "B" using the syntax "B=1;B;B". You can do this also if you know the other states for pst that have not yet been observed. The first B is the text observed in the payload. The second B is the status label. The third B is the control label that will be visible in HS Devices page.

                Click image for larger version

Name:	Capture.PNG
Views:	300
Size:	49.7 KB
ID:	1500715

                The HS Status Graphics will look like the following at this point. Note that there are no Control labels so HS is not able to send commands of A and B.

                Click image for larger version

Name:	Capture3.PNG
Views:	216
Size:	47.3 KB
ID:	1500716

                It may be a status-only Device Feature. In this case nothing else needs to be done. If controls are to be added then a Publish topic needs to be specified. It can be done either on the MQTT Association table or on the Edit popup. I put in on the popup in the screenshot below. IT shows at the top.
                Click image for larger version

Name:	Capture2.PNG
Views:	215
Size:	51.7 KB
ID:	1500717

                HS now has controls. Since the List Control/Status UI was selected the controls are shown as a list selector.

                Click image for larger version

Name:	Capture4.PNG
Views:	227
Size:	11.4 KB
ID:	1500718

                If Button rather than List radio had been selected then the UI are buttons

                Click image for larger version

Name:	Capture5.PNG
Views:	228
Size:	19.2 KB
ID:	1500719

                In my testing I did not confirm the operation of sending a "A" or "B" payload. It would be more likely that some other payload would be sent and it may be in JSON format. The exact format that will be sent in the payload is specified in th4e Publish Payload template which can also be found a little lower on the Edit popup. A blank template means to send the VSP text. These templates often contain replacement variables such as $$VALUE: to send the DeviceValue, $$LABEL: to send the control label. The full list of replacement variables are in Table 2 or 3 of mcsMQTT.pdf. Since there is special processing of URL vs. MQTT publishing I am not certain what will actually happen if you were to try this. If you have a need for sending one of an enumeration of commands via URL then let us discuss.

                Click image for larger version

Name:	Capture6.PNG
Views:	218
Size:	5.8 KB
ID:	1500720

                An anomaly I observed when I first selected the Control/Status UI to be List is that the HS status label was not "A", but was blank. Don't know why, but I fixed it on the Edit popup by replacing the original definition with the same thing "A=0;A;A"

                Comment


                  #23
                  Yes, seen this on the MyEnergi forum and GitHub. They talked about sending a call to director.myenergi.net first as the response will give you the server number, but I've not been able to make the director call work. It would be useful to use director to get the server number and then use that in subsequent calls, but I think you'll have to stick with something more basic of finding the right server number and sticking with it, then having an event which compares the actual date against the date from the Eddi status and if they're different reporting to the user that the connection has gone down so they can investigate.
                  This discussion may not help, but may provide some ideas. Let us say that you are getting a response from one of your URLs that has an endpoint of "ASN" and value of "S18.myenergi.net". You have associated this endpoint with HS Device Feature 123.

                  You have other URLs that want to use "S18.myenergi.net" or whatever is the most current payload in the first URL endpoint.

                  You can define on the Cloud Page a URL of https://$$DTR: (123):

                  mcsMQTT will read from DeviceString of Feature reference 123 to form the full URL.

                  You should also be able to do the same thing without the HS association and use the Topic reference rather than the Device reference. An example for the URL https://xyz that returns JSON {"ASN":"S18.myenergi.net"} as part of its payload.

                  The Cloud Page URL then becomes as shown below. I not validated this exact syntax, but the capability does exist. I also added space to separate colon and open parenthesis so this page would not render an emoji.

                  https://$$PAYLOAD: ("xyz:ASN"):

                  Comment


                    #24
                    I did try the dynamic IP address and there are some dependencies/assumptions that exist and preventing it from working as intended. If you want t use the the technique described in post 23 you will need to wait for the next update. The issue I have in my head is the accounting of a URL. It can be be before he expression is evaluated or it can be after. If after the side-effect is that multiple HS Device Features will be created as the URL/P changes. No big deal unless events exists based upon the original URL/IP and the URL has changed.

                    Comment


                      #25
                      Thanks Michael! Got the events working using method 1. It was just getting the right syntax. Got the mapped status working as well. I agree that the dynamic IP addresses adds a whole layer of complexity. I'm not playing with that just yet. I'll working on tidying things up and making my events more flexible (I've just done a basic 20 minute boost on Eddi to begin with to test, but using the variable replacement should be able to make this flexible and voice-controllable. I'll update the set of instructions above as I get it improved later on.

                      Comment


                        #26
                        Originally posted by Mack1979 View Post

                        Yes, seen this on the MyEnergi forum and GitHub. They talked about sending a call to director.myenergi.net first as the response will give you the server number, but I've not been able to make the director call work. It would be useful to use director to get the server number and then use that in subsequent calls, but I think you'll have to stick with something more basic of finding the right server number and sticking with it, then having an event which compares the actual date against the date from the Eddi status and if they're different reporting to the user that the connection has gone down so they can investigate.
                        A call to director,myenergi.net will give an error but the right servername is in the header.
                        But it is far easier to just do your regular call and look at he asn: tag near the end of the JSON response as there the correct servername is also stated.
                        As said, if this is different then the one you used then your are migrated and you can use the new and correct servername
                        - Bram

                        Send from my Commodore VIC-20

                        Ashai_Rey____________________________________________________________ ________________
                        HS3 Pro 3.0.0.534
                        PIugins: ZMC audio | ZMC VR | ZMC IR | ZMC NDS | RFXcom | AZ scripts | Jon00 Scripts | BLBackup | FritzBox | Z-Wave | mcsMQTT | AK Ikea

                        Comment


                          #27
                          I did fix the internal inconsistencies to allow the dynamic URL. One difference is when using $$PAYLOAD: (topic): approach there are no quote within the parenthesis so my post #23 example becomes https://$$PAYLOAD: (xyz:ASN):

                          When the URL changes a new HS control device will be created. In the example below illustrates this for the case. For my test I was using topic Home with a JSON payload containing key ASN. I tried to use the URL for the director at myEnergi, but was not able to get past the authentication. I assume different credentials are used to login to the director URL.

                          Updates are at
                          HS4: http://mcsSprinklers.com/MCSMQTTHS4_52101.zip
                          HS3: http://mcsSprinklers.com/MCSMQTT_52101.zip
                          ​​​​​​​



                          Comment


                            #28
                            After thinking about this, I think it would make more sense to leave the Association tab display of the source address to be the "Home:ASN" rather than what it gets resolved to be as "s1.myenergy.net". Much like a browser URL showing the DNS name and not the IP to which this DNS resolves. This way if the server changes the payload will still be placed in the same Association table rows and HS Device Features. Another iteration will be needed to accomplish this.

                            Comment


                              #29
                              Some help on the director.myenergi.net calls

                              See this post
                              Update to "Active Server" redirects - myenergi

                              New approach
                              We are in the process of updating the server code so that all API calls will return the asn information in the headers of the HTML response.
                              Every API call will include the header "x_myenergi-asn" with the correct target server, eg


                              and further down.

                              check the "asn" response in the headers. You may get a 401 - Unauthorised error when calling the Director, but the asn response will still be in the header.


                              But i think this isn't a huge dealbreaker because this is how i understand it ounce you are moved to the S18 server you gonna stay there.
                              No real need to make this URL as a variable that change all the time.
                              But that is my oppinion.
                              - Bram

                              Send from my Commodore VIC-20

                              Ashai_Rey____________________________________________________________ ________________
                              HS3 Pro 3.0.0.534
                              PIugins: ZMC audio | ZMC VR | ZMC IR | ZMC NDS | RFXcom | AZ scripts | Jon00 Scripts | BLBackup | FritzBox | Z-Wave | mcsMQTT | AK Ikea

                              Comment


                                #30
                                I did include the update to keep the URL replacement text in place and only resolve to the endpoint at the time the access to the site is being made. It is at
                                HS3: http://mcsSprinklers.com/MCSMQTT_52102.zip
                                HS4: http://mcsSprinklers.com/MCSMQTTHS4_52102.zip

                                I did not pursue any further the specific case of the Director site. The technique I'm using to access it does not provide visibility into a return header when 401 unauthorized response is received. I could try other techniques, but since there is no need I did not pursue alternatives.

                                Comment

                                Working...
                                X