[OLD] MQTT app beta1 and pre beta2 - please use beta3 thread

Hi @IslandMan54 and @mag - just wondered ... are either of you using my MQTT app ? Is there something I need to fix to make it work better for you ?

Hi Kevin,
I am not using your MQTT APP. Did that enable use of the WWA02AA sensor?
I've been away from the board for a while, have the system kinda stable and don't want to mess with it. It's still acting flaky at times but I just work around it.
Dave

Hi Dave,

Sorry no help on WWA02AA but this topic is for discussion of the beta release of my MQTT app and I'm thinking maybe your discussions with @mag might get better visibility and response if you moved it to a different, appropriately titled topic ?

No I have the WV-02 Outdoor Water Valve with moisture sensor

Ok thanks, yes on beta 2. I’ll wait... plenty of time now :slight_smile:

I'll be in touch so you can pre-test in a day or so.... as you're using the attribute mappings

Kevin,

for the most part, it works beautifully. Thank you for your efforts!

I do see a couple if issues:

  1. A Smart vent is not 'settable'. It should exposed On, Off and Level. My vents are on the default driver.
  2. (Following the discussion about valves and flood sensors,) I noticed that the Flood sensors have only one property - Battery; the Water property is missing.
  3. The Valves are working now. However, the valve driver also allows me to send Refresh commands (and receive contact:status in response).
    valve
  4. For AlexaTTS, I only get this:
    Alexa
    and she does not want to talk. Of course, this is like 0 priority - there are other female voices in the house.

Thanks!

I'm surprised you're able to select one actually as I don't see a specific vent device capability. Which capability dropdown are they listed under ? Is it masquerading as a dimmer or something ?

Are they being listed under 'Water Sensors' ?

I haven't supported the refresh command on any device - is it important or useful ? Is the status not always correct ?
Are you saying that if it was locally activated by say a leak detector or other contact closure it doesn't report it's status change to HE ?

This Alexa device is showing under 'Speech Synthesis' ? I have only tried Sonos and so possibly issues here. I can take a look though. Google Home is probably the same. Alexa exposes a 'speech synthesis' capability and a 'speak' command in the driver does it ?

https://docs.hubitat.com/index.php?title=Driver_Capability_List

Kevin,

the vents:
Although there is no distinct Vent type, they are visible in 'Everything (all capabilities/attributes a selected device supports). I am guessing that's where I got it from.

Flood Sensor:
I am using (slightly modified) ST driver. Not sure about now but at the time of installation, the default Hubitat driver did not reliably report the battery status. The daily reports confirm that the sensor is alive.

Valves;
There are two things here.
For some reason, the default driver (and btw Homeseer) return the 'expected' status immediately after the command and regardless of whether the expectations materialize or not. So, I ended up with the ST driver.
The Refresh is only needed as the lifeline but just like with the Flood sensors, it's nice to know that the devices are on the network. The Refresh thing returns contact:status instead of 'valve'. If this causes additional problems, I can try fiddling with the driver; however, my abilities are very limited.

I use Alexa for entertainment and certainly, would not ask you to treat it as anything more than that.

That drop down may not be working correctly in the beta release but I am interested what capability is being found.

Is it visible under water sensors ?

I will think about refresh but it encompasses every device and you could instead use an MQTT trigger to an RM Rule to accomplish this for such devices.

Could you copy paste me the 'Data' section from this particular device from the HE devices page ?

This is purely a HE virtual switch - not associated with any actual device on MQTT ? So nothing external actions the _cmd when sent to MQTT ?

I think it's just an issue in beta2 whilst I was implementing attribute maps

Kevin,

Just the batteries, in both cases.keen

flood

I think you'll need to send me a copy of the drivers code you are using (by PM) as I don't know how to pick the devices up - vents and floods... or point me to it..

The fact vents has on/off (unless I misunderstood that) must mean it has a switch attribute but how to get the 'level' I'm not sure. I'm surprised it isn't appearing as settable already..

Neither of these devices seem like things that would have battery levels.

Sorry to be dumb - what is a vent device ? Is it some form of adjustable heating/cooling airflow device - or maybe a venetian blind type device (we don't have them over here with that naming)

I must apologize.
Just verified the flood again and it was present under Water Sensors but not checked.

Selecting the option fixed the problem.

I can certainly forward you the flood and valve drivers.
The Vent driver is Hubitat proprietary. Will a ST driver help?

Both the Flood sensor and the Vent have batteries. And the reporting is correct.
And yes, the Smart vent thing simply adjusts airflow by changing the angle of the slats, it does look like a venetian blind, except there is no Up/Down.

With some reservations, I believe on/off/level implementation is similar to dimmers (and blinds, for that matter). In other words, sending Level=0 is (almost) equivalent to setting Switch to Off.

Sounds a bit similar to a louvre shutter arrangement..

What is the name of the Hubitat vent driver in HE's list of drivers ?
They do not list a capability for vent.
I just need to know the capabilities and attributes that driver supports.

What actual device is it manufacturer/model ? Point me to the ST driver.

If it appears in 'everything' but doesn't populate MQTT correctly but appears in no other dropdowns then it's some capability I don't support... Unless it is only seeing it as a battery - but then it should be in the battery dropdown too.

Both flood and valve are working OK for you now though aren't they ? - so I don't need those drivers.

If you have the dropdown at the bottom of the config page Publish these device capabilities’ entitled

List devices capabilities and attributes to Hubitat topic

then select your vent device there and restart your hub - you will then have a Hubitat topic on you MQTT broker with this device information populated, expand all the sub topics, take a screenshot and paste it and that will show the information.

The flood is working; valve is working but there is no refresh.
If fixing it is beyond the scope, I'll think of something. Unfortunately, that something will certainly affect reliability.

Here is what I have for the vent.

It is present in Battery sensors. I did not select it explicitly but again, probably because of the problem you've mentioned, no devices are selected in the category but all show their batteries.

will do and let you know (tomorrow). Thanks!

OK that’s fine... I’ll see what I can work out.

Refresh is not an option I support currently - sorry. But as I said above just create a virtual switch on MQTT and link it to an RM rule that handles the refresh command direct to the device(s) you want. Then you can initiate a refresh from MQTT which seems to be your goal. One switch could send refresh to many devices.

The screenshot is enough...