Automating the pain

Continuing the discussion from Your best pain cave upgrade:

I actually love this stuff… this has spurred a whole new topic but it was this novel kind of thing I was looking for in the original thread!

I use a Win10 laptop which is paired with the TICKR (as some had said, only 1 BLE connection with these) so I was thinking of creating an Windows Universal App that would read the HR/Power and inject it into smartthings, which could then do the logic part if it was coupled with a temperature sensor and a sonoff wifi switch (they do a wifi ceiling fan switch which also has variable speed settings).

Ive actually ordered the sonoff fan, zigbee and temp/humidity switches/sensors today… so will keep you all posted.

1 Like

I forgot to add, here is the win10 app that gave me the idea:

Sonoff also sell a “4ch Pro” that I used to have connected to my two fans. As the name suggests it has 4 outputs. That is probably the easiest way to get 4 variable amounts of wind. The variable speed fans I’ve seen generally look a bit weedy. If you see an infrared or radio frequency one that could be easily integrated into Home Assistant too as there’s already a ‘Broadlink’ integration and they build RF/IR hubs. I have the old version and it has a LAN mode and appears in scenes. I think that’d be the easiest way to get variable air speeds. Doesn’t fit in the standard waterproof box though. I have mine screwed in under my Soundbar in a wooden box I made.

That’s another interesting take, I have a 3 speed fan, but it’s 300W and on max it moves a lot of air. I decided on the fan controller as I wanted to avoid dismantling the fan, and I usually have it on the lowest setting in the winter and even then I find it’s a little too much, so this will give me variation within each of the 3 settings as I can set the fan to 1/3 and then reduce it further with the sonoff if needs be.

For me the main challenge will be getting the HRM/Power and and other data into smartthings. I would like to make this and standardised as possible so others can use it, any ideas on methods would be much appreciated.

What are you using as a fan controller? I’ve got this fan and would love to be able to have some variable speed control. Usually it’s just “I’m too cold on the warmup” which I feel like isn’t really a good enough reason to spend $$$ on a Headwind.

At the moment, just an RF 13A socket with remote on the desk, it’s fine, but binary. once I have the sonoff kit I will try and integrate it with Windows so I can intercept HR and power and ambient temp, and use them as a trigger, the sonoff fan switch has variable power settings

1 Like

What would be awesome is if the Sufferfest app had an API for pulling this stuff in real time… that would save a lot of work.

1 Like

Home Assistant is free and connects to Samsung Smartthings, Sonoff, Tuya and Broadlink (who make IR and RF devices that can control fans). I think it makes sense to use that rather than reinvent the wheel. I run it on a Rasperry Pi but you can just run it in a virtual machine on any computer and most people have a computer somewhere. There’s already a Zwift integration available for it because they have an open interface.

The problem is connecting a sensor to it. Raspberry PI and computers have built in Bluetooth but if that isn’t possible a cheap Arduino with a simple Bluetooth can probably connect. I don’t know the protocol though. An alternative is a second ANT+ stick and there are Linux drivers for it already so it could potentially be connected to Home Assistant. There’s a gap between driver and Home Assistant though. I don’t know which route would be easier.

I agree if you are a Zwift user, but I don’t use Zwift. I’ve used HA and it is a nice and relatively easy solution but you need to host a VM or run it on a Pi, I have the ST Hub which is there already 24/7. For me I think golden cheetah > ST may be the answer, until SUF open their API or I work out how to build a Windows app that will read the BLE inputs

I had a look at the Golden Cheetah code. Couldn’t see a public interface. Only a brief look though. I think you’d possibly need to create one.

My pain cave is low tech.The cooling comes from opening the garage door, and the heating comes from adding a sweatshirt.A towel protects the bike from sweat, but I do not mind it dripping on to the floor. I feel a bit like a wild animal marking out its territory with drips of holy water


There is an httpserver folder in the github repo, was hoping this would expose the data to external clients… not had time to look into it properly yet

I missed that. Had some days off prior to a 4DP test so had insomnia. Which file did you see the server in?

Doh. It’s bloody obvious now.

I used as inspiration and built a HR controlled fan using a Nordic nrf52-dk and a light dimmer from Robodyn.

He has open sourced the solution now for those interested. His example used ANT+ with the same board and light dimmer I used, but I implemented it BLE because it was easier for me to understand and use code examples from the Zephyr project.

