First and foremost thanks to the coders for your work! I envy your capabilities!
Am not sure if this post is the appropriate thread, as I need some help with the Shelly i3.
I'm trying to use @tomw 's driver for the i3, however I'm running into some issues. The parent device is being created, along with 4 child devices, a common and three shellyButtonChilds. I can't seem to be able to get Hubitat to communicate with the i3. Any advice?
I'm planning a whole apartment build from scratch with 20shelly 4pm pro for light control and about 15shelly i3 for switching.
I cannot seem to get any interactions in either direction, that is, whenever I try to click either of the 'hold, on, off, push, etc..' buttons on the hubitat interface nothing changes on the i3's own web-interface and whenever I press a physical momentary switch connected to the i3 I'm not getting any feedback on Hubitat either.
I am able to toggle the shelly 4pm on and off, if I feed it's IP address into the button url in the i3's web-interface and press the physical switch. I can also manipulate the shelly 4pm in it's hubitat device page, so I don't think it is a network issue.
I'm still very new to hubitat, so I'm assuming it is human error on my side with respect to using your drivers.
The Hubitat interface doesn't send anything towards the Shelly, so no issues with that not seeming to do anything.
But the physical interactions on the Shelly side should be mirrored into Hubitat. Maybe something failed in configuration or was broken by some code changes I made recently.
Can you show screenshots of the Shelly web interface configuration with some of the action URLs exposed? And will you please turn on debug logging on the Shelly i3 virtual device on the Hubitat side and send logs of a Configure and the time period when you press the momentary switch on the Shelly side?
Hubitat Logs: Device 149 & 151 are the Parent/Child Logs. Am noticing there is quite a lot of lag before they get updated, between the actual button press and event coming up.
There was a critical bug in the i3 driver which was resulting in the "Cannot get property 'mac'" error. Please do a Repair in HPM to get the fix for that.
Before you actually Configure again, I should note that I use the action URLs in my implementation, and the way I have it written now will overwrite any existing settings there. So, it'll blap over your 4pm relay URL. I can take a look at doing an append instead of replace (since they support multiple values), but I'd recommend only testing one i3 at a time until we find a good solution for that so that you don't have to re-do your settings for the 4pm.
Dev 151
I'm stumped on this error. Was this from manually executing the push() command on the child device page? If so, what value did you use for button number?
With testing help from @iNegibb , I think we got it all sorted out.
Version 0.0.25 contains the i3 fix as well as the improvement to retain any existing action URLs.
Having a Shelly device signal events to both Hubitat and another Shelly device directly is a cool use-case that I hadn't thought of, but that is now possible with this driver.
a quick question from my side. I'm playing around with my coffee machine. Right now, If managed to get the shelly uni onto the coffee machine and turn it on, which was pretty easy. The old switch stayed in place, so I can turn it on and off using the shelly or the original button. The only problem I have right now, is when I use the button, the is no updated status in the app or my HE. To get this going, I was thinking about connecting the button onto the shelly. When I got it right, I can use position 7 & 8 to switch the potential free relays (see picture). So connecting everything this way should give me the status update. So far right? Two more things which are bothering me right now are:
Will this work offline? For example, when I move houses, will the coffee machine work, even if I haven't hooked everything to my network.
The coffee machine has an auto off function. Will I get the status update or will the UNI always display "on". I know, there is auto-off for all the shelly devices, but I want to preserve the offline functionality, because for me a good smart device is adding options and not replacing them.
That all sounds right to me. Some of the functionality in your two points (offline functionality and auto-off status being reflected) will depend on the specific behavior and electronics of the coffee machine. So, my advice would be to just try it out.
Sure...I added a command (setRefreshInterval) to do that. Just repair your installation in HPM to pick it up, since I didn't bump the version just for this change.
@tomw, I know that some of the over/under voltage like the URL is functionnal, would you mind adding the buttons to set under and over voltage alerts from the device page, having the possibility to also use cloud URLs would also be great since i'm using the Shelly UNI on a boat.
One other question, I did some tests and do see in the logs when the Shelly UNI calls back and all, but what do we do with it, looked in RM and did not see anything anywhere that I could use as a trigger?
My driver does support setting the ADC over and under URLs to callback to, but you still have to set the actual numerical limits on the Shelly configuration page (directly from the Shelly itself).
I can't use cloud URLs unfortunately, because only an app can receive cloud callbacks directly and this is a drivers-centric integration. Can you tell me more about your setup? It sounds like the Uni is remote from the network that your Hubitat is on, but the Uni is still connected to the internet from your boat? What is it that you're wanting to do from Hubitat if it's not to control something else on the boat?
I could add an attribute to the ADC child device that would change value to "over" or "under" when the relevant event was tripped. Any suggestions on a name for the attribute?
No problem, thanks for the fast reply, I have a router on my boat that has an LTE connection on it, but come to think of it, I could just do a cloud end point and enter that URL in the local app of the UNI and that would also work through RM. So completing this would not really help without being able to use cloud.
Anyway, for the winter that is coming, I will deactivate the cell connection and rely only on WIFI to monitor the batteries, But then I can still use that same cloud connection or even just add a local end point in RM also.
So maybe just have the option to set or not set the call back URL could be a better feature for me right now.
I could do an enable/disable on action URLs pretty easily. I didn't really want to do an overwrite or remove option, though, just in case the user had set an additional action URL outside of what I was setting up, since I didn't want to have the effect of clearing that out when a user configuration changed on my integration for HE.
Would an enable/disable for the action URL by type (e.g. adc_over_url) work for you, or are you saying you'd like to disable the specific callback URL associated with my Hubitat integration but leave another callback URL active for the same event (for cloud or similar)?
Is there any harm in having the one my integration sets to callback to itself active all the time, even if you aren't explicitly using it? Right now, it has the side benefit of refreshing all of the attributes, so there is a lesser need to frequently poll for updates.
