@Samsung123 I havenāt quite got that far yet, but this script should help. The only line that needs changing is adding your mac address, save it, chmod +x it then run like
Riiiiiiiiiiiiiiiiiiiiiiight on thankyou! Sorry I thought everyone was doing something magical in the HA automation gui that I couldnt figure out.
So I can basically just make an automation with a threshold helper or in node red where if my SCD-41 temp is is 25c send command 5, when temp is 27c send command 6 and so on?
For example this is how Iām controlling my intake fan to kick in.
I could do some kind of threshold thing where the fan incrementally increases until the input temperature target is met with 1 minute waits or something? Hmmmm ok thanks man this has got me thinking.
Iām having trouble calling the script in HA using shell_command, it seems /usr/bin/expect and /usr/lib/expect5.45.4 paths are not available in the context of the process. Will check it out again a bit later.
Basically, up until now Iāve only been able to control my dehumidifier/humidifier (on/off), intake fan (on/off) and exhaust ((on/off) or manually adjusting/automating in the AC infinity rubbish trash app).
Iāve got to the point where I can set a leaf VPD target, measure live leaf temperature with an MLX90614, and maintain exact leaf VPD regardless of the tent VPD/environment fluctuations using the dehumidifier where tent temperature is an uncontrollable variable in the automation. This is going to be amazing now I can control exhaust to maintain a more linear Tent VPD instead of relying on kicking in the intake fan, especially remotely and ties the whole thing into HA instead of having everything in HA and then a disjointed exhaust fan. I really like the variable speed settings of AC infinity it just sucks their app is so restricted.
Thank you so much @mikeybatoz@jayrama I really really appreciate your help and work. This is going to be next level.
I am more than happy to share my automations/esphome yaml to maintain exact leaf VPD if you want them.
Great, your use case sounds perfect. Definitely feel free to keep sharing in this thread, Iām guessing things will change a bit now that there has been some progress, and maybe a native integration isnāt completely out of the question a little further down the track.
Its possible @mikeybatoz had the sleep commands in there for a reason (or maybe just debug?), but seems to work ok here even with them removed. It is ridiculously quick even using expect, I was quite surprised.
One other thing mikey, someone pointed me at this thread for an unrelated reason - Could you redo the serial extract running the Pill on Bluetooth isteed? Ā· Issue #1 Ā· BestEnemies/pill Ā· GitHub - it has some interesting info that seemed semi related to what we are doing - mainly the work at decoding the hex pairs into int16_t values which at first glance feels very similar. I wonder if we can drag them in too for some advice, or if you might get some ideas from reviewing that postā¦
im guessing this is the same problem I am running into (i can also run it fine from terminal) - when the script runs by HA it does not seem to have access to /usr/bin/expect binary (which is where it is installed to by apk add expect).
if you turn on debug logging then the error output from the script is in the homeassistant logs.
2023-01-25 14:35:08.588 DEBUG (MainThread) [homeassistant.components.shell_command] Stderr of command: `./ac.sh {{ states("input_number.acinfinity_speed") }}`, return code: 127:
b'./ac.sh: line 37: /usr/bin/expect: No such file or directory\n'
(dont forget to set this back to error/warning later)
there is probably an easy workaround, but havenāt had the chance to poke at it yet. I did try dropping the expect binary and its lib file into the current dir but that did not work (the binary is found but the lib is not).
I think I have a misunderstanding about how the HA user is chrooted or how to grant deeper filesystem access to the HA container (outside of the /config folder).
then itāll work, cause now expect will be installed inside the HA container.
But I think it would revert on update perhaps, unsure really - doesnāt seem like the right way to fix it. At the top of the script we can just check if expect is installed, and if not, apk add expect, then itād still work even after the container is recreated, with just a small delay the first time while it installed the package (this may not work if the HA user does not have permission inside the container to apk add).
working for me now, I had to make a small change to the script to allow sliders to work in HA, since they set the value at 10.0 rather than 10.
if [[ $1 == 0* ]]; then speed="0x00 0xaa 0x33"; fi
if [[ $1 == 1* ]]; then speed="0x01 0xba 0x12"; fi
if [[ $1 == 2* ]]; then speed="0x02 0x8a 0x71"; fi
if [[ $1 == 3* ]]; then speed="0x03 0x9a 0x50"; fi
if [[ $1 == 4* ]]; then speed="0x04 0xea 0xb7"; fi
if [[ $1 == 5* ]]; then speed="0x05 0xfa 0x96"; fi
if [[ $1 == 6* ]]; then speed="0x06 0xca 0xf5"; fi
if [[ $1 == 7* ]]; then speed="0x07 0xda 0xd4"; fi
if [[ $1 == 8* ]]; then speed="0x08 0x2b 0x3b"; fi
if [[ $1 == 9* ]]; then speed="0x09 0x3b 0x1a"; fi
if [[ $1 == 10* ]]; then speed="0x0a 0x0b 0x79"; fi
Do I need to create an automation or do I just create a slider with the templated entity? Sorry I know Iām a time waster I just canāt quite connect the dots that you assume I would understand if you know what I mean.
As an example it took me half a day to figure out that I had to change notepad++ to unix for the script to work properly.
this can go into your configuration.yaml or similar (you may need to adjust the path to your script), then you will end up a new entity after restart input_number.acinfinity_speed
in lovelace if you create an entity card for this, then when you slide it, it will trigger the automation which runs the script, and uses the value in input_number.acinfinity_speed as the value that gets sent as the argument to the script (which was just set when you moved the slider).
hope that makes sense. this is just one way it could be used, over the next few days/months Iām sure we will improve on these temporary scripts!