Now as my HR changes up or down my fan speed does the same. It was a bit of fun as a lockdown project!


The way I do my “SUF+” stuff is:

  • second ANT+ dongle to pick up the sensor metrics
  • simple node.js app running locally to decode the ANT+ data and rebroadcast the metrics to a socket
  • regular web app to receive the socket data and do all the numerical and graphic goodiness that I seemingly like to do

All totally asynchronous to the SUF app but it’s worked out pretty well. This is on Windows.

Can’t say I’ve ever thought about automating my play cave though. Already have a remote control fan, with an actual remote, and no amount of funky lighting will affect the SUF mines or very dark places :wink:

1 Like

JamesT - Please share!!

Not a lot to share. The node.js code is just a few lines. The other stuff, well that’s mine :wink:

The ANT+ module I use is here GitHub - Loghorn/ant-plus: A node module for ANT+ (I may have hacked it a bit, can’t remember). The node.js code listens to the events from the “stick” and then broadcasts the data using Front end receives that, does funky stuff.

1 Like

Look like I’m swinging back to using ANT+ USB stick on a Raspberry Pi running Home assistant as the easiest route. Need to do some reading on how to write Home Assistant ‘integrations’

@Jim and @JamesT - great idea about moving the conversation elsewhere, thanks.

I’d expand on the reasons why I’m using Home Assistant and MQTT and recommend it to others, because I completely agree - there’s no reason to reinvent the wheel.

Home Assistant.

This has grown over the years to one of the most interesting open source projects on Github. It has a great active community and a lot of developers around constantly making it better.
Apart from the home automation stuff (for which I personally think it’s currently THE best out there), I think it’s also a brilliant solution as a simple central data collector/automator for all things IoT. It runs on anything, either standalone cheap rPi3, Odroid, miniPC or you can set it up as a Docker container on your home server, or even on the same PC/Mac you run your Sufferfest on if you really want.

The reason why I like it so much is because once you set up the data inputs from your sensors, it just sits in the background, constantly ingesting and storing the data to its internal SQL database (and time-based db like InfluxDB if you want) and then you can decide what and when you want to do with it. You can analyse it in realtime or later in InfluxDB or Grafana and build nice looking dashboards there, you can use it in realtime to automate other devices in and out of your home, you can convert, recalculate, combine, store and use it for anything else you want. It doesn’t matter how many sensors you have and where, it’s just perfect central scalable solution.

The beauty of it is that you don’t really need a dedicated bespoke integration for every device you use, as there are generic standards like JSON webhooks, Z-Wave, Zigbee, ESPHome and the one I really started to like - MQTT.


I wasn’t a big fan at first - what, yet another sensor data stream protocol? But I have to say, after the initial steep-ish learning curve and slightly complicated setup, I have to admit it’s just brilliant telemetry solution. It really is optimised for a lot of realtime sensor data flowing in and unreliable data limited communication networks and it is really scalable. Once you setup your broker (again - can be part of your Home Assistant server, home server, dedicated server, or as a Docker container elsewhere) and connect it to Home Assistant, all you need to do for all your sensors in future is:

  • Read the sensor value
  • Connect to a network
  • Publish a MQTT message (pretty simple, libraries available)

That makes it really easy to use on anything with USB/Bluetooth/WiFi/Ethernet like Arduino,, ESP8266/ESP32, Raspberry, etc. Without doing almost anything else, the broker then just resends every message to any subscribed client (like Home Assistant, or directly into database like InfluxDB, or for easy visual manipulation via Node-RED). You just create a Home Assistant sensor from every published MQTT topic you want to use and off you go, data starts flowing and you can start working with it right away. If you want to collect another metric, or you build new sensors or you change the communication standard (let’s say your pain cave is out of WiFi reach, so you use another way) - everything stays the same. You just create a topic from your sensor, connect and publish it to MQTT broker and everything else still works as before.

Another great thing is that it works both ways. You can create MQTT topics from Home Assistant events and your sensor/device can subscribe to those at the broker, so you can use it for 2way comms and remote control.

To summarise.
I used to try to build the whole infrastructure from scratch, but I now use these great tools to do the heavy lifting in the background for me, so I can concentrate on the input (reading sensors) and output (dashboards, storage, analysis, automation).