@troy_owens, what is the runLocally set in your DH? If you want that the device would use the correct DH (your modified), then you need to set it to false, otherwise it picks up one from the Hub.
And indeed the devices uses the stock one, see the Execution Location: Local line.
but I’m still able to set the temp configure, so it is indeed using the modified, the set humidity is the issue
Try this dth. I have changed the humidity configuration command, he was sending it to another cluster that this manufacturer does not have. Added fingerprint for this Device.
Anyway put 500 in the trigger to test.
If you do not get it to work, there would be another option and that is to put the minimum interval of the report, which is now at 60 seconds, to a fixed 10 minutes and raise the maximum to 15 minutes.
I also see in the photo that it has poor signal coverage, there are 438 failed messages out of 529 sent to the device.
To do the configuration, you have to bring it closer to the hub or take it out of the fridge
Edit the old modified dth in IDE and copy the new over it.
Change the runLocally to false. And try it again. I cannot remember how devices call the configure section, when saved or edited (parameters). In theory if you used a DH which set that value and was not runLocally: true, the device should keep it, but if the DH runs the configure where the stock DHs values updates that, then it must have over written the values in the device itself.
That is a bit of pity, that you cannot change configure reporting values outside of a DH, the same applies for Zwave settings as well.
DTHs modified work well in local with “true”.
Tested without hub internet connection
I don’t want to argue about this now, but trust me, if you leave that as true, the device will run a stock ST DH and NOT your modified code.
No custom code can run locally on the Hub.
That’s a no go… makes the tile show as “checking”
Hi @GSzabados,
I have no intention of arguing with anyone here. It is about helping where possible and all opinions are welcome.
What I can assure you is that the DTHs modified for my “SmartSense multi sensors” and “SmartSense motion sensors” and configured as I liked, work locally in my smart lighting app automations with the hub disconnected from the router.
And I am telling you, that your device is running locally only the stock ST DH deployed with the Hub’s firmware and NOT your modified code.
Install original dth and reinstall the modified
Already done. Thanks for your help
To end this for my part,
I think we are talking about things that are compatible and let me explain:
The modifications made to the dth are only in configure (), which only runs on device installation.
Once the device is installed, it sends the reports according to the configuration saved in device, regardless of whether the dth runs locally or in the cloud.
Specifying:
The device works locally and the reports sent by device are configured as the modified dth has sent to it
@Mariano_Colmenarejo, please read from this point the topic:
And just to learn from other people’s questions:
@Brad_ST, @Jody.albritton, @Zach_Varberg
Can some of you comment please how runLocally works at the moment in custom DH code?
It is amazing that things are continuously changing without any documentation. And obviously not even @erickv, @SamsungZell or @nayelyz has any idea about it.
Please see the comments above…
Well it’ll run when you update the device via the IDE, if you’ve actually changed anything, and of course anytime you choose to run it. I guess the question is whether configure() ever runs locally. There is no particular reason why it should need to and quite possibly good reasons for it not to. Given the DTH starting point is cloud execution I don’t see why you’d bother with configure() in firmware (or indeed installed() or updated()).
I think there is a danger of thinking that whatever is running in the firmware includes recognisable whole DTHs. It might do, but there is no reason it should do. I’d have thought it is more likely it is a collection of code for implementing more important methods like on(), off(), parse() etc in a reasonably standard fashion.
My problem with the situation is that, some part of the code might be separated from the other, configure(), preferences() and is not part of local execution in any condition, but the rest of the code cannot be changed to run locally, but some might would think, oh yeah, it is running locally when it is not running locally. And when at the end it is not doing what your code is, and you spend hours in frustration why it doesn’t do what the code is, then you waste a lifetime to try to fix something which isn’t broken.
When I opened up the topic yesterday, I didn’t know that I haven’t seen it before, and I just read quickly the OP. And though, that person has no idea about the changes what has been implemented back in November, 2020.
All those devices were reporting since the beginning with 0.1 resolution, and ST did a rounding to integer values and showed only integer values instead of decimals. The battery drain hasn’t change due to that change, only a cloud and DH update happened to display the decimal values. Back in 2018, those devices were reporting and displaying decimal values, and somewhere at the beginning in 2019 was changed to display only integer values.
The battery reporting went seriously bad with a firmware update of the devices somewhere in 2019, and since that it shows really quick drain, but the device is running for months without any issue on 1% battery level.
Of course, I am not questioning that changing reporting intervals and changes are not a good thing. But that should have been implemented by ST from the beginning on a non-DH level. The same applies for Zwave devices. Other platforms are solving these issues by having a tool for the communication protocol where specific messages can be delivered to the devices to update these settings. (It could be part of the Zigbee and Zwave settings of the Hub. But look at it, we are still unable to change the Zigbee channels to our own choice. There is no intention to offer this kind of features.)
One of the solutions for Zwave and ST is Zwave Tweaker, but that is again a custom solution with it quirks to do it.
And of course, the biggest problem is the undocumented developer environment with changes in the cloud without any notice. And when you report any missing documentation being missed or incorrect, the answer that they will update it. I have some requests what I have sent by email more than a year ago and still hasn’t been updated.
The whole platform is a shambles. This commit is the a clear statement of it.
(And the developer was well informed and did the research very well.)
First of all, my sincere thanks for the explanations and advice.
Secondly, I think that this is a sterile discussion, that it does not lead to any useful solution, since it does not depend of you or me.
Third, the long version:
- I said yesterday that I ended the conversation and it bothers me not to comply.
- I did not buy a home automation system to be all day watching if it works or does not work, or if it runs in my living room, or in cloud in Dublin or on the far side of the moon. I bought it for the opposite, to make life at home easier.
- I bought zigbee smartthing because they sold it as very low energy consumption technology for long life batteries.
- I did not buy it to dedicate myself to developing software for the system. With all due respect, I have already spent 40 years dedicated to other things about hardware and software systems and I have other things that interest me more now.
- I only got involved in solving for me a problem that someone created, surely with very good intention, turning closing/opening, movement and water leak sensors into fantastic temperature sensors, which from time to time send opening, movement and water leaks events.
- I told my problem here and customer support, looked for information in this fantastic community and shared my temporary solution found for whoever needs it, hoping that whoever created the problem will solve it at some point.
- I don’t think anyone in their right mind at smartthings team thinks, that these sensors placed on doors, windows, floors and ceilings can be used to precisely control of virtual thermostats or similar devices or apps. So, why so much precision wasted in battery consumption?
- If it issue is not solved and they close the IDE and we cannot use custom dths?, let’s look for something else. The world is full of opportunities.
Best regards