I have my webCore setup working well in Hubitat, a few items i need to deal with - but generally working. The Dashboard is currently still using the cloud dashboard (for the moment).
I am trying to build out a fuelstream, which the WC logs says is working and dutifully writing to the proper stream, but in the Dashboard there are no streams found in the IDE.
Are fuel streams not supported with HE?
@ipaterson Is there some sort of restriction that prevents writing to fuel streams if the requests don’t originate from smarthings’ servers? I’ve tried on and off to get this working for Hubitat’s version of webcore, but haven’t had any luck.
Sorry but I do not have any information about the fuel streams endpoint. I assume you are correct that it is protected to avoid becoming a generic storage solution. Since the fuel streams live on a different system that I cannot access I recommend contacting @ady624 with all information that would be required to allow access for Hubitat. YMMV, perhaps someone willing to bear the operating costs can reverse engineer the API for Hubitat users.
Thanks for the info, I did verify the restriction by writing to a fuel stream using another smartapp in smartthings and had the result come through. Since the requests would originate from where each Hubitat hub is located, I’m not sure it’s feasible to disable that from his side.
@ady624 would you object to hubitat users writing to a fuel stream using a proxy smartthings app?
**Now that I think about it, it wouldn’t be too hard to create another webcore child app in Hubitat strictly for fuel streams since there isn’t a 100K limit on state, and just route it to that instead. It would require users though to use a custom local dashboard. If possible I’d like to keep them on dashboard.webcore.co since it’s globally accessible and the ad revenue can go to you, but I’m not sure if the added server costs for fuel streams would outweigh that.
Absolutely, creating a child app for each Hubitat user seems like a good all-local solution. If that ends up being the preferred solution it would be great to receive a pull request for the frontend dashboard on GitHub to allow writing to the alternate URL either via an option or by detection of a hubitat install.
That sounds like a good plan. I’ll do some research into the fuel stream api and see about replicating it. I’ll probably move the fuel stream url from the app.js to the instance response from webcore.groovy and get a PR up to you when it’s ready.
Got it, thanks! I will review the pull request then add to the next release for testing. If there is any other Hubitat support that can be added via pull request this would be a great time to get that into webCoRE to reduce the chances of merge conflicts on the Hubitat fork(s).
I did see a discussion on merging the 2 so that it was one code with a check built in to decide if it was ST or HE. Did anything ever come of that?
I haven’t seen any code submitted to merge the two, but I believe there are some changes for Hubitat that make it impossible for the smart apps to support both platforms. The maintainer of the Hubitat fork uses a service that helps to automate synchronization with changes in the SmartThings version.
It would be great to get pull requests for any changes that can be written to support both platforms without extra overhead or excessively complicated code so that merge conflicts can be minimized. Currently if we were to do a sweeping change like normalizing all of the very inconsistent indentation throughout the codebase it would probably be very challenging to merge that into the Hubitat fork.
I’m working on a PR for that now. I have the code running on both systems with the only change needed being an import statement at the top of the piston source:
//import hubitat.device.HubAction
//import hubitat.device.Protocol
import physicalgraph.device.HubAction
import physicalgraph.device.Protocol
I’ll try and get that submitted to you once I get the fuel streams running.