This thread is about Mira. There are other threads to discuss Hubithings Replica.
4 Likes
I have been trying to integrate a Lutron Pico original 5 button remote through Hubitat using the Mira integrations. I can it to work pretty easily but no matter which driver I select for the remote in Hubitat only 4 buttons work out of the possible 5 that are on the remote. Does anyone know what I’m doing wrong? All five of the buttons work in hubitat.
Mira is hard coded to 4 buttons max. Id have to look to see what it would take to change that or if it was for a specific reason.
3 Likes
First off just wanted to say hats off to an awesome product, synchronizing on local network is awesome 
I’m having difficulties with a device not properly mapping; here’s the device on hubitat:
* capabilities: {"components":[{"attributes":{"humidity":{"enumCommands":[],"schema":{"additionalProperties":false,"properties":{"unit":{"default":"%","enum":["%"],"type":"string"},"value":{"maximum":100,"minimum":0,"type":"number"}},"required":["value"],"title":"Percent","type":"object"}}},"commands":{},"ephemeral":false,"id":"relativeHumidityMeasurement","name":"Relative Humidity Measurement","status":"live","version":1},{"attributes":{"battery":{"enumCommands":[],"schema":{"additionalProperties":false,"properties":{"unit":{"default":"%","enum":["%"],"type":"string"},"value":{"maximum":100,"minimum":0,"type":"integer"}},"required":["value"],"title":"IntegerPercent","type":"object"}}},"commands":{},"ephemeral":false,"id":"battery","name":"Battery","status":"live","version":1},{"attributes":{"temperature":{"enumCommands":[],"schema":{"additionalProperties":false,"properties":{"unit":{"enum":["F","C"],"type":"string"},"value":{"maximum":10000,"minimum":-460,"title":"TemperatureValue","type":"number"}},"required":["value","unit"],"type":"object"}},"temperatureRange":{"enumCommands":[],"schema":{"additionalProperties":false,"properties":{"unit":{"enum":["F","C"],"type":"string"},"value":{"additionalProperties":false,"properties":{"maximum":{"maximum":10000,"minimum":-460,"title":"TemperatureValue","type":"number"},"minimum":{"maximum":10000,"minimum":-460,"title":"TemperatureValue","type":"number"},"step":{"maximum":10000,"minimum":-460,"title":"TemperatureValue","type":"number"}},"required":["minimum","maximum"],"type":"object"}},"required":["value","unit"],"type":"object"}}},"commands":{},"ephemeral":false,"id":"temperatureMeasurement","name":"Temperature Measurement","status":"live","version":1},{"attributes":{"water":{"enumCommands":[],"schema":{"additionalProperties":false,"properties":{"value":{"enum":["dry","wet"],"title":"MoistureState","type":"string"}},"required":["value"],"type":"object"}}},"commands":{},"ephemeral":false,"id":"waterSensor","name":"Water Sensor","status":"live","version":1}]}
But here’s how it shows up on mira:
{"name":"Wally MultiSensor","label":"Basement bathroom sink","type":"Wally MultiSensor","id":"11","date":null,"model":null,"manufacturer":null,"room":null,"capabilities":["RelativeHumidityMeasurement","MotionSensor","Configuration","Refresh","Battery","WaterSensor","TemperatureMeasurement","Sensor"],"attributes":{"humidity":"54","dataType":"NUMBER","values":null,"battery":"100","water":"dry","motion":null,"temperature":"66.31"},"commands":[{"command":"configure"},{"command":"refresh"}]}
i.e. it looks like a MotionSensor is getting introduced even though the device doesn’t actually support it, so then it ends up borked in SmartThings
Any help would be appreciated 
(As an added bonus, if you could add a simple config, something like a device_type → capabilities mapping that’s user-configurable, it could allow for more power-user features to hide capabilities that don’t map well to ST)
I’m not sure how this is a Mira child device, replicated from Hubitat. None of the device profiles used by Mira have the Battery capability in them.
Can send a screenshot of the child device from the advanced UI? Whats listed under the “device profile” field?
I’m not sure how that would help much. A profile has to be selected based on capabilities in all sorts of combinations. I guess I could have a configuration parameter that lets you pick a profile (similar to how the Zwave Masquerade driver works).
Apologies, that “shows up on mira” dump was from the hubitat side (i.e. hubitat-ip/apps/api/77/devices/11/capabilities)
Did not know about advanced UI, cool, thanks for the link! Here’s what it shows:
Device Profile: hubitat-motion-temp
Attributes:
main motionSensor motion
main temperatureMeasurement temperature
main temperatureMeasurement temperatureRange
I had thought that the capabilities seen on the hubitat side were simply being mapped to respective capabilities on the ST side, which is why I suggested the mapping; but obviously I don’t know how the underlying code works so mostly just guessing
I know you’re likely very busy, so if you you’re strapped for time I’m a software engineer & can help out
Thats exactly how it works, and it looks like your Hubitat side driver is exposing that the sensor supports a motion sensor capability (viewable with your hubitat-app/apps/api/77/devices/11/capabilities URL)
Mira simply takes whatever Hubitat is reporting via the API and maps it accordingly.
You’ll need to use a driver on the Hubitat side that doesn’t expose the Motion Sensor capability. For some of my “multi sensor” type devices, I’ve had to customize a driver on the Hubitat side by removing capabilities it doesn’t support.
Ah I think now I understand; the data at hubitat-ip/apps/api/77/devices/11/capabilities is generated by maker API?
The reason I ask is that the MotionSensor I see at that URL, I don’t see when I go to hubitat-ip/device/edit/11; there, I see:
* endpointId: **01**
* application: **00**
* capabilities: **{"components":[{"attributes":{"humidity":{"enumCommands":[],"schema":{"additionalProperties":false,"properties":{"unit":{"default":"%","enum":["%"],"type":"string"},"value":{"maximum":100,"minimum":0,"type":"number"}},"required":["value"],"title":"Percent","type":"object"}}},"commands":{},"ephemeral":false,"id":"relativeHumidityMeasurement","name":"Relative Humidity Measurement","status":"live","version":1},{"attributes":{"battery":{"enumCommands":[],"schema":{"additionalProperties":false,"properties":{"unit":{"default":"%","enum":["%"],"type":"string"},"value":{"maximum":100,"minimum":0,"type":"integer"}},"required":["value"],"title":"IntegerPercent","type":"object"}}},"commands":{},"ephemeral":false,"id":"battery","name":"Battery","status":"live","version":1},{"attributes":{"temperature":{"enumCommands":[],"schema":{"additionalProperties":false,"properties":{"unit":{"enum":["F","C"],"type":"string"},"value":{"maximum":10000,"minimum":-460,"title":"TemperatureValue","type":"number"}},"required":["value","unit"],"type":"object"}},"temperatureRange":{"enumCommands":[],"schema":{"additionalProperties":false,"properties":{"unit":{"enum":["F","C"],"type":"string"},"value":{"additionalProperties":false,"properties":{"maximum":{"maximum":10000,"minimum":-460,"title":"TemperatureValue","type":"number"},"minimum":{"maximum":10000,"minimum":-460,"title":"TemperatureValue","type":"number"},"step":{"maximum":10000,"minimum":-460,"title":"TemperatureValue","type":"number"}},"required":["minimum","maximum"],"type":"object"}},"required":["value","unit"],"type":"object"}}},"commands":{},"ephemeral":false,"id":"temperatureMeasurement","name":"Temperature Measurement","status":"live","version":1},{"attributes":{"water":{"enumCommands":[],"schema":{"additionalProperties":false,"properties":{"value":{"enum":["dry","wet"],"title":"MoistureState","type":"string"}},"required":["value"],"type":"object"}}},"commands":{},"ephemeral":false,"id":"waterSensor","name":"Water Sensor","status":"live","version":1}]}**
* status: {"components":{"main":{"battery":{"battery":{"timestamp":"2024-08-19T22:59:03.950Z","unit":"%","value":100}},"relativeHumidityMeasurement":{"humidity":{"timestamp":"2024-08-19T22:59:02.143Z","unit":"%","value":50}},"temperatureMeasurement":{"temperature":{"timestamp":"2024-08-19T22:59:02.174Z","unit":"F","value":70},"temperatureRange":{"timestamp":"2024-08-19T22:58:56.743Z","unit":"F","value":{"maximum":2062.618031052927,"minimum":-175.70433435576444,"step":9412.28362744926}}},"waterSensor":{"water":{"timestamp":"2024-08-19T22:59:03.142Z","value":"dry"}}}}}
So I guess the bug is actually with maker API, not mira (I think, if you can confirm)
I’ve asked the same question @ Maker API capabilities don't match what I see on device - Maker API - Hubitat
(apologies, I hadn’t realized that mira is just using a built-in hubitat app which advertises device data at URLs)
No, Maker API is doing exactly what its being told to do.
The driver that you’re using on your device for Hubitat lists all the capabilities that the device supports. This list is what you’re seeing when you use the capabilities URL. Maker API is just exposing what the driver says it supports.
Often drivers will have “extra” capabilities that the device doesn’t really have, especially for multi-sensor type devices. That way the same driver can be used for a whole class of devices without needing to customize it for each one. Normally it wouldn’t matter that a device doesn’t have motion or temp or humidity if it never reports it. In this case, where Mira uses the list of capabilities as reported by Maker API to determine what device it should map to on the ST side, it does matter.
Use an HE driver that doesn’t have the Motion Sensor capability. If the driver is one that is provided by the community, copy it and modifiy it to remove the capabilities that don’t make sense for your device.
1 Like
Would I be able to use this to use echo speaks within Hibitat? Currently my main hub is ST with all of my devices on there but I think I should be able to do this with virtual devices created on Hubitat and then create routines within ST which should mirror back to Hubitat?
Sure, that should work fine. HE exposes virtual devices the same way as real devices, its up to the driver to indicate what capabilities it supports. Mira would then replicate those to virtual devices on the ST side, reflecting the current state and mirror any changes back over to HE.
2 Likes
Has anyone brought up modifying the smartthings driver to allow double-press and expansion to buttons 3, 4 and 5 to cassette pico remotes?
I’m mirroring a Zooz Zen37 4 button remote from Hubitat to Smartthings.
However, it seems a little confused.
Pressing the buttongs on the remote and watching the device on Hubitat everything is correct.
On Smarthings, pressing any button executes button 1 routines, pressing button 1 executes button 1 and 2 routines. Pressing button 2 executes buttong 1 but not button 2 routines.
So there seems to be some confusion of what Mira is sending to ST and what ST is sending back.
Any ideas?
What virtual device is being used on the ST side? A screenshot may help too.
@csstup Hi Mate, any plan to bring battery capability from hubitat to ST
Looking at the history of the virtual device, I think I see the issue. Everytime I press a button, it’s also registering a press for the main button.
Except, that there isn’t a main button. There’s buttons 1-4, but the virtual device is showing a main button, plus buttons 1-4. There should only be buttons 1-4.
This is the device:
https://www.getzooz.com/zen37-wall-remote/
I think a temporary fix here is to remove the action I have for the main button, since there isn’t one.
No, this is by design and is in line with how the other ST drivers work, including the virtuals and stock multi-button devices.
The “main” button is an “is any button pressed”, and the 1-4 component devices are for the specific button.
The “main” button device is used as an overall state, and to show the status on the summary card. If it didn’t have an overall state device, which button should it show on the card? It can’t show all X (in your case 4).
name: hubitat-button-four
components:
- id: main
capabilities:
- id: button
version: 1
- id: refresh
version: 1
categories:
- name: RemoteController
- id: button1
capabilities:
- id: button
version: 1
categories:
- name: RemoteController
- id: button2
capabilities:
- id: button
version: 1
categories:
- name: RemoteController
- id: button3
capabilities:
- id: button
version: 1
categories:
- name: RemoteController
- id: button4
capabilities:
- id: button
version: 1
categories:
- name: RemoteController
There’s no fix, if you want to have a routine trigger on any button being pressed, use the main device. If you want one for any of the specific buttons, use that component device (button1-button4).
Not at this time, and I’m not sure it makes sense anyway. Battery is often optional (devices that are powered via USB or battery) and some devices on HE will say they have the Battery capability but don’t actually, so ST would think it was a battery device yet no values would ever be sent for it.
Also, I’d need to add battery versions of each virtual device profile.
To me it made more sense to manage battery state on the HE side as needed.