Hub Connected Devices Now Use Edge Drivers

I have at least one that was automatically migrated to Edge that still shows in the IDE with a DTH assigned. I haven’t noticed any issues, so I wouldn’t worry about it. Just take it as another sign that the Groovy IDE shouldn’t be trusted anymore. The best thing to check to see which platform is being used is probably the devices command in the CLI.

I moved my first few devices (3 ZigBee temperature sensors, one ZigBee plug…all light use in sense of few automations) to edge drivers.

Very weird things happening. For one all the lights in the house keep going off. Others going on seemingly randomly. I got an intrusion notice as if the house was in away mode. And I got the attached error which I’ve never seen and don’t understand.

Any idea what all of this is about? Doesn’t bode well for 9/30.

Did you remove/add a lock… perhaps reset it?

No. I have a lock but didn’t make any change to that.

Hi, @Terri_Baker. Sorry for the

So, in the app, you notice they’re using a driver, because this option appears in the device’s details, right?
But in the IDE, the device type shows still a DTH’s name instead of “Placeholder”? This is what you see, @philh30, right?

We have seen that some values stay there with the same values prior to the migration, this includes route and other metrics. Despite they’re shown there, they won’t be updated anymore.

So, @philh30 is right, you should check in the app and the ST CLI (command: smartthings devices deviceId -j)

2 Likes

Correct. I posted screenshots here. Potentially confusing for users, but thank you for the confirmation to not worry.

1 Like

Can you share the Brand and model of those devices you reinstalled using drivers, please?

Also, have you checked the info in the driver’s log to see the incoming events?

For that, you need to install the ST CLI (here are the instructions) and execute the command:

smartthings edge:drivers:logcat 

Then, enter your Hub’s IP address (which you can find in the IDE > My Hubs) and select the driver from the list.

It was a few of these: sonoff snzb-02
And one of these: Innr SP 224-2

I installed the CLI, but am not really sure what I’m looking for in the logs.

I have four of these temperature & humidity sensors.
What driver are you using with them?

I’m using “ZigBee Temp Humidity Sensor Mc” because I only saw a stock ZigBee humidity sensor.

From here: [Beta] ) Edge Driver Zigbee Temp Sensor and Thermostat Mc: - #173 by Mariano_Colmenarejo

2 Likes

I’m working on an updated driver for the SNZB-02, should be in beta shortly. I have quite a few of the sensors and am porting my DTH over with any device peculiarities.

2 Likes

I see. Was this strange behavior (lights going on and off unexpectedly) reported by others with that device and driver combination? I didn’t see that but didn’t read the whole thread.

That’s the same one I’m using.

You shouldn’t be seeing any adverse affects from that, since it’s just a temperature and humidity sensor, unless you’ve got a routine associated with it somehow.

1 Like

Hi,

The deviceProfileName for the Fibaro Carbon Monoxide Sensor in the zwave-smoke-alarm fingerprint is set incorrect. Currently lists deviceProfileName: fibaro-co-sensor-zw5.
I think it should actually be deviceProfileName: co-battery-temperature-tamperalert-temperaturealarm.
Is there anyone who can fix this please?

I am not familiar with the device but clearly the profile matches up with the source code which specifies two preferences. So might I suggest you explain your reasoning?

Sorry I’m still new to this and still learning.

But if I’m not mistaken the deviceLabel is the device name, in this case Fibaro Carbon Monoxide sensor (Or Fibaro CO sensor ZW5 as it was called in the Groovy Device Type Handler).
And the deviceProfileName contains the parameters the device measures/senses and displays in the app.

Looking at other devices as example:
deviceLabel: First Alert Smoke Detector
deviceProfileName: smoke-co-battery

deviceLabel: Fibaro Smoke Detector
deviceProfileName: smoke-battery-temperature-tamperalert-temperaturealarm

For both of the above devices the deviceProfileName contains the parameters that specific device measures/senses.

Back to the Fibaro CO sensor. This device is currently listed as:
deviceLabel: Fibaro Carbon Monoxide Sensor
deviceProfileName: fibaro-co-sensor-zw5
But for the Fibaro CO sensor the parameters are actually CO-battery-temperature-tamperalert-temperaturealarm.
So what I would expect for the Fibaro CO sensor:
deviceLabel: Fibaro Carbon Monoxide Sensor
deviceProfileName: CO-battery-temperature-tamperalert-temperaturealarm
or
deviceLabel: Fibaro CO sensor zw5
deviceProfileName: CO-battery-temperature-tamperalert-temperaturealarm

The profile name points to an actual profile defined in the profiles folder of the driver. In this case there’s one specifically designed for the device:

1 Like

Ok, thank you for explaining!

I’ve read through this thread and I’m mostly just left confused! I have a bunch of GE switches that do not show up as edge drivers. Actually none of my GE switched are showing up as edge. What do I need to do? Do I have to remove each one from ST and add again?

1 Like

It can definitely be confusing! The automatic transition for devices already on your account has not started to happen yet, so you will probably not see any edge drivers unless you have enrolled in the beta program or unless you manually download them yourself.

The automatic transition for devices already on your account is not scheduled to start until September 30 and even then it may take several months to be complete.

Meanwhile, there are some production edge drivers being loaded for some customers, so as you add new devices to your system some of them may onboard with an edge driver. Otherwise just wait and eventually everything will catch up.

3 Likes