First can I thank you for packaging this up so well.
I am encountering a problem though and I wonder if you could help please.
The background is that I run Homey and Hubitat in the same house. This is primarily for fail safe. Some of my lights are on Homeyâs zigbee and others are on Hubitat. Thus if one device fails we wonât be left totally in the dark.
I am using Lightwave multipress to control my lights. Multipress turns on a âvirtualâ lightwave switch. This is supposed to be recognised by both Homey and Lightwave and thus can trigger automations that toggle the required lights.
My problem is that the change of status in lightwave is only reflected in either Homey or Hubitat. It is worth saying that both Homey and Hubitat can correctly turn lightwave switches on and off.
So my problem is that I can only get either Homey or Hubitat to recognise that the virtual switch has been turned on in lightwave. Both Homey and Hubitat need Lightwaveâs refresh token however if I refresh for Homey then it breaks Hubitat so I restart Hubitat and it breaks Homey and so on.
Perhaps this is not something that lightwave api can support although I am doing something similar between Homey and Smartthings elsewhere.
Is your problem that the api session refresh, by either hubitat or homey, generates a new key which is then unknown by the other instance, causing the api call to fail?
You want to share the refreshed key / session information between systems?
Your problem is that the Lightwave api will only permit one session.
You also need to register events to enable webhooks which is how your home automation system stays in sync when, for example, you switch on a light at the physical switch.
It really depends on system / app capabilities.
You could use one system to refresh the session. The refresh key is shared with the second system so in the event the first system fails it takes over.
Your problem is going to be how to handle devices status changes. I'm assuming you'd want the systems to be active, standby, i.e. one active, one standby at all times? In which case the devices discovered by the standby system would need to be static until the system became active, then refresh status and register events when the standby system became active?
I'd need to know more about your setup. It would likely be possible to do some dev work to get the WogaLWRF app to be your standby system, assuming you know how the key could be shared from homey? I'd also need to understand how the discovered devices should behave when the system is standby.
No I need both systems to be active so that no changeover would be required. We would still have half the lights in each room available.
This works when it is Homey and Smartthings probably because the Smartthings lightwave app doesnât use the api??
My only other alternative is to bring Home Assistant into the mix as middleware but at the moment I am struggling with the maker API app which links Hubitat devices to Home Assistant in that I am not sure what to put in âURL to POSTâ.
Best possible solution would be to get lightwave to add functionality to run Alexa routines. Otherwise I could link via IFTTT I suppose.
If you have any better thoughts I would be very grateful.
I'm not completely convinced I understand what you're trying to do.
Is it only the virtual switch that is part of the Lightwave ecosystem? Are all your lights other brands and not Lightwave devices?
I've not played with the multiswitch so I don't know how my app sees it during discovery. I'm assuming it just adds it as a switch. What happens when you press the multiswitch in the hubitat app. From reading the Lightwave info it looks more like it should behave like a button. How are you turning it off again?
One thing I could do is build add an auto off preference to save you from scripting it if that's what you're doing.
If it's just the status change you need for triggers, it might be possible to register multiple webhook events with Lightwave so it sends the webhook out to both systems. We could test whether it's possible to register multiple webhook endpoints. That means you wouldn't actually need a live session, assuming it's only the multiswitch status you need and nothing else.
Iâm really grateful for your interest and patience with this.
So this is the use case.
When I multi-press a lightwave physical switch a lightwave automation turns on a lightwave virtual switch. Letâs call this Trigger_1.
On Hubitat a simple automation states that when Trigger_1 is turned on it will toggle 3 Innr lights. Letâs call them light_a, light_b and light_c. These lights are on hubitatâs zigbee network
On Homey a similar flow also states that when Trigger_1 is turned on it will toggle 3 more Innr lights. Letâs call them light_d, light_e and light_f. These lights are on homeyâs zigbee network
Both automations will then turn off Trigger_1 which since it is the same instance will turn it off on lightwave. It would also be possible to change the Homey and Hubitat automations to toggle on receiving change in status of Trigger_1.
So it is probably just the status change that I need for triggers. If it is possible to register multiple webhook events with Lightwave so it sends the webhook out to both systems that would be great. I would be very interested in helping test this but I only have limited knowledge about using webhooks so I would have to lean heavily on you.
No problem at all. Thanks for the explanation. It's difficult when trying to visualise someone else's implementation.
The virtual switch, is that discovered during install? I'm assuming that's receiving the webhook event.
It sounds plausible, anyway, for what you're trying to do. I can probably test whether multiple webhook endpoints can be registered fairly easily. I've a whole load of hidden test pages I can turn on. It would be quite straightforward to send up an event registration, then poll lightwave to see if it's added.
I may get a chance tomorrow. If that works then I'll let you know and we can go from there.
It looks like you can register multiple webhook endpoints in Lightwave.
I've been mucking about with menu pages today, trying to create something sensible. I'm just up to the point of adding a page to create the event. I'll need to create the ability to amend it as well. I'll be happy to share the code so you can test it before I release it.
If you do want to keep the ability to flip the switch logically in both apps and the status to be consistent across systems i.e. without pressing the physical button, one of the systems will need to not refresh the Lightwave session. You're going to need to do some dev work on the Homey side to process the webhook event at some point. It's probably better to start with a virtual switch that can receive external events. Otherwise I can write some functionality so WogaLWRF can receive a key and not refresh the session. WogaLWRF will need a key as I'm writing the functionality to register and manage multiple webhook endpoints.
I'm about ready to release a version that will enable you to add an external webhook endpoint. Before I do, can you message me the device details section, for your device, from the status menu from the homepage please?
I've limited the features available external endpoints to switch events for now. That section will tell me how Lightwave names the available features so I can make sure it adds the right one.
Yes, that's it. Just wanted to make sure the switch feature was being used.
I've just released v1.2.15. Available via HPM.
Features
Fixed a bug which was trying to add webhooks for local automations
I've added a whole section for viewing webhooks and the ability to add an external webhook endpoint
The app preferences page is now only available if a session is active. As there's so much interraction with the api, it may as well be limited to cut down errors.
OK I got a chance to do a remote install of the new version.
When I went for the install it still asks me to put in the API tokens. How do I address this. Do I have to get new tokens from Lightwave as I did before? If I do then that will break my Homey Lightwave integration as it did before.
I've written in the option of being able to add additional webhook endpoints. What that will allow you to do is to create a device, in homey, that can be triggered by a webhook that you register via WogaLWRf. You would only be able to keep the lightwave session live in WogaLWRF.
That does allow you to run automations in both systems based on a lightwave event.
OK. I'm really grateful for all the work you've put in to this but it doesn't seem to give me the solution I need.
As I said the whole reason for my splitting the lights across two zigbee controllers is so that should one fail the other will keep working so there is unlikely to be a complete failure.
In your solution we are fully dependent on Hubitat in which case I might as well just attach all lights to the Hubitat zigbee or, if preferred the Homey zigbee.
I think I've got to think another way. I do wonder why Homey and Smartthings seem to comfortably share the Lightwave data in another Lightwave instance I'm running in a friend's house. Perhaps it's because there's a special integration supported by Lightwave.
Perhaps I need to drop Hubitat in my house and go the same route. I've also found a Hubitat app called HubConnect which looks interesting. I've also just looked at Google Home routines again (after a long time) and it seems that they can use a Lightwave device as a trigger.
Food for thought!!
I expect smartthings uses some sort of enterprise oauth and they receive the webhooks, using internal ids to update devices. They keep their own session, presumably which is why you can keep yours active in Homey.
The way I've set it up here is that lightwave would send a webhook to the trigger switch in hubitat as well as a trigger switch in whatever system you point the additional webhook at.
The hubitat could be down and the webhook would still be sent to the second system as it comes directly from Lightwave.
That seemed to be a way to meet your use case
It was a worthwhile piece of dev anyway. Provides some additional functionality someone might find useful. I don't often pass up an excuse to have a go...
Thank you. I didnât realise that. This would meet my requirements then.
I need to just check that Hubitat lightwave integration is able to trigger automations based on other criteria than simple off or on. That was the use case for my lights using a virtual lightwave device. For example I do already have other automations in Homey that trigger when power usage of a physical lightwave socket rises above a given criteria.
You will need to bear with me for that because that will take a while.
If i can help, let me know. I only created a couple of device types so if any of your devices used the default driver you may find the states don't exist. It's fairly straightforward to create a device driver for a new type, if needed. I'm going to add one for the type you sent me yesterday.
