New user, maybe old questions? :)

I believe the app is assuming you want to configure a new user/device for use. Handy if you need to add a spouse or significant other, but otherwise ....

thanks @thebearmay. So its harmless and it's how it is supposed to be.

I spent few hours doing migration and few questions came up if you guys can give me suggestions..

  1. I have two identical Fibaro Motion sensors. I paired them and updated status by pressing button in motion sensor. How come they report different information.
    THIS ONE IS SOLVED. There's pending changes and they are slowly updating..

  2. I have Fibaro Smoke Detectors. Found this link and installed groovy.
    [RELEASE] Fibaro Smoke Sensor
    When button is pressed sensors log file say this:

2021-01-28 12:17:08.308 warnSmoke Sensor Living Room zwaveEvent(Command) - Unhandled - cmd: VersionReport(zWaveLibraryType:3, zWaveProtocolVersion:4, zWaveProtocolSubVersion:24, applicationVersion:3, applicationSubVersion:3)

Nothing to worry about?

Also what is that fibaro smoke detector json file in github. I did just copy that fibaro smoke detector groove file and I assume that is enough right?

  1. For some reason my webcore pistons are not working. I did take a backup and import them one by one to hubitat side. Resumed couple of pistons but nothing happens. I did not have time to see what's going on but probably this will be solved later when I have more time.

Actually can someone confirm that send push notification on piston works same way in Hubitat as it works in ST. Should I get push notification from my Hubitat App?

EDIT: it's probably this section which need to be configured to receive push notifications from webcore.

  1. Popp water shut off valve was not easy to pair. Finally got it and had to change device to Dome water shut off. It seems to work as Dome but started to think that is that safe to use other driver which is not made for the exact device. I mean..if generic driver would work should I prefer that? I did not find any popp users here.

  2. What purpose does device* line have:

Here's example from one of the devices. It's Hank one key but when paired hubitat said it is Aeotec Nanomote. I changed type to hank one-key and device is working. I gave it a Device label name but what about that Device name. Where is that used and can I changed it without problems. And.. does it even matter what it is because most likely log files uses device label line right?

Looks like you’ve found answers to most of your questions, but I’ll clarify a couple of them for you anyway. Device Name is defaulted to the Name found in the first Driver paired. Device Label is normally used for most displays (Name used if Label is blank) but you can change both it and the Device Name without harm - the apps and system use the device ID for referencing.

Drivers, generally there is a built in that works (the Generic usually has good coverage for the device class), but sometimes the manufacturer or a community member will write a speciality driver to bring out additional features or capabilities beyond the generic - HE will attempt to match to the closest driver based on the device fingerprint but you can override at any time (remember to hit the Configure after changing the driver to initialize all properties of the driver though).

webCoRE should be able to create a piston on the HE side by copying the piston from the ST side - devices will need to be re-linked. Push notifications will go to the devices you select in the app configuration and the Notifications section of the Mobile App.

The Fibaro groovy file is what you wanted, the JSON file allows the Hubitat Package Manager (I’d highly recomend installing this community app) to install and manage the driver for you. The unhandled command is possibly an extra capability or a newer version of a command - generally an indication that the driver was written against a prior generation of your device’s firmware; so not an exact match but if everything you need is functioning not an issue.

1 Like

Thanks for the great message!! My only problem seems to be webcore. Everything else seems to be okay but I can't get broadcast from hubitat side webcore to assistant relay. ST side works normally. I have to go to right topic and ask about this..

Not familiar with Assistant Relay I'm afraid...

What about this one. I do not probably understand English well enough to figure this one out.

I tried to use same logic as in ST. I got away, night and home/day.
Added presence sensors for away mode and for day mode.

What does that "use time settings for return from away" mean? I do not understand what "time" has to do anything with people arriving back home.

Now my situation is that if I choose presence sensors to "away" mode I can't choose nothing to "day" mode. Day mode is grey and it can't be activated at all. It says click to set but nothing happens. I can still add sensors to night mode and away mode but not to day/home mode.

If I enable that time thing in the beginning does that mean that when one of the presence sensors arrive (listed in away mode) then mode is set to day..or..?

EDIT. instructions says: " As you'll see in the following example, the option Use time settings for Return From Away Mode will change to the hub to the correct mode for the time of day you return home."

So basically it means that if I have been away and I come home middle of the night.. mode is changed to night.. and my intrusion alert is on.. why..
I want it always to revert "day/home" when I come home from "away" mode but can't add presence sensors to day/home mode at all.

