Does this persist after a hub reboot?
Did you remove your account the webcore website?
How do you do that? I didn't see anything other than 'Logout'. I would have thought that by hitting the 'remove' button within the Webcore app it would've taken care of all aspects of app removal.
lol, I already tagged him in my first post
lol didn't see that, sorry
1 Like
Yeah, that was the first thing I tried. Still there.
Thanks
Appears to be a browser you have running doing that
Did u leave one up?
Couldn't find one so I went ahead and rebooted my chromebook and logged out of the mobile app (android). Looks like that did it!
Thanks everyone for your time and effort.
(I'll go back into hiding now. 
)
1 Like
I have run in to this before where setvolume doesn't work in commands.
It still seems to be broken so maybe someone has insight.
I am simply saving the old volume in a var which works.
Setting a new one and putting the original volume back.
Set volume never changes from 30.
+30ms ║║Executed virtual command [Living Room Pair].setVariable (2ms)
+503ms ║║Executed device command [Living Room Pair].setVolume(75) (471ms)
+31ms ║║Command optimization: Skipped execution of device command [Living Room Pair].setVolume(30) because it would make no change to the device. (1ms)
It would be good to show more logs on each execution start to finish.
Medium level likely would do...
What type of device is your speak device?
Ok. I just cut out all the crap from the Full log.
Google Chromecast speakers.
I'll try for some more detail.
Test piston. Volume never changes.
app:16092023-11-27 12:37:18.367debugReleased Lock and exiting
app:16092023-11-27 12:37:13.374debugReleased Lock and exiting
app:16092023-11-27 12:37:04.672debugReleased Lock and exiting
27/11/2023, 12:37:18 +304ms
+3ms ╔Received event [HomeC8].time = 1701117438282 with a delay of 22ms, canQueue: true, calledMyself: false
+10ms ║RunTime initialize > 9 LockT > 0ms > r9T > 1ms > pistonT > 0ms (first state access 4 m:8 4 5)
+13ms ║Runtime (6514 bytes) initialized in 1ms (v0.3.114.20231008_HE)
+19ms ║╔Execution stage started
+26ms ║║Command optimization: Skipped execution of device command [Living Room Pair].setVolume(30) because it would make no change to the device. (1ms)
+28ms ║╚Execution stage complete. (10ms)
+33ms ╚Event processed successfully (30ms)
27/11/2023, 12:37:09 +584ms
+4ms ╔Received event [HomeC8].time = 1701117429551 with a delay of 33ms, canQueue: true, calledMyself: false
+10ms ║RunTime initialize > 9 LockT > 0ms > r9T > 2ms > pistonT > 0ms (first state access 3 m:7 4 5)
+12ms ║Runtime (6499 bytes) initialized in 2ms (v0.3.114.20231008_HE)
+18ms ║╔Execution stage started
+3693ms ║║Executed device command [Living Room Pair].speak(Testing set volume) (3667ms)
+3697ms ║║Executed virtual command [Living Room Pair].wait [5000] (0ms)
+3700ms ║║Requesting wake up at Mon, Nov 27 2023 @ 12:37:18 PM PST (in 4999ms) for 1 (st:6)
+3704ms ║╚Execution stage complete. (3686ms)
+3744ms ║Setting up scheduled job for Mon, Nov 27 2023 @ 12:37:18 PM PST (in 4990ms)
+3746ms ╚Event processed successfully (3742ms)
27/11/2023, 12:37:04 +280ms
+4ms ╔Received event [HomeC8].test = 1701117424280 with a delay of 0ms, canQueue: true, calledMyself: false
+34ms ║RunTime initialize > 33 LockT > 1ms > r9T > 25ms > pistonT > 24ms (first state access 2 m:7 5 28)
+36ms ║Runtime (6398 bytes) initialized in 25ms (v0.3.114.20231008_HE)
+38ms ║╔Execution stage started
+49ms ║║Executed virtual command [Living Room Pair].setVariable (1ms)
+266ms ║║Executed device command [Living Room Pair].setVolume(75) (214ms)
+270ms ║║Executed virtual command [Living Room Pair].wait [5000] (0ms)
+273ms ║║Requesting wake up at Mon, Nov 27 2023 @ 12:37:09 PM PST (in 4999ms) for 1 (st:4)
+277ms ║╚Execution stage complete. (239ms)
+314ms ║Setting up scheduled job for Mon, Nov 27 2023 @ 12:37:09 PM PST (in 4989ms)
+316ms ╚Event processed successfully (313ms)
I would start with testing the device driver (HE console -> devices -> select the device) that you can change the volume, and that the new volume shows up in the attributes.
The logs show the last set volume would make no changes, so it seems to suggest the device is having a problem or delay in adjusting the volume.
I would assume device debugging turned on would show the commands being sent to the device, but I don't have the device log data to match your piston executions.
For debugging purposes you could read back the setting after making the change.
So it appears that strange things happen.
I could get a single speaker to work in the office but not the living room ones.
I kept getting invalid attribute in the expression; weird.
I did a chromecast app (beta) rediscover and I think it assigned all the drivers to Chromecast Video; no volume attribute there.
I manually put them all back to Audio and it's working now.
I'll have to be aware whenever rediscover is run to check the device drivers.
The odd thing is it worked on some speakers around the house because after the driver change "Initialize" was never pushed so the old Audio driver remained.
Thanks for your push in the driver direction.
@nh.schottfam
I'm seeing missing device attributes on Global vars now. I use the staging site so I thought it might be that but the production one shows the same thing.
These are old pistons that have run for years. I cloned one the other day to set up some new blinds on a different schedule.
The @BlindsRecRoom device now has drop down options for generic stuff but no Close, Open etc. for their device type. Using them individually provides these attibutes but not as a global anymore.
You can see that when I originally created these pistons I had populated the tasks with the correct available attributes. If I edit these lines now they show Do - nothing selected.
I have tried it with other devices such as locks and water sensor globals and I don't get chopises for locking or wet/dry; just generic attributes.
Tried adding a real device that has the attributes, use it, then remove it?
Try again with staging
@ipaterson has made some changes to correct this. Let him know if another issue.
I've tried may variations but not that one.
I added a real device of the same type to the global containing 3 of the same device.
Checked the commands available and I get something I haven't seen before; an extra list at the bottom of "Commands available to only some devices" which contains the missing commands for blinds.
One I remove the real device I'm back to no slection for the device types in the global var.
This has always worked, I have lots of pistons with global vars, same type, devices that show the correct command options for that device.
Will do, thanks!
Stay tuned.
No luck yet but maybe wait a bit for the changes to migrate?
