I can, haha! This will be fixed in the next version of the app.
Hello @evdpol
Would you be open to some QOL improvements I’ve thought of while using the app for a while?
-
Onboarding filter Right now every plant in the fyta account shows up, even those without a beam sensor. It could be more focused if only plants with data capability appeared—e.g. by filtering /user-plant for entries where sensor.has_sensor === true (or skipping ones tagged isNoBeam === true).
-
Beam-move recovery If a beam gets moved to a different plant, that homey device is now “dead”. No data will flow because the sensor moved to a different /user-plant/id endpoint. From the homey side, your only option is to delete the plant and pair the new plant location as a new device to “follow the sensor”. My suggestion is that instead of storing a plant id as the device, you instead store the sensor id, and simply follow it to its current plant association by simply querying /user-plant before fetching the data from /user-plant/{{plant_id}}. It is one more api call per polling period, but thats hardly any overhead at all.
a sample response to illustrate my meaning
{
"plants": [
{
"id": 85301, #plant id for the data endpoint that can be fetched prior to polling instead of being stored once during pairing process
"nickname": "thai",
"sensor": {
"id": "FA:11:23:6A:EC:0E", #id of actual hardware
"has_sensor": true, #filter property
...
},
...
]
}
The check on sensor.has_sensor === true wil be added in the next release, thanks!
I wil keep it how it is for now.
Storing all plants in the app, and lookup the sensor ID of the plant from the device is the correct option.
Still, the id of the device can’t be changed, so I have to store the sensor ID that on the device.
Maybe I will introduce a migration from plant ID to sensor ID in the future.
Thanks for the feedback!
thank you kindly for your consideration
Does communication between Beam and Homey still work if the internet fails?
No, it does not. It uses the FYTA API to get the data from their servers.
Thank you for the reply. Are there any plans to integrate the Mini 2.0 in the future? So that it can be connected directly to Homey via BLE?
hi, all my devices have come into state:
Device Unavailable
FYTA API has denied access to this device
But i am not sure how to re-initiated login process.. any idea what should i do? when i try to add new FYTA device there seems to appear login for a split of a second, but then the screen changes.. i have several flows that use data from fyta sensors and uninstalling and installing the app would require to remap all of these flow 
thanks in advance for any help…
You can try to repair the device which requires you to login again.
Hi,
I’d to move some Fyta sensor to new plants and now I won’t know, which sensor it is in Homey. Can you add information like sensor Mac-adress or serial number? So I could find matching pairs in Homey and in Fyta app.
In Fyta public api I found this:
"sensor": {
"id": "AA:AA:AA:2B:AF:F4",
"has_sensor": true,
"status": 1,
"uuid_android": null,
"uuid_ios": "AAAAA6BF-0457-3233-8A43-032B5377E763",
"version": "0.30.0",
"is_battery_low": false,
"received_data_at": "2023-01-01 10:10:00",
"created_at": "2022-01-01 01:10:10"
},
If you could map the “id” it would help. Using the Homey developer tools I can not find this attribute currently.
Greetings,
David
Yes, I will add a new setting which will display the sensor ID in the upcoming version.
A new test version is available: FYTA | Homey
Can you all try it out and see if everything works as expected?
Could you send a diagnostic report?
Yes, of cause. Here’s the diagnostic report id:
17134cf7-d4ce-41fd-97e9-21919fb6c31a
Ah, I see the problem… Thanks.
Can you try again with the latest test version?
Can you send me your login details via PM or email? I’m not sure why sensor.id is empty at this point.
Which 2 plants give this error?
