Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Mysensor TempHum Error #276

Closed
Spugna85 opened this issue Dec 29, 2015 · 16 comments

Comments

Projects
None yet
7 participants
@Spugna85
Copy link
Contributor

commented Dec 29, 2015

Hi,
I have a Mysensor physical node (Arduino) with 6 sensor DHT22.
So I have 12 values, 6 temperature and 6 humidity, so listed:
-Sensor0 (ID=0501): H0 (IDCHILD = 0), T0 (IDCHILD = 1)
-Sensor1 (ID=0503): H1 (IDCHILD = 2), T1 (IDCHILD = 3)
-Sensor2 (ID=0505): H2 (IDCHILD = 4), T2 (IDCHILD = 5)
-Sensor3 (ID=0507): H3 (IDCHILD = 6), T3 (IDCHILD = 7)
-Sensor4 (ID=0509): H4 (IDCHILD = 8), T4 (IDCHILD = 9)
-Sensor5 (ID=050B): H5 (IDCHILD = 10), T5 (IDCHILD = 11)

Domoticz create 6 sensor (Model:Temp + Humidity, subtype:WTGR800).

Each update temperature (T0 to T5) correctly updates the sensor device in the table.
Example:
T0 updates the temperature of the first sensor (ID: 0501)
T1 updates the temperature of the second sensor (ID: 0503)
and so on...

While each update of humidity (H0 to H5) always updates the first sensor for the node.
Example:
H0 refresh the humidity of the first sensor (ID: 0501)
H1 refresh the humidity of the first sensor (ID: 0501)
and so on...

I think that the problem is that Domoticz use "IDCHILD" temperature as the sensor address for Model "Temp + Humidity" and uses the default 0 to update the humidity.

So, if I have more sensors, any humidity variation on one of them, generates an incorrect update of the first sensor and a missing update of another sensor.

What do you think?

@gizmocuz

This comment has been minimized.

Copy link
Contributor

commented Dec 29, 2015

Could you set the temp+hum both on the same child id, for all sensors?

DTH1: (child id 0 for both temp+hum)
DTH2: (child id 1 for both temp+hum)
...
DTH5: (child id 4 for both temp+hum)

@Spugna85

This comment has been minimized.

Copy link
Contributor Author

commented Dec 30, 2015

Now I just tried this:
Sensor0 (ID=0500): H0 (IDCHILD = 0), T0 (IDCHILD = 0)
Sensor1 (ID=0501): H1 (IDCHILD = 1), T1 (IDCHILD = 1)
...
Sensor5 (ID=0505): H5 (IDCHILD = 5), T0 (IDCHILD = 5)

And yet I can see the same behavior:
each update of humidity, always updates only the first sensor (in this case ID=0500).

