Skip to content
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Development
  3. Usage of Child IDs
  • Getting Started
  • Controller
  • Build
  • Hardware
  • Download/API
  • Forum
  • Store

Usage of Child IDs

Scheduled Pinned Locked Moved Development
8 Posts 5 Posters 4.1k Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Offline
    J Offline
    joshmosh
    wrote on last edited by
    #1

    I am confused about how to use child ids for sensors which deliver more than one values. Example: DHT22 (gives humidity and temperature) or power meter (gives watts and kWhs).
    In the examples I have seen: a different child id for each value (child id 1 for temp, child id 2 for hum) as well as the same child id for both values (child id 1 for watts and for kWhs as well). Are both methods ok ? Or is there a recommended way to assign child ids ? Or is one method not advisable ?
    Please enlighten me 😉
    Thank you very much in advance
    Josh

    1 Reply Last reply
    0
    • hekH Offline
      hekH Offline
      hek
      Admin
      wrote on last edited by
      #2

      You can find a table with the most common variables used for each sensor type here (see under presentation):

      http://www.mysensors.org/download/serial_api_15

      There isn't any law against using other variables/sensor-type but the controllers will most probably not support it.

      J 1 Reply Last reply
      0
      • hekH hek

        You can find a table with the most common variables used for each sensor type here (see under presentation):

        http://www.mysensors.org/download/serial_api_15

        There isn't any law against using other variables/sensor-type but the controllers will most probably not support it.

        J Offline
        J Offline
        joshmosh
        wrote on last edited by
        #3

        @hek said:

        You can find a table with the most common variables used for each sensor type here (see under presentation):

        http://www.mysensors.org/download/serial_api_15

        There isn't any law against using other variables/sensor-type but the controllers will most probably not support it.

        My confusion is not related to sensor types but to the assignment of child IDs. In the sketch example for DHT22, different child IDs are assigned to the temp value and the hum value of the same sensor (DHT22). In the example for the pulse energy meter, only a single child ID is assigned to the watt value and the kWh value.
        Somewhere in the general description it says that a child ID identifies (on a node with several sensors) a sensor. In my understanding that means that sensors providing more than one measurement values get assigned the same child ID for each value (example watts and kWh) they provide. The energy meter sketch reflect this view. What confuses me is the DHT22 sketch. There, two child ID are used, although it is the same sensor (DHT22).
        Both methods seem to work ? Are both methods (one child id vs. two) equivalent or is one of the methods "better" ?

        Thank you for a clarification
        Josh

        1 Reply Last reply
        0
        • T Offline
          T Offline
          TimO
          Hero Member
          wrote on last edited by
          #4

          Stumbled on that a week ago too. I don't see the difference either. Please enligthen me. :-)

          1 Reply Last reply
          0
          • hekH Offline
            hekH Offline
            hek
            Admin
            wrote on last edited by
            #5

            Ahh.. can understand the confusion. Even though the physical DHT contains both temp and humidity readings most controller distinguish between them (GUI vise).

            So it felt more natural to keep them separated when presenting and reporting readings on them to make it easier on for the controller plugin developers.

            1 Reply Last reply
            0
            • DwaltD Offline
              DwaltD Offline
              Dwalt
              wrote on last edited by
              #6

              How about the BMP085, one sensor, two child ids (temp, barometer) and three variable msg (temp, pressure, forecast):fearful:

              Veralite UI5 :: IBoard Ethernet GW :: MyS 1.5

              1 Reply Last reply
              0
              • J Offline
                J Offline
                joshmosh
                wrote on last edited by
                #7

                After some thinking (yes, I am able to 😉), this is the conclusion I came to.
                Put yourself in the shoes of a controller 😏. You have a node which tells you it has just one sensor (DHT22) attached. Wether it sends you a V_TEMP and a V_HUM with the same child ID or with two different child IDs makes no difference to you. Since there is only one temperature sensor, the controller has no problem to see that V_HUM and V_TEMP belong to the same sensor and correlate them (to calculate a dew point for example).
                Now imagine that there are three DHTs (of course at three diferent locations) connected to the same node. Now the node sends six different child IDs (three pairs V_HUM / V_TEMP) to the controller. How can the poor controller find out, which two child IDs belong to the same sensor ? No way to find that out !
                So, my conclusion is, that it seems to be strongly advisable to use the same child ID for all values which are produced by a sensor. Makes life for a poor controller much easier 😜.

                Or is there a mistake in my thinking, which I have not seen yet ?
                Cheers
                Josh

                1 Reply Last reply
                0
                • JohnJ Offline
                  JohnJ Offline
                  John
                  Plugin Developer
                  wrote on last edited by John
                  #8

                  @joshmosh

                  When a node presents it's sensors it sends out child id's. So the controller knows which child id's exist. When values are send to the controller this is in combination with the sensor child id. So the controller knows which value belongs to which child id's exist.

                  If you then look at it pure from controller perspective it just sees multiple sensors. You can even put all your values within the same child id as long as the V_* types are unique used with that child id (do not use two V_TEMP values with the same child id).

                  My Domotica project: http://www.pidome.org

                  1 Reply Last reply
                  0
                  Reply
                  • Reply as topic
                  Log in to reply
                  • Oldest to Newest
                  • Newest to Oldest
                  • Most Votes


                  9

                  Online

                  11.7k

                  Users

                  11.2k

                  Topics

                  113.0k

                  Posts


                  Copyright 2019 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
                  • Login

                  • Don't have an account? Register

                  • Login or register to search.
                  • First post
                    Last post
                  0
                  • OpenHardware.io
                  • Categories
                  • Recent
                  • Tags
                  • Popular