• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register


Proposol "General Purpose Sensor" Protocol
#1
I would like to propose a protocol that is usable and used by home made sensors.

Every sensor can transmit a maximum of 7 different types of measurement (Channels). There are four characters to hold the units of measurement, for instance "Lux", "*C", "mV", "Volt", "Amps", "kWh" etc.

The protocol exists of 144 pulses that translate into 71 bit (first two pulses are the START and SYNC pulse).

Every bit consists of two pulses. A short START-pulse and a long(er) DATA-pulse.

The pulse-length of every pulse are in the table below:
Code:
Pulse Name    Duration in μ seconds
    START            250  
    SYNC            4500  
    Data ‘0’         900  
    Data ‘1’        1800  

A complete message has the following attributes:
Code:
Attribute Name    From   Till   Length     Description
---------------------------------------------------
Protocol ID         0       3       4      Always 12 (b1100)
Sensor ID           4      11       8      Identification of the sensor-module (0-255)
Channel            12      14       3      sub-ID of this sensor (0-7)
Battery state      15      15       1      ‘1’ = battery OK, ‘0’ = battery not OK
Payload            16      35      20      The actual payload as a two's complement 20 bit integer
Decimals           36      38       3      Number of decimal places (divide payload by 10^Decimals)
Label(chars)       39      70      32      Four character text
ParityBit          71      71       1      Modulo 2 of all the ‘1’ bits

A puls-train is 144 pulses long and starts with a START/SYNC pulse. Every pulse-train is transmitted at least 4 times.

Code:
(SYNC)      249 4392
(ProtoID)   276 1741 270 1739 270 854 276 877
(SensorID)  276 858 287 1797 226 1720 296 846 274 867 290 1722 273 854 279 876
(Channel)   271 858 271 1735 275 875
(Bat.State) 280 1783
(Payload)   260 907 247 864 273 881 277 1753 276 1756 278 854 276 891 261 865 283 1735 298 1720 293 858 277 1744 278 865 330 805 272 1735 276 866 275 1743 285 842 291 1723 298 1734
(Decimals)  283 841 276 1736 274 885
(Char-1)    285 847 278 1736 289 1734 281 869 277 1734 277 845 285 856 276 888
(Char-2)    277 857 277 1748 281 851 285 1733 277 850 277 867 277 846 293 871
(Char-3)    275 863 290 1735 287 1733 284 844 279 894 254 844 283 857 278 1753
(Char-4)    316 832 296 845 281 865 313 817 280 858 276 848 279 861 277 870
(Parity)    286 1755
(SYNC)      261 4373 (start next transmission)

This raw output translates into:

Code:
110001100100010100011000110100101011010011010000101000001100001000000001
--12-----100--21--------------101675--2-------h-------P-------a----null1

Code:
1100 01100100 010 1 00011000110100101111 010 01101000 01010000 01100001 00000000 0

Code:
Protocol ID:   1100                  12 (check!)
SensorID:      01100100              100
Channel:       010                   2
Battery State: 1                     1
Payload:       00011000110100101111  101679
Decimals       010                   2 = 10^2 = 100 => payload / 100 = 1016.79
Char-1         01101000              h
Char-2         01010000              P
Char-3         01100001              a
Char-4         00000000              null
Parity         0                     26 % 2 = 0 (check!)

On the GUI the output shown should be something like:

Code:
HomeMadeSensor                     1016.71 hPa []
HomeMadeSensor                         400 lux []
where "[]" is the red/green battery icon
 
Reply
#2
Hi folks,

One problem I already have reading the "Protocols" manual is ...

What kind of device is this???

It is possible to create a "General Purpose Sensor" device type?
Can I do that myself or is this something for the more experienced developers...

Regards
 
Reply
#3
Just adapt the generic_weather protocol with 433MHz receiving logic and all the settings you want Smile
There is a device type called WEATHER, which is what you are looking for.
 
Reply
#4
(06-28-2016, 03:01 PM)pilino1234 Wrote: Just adapt the generic_weather protocol with 433MHz receiving logic and all the settings you want Smile
There is a device type called WEATHER, which is what you are looking for.
Thanks for your reply.
The point is this is not a weather device (although it can be). It can give all kind of sensor-data as, for instance, movement, speed, height, light and so on.
And then in the GUI it must display the payload-value, but also the four char's that gives the units of measurement.
Can that all be incorporated with the weather-type?

