I jut let mine reset on a reboot. It is a good question, though. I would also like my trends to not reset - if that is even possible (the dashboard nodes aren't exactly flexible).
That has been on my to-do list to look into, just hasn't made it to the top yet.
Don't know, I need to find the time to try one of the google results...
Maybe this? Looks promising.
Now I've really done it... 
Removed HubConnect, SL/ML and most of the RM rules and other apps from ALL of my hubs. Running entirely in NR. 
I am still using groups for collections of zigbee bulbs etc, motion zones for sensor aggregation and some virtual switches to record things like hub restarts, act as "storage variables" etc. Also am keeping lock manager for now.
I did make hub backups this morning before the great purge and just now in NR so hopefully there is a way back if needed.
We will see how this goes over the next few days.. am pretty optimistic based on my recent experiences.. 
WOW!! I am impressed!!! I would like to stop using HubConnect but I have some remotes that only work on ST thru HubConnect but they don't work using the SmartThings Nodes in NR. I also have Echo Speaks and Ecobee Thermostat on my ST hub but I could easily move those 2 to HE if I was going to shut down my ST hub.
My philosophy is to use HE for the device management and NR for the rules. My "control" hub still connects to Amazon Echo and I use virtual switches for the doorbell (going to my old Aeon Alarm) and a few other things. In your case I would probably connect the ST devices thru HE to NR and use them there - if they can work in RM then they can work in NR. So far everything - button presses for lights, motion sensor triggering - everything seems a bit snappier and more importantly more reliable but it's still too early to tell. I really like being able to control the environment - add resources as needed / troubleshoot stuff directly not to mention how easy it is to maintain/create/visualize things. Will let you know how it goes!!!
edit: I should mention that I think HE plays a very crucial roll in this experience. The robust and local way it handles devices and other things is super important to my setup.
There is always another way, how about
I am trying that palette. The button presses on these cheap remotes don't show up. I have no idea why. It is supposed to work thru a local webhook and I can get the Ecobee sensors & Thermostat thru that palette but not these dang remotes. It would be awesome if they would work thru NR because it's local and would be fast. When going from ST via HubConnect to HE, the delay is 1/2 to 2 seconds. The remotes are in unimportant locations for that reason so it's not a huge deal.
They are the remotes described in this thread:
I'll give it a try tomorrow!
Do you know what the event is that is generated on the ST side. It is probably just a minor modification of the SmartApp
I wouldn't even know where to start trying to fix it but.
ST Log when button is pushed:
ST Log for the Node Red Webhook
that actually all looks good. Any log output on the NR end?
Can you remind how to do that? I did it a couple of days ago for something else and can't remember what i used in Terminal.
EDIT: Found it. node-red-log. The button presses don't show up in that log. If I enter http://192.168.68.139:1880/smartthings/webhook in a browser, the result is "SmartThings NodeRed is Installed."
Does anything work via the plugin? Here is why, the log output on SmartThings logs the IP and port as Hex string in the log file. The port is show as "0050" in that log output. However, you show 192.168.68.139:1880 as you IP/port for NR so I would expect a log output of "0758". Are you sure you entered the right information in the SmartApp on SmartThings?
In the smartapp, make sure that the URL has the port included....
THAT WAS IT!!! I needed to have port # in the ST SmartApp. Thank you thank you!!!!
The instructions on the website don't show the port incl:
Agree, the instructions could be a bit clearer here
Now that I think about it, I never waited for a sensor to start generating temps for the Ecobee sensors, I was using an inject node to get that info while I was experimenting. Now that the port number is there, the sensors and thermostat should be sending info now on their own.
I am pretty sure the remotes are working quicker now. Thank you again.
Nice catch.
Can some one tell me what i'm doing wrong with this flow as I have big timer setup to come on at sunset and off at sunrise but it turning on one or the other light but not both and it not updated the switch off or on till I re deploy the nodes? I can also click on or off with the inject and the lights either come on or off but doesn't change the device node to off or on it stay on whatever it was until I re deploy the nodes? Thanks
You need a switch node between bigtimer and the command nodes so the on/off commands are routed correctly. Something like this:
The way I did this was to define "on" and "off" in your BigTimer settings. The "On Msg" and "Off Msg" bit (it says MQTT in the defaults which is confusing). Then use a change node and set "msg.command" = "message.payload"...
Not sure if anyone i running node-red in docker on unraid, but i'm having an issue with file path in the alexa2 palette.
I have asked on the unraid forums, but thought i would check here also!
I can log into the alexa service, which indicates a cookie has been generated, but it doesn't save - i assume because of the file path error
I know it has logged in with amazon, as i see a new device in my amazon account
EDIT: actually, for memory @JasonJoel is runing unraid?? Do you use the node-red-contrib-alexa-remote2 palette???
Download the Hubitat app
