Has anyone had any issues with custom responses and piper? I was following @mostlychris YT videos and have created a special custom_sentences file, added the specific response but when I ask the ESPBox to turn on the specific light, it still defaults to the “turn on light” response.
I was just coming in here to ask how to do that. Well, I’ll keep an eye out in the future! Hopefully it doesn’t take too long to see this.
1 Like
I was able to run ollama in a docker and with a custom hacs integration was able to use llama2 and other llamas with it i didnt have a Nvidia card so its a bit slow but it worked
As far as I could see, there is some work already done to implement the i2c component and the sensors…
It might still take some time, because some components from the Sensor-Dock are not yet available as ESPHome Components, so they probably need to completely create those…
But the AHT30 temperature / humidity sensor might already work with the 2023.12 firmware… but yet, I was not able to successfully add it to the configuration.
Using the Temperature Sensor of the SENSOR Dock:
by adding the following config, the AHT30 temperature & humidity sensor can be used with the S3-Box3 SENSOR 
i2c:
- id: bus_a
sda: GPIO08
scl: GPIO18
scan: true
- sda: GPIO41
scl: GPIO40
id: bus_b
sensor:
- platform: aht10
i2c_id: bus_b
variant: AHT20
temperature:
name: "Temperature"
humidity:
name: "Humidity"
update_interval: 1s
4 Likes
Working for me. I did need to clean the build files before I got a successful compile though.
I’m wondering how that can work. Isn’t the address on the I2C bus needed so that the correct chip responds?
Also, the sda and scl pins seem correct for bus_b but the chip is AHT30. Is it downward compatible with AHT20?
the correct i2c chip will be ‘detected’ by the bus_a or bus_b
Since the AHT is using i2c_id: bus_b it is using the chip connected to SDA41 and SCL40
Right now, there’s no component / variant for AHT30
it seems that AHT 20 variant is pretty similar - and I’ve already seen a PR where the AHT component will be changed to add more variants by using AHTxx instead of AHT10…
The important part is how the sensor is reporting the measured values… it might be, that the sensor is newer, but implemented in the same way…
1 Like
Thank you for that tip. I was unsure why I couldn’t get the sensor code working but cleaning the build files did it.
Good news. I have a battery sensor working. Still doing fine tuning, but the config to add is:
sensor:
- platform: adc
pin: GPIO10
name: "Battery voltage"
id: battery_voltage
unit_of_measurement: "V"
accuracy_decimals: 3
device_class: "voltage"
entity_category: "diagnostic"
update_interval: 30s
attenuation: 2.5db
filters:
- multiply: 4
- platform: copy
source_id: battery_voltage
name: "Battery level"
unit_of_measurement: "%"
accuracy_decimals: 1
device_class: "battery"
entity_category: "diagnostic"
filters:
- lambda: return (x - 2.65) / (4.2 - 2.65) * 100;
- clamp:
min_value: 0
max_value: 100
ignore_out_of_range: true
This adds two sensors:
Battery voltage (volts)
Battery level (%)
The tuning I’m doing is measuring actual voltage and reported voltage. Then using the result to add some calibration (so far the above is now testing fairly accurate). Adding the attenuation was needed to prevent it clipping at the top range despite the circuitry having a 3:1 voltage divider.
Once I’ve got the limits properly sorted, I’ll adjust the lambda for the %. Presently it’s calculated based on values before I added the attenuation. You can see the clipping in the graph below and the unit powered down at 9.3% in this graph which was about 2.65V so I had adjusted the lamda to make this 0% in the above calculation.
Now waiting for the Box3 to eat its way through the battery again so I can recalculate the %. I’ll post the update again here once it’s done.
3 Likes
Updated yaml for the battery sensors is"
sensor:
- platform: adc
pin: GPIO10
name: "Battery voltage"
id: battery_voltage
unit_of_measurement: "V"
accuracy_decimals: 3
device_class: "voltage"
entity_category: "diagnostic"
update_interval: 30s
attenuation: auto
filters:
- multiply: 4.01
- platform: copy
source_id: battery_voltage
name: "Battery level"
unit_of_measurement: "%"
accuracy_decimals: 1
device_class: "battery"
entity_category: "diagnostic"
filters:
- lambda: return (x - 2.5) / (4.2 - 2.5) * 100;
- clamp:
min_value: 0
max_value: 100
ignore_out_of_range: true
The voltage is following readings from my multimeter ±0.02V so the ADC measurement seems good. However, my battery seems to be topping out at about 4.0V but 18650 lithium cells are usually rated to a max of 4.2V, hence my unit only gets to about 90% when charging.
This may either be my battery being a bit tired (new but received at 0% so storage was a bit dodgy) or it may be the charging circuit maxing out at that level for safety’s sake. I would be interested if other people can test this to see the max % they can get.
If it’s the charging circuit, the 4.2 in the lambda could come down, but if it’s my battery, it should stay at 4.2.
Graph of a discharge & charge cycle. The glitches are me tweaking the sensors.
hm… I might be able to do a test, too - but honestly, I think, I have only one 18650 here (maybe some older ones in a battery drill, too) … but I don’t know how good they are.
Anyway - I will start testing over the next week when I have holidays and a bit more time to do such stuff… (maybe, I’ll go to get another 18650 if I find one in our store today)
So, one of my 18650 is currently charging…
Not sure yet, If the calculation is right - but I guess, it looks quite OK?
Update:
Update 2:
The box is still connected via USB…
The Battery charge - LED is green…
The Battery Level is decreasing slowly
THANKS everyone for the work above … it has helped a ton!
I’ve gotten the VA working, added the temp/humidity sensor then the battery sensors for the sensor base …
Things seem to be working (even if the temp needs calibration but for now “good enough”) …
Has anyone been successful getting the radar/presence sensor working? That is something that would be a great addition with the base providing presence for a desk or similar 
3 Likes
Afaik, The Radar Sensor needs to be integrated into ESPHome - so right now, there’s no component that we could use for it.
Thanks everyone, i also got mine up and running. Notice though the volume of the built-in speaker is ridiculously low. My thinking is to send output to a different speaker, did anyone already try this?
I saw you mentioned MPD & have installed on my RPi02W voice assistant. I’ve ran into an MPD/HA media_player issue & would like to ask if you encountered this & how you resolved it.
VA is still working fine & I can see MPD service running. HA even recognized it as a media_player once I added the MPD platform configuration. My issue is, if I try to play media to it, HA will ban the RPi02W’s IP address. Have you encountered anything like this & if so, how do you resolve it. Thanks.
I did not run into such issues. So sorry, I have no idea how your problem could be fixed.
was afraid that was the answer … thanks for the confirmation though
Can you post your full yaml please ?
Hey, you wrote that your temp sensor needs to be calibrated…
I am not sure, if this is also true for my device… if yes, have you already done some calibration?
This is the first time I might need to do this - and right now, I don’t have any reference sensor to use for calibration… so I am not sure, how to deal with this… 