If so I will use the alecto_ws1700 protocol as an example.

Regards
 
Reply
#5
Besides the protocol there are several more issues to be addressed.
1.GUI related
The toolset supports the following values and icons: Temperature, Humidity, Rain, Wind, Pressure, Battery
2. Config.json
Handling of mandatory and optional configuration parameters
 
Reply
#6
(06-29-2016, 09:28 PM)wo_rasp Wrote: Besides the protocol there are several more issues to be addressed.
1.GUI related
The toolset supports the following values and icons: Temperature, Humidity, Rain, Wind, Pressure, Battery
2. Config.json
Handling of mandatory and optional configuration parameters

Thanks for pointing that out.
I know those issues has to be addressed, if we follow the road of the weather protocols.
Point for the General Purpose Sensor protocol is that they are far to limited.
The protocol can measure everything you can think of. It does not need icons (except for the battery icon) because it sends the unit of measurement as part of the protocol. As for the json configuration it only needs the ID and a Channel (as one sensor can transmit as much as 7 (types of) measurement). The reply values in the config are "Value", the 4 chars with the units of measurement and number of decimal places to display in the GUI.

Thats why I think we need a special type for this type of devices.

Having said all that I think I can create the protocol handler from, for instance, the ws1700 protocol, but I have no clue how the display the four char's that shows the unit of measurement on the GUI.

So, I do need help to implement this type of sensor protocol for pilight. On the bright side I have an Arduino (actually an AVR) library to build this type of home made sensors with that I will place on github soon.
 
Reply
#7
The interface to the GUI is via the JSON objects defined in config.json. Based on the devicetype, defined in the protocols init() function of each protocol handler, the WEBGUI application reads the values of various json objects and displays them in accordance to the GUI settings.

To avoid wear of the SD card, config.json does not get constantly updated, but only at proper shutdown of the pilight daemon.

Enter the following URL, to get an idea of the above:
- http://ip:5001/config
- http://ip:5001/values

Communication between pilight instances in a distributed environment is pretty inefficient using the protocol interface, as there is an efficient "adhoc" network interface implemented, but I agree it would be beneficial to add to the generic protcols the RF interface modules using a standardized pilight pulsestream. My proposal would be to call those modules generic_devicetype_RF.c

In my opinion another suitable approach would be to always implement the RF transmit/receive functionality to all protocols,  so that pilight will not only be able to receive data for example from temperature sensors, but that pilight can also act as a temperature sensor, thus that it could act as a gateway between a remote sensor and a weatherstation by forwarding received data to an external weatherstation. (I did that originally for the ninjablocks protocol, you can find that unmaintained version still in my repository, it will give you an idea on what has to be added to a protocol module).
 
Reply
#8
(06-30-2016, 08:07 AM)wo_rasp Wrote: The interface to the GUI is via the JSON objects defined in config.json. Based on the devicetype, defined in the protocols init() function of each protocol handler, the WEBGUI application reads the values of various json objects and displays them in accordance to the GUI settings.

In my opinion another suitable approach would be to always implement the RF transmit/receive functionality to all protocols,  so that pilight will not only be able to receive data for example from temperature sensors, but that pilight can also act as a temperature sensor, thus that it could act as a gateway between a remote sensor and a weatherstation by forwarding received data to an external weatherstation. (I did that originally for the ninjablocks protocol, you can find that unmaintained version still in my repository, it will give you an idea on what has to be added to a protocol module).
wo_rasp, to be honest; I do not understand half of what your writing (which is totally on me!). 
If I understand it correctly: If I define in the init() part of the protocol function an array of 4 chars (5 with a "\0" at the end), they will automatically and magically be displayed in the GUI?
Where can I find your repository to look for the ninjablocks protocol? (the web activity on developing ninjablocks has come to a standstill has it not?)
 
Reply
#9
I need more help already....

In a previous post I showed the actual pulse lengths of the protocol definition and the pulse-length's as pilight-receive sees them.

Now, for the protocol implementation I have no clue as what values the following constants should have:

Code:
PULSE_MULTIPLIER 12  // To define the minimum time of a HIGH pulse
MIN_PULSE_LENGTH 120 // Times 34 is the shortest SYNC to react upon
AVG_PULSE_LENGTH 250 // Multiply by PULSE_MULTIPLIER / 2 = HIGH or '1'
MAX_PULSE_LENGTH 150 // Times 34 is the longest SYNC to react upon
RAW_LENGTH 146       // this is the number of pulses right .. more or less?

