Idea: add piezo speaker to aid plant-sitting

[wrobelda]

I like the project and all, but one particular issue I see is watering plants while away. Typically you need someone somewhat skilled with plants to help you out, on top of a general list of guidelines. B-parasites should help in theory, but I can't imagine getting anyone bothered with access to Home Assistant and figuring out the whereabouts of plants that indicate low moisture.

However, if b-parasite had a small speaker, combined with Holiday mode of sorts it could make the sensors beep, indicating low moisture and thus allowing anyone in the house navigate the plants in need. Considering it's a Home Away mode, the beeping shouldn't really bother anyone and doesn't even have to be a loud one.

I can imagine the beeping would be intermittent, with higher frequency indicating dryer soil.

It could totally make sense to even consider this a regular, always-on feature, assuming not everyone in every household cares for Home Assistant UI but some still may want to help with watering the plants.

[drspangle]

This is an interesting idea but it has a few problems:

• What if multiple b-parasites start beeping?
• What is the impact on battery life, I imagine it would be quite severe if the beeping happens often (necessary to make it an effective notification)?
• How will someone "snooze" the beeping without the ability to give feedback, if it's not an appropriate time to water?

In general I think that the solution here isn't to modify the hardware to incorporate this functionality, rather, an app which provides a better frontend would really solve all the problems here. It could include a setup workflow which requires the user to take a picture of the plant associated with the b-parasite so it can be recognized. The app could also be responsible for notifications, which would ensure that calibration differences, physical differences, or different watering requirements don't cause the individual sensors to need a special setup procedure. My understanding of the design intent for this project is to minimize the power draw to create a long-life sensor, which implies that centralizing interaction with the sensor should be the main approach. Then there's no need for a hardware change, the software can handle all of the use cases associated with this particular suggestion, without sacrificing battery life or increasing the complexity of the hardware design. Just my two cents.

[wrobelda]

• What if multiple b-parasites start beeping?

I don't see a problem with that, actually that's expected. Since they wouldn't beep synchronously, you would be able to locate them, anyway.

What is the impact on battery life, I imagine it would be quite severe if the beeping happens often (necessary to make it an effective notification)?

That's a good point. Maybe the Holiday mode would actually be an "I'm watering plants now" mode, one that would be temporarily enabled via a switch on one of the parasites, which would then sync back to the HUB and enable it on all of them? And it would remain on for 30 minutes or so, unless the plant got watered first? The way it would be enabled is obviously debatable, but to only enable it for short period of time would make sense. I could e.g. add an automation to HA that would enable it automatically as soon as human presence was detected if Holiday Mode in HA was enabled.

It could include a setup workflow which requires the user to take a picture of the plant associated with the b-parasite so it can be recognized.

I am afraid I don't agree. I already use a dedicated app for watering (Planta) and it's a huge hassle to have anyone on it. You're simply asking for too effortful of a favor: they not only need to install the app, configure it, but also learn to navigate and find the plants. I tried once and wouldn't even dare to do so again. Especially not anyone who's older and/or not tech-savvy.

Not to mention that if that was BLE, you'd still have to wait until all parasites sent out their status? Could be several minutes at least, asking plant sitter to wait 1x minutes before all plants report back is another favor to ask for and another complication.

Meanwhile waiting the plants that literally audibly beg for it is a matter of minutes, tops, until the sitter has them all watered, with zero additional effort. It's a KISS solution to a problem.

EDIT: most importantly, my understanding is that piezo speakers are rather highly efficient, compared to traditional speakers. So this whole conversation might be on a non-issue, after all.

[drspangle]

I'm still not convinced adding more complexity to the hardware is the KISS approach. It just sounds like your problem is with the app you use for watering, and a better app would improve the situation. Here are some more points for consideration:

• How big is the speaker, and how much more difficult does it make protecting the hardware (with a case, with waterproofing)?
• Can the speaker be waterproofed, or will it degrade and potentially fail in a way which damages the hardware or drains the battery (I am considering the speaker + the circuit necessary to operate it)?

