Once we've transitioned from the "User" WC to the "Built-In" version, should we then perform an Uninstall in HPM? Asking because WebCoRE came up among the items to "Update" in HPM moments ago, and I instinctively checked its box, which generated the following error:
As usual, I don't want to assume I know what to do next, lest I bork something. But it feels as though I should be eliminating all reference to WC in HPM?
If you are only using a built-in install, you don't need the user install.
It should not hurt if you do not have an instance of webCoRE.
Would have to see your
HE console -> apps listing
and your
HE console -> apps code. listing
The only instance of WC I have running on my C-7 is the latest built-in version:
and safe to say no copy of WebCoRE appears in my Apps Code.
So if you don't have user installed, then you do need to unmatch it in HPM (or uninstall, then re-install HPM, then rematch)
@nh.schottfam
I 'm not sure when this stopped working but sendemail now fails to do anything.
I did an HPM repair and tried a test piston and no go. Works if I just send a real email.
I am on the latest version of HE and WC.
WC log
app:122023-03-06 10:47:08.316debugDashboard: Received test a piston
app:122023-03-06 10:47:06.589debugDashboard: Received clear piston logs
app:122023-03-06 10:46:59.821infoUpdated ran webCoRE v0.3.114.20220203 HE: v0.3.114.20230222_HE
Trace log
06/03/2023, 10:45:10 +178ms
+4ms ╔Received event [Home].wc_async_reply = sendEmail with a delay of 0ms, canQueue: true, calledMyself: false
+10ms ║Runtime (5265 bytes) initialized in 1ms (v0.3.114.20230222_HE)
+37ms ║╔Execution stage started
+57ms ║╚Execution stage complete. (21ms)
+64ms ╚Event processed successfully (60ms)
06/03/2023, 10:45:09 +476ms
+3ms ╔Received event [Home].test = 1678128309476 with a delay of 0ms, canQueue: true, calledMyself: false
+9ms ║Runtime (5192 bytes) initialized in 2ms (v0.3.114.20230222_HE)
+11ms ║╔Execution stage started
+20ms ║║Executed virtual command sendEmail (2ms)
+22ms ║║Requesting wake up at Mon, Mar 6 2023 @ 10:45:33 AM PST (in 23998ms) for 1 (st:2)
+26ms ║╚Execution stage complete. (16ms)
+99ms ║Setting up scheduled job for Mon, Mar 6 2023 @ 10:45:33 AM PST (in 23988ms)
+101ms ╚Event processed successfully (99ms)
I may need to see full logs for this.
My simple test of email worked, but I'm not using a variable for the email address.
I turned on WC Settings | Logging | Full but all I get is:
app:122023-03-06 13:00:29.389debugDashboard: Received test a piston
I don't recall other logging beside that one and the Piston level logging?
I tried my phone number instead of a var but no go. If I send a regular email it works so I kow it's not a provider change.
Ha, figured it out.
Sendemail doesn't like having a blank message. I was just using the Subject as the message.
I guess I have something in the message protion everywhere else.
Thanks for fiddling with me. 
with the send email, is there anyway to grab a file from the habitats file manager and send it in the email as an attachment?
I have cameras that will take a picture and store it to the hub file manager (Someone made this not me), I would like that if I am not home and there is motion inside my home that I get an email with a screen shot that was taken so I can view the image.
If this is not possible, can you look into adding this feature?
webCoRE does have a readFile command.
That said, I think to send as email you get into converting this to a MIME attachment, which is where things can get challenging. Likely we would need someone that understands this and likely they are going to ask for some additional webCoRE functions to help with the conversion....
So some collaboration would be needed....
Fair enough. Dont waste time on it then unless many ask for it. I am sure you have better things to work on then. Thanks anyways. 
I'm noticing that since 2.3.5 have some piston that fail to run. Reboot and recreate cache and it will work until the next reboot. I have noticed a few times. I have seen this with RM rules only so far and WebCoRE. This rule hasn't changed in years. It's one of my old reliable rules that never fails. This rule does control, and hub meshed device, but I don't have any issue manually controlling it. Very strange. I want to see if anyone else notices this.
Would be interesting to see more logs of the piston when it is having trouble
Low or medium logging on a piston may give insights.
@nh.schottfam Thank you for your response. I need to dig further.
I don't see the request sent to the device. However, the hubs were rebooted around midnight. However, the device on the c7 (hub mesh) shows offline. However, that was hours after the reboot.
3/9/2023, 7:48:16 AM +401ms
+4ms ╔Received event [Kate Sarcone].presence = not present with a delay of 56ms, canQueue: true, calledMyself: false
+8ms ║RunTime initialize > 7 LockT > 0ms > r9T > 3ms > pistonT > 0ms (first state access 0 m:4 4 3)
+11ms ║Runtime (8803 bytes) initialized in 3ms (v0.3.114.20230222_HE)
+34ms ║╔Execution stage started
+86ms ║║Comparison changes_to = false (event device/attr eXcluded)
+87ms ║║Comparison changes_to = false (event device/attr eXcluded)
+90ms ║║Comparison (enum) not present changes_to (string) present = false (1ms)
+91ms ║║Comparison changes_to = false (event device/attr eXcluded)
+98ms ║║Condition #2 evaluated false (32ms)
+112ms ║║Condition group #1 evaluated false (condition did not change) (39ms)
+148ms ║║Comparison changes_to = false (event device/attr eXcluded)
+156ms ║║Comparison changes_to = false (event device/attr eXcluded)
+167ms ║║Comparison (enum) not present changes_to (string) not present = true (0ms)
+181ms ║║Condition #9 evaluated true (45ms)
+190ms ║║Comparison (enum) closed is (string) closed = true (6ms)
+192ms ║║Condition #10 evaluated true (9ms)
+233ms ║║Comparison (long) 38071674 is_greater_than_or_equal_to (integer) 300000 = true (2ms)
+235ms ║║Condition #11 evaluated true (42ms)
+245ms ║║Comparison (enum) unlocked is (string) unlocked = true (1ms)
+246ms ║║Condition #12 evaluated true (11ms)
+248ms ║║Condition group #8 evaluated true (condition did not change) (134ms)
+274ms ║║Executed device command [OFFLINE - Front Door Lock].lock() (22ms)
+280ms ║║Executed virtual command [OFFLINE - Front Door Lock].waitRandom [500, 1000] (1ms)
+283ms ║║Requesting wake up at Thu, Mar 9 2023 @ 7:48:17 AM EST (in 719ms) for 13 (st:15)
+335ms ║╚Execution stage complete. (301ms)
+437ms ║Setting up scheduled job for Thu, Mar 9 2023 @ 7:48:17 AM EST (in 631ms)
+440ms ╚Event processed successfully (436ms)
I don't see this issue the RM. I'm not sure where to look.
I would check your hub mesh devices are setup properly, and webCoRE piston is using the proper devices.
I don't see anything so far that shows webCoRE itself misbehaving.
I have done that. On reboot it "takes time" Default 2 minutes to synchronize up. That has been set up for quite some time too. Some devices may show offline until the next sync. Dashboard will show offline for two minutes and then it is OK. RM Rules work everything seems to work just the Webcore is affected. Maybe it is the C5 and Processing. I'm just seeing strange behavior since moving the firmware of the C5. Example, I check Wi-Fi and Geo fencing for presence and combined them together. This just failed where typically this has been solid. Maybe I'm looking at the wrong place. I'm getting an error the comes and goes with a Webcore variable that it cannot be read but I don't see any issue with positon and it is still working. Thanks for your help.
You need to show some logs of this. I have C5s, reboot them all the time.
The example you show, webcore sent the command and the device is what is showing the offline. WebCoRE is sending the command and you can turn on device logging to see what it is or is not doing...ie webCoRE does not change the device internals
This thread has lost its purpose. It has turned into an unwieldy disorganised support thread.
Can we get a new read-only thread that contains important updates and release notes for Webcore Hubitat?
…. Which is what this thread was originally for.
Well the first post is regularly updated to show changes and fixes related to Webcore, with archived notes of what was fixed in previous builds. Were you looking for anything else regarding updates, or were you possibly unaware this was there? It has been edited 237 times, so I feel @nh.schottfam has done a great job keeping us informed.
The more recent posts are mostly others speaking up when they have a problem with a certain Webcore related function, or something is not operating the way they are expecting it to within Webcore.
Fortunately, I feel this thread is pretty on topic, and I have seen other threads on the forum which get wildly off topic, or drift away from the original issue posted about. And when it does get highly user issue specific, the moderators tend to take it into a PM based fix, rather than just spamming the thread here.
Download the Hubitat app
