You maybe need confirmation if that will work? If the Ezlo controller is on a remote network from the MSR installation.
I think when using cloud authentication if gets the access token but then connects locally to the Ezlo Controller with that token etc.
@rigpapa Can you confirm please.
I’ll check the docs first, but await Patrick’s input as well. All my ezlo equipment resides at an entirely different home address than my Vera/MSR installations, so local connections are a no-go. And, hey, if it doesn’t work, no worries, because I only use ezlo products for beta testing, nothing useful (yet).
Link is above now, I wasn’t sure if we could post direct links to it, but apparently we can.
Ha, I’m so glad you did (place the link) because I was going bonkers trying to find the ‘ezlo’ entry from MSR > Manual. Turns out I was reading a local (and therefore somewhat dated) version of the Docs, which had not yet included such a reference.
I’ll explore it in depth now**. Thanks again. You and Patrick are light years ahead of other Forum users in terms of your collective helpfulness, for which I’m indebted.
**EDIT: I’m getting the sense that true ‘remote’ access would require me to configure port forwarding (to my ezlo hub) on the non-local router, which sounds like ‘fun’, as well as cross my fingers that the ISP never changes the outward-facing IP address, lol. 
It’s pretty easy just copy the example and paste it into your reactor.yaml file in your config folder and edit with your own details for connection.
Also MSR version 1.0 is now released. So make sure you have the latest version installed.
Guess it’s OK to link to the new download page here also.
I have a feeling that will be the case also.
VPN tunnel maybe from location A to B.
Or as you say if port forwarding you will need a static WAN IP address at the remote location.
Maybe use a DynamicDNS service at the remote location and then use the
domain-name:portnumber
You might be in luck. Seems the Web socket API that MSR uses can also be used remotely.
See conversation about it here
It’s the HTTP Server API that only works locally currently.
But again it depends on what Patrick says to confirm.
I tried to connect my Ezlo Atom controller to MSR but its not working fully, it didn’t find my devices pair to the Atom. It did however add an Atom “system” entry in to the Entities area of the MSR gui. But the system state is “false” rather than “true”.
Also apparently the Atom doesn’t support the “offlineAnonymousAccess” setting.
So if it can be made to work and connect properly, it may have to always be via cloud authentication and access token, rather than direct local access.
I have created a thread titled " Support for Ezlo Atom controllers?" on the “other forum” and I definitely can’t link to that.
I had a reply he says
“We have local Web sockets API on the Atom and plughub but not the HTTP API”
Well, if there’s a WebSocket open, it’s either (a) not on the version of Atoms that I have, or (b) on a port other than 17000 (as the WebSocket API is for Plus), because that location isn’t open on the Atom I have up right now. So I guess I’m going WireSharking/NMAPing to find it, unless you can get an answer…
Edit: for clarity, the socket is open and connectable, but the endpoint (Atom) doesn’t respond to hub.offline.login.ui. There’s no documentation as to any specific requirements for the Atom elsewhere, so we need engineering ( @Oleh ? ) to answer, and document the process.
And, ideally, we should also get documentation for connecting via remote access. This post had some information, but the way to get the relay server is a bit ropey (the host/domain on the second request is questionable). It seems the correct mechanism is to make the initial cloud auth request, which returns a structure that includes Identity, IdentitySignature and Server_Account. One can then request /device/device/device/NNN (where NNN is the serial number of the controller) from the host named in Server_Account, passing the Identity and IdentitySignature in the HTTP(S) headers MMSAuth and MMSAuthSig, respectively, and this will return a JSON structure that includes Server_Relay, which is a WebSocket endpoint to which you can connect for API access. So far, that seems like it has potential to be a stable process, but it isn’t official until it’s documented, and it isn’t that I can see. To go on, you then have to log in on the WebSocket connection, which requires that you send method userLoginMios with parameters MMSAuth and MMSAuthSig as before (same values as previous HTTPS request headers), and this gets you logged in locally, up and running with the API on the WebSocket. Just the name of this method (not patterned after all other API methods) makes me nervous that it’s an internal mechanism and subject to change, and again, unless and until it’s documented, it isn’t usable for production code.
As I said, I can’t find any documentation for hub login, locally or remote, from eZLO. All I’ve seen are your guide (CW’s Idiot’s Guide), and sample code from other users in both Lua and Python, but no official documentation from eZLO. Yet the API itself has official documentation. It seems a good bit “cart before the horse” to document the API officially in detail, yet have no documentation for the official mechanisms for logging in to the API, both locally and remotely. Maybe it does exist somewhere, but I haven’t found it, and if it exists, it should be the top/pinned post in the Ezlo Library category.
I’ll ask now, but they might have finished for the day already. But they do sometimes reply out of hours.
@Oleh can you speak to the availability of the documentation I refer to in this post? While I see a lot of API documentation, I have yet to find any document that official states what the login process is to get access to the API. What exists today is “lore” passed down from early discussions in 2020 and embodied in code fragments pasted on these forums, which is neither specification nor documentation. To the extent that the methods are different for RTOS vs Linux controllers, this also needs to be documented.
Hi @rigpapa
I know local or http(s) based access is not available for the Atom, only cloud based web socket. It should work using the logic in my Elzo bridge plugin, but I must say I have not plugged in an Atom in months so not sure it still works like that.
Cheers Rene
I am able to connect to both the eZLO Plus and Atom using the known (tribal knowledge) mechanisms, that’s not the issue. The issue is that these mechanisms are not documented, and therefore not reliable for use in production code. They were either (a) learned informally on Skype chats you and I both were party to over 18 months ago, and other conversations and forum posts prior, to “get something working”, and (b) apparent reverse engineering of the activities of the mobile app, the API tool, etc. The procedures for Linux and RTOS appear to be different, and notably, as you said, access to the Atom’s local WebSocket may not be available, but there is conflicting information on that, and you can, in fact, connect to the socket, it just does not respond to the usual hub.offline.login.ui method; I have not found a working alternative (maybe that’s a firmware issue with my Atom at 0.8.798, I don’t know). Both platforms and login methods currently in use access various eZLO endpoints (servers/services) in the blind, with hard-coded domain and host names (will vera-us-oem-autha11.mios.com work for everyone in all regions? and does eZLO really want all external integrations hitting this one endpoint?), which seems risky (minimally, it opposes the scalability implied by the region stamping and numbered naming of these target sites).
So there are disconnects, assumptions, unanswered questions, and basically just a ton that is anecdotal and undocumented, and you can’t build production software on that kind of loosey-goosey stuff. I am asking @Oleh and his team for definitive and clear documentation on the login procedures for both system types, including for both access through the cloud and access locally when/where available. If we have formal documentation for the API, why is there no such formal documentation for how to access that API? Tribal knowledge isn’t sufficient at this point, not just for myself, but now for others planning on integrating their dashboards and applications with these platforms.
I’ve looked at your EzloBridge code, and it doesn’t have any special conditions for connecting to Atom, and at least with my Atoms, the mechanism used there, which does work for Plus/Linux, does not work for Atom/RTOS. The “other” mechanism that can be derived from several forum posts here does work, but is vastly different from the Linux-hub method (and no evidence of that is in your bridge code right now). And again, all of it is basically hearsay. Documentation would answer these questions definitively and formally, and is much needed.
Just checked my Atom is still firmware 0.8.539
And can’t currently be connected to Multi System Reactor.
I hope Ezlo can answer these questions and provide the needed documents to the 3rd party developers.
Hi @rigpapa. I couldn’t agree more for real SDK docs and I implored the devs early on but it fell on deaf ears. However, I have also implemented the aforementioned “lore” in ezlo-hub-kit using a mechanism that works universally for both the Linux and RTOS, albeit for secure web sockets only, so I am not sure what you are experiencing. It is up on GitHub with a very liberal license (effectively people can do with it whatever they want with it). The implementation’s automated test suite has survived numerous ezlo firmware updates so I feel pretty good about the stability, albeit with the real-SDK caveats that you mentioned. Feel free to use the npmjs module or copy/paste or whatever with the source code that might help. It is there for people to do whatever they choose, even if it just helps someone with their own ezlo connection strategy implementation. If you just want to harvest some additional “lore” but unified across Linux and RTOS, take a look at the EzloCloudResolver strategy.
I’ll be happy to entertain any questions that you might have but given that it is a nodejs module complete with unit tests, I suspect you will auger in quickly by downloading the code and running the unit tests. The tests will discover all your locally connected ezlo hubs and run each unit test on them (note, you will need to use your mios credentials in the config.env file for the tests).
I suspect the RTOS devices for which your package works are, at least on the Atom side, Gen2. I’m using the same mechanism, of course, down to the hard-coded URLs and salt (and they’re using SHA1? Oy.). Have you tried your library with a first generation Atom?
I believe you are correct that it only works with Gen 2+ ATOMs and I don’t think I even have an Atom 1 around anymore. I use an Atom 2 to run my landscape lighting (8 dimmable zones) and it has worked pretty well. Also, for Atoms, make sure you override the wss:// encryption to something less compute-intensive than ECC because my benchmarking showed a huge difference in performance on the Atom2 when using ECC vs. SHA-256. See my in-line comments here ezlo-hub-kit/EzloHub.ts at efd3ae843421564c24e96e00a35889ad27cad1b4 · bblacey/ezlo-hub-kit · GitHub
That said, ezlo-hub-kit was my attempt to create an off-device SDK that we didn’t have, and ideally, could codify the lore in a single place for the use of many others… In fact, you may recall, I refactored the kit from my in-work HomeKit bridge when you announced MSR thinking that it might be of use for integrating Ezlo Hubs into MSR.
Finally, sorry for the slow reply but I can only post from my desktop because my forum email can’t be confirmed for some unknown reason.
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules
