If you figured out the 3d printed case, please share one with me. I have been meaning to make one. But, I am always got distracted with some other work. I am a software engineer. Probably, making the right case is over my head anyway.
Thanks
Iman
1 Like
Thanks I have done that now.
The temp sensor seems to read 2/2.5 degrees c over what my other sensors show. It fluctuates a reasonable amount but they may be the fast thermal response of the sensor (no averaging which I may do in rule machine) and my room air movement with the heaters on. I'll try this when the heaters are turned off later today.
Ia there any way to include a single decimal for use in tiles? I've looked through the driver hoping to see a rounding value but my limited knowledge in the code led to nothing for the temperature component.
Yes, you are correct. Bosch 280 has internal filtering. I am not enabling them. There are perhaps some application that actually want to read the temperature as it comes in. If you are using it as room temperature measurement, you can use below. Measuring a body of air in the room may need some filtering to slow down the response.
"Coeficient Temperature filter between 0.0 and 1.0" setting in DTH. This will slow down the changes. I would try 0.95 as start. You can lower it to make it more stable. However, if you err on the stability, response will be slow. This will depend on what you are trying to do.
Before enabling the above, I would settle on the offset. I personally would not be surprised at 1 C higher. I also can believe that it may be 2 C higher. I measure compare them with some of the IR temperature reader. 2.5 C higher is a bit much based on my experience. Bosch 280 is very sensitive to its surrounding. Do you have any adapter close by other than the one used by the module?
FYI, the radio module above the sensor is alive all the time as repeater (this has about roughly 1 degree self heating contribution). Unlike battery powered sensor which will sleep most of the time. Therefore, you have this offset. I believe cost of this slight offset is worth the benefit of getting the module work as repeater. Putting the module to sleep will make the temperature reading with less offset out of the box. But, you will loose the repeater functions. A little calibration will resolve the offset anyway.
I am sorry about the log. I have remove it from the code. You can enable it again. There is a method below where you can print the temperature.
private def adjustTemp(double val)
{
Log("reported temperature is $val")
...
...
}
This is your raw temperature reading that you should use as adjustment (not after it is filtered).
I do not control how temperature is shown in the GUI. There may be a work around to parse the temperature as custom attribute. In this case, I can format it anyway I like. If you prefer this way, I can try to make something up for you.
Thanks
Iman
Sorry for all the questions, but is it possible to add another attribute for the temperature with a single or double decimal point? I might be asking the obvious but I can't seem to work it out easily. So there is temperature and temperatureDecimal? Or is this not a possibility to have custom attributes in hubitat?
I am using a rule that is triggered by a temperature change on your device, that then sends this value to a global variable and also sends the %value% to a http get so my android box also knows the temperature. It would be good in my case to have at least one decimal point ideally. Not a deal breaker as 1 degree isn't a lot, but half a degree resolution would have been nice.
I am happy to keep learning if this isn't easily answered.
I do not have problem providing you a way to get the decimal point of the temperature. The temperature data is in Celsius there in the first place. I will prepare something for you. I will let you know when I have updated driver for you. I am not sure that this is something that everyone want. I will not make a public DTH.
1 Like
@iharyadi The version of the Environment Sensor driver written by @mike.maxwell properly handles the temperature with decimal places. I just switch to Mike’s driver and now have 1 decimal place of data in the value. The issue is NOT a display issue. I believe the calls you’re using are truncating the decimal portion of the temperature returned by the sensor.
Perhaps you could tweak your driver to keep the fractional portion of the data. This is especially important for users who prefer Celsius.
Here is Mike’s driver which could use an example for parsing the temperature data on Hubitat.
Hi Dan,
My version of the driver use the following call to parse the temperature.
def event = zigbee.getEvent(description)
getEvent is a built in function. It has the say how to format the temperature. I think this method is used a in a lot of other DTH. In addition, I would get consistent temperature display with other DTH. If hubitat decide to change how to present a temperature value, I do not need to change my DTH.
Mike example does the following to the temperature.
private getTemperatureResult(hex){
def valueRaw = hexStrToSignedInt(hex)
valueRaw = valueRaw / 100
def value = convertTemperatureIfNeeded(valueRaw.toFloat(),"c",1)
...
...
sendEvent(name: name,value: value,descriptionText: descriptionText,unit: unit)
}
I thought that this example will force the DTH to report only in Celsius with 1 decimal precision. It would make the DTH only report in C. It would be an issue for those of us in F scale.
I am planning to make a special attribute that I would format the temperature like in the example for Peter.
Thanks
Iman
Actually, using Mike’s driver mine reports perfectly in Fahrenheit. So please do not add a custom attribute as that will only confuse users. Please try using Mike’s example, as he is the Hubitat Engineer that writes almost every Hubitat driver for the platform. I have to believe he must use similar code in the rest of Hubitat’s drivers.
Yes, that's pretty much the stock temp reporting method for a device that nativly reports in C, some times I change the precision depending on the application.
1 Like
Yes, this is true, however the scope of data and events this returns are limited.
I don't use it for this reason, sure it could be fixed, but it's there more for backward compatibility than production use, and not a big priority atm.
The problem I have with Mikes driver is that there are no options for correcting the temperature or other attributes. Iman's driver has the temperature correction which it appears I need. Otherwise I could look into using rules for this, but would prefer to do that at the driver level so there aren't more global variables created. I will look into Mikes driver and rules to correct the temperature in the meantime.
@peterbrown77.pb, I have updated my github to manually parse the temperature and add a single decimal precision. From what I read here that it is fine to do so. Therefore, I may as well make it public for everyone in the github as well.
Please give it a try. Let me know if you run into issue. I have not given a lot of time to test it.
Thanks
Iman
1 Like
Will do. Thanks.
On another note, but don't expect a solution as I feel the solution lies outside this topic. I am posting it here just in case there are specific suggestions for this device specifically... but suspect its a zigbee problem specifically.
I am having problems with my devices losing connection and not updating. I suspect this is an issue with the placement of my devices or that the second repeater is trying to connect to the hubitat box rather than the other repeater/sensor... The rssi value of the second (furthest from the hubitat) is -76. This seems a little low for reliability yes? I am not convinced its connected to the other repeater as its only 7m from the other one with one wall in between.
I do not think -76 is low. These radio has sensitivity all the way down to the -90s db.
I would double check if you have any interference on the channel. These modules is unlikely drop out mesh. They are pretty hardy. They come with external amplifier to help with its sensitivity and outgoing power.
I am assuming that you have WIFI network around you. If you place your sensors close to your WIFI routers/repeaters, I think it is better to make sure that your Zigbee and WIFI channel is not overlapping. I am sure that your neighbor have WIFI as well. I would not worry about overlapping with them.
Once you take care of the above, yes you can play around with the placement of the modules.
Zigbee routing is not simple. It has neighbor table on top of routing table. If the hub is seen by the module, it will be in the neighbor table. Zigbee routing will try to send the packet directly because it see that the hub is seen from time to time. This is rather complex to control. It is best to leave it alone as they should eventually optimized themselves.
Thanks for the feedback. I have my main router on channel 1 (auto width) and my secondary router which is bridged on channel 6 (auto width). I have the hubitat on channel 25 which I have read is better for inference and believe this is what the Xioami sensors use with their own hub (only read, not confirmed).
Hopefully things optimise over the next few days as I am not seeing any of the temperature sensors frequently updating (they are sometimes very far between). These are a combination of your repeaters (2x) and the xioami/aqara temp sensors (3x).
Are you seeing it on the device event page? If yes, this data does not show updates when the value does not change. I can't say what is the xiaomi is doing.
Yes in the device page. The temperatures would have changed though as I've noticed a number of times the temperature doesn't change when the heaters are turned on in the morning. Unfortunately it seems it's your sensors and the xiaomi sensors. I had anticipated the xiaomi ones could have problems but had hoped with your repeaters that this would be unlikely. And still have good hopes seeing that this seems to be an isolated case.
However I think I need to look into this more as it could be something related to my home in particular and not necessarily the sensors.
I have recently changed (24 hours ago) to channel 25 from 24 as I read somewhere it could be what the xiaomi sensors use by default. However I have had a temperature update since that so the sensors have adjusted, however this morning the updates are few and far between still.
None of the sensors seem to drop off however. I suspect most are relying on the repeaters due to their location, with only two sensors directly connecting to the hub.
It could be the respond to temperature change is slowed if you turn on the filtering. A small spike would have been dampened. Therefore, it would not be shown in the device page. However, the sensor does send the temperature reading.
Another way to check is use the logging. You will see something like below.
dev:31712019-07-30 01:26:41.703 pm infodescription is read attr - raw: 3E830804020A000029BB0A, dni: 3E83, endpoint: 08, cluster: 0402, size: 0A, attrId: 0000, encoding: 29, command: 0A, value: BB0A
dev:31712019-07-30 01:23:41.704 pm infodescription is read attr - raw: 3E830804020A000029A90A, dni: 3E83, endpoint: 08, cluster: 0402, size: 0A, attrId: 0000, encoding: 29, command: 0A, value: A90A
This is my sensor reporting temperature. It is configured to send report at maximum 5 minutes interval or when changes is detected by 0.1 Celsius. The report will not be sent in 5 seconds after one is already sent.
Ok I have changed the filtering to 1.0. I'll keep an eye on the logging.
It seems things are better now, but I may look into a way to log the sensors to see the trend... Although that isn't as straight forward as I would have hoped.
It seems this sensor is sending something to the log every few minutes (edit: seems to be less than a minute for the evening, perhaps becasue the heaters have been turned on in the room?) so appears to be responding well now. Below seems normal yes?
dev:442019-07-31 05:55:00.890 pm infodescription is read attr - raw: 6E050804020A0000297909, dni: 6E05, endpoint: 08, cluster: 0402, size: 0A, attrId: 0000, encoding: 29, command: 0A, value: 7909
dev:442019-07-31 05:54:58.859 pm infodescription is read attr - raw: 6E050804000A000021C535, dni: 6E05, endpoint: 08, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: C535
dev:442019-07-31 05:54:26.862 pm infodescription is read attr - raw: 6E050804000A000021BD33, dni: 6E05, endpoint: 08, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: BD33
dev:442019-07-31 05:54:00.900 pm infodescription is read attr - raw: 6E050804020A0000298F09, dni: 6E05, endpoint: 08, cluster: 0402, size: 0A, attrId: 0000, encoding: 29, command: 0A, value: 8F09
Edit 2: Seems the Xioami/Aqara temp sensors are logging every 0.5 degrees so I think its all updating now. Maybe the channels changes, maybe re-pairing all sensors in situ (push their buttons while searching for devices), maybe the network took a while to repair itself...I don't know but for now all seems well. The log only goes so far back so can't be sure.
