Decoded some more parts around the heating and pump states. The commands are simply memory reads and writes with 16bit address and 16bit length, so I dumped the entire address space (some accessible, some not) and found an interesting tidbit. Starting at address 0x0100 is the following:
I can connect to the MQTT broker using the GUID as the username and the long string that follows as password @ port 8883, but it immediately disconnects. Changing the username or password fails initial authorization, so Iām pretty sure those are correct. Iāve tried using different client IDs (the GUID, machine serial number, Z + serial number (as in the memory dump), others) with no luck. I havenāt checked if the machine is actually connecting to this broker or not.
I added a couple of commands to the dev version of the test app to read arbitrary memory:
10 aaaallll issues a single āreadā command, where aaaa is the 16-bit address to start at and llll is a 16-bit length. The machine wonāt return large chunks of data, so you have to read a bit at a time. An example is 10 0100001F, which reads the first 32 bytes of the memory region above
11 xx reads an entire 256byte block of memory, where xx is the upper 8-bits of an address range. An example is 11 00 to read and dump the first 256bytes of the memory space.
Thereās a lot of repetition in the memory, some regions get no response at all, and some appear to echo back the command in the response data. Itās weird. I found the memory region that represents the contents of the front display of my GS/3: STAND-BY 10 12p
Itās pretty close to having all the functionality that I would want at a glance. Anything you guys are looking for? I could do something similar for prebrew.
Hey plonx, Would you be able to share more details on how you got your mini into HomeKit? Iām pretty new to the home-assistant ecosystemā¦ Any additional details you can share would be greatly appreciated!
I just made an account so I could let youāll know that I really like this project and what you guys are doing.
I donāt know anything about programming or coding, but I do have homebridge running for HomeKit. I miss the integration in HomeKit for my Linea Mini. Is that what youāre building or am I confusing things?
If there is something for me to contribute or test please let me know.
My goal here was to allow Home Assistant to see the current status of the machine and control it. With that done, you can then use HA automations, scripts, voice control, and Lovelace UI capabilities to interact with it. Since La Marzocco doesnāt provide a direct interface to HA or Alexa/GA, either using the high-level REST API that plonx mentioned or the integration that Iāve developed can help bridge the gap. I could easily expose my GS3 as an Alexa device and turn it on or off by speaking to an Echo/Dot/etc., for instance.
I donāt personally use HomeKit, so perhaps plonx can describe what heās done there.
Unfortunately, both methods require retrieving the client_id and client_secret thatās used to communicate with the La Marzocco server, and thatās not very user-friendly. I simplified the process as much as I could here, but I expect that itāll be a significant stumbling block for ānormalā users.
Has the integration been reliable for you? Some of the changes that Iāve made recently are an attempt to make it more resilient to connection issues, but itās been pretty solid for me.
I updated the Lovelace card docs and will get it added to the default HACS list. For now, you can add the repo manually in HACS or install manually, as described in the instructions.
It needs at least v0.7.4 of the integration (released almost a week ago), so make sure thatās installed before trying to use the card. One of the benefits of using the card is that itās much, much faster than using the mobile app.
Edit: Updated the card again - it no longer requires an entity_id to be specified because it finds the right one automatically. It makes the card really easy to use with a config like this:
Itās now possible to add and configure the card via the Lovelace UI ā+ Add Cardā interface, and the card preview updates automatically as the config is changed.
Any thoughts on how the client Id & secret are provisioned to the app? Iām no expert on this topic, but I thought these values would be issued to the app prior to distribution, and so be consistent for every user.
Iāve wondered the same thing. Maybe theyāre identical for all users, or for an app family, or app version. It could also be calculated and provisioned during initial pairing. I havenāt tried repairing to check.
Here are the first 10 characters of my client_id: 4_2d2impyk
And client_secret: 1m52x65srm
Well, thatāsā¦curious. I wonder if itās based on the Bluetooth or Wifi MAC address, where the OUI would lend some similarity. It doesnāt look like any sort of hash that Iām familiar with, and itās not base64. I just rechecked my secret and I posted the correct hash for my value. If youāre comfortable with it, would you mind exchanging client_secret values via DM? Token access is still further protected with email/password, and Iām really curious if itās possible to decode it by analyzing the differences. If not, thatās cool.
Iām dying to know how the client_id and client_secret are encoded, and Iāve been staring at them hoping for inspiration.
The ā4_ā that starts the client_id seems to be some sort of preamble that isnāt matched in the client_secret
If you strip the ā4_ā in the client_id, both strings are 50 characters, which is a weird length
Both appear to start with a character sequence with some variety, including numbers and letters that donāt appear in the latter portion of the string
Thatās followed by a sequence with a very limited character set and what appears to be some small repetitive sequences
I intuitively broke it up in 12 characters followed by 38, but that may not be accurate or meaningful.
After the first sequence, the remaining sequence (38 or ?) characters are drawn from the same 9 characters in both strings: w, k, s, g, c, o, 0, 4, 8
The character frequency isnāt consistent between the two
With the limited character set, I canāt believe that this the output of any hash, encryption, or common encoding, but thereās no obvious pattern that I can see.
I donāt know why I didnāt think of this before, but I just downloaded the Android APK and the client_id and secret are sitting right in the Javascript in plaintext:
Thatās the same secret that I retrieved via my iOS app, so Iām curious why @mrvautin ended up with a different hash. Thereās also a Google API key and a Mixpanel token in there.
Iām tempted to just hardcode the client_id and client_secret in the integration now that it appears to be built into the app, but Iād like to clear up why we donāt all see the same values first.