Unfortunately, this solution does not seem to solve the problem :(

@gizmocuz

This comment has been minimized.

Copy link
Contributor

commented Jan 2, 2016

Looking at the code I can confirm this does not work....
Maybe we should make a function that checks for a temp (or hum) or (baro) close to the current child id
not so easy as It looks I think

@Spugna85

This comment has been minimized.

Copy link
Contributor Author

commented Jan 2, 2016

I can see that domoticz always assigns the "child id temp" to sensor "temp

  • hum". You could do a background check on receipt of an humidity update,
    if the child id equals "child id temp" - 1, you can assign it to the
    correct sensor. it's just an idea, maybe it is possible ... alternatively
    would be useful to recognize humidity and temperature sensors as 2
    different, what do you think?
    Il 02 gen 2016 1:27 AM, "gizmocuz" notifications@github.com ha scritto:

Looking at the code I can confirm this does not work....
Maybe we should make a function that checks for a temp (or hum) or (baro)
close to the current child id
not so easy as It looks I think


Reply to this email directly or view it on GitHub
#276 (comment).

@gizmocuz

This comment has been minimized.

Copy link
Contributor

commented Jan 2, 2016

it could be + or - one, but that's indeed what I was thinking about

@Sevift

This comment has been minimized.

Copy link

commented Jan 18, 2016

And what if
_tMySensorChild *pChildHum = FindChildWithValueType(pChild->nodeID, V_HUM, (pChild)->childName);

and

MySensorsBase::_tMySensorChild* MySensorsBase::FindChildWithValueType(const int nodeID, const _eSetType valType, const std::string childName)
...
for (itt = pNode->m_childs.begin(); itt != pNode->m_childs.end(); ++itt)
{
if (itt->childName == childName)

because
#define Location "qwerty"
gw.present( Motion_CHILD, S_MOTION, Location );
gw.present( Humidity_CHILD, S_HUM, Location );
Location it childName

@gizmocuz

This comment has been minimized.

Copy link
Contributor

commented Jan 18, 2016

That is if you name your nodes/childs, as is not the case for a lot of users

@guiguid

This comment has been minimized.

Copy link

commented May 5, 2016

Hi,
We can mix the both solutions above :
first : check for an indentical descrition (My sensor presentation code :
void present(uint8_t childSensorId, uint8_t sensorType, const char *description, bool ack);
with : description as an optional textual description of the attached sensor.

second : if first failed : increment an internal counter for each temp CHILD_ID, an merge HUM, BARO ... with the current internal temp CHILD_ID

Example:

My SENSOR :
present (IDCHILD = 0) TEMP, "SENSOR1"
present (IDCHILD = 1) TEMP
present (IDCHILD = 2) HUM
present (IDCHILD = 3) HUM, "SENSOR1"
present (IDCHILD = 4) TEMP
present (IDCHILD = 5) TEMP
present (IDCHILD = 6) HUM

DOMOTICZ :
-Sensor0 : TEMP (IDCHILD = 0), HUM (IDCHILD = 3) ( by description)
-Sensor1 : TEMP (IDCHILD = 1), HUM (IDCHILD = 2)
-Sensor2 : TEMP (IDCHILD = 4)
-Sensor3 : TEMP (IDCHILD = 5), HUM (IDCHILD = 6)

Feature :

  • no modification on MySensor protocol
  • don't break compatibility with old sensors
  • easy to code
@gizmocuz

This comment has been minimized.

Copy link
Contributor

commented May 5, 2016

you can not go out from a textual description, as this is not implemented in most sketch examples
... yes you can modify the sketches, but then you can also modify the sketches to solve problems

So i quess we should support this combination?

My SENSOR :
present (IDCHILD = 0) TEMP //temp sensor 1
present (IDCHILD = 1) TEMP //temp+hum sensor 1
present (IDCHILD = 2) HUM
present (IDCHILD = 3) TEMP //temp+hum sensor 2
present (IDCHILD = 4) HUM
present (IDCHILD = 5) TEMP //temp sensor 2
present (IDCHILD = 6) TEMP //temp+hum sensor 3
present (IDCHILD = 7) HUM
present (IDCHILD = 8) HUM //hum sensor 1
present (IDCHILD = 9) HUM //hum sensor 2
present (IDCHILD = 10) TEMP //temp sensor 3

If you agree, could you make a pull request ? (maybe create a mysensors test branch?)

@BmdOnline

This comment has been minimized.

Copy link
Contributor

commented Aug 31, 2016

Hi,

The goal is to add a group ID for each node's child (we can discuss for a good method, I'll explain mine below).
Then, when we need to find a child to combine with (FindChildWithValueType calls from SendSensor2Domoticz), we have to restrict this search to the group ID.

To do this, my method will be :
First, add "groupID" property in _tMySensorChild struct (MySensorsBase.h).
Then, when adding a new child in mNode.m_childs collection, we have to assign his groupID (see below).
Finally, we can use this groupID later, in FindChildWithValueType function. To do this, we have to add a new parameter to the function (called valGroup, identifying requested group).

The complex part is to identify groups.
Maybe later, we can add a new interface in MySensor Node setup to manually assign group. Maybe later...

For now, when reading childs from database (LoadDevicesFromDatabase), we only have to increment groupID when an sensor type already exists in current groupID.

For example :

present (IDCHILD = 0) TEMP  // groupID 1
present (IDCHILD = 1) TEMP  // groupID 2
present (IDCHILD = 2) HUM   // groupID 2
present (IDCHILD = 3) TEMP  // groupID 3
present (IDCHILD = 4) HUM   // groupID 3
present (IDCHILD = 5) TEMP  // groupID 4
present (IDCHILD = 6) TEMP  // groupID 5
present (IDCHILD = 7) HUM   // groupID 5
present (IDCHILD = 8) HUM   // groupID 6
present (IDCHILD = 9) HUM   // groupID 7
present (IDCHILD = 10) TEMP // groupID 7

Note : Childs 9 and 10 are presenting HUM before TEMP, but they are in the same group.

Another example :

present (IDCHILD = 0) TEMP, "SENSOR1" // groupID 1
present (IDCHILD = 1) TEMP            // groupID 2
present (IDCHILD = 2) HUM             // groupID 2
present (IDCHILD = 3) HUM, "SENSOR1"  // groupID 3
present (IDCHILD = 4) TEMP            // groupID 3
present (IDCHILD = 5) TEMP            // groupID 4
present (IDCHILD = 6) HUM             // groupID 4

Note : Childs 3 and 4 are presenting HUM before TEMP, HUM is named "SENSOR1", but they are in the same group.

Last example, with other sensors :

present (IDCHILD = 0) TEMP  // groupID 1
present (IDCHILD = 1) TEMP  // groupID 2
present (IDCHILD = 2) HUM   // groupID 2
present (IDCHILD = 3) WIND  // groupID 2
present (IDCHILD = 4) HUM   // groupID 3
present (IDCHILD = 5) TEMP  // groupID 3
present (IDCHILD = 6) RAIN  // groupID 3
present (IDCHILD = 7) WIND  // groupID 3
present (IDCHILD = 8) TEMP  // groupID 4
present (IDCHILD = 9) HUM   // groupID 4
present (IDCHILD = 10) TEMP // groupID 5

Note : RAIN, WIND and other sensors are treated exactly like TEMP, HUM...
We attach them to their respective groupID.
I think it's not a problem.

With this method, we have to determine groupID once when loading database. Then we don't have to repeat this work.
And later, we can imagine an interface for manual assign groupID and add them to database.

What do you think about this ?

@BmdOnline

This comment has been minimized.

Copy link
Contributor

commented Sep 4, 2016

Hi,

I have tried to implement it. Seems good.
I will verify my code and try to pull changes.

@handfreezer

This comment has been minimized.

Copy link

commented Sep 28, 2016

Hello,

What you've done is just amazing as I was looking for the way how groupID works in mysensors with hum and temp.

May I do a suggestion : as you are proposing to add an interface to change groupID, but not for now, could you just add a global option that unactivate grouping child_id for a MySensor Gateway (Serial or LAN)?

So, the result could be something like:
present (IDCHILD = 1) TEMP // groupID 1
present (IDCHILD = 2) HUM // groupID 2
present (IDCHILD = 3) HUM // groupID 3
present (IDCHILD = 4) TEMP // groupID 4

@BmdOnline

This comment has been minimized.

Copy link
Contributor

commented Sep 29, 2016

Hi,
I don't know enough domoticz code structure for improve MySensors configuration interface without side effect.
So, I prefer leave it.

Maybe gizmocus can add an option to enable / disable grouping.

@gizmocuz

This comment has been minimized.

Copy link
Contributor

commented Oct 2, 2016

This should already been taken care of... see the forum thread about mysensors/grouping
you have to adjust your id's

@gizmocuz gizmocuz closed this Oct 2, 2016

@jonasengs

This comment has been minimized.

Copy link

commented Dec 12, 2016

Hi!

Unfortunately this update doesn´t work very well with my setup.. As you can see in the picture the first are ok to group, but the rest need to be separated.

screen shot 2016-12-12 at 19 56 12

I´ve read the forum posts about grouping, but can´t find a method to get them separated.. How do I accomplish that?

regards

@jonasengs

This comment has been minimized.

Copy link

commented Dec 14, 2016

Answer to my question:
I found a workaround by naming all sensors v_hum - then they are placed in different groups and are possible to work with in domoticz...

I tried with v_var1 and v_voltage but they all ended up in the same groups.

I can see some solutions:

  • grouping would be triggered on all v_.. the same way as for v_hum and v_temp
  • be able to edit groups in the hardwaretab - seems to me that it would be possible in the same way that you can edit timeout now?

these are just suggestions, I have too little knowledge myself to make them real..

thanks for a super plattform! I feel som happy to get rid of vera and its stupid UI!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.