Been a while since I looked at mode manager, but I ended up creating a piston to handle my return from Away as it wouldn't operate the way I wanted it to natively - I created a mode that I named Transition and had return from Away change to Transition which triggered the piston to set the mode according to my criteria.

1 Like

Well that is one way to solve it but still I do not understand how this time based returning is supposed to work at night :smiley:
This wouldn't even be an issue if I could add presence sensors to day mode but I can't for some reason.

EDIT: Found the reason... my mode was named Day/Home and it seems that "/" is disabling mode changes. Had to change mode back to "Day" and now I can add presence sensors to that mode. Some would say it's a bug...

Just wanted to update that webcore is fully working now. Main problem was assistant relay not getting any broadcasts from webcore. Issue was because POST request url did not have http in front of the server ip adress. That worked in ST side without http but hubitat side needed that.

1 Like

In ST world I made virtual devices per certain time let's say at 04pm 05pm and 06pm. Then I added those buttons to Sharptools dashboard.
When I pressed 04pm button in dashboard then webcore piston set timer for car heater.

Is there any sophisticated way to do this on Hubitat? I have couple of timer needs and in ST I had over 30 virtual devices just to get timer buttons to Sharptools or Actiontiles dashboard. If there is better and cooler way to do it.. ?

If you add a Button Controller device you can use it to create multiple button tiles on a dashboard, that you can then monitor with a piston to take further action.

But that seems to need real button right? At least that's how I understood it when I tested. I did not test to create virtual button if that counts as button in Button Controller. Then this could work...

I don't have any real buttons, but have six button tiles working from the button controller to act as preset buttons for my Bose Soundtouch

Oh man...You're MVP! :muscle: Going to test it right away.

1 Like

Just keep in mind that the Virtual Button device doesn't implement any standard commands.

So while it has a push() and held() command, they're not part of a standard capability, so you may have to issue custom commands for them

For example, in SharpTools you can create a rule to send the push() command for the relevant button, then add that rule to your dashboard.

Technical Background

Most people probably don't care about the inner workings and intricacies of this, but if you do here's a few more details...

Hubitat (and much of it's legacy from SmartThings) is based around a concept of Capabilities which are a standard set of definitions for what attributes a device reports and what commands it supports. Devices can implement these standard capabilities and then Apps can consume them.

So if an app knows that it's looking for a Switch capability for example, it knows that the device will report a switch attribute with values of ['on', 'off'] and commands of on() and off().

If you think about the normal use of a Button capability, it's in physical devices wherein a person is physically pressing the buttons... so the Button capability is designed for only for reporting which button was pressed... as the only form of actuation should be a physical press of the physical button. In other words, no way in software to actuate the button. The Virtual Button is a bit of an exception to this rule and as such, they've defined custom commands.

Devices can also implement custom commands and attributes. Unless an App has the capability of becoming aware of these custom commands and attributes, it won't know about them. One common approach is with Apps and Drivers that are tightly tied to each other and explicitly aware of the custom commands (eg. a 'service manager' app that knows the custom features of the device). Another approach is through a concept called reflection where an app can read these custom attributes and commands of a device.

The Hubitat dashboard has a custom button tile for the custom commands effectively tightly coupling this custom implementation rather than defining a standard capability for it. This is in contrast to almost every other tile template which matches an official standardized set of capabilities.

Regarding apps and following standard capabilities - note that reacting to button presses is part of the capability specification and will be supported by apps that support the button capability. It's sending a push() or hold() command that is not standard.

1 Like

Thanks for all the comments so far. You all have been very helpful. Couple on new things I'm wondering.

Found this app called Device Watchdog, installed it and got reports. I'm not sure though does that tell me information I need. I was looking a way to see if sensor is offline or if sensor is not acting the way it should. In ST I used to open mobile app and check if sensor had offline tag on it. How does this work in Hubitat?

I had open close z wave sensor that I installed yesterday. Today I just saw that sensor says it's open even though door was closed. Case was that sensor had not reported nothing after successful pairing.

How do I know for example that zwave plus smoke detector works?

For Device Watchdog questions I’d suggest asking @bptworld on the app thread:

He’s usually pretty good at helping people configure the app to achieve their reporting goals.

Sounds like pairing didn't complete successfully.

Come on guys. Topic is nearly one year old and problem was solved back then :grinning: