That's my point. I don't know and it doesn't matter. I look at my plants, then the meter and back to the plants. If 900 is good for my conditions then i tune the light to get 900.
I can make that same argument and it's a valid argument as long as I limit the problem I'm trying to solve.
One of the downsides to that approach is that it's not information that can be used other than in the present circumstance. If you're using a meter that has a repeatable but known error, that's OK but how do you use those readings in another meter that has a different variance?
Your reading of 900µmol may not be 900µmol. It could be 740µmol or 1200µmol. In this case, if I have the same model of phone, there's a very high likelihood that I'll get the same result. On the other hand, if I don't have the same hardware, I may not get the same result. Or I might.
The response of "That's OK, it's for me and my grow" is completely defensible. It's not an argument that I would particularly make but, it is defensible.
Do you care to elaborate why photone is conceptually flawed? You repeated that multiple times now but offered no further explanation than 'trust me, I'm an engineer'.
I'm interested because I don't see much benefit over using a lux meter that takes a measurement at a single point in the spectrum and makes a lot of assumptions how the rest of the spectrum looks to calculate its reading.
What Photone is doing is conceptually the same as a lux meter + a conversion factor. The downside to writing software that uses hardware of unknown quality is that the software is dependent on the accuracy of the underlying sensor. Alternatively, the programmer can "write to the hardware" which can be advantageous but which can also be a very bad idea. In the case of a major phone manufacturer, there's stability and accuracy in the sensors that they're using, in theory. In reality, that's not the case. At times Photone has been shown to be accurate, at times it isn't.
The biggest issue, according to their programmer, was that in the Android world, "there are 20,000 devices" that he needed to deal with. I didn't ask for additional info and I didn't ask why he cared about the chip. The latter is important because of the dangers of "writing to the hardware". You just don't do that unless you are willing to accept the downsides. Instead of trying to get data from the hardware, programmers should be calling the operating system for the data. You write to the hardware when you need optimal performance and are willing to make the business tradeoff of getting an improvement in performance, by going around the operating system, but are also willing to accept the risk and cost of having to modify your hardware when your code blows up because the manufacturer changed something on the chip.
A key design factor with a PAR sensor is called the cosine angle. I have not looked behind that curtain much at all but it describes how a sensor is able to capture light coming in at other than a 90° angle. The diffuser is needed because the chip in a phone is not designed to pick up light coming in as far off axis as is the sensor on a PAR meter. That's another source of inaccuracy and, gen that it's required for iPhones but not required for Android, that indicates that it's not quite a slam dunk solution.
The need for the diffuser is called a "kludge" in the software business. Modern vernacular might be to cal it a "hack" but the modern usage of "hack" has positive connotations. It's not a selling point that you need a diffuser. It's a workaround that's needed so overcome a fundamental shortcoming. When they first released the product, then called "Korona" BTW, they didn't even specify what weight and brightness to use. Even now, the accuracy of the product is based on cutting a strip of paper and looping it around the phone. Put that in front of a team in a design review and there's going to be a lot of raised eyebrows. And we see the practical side of it - many people are unaware of it so they get readings that are even more incorrect.
I'm not particularly keen on waving my $1000 phone a grow tent. That's my personal choice about my very old phone but, again, in the bigger picture, I'd much rather have a $32 meter in a grow tent than a mobile phone.
The other side of the coin is to use the Uni-T, or something similar, and use a conversion factor. Can that combo be wrong? Absolutely. The grower might not use the right conversation factor but the Uni-T has it's own diffuser and, as I understand (yup, I haven't bought one yet - strike that, I just ordered one), it the meter has a decent pieces of software that lets you record samples. That's a handy feature - I turn on dictation on my iPhone and yell at the phone to record my PPFD.
Bottom line - your argument about constant error is completely valid. It makes transferability impossible but it does have a valid use case. Instead of spending $5 and putting a paper wrapper around a mobile phone, for $32 you can get a purpose built product that does not require the user to put a strip of paper around it and which provides an output which is transferable.
Over the past few months, I've seen more growers with problems in their grow who are using Photone. Some of the light levels are absurd - 1200µmol from a TS1000 or somesuch. The fact that the grower is using Photone makes it harder for the grower because, in their mind, they're getting all this great light on their plant when, in reality, it's completely divorced from reality. For a yutz like me who wants to help troubleshoot the grow, how do I tell that person that their light readings are completely off the wall? I promise you, it sucks. Understandably, the grower is skeptical because some rando is saying that the numbers are wrong when that can't be right because the website says…
In that situation, it ends up being, perhaps, a cause of the problem and can be an impediment to solving the problem.
No thanks.
