Sort of the same answer. I don’t own a lock so I’m limited to using the virtual Lock. One for the future. You could implement it via RM of course temporarily. I’m concerned over the security aspects over MQTT too.
Kevin,
would it be possible to add
capability "Speech Synthesis"
for use with Alexa TTS or similar?
Thanks.
maybe... I'll take a look - I can see that being useful..
There's likely other associated aspects like volume ..
@mag I now have a rudimentary implementation in beta2. - a speech topic within a speechSynthesis capable device that reports last TTS announcement and you can also .../set this to make a TTS announcement. Thinking about how best to control volume as I don’t really want a separate topic for that because then I have to store it per device.
Kevin,
first of all, thanks for your efforts!
In my opinion, the 'volume' question is probably more complicated than what it appears to be.
I currently use Alexa TTS; and I don't believe the driver has the capability to adjust the volume. If the volume changes come within the same topic, will the driver be able to react properly to the sections it understands?
If an audio device is interrupted for an announcement and the announcement comes with it's own volume, shouldn't the volume be returned to the previous level when the interrupted audio is resumed?
I think I feel that the volume changes should be in a separate topic but on the other hand, I would not want you to go though unnecessary difficulties.
I'm well on with beta2 and hope to release soon, maybe this weekend even if some features are still 'evolving'.
Speed improvement is great and I've added various new capabilities including the requested illuminance. There is preliminary support for 'speechsynthesis' and 'music player (currently status only) . With speech I'm having difficulty with 'speak and resume playing' - it's not working for me on Sonos - it always speaks and stops, maybe that's no longer supported ??
I have initial support for HA Discovery advertising of HE thermostat devices, although most HA attention will come in later beta's
I am working on supporting json payloads too and that's what is delaying me a little but getting there. I publish track info from music players in both json and text.
Lastly there are aspects of supporting multi attribute devices (omni / thermostat) or multiple different devices with duplicate topics which I have to resolve , doubly so now for json payloads where different data values can often appear within the same topic (json payload). This impacts the 'Virtual Devices' page two of my configuration which I'm still not happy with but I haven't had time to refine that yet - just made it a little more useable in this respect.
3 Likes
There's dragons there. It's not only Sonos. VLC Thing has problems with resume (because it doesn't really know enough about what's playing in order to restart it). It's best left as 'unsupported, almost everywhere'
It used to work I thought but it's definitely not now. The TTS works fine though.
Pretty much off topic but, it's a 'not well developed' spec for music players. There's plenty of complaints here about Sonos, VLC, and their ilk. I might go the other way and write a HE driver with speechsysthesis() that sends the mp3 url to an MQTT topic and then subscribrers can figure out what to do on the subscribing platform. It's too big a mess for Hubitat to deal with.
Heya Kevin, just checking to see when you're planning to release beta2? I was eagerly looking forward to it this past weekend. Thanks.
"Soon". I assure you he is pounding away at the code as we speak. 
I was too.. but just a bit more to do with json....
Ive had a break from this, but removed the older alpha versions and reinstalled the latest today. I've created a temperature virtual sensor that is manually populated from MQTT, and this works good.
I cant get a virtual presence sensor to work though. I publish a 0 or 1 into MQTT, based on collecting wifi presence from my Unifi AP, which is then wrangled through node-red and published into MQTT.
These are the snippets of logs, but basically the MQTT Virtual device never updates. Thanks!
MQTTBROKER:
2020-02-29 21:52:20.183 debugMQTT> Rx: heartbeat [671] none
dev:7102020-02-29 21:52:20.120 debugMQTT> Tx: heartbeat [671] none
dev:7102020-02-29 21:52:12.477 infoMQTT> MQTT subscribing to: Presence/Eden
dev:7102020-02-29 21:52:12.447 infoMQTT> MQTT subscribing to: Garden/Spa/temperature
dev:7102020-02-29 21:52:11.029 infoMQTT> MQTT subscribing to: homie/hubitatv5/+/+/+/set
dev:7102020-02-29 21:52:10.994 infoMQTT> MQTT subscribing to: homie/hubitatv5/+/+/set
dev:7102020-02-29 21:52:05.081 infoMQTT> Log Level set to 1
dev:7102020-02-29 21:52:05.080 warnMQTT> ## Restarted ##
MQTTAPP:
app:6432020-02-29 21:52:13.064 debugMQTT: Unifi Eden Phone Unknown device type - dim:false onoff:false type:Virtual Presence
app:6432020-02-29 21:52:12.688 infoMQTT: ================== Startup complete ==================
app:6432020-02-29 21:52:12.687 infoMQTT: [72] Total Hubitat endpoints enabled on MQTT
app:6432020-02-29 21:52:12.685 infoMQTT: [71] Total Hubitat devices are enabled on MQTT
app:6432020-02-29 21:52:12.661 infoMQTT: [71] Hubitat 'everything' all capability devices enabled on MQTT
app:6432020-02-29 21:52:12.510 infoMQTT: ==================================================
Unifi Eden Phone Virtual Device:
Data * presence_Cmd: Presence/Eden
- presence_Topic: Presence/Eden
- presence_ON: 1
- mqtt: enabled
- origin: user
- presence_OFF: 0
In Use By * MQTT
Will take a look... and try it here.
That line actually has the answer !
The 'Virtual Presence' device does not have the word 'sensor' in it's name as HE define it so it wasn't being handled correctly and updating. This is fixed in beta2.
I need to watch out for 'detector' too as in Smoke and CO although those have 'Test' commands available so are not pure sensors.
There are other of the more unusual virtual devices still to complete. If anyone needs one prioritising let me know...
At some stage I am going to change the virtual device page to have more of a 'map value' presentation for attribute values and MQTT payload, rather than (ab)using on/off or true/false .
It will be less cluttered and more flexible
e.g. presence: present|not present 1|0
switch: on|off true|false
contact: open|closed high|low
thermostatMode: auto|cool|emergency heat|heat|off Auto|Cool||Warm|OffThanks Kevin, I'll look forward to updating to beta2!
BTW, I have various mismatches reported as errors. Do you want me to collate these and report back? Most of these are coming from either Xiaomi temperature sensors or SmartThings contact sensors
app:6432020-03-01 08:45:45.571 errorMQTT: [s] Unknown Category for type acceleration reported by device Front Door
app:6432020-03-01 08:45:45.571 errorMQTT: [s] Unknown Category for type threeAxis reported by device Front Door
app:6432020-03-01 08:45:35.956 errorMQTT: [s] Unknown Category for type pressure reported by device Lounge
app:6432020-03-01 08:36:56.968 errorMQTT: [s] Unknown Category for type pressure reported by device Eden's Room
These are sensors that I am not currently creating virtuals for - the 'error' level should really be reduced to 'warn' or 'info' but the red of error draws my attention to them as still things on the ToDo list. There is no Virtual Pressure Sensor in HE or a pressure attribute in an Omni Sensor, but I could put it in a text or variable attribute.
Ok no problem. I'm not too bothered by these attributes anyway, just a by-product of those sensors I guess.
As always I got diverted trying to include a few extra things into beta2 and that plus a little life complication has delayed it. Upshot, I have a hopefully short stay in hospital for an op this week from Thurs for a few days and so I want to get something released before I go in. No support until next Monday I'm estimating. Nothing too serious btw.
So I will post beta 2 before I go in although it's not as tested or complete as I wanted. Some things are still 'in progress', including json / multi attribute support for manually created devices and homie discovery for sensors. Fortunately these features aren't used by many users yet.
So back up your hopefully 'working OK' beta1 code and install beta2 if you wish. If it does have issues you can always revert but the pre testers seem happy with it.
Will post beta2 shortly, it should be quite a bit faster and has most reported bug fixes implemented.
Please keep a copy of and then paste over your existing client driver and app code. Don't create a new device. Then reboot your hub. This will ensure only one device driver is loaded.
3 Likes
Take care of yourself, and good luck!
