Giters

phord / Jarvis

Hacking the Jarvis standup desk from fully.com for home automation using an ESP8266 arduino interface

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

A few qustions about commands

kquinsland opened this issue · comments

commented

Hi!

Thanks a ton for your work on this. I am working on porting your work to ESPHome and have managed to get the basics working: I can request the motor move to a preset.

I was wondering if there was a way to inquire about certain things rather than SET them. Almost all of the commands you've documented cover SETTING/CLEARING things.

How does the remote get the motor controller to respond with the height? I have used your notes to decode the height ... when it's transmitted. I want to get the motor controller to send this information on command, though.

I can keep spamming the WAKE 0x29 command and this will light the remote buttons up. The screen will be blank for a few seconds. I suspect that it's waiting for a height report and - after some timeout period of a few seconds - the remote falls back to just displaying the "fully" logo. It will display the logo until I stop spamming the WAKE commands.

Likewise, is there a way to inquire about the units without having to issue the 0x0E command?

commented

Hi @kquinsland,

I think I can answer these to you.

How does the remote get the motor controller to respond with the height?

My experience is that the controlbox will never shut up really. If you send any command it'll spam a couple dozen of height reports back to you. Thus the initial 0x00 empty message. If you don't get anything back from it, then there's probably something wrong with the communication. Check the wiring.

Is there a way to inquire about the units without having to issue the 0x0E command?

Try 0x07. I spent some time reverse engineering more commands. The controlbox answers to 0x07 with:

0x25 - PresetRaw1
0x26 - PresetRaw2
0x27 - PresetRaw3
0x28 - PresetRaw4
0x0E - Units
0x19 - TouchMode
0x17 - KillMode (Anti-collision enabled)
0x1D - Sensitivity

Raw presets are just motor positions, they have to be converted to units.

Sorry for the self-advertisement but you can find more information about extra commands in the project I'm building:

commented

HA! I am also working on a similar ESPHome component. I've been pretty happy with it but not gotten around to fixing one small mistake on the rev1 PCBs prior to making the repo public.

This is what I have so far:

pngout

In addition to the desk controller, I also have two RGB strips of LEDs and a lidar sensor hooked up to this PCB.

Your code / esphome component is almost certainly going to be neater than my code but i'll try to get what I have posted public in the next 24h in the off chance that it's somehow going to help you with your component.

Looking @ your repo:

The "handset control lines" are unnecessary. Everything can be done via UART messages.

This has me so damn excited. I would love to re-spin my PCB to be even simpler (and more reliable!).

commented

Few extra delays, but I've finally gotten my stuff out: https://github.com/kquinsland/fully_jarvis_esphome

I've starred / followed your repo @maraid. Looking forward to a simpler ESPHome component that uses UART only... which - hopefully - should solve some of the issues I have in my own code.

commented

Hi!
Good to hear that you haven't given up. Feel free to take anything from what I've done. I cannot access the repo you linked, is it private maybe?

I'm not planning on creating a proper ESPHome component and it's kind of hacky right now as you can see in the yaml. I might create a better HA card because it is pretty basic right now.
image

Good luck with your project and let me know if I can be of any help.

commented

. I cannot access the repo you linked, is it private maybe?

It was! Thanks for catching that :).

I'm not planning on creating a proper ESPHome component

Sorry to hear that. You should re-consider as it's not much more work beyond what you've already done to get the c++/h files included. Really, it's just some python which helps ESPHome understand how to validate the yaml and how to pass off the sensor/entity IDs to your code.

Feel free to use the esphome component in my repo as a starting point. I got some help from this guy on the ESPHome discord and used the desky component as a reference of sorts: https://github.com/ssieb/custom_components/tree/master/components/desky

Looking at your yaml, what's the difference between these two:

  - platform: template
    name: "$name Height"
    id: height_number
    optimistic: false
    min_value: 1
    max_value: 1800
    step: 10
    set_action:
      - lambda: (*reinterpret_cast<JarvisDesk*>(id(desk))).move(x);
  - platform: template
    name: "$name Offset"
    id: offset_number
    optimistic: true
    min_value: 1
    max_value: 1800
    step: 1
    set_action:
      - lambda: (*reinterpret_cast<JarvisDesk*>(id(desk))).setOffset(x);

Does the 'move' command work precisely? That's the biggest "i want to improve" from my current implementation: https://github.com/kquinsland/fully_jarvis_esphome/blob/main/components/fully_jarvis_cb2c/fully_jarvis_cb2c.cpp#L154

commented

Feel free to use the esphome component in my repo as a starting point.

Thanks. It really doesn't seem all that difficult as I imagined.

Looking at your yaml, what's the difference between these two:

Height is what's shown on the display. Offset is what you would set with the calibration menu. In other words the lowest position of the desk. The upper limit for the offset is 65535 not 1800 but it would be pointless to set it anything beyond the displayable range.

Does the 'move' command work precisely?

Mostly. I'm using centimeters and there's a slight problem with it. Whenever the desk moves upwards it stops 2 mm early. I couldn't figure out the reason so I just corrected it like so and it works.
(I didn't really test anything using inches.)

void JarvisDesk::move(uint16_t height)
{
    // Hysteresis correction
    if (height > mHandset.getLastReportedHeight())
        height += 2;
    sendMessage(SerialMessage(CommandFromHandsetType::MoveTo, 
                              static_cast<uint16_t>(height)));
}

Edit:
I see what issues you had with setting the height precisely. This command definitely solves that. It does the deceleration the same as the memory buttons.

commented

Thanks. It really doesn't seem all that difficult as I imagined.

Right? The ESPHome docs are lacking on the 'getting started' front which is why my first several custom components were done the "manual include" way. For better or worse, I 'reverse engineered' a lot of the python by cloning the esphome repo locally so I could study other components to get an idea for how Voluptuous had been used/extended and how to write the yaml -> c++ linking functions so entity IDs and the like are properly passed into your C code.

I see what issues you had with setting the height precisely. This command definitely solves that. It does the deceleration the same as the memory buttons.

AWESOME. I know it's such a small thing, but it bugs me so much that I had to YOLO it with the precise height 'go to' command. I always assumed that there would be a UART command for it but didn't have the time/effort to properly sus it out.

I guess I'm still confused about what the offset would be used for. The only thing that comes to mind is if you wanted to program in the height of a desk / work surface so the display would indicate the height of the desk top and not the height of the motor/frame that the desk rests ontop of.

commented

I guess I'm still confused about what the offset would be used for. The only thing that comes to mind is if you wanted to program in the height of a desk / work surface so the display would indicate the height of the desk top and not the height of the motor/frame that the desk rests on top of.

Exactly. So in calibration mode it asks you to lower it the lowest position and measure the height of the tabletop. It accounts for not only the thickness of the tabletop but for potential manufacturing errors or the leveling of the desk. I think it's always better to use the built-in calibration than setting the offset manually. When I was brute forcing I messed it up without knowing what it does. It took me some time to figure it out.
Once you set it manually you don't really need to touch it, but it comes in handy when you want to convert the raw preset positions in the response to 0x07. I figured this to be the equation for it: height [mm] = offset + raw * 0.0642mm
Hope this clear things up.