OREGON V2 Protocol

Supported Brands

Currently Devices using the Oregon Protocol V2.1 are supported.
To display the correct device capabilities in the GUI, the corresponding options for the individual device have to be configured.
For details or requests please read/use the following pilight forum thread:
Thread-Oregon-THGR122NX
Until this protocol stack is integrated into the main pilight release, the updated development version is available at:
https://github.com/wo-rasp/pilight/tree/test_dev

List of supported device IDs The following list is an overview of implemented device_id's. If users have confirmed proper operation the status is set to Tested.

(*) Device was tested by users (+) Testing progressing The pilight daemon will log details of unknown device_id's in debug mode.

Config

{
"devices": {
   "TempSensTHGR122N": {
      "protocol": [ "oregon_21" ],
         "id": [{
            "device_id": 7456,
            "id": 3,
            "unit": 155
         }],
         "battery": 0,
         "humidity": 10.00,
         "temperature": 10.00
       }
   },
   "rules": { },
   "gui": {
      "TempSensTHGR122N": {
         "name": "Living_Room",
         "group": [ "Weather" ],
         "media": [ "all" ],
         "temperature-decimals": 2,
         "humidity-decimals": 1,
         "show-battery": 1,
         "show-temperature": 1,
         "show-humidity": 1
      }
   },
   "settings": {
   },
   "hardware": {
   },
   "registry": {
   }
}

The device_id specifies the type of the sensor and the attributes it handles.

The id defines the individual channel used, typically it is a switch on the backside of the device and can be set to 1, 2 or 3.

The code for the unit is randomly set by the device upon insertion of the battery.

The battery flag is set if the battery status is low.

Depending on the capabilities of the individual OREGON devices the following objects have to be defined as part of the protocol: temperature, humidity, uv, wind_dir, wind_speed, wind_avg, rain, rain_total, pressure.

Optional Settings

Protocol The Oregon V2.1 protocol driver decodes between 172 and 511 pulses like this:

929 918 1168 810 982 951 989 947 1004 972 996 950 997 945 998 953 995 967 987 966 990 971 978 983 965 968 994 984 976 965 980 969 980 509 454 1010 479 471 1018 467 476 1000 470 487 994 967 992 495 475 1000 943 1014 920 1030 460 498 993 469 463 1031 478 464 995 967 967 516 434 1054 446 490 972 532 414 1039 930 1028 908 1042 945 1022 902 1051 911 1035 902 1046 955 1006 436 509 962 530 419 1060 427 525 939 560 396 1048 1383 707 313 503 956 995 974 1018 915 537 411 1068 408 531 957 511 435 1064 880 1052 941 1030 429 534 932 1002 956 541 424 1044 892 1064 918 1030 431 521 944 1008 963 519 428 1061 894 1045 920 1035 430 517 951 551 415 1052 885 1058 907 1052 883 1075 926 1031 883 1056 910 1046 909 1047 891 1067 420 537 942 517 424 1059 907 1048 426 517 954 545 403 1083 865 1062 910 1047 424 527 945 545 434 1033 906 1061 412 522 946 1008 946 545 405 1067 888 1068 886 1070 405 533 957 528 444 1035 891 1054 901 1059 876 1067 438 540 937 519 421 1061 903 1073 866 1071 438 504 963 11018

 668 1032 932 1018 931 1027 921 1023 926 1037 917 1052 916 1017 924 1045 909 1045 906 1050 919 1026 918 1027 921 1028 928 1034 919 1031 925 1028 919 571 412 1053 447 498 951 553 411 1051 419 521 956 1012 942 520 422 1061 906 1056 877 1065 423 530 953 541 419 1050 423 522 944 1010 940 545 405 1066 420 546 935 534 414 1057 906 1049 885 1070 905 1052 880 1071 907 1047 902 1059 875 1072 423 540 936 521 422 1063 418 541 946 526 419 1055 903 1086 396 515 1034 931 938 1022 923 557 420 1044 420 540 940 526 418 1063 901 1053 884 1105 381 532 955 993 944 551 401 1074 894 1058 884 1078 405 545 934 1014 936 532 422 1081 870 1065 896 1064 410 527 939 554 395 1076 925 1046 869 1064 899 1067 873 1073 894 1060 876 1068 900 1060 877 1080 409 557 919 551 409 1058 879 1073 413 548 954 545 403 1083 865 1062 910 1032 394 530 954 528 418 1057 898 1064 409 559 910 1015 944 578 385 1066 887 1050 899 1062 414 528 942 552 398 1087 863 1075 895 1056 899 1060 415 592 907 533 408 1054 878 1073 903 1055 423 522 943 245520 3003352

The pulse stream uses the “Manchester Code” principle.

The first 32 pulses are the Pre-Amble, followed by 12 pulses of a fixed SYNC header, a varying length (88 to 172) of Payload Pulses and a varing length (16 to 80) of Post-Amble pulses, followed by:
- either a gap pulse with an approximate length of minimum 11000µS and a 2nd transmission starting with the 12 pulses of the fixed SYNC header
- or a 2nd transmission starting with the pre-Amble pulses
There is no footer, the transmission ends with a pause of unknown length.

The first step is to remove from this pulse stream the pre-/post-Amb pulses.

The second step is to extract from the remaining pulse stream the 8 to 22 nibbles of logical bits forming the payload of the data transmitted.

Depending on the device_id of the sensor, the decoded data is assigned to the JSON objects defined in config.json.

We can group the sequence of Payload Pulses into 4 bit nibbles forming the following groups A to G:

AAAA B CC D EEEE FFFFFFF GG HH

Each of the groups of nibbles (A to H) has a specific meaning:

So this code represents:

{
        "code": {
                "device_id": 7456,
                "id": 3,
                "battery": 1,
                "unit": 155,
                "temperature": 23.10,
                "humidity": 48.0
        },
        "origin": "receiver",
        "protocol": "oregon_21",
        "uuid": "0000-00-00-b4-46a46b",
        "repeats": 1
}

Literature Aforementioned information was taken from the following source: http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf, and http://www.osengr.org/WxShield/Downloads/OregonScientific-RF-Protocols-II.pdf and matches with the protocol driver implementation V1.25 or higher.