Maybe a better app would allow for a plant-sitter to have an easy time of watering the plants by sending them an SMS notification (therefore not even requiring the app) containing a link to the image of the plant(s) which need watered, and other information? Again, it just seems to me that a software solution here is far simpler than a hardware solution. It's also difficult for people to localize chirping sounds -- smart smoke alarms fix this problem by enabling an audible message upon triggering in the app, which is nice to have for a device which is difficult to visually distinguish. But the plant visually distinguishes the sensor in this case.

[wrobelda]

I'm still not convinced adding more complexity to the hardware is the KISS approach

But you do realize that this would be an optional component, just like the light, temperature and humidity sensors are already?

Can the speaker be waterproofed, or will it degrade and potentially fail in a way which damages the hardware

Again, if this is anyone's concern, e.g. they want to operate it without an enclosure, then they don't need to install it at all.

or drains the battery (I am considering the speaker + the circuit necessary to operate it)?

Piezo buzzer requires a mere resistor.

Maybe a better app would allow for a plant-sitter to have an easy time of watering the plants by sending them an SMS notification (therefore not even requiring the app) containing a link to the image of the plant(s) which need watered, and other information?

How is this KISS compared to what I suggest? As I mentioned, I already went through it and it's too much of a hassle. I have 50+ plants at my place, expecting someone to go on a visual hunt is just unreasonable.

BTW: Such product already exists, which is where I am drawing this idea from:
https://www.aliexpress.com/item/4000586280615.html

[drspangle]

I'm not saying it's a bad idea, I'm just saying it's not a simple idea and seems to be in opposition to the design philosophy of this project. That's only my opinion, don't take it as a fact. The reason why in particular I am opposed to the idea of including the extra component in the design is that regardless of whether it is optional it impacts the design of the overall PCB and the firmware, increasing its complexity. The case designs have to take into consideration a bulky component, requiring variants. Where on the PCB do you propose to put this speaker when it's going to become the largest component on the board? It needs a footprint regardless of it being optional. Piezoelectric speakers require 5V single-ended or 2.5V bi-polar to run, and the board only operates at 3V3, and has no hardware to create a bi-polar signal, so it will be quiet even if driven at the maximum voltage the board can offer.

All I'm saying is that hardware changes are complex and have all sorts of difficult to predict impacts on the design. The software differences I am proposing are totally decoupled from the hardware, which unlike optional hardware has no impact on the design whatsoever. If you are ambitious and believe that redesigning the PCB and firmware to support this addition is of value, give it a shot. But I don't think it is, I think it would be of far more value to work on better software as this is really what limits the current project state from being at quality parity with commercially available options in my opinion... but it isn't a software project, after all, so maybe my suggested approach is less attractive for that reason.

[wrobelda]

Where on the PCB do you propose to put this speaker when it's going to become the largest component on the board?

Piezoelectric speakers require 5V single-ended or 2.5V bi-polar to run,

I would appreciate a more merit-based discussion, especially regarding the energy, since you are keen to jump into conclusions here but I assume did not do a quick research on piezo buzzers?

