SmartThings Edge Developer Beta | Known Issues and Bug Tracking

Let me verify with the engineering team. I’ll be back in a moment.

Update:
Yes, it is normal behavior. If the Hub is restarted, all the timers will be destroyed.

2 Likes

I don’t know if it’s really necessary, but I’ve gotten into the habit in my drivers of when I know the info_changed lifecycle is called because of a driver restart, I cancel all my timers, as well as shut down anything else that may be left hanging, like open sockets and such. Hopefully when the proper driver restart lifecycle gets implemented I’ll be able to move that ‘shutdown’ type of code over to that handler.

1 Like

Lifecycle infoChanged is called for various reasons, even cyclically every 1 hour.
How do you recognize if infoCanged is called due to a reboot hub?

The problem is when you don’t want a timer to stop with the restart or reboot the hub, for example so that a thermostat continues to work where it was when it is back online.

Obviously, all device states are stored in permanent memory and are automatically retrieved.

But, sometimes when initializing the driver we initialize values for custom capabilities and some variables so that it begins to work as we want and perhaps we should differentiate if it is initialized by a new installation, driver change (life cycle, handler driver_switched) or by hub reboot

It’s just a temporary measure until driverSwitched is implemented, but when I see an info_changed come in that doesn’t have any of my preferences that have changed, or any other standard attribute that hasn’t changed, I assume it’s a driver restart. That may be dangerous, I know, but seems to be accurate the majority of the time.

Once the driverSwitched lifecycle is implemented, you’d probably have to somehow save the state of your timers, if that’s possible. (I wonder if you can find out what’s left on a timer?..) But yes, I usually have unique code based on if the device has just been created vs. (re) initialized.

I am using theSwitched lifecycle driver to execute the device configuration when switching to a driver that needs a specific report configuration to work and the device could have custom configurations in the previous driver, for example a temperature sensor that is paired to a thermostat needs to make sure it is set to maximum accuracy.

A post was split to a new topic: [ST Edge] Integrating Z-Wave sensor device

See the post I just made in the Lifecycle topic. I think we all misunderstood the driverSwitched lifecycle: it looks like it’s only for when devices get moved from one driver to another, not when a driver gets an update.

A post was split to a new topic: [ST Edge] Issues with the channel invitation web UI

A post was split to a new topic: [ST Edge] Issues with the driver “Z-Wave Button”

Do you plan on adding a Live Logging feature that end users can see without having to setup the CLI?

You’re asking users to submit their hub logs when they report a problem, but users can’t provide anything to community developers which makes troubleshooting extremely difficult…

2 Likes

A post was split to a new topic: [ST Edge] Issue with the integer type device preferences

Hi! I noticed that support for floating point numbers has been added to firmware 0.40.x. However it seems like almost nothing changed compared to before the support was added. When I try to handle the PresentValue (0x55) attribute on the AnalogInput cluster (0x000C) the value that I see in logcat is always 0. According to the zigbee docs this attribute is of type Single.

This is my attribute handler:

local tvoc_value_attr_handler = function(driver, device, value, zb_rx)
  local tvoc_ppb = utils.clamp_value(value.value, 0.0, 2500.0)
  device:emit_event(capabilities.tvocMeasurement.tvocLevel({ value = tvoc_ppb, unit = "ppm" }))
end

And these are the logcat entries:

