Support for Ezlo Atom controllers?

[cw-kid]

Hi

I just tried to add a connection for my Ezlo Atom, its added the Atom system in to the MSR Entities, but it has a "false" state and hasn't found my devices that are paired to the Atom.

Also note that on the Atom controller there is no settings for:

offlineAnonymousAccess: true or false

offlineInsecureAccess: true or false

So this line in the reactor.yaml file won't work for Atom's.

set_anonymous_access: true

This was what I added to my reactor.yaml file.

- id: ezlo-atom
  enabled: true
  implementation: EzloController
  name: Ezlo Atom
  config:
    source: "wss://192.168.0.101:17000"  # change the IP address
    serial: "70060304"    # put your hub's serial here
    username: "myusername"  # put your username here between quotes
    password: "mypassword"  # and password
    # set_anonymous_access: true

Thanks

[toggledbits]

OK. Please do this:

1. Disable any other EzloController instances (by setting enabled: false in their controller config in reactor.yaml), leaving just the Atom enabled.
2. Restart MSR. Wait until the restart occurs and your browser/UI reconnect.
3. Confirm no devices list.
4. Open a PR and post the nnn_data_list.json, nnn_hub_info.json and nnn_mode_info.json files, where nnn is the ID of the Atom interface (from reactor.yaml). Based on your snip above, that would be ezlo-atom_data_list.;json, etc.

You can put your other Ezlo instances back after grabbing and posting the files.

[cw-kid]

@toggledbits

Thanks.

I've tried that, with the Ezlo Plus controller disabled, then in Entities area for the Ezlo Atom controller and still no devices listed for the Atom.

I can't see any file called ezlo-atom_data_list.json however or hub and mode info either.

These one listed have time stamps from several hours ago earlier today.

EDIT: I've searched in Winscp the entire Reactor folder and there is no .json files of that name with Atom.

[cw-kid]

Not sure exactly what I am looking for in the reactor.log file but I can see several errors like these:

2021-07-22T15:41:45.378Z <EzloController:5:Controller.js:581> EzloController#ezlo-atom ws_open caught TimedPromise timeout
2021-07-22T15:41:45.383Z <EzloController:WARN> EzloController#ezlo-atom websocket error during open/negotation: Error: WebSocket was closed before the connection was established
2021-07-22T15:41:45.385Z <EzloController:ERR> EzloController#ezlo-atom failed to connect websocket to wss://192.168.0.243:17000: TimedPromise timeout
2021-07-22T15:41:45.389Z <EzloController:NOTICE> EzloController#ezlo-atom websocket to wss://192.168.0.243:17000 closed during open/negotiation

I don't want to post the entire log here or in the ticket system, perhaps I can email it to you if needed?

Thanks

[toggledbits]

No, that's enough for now. Do we know if a local API for the Atom is even possible?

[cw-kid]

@toggledbits said in Support for Ezlo Atom controllers?:

Do we know if a local API for the Atom is even possible?

The Ezlo dev just said "We don't have it on Atom" when I asked him why I couldn't see the offlineAnonymousAccess and offlineInsecureAccess settings in the API Tool for the Atom.

[toggledbits]

I have Atom working, but it uses an undocumented method of access (not the one described on the eZLO Community, but similar), and I'm still working out some issues.

[cw-kid]

Via a local or cloud Web sockets API?

Why is it undocumented, do we need the Ezlo Devs to confirm that type of access will remain open and available.

Thanks.

[cw-kid]

Ezlo dev says

"We have local Web sockets API on the Atom and plughub but not the HTTP API"

[toggledbits]

It doesn't much matter what they say if the device doesn't answer (won't answer hub.offline.login.ui) on the published port number they use for the others (like Plus), and they don't tell us what the Atom-specific mechanism is. Or, maybe my Atom is too old, but it is a second-gen unit, so I don't think so. I can't work from "we have it". There needs to be documentation to not only describe it, but memorialize their commitment to supporting it.

Remote access is really the same. I can't build on unsupported/undocumented features and functions. It may work today, but if doesn't down the road, I look like the bad guy, and the onus is on me to fix it and restore the feature, which may not even be possible. Poor risk reward, especially for this context.

[cw-kid]

@toggledbits

I totally agree.

I've asked him on Skype what the port number should be? and if they have any documentation for the Web socket API on the RTOS based controllers, such as the Atom.

[toggledbits]

The port number is right, it connects, it just never answers the usual login request, and doesn't issue any messages of any kind at all. I embellished details in my previous post there, and prompted Oleg in it. In any case, none of this is serviceable until this is documented.

Over a year ago on Skype, early on in perhaps March or April, I suggested that all of their PDF documents need to be in a single location/library where they can seen. This business of them posting single PDFs on demand in the forums is the worst possible way to get it done (maybe second worst: they were replying on Skype with them, which was actually worse). Did that ever happen? I know of no such repository. If there were, at least one could research, but as it is, their docs are a hodge-podge of "lucky if you have it" one-offs, a dated web reference site, and an incomplete/dated API tool. And no version control. Ugh. This entire situation is why I didn't want to do this eZLO interface, and I'm really regretting it this morning.

[cw-kid]

I feel your pain.

Forgot it for now then.

For me personally I don't need my Atom connected to MSR. But I just thought I'd try it and test it if it did connect.

As long as Ezlo Plus and Ezlo Secure works, I think most people will be happy with that.

That website you mentioned is all I know of and there's a bit of a library section they created on the forum here.

[cw-kid]

There is also this Ezlo Support Site here which has some API stuff in it, but overall it looks lacking in content.

[toggledbits]

Yeah, nothing there either. Cart before the horse. API docs. No docs for how to log in to the API. And enough people have asked, including you, to produce various unofficial mechanisms; that should have been enough prompt/repetition to cause an official document to be produced (and really, together with/as part of the API docs is the perfect place for it).