So, after placing a lot of log messages into the gpsensor.c file I found out that:

PULSE_MULTIPLIER is used to define the lower time limit of a HIGH ('1') pulse. I have set it to 12 as 250 * 12 / 2 = 1500. 

MIN_PULSE_LENGTH and MAX_PULSE_LENGTH is the bandwidth of the SYNC pulse divided by 34. I have set them to 120 and 150 respectively so my gpsensor will react on a SYNC pulse between (120 x 34) 4080 and (150 x 34) 5100 (microseconds).

The AVG_PULSE_LENGTH is multiplied by PULSE_MULTIPLIER/2 to define a HIGH ('1') pulse. I have set it to 250 so if the pulse-length is greater than 250 * 12 / 2 = 1500 it's a '1'; otherwise it's a '0'!

RAW_LENGTH is a bit confusing. If the pulse-train consists of 71 bit and every bit is 2 pulses I would expect a RAW_LENGTH of 142 or, if you count the SYNC in front as being the header or leadin, or for the SYNC of the next train as being a trailer, than 2 more pulses, so 144. 
The protocol seems to work with a RAW_LENGTH of 146 which I cannot explain....

With the information in my first post, what should the values are?

Is someone willing to confirm?

Regards
 
Reply
#10
It is getting somewhere!!!
pilight rocks!!

Ok, I have the gpsensor.c and gpsensor.h in place.

It does receive the sensor data! I have 1 sensor-module that measures temperature, pressure and battery voltage.
Code:
--
"message": {
        "id": 100,
        "channel": 2,
        "battery": 1,
        "sensorvalue": 1010.39,
        "munit": "hPa"
},
"origin": "receiver",
"protocol": "gpsensor",
"uuid": "0000-b8-27-eb-048c50",
"repeats": 1
}
--
"message": {
        "id": 100,
        "channel": 2,
        "battery": 1,
        "sensorvalue": 1010.39,
        "munit": "hPa"
},
"origin": "receiver",
"protocol": "gpsensor",
"uuid": "0000-b8-27-eb-048c50",
"repeats": 2
}
--
"message": {
        "id": 100,
        "channel": 7,
        "battery": 1,
        "sensorvalue": 4973.00,
        "munit": "mV"
},
"origin": "receiver",
"protocol": "gpsensor",
"uuid": "0000-b8-27-eb-048c50",
"repeats": 1
}

Now I need these values (that is, the "sensorvalue" and the "munit" values) to appear in the GUI... and that is not yet working (as I expected).

Problem is: I have no Java or jQuery experience at all. 
Is there someone who can help me with this or point me in the right direction?
I would really appreciate that!!

Regards
 
Reply
  


Possibly Related Threads...
Thread Author Replies Views Last Post
  Oregon Protocol V2.1: THGR122NX jpoilux 210 87,037 05-07-2020, 10:28 AM
Last Post: Alomon
  [Fully Supported] KlikAanKlikUit Motion Sensor koen01 37 15,782 03-26-2020, 02:46 PM
Last Post: Gisto
  Digoo / Baldr / Nexus / Rubicson temperature/humidity sensor thielj 12 3,442 02-10-2020, 10:54 PM
Last Post: ha_username
  Support for Temperaturee sensor clona 4 597 02-10-2020, 02:52 PM
Last Post: clona
  FT007TH Thermo-/Hygrometer, Protocol: Alecto V3 sandnabba 1 534 12-12-2019, 09:40 PM
Last Post: sandnabba
  gs-iwds07 window sensor Loggisch 48 18,216 12-09-2019, 07:14 PM
Last Post: curlymo
Lightbulb [Fully Supported] Kaku Door sensor (AMST-606) geerttttt 53 29,270 10-19-2019, 06:26 PM
Last Post: curlymo
  433MHz PIR sensor from Amazon ha_username 0 798 09-29-2019, 11:44 PM
Last Post: ha_username
  missing protocol of "date_and_time" in Wiki/Protocols fleisch 3 743 08-03-2019, 06:10 PM
Last Post: curlymo
Brick Protocol for FT0073 drobskind 5 4,334 07-25-2019, 10:44 PM
Last Post: fireball

Forum Jump:


Browsing: 1 Guest(s)