@Royski That's another interesting approach I'd like to try.
I'm doing a version where my first hub has nothing but Zwave devices and Zigbee repeaters friendly with Xiaomi devices. I use RM on that hub and no WC. That hub has zigbee on Channel 23. My wifi is on channel 7.
My second hub is the newest M5 hub and it only has those Iris 3210-L smart plugs for zigbee repeaters and a few zwave devices. This hub has zigbee on channel 26.
I've found it interesting how both hubs and their respective connected devices are working perfect when both are running zigbee on those upper zigbee channels. This testing has demonstrated how all of my previous zigbee mesh issues with both Wink and STs, was caused by smart bulbs that were poor repeaters and had nothing to do with the hub's zigbee radio channel.
I do appreciate @nh.schottfam willingness to keep tinkering with Adrian's original WC code for use with Hubitat. Having choice when it comes to apps and functionality on any platform is a win for all involved.
Find two hubs so much smoother. There maybe times when something may run a little slow, that normally my Hue lights. But I like the way it does seem to recover itself and speed back up.
The WC updates came at the same time my second hub arrived, so I thought why not.... I’ve not looked back really, that was running hub link at the time, then HubConnect was released and I did it all over again lol
That's only for editing. Your pistons actually "live" on your hub. The only reason to run locally is in case WebCoRE ever shuts down or if there are changes needed exclusively for hubitat.
@Royski - that’s only for the local run of dashboard isn’t it? I’ve been looking to see if I can get it installed on my laptop that is running 24/7 (which currently has Plex Media Server, Sonarr, Radarr etc installed, HomeBridge and numerous other software installed on Win 10) but it has the oomph behind it being an I7 professor with 8gb ram. So far I’ve only seen instructions for Pi or Docker for WC. Lol I installed Docker but that wiped out HomeBridge connectivity with HE
I'm happy to look at your issue / logs. I have sent a private message.
Nothing should be lost, so if we have a look in private messages, we should be able to resolve the issue.
Apologies for the trouble.
Do be sure you are running latest code, and for pistons subscribed to ifttt events, they need to be paused/resumed so that the subscriptions are updated. Also ensure when updating that webcore-piston.groovy is updated, first, then webcore.groovy.
I sent you a message asking you all that before I updated asking you that specifically and you specifically said that all I had to do was update.
So, either you just don't like being clear or you intentionally didn't tell me that before I updated. Which?
But now that you've broken my system, what would i have to do to fix it? I don't know what order i updated the files because you didn't tell me that when i asked the first time.
Well, i updated like you told me, paused and resumed the pistons like you told me and it still doesn't work,
║An error has occurred while subscribing: java.lang.NullPointerException: Cannot get property 'r' on null object
It is stating that it is receiving the event, and it is recognized in the piston but nothing happens.
4/6/2019, 12:16:52 PM +155ms
+5ms ╔Received event [Home].ifttt.google_calendar = google_calendar with a delay of 87ms, canQueue: true, calledMyself: false
+116ms ║RunTime LockT > 129ms > rtDataT > 3ms > pistonT > 24ms > CE
+131ms ║Runtime (24972 bytes) successfully initialized in 27ms (v0.3.10a.20190223)
+155ms ║╔Execution stage started
+159ms ║║Comparison (string) :: is_any_of (string) ::,:: = true (1ms)
+161ms ║║Condition #87 evaluated true (4ms)
+163ms ║║Condition group #null evaluated true (state did not change) (5ms)
+166ms ║║Comparison (string) null executes (string) calendar = false (0ms)
+168ms ║║Condition #22 evaluated false (3ms)
+169ms ║║Condition group #52 evaluated false (state did not change) (4ms)
+172ms ║║Comparison (datetime) 1554567412326 happens_daily_at (datetime) 1554490500000 = false (0ms)
+174ms ║║Condition #155 evaluated false (3ms)
+175ms ║║Cancelling statement #155's schedules...
+179ms ║║Condition group #152 evaluated false (state did not change) (7ms)
+182ms ║║Comparison (string) null executes (string) google_calendar = false (1ms)
+239ms ║║Condition #191 evaluated false (58ms)
+240ms ║║Condition group #190 evaluated false (state did not change) (60ms)
+243ms ║╚Execution stage complete. (88ms)
+285ms ╚Event processed successfully (284ms)
So, IFTTT triggers don't work. Period. It is receiving the event but not carrying it through for the comparison. You can see. null doesn't match "google_calendar" even though the event name was subscribed to at the top.
No, i don't think that is appropriate. Because what if someone else runs in to the same problem. I think it is appropriate to have this discussion right here. You posted this thing....no one held a gun to your head to make you do that. You chose to do that on your own. Now you have to stand by what you did.
your call. I don't suggest private messages to hide anything other than your data/privacy.
I don't think posting your state data in public is the best course of action.
I would like to see the state data for the piston please. and the piston/ifttt details.
The good things I see is the event is being received, and now we need to understand why the data is null. I know folks have had issues with google recently as they have locked down their data access to various services. Perhaps this is why you are not getting valid results from Google.
That is just the event name. The link is a hubitat link that I am launching from my browser. I also have the same thing happening with the event "vacation". Are you going to say that it isn't working because my hub is on vacation?
This one was even tried from a local link instead of the cloud link so you can't blame the Hubitat cloud either. My point is, this was working and your post here:
How did you get IFTTT events to work when there is clearly a problem. What data do you need now? The "state" data? And why do you need the IFTTT or Piston details? It isn't working!!!
@nh.schottfam On this question that @TranDzung posted, I've noticed anytime I do a clean new install of WC I see this behavior on the first piston I create. When nothing happens I'll go create the very same new piston\name a second time and get the same response.
Then when I return to the main dashboard I'll see both the first and second piston and they are both paused.
It might be good to run this issue down for future users. This issue has been around a long time. It may have existed since the first version that was forked from the original STs code base.
I have decided to run a few webCoRE pistons just to see how the hub responds.
Previously the simple pistons I ran would be slower than RM rules.
With the latest update they are running as fast as my RM rules.
For me, I didn't have any pistons running before today, the latest update is working very well.
Thanks @nh.schottfam for your efforts in keeping this available to us.
P.S. The only thing of note for me is the update sequence.
I have always assumed it goes from top/parent to bottom/child. This means I would update webCoRE.groovy before the webCore-piston.groovy.
Perhaps a note in the release notes would be good (in case I have missed it). Just a minor observation though.
