I need to connect a number of Bluetooth radiator valves to my home network. I have not been able to find a cost effective LAN to Bluetooth bridge, so I think I will have to create this for myself. This could be done either via WiFi or via wired ethernet. Is ESP32 a good way to do this? Is there code that I can get that already does this job, or do I need to develop it myself? What version of the hardware would be most appropriate for this? I guess they will need to be mains powered (e.g. via a USB power supply).
Thanks for any suggestions on the best/quickest way to get this done.
Rowan
Ethernet to Bluetooth Bridge
-
- Posts: 6
- Joined: Tue Jan 01, 2019 3:31 pm
Re: Ethernet to Bluetooth Bridge
It looks as if the ESP32-BLE2MQTT project on Github does more or less exactly what I need. I am currently trying to build and install this on a LILYGO® TTGO T-Internet-POE ESP32-WROOM LAN8720A board. Once this is working, I should be able to control my Bluetooth radiator valves (several different makes) using MQTT commands. I will let you know how this goes...
Rowan
Rowan
Re: Ethernet to Bluetooth Bridge
@rowan.bradley
Any news in this case?
I´ve seen also the LILYGO® TTGO T-Internet-POE ESP32-WROOM LAN8720A board and have the same approch with BLE-MQTT 2 RJ45 gateway. I´m not sure if it works as expected.
Any news in this case?
I´ve seen also the LILYGO® TTGO T-Internet-POE ESP32-WROOM LAN8720A board and have the same approch with BLE-MQTT 2 RJ45 gateway. I´m not sure if it works as expected.
Re: Ethernet to Bluetooth Bridge
As far as I can see you would also need an MQTT server.
This would mean having to; (1) Open your network to the cloud and using a cloud server, (2) Install a home server & (say) run mosquitto MQTT server, (3) roll your own ESP MQTT server.
I have done (3), its some coding work but the ESP can do it.
If you go MQTT then you always need the cloud or an internal server, that's effort & downtime risk.
Exposing the valves using HTTP would seem much simplier than MQTT as the ESP can be the HTTP server and so any device could access (locally) without the cloud running. ATM if you go (1) and your ISP fails then local control/readings are impossible.
If you want remote access then it might be best to post to the cloud (which could also be an HTTP POST) but with an external interface security becomes a thing.
This would mean having to; (1) Open your network to the cloud and using a cloud server, (2) Install a home server & (say) run mosquitto MQTT server, (3) roll your own ESP MQTT server.
I have done (3), its some coding work but the ESP can do it.
If you go MQTT then you always need the cloud or an internal server, that's effort & downtime risk.
Exposing the valves using HTTP would seem much simplier than MQTT as the ESP can be the HTTP server and so any device could access (locally) without the cloud running. ATM if you go (1) and your ISP fails then local control/readings are impossible.
If you want remote access then it might be best to post to the cloud (which could also be an HTTP POST) but with an external interface security becomes a thing.
& I also believe that IDF CAN should be fixed.
Who is online
Users browsing this forum: No registered users and 144 guests