Support for Ezlo Atom controllers?
-
Looking in the log I now see this, I have changed some sensitive items:
2021-08-25T14:54:50.826Z <EzloController:null> EzloController#ezlo-atom account server replied { "PK_Device": "70060304", "NMAControllerStatus": 1, "NMAUuid": "a12bgd83-96b3-22d9-ad44-533df5564f44", "firmware_upgrade_progress": 100, "firmware_upgrade_status": "finished", "public_key_android": "", "public_key_ios": "", "Server_Relay": "wss://nma-server6-ui-cloud.ezlo.com:443", "MacAddress": "54:F5:4E:A4:5E:E5", "FK_Branding": "1", "HasWifi": "0", "HasAlarmPanel": "0", "UI": "4", "EngineStatus": "0", "LinuxFirmware": 1 } 2021-08-25T14:54:50.828Z <EzloController:INFO> EzloController#ezlo-atom cloud auth succeeded 2021-08-25T14:54:50.829Z <EzloController:6:EzloController.js:660> EzloController#ezlo-atom authinfo { } 2021-08-25T14:54:50.830Z <EzloController:INFO> EzloController#ezlo-atom opening hub connection to "70060304" at wss://nma-server6-ui-cloud.ezlo.com:443 2021-08-25T14:54:50.832Z <EzloController:NOTICE> EzloController#ezlo-atom connecting via WS to wss://nma-server6-ui-cloud.ezlo.com:443 2021-08-25T14:54:50.834Z <EzloController:5:Controller.js:537> EzloController#ezlo-atom websocket options { "maxPayload": 268435456, "followRedirects": true, "pingInterval": 60000, "agent": [object Object], "handshakeTimeout": 30000 } 2021-08-25T14:54:51.518Z <EzloController:6:Controller.js:554> EzloController#ezlo-atom websocket connected to wss://nma-server6-ui-cloud.ezlo.com:443; starting ping check timer Timer#ezlo-atom-ping 2021-08-25T14:54:51.519Z <EzloController:INFO> EzloController#ezlo-atom hub websocket connected (wss://nma-server6-ui-cloud.ezlo.com:443) 2021-08-25T14:54:51.520Z <EzloController:INFO> EzloController#ezlo-atom sending remote hub login 2021-08-25T14:54:51.522Z <EzloController:7:EzloController.js:1848> EzloController#ezlo-atom sending tracked request "17c8dcd8491" payload { "api": "1.0", "id": "17b7dce8481", "method": "loginUserMios", "params": { "MMSAuth": --undef--, "MMSAuthSig": --undef-- } } 2021-08-25T14:54:51.523Z <EzloController:5:EzloController.js:1856> EzloController#ezlo-atom created tracked request "17c8dcd8491" with payload { "api": "1.0", "id": "17b7dce8481", "method": "loginUserMios", "params": { "MMSAuth": --undef--, "MMSAuthSig": --undef-- } } 2021-08-25T14:54:51.675Z <EzloController:5:EzloController.js:1419> EzloController#ezlo-atom received message 144 bytes 2021-08-25T14:54:51.676Z <EzloController:5:EzloController.js:1419> EzloController#ezlo-atom message data {"id":"17b7dce8481","method":"loginUserMios","error":{"code":2,"data":"cloud.error.failed_to_get_mms_autha_token","description":""},"result":{}} 2021-08-25T14:54:51.678Z <EzloController:7:EzloController.js:1423> EzloController#ezlo-atom tracked request result slot { "req_id": "17c8dcd8491", "req_method": "loginUserMios", "expires": 1629903306521, "resolve": --function--, "reject": --function--, "promise": [object Promise] } 2021-08-25T14:54:51.679Z <EzloController:ERR> EzloController#ezlo-atom request "17c8dcd8491" (loginUserMios) failed: { "code": 2, "data": "cloud.error.failed_to_get_mms_autha_token", "description": "" } 2021-08-25T14:54:51.680Z <EzloController:7:EzloController.js:1855> EzloController#ezlo-atom removing resolved tracked request "17c8dcd8491" 2021-08-25T14:54:51.681Z <EzloController:ERR> EzloController#ezlo-atom hub login failed: { "code": 2, "data": "cloud.error.failed_to_get_mms_autha_token", "description": "" } 2021-08-25T14:54:51.685Z <EzloController:5:Controller.js:560> EzloController#ezlo-atom got websocket close 2021-08-25T14:54:51.686Z <EzloController:NOTICE> EzloController#ezlo-atom websocket closing, 1006And as I said no devices from the Atom are being pulled in to MSR. Maybe at this stage I need your bug fix then..
-
OK. Since it's a minor change, I just patched the build. Re-download the build package and reinstall it for the update. Then, you should be able to start with
sourcecommented out and get remote access.Once you have it connected, look at the system entity (the one with ID "system" matching the controller ID, like
atom>system), and there is ahardwareattribute that tells you the generation of Atom.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
OK. Since it's a minor change, I just patched the build. Re-download the build package and reinstall it for the update. Then, you should be able to start with
sourcecommented out and get remote access.Once you have it connected, look at the system entity (the one with ID "system" matching the controller ID, like
atom>system), and there is ahardwareattribute that tells you the generation of Atom.Its connected now and has imported the devices and scenes from the Atom in to entities area.
I see this though in alerts:
x_ezlo_sys.hardware="rev2"
So what's rev2 ?
sys_system.state=true x_ezlo_sys.anonymous_access_enabled=null x_ezlo_sys.architecture="esp32" x_ezlo_sys.firmware="0.8.539" x_ezlo_sys.hardware="rev2" x_ezlo_sys.kernel="v4.1-rc-4-gbd72a9ab2" x_ezlo_sys.model="ATOM32" x_ezlo_sys.reconnects=1 x_ezlo_sys.restarts=1 x_ezlo_sys.serial="70060304" x_ezlo_sys.support_enabled=null x_ezlo_sys.support_status=null x_ezlo_sys.temperature_scale="fahrenheit" x_ezlo_sys.temperature_unit="F" x_ezlo_sys.upsince=1624528447000 x_ezlo_sys.using_cloud_auth=true x_ezlo_sys.using_cloud_relay=true x_ezlo_sys.uuid=null Capabilities: sys_system, x_ezlo_sys Actions: sys_system.restart, x_ezlo_sys.runlua, x_ezlo_sys.set_settingThanks
-
That's gen2, so you may have local access. If you want to use local access, your Atom needs a stable IP address (static or DHCP reserved). You can put that into the
sourcefield (uncomment now), and also setdisable_ecc_cipherstotrue. Then restart Reactor.config: source: "wss://your-atom-ip:17000" serial: "7006nnnn" username: "whatever" password: "whatever" disable_ecc_ciphers: trueThis may or may not work for you. My rev2 Atom is on firmware 0.8.798, and it allows remote access. I don't have an Atom with 0.8.539 that is at rev2, so I don't know if rev2 will work at that firmware level. I do have a rev3 Atom at 0.8.539, and it does allow remote access, so I think it should, but we'll see...
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
That's gen2, so you may have local access. If you want to use local access, your Atom needs a stable IP address (static or DHCP reserved). You can put that into the
sourcefield (uncomment now), and also setdisable_ecc_cipherstotrue. Then restart Reactor.config: source: "wss://your-atom-ip:17000" serial: "7006nnnn" username: "whatever" password: "whatever" disable_ecc_ciphers: trueThis may or may not work for you. My rev2 Atom is on firmware 0.8.798, and it allows remote access. I don't have an Atom with 0.8.539 that is at rev2, so I don't know if rev2 will work at that firmware level. I do have a rev3 Atom at 0.8.539, and it does allow remote access, so I think it should, but we'll see...
@toggledbits said in Support for Ezlo Atom controllers?:
You can put that into the source field (uncomment now), and also set disable_ecc_ciphers to true. Then restart Reactor.
Done that.
I cleared the alert and restarted MSR. It hasn't come back again as yet.
And I can still see the Ezlo Atom items in entities.
-
@toggledbits said in Support for Ezlo Atom controllers?:
You can put that into the source field (uncomment now), and also set disable_ecc_ciphers to true. Then restart Reactor.
Done that.
I cleared the alert and restarted MSR. It hasn't come back again as yet.
And I can still see the Ezlo Atom items in entities.
@cw-kid said in Support for Ezlo Atom controllers?:
It hasn't come back again as yet.
I'm not sure what you mean by this. What "it" are you referring to?
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
@cw-kid said in Support for Ezlo Atom controllers?:
It hasn't come back again as yet.
I'm not sure what you mean by this. What "it" are you referring to?
The yellow warning alert hasn't come back again since adding disable_ecc_ciphers: true to the reactor.yaml flie.
And I uncommented the source line. The Atom already has a DHCP reserved LAN IP.
-
I didn't comment the username and password lines however.
I should do that if it is really only local access to the hub APi via the source line?
-
Don't uncomment the username and password. That only works for Plus/Secure hubs with anonymous access enabled. Atoms do not support anonymous access, so it is still necessary to get the access tokens from the cloud, even when connecting to the Atom locally.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
Don't uncomment the username and password. That only works for Plus/Secure hubs with anonymous access enabled. Atoms do not support anonymous access, so it is still necessary to get the access tokens from the cloud, even when connecting to the Atom locally.
OK. Do you know how long the tokens last and will MSR automatically request a new one when it does expire?
Thanks.
-
Supposedly 24 hours from what I can see. An expiration is given when the token is acquired. I haven't observed that there is any consequence to the expiration being met, though... it appears that access continues even after the token's expiration time/date. My presumption would be that access terminates when the token expires. Looks like more unfinished work there at eZLO to me.
Any disconnect will cause a reconnect retry.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
Supposedly 24 hours from what I can see. An expiration is given when the token is acquired. I haven't observed that there is any consequence to the expiration being met, though... it appears that access continues even after the token's expiration time/date. My presumption would be that access terminates when the token expires. Looks like more unfinished work there at eZLO to me.
Any disconnect will cause a reconnect retry.
I'm inclined to agree with you.
I have a token obtained by using Renes python script for my Ezlo Plus for use with curl commands and I bet that same token still works today I will have to try it again.
Token was probably obtained 12 months ago maybe.
-
Yup, that's definitely a security issue, and not the only one I'm concerned about, which is another reason I'm unlikely to be using an eZLO hub in my home for anything more than development of this tool.
-
T toggledbits locked this topic on
