rccoleman/lamarzocco

Stopped working since recent LM Linea Mini firmware upgrade

valsily opened this issue · 116 comments

Hi,

First of all, thank you so much for making such a great integration. It has worked great with my Linea Mini until this morning. I saw an firmware update in the La Marzocco Home app and decided to proceed with it, which appears to be a bad idea now.

The upgrade went smoothly and successfully completed. But the machine became unreachable from my home assistant since then.

I had tried to restart both the espresso machine and Home Assistant server but still no luck.

Just wondering if there is any way to fix this? Or is anyone running into such issues recently?

Thanks in advance

image

@valsily you will need to use this repo in HA for now which supports the new API for Micra and Mini's. https://github.com/zweckj/lamarzocco

orxelm commented

@mrvautin why are you saying that? Did @rccoleman stopped supporting the project?

@orxelm no just the support is not merged into the main repo yet. Still working on it. I should have said "use this repo for now".

Actually my GS3 integration also stopped working since the latest upgrade.

Gateway v3.1-RC4
Machine firmware 1.40

Happy to help provide whatever other debug info you may need.

zweckj commented

@gmathur you can test pre-release v0.12.0-beta.1 on my fork, which should theoretically also support the GS3

BTW, here's their blog entry indicating that all machines must update to the new gateway by Sept 10: https://home.lamarzoccousa.com/important-firmware-update/

@gmathur you can test pre-release v0.12.0-beta.1 on my fork, which should theoretically also support the GS3

Ill give it a whirl today and respond back.

@gmathur you can test pre-release v0.12.0-beta.1 on my fork, which should theoretically also support the GS3

Tried beta1 - beta4. Seeing this issue in logs as soon as I try and configure the integration.
My best guess is some version mismatch (or missing dependencies) with lmcloud?