2021-11-19T18:57:48.233858442+00:00 TRACE Aqara AAQS-S01 TVOC Sensor  Received event with handler zigbee
2021-11-19T18:57:48.251565775+00:00 INFO Aqara AAQS-S01 TVOC Sensor  <ZigbeeDevice: 7b437bf5-d5bd-4af6-917c-c6ff795015d4 [0x4E69] (Aqara TVOC Air Quality Monitor)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x4E69, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: 0x000C >, lqi: 0x84, rssi: -67, body_length: 0x000B, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x66, ZCLCommandId: 0x01 >, < ReadAttributeResponse || < AttributeRecord || AttributeId: 0x0055, ZclStatus: SUCCESS, DataType: SinglePrecisionFloat, SinglePrecisionFloat: 0 > > > >
2021-11-19T18:57:48.273495442+00:00 TRACE Aqara AAQS-S01 TVOC Sensor  Found ZigbeeMessageDispatcher handler in aqara_tvoc
2021-11-19T18:57:48.279889442+00:00 INFO Aqara AAQS-S01 TVOC Sensor  Executing ZclClusterAttributeValueHandler: cluster: 0x000C, attribute: 0x0055
2021-11-19T18:57:48.289154442+00:00 INFO Aqara AAQS-S01 TVOC Sensor  <ZigbeeDevice: 7b437bf5-d5bd-4af6-917c-c6ff795015d4 [0x4E69] (Aqara TVOC Air Quality Monitor)> emitting event: {"capability_id":"tvocMeasurement","state":{"value":5.8774717541114e-39,"unit":"ppm"},"component_id":"main","attribute_id":"tvocLevel"}
2021-11-19T18:57:48.316206775+00:00 DEBUG Aqara AAQS-S01 TVOC Sensor  Aqara TVOC Air Quality Monitor device thread event handled

Do I have to deal with the arguments in the attr_handler differently for floating point numbers?

Also what I find a bit weird (but that’s a separate thing) is that the references to the tvocMeasurement capability show that it should be emitted in ppm but my device (and probably most of these tVOC sensor devices) report it in ppb. So far I haven’t found any evidence that providing ppb would work, but as long as I don’t get non-zero values it won’t make a difference anyway :grin:.

@DJFliX I have a driver for this device (Aqara tvoc by varzac · Pull Request #6 · varzac/EdgeDrivers · GitHub) and I am getting values as I would expect.

<ZigbeeDevice: b2ede2e6-6eff-47c0-afee-99ca23474e89 [0xC4F2] (Aqara Air Quality Sensor)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0xC4F2, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: 0x000C >, lqi: 0xFF, rssi: -52, body_length: 0x000A, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0xE3, ZCLCommandId: 0x0A >, < ReportAttribute || < AttributeRecord || AttributeId: 0x0055, DataType: SinglePrecisionFloat, SinglePrecisionFloat: (1 + 0.589844) * 2^(9) > > > >

So without more specifics it looks to me like your device is actually reporting a 0 value. However, it is a bug that value.value is not doing the special handling of a 0 report which is why that event is showing that really tiny non-zero value.

1 Like

Awesome, thanks! This was my first (attempt at) an edge driver so it’s nice to see that I at least got some stuff right. I’ll keep an eye on that edge channel so I can try out this driver to see whether my device is faulty. Chances are I messed up elsewhere in the driver and the device is working perfectly fine :sweat_smile:

@nayelyz,

Since yerterday, I can’t access any edge drivers channel via web or from the app. If I can access it from the CLI.
Users cannot access my shared channel, I don’t know if to other channels can.

From the CLI and the app I cannot access the drivers installed in my HUB, but I can change the drivers in the devices by clicking on the proposed drivers. The magnifying glass does not find drivers installed in the Hub

I have tried to reboot and shut down the hub several times and the problem persists

Thanks

2 Likes

Hi! I was able to replicate the issue with the web page of the invitations. I’m already in contact with the engineering team about this. As soon as I get an update, I’ll share it with you.

About this, do you receive any error in the CLI? I got the 403 error but I just want to confirm

1 Like

Yes, 403 Code error

The engineering team already solved both issues, let me know if you’re still having problems

2 Likes

From the app I can now access the hub drivers and all the channels.
From the cli, I’ll try later, now I can’t

UPDATE: with CLI works fine too

Thanks

1 Like

Regarding the new beta ‘Zigbee Button’ driver when used with the ‘IKEA On/Off Button’ (two-buttons-battery).

  1. Unlike the DTH there isn’t a button capability in the main component for legacy purposes. That’s fine by me but it does mean that there isn’t anything to display in the dashboard tile other than the battery level. Obviously we have to start somewhere but I think that needs addressing.
  2. Unfortunately the battery level is half what it needs to be. Unsurprisingly I had to change the batteries in both my buttons before installing them so they should really be showing 100% but IKEA is quite enthusiastic about 87%. The driver is reporting 44%. I believe we saw that with other IKEA devices using Edge drivers.
  3. Thank you. Just a pity the IKEA buttons are currently useless because of their battery problem.
1 Like