Just checking out this post now - does this work with new app? Even using Fully as SmartThings motion sensor?
Also I’ve read the part about the piston twice now but I guess I’m not fully understanding what is gained by using the piston in addition to the handler.
PISTON 1: will lower the brightness level at night and turn off the motion detection, during the day it increases the brightness. HD Fire tablets with FKB often have brightness problems with the auto function.
PISTON 2: will make the device into a real time motion detection device and in the classic SmartApp grab an image and present to the GUI. With the new app, the motion detection still works, but there is no image display capabilities.
In general, this DH is designed to be friendly towards webCoRE users so you can design your own smart solution. I appreciate the folks that build thoughtful & complicated dedicated SmartApps, but my position with a reasonable understanding of webCoRE - everyone can design their own specific requirement and shouldn’t burden the original designer with their specific needs.
To add: I still run a SmartThings hub in limited functionality, but like others moved a lot over to Hubitat. Once SmartThings releases a reasonable development environment, I will update the DH as best possible with the new Application. Once they shut down the Groovy support next year, I believe that will be the end of the road for ST support.
@Bloodtick_Jones Would there be any chance to add audioNotification and playText commands to support TTS announcements with Rboyapps?
Anyway you can confirm with Rboy that Audio Notification is looking the for playText method? That seems to be long deprecated from the Music Player with Sonos. It should be trival to add if you can confirm the capability and expected method call. I am not really doing SmartThings anymore, so it will be just a blind update.
That was my thought as well…
In an email exchange:
> The device handler would need to implement the capability audioNotification and support the playText command to support TTS announcements with Intruder Alert with Actions and Chimes and Notifications. Once it does that it will be showup as a compatible device.
So actually found a reference in Hubitat to audioNotification. I did test the function on Hubitat, but not ST. You might need to uncomment line 104 if you don’t have any luck, and if you turn on debug it should output the method call and your text variable. Usage is “playText”,[“string”, “number”] but you do not need to supply the “number” as it will default to the current level. GitHub is updated now.
Updated the DH and it pulled right up in a few of the apps. I’ll test it when the family wakes up.
Finally got back to testing out the DH…
Commenting out line 104 gets this in the ST logs.
8:33:21 AM: error java.lang.IllegalArgumentException: Command 'playTextAndResume' is not supported by device 2b9e4280-4d7b-4f2e-b12c-8aace5276adc of type 'Fully Kiosk Browser Device'. Supported commands: [on, off, off, strobe, siren, both, beep, setLevel, refresh, take, speak, ping, playTrack, playTrackAndResume, playTrackAndRestore, screenOn, screenOff, startScreensaver, stopScreensaver, triggerMotion, toForeground, fetchSettings, fetchInfo, loadStartURL, loadURL, setVolumeAndSpeak, setSpeechVolume, setScreenBrightness, setScreensaverTimeout, setStringSetting, setBooleanSetting, getStringSetting, getBooleanSetting, sendGenericCommand, speechVolumeUpdate, getCamshot, getScreenshot, fetchImageS3, setVolume, speechTestAction, chime, alarm, playSound, stopSound, alarmOff, setMediaVolume, setAlarmVolume, setNotifyVolume, playText] @line 864 (doCall)
So the playTextandResume is now the command in dispute.