furrtek / portapack-havoc

Custom firmware for the HackRF SDR + PortaPack H1 addon
GNU General Public License v2.0
791 stars 219 forks source link

Feature suggestion: adding 433MHz send/receive commands for devices #162

Open maulwurf98 opened 6 years ago

maulwurf98 commented 6 years ago

Hi, first of all: great software, thanks for all the work here furrtek! I am using the following software suite to control 433 MHz devices such as remote-controlled power plugs:

https://github.com/pilight/pilight

This software has a nice "receive" function, which will provide you with all 433 MHz devices in your environment on the commandline with the names. And then you also send commands with pilight to switch devices "on" or "off". As it is written in C it should be straight-forward to implement this in the havoc-suite. Currently, I am using it on a Raspi with the following cheap sender/receiver: https://www.amazon.de/gp/product/B00R2U8OEU/ref=oh_aui_detailpage_o02_s01?ie=UTF8&psc=1

It would be great to have both the receive and then then the send (for the fun ;-) option implemented. Any chance this is possible? I was really surprised how many devices in the neighborhood can be logged, so it would be a handy feature.

*Thanks.

maulwurf98 commented 6 years ago

Picking up this thread again as I still think this would be a killer feature. The tool and code supports various protocols:

https://manual.pilight.org/protocols/index.html

Example picture: https://www.dropbox.com/s/mavtqh5q4a0fa7g/Pilight-receive_Example_Output_Neighborhood.jpg?dl=0

And yet another idea: for 868MHz and ISM, fhem has all the protocols built in for translating signals from air into meaning...: http://fhem.de/#Protocols

ImDroided commented 6 years ago

This would be a awesome addition.

On Sat, Mar 24, 2018, 3:13 PM maulwurf98 notifications@github.com wrote:

Picking up this thread again as I still think this would be a killer feature. The tool and code supports various protocols:

https://manual.pilight.org/protocols/index.html

Example picture: https://www.dropbox.com/s/mavtqh5q4a0fa7g/Pilight-receive_Example_Output_Neighborhood.jpg?dl=0

And yet another idea: for 868MHz and ISM, fhem has all the protocols built in for translating signals from air into meaning...: http://fhem.de/#Protocols

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/furrtek/portapack-havoc/issues/162#issuecomment-375921580, or mute the thread https://github.com/notifications/unsubscribe-auth/ANVzacToCOa24acMMoOy-oMsL1E9xCl6ks5thqjYgaJpZM4SGet3 .

furrtek commented 6 years ago

How about having a scriptable remote control app ? Realizing how many appliances are using ISM radio remotes, maybe it's a waste of time to hard-code apps for each.

The idea would be to make an app which would be able to load a text file from the SD card, defining how to set up the "virtual remote" layout and frames for each button. That way there's no need to dive in the C++ code and rebuild the firmware each time someone suggests support for a new device ?

There would be a header specifying the frequency, modulation, frame format and number of buttons. Then a list of positions/sizes for each button and how they change the bits inside the frame.

ImDroided commented 6 years ago

Well if it helps I have a few fan remotes recorded. Here is the link to one of them

http://www.rfoverride.com/download/hampton-bay-ceiling-fan-remote-model-fan-hd/

That is a awesome idea. Better than the method I am using by recordings of the key press

On Mon, Mar 26, 2018, 11:26 PM Furrtek notifications@github.com wrote:

How about having a scriptable remote control app ? Realizing how many appliances are using ISM radio remotes, maybe it's a waste of time to hard-code apps for each.

The idea would be to make an app which would be able to load a text file from the SD card, defining how to set up the "virtual remote" layout and frames for each button. That way there's no need to dive in the C++ code and rebuild the firmware each time someone suggests support for a new device ?

There would be a header specifying the frequency, modulation, frame format and number of buttons. Then a list of positions/sizes for each button and how they change the bits inside the frame.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/furrtek/portapack-havoc/issues/162#issuecomment-376393130, or mute the thread https://github.com/notifications/unsubscribe-auth/ANVzafaC7aewdGwrgsUyrNnq0NGQ4Yzlks5tib9jgaJpZM4SGet3 .

maulwurf98 commented 6 years ago

I think the suggestion with the remote is a good one. Nevertheless, I keep mentioning plight as this nicely monitors your environment and translates all the signals back into the actual device names and their IDs. It would be great to implement this exact monitor on the PortaPack as you will then see immediately what 433 MHz devices are acting around you. Auto-generating then a remote for on-off commands of the identified devices is then straight-forward. Here, a simple list of the detected devices and an on-off switch to the right would be enough. I am attaching a log-file of some hours of monitoring using pilight-receive. This was generated with a Raspi and a very cheap 433 MHz receiver. Isn't it impressive what you already find in a small town? So the PortaPack would be more convenient for the field. Yes, ISM and 868 MHz is then another story (fhem auto-detect feature here).

Example_Log.txt

tibas21 commented 6 years ago

Great idea maulwurf, this could bep clearly an excellent addon for the portapack.

jLynx commented 4 years ago

+1 for this idea