Hi everyone,
First.. A special thank to Martijn Poppen!
Then to repeat what he said in his API Playground script that made this app possible.
Use at own risk!
I built Flow Converter to solve a common Homey headache: after replacing or re-pairing a device, Flows and Advanced Flows can still point to the old device ID and stop working. This app helps you remap old references to the new device safely, directly from the app settings page, so your automations are easier to recover without manual edits.
The app focuses on safe repair with preview before apply, supports broken references from deleted devices, and is made for Homey Pro users who want a quicker way to restore existing automations. If you test it, I would really appreciate feedback, edge cases, or sample scenarios that should be improved
As requested, i am putting up some donation details, thank you for any contribution!
BTC (Bitcoin network)
3KwL5DHBWUWmf9rLjo6hYR1WHMADMY2hum
EVM address (ETH / CRO / ERC20….)
0x48Dac30DE0409380005d90233711c8cD42eF3aF6
Paystring
l4m$paystring.crypto.com
Just submitted the app heres the link to the test version:
thank you! 
You are still my hero though!
Nice job, well done @late4marshmellow , it even scans for Timers deleted/invalidated devices, really nice !
vs 
And even broken Insights trends
vs
Btw, support for replacing sensor between apps, within flows… have you been thinking on that ? Not sure if it’s possible/API supported thought.
Eg. replace Button from IKEA with Button from SONOFF.
if i understand you correct, this can be achieved with the advanced targeting, capability targeting and both id in same flow turned on
Well, not really, or I might be not understanding usability of that option 
Imagine a device will die…you will replace it by another device from another manufacturer, which might have similar capabilities or ideally is same class, but naturally device ID and applications are different. It’s not happening often but when it happens, you basically have to fix everything manually. It’s just idea…
is this what you mean?
when both devices is actually theres?
the old device dont need to be dead.
I have a sample I am doing right now actually.
I have two active devices, and I am going to move all flow references from PIR to Radar sensor.
Because the PIR one lacking radar
Then I just run the old to new as usual.
This will also work if the old device is lets say Zigbee and the new is a Z-wave or wifi device
as long as they have the same capability
But heres some usecases..
if those two devices already have flowcards and happens to be in the same flow.
You can activate the Allow both old and new ids in same flow.
This allows all flowcards be converted to the new device.
I added this safeguard since this can make a headache if they have different purposes or to avoid a mistake (i learned this the hard way).
**
If the two devices is of different class**
Activate the allow class mismatch
this is useful if one device is thermostat and other is sensor, but they have same capabilities.
guard because i did once run a convert (learned from another mistake) on wrong device and i ended up with a lot of work do correct this mistake. since the “new device” didn’t have those capabilities.
Then there’s the Advanced targeting
Flows: Here you can do converts only in the defined flows you want
the flows that shows here is the flows of the old device.
and the capability targeting should allow to select what capability that exist on old and new device so you can convert say only temperature cards.
but with that said, it seems i discovered a bug 
Anyway all the switches works together to minimize the target a level a time if you want.
so what your are supposed to be able to do and will be when i fix that bug. ..
and here is what i think you mean.
lets say you have a dying thermostat device.
now you got a sensor that is going to replace the temperature sensor capability only, and only in flow 1 of the 3 flows the thermostat lives in.
- set the thermostat id as old > sensor ID as new
- activate allow class mismatch
- enable advanced targeting
- do a flow target and select flow 1
- do a capability target and select the temperature capability.
this way you will only change the cards with temperature in flow 1 from old thermostat device to new sensor device (different class, different manufacturer, maybe even different type (zigbee / wifi).
and after sending my long explanation and some after thought realized that i think i get you now
the button up for ikea and button up for SONOFF is not neccessary the same action?
one can say button_up_pressed and the other say button_1?
so a device action mapping of sort?
good idea and i will look into that!
Well, seems that the majority of cases you have indeed covered, I would need to test that out, if that will happen once… class mismatch, it could be but also simply app (ownerUri) mismatch, or what you actually have described :
…that could be also possible edge case, eg. capabilities remapping, I have experienced that case already as well.
But in general I originally really meant replacing one dead / missing device with another one from different app.
Device 1
"driverId": "homey:app:com.xiaomi-miio:mi-temperature-humidity-sensor",
"ownerUri": "homey:app:com.xiaomi-miio",
"capabilities": [
"measure_temperature",
"measure_humidity",
"measure_battery",
"alarm_battery"
Device 2
"driverId": "homey:app:com.xiaomi-mi:weather",
"ownerUri": "homey:app:com.xiaomi-mi",
"capabilities": [
"measure_battery",
"measure_temperature",
"measure_pressure",
"measure_humidity",
"alarm_battery"
Yeah that one should go through as is.
The only mismatch is pressure if you go from device 2 to 1 . And if you would like to move that variable to a device 3 it can be achieved with capability target
What a life saver!
You should put an paypal donation button up.
Cheers,
Ralf
@late4marshmellow i agree with @Ralf_Huelsmann
Add some donation links in the top post !
hey!
the capability targeting is fixed and available as test
, working on a mapping feat next