An example SMD compact piezo buzzer is 8.5 x 8.5 x 3.6 mm (https://www.cuidevices.com/product/resource/cmi-8536-82-smt-tr.pdf)

For the context:

1. a typical CR2032 Panasonic battery is 225mAh at 3V
2. The above compact piezo buzzer yields about 84dB at 3V, consuming 28mA. At this rate, it would discharge the battery in 8 hours of continuous buzzing at 84dB.

Assuming that in this specific case the piezo would buzz for, say 100ms every 10s, for a total of 600ms every 60s, it would take 800 hours, or 33 days of intermittent beeping before the battery discharged.

Let's assume that in the proposed holiday mode a plant would beep on average for 2 days before plant sitter attended it. For two holidays a year, 4 days in total, that reduces the battery life by 12%. And I think this is a fairly pessimistic scenario, plus this is the always-on Holiday Mode scenario, as opposed to the one that could be enabled on-demand by the sitter themselves, in which case the energy loss is completely negligible.

84dB is more than the alarm clock level (~80dB) of noise, BTW., which is obviously an overkill here.

[drspangle]

You haven't considered the additional current draw from waking up the MCU to activate the buzzer. It might seem inconsequential, but this is a sensor designed to last for a year, not for a month. A 12% drop in battery life for 4 days worth of beeping at the proposed, that's really a big drop. Maybe there is a way to activate the buzzer without significantly increasing the power draw from the MCU, I don't know, but I doubt it. You could decrease the duty cycle, but that's going to make it impossible for someone to hear unless you lurk next to the plant for a few cycles. Is that really practical?

The answer is no -- you didn't look at the performance curve graph carefully enough. Decibels are proportional to distance of measurement. The proposed buzzer is 84dB at 10cm. At 1m it will be "fairly quiet" at 64dB, equivalent to background noise in an office, so maybe you can hear it, but it will be difficult. At 2m it will be bordering on barely audible to most humans. How close do you reasonably expect people to get? Wouldn't it be much easier to match a photograph? Most people can distinguish between a small houseplant sized object at 10m or more.

Bigger buzzer? Bigger current draw, bigger footprint. Still can't escape the inverse square law.

[wrobelda]

A 12% drop in battery life for 4 days worth of beeping at the proposed, that's really a big drop.

And yet you conveniently ignore the point I made in the sentence that followed.

At 1m it will be "fairly quiet" at 64dB, equivalent to background noise in an office, so maybe you can hear it, but it will be difficult.

The normal decibel level of human voice is 55-65 dB. If you're having difficulty hearing that from a distance of 1m in an otherwise empty, noiseless house, then you have a different kind of trouble.

I am gonna spare myself the imperial to metric conversion jokes.

The SMD components in speech are used widely by the industry, including automotive, e.g to indicate failures or unfastened seatbelts.

I'm sorry, but I am not going to entertain your uncalled, speculative, pseudo-scientific, negging attitude.

That's an EOT for me.

[drspangle]

It's a shame you took my attempt at having a discussion so personally. I'm sorry if you thought that I was being overly negative. As I said a few times, I don't think your idea is a bad idea, just it's not a simple one.

Best of luck with your implementation attempt, I will be watching your progress with great interest. I hope that this thread at least helps you to proactively avoid some of the design problems you will face along the way.

[drspangle]

The normal decibel level of human voice is 55-65 dB. If you're having difficulty hearing that from a distance of 1m in an otherwise empty, noiseless house, then you have a different kind of trouble.

This is true only at a distance of 1m. Doubling the distance to 2m, 55dB drops to around 48dB. This is an equivalent drop in intensity as someone whispering versus someone speaking at a normal volume level at the same distance. If your ear is 1m away from the beeping plant you are close enough to see that it needs watered, let alone hear a buzzer. Yet, until you get that close it will be difficult to hear a 100ms high-pitched chirp unless you have very good ears. And of course, most people don't have ears at the same height as their plants, so you will need to be standing right on top of a potted plant to get within 2m (for an average height person with a plant on the ground). The sound will be mostly drowned out by a refrigerator humming (typically 40dB from the average distance within the same room). It will be completely drowned out by most home air conditioners running (typically 60dB from the average distance of most places inside a home on the same floor). I personally don't see that as useful, I live in a city and the ambient noise (I measure it at around 49dB in my quiet office) is enough to make this hard to hear unless I plan to have someone water my plants only in the dead of night. And I would still need to have them walk right up to each plant to be able to perceive the beeping well enough to localize which plant is beeping. Doesn't this defeat the purpose?

A phone notification has a configurable volume that can be set to any level and is far more easily perceived, and it can even be designed to repeatedly notify you without impacting the sensor in any way. The logic for the notification is not coupled to the sensor firmware, and requires no hardware modification, zero battery impact, and no change to the BOM.