I made a new reactor sensor in OpenLuup and I used the restore option of Reactor. If I use the reactor restore option I can transfer all conditions, expressions and activities settings from the Vera reactor sensor to the new reactor sensor in Openluup. The devicenumbers in de openluup senser refer to the Vera devicenumbers. So de reactor sensor doesn’t work because the devicenumber is missing. I have to change this manually. Is it possibe to do this automatically? The Openluup device number is incraesed by 10000.
You’ll want to update your openLuup version of Reactor to the stable branch. You can do this by going to the Plugins item in the ALTUI menu, finding Reactor, typing “stable” in the update field, and hitting the update button. You can also install the “0.stable” version from the AltAppStore. This will fix an issue with unknown devices in Activities that makes remapping them easier (it won’t lose the action and parameters when you select a different device, as long as the new device supports the same action). As for automatic mapping, that’s not in the cards at the moment.
Thanks for your quick response. So I have to change it by hand
There is a unique identifier on every device that theoretically could be used as an alternative for identifying the correct device. Unfortunately, openLuup does not support it, and the bridge is one of the facilities where it could be most useful. But since openLuup doesn’t support it, Reactor doesn’t use it, so it’s moot anyway. I’m betting it will have no analogue in eZLO’s replacement firmware now under development, either.
Are you speaking of UUIDs?
Yeah the UDNs…
I was thinking of enabling this for device name strings… although it’s not guaranteed to be unique, it is much more intuitive.
Not quite sure I understand what you mean there… if you mean be able to use the device name in any Luup call as you can UDNs in Vera Luup, I don’t think that’s as useful as the UDNs because device names can be changed, and are really expected to change, where UDNs are stable (unless the user does something nefarious).
Separately. I had pondered doing some kind of “device tagging” in Reactor, where a device that is used in Reactor logic gets some kind of mark (perhaps similar to a UDN but assigned by Reactor) and used in that way. Reactor’s internal logic would then provide the functionality of resolving device number or device tag to a system device. So, this is conceivably something I could handle entirely in Reactor, and is no more work for me really than I would have to do to support UDNs… same same. The difference is in how much work it is for you, so yes, I am working again to preserve your sanity! 
The difference, clearly, is if you think it worthwhile to extend that benefit (UDNs) universally in openLuup to all other plugins and code/facilities. I have other thoughts about that, but they’re OT for these forums.
1 Like
Interesting… that’s exactly why I thought it was useful. The user chooses the device name, the user can get to reference it (in, say, scenes, etc.) Any non-uniqueness issue is entirely their fault.
I have recently switched to doing this for bridged devices – currently VeraBridge and the rapidly developing ZWay plugin, which is now looking really good (thanks due to @rafale77 and @DesT for testing and suggesting improvements.) For this, I’m simply adding a new attribute called host to the device which takes the value Vera or Z-Way, respectively. This seemed by far the easiest approach.
…and that is much appreciated.
This has been a very sane approach. Now you can have Reactor as host I suppose.