Logger: aiohttp.server
Source: custom_components/lamarzocco/config_flow.py:45
Integration: lamarzocco ([documentation](https://github.com/rccoleman/lamarzocco), [issues](https://github.com/rccoleman/lamarzocco/issues))
First occurred: 3:45:20 PM (2 occurrences)
Last logged: 3:45:33 PM

Error handling request
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py", line 433, in _handle_request
    resp = await request_handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_app.py", line 504, in _handle
    resp = await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_middlewares.py", line 117, in impl
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 85, in security_filter_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 100, in forwarded_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 28, in request_context_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 80, in ban_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 236, in auth_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 148, in handle
    result = await handler(request, **request.match_info)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 181, in post
    return await super().post(request, flow_id)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 72, in wrapper
    result = await method(view, request, data, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 110, in post
    result = await self._flow_mgr.async_configure(flow_id, data)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 297, in async_configure
    result = await self._async_handle_step(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 393, in _async_handle_step
    result: FlowResult = await getattr(flow, method)(user_input)
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/lamarzocco/config_flow.py", line 86, in async_step_user
    return await self._try_create_entry(data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/lamarzocco/config_flow.py", line 67, in _try_create_entry
    machine_info = await validate_input(self.hass, data)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/lamarzocco/config_flow.py", line 45, in validate_input
    lm = await LaMarzoccoClient.create(hass=hass, data=data)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: LMCloud.create() got an unexpected keyword argument 'hass'

Trying with master, I hit a different error:

Logger: aiohttp.server
Source: custom_components/lamarzocco/interface.py:97
Integration: La Marzocco ([documentation](https://github.com/rccoleman/lamarzocco), [issues](https://github.com/rccoleman/lamarzocco/issues))
First occurred: 4:23:52 PM (1 occurrences)
Last logged: 4:23:52 PM

Error handling request
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py", line 433, in _handle_request
    resp = await request_handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_app.py", line 504, in _handle
    resp = await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_middlewares.py", line 117, in impl
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 85, in security_filter_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 100, in forwarded_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 28, in request_context_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 80, in ban_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 236, in auth_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 148, in handle
    result = await handler(request, **request.match_info)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 181, in post
    return await super().post(request, flow_id)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 72, in wrapper
    result = await method(view, request, data, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 110, in post
    result = await self._flow_mgr.async_configure(flow_id, data)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 297, in async_configure
    result = await self._async_handle_step(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 393, in _async_handle_step
    result: FlowResult = await getattr(flow, method)(user_input)
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/lamarzocco/config_flow.py", line 87, in async_step_user
    return await self._try_create_entry(data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/lamarzocco/config_flow.py", line 68, in _try_create_entry
    machine_info = await validate_input(self.hass, data)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/lamarzocco/config_flow.py", line 44, in validate_input
    lm = await LaMarzocco.create(hass=hass, data=data)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/lamarzocco/api.py", line 39, in create
    await self.init_lm_client(hass=hass, config=config_entry.data if config_entry else data)
  File "/config/custom_components/lamarzocco/interface.py", line 97, in init_lm_client
    self._lm_direct = LMDirect.__init__(config)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: LMDirect.__init__() missing 1 required positional argument: 'machine_info'
zweckj commented

apologies, the flow for setting up the integration from scratch was untested. beta.5 should fix this issue.

That totally did the trick - everything is up and running. You rock!

Thanks so much for doing this!

Is @zweckj or anyone else experiencing the main entity being out of sync with the machine?

Mine is showing on but the machine is off (in standby):

image

The official app is correctly showing the machine as off:

image

Toggling the entity off and on fixes it but just wondering if there is an issue.

zweckj commented

@mrvautin are you on the latest pre-release? (0.12.0-beta.5)

@mrvautin are you on the latest pre-release? (0.12.0-beta.5)

Yes. I'm on that release.

The issue seems to stem from the machine going into standby after a period of time and Home Assistant not getting the update.

Is there anything I can check do give you proper info?

zweckj commented

Does it the other way for you - bringing the machine out of StandBy with the paddle? I just tested that and that appears to be working fine. Also turning the machine off through the official app reflects in HA for me. Would be good if you could test those things as well (always keep in mind it can take up to 30 seconds for the state to update)

@zweckj it doesn't work. I toggled the entity off, moved the paddle and home assistant is still showing as off. The LM app is correctly updated from the paddle. There is nothing in the logs indicating any issues.

zweckj commented

@mrvautin interesting. Turn debug logging on please, it should log the entire status object whenever it gets refreshed (every 30 seconds). If that indeed seems wrong, also reload the integration once

@zweckj it's really weird, my HA has debug turned on and I can see debug logs however not the full output every 30 secs. I might need to remove and re-install entirely.

2023-07-13 16:20:55.391 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Manually updated La Marzocco API coordinator data
2023-07-13 16:20:55.393 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Manually updated La Marzocco API coordinator data
2023-07-13 16:21:15.359 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Manually updated La Marzocco API coordinator data
2023-07-13 16:21:15.360 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Manually updated La Marzocco API coordinator data
2023-07-13 16:21:35.351 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Manually updated La Marzocco API coordinator data
2023-07-13 16:21:35.352 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Manually updated La Marzocco API coordinator data
zweckj commented

@mrvautin yes that's weird. Seems like the update coordinator is not running properly for you.
There should be an Update coordinator: Updating data every 30 seconds followed by the data.

@zweckj I've totally removed and reinstalled. I had debugging turned on in the config which didn't seem to work. When I clicked on debugging through the integration it works as I'd expect.

image

I had Websockets enabled. When I turned it off the main entity works perfectly now. Seems to be related to the websocket code but still nothing in the logs to indicate why or what.

zweckj commented

I had Websockets enabled. When I turned it off the main entity works perfectly now. Seems to be related to the websocket code but still nothing in the logs to indicate why or what.

yeah that can be, sorry should have made that clearer that that is a VERY beta functionality

zweckj commented

@mrvautin I think I found the issues. Could you please test beta.6 and report back?

@mrvautin I think I found the issues. Could you please test beta.6 and report back?

Thanks @zweckj. I will have a test. Also note there is a new machine update for me this morning in the LM app. V3.1-RC6.

zweckj commented

[...] there is a new machine update for me this morning in the LM app. V3.1-RC6.

appears to be a bugfix release, but please report if anything breaks

Thanks for all the hard work on this. My machine is on gateway V3.1-RC6 and I am using the latest beta release (0.12.0-beta.6) and am seeing the following error after configuring

2023-07-15 11:42:45.886 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Update coordinator: Updating data
2023-07-15 11:42:48.714 DEBUG (MainThread) [custom_components.lamarzocco.lm_client] Model name: Linea Mini
2023-07-15 11:42:49.156 ERROR (MainThread) [custom_components.lamarzocco.coordinator] 'NoneType' object is not subscriptable
2023-07-15 11:42:49.158 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Finished fetching La Marzocco API coordinator data in 3.273 seconds (success: False)

The result is an endless "retrying setup" loop - and the entities are never created. I have retried numerous times over the past 12 hours without any success. Any ideas on what the cause is, or how I can get you more details.

The result is an endless "retrying setup" loop - and the entities are never created. I have retried numerous times over the past 12 hours without any success. Any ideas on what the cause is, or how I can get you more details.

Ok - this is crazy. So immediately after posting this it just started working. I wonder if their cloud endpoint had some sort of outage? I also wonder if we could detect that and log in such a case so it is easier to identify if it happens again.

Upgraded to the RC6 gateway and beta6 integration. But integration stopped working for me - Start/stop wasn't working as an example.

Going back to beta5 (with the updated gateway) fixed it for me.

zweckj commented

I also wonder if we could detect that and log in such a case so it is easier to identify if it happens again.

I am normally logging anything that is not a success status code very visibly as a warning, so they'd need to have returned a success without the information I'm looking for...

Upgraded to the RC6 gateway and beta6 integration. But integration stopped working

@gmathur that is weird, I didn't touch anything except WebSocket code in beta.6 (which is working flawlessly for me). Can you maybe try beta.6 again later and turn on debug logging?

Weird - beta6 seems to work fine at the moment. Ill leave debug logging on for the next day or so and live with it.

Looks like there is a crash as the integration becomes unavailable after some time.

See this error repeatedly in the logs:

Logger: custom_components.lamarzocco.coordinator
Source: custom_components/lamarzocco/coordinator.py:70
Integration: La Marzocco ([documentation](https://github.com/rccoleman/lamarzocco), [issues](https://github.com/rccoleman/lamarzocco/issues))
First occurred: 9:14:20 AM (11 occurrences)
Last logged: 9:19:20 AM

'NoneType' object is not subscriptable

This keep recurring in the logs:

2023-07-15 09:14:20.832 ERROR (MainThread) [custom_components.lamarzocco.coordinator] 'NoneType' object is not subscriptable
2023-07-15 09:14:20.833 ERROR (MainThread) [custom_components.lamarzocco.coordinator] Error fetching La Marzocco API coordinator data: ('Querying API failed. Error: %s', TypeError("'NoneType' object is not subscriptable"))

See this on beta5 also as a matter of fact

zweckj commented

@gmathur thanks for reporting. Are WebSockets enabled or disabled?

@gmathur thanks for reporting. Are WebSockets enabled or disabled?

Disabled. Enabling it now and retrying (beta5 and 6)

Still the same error. Now consistently seeing the integration "Failed setup. Will retry"

(Update 10 mins later) Things are just magically working (!).

zweckj commented

Disabled. Enabling it now and retrying

Shouldn't make a difference then. I'm just flying in the dark here, as I'm not having those and I'm trying to localize where it could be coming from

Restarting the integration/HA seems to have triggered these errors. Anything I can do to help debug?

zweckj commented

@gmathur please install v0.12.0-debug.1, that should log the full stack trace on that error (at least I hope so)

Here are all the errors:

1:

This error originated from a custom integration.

Logger: custom_components.lamarzocco.coordinator
Source: custom_components/lamarzocco/coordinator.py:62
Integration: La Marzocco (documentation, issues)
First occurred: 10:34:43 PM (21 occurrences)
Last logged: 10:58:33 PM

Update coordinator failed.
Traceback (most recent call last):
  File "/config/custom_components/lamarzocco/coordinator.py", line 62, in _async_update_data
    await self._lm.update_local_machine_status()
  File "/usr/local/lib/python3.11/site-packages/lmcloud/lmcloud.py", line 250, in update_local_machine_status
    self._config_coffeeboiler = next(item for item in self.config[BOILERS] if item["id"] == COFFEE_BOILER_NAME)
                                                      ~~~~~~~~~~~^^^^^^^^^
TypeError: 'NoneType' object is not subscriptable

2:

This error originated from a custom integration.

Logger: custom_components.lamarzocco.coordinator
Source: custom_components/lamarzocco/coordinator.py:70
Integration: La Marzocco (documentation, issues)
First occurred: 10:34:43 PM (21 occurrences)
Last logged: 10:58:33 PM

'NoneType' object is not subscriptable

Running gateway firmware 1.31 RC4 with beta 6 and all working perfectly. Machine wants me to upgrade to 1.31 RC6 but don’t want it to break again, but if helpful for me to try then can do.

zweckj commented

Running gateway firmware 1.31 RC4 with beta 6 and all working perfectly. Machine wants me to upgrade to 1.31 RC6 but don’t want it to break again, but if helpful for me to try then can do.

Been on RC6 for a while already, should be fine.

Btw even with the latest updates I still see it sometimes work just fine and other times failing setup with the Nonetype error

mtwo commented

Btw even with the latest updates I still see it sometimes work just fine and other times failing setup with the Nonetype error

Same here, I'm getting this error during setup:

'NoneType' object has no attribute 'get'

zweckj commented

@gmathur @mtwo please install beta.13 and enable debug logging. It should log the full stacktrace directly after the error, if you give me that stack trace I can look into what is causing this.

mtwo commented

I updated to beta.13 and set the log level for custom_components.lamarzocco.coordinator to debug (let me know if I should have specified a different component). Here are the logs that I received:

Logger: custom_components.lamarzocco.coordinator
Source: custom_components/lamarzocco/coordinator.py:72
Integration: La Marzocco (documentation, issues)
First occurred: 12:02:08 PM (12 occurrences)
Last logged: 12:09:42 PM

'NoneType' object has no attribute 'get'
Logger: homeassistant.config_entries
Source: config_entries.py:1250
First occurred: 12:09:00 PM (1 occurrences)
Last logged: 12:09:00 PM

Config entry 'GS015078' for lamarzocco integration not ready yet: ('Querying API failed. Error: %s', AttributeError("'NoneType' object has no attribute 'get'")); Retrying in background

This is for a GS3 manufactured in ~November 2020, with the built-in WiFi board.

mtwo commented

Just re-read and realized that you wanted the full stack trace, getting this

mtwo commented

Do these help?

2023-08-02 12:32:56.679 ERROR (MainThread) [custom_components.lamarzocco.coordinator] 'NoneType' object has no attribute 'get'
2023-08-02 12:33:16.970 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Update coordinator: Updating data
2023-08-02 12:33:18.333 DEBUG (MainThread) [custom_components.lamarzocco.lm_client] Model name: GS3 AV
2023-08-02 12:33:18.491 ERROR (MainThread) [custom_components.lamarzocco.coordinator] 'NoneType' object has no attribute 'get'
2023-08-02 12:33:18.493 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] 'NoneType' object has no attribute 'get'
Traceback (most recent call last):
File "/config/custom_components/lamarzocco/coordinator.py", line 63, in _async_update_data
await self._lm.update_local_machine_status()
File "/usr/local/lib/python3.11/site-packages/lmcloud/lmcloud.py", line 255, in update_local_machine_status
self._config_coffeeboiler = next((item for item in self.config.get(BOILERS, []) if item["id"] == COFFEE_BOILER_NAME), {})
^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get'
2023-08-02 12:33:18.495 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Finished fetching La Marzocco API coordinator data in 1.526 seconds (success: False)
2023-08-02 12:33:58.876 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Update coordinator: Updating data
2023-08-02 12:34:00.459 DEBUG (MainThread) [custom_components.lamarzocco.lm_client] Model name: GS3 AV
2023-08-02 12:34:00.661 ERROR (MainThread) [custom_components.lamarzocco.coordinator] 'NoneType' object has no attribute 'get'
2023-08-02 12:34:00.664 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] 'NoneType' object has no attribute 'get'
Traceback (most recent call last):
File "/config/custom_components/lamarzocco/coordinator.py", line 63, in _async_update_data
await self._lm.update_local_machine_status()
File "/usr/local/lib/python3.11/site-packages/lmcloud/lmcloud.py", line 255, in update_local_machine_status
self._config_coffeeboiler = next((item for item in self.config.get(BOILERS, []) if item["id"] == COFFEE_BOILER_NAME), {})
^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get'
2023-08-02 12:34:00.667 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Finished fetching La Marzocco API coordinator data in 1.791 seconds (success: False)
IndexError: list index out of range
2023-08-02 12:32:56.679 ERROR (MainThread) [custom_components.lamarzocco.coordinator] 'NoneType' object has no attribute 'get'
2023-08-02 12:33:16.970 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Update coordinator: Updating data
2023-08-02 12:33:18.333 DEBUG (MainThread) [custom_components.lamarzocco.lm_client] Model name: GS3 AV
2023-08-02 12:33:18.491 ERROR (MainThread) [custom_components.lamarzocco.coordinator] 'NoneType' object has no attribute 'get'
2023-08-02 12:33:18.493 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] 'NoneType' object has no attribute 'get'
Traceback (most recent call last):
  File "/config/custom_components/lamarzocco/coordinator.py", line 63, in _async_update_data
    await self._lm.update_local_machine_status()
  File "/usr/local/lib/python3.11/site-packages/lmcloud/lmcloud.py", line 255, in update_local_machine_status
    self._config_coffeeboiler = next((item for item in self.config.get(BOILERS, []) if item["id"] == COFFEE_BOILER_NAME), {})
                                                       ^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get'
2023-08-02 12:33:18.495 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Finished fetching La Marzocco API coordinator data in 1.526 seconds (success: False)
2023-08-02 12:33:58.876 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Update coordinator: Updating data
2023-08-02 12:34:00.459 DEBUG (MainThread) [custom_components.lamarzocco.lm_client] Model name: GS3 AV
2023-08-02 12:34:00.661 ERROR (MainThread) [custom_components.lamarzocco.coordinator] 'NoneType' object has no attribute 'get'
2023-08-02 12:34:00.664 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] 'NoneType' object has no attribute 'get'
Traceback (most recent call last):
  File "/config/custom_components/lamarzocco/coordinator.py", line 63, in _async_update_data
    await self._lm.update_local_machine_status()
  File "/usr/local/lib/python3.11/site-packages/lmcloud/lmcloud.py", line 255, in update_local_machine_status
    self._config_coffeeboiler = next((item for item in self.config.get(BOILERS, []) if item["id"] == COFFEE_BOILER_NAME), {})
zweckj commented

@mtwo yes, thank you, those helped. Let's see if those errors are gone with beta.14

mtwo commented

@zweckj it connected, thank you! I'll test it more thoroughly later today and I'll follow up if any functionality is broken, but at first glance it appears to be working well

Just got to this - mine started working too.

At first glance the boiler temp seems to be double of actual but will take a closer look later

Just got to this - mine started working too.

At first glance the boiler temp seems to be double of actual but will take a closer look later

Maybe a temperature unit mismatch? At those temps, F is roughly twice C.

zweckj commented

@gmathur @mtwo I believe you should now see some warnings can you share what those are (especially the status codes part) as it seems the integration can't connect to your machines locally.

mtwo commented

Looks like a 403

This error originated from a custom integration.

Logger: lmcloud.lmcloud
Source: custom_components/lamarzocco/coordinator.py:63
Integration: La Marzocco (documentation, issues)
First occurred: 7:55:14 AM (89 occurrences)
Last logged: 8:40:25 AM

Could not connect to local API although initialized
2023-08-03 08:39:53.416 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Update coordinator: Updating data
2023-08-03 08:39:53.416 DEBUG (MainThread) [lmcloud.lmcloud] Getting config from local API.
2023-08-03 08:39:53.562 WARNING (MainThread) [lmcloud.lmcloud] Could not connect to local API although initialized
2023-08-03 08:39:53.565 DEBUG (MainThread) [lmcloud.lmcloud] Full error: Querying local API failed with statuscode: 403
2023-08-03 08:39:53.566 DEBUG (MainThread) [httpcore.connection] close.started
2023-08-03 08:39:53.567 DEBUG (MainThread) [httpcore.connection] close.complete
2023-08-03 08:39:53.568 DEBUG (MainThread) [httpcore.connection] connect_tcp.started host='gw-lmz.lamarzocco.io' port=443 local_address=None timeout=None socket_options=None
2023-08-03 08:39:53.580 DEBUG (MainThread) [httpcore.connection] connect_tcp.complete return_value=<httpcore._backends.anyio.AnyIOStream object at 0x7f48f24e10>
2023-08-03 08:39:53.580 DEBUG (MainThread) [httpcore.connection] start_tls.started ssl_context=<ssl.SSLContext object at 0x7f63d51ac0> server_hostname='gw-lmz.lamarzocco.io' timeout=None
zweckj commented

Looks like a 403

Interesting, I'm wondering what's going on there. Seems like something is different for your machine... if you find the time the mitmproxy logs between the official app and the machine would be interesting.

@rccoleman you don't have those issues with your AV, do you?

mtwo commented

My GS3 AV gateway version is 3.1-RC6, firmware version is 1.40, not sure if that helps. My La Marzocco app is able to connect to the machine locally still.

I have a few VLANs on my network, however Home Assistant has native access to all of them (one virtual interface per VLAN / subnet), including the one that the GS3 is connected to. It occurred to me that the 403 could be for the traffic coming in from a different subnet if it was somehow sent out from the wrong VLAN, but this was never an issue before and the VLANs are all isolated by a firewall anyways (meaning that the request from HA wouldn't even reach the GS3 if it was from a different VLAN / subnet).

I'll try to MITM the traffic when I get a chance, though this might not be possible for a few weeks.

mtwo commented

Actually, I restarted Home Assistant and it appears to be connecting locally now!

zweckj commented

Actually, I restarted Home Assistant and it appears to be connecting locally now!

Weird. But good that it works!

Just got to this - mine started working too.
At first glance the boiler temp seems to be double of actual but will take a closer look later

Maybe a temperature unit mismatch? At those temps, F is roughly twice C.

Weird, I just noticed that all my temperatures are doubled as well:

Steam boiler:

current_temperature: 442.8
temperature: 491

Coffee boiler:

current_temperature: 370.6
temperature: 397.4

I don't think it was the 2023.8 release, as I have my coffee temp on my main dashboard and would have noticed. I'm out of town today and was surprised to see the temp as 400+ degrees.

@rccoleman you don't have those issues with your AV, do you?

I don't see those connection failures in the current or previous logs.

Just got to this - mine started working too.
At first glance the boiler temp seems to be double of actual but will take a closer look later

Maybe a temperature unit mismatch? At those temps, F is roughly twice C.

I doubt its the C -> F thing. My machine is set to F and Im seeing 398 F as the boiler temp :)

Used to be fine till atleast a few betas back (the last 2 or so didnt really work for me) so feels like a regression in the last few beta releases @zweckj

zweckj commented

I don't think it was the 2023.8 release, as I have my coffee temp on my main dashboard and would have noticed. I'm out of town today and was surprised to see the temp as 400+ degrees.

I think that probably happened when I removed the state_attributes. I'm using metric so nothing changed for me. beta.15 should hopefully fix that.

That fixed it for me.

However, I think there is something funky with state attributes. My GS3 is showing as "permanently on" monitoring switch.gs3_main

zweckj commented

However, I think there is something funky with state attributes. My GS3 is showing as "permanently on" monitoring switch.gs3_main

That one I can't reproduce, sorry... Even if I configure a wrong IP address and therefore force the integration to only communicate through the cloud (that's happening for you apparently) it's still working for me.
Keep in mind the updates can take up to 30 seconds in cloud only mode if you change the state out the machine outside of HA (e.g. by moving it out of Standby by turning the paddle)

I can repro the stuck mode quite reliably i.e. its pretty permanently reflecting only that. I also have websockets enabled now in case that helps.
Anything I can do to get you the data?

I think I figured this out. I think at some point triggering backflush made this state stuck in the LM cloud - this implicitly was marking the machine “on” 🤷🏽

God help us with IoT companies doing “cloud” 🙈

Thanks again for all your work on this! Just upgraded to beta.15 and now seeing the following error

2023-08-06 08:07:01.303 WARNING (MainThread) [lmcloud.lmcloud] Could not connect to local API although initialized
2023-08-06 08:07:02.241 ERROR (MainThread) [homeassistant.components.water_heater] Error adding entities for domain water_heater with platform lamarzocco
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 471, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 661, in _async_add_entity
    capabilities=entity.capability_attributes,
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/water_heater/__init__.py", line 202, in capability_attributes
    if self.supported_features & WaterHeaterEntityFeature.OPERATION_MODE:
       ^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/lamarzocco/water_heater.py", line 107, in supported_features
    return WaterHeaterEntityFeature.TARGET_TEMPERATURE | WaterHeaterEntityFeature.ON_OFF
                                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/enum.py", line 783, in __getattr__
    raise AttributeError(name) from None
AttributeError: ON_OFF
2023-08-06 08:07:02.247 ERROR (MainThread) [homeassistant.components.water_heater] Error while setting up lamarzocco platform for water_heater
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 328, in _async_setup_platform
    await asyncio.gather(*pending)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 471, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 661, in _async_add_entity
    capabilities=entity.capability_attributes,
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/water_heater/__init__.py", line 202, in capability_attributes
    if self.supported_features & WaterHeaterEntityFeature.OPERATION_MODE:
       ^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/lamarzocco/water_heater.py", line 107, in supported_features
    return WaterHeaterEntityFeature.TARGET_TEMPERATURE | WaterHeaterEntityFeature.ON_OFF
                                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/enum.py", line 783, in __getattr__
    raise AttributeError(name) from None
AttributeError: ON_OFF
zweckj commented

@edwardsa could it be that your Home Assistant is not up to date?

Could be. Thanks for the suggestion. I just updated to the latest home assistant and the error has gone away.

The current_temperature attribute for the boilers now seems off in the other direction in the last couple of betas:

min_temp: 185
max_temp: 219.2
current_temperature: 84.4
temperature: 203
target_temp_high: null
target_temp_low: null
icon: mdi:water-boiler
friendly_name: Buzz Coffee
supported_features: 9

It should be ~205.

zweckj commented

The current_temperature attribute for the boilers now seems off in the other direction in the last couple of betas:

It should be ~205.

Not a clue why HA would convert the other values but not that one. In metric all is normal.

Edit: I just switched HA to °F and conversion in the GUI went flawlessly. @rccoleman where did you get this text return from?

Edit 2: 84.4°F are 29.1°C which is right in the temperature range when my boilers are off for a longer period of time. Are you sure the problem isn't somewhere else?

Now it's mysteriously correct, and I suspect that it's related to a bunch of these this morning:

2023-08-06 09:50:35.454 WARNING (MainThread) [lmcloud.lmcloud] Could not connect to local API although initialized.

It's since corrected itself without any intervention on my part. I had restarted HA while it was reporting the wrong value and it continued to do so when it came back up, and I haven't done anything with the machine itself beyond pulling a shot.

It was definitely on and up to temp when it was reporting 84.4F this morning, which is what initially concerned me. The front panel display was reporting the correct value. I wonder if it was cached in the integration when it was unable to connect locally, and the value was from when the unit was off (the last time it successfully connected)? And retained that value across an HA restart?

@rccoleman where did you get this text return from?

It's a text dump of the attributes section from DevTools->States for the coffee boiler entity

zweckj commented

It was definitely on and up to temp when it was reporting 84.4F this morning, which is what initially concerned me. The front panel display was reporting the correct value. I wonder if it was cached in the integration when it was unable to connect locally, and the value was from when the unit was off (the last time it successfully connected)? And retained that value across an HA restart?

Probably not, values shouldn't be retained across restarts. What rather happened is: The local connection failed, so there was a fallback to the cloud endpoints for the status. And I could imagine those weren't updated successfully with new values from the machine either and still reported the old values...

Makes sense. More fun and games with RCxx version, I guess.

Grrr, happening again this morning
[lmcloud.lmcloud] Could not connect to local API although initialized

In this case, it looks like it happened as it was coming up to temp this morning, as it's showing 115F. When I tried to turn it off, it took a long time to turn off, but eventually did and the temp started reporting correctly. I guess it's getting the proper temp during the command to toggle power? I'm still getting the error above in the log.

zweckj commented

Grrr, happening again this morning [lmcloud.lmcloud] Could not connect to local API although initialized

In this case, it looks like it happened as it was coming up to temp this morning, as it's showing 115F. When I tried to turn it off, it took a long time to turn off, but eventually did and the temp started reporting correctly. I guess it's getting the proper temp during the command to toggle power? I'm still getting the error above in the log.

It can get the temperature either in the regular, scheduled update calls (every 30s) which will be either local connections or cloud connections (depending on what is available) or updated through a WebSocket message. The machine sends temperature updates every now and then on the WebSocket, but a command doesn't necessarily force a temp update from my end - maybe LM does one to their cloud though.

You can check your debug log as to why the local connection failed, maybe you get the 403 as well, then I would be very interested in you doing some research why that might be happening to you, as I'm not having those issues with my machine.

Thanks, I'll turn on debug and see if I can track it down.

Yep, it's a 403:

2023-08-07 07:51:12.327 DEBUG (MainThread) [custom_components.lamarzocco.coordinator] Update coordinator: Updating data
2023-08-07 07:51:12.327 DEBUG (MainThread) [lmcloud.lmcloud] Getting config from local API.
2023-08-07 07:51:12.447 WARNING (MainThread) [lmcloud.lmcloud] Could not connect to local API although initialized
2023-08-07 07:51:12.448 DEBUG (MainThread) [lmcloud.lmcloud] Full error: Querying local API failed with statuscode: 403

I'm getting "Not Authorized" along with the 403 when I test with Postman using GET with http://192.168.1.215:8081/api/v1/config. To make sure I'm doing the right thing, I'm retrieving a token from https://cms.lamarzocco.io/oauth/v2/token, making a request to https://cms.lamarzocco.io/api/customer with that token, retrieving the communicationKey from that response, and then use that as a Bearer token with http://192.168.1.215:8081/api/v1/config?

I'm still getting "Not Authorized" with that procedure after disabling the integration and bouncing the machine power. I'm getting the green bar in the official app (iOS), so I think that indicates that it's able to connect locally?

It did magically start working on its own yesterday, so it could just be a transitory failure. But it's odd that it's explicitly rejecting the token.

Edit: Ah, it doesn't like Postman's User-Agent. I changed it to La Marzocco/3.0.2 (iPhone: iOS 17.0; Scale/3.00), which is what I get when I Wireshark the connection from the iOS app, and Postman gets a valid response now. It looks like you're sending Python/3.11 aiohttp/3.8.5 (just the default), and it's working now that I disabled and re-enabled the integration. I wonder if it only cares about the User-Agent some of the time, and connecting with the app helped get past that for now?

Based on my relatively positive Postman results, I suspect that the User-Agent is the key here somehow, and setting it to match the mobile app would be helpful.

zweckj commented

Interesting, that's something I never paid attention to, because my Micra doesn't care at all, I was always able to connect with Postman immediately. I'm wondering what exactly it checks for in the User-Agent. Maybe La Marzocco?

Hard to say, since now it's accepting either. I'll try to be more methodical about it if it happens again tomorrow.

zweckj commented

What if you turn your machine off completely (really remove the power), does it switch back to denying you again?

Yes, and I'm debugging now.

zweckj commented

Great! Because I checked again for my machine and it really doesn't care about the header...

I'm quite confused right now. I've even seen the official iOS app try to access http://192.168.1.215:8081/api/v1/config and get the same Not Authorized back, but then it just moves on to open the websocket connection. After that, I can successfully use Postman to access the same endpoint and it returns the expected JSON data. If I bounce the machine power and try to connect the websocket via Postman, it immediately disconnects. If I start the iOS app and it connects, I can suddenly connect to the websocket endpoint and the "config" API responds correctly.

There must be some sort of handshake that I'm missing, but I haven't found it in the Wireshark trace yet. The workaround seems to be to open the official app once if the integration can't connect to the local API and let it do its magic.

This from the iOS app after bouncing the machine power:

4425	35.314158	192.168.1.150	192.168.1.215	HTTP	358	GET /api/v1/config HTTP/1.1 
4426	35.315477	192.168.1.150	192.168.1.215	TCP	60	[TCP Dup ACK 4424#1] 63380 → 8081 [ACK] Seq=305 Ack=1 Win=65535 Len=0
4429	35.338316	192.168.1.215	192.168.1.150	TCP	123	8081 → 63380 [PSH, ACK] Seq=1 Ack=305 Win=5440 Len=69 [TCP segment of a reassembled PDU]
4430	35.338962	192.168.1.215	192.168.1.150	TCP	56	8081 → 63380 [PSH, ACK] Seq=70 Ack=305 Win=5440 Len=2 [TCP segment of a reassembled PDU]
4431	35.339280	192.168.1.215	192.168.1.150	HTTP	68	HTTP/1.1 403 Forbidden  (text/html)
4432	35.341501	192.168.1.150	192.168.1.215	TCP	60	63380 → 8081 [ACK] Seq=305 Ack=86 Win=65535 Len=0
4482	35.834681	52.29.238.7	192.168.1.215	TLSv1.2	486	Application Data
4483	35.853165	192.168.1.215	52.29.238.7	TLSv1.2	87	Application Data
4502	36.058643	52.29.238.7	192.168.1.215	TCP	60	8883 → 62496 [ACK] Seq=6341 Ack=6057 Win=64800 Len=0
4508	36.130601	192.168.1.215	52.29.238.7	TLSv1.2	289	Application Data
4523	36.293125	52.29.238.7	192.168.1.215	TCP	60	8883 → 62496 [ACK] Seq=6341 Ack=6292 Win=64800 Len=0
5808	43.908247	192.168.1.215	52.29.238.7	TLSv1.2	85	Application Data
5961	44.078771	52.29.238.7	192.168.1.215	TCP	60	8883 → 62496 [ACK] Seq=6341 Ack=6323 Win=64800 Len=0
5962	44.078800	52.29.238.7	192.168.1.215	TLSv1.2	85	Application Data
5970	44.087327	192.168.1.150	192.168.1.215	TCP	78	49524 → 8081 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1134347859 TSecr=0 SACK_PERM
5992	44.124784	192.168.1.215	192.168.1.150	TCP	58	8081 → 49524 [SYN, ACK] Seq=0 Ack=1 Win=5744 Len=0 MSS=1440
5993	44.128774	192.168.1.150	192.168.1.215	TCP	60	49524 → 8081 [ACK] Seq=1 Ack=1 Win=65535 Len=0
5994	44.130509	192.168.1.150	192.168.1.215	HTTP	350	GET /api/v1/streaming HTTP/1.1 
6002	44.146410	192.168.1.215	192.168.1.150	HTTP	183	HTTP/1.1 101 Switching Protocols 

And then it happily goes on to use the websocket. There's also some interspersed communication with the cloud, so maybe there's something in there.

zweckj commented

Intriguing. Maybe it needs the Bluetooth auth command first before it opens the local API? Although that would be pretty stupid, but on the other hand they're notorious for mixing protocols...

zweckj commented

@rccoleman v0.12.1-beta.1 tries to initiate a BT connection before trying to connect to the local API, let's see if that makes a difference for you

mtwo commented

You might be on to something. I think that I'm typically only getting a remote connection between HA and my GS3, as the boiler temperatures are only updating every two hours or so. However if I connect to the machine with the app, the temperatures start updating in HA every 30 seconds, which might indicate that it established a local connection?

Unfortunately my HA hardware is too far away from my GS3 to test the Bluetooth handshake from Home Assistant.

zweckj commented

temperatures start updating in HA every 30 seconds (which might indicate that it established a local connection?).

It tells you in the logs whether it's a remote or local connection (or rather only if it falls back to cloud). The integration per se always updates every 30s.

Unfortunately my HA hardware is too far away from my GS3 to test this further.

HA's Bluetooth proxies are cheap and are functioning great for me if you wanted to get a Bluetooth connection from HA to a far away device.

Unfortunately, I can't do anything on my own here. My machine is always accepting (and always has) local traffic. I wouldn't be too surprised if that was a bug in your machine's software tbh...

orxelm commented

Guys which branch I can use meanwhile for the integration to work?

zweckj commented

Guys which branch I can use meanwhile for the integration to work?

You need my fork as custom repository https://github.com/zweckj/lamarzocco

mtwo commented

I'll have a chance this weekend to spend more time capturing logs and trying to MITM the traffic between the app and the machine to find out why an app connection needs to take place before HA can get local API access.

@rccoleman I don't think that there's a bluetooth handshake: I launched the app too far away for Bluetooth to connect but while on the same network as the machine, and it still allowed HA to start getting better data almost immediately. If there's a handshake then it must be occurring over the network, either directly from the app or perhaps proxied via their cloud service.

Here's an example of where HA was only getting periodic data (presumably from the cloud, though I'll validate this) until I opened the app on my phone:

image

I agree, thanks for checking. I can always 'fix' it by launching the official app and letting it connect. I did see some communication from the machine to LM, but not what it's doing or what triggered it.

mtwo commented

I was able to test this again with my La Marzocco app while not connected to WiFi. It did not cause HA to get more datapoints, which implies that the handshake is still local (or perhaps local followed by cloud, but I hope not). As mentioned above, I'll try to MITM this over the weekend.

zweckj commented

I was able to test this again with my La Marzocco app while not connected to WiFi. It did not cause HA to get more datapoints, which implies that the handshake is still local (or perhaps local followed by cloud, but I hope not). As mentioned above, I'll try to MITM this over the weekend.

what happens if you do the same test, but with WiFi on and Bluetooth off (the app will complain quite a bit, but should still function)?

Just tested two things:

  • Disabling Bluetooth still worked fine, in fact the app never complained and it behaved normally. Perhaps the connection to the GS3 behaves differently than the Linea Mini or Micra.
  • Blocking my phone from the internet via firewall caused the app to hang upon opening, probably because it tries to log in to La Marzocco before connecting to the machine.

I just grabbed a mitm trace and saw some interesting transactions. Here's a pic:

image

First, you can see that it tries to connect to my machine and fails with the same 403 error that the integration gets. It then does a GET https://gw-lmz.lamarzocco.io/v1/home/machines/GS013432/token-request, which returns this:

{
    "data": {
        "commandId": "78c69d29-f764-4edd-b8bf-1a35e299b47a"
    },
    "status": true
}

It then makes a request to the cloud "commands" endpoint with that commandid and returns a bunch of stuff that I don't understand, but makes lots of references to tokens (command seems to be TokenGet)

Later, it =makes a request to POST https://gw-lmz.lamarzocco.io/v1/home/machines/GS013432/clock with the current date and time:

{
    "date": "Mon Aug 21 2023 17:54:32 GMT-0700 (Pacific Daylight Time)"
}

and gets back another commandid. It makes another request to the cloud "commands" endpoint with that commandid and gets back some stuff that looks similar to the first call (command this time is TimeStampUpdate).

After it does those things, the next call to the machine's local API succeeds. I haven't looked closely at what the localapi part of lmcloud does, but I suspect the magic is in those API calls somewhere. I saved the flows so that I can go back and review them later, but I suspect that you'd see something similar with your machines. Does that command sequence reflect what's currently done in the integration?

Does that command sequence reflect what's currently done in the integration?

Not at all 😅I saw some of those commands as well, but ignored them entirely, because I didn't need them. I just get the token from the cms endpoint and call the /config and /stream endpoints with that directly without any other logic.
What would be interesting is, what happens if you'd block the machine from accessing the internet in the firewall (not the app). Does it ever resolve that 403?
I'm currently blocked to do any tests on my end, because my machine disconnected from my WiFi and it doesn't want to activate Bluetooth again to reconnect...

I'll run some more experiments when I get some time, including simulating the GetToken and TimeStampUpdate commands and see if it helps. My machine falls into the broken state quite frequently now, so it makes me think that something may have changed on the LM side. It wasn't an issue when I first updated to the new gateway, but now it's broken more often than not.

BTW, hopefully you can get your machine to connect again :). I'm curious if you would see the same type of transactions for your machine, even if it's able to initially connect, or if it's a reaction to the failure. It's also possible that LM treats the Micra (designed as a home machine) and GS3 (more prosumer, could be in a cafe) differently.

BTW, hopefully you can get your machine to connect again :).

I do hope so, thanks! Currently in contact with LM's IoT support in Italy...

I'm curious if you would see the same type of transactions for your machine, even if it's able to initially connect, or if it's a reaction to the failure.

Me too.

It's also possible that LM treats the Micra (designed as a home machine) and GS3 (more prosumer, could be in a cafe) differently.

Something is definitely different about the GS3. I've heard zero complaints from Micra/Mini owners in that direction.

My initial testing shows that doing these two things fixes the connection issue:

image

I didn't even have to do anything with the response. I just used Postman to send the first one, got the commandid from the response (which was different from the initial trace), then made a separate request to the "commands" endpoint. The connection errors stopped and I suddenly got the correct current temperature in the integration.

Wondering what they're doing this for. I'll add it to lmcloud. The question is, how often does this call need to be made?

Wondering what they're doing this for. I'll add it to lmcloud. The question is, how often does this call need to be made?

I would say 'when it fails', but I'll check if the app just does it unconditionally or if it's triggered by a connection failure. My guess is that when the app starts they spawn a thread that keeps trying to connect locally and another that does the cloud connection. From the app, it seems like it just keeps trying the local api while the app is open to see if it's working (in case you come into range, restart the machine, etc). They're probably not expecting the app to stay running continuously, as the integration does.

I understand that tying the cloud and localapi pieces together to trigger a new token request on a local failure probably isn't ideal. I don't see anything in the responses about token expiration, but maybe you would if these calls work for your machine.

I understand that tying the cloud and localapi pieces together to trigger a new token request on a local failure probably isn't ideal.

don't worry they are tied together in the main class anyways.

I don't see anything in the responses about token expiration, but maybe you would if these calls work for your machine.

yeah that might take a while... LM sends me an entirely new IoT board to swap out the current one...
I published 0.12.2-alpha.1. But it's best guess development as I can't test it at all. Maybe we're lucky though and it works (and I didn't make the usual silly coding mistake)... Give it a try please and let me know.

Will do. Does your machine need to be online to make those calls to the cloud API in Postman (or equivalent)?

Results look positive so far. I got exactly one of these, but it seemed to recover and start providing valid data:

2023-08-23 10:35:24.100 WARNING (MainThread) [lmcloud.lmcloud] Could not connect to local API although initialized

BTW, I still always get this on shutdown. I keep meaning to look into it, but never do:

2023-08-23 10:42:47.000 WARNING (MainThread) [homeassistant.core] Task <Task pending name='Task-19363' coro=<LMLocalAPI.websocket_connect() running at /usr/local/lib/python3.11/site-packages/lmcloud/lmlocalapi.py:77> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]> was still running after stage 2 shutdown; Integrations should cancel non-critical tasks when receiving the stop event to prevent delaying shutdown

Will do. Does your machine need to be online to make those calls to the cloud API in Postman (or equivalent)?

I don't know. I removed my machine from the app, now I don't have anything in my LM account anymore, so I can't do anything...

Results look positive so far. I got exactly one of these, but it seemed to recover and start providing valid data:


2023-08-23 10:35:24.100 WARNING (MainThread) [lmcloud.lmcloud] Could not connect to local API although initialized

I probably need to wait a bit before trying the local call again and it's currently only reconnecting on the next iteration.

BTW, I still always get this on shutdown. I keep meaning to look into it, but never do:


2023-08-23 10:42:47.000 WARNING (MainThread) [homeassistant.core] Task <Task pending name='Task-19363' coro=<LMLocalAPI.websocket_connect() running at /usr/local/lib/python3.11/site-packages/lmcloud/lmlocalapi.py:77> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]> was still running after stage 2 shutdown; Integrations should cancel non-critical tasks when receiving the stop event to prevent delaying shutdown

I believe those are coming from the WebSocket task still running in the background. I tried a couple of things to terminate it cleanly, but never figured it out.