Hi Community, how far are we from creating a generic 433 Mhz app? I have seen that you can create and emulate a 433 Mhz signal in the developer area.
I have two 433 Mhz items (elctric sunshade and a beamer screen), which are not included as there is no app for this. Has anyone an idea how to build a generic 433 Mhz app to record and use this signals for generic 433 Mhz items?
For what I know it is not possible to create an app that learns and replays random RF signals like the way Athom implemented the learn an infrared signal.
The developer tools are there to facilitate the developers with analyzing signals. You can only try analyze the signal and build a specific app for your remote.
Please look at the topic Generic RF-remote for a workaround.
Thanks a lot for the answer Dijker, I hoped that someone is out there who has an idea to build a generic app for this case⌠e.g. to enter the code which is recorded via Homey in a field like you do it in other applications to create variables, countdown timer, etc. Then it would be possible for multiple people use this app for 433 Mhz itemsâŚ
Looking for ideas or help⌠if someone is out there to build me an app for my two items, you are welcome 
From what I know, itâs simply not possible to create an app that does what you want. Signal definitions for an app (timing data, mostly) need to be defined up-front (in app.json) and cannot be created dynamically.
Also, with RF, there is no such thing as a âcodeâ. An RF signal deals with timings and encodings, and only if those are known to Homey (the âdefined up-frontâ part) is it possible to decode the signal. The result of that decoding process will be a code that could be used in flows, but thatâs only the last part of the âRF chainâ.
The Sonoff RF Bridge (mentioned in the thread that @Dijker referred to) does the decoding part in hardware and passes the code to Homey (but that device is also limited in the amount of different timings and encodings that it can recognize, itâs not a generic RF receiver either).
Donât know if itâs useful in this conversation, but I once created a signal analyzer which tries to predict a âHomey readyâ Signal definition. This can be used to create a Homey driver. Due reasons explained above it cannot be transformed into a âgeneric remote appâ.
Itâs far from perfect, but the closest I could get in automating the processâŚ
Hello Hardie, I have used your signal analyzer and it worked some time ago. However now that I am ready to start creating my first app, I tried using the signal analyzer again but it doesnât seem to work anymore. Do you know if something might have broken it, and do you maybe have a detailed step by step description on how to get an app created out of the signal analyzer results?
A step by step description would be golden!
Thanks!
Well, there IS a RF433 radio : it should be able to pick up all the noise and give you av list over items and data. Is there any 433 API in Homey that can give this list?
There is no protocol on 433 as I know, so usually decoding is about mapping raw datastream to expected result. If I know what the thing sends, I should be able to get it.
It´s a bigger issue with sending, as that needs an initation and a type, but a lot of open source solutions have the codes for that.
I really do not see the problem of making a generic RF433 App given there are support for specific 433 App⌠There has to be a reference implementation of RF433 specific apps can build on.
yeah⌠that means decoding noise⌠that´s a good start : it gives us room for all the enviromental 433 options : weather and presence and so forth : so we need the API´s!!
It doesnât match the âHomey Philisophyâ to provide generic support for most devices. I think this is because Athom wants to offload responsibility for device support to app developers instead of themselves, and they accept that this will make the Homey UX less polished than other platforms when it comes to supporting newly released devices (or, alternatively, Athom were so confident that device manufacturers would provide device support for Homey that they thought there wouldnât be any issues in this respect).
It also doesnât fit to provide the tools for others to implement generic device support, because the onboarding will be less polished than what it currently is, and Athom is all about looks.
