Getting it running on the Raspberry Pi via SPI

[pfink]

I'm trying to get this running on the Raspberry Pi using https://github.com/me-no-dev/RasPiArduino and did make some progress within the last days. Thanks to @criztovyl for the awesome help on this.

Scope of this project: Getting a "light" version of esp8266_milight_hub (settings.json, Radio, UdpV6) working on the RaspberryPi with a NRF24L01+via SPI. Setting up a PR to this project integrating the necessary changes for RPI compatibility.

Latest Code Base: https://github.com/pfink/esp8266_milight_hub/tree/piworking (this one is really trashy, will do a new branch with proper commits soon)

Status:

• [x] All known compile issues and runtime issues for Settings, Radio & UDP solved (at least with workarounds)
• [x] Parsing settings with ArduinoJSON works fine
• [x] UdpV6 server and radio communication are working fine (tested with milight 3.0 iOS app).
• [x] Setup PRs for RaspiArduino: https://github.com/me-no-dev/RasPiArduino/pull/115, https://github.com/me-no-dev/RasPiArduino/pull/116, https://github.com/me-no-dev/RasPiArduino/pull/117
• [x] Docs: https://github.com/pfink/esp8266_milight_hub/blob/piworking/pidocs.md
• [ ] Upload binary somewhere
• [ ] Cleanup logging
• [ ] Use relative path for settings.json / let it be determined via environment variable
• [ ] RasPiArduino has to be integrated as a platformio framework. Already prepared branches: https://github.com/criztovyl/platform-linux_arm/tree/raspiarduino, https://github.com/pfink/RasPiArduino/tree/platformio
• [ ] Prepare a PR against ESPMilightHub (rebase piworking branch to a clean one)

[Clemens82]

Thanks for this great work! That's exactly what i was looking for. No need for an additional ESP if I have anyway a pi close that I can just wire up to control my milights. I succeeded getting the app running on my pi, however, have difficulties having them contacting my bulbs. I could not re-pair my already paired (to original milight hub) bulbs. Can I somehow use the "spy" feature with your code to sniff the device id of the original hub ? Is the web UI exposed somewhere? would it be possible to change the port?

Many thanks again for your great work!

[Clemens82]

I traced down the issue: My real bridge (V3) has the id "ABCF23A6BD1C" (corresponding to it's MAC - anonymized for this post) what is equal to 188906144709916 decimal. If I specify 188906144709916 as device_id in your settings.json, the simulated bridge will expose itself with id '00000000FFFF'. As device_id "333" is exposed as "00000000014D" (just to name another example from your defaults) I suppose that the decimal version of my hexadecimal device id is expected. Could this be modified, such that I can specify the full ID, meaning a decimal number of 188906144709916 and not only 3 digits?

[sidoh]

Hi,

I somehow missed this over the holidays. Nice work, @pfink!

@Clemens82, device IDs are only 2 bytes and are tied to the microcontroller. The best way to find the ID of your old hub, as you suggested, is to put espMH in listen mode and sniff a packet sent by the old hub.

[pfink]

Is the web UI exposed somewhere?

No, webUI is out of scope here and I guess it would be less effort completely rewriting it than porting it. I focussed on getting the stuff working that is really required to control the milight lamps. If you need WebUI, you could just install any application that integrates with the milight Udp server and provides WebUI (there should be plenty of solutions available). Pairing can also be easily done e.g. with the milight smartphone app.

[sidoh]

Makes sense that a rewrite would be easier given the context.

As a workaround, might be able to set some debug flags and see packets in serial?

@Clemens82, some bulbs will not pair with a new remote until unpaired with their current one. You could try unpairing and then re-pairing with an arbitrary device ID.

[dehart]

Hi @pfink

I am trying to get your raspberry pi port running on Raspberry OS 64-bit. (PI4)

The reason I am trying to do so is because I am using this with diyHue and a Philipsambilight TV and the ESP is to slow to process all the requests. See: https://github.com/diyhue/diyHue/issues/487

I installed the 64-bit driver using debian packages as shown here: https://github.com/nRF24/RF24/blob/2a8329ff3862713f0ca2bf00c384b2d73b38f562/docs/using_cmake.md

I wired the nRF24 to the PI's GPIO as shown here: https://github.com/nRF24/RF24/blob/2a8329ff3862713f0ca2bf00c384b2d73b38f562/docs/rpi_general.md

There is still on open issue on PlatformIO_linux_arm to support the PI4: https://github.com/platformio/platform-linux_arm/issues/14 Could it be I am out of luck here?

[pfink]

I also couldn't get the build process running on 64-bit. Finally, I ended up using the 32-bit builds on a 64-bit system which works fine. If you don't have a 32-bit system for building, I could provide my binaries.

[dehart]

Aha, I didn't know that would work. I probably have to install ia32-libs.

I found a binary in your manual: https://github.com/pfink/esp8266_milight_hub/blob/piworking/pidocs.md

Ill see if I can get it running. Thanks a lot!

EDIT: it's running! If anyone wonders how to run 32bit binairy on aarch64 raspberry pi:

sudo dpkg --add-architecture armhf
sudo apt update
sudo apt install libc6:armhf libstdc++6:armhf

Also needed the 32-bit librf24

wget https://github.com/nRF24/RF24/releases/download/v1.4.6/librf24-RPi_1.4.6-1_armhf.deb
sudo dpkg -i librf24-RPi_1.4.6-1_armhf.deb

[poudenes]

How far is this now? Are you able to use Milight Hub on a RPi?

[pfink]

How far is this now? Are you able to use Milight Hub on a RPi?

It's possible to use the UdpServer on RPi. That's enough to use the official Milight app and other Milight integrations. I use it in my production setup and it runs very stable. Other components (e.g. MQTT, web interface) are out of scope for me.

The build process only works on 32-bit, but the binary runs on 64-bit as well.

Unfortunately, I don't have much time to put further work into this project.