Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
support for DS18S20 + HTU21D added
#11
Now the basic calculation works for the first time:

Code:
    // calculate temperature according datasheet
/*
    if (tmp[1] == 0)
        res = tmp[0];
    else
        res = -256 + tmp[0];

    

    res = (int16_t)((int32_t)res * 100 / 2 - 25 + ((int32_t)tmp[7] - tmp[6]) * 100 / tmp[7]);
}    
*/  
        UART_PUTF2("tmp[0]: %d , tmp[0]: %d\r\n", tmp[0], tmp[1] );
    res = (int16_t)( tmp[1] << 8 | tmp[0] );
        UART_PUTF("%d \r\n", res );
    res = (int16_t)(int32_t)res * (int32_t)(100 / 16);
//        UART_PUTF2("%d.%02d\r\n;", res / 100, res % 100);  //<= works not for negative temperatures!
    
    return res;


Here is the debug output:
Code:
smarthomatic EnvSensor v0.0.0 (00000000)
(c) 2012..2015 Uwe Freese, www.smarthomatic.org
Device ID: 21
Packet counter: 100
Init analog
Wake-up interval: 60s
Temperature sensor type: 4 (measInt 1, avgInt 3)
Humidity sensor type: 0 (measInt 1, avgInt 3)
Barometric sensor type: 0 (measInt 1, avgInt 3)
Brightness sensor type: 0 (measInt 1, avgInt 3)
Distance sensor type: 0 (measInt 1, avgInt 3)
1-wire ROM ID: 28 28 aa eb 03 00 00 be
Min. battery voltage: 1500mV (measInt 475, avgInt 3)

tmp[0]: 21 , tmp[0]: 2
533
31.98
;Send DeviceInfo: DeviceType 20, v0.0.0 (00000000)
Before encryption: 9e 61 dd 28 01 50 00 06 58 00 42 80 00 00 00 00
After encryption:  75 23 4d f1 7b 08 f7 75 d4 f6 8d 39 78 1a 29 99
tmp[0]: 22 , tmp[0]: 2
534
a▒tmp[0]: 23 , tmp[0]: 2
535
32.10
;Send temperature: 32.04 deg.C
Before encryption: 8b e4 6a c5 01 50 00 06 68 14 21 90 80 00 00 00
After encryption:  99 5b 17 96 d4 50 34 25 42 00 b9 23 af 0d 26 54
tmp[0]: 24 , tmp[0]: 2
536
a▒tmp[0]: 25 , tmp[0]: 2
537
a▒tmp[0]: 25 , tmp[0]: 2
537
32.22
;Send temperature: 32.20 deg.C

Open points / questions:
  • The function onewire_get_temperature is called more than once between two sending processes. See debug output.
  • The code doesn't differentiate between DS18S20/DS1820 and DS18B20.
  • Measuring negativ temperature works also, but something in FHEM went wrong. See attachment.
  • How can i use here in onewire.c the function printSigned?
  • Is it not better to use for every sensor a own file an decide in onewire.c depending on the 8-BIT FAMILY CODE the right sensor. If there are more sensors avaiable, it is also possible to exclude the not needed sensors.
  • Is it possible or planned to use this like a one-wire bus or to connect more than one DS18x20 sensors?


Attached Files Thumbnail(s)
   
#12
I've already started implementation yesterday and it's nearly finished. Please wait some days, I'll submit it when I'm done testing.
#13
DS18B20 support is now tested and submitted to the repo. If you find any bugs, let me know.

Another question came up: How should the sensor be called in smarthomatic primarily (e.g. the e2p configuration)? The DS18B20 seems to be much more popular / common than the DS18S20. The DS1820 seems to be the original, old model, which is no longer produced. So DS1820 is not a generic term for both DS18S20 and DS18B20, but a different sensor.

I suggest to call it DS18B20. Other opinions?
#14
(02-02-2015, 03:50 AM)breaker27 Wrote: suggest to call it DS18B20. Other opinions?
AFAIR it is called DS18x20 in the Ethersex and some other projects, because all different sensors are supported and distinguished by the first byte of the serial, the family code. Besides that I have some DS18B20 which are labeled DS1820 only, so somebody without knowledge about the correct type may have a sensor, looking at the label and not knowing what to put in E2P because of incorrect labeling.
And I havent looked at the actual development firmware, is it possible to have different sensor types connected to the 1W bus?
#15
(02-02-2015, 03:50 AM)breaker27 Wrote: DS18B20 support is now tested and submitted to the repo. If you find any bugs, let me know.

The test with positve temperatures works. But i've already the problem that negative temperatures in FHEM are not right.

(02-02-2015, 03:50 AM)breaker27 Wrote: I suggest to call it DS18B20. Other opinions?

I think also DS18x20 is ok.

For me it would also be nice to have the possibilty to connect more then one DS18B20 or other sensor types to the 1-wire bus.

Thanks for the first 1-wire implementation.


Attached Files Thumbnail(s)
   
#16
(02-05-2015, 05:18 AM)cfi Wrote: The test with positve temperatures works. But i've already the problem that negative temperatures in FHEM are not right.

Seems it's time for me to make another test in my refrigerator. Rolleyes Thanks for the info, I'll test and fix it.

Inhumierer Wrote:is it possible to have different sensor types connected to the 1W bus?

Only one at a time, but it detects the different type already.

Quote:I think also DS18x20 is ok.

OK, I'll change this as well.

Quote:For me it would also be nice to have the possibilty to connect more then one DS18B20 or other sensor types to the 1-wire bus.

Noted, but this is for a version after 0.9.0. I want to release the 0.9.0 if possible this weekend.
#17
The issue with negative temperatures using the DS18B20 sensor is hopefully fixed now.
#18
(02-08-2015, 06:38 AM)breaker27 Wrote: The issue with negative temperatures using the DS18B20 sensor is hopefully fixed now.

The temperature error is not fixed in FHEM. In the line SHC1_RAWMSG is the Temperature=-16.47 in my refrigerator, but in the FHEM readings it is already 638.89
#19
I added your raw message with the -85.81 degrees to the SHC_parser_test.pl script. It shows

Code:
SenderID: 21
MessageTypeName: Status
MessageGroupName: Weather
MessageName: Temperature
MessageData: de7b00000000
Temperature: -85.81

I see no error. Also my outdoor sensor sends negative temperatures, and I have no problem in FHEM showing them.

Are you sure you use all the newest files in FHEM?
I don't know how to debug it further, since it's correct both in my running fhem instance (on linux) and with the test script (on windows).
If it still persists, could you add debug output in "37_SHCdev.pm" where it reads the temperature value?

Code:
when ('Weather') {
      given ($msgname) {
        when ('Temperature') {
          my $tmp = $parser->getField("Temperature") / 100;    # parser returns centigrade

          readingsBulkUpdate($rhash, "temperature", $tmp);
        }
#20
An update check in FHEM show's not anything with SHC.

I've tried this. Is seem that the SHC_parser returns the wrong value:

Code:
when ('Weather') {
      given ($msgname) {
        when ('Temperature') {

          my $tmp = $parser->getField("Temperature") / 100;    # parser returns centigrade
          my $xtmp = $parser->getField("Temperature");  

          readingsBulkUpdate($rhash, "temperature", $tmp);
          readingsBulkUpdate($rhash, "xtemperature", $xtmp);

Quote:temperature 638.3 2015-02-08 19:46:05
xtemperature 63830 2015-02-08 19:46:05


Forum Jump:


Users browsing this thread: 1 Guest(s)