Supported Sensors

[FireWizard52]

@andrei-tatar

Currently the SmartNora "Sensor" node supports Temperature and/or Humidity. What is your opinion about extending this Sensor Node with other sensors, as presented at: https://developers.google.com/assistant/smarthome/traits/sensorstate

1. Does there exist a particular interest to have these sensor types added?
2. If so, should the existing SmartNora sensor node be used or should an additional node be created?

Interested in your opinion or any other thoughts about it.

Regards

[andrei-tatar]

@FireWizard52 the backend already supports all the sensor types (https://github.com/andrei-tatar/nora-firebase-common/blob/ca0f3e2ab4fa71e4d26c1f71293d13b9ee8b5958/src/device.ts#L349)

The node-red node hasn't been extended yet to support them as there's not much interest and temperature/humidity is the most common use case. Which one are you interested in?

[rgerrans]

I'd love to have contact sensors (open/close) included. Thanks

[FireWizard52]

Hello @andrei-tatar

As we will get new building legislation at July 1st 2022 in The Netherlands and part of this legislation is, that it will become mandatory to install smoke alarms on, at least, every floor, also in existing houses, built before 2003. In new to build houses it is not a problem, as tubes and wires will be installed. However old houses do not have these facilities pre-installed and so many of these new smoke alarms will be wireless and battery powered.

So I'm most interested in SmokeLevelSensorSupport. But in addition people also might be interested in CarbonMonoxideSensorSupport.

As I currently also use environmental sensors the following are interesting as well:

• AirQualitySensorSupport
• WaterLeakSensorSupport
• RainDetectionSensorSupport
• CarbonDioxideLevelSensorSupport
• ParticulateMatterSensorSupport

For me, these are the most interesting ones. I do not not have any idea, how much time will be involved to implement these sensors or even to implement them all.

As @rgerrans said: Open/Close or On/Off is very interesting to have implemented as this is a common application.

Unfortunately, I have insufficient knowledge of the SmartNora internals to support you in programming, but for things like testing, etc I'm happy to support you.

Best regards

[andrei-tatar]

Ok, I'll try to extend the sensor node so that it supports the other sensor types as well. Though it might be easier to have separate nodes for them so that the payload is not very complex.

How would you see the input payload format for one of them or a combination of them?

I guess on/off, open/close sensors are straight forward, the others are a bit more complex as the state is stored in google home as an array... Not sure if we want to be passing arrays as payload.

[andrei-tatar]

For example for Smoke Level sensor, the state would be: A state string with any of the values: smoke detected or high or no smoke detected. It could also have a number to indicate a value in parts per million.

[rgerrans]

For simplicity of pallet, my vote would be a single node with the various sensor types handled by payload values, though given your example above I could see where that could get to be a mess of sub-values...

[FireWizard52]

@andrei-tatar,

You asked:

How would you see the input payload format for one of them or a combination of them?

Personally I would prefer the same type of payload as the other sensors. The input payload for, both, the Temperature and the Humidity are an Object, with a key/value pair. For consistency I would prefer that.

For example for Smoke Level sensor, the state would be: A state string with any of the values: smoke detected or high or no smoke detected. It could also have a number to indicate a value in parts per million.

I would prefer that and both the "state string" (Descriptive Capabilities), if supported and the numerical value (Numeric Capabilities), if supported, can be part of the Object.

Remark: you did not mention for the Smoke Level the "state string" "unknown. We should not forget that state.

As we had a discussion in July, (See: https://github.com/andrei-tatar/node-red-contrib-smartnora/issues/64), I would also suggest that regarding the numerical values, if supported, both string an number are accepted.

the others are a bit more complex as the state is stored in google home as an array... Not sure if we want to be passing arrays as payload.

Is it? As far as I see it is only the sensorStatesSupported, and currentSensorStateData that should be an array. Is it difficult to move the Object into the array? For the sensorStatesSupported, I suggest to send al possible values, to avoid to have to change it later, if someone comes with a new state.

I think that the examples are quite clear.

Examples

Sensor device that reports descriptive state value.

{ "currentSensorStateData": [ { "name": "AirQuality", "currentSensorState": "healthy" } ] }

Sensor device that reports numeric state value.

{ "currentSensorStateData": [ { "name": "CarbonMonoxideLevel", "rawValue": 200 } ] }

Sensor device that reports descriptive and numeric state value.

{ "currentSensorStateData": [ { "name": "SmokeLevel", "currentSensorState": "smoke detected", "rawValue": 200 } ] }

What are your thoughts,

Regards,

Herman

[andrei-tatar]

So the sensor node could be any combination of sensor types (temperature/humidity/air quality/smoke/etc.). The input payload format right now is: { online?: boolean; temperature?: number; humidity?: number; }

if we're updating the smoke state, do we want to send { "name": "SmokeLevel", "currentSensorState": "smoke detected", "rawValue": 200 } ?

I guess the simplest value would be to allow the sensor type to only be one of the following (and not a combination):

• temperature/humidity
• on/off
• smoke
• air quality
• etc.

In that case, the payload could be:

{
online?: boolean;
temperature?: number; - only if temp/humidity sensor
humidity?: number; - only if temp/humidity sensor
state?: string; - if sensor supports a state string
value?: number; - if sensor supports a raw numeric value
}

I guess we can keep the above payload for multiple sensor types in the same node, but that would mean sending multiple messages to update the state for all the sensor types.

[FireWizard52]

@andrei-tatar

You wrote:

So the sensor node could be any combination of sensor types (temperature/humidity/air quality/smoke/etc.). The input payload format right now is: { online?: boolean; temperature?: number; humidity?: number; }

No, I don't think so. I think you have to select the type of sensor.

Currently you have chosen to combine the Temperature and the Humidity. In the current sensor you can select "Temperature" or "Humidity" or both, by means of activating the corresponding checkbox.

If we want to include more sensor types, you have to decide whether to create new node(s) for the sensor types or to expand/modify the current sensor node.

From a end user point of view, I think it is more logical to expand and to modify the node, than to create new nodes, which will also represent sensors.

However I do not have enough knowledge of the SmartNora and/or Node RED internals in order to give a recommendation on that. One method may be far more complex than the other or even impossible..

I would love to see one "Sensor" node covering all. I think you should replace the check boxes for Temperature and Humidity and to replace them for a Drop-Down List, where you also can include the other sensors, like on/off, smoke, air-quality, etc. Include them all for the moment and this solutions is also easy expandable, if e.g. more sensors will be introduced by Google. I believe this is a similar approach as use in the "Media" node for " Device Type"

if we're updating the smoke state, do we want to send { "name": "SmokeLevel", "currentSensorState": "smoke detected", "rawValue": 200 }

Yes, that is okay, if the sensor type (in the drop-down list) equals Sensor Type "Smoke Level".

Whether we want to use combinations of several sensors, I have my doubts. This will make it more complex. Perhaps only Temperature and Humidity, as we have that today already. but if you have multiple sensor, you can also have multiple nodes. If you do not choose to go for combined sensors, users, those, who currently use Temperature and Humidity, have to split it into 2 nodes, one for Temperature and one for Humidity. Would be perfect and clear for me, but I have no idea what the opinion of other users is.

I guess we can keep the above payload for multiple sensor types in the same node, but that would mean sending multiple messages to update the state for all the sensor types.

That depends on, if we want combinations. Not if we use a drop-down list for the type of sensor. But, as said, I have no clue about the complexity.

What do you (and others) think.

Best regards,

Herman

[andrei-tatar]

No, I don't think so. I think you have to select the type of sensor.

Yes, but that is the format. ? to a property name means it's optional. So yes, after you select temperature and/or humidity, that is the format of the input payload.

That depends on, if we want combinations. Not if we use a drop-down list for the type of sensor.

I would like combinations. The single reason I think these would be good is that if you have 5 different sensors in a room, they will appear as 5 shields in Google Home, cluttering the screen. Otherwise, there's no good reason to have a combination of them.

I guess this payload format would satisfy all conditions (@rgerrans - do you think we need an open percentage as well?):

{
online?: boolean;
temperature?: number; - only if temp sensor
humidity?: number; - only if humidity sensor
on?: boolean; - only if on/off sensor
open?: number or percentage; - only if open/close sensor 
state?: string; - if sensor supports a state string
value?: number; - if sensor supports a raw numeric value
name?: AirQuality | CarbonMonoxideLevel | SmokeLevel | etc. - required only if combinations of sensors configured - otherwise can be infered from the single sensor type that was chosen
}

[FireWizard52]

@andrei-tatar

I would like combinations. The single reason I think these would be good is that if you have 5 different sensors in a room, they will appear as 5 shields in Google Home, cluttering the screen. Otherwise, there's no good reason to have a combination of them.

Okay, but what do you mean with "if you have 5 different sensors in a room, they will appear as 5 shields in Google Home, cluttering the screen". Do you mean the screen of a Google Nest Hub (Max)? Or the screen of your smartphone if you open the Google Home app?

Currently I have in my Living Room 5 Lights, switched by Google Home, and so I have 5 Smart Nora "Lights" nodes and they show 5 shields on my Google Nest Hub, but they do not clutter the screen. They are nicely sorted. Why should 5 different sensors clutter the screen and why 5 different lights do not?

Regards,

Herman

[andrei-tatar]

Currently I have in my Living Room 5 Lights, switched by Google Home, and so I have 5 Smart Nora "Lights" nodes and they show 5 shields on my Google Nest Hub, but they do not clutter the screen. They are nicely sorted. Why should 5 different sensors clutter the screen and why 5 different lights do not?

In the Google Home app on Android, lights from the same room are grouped. I assumed sensors are not. Will have to check.

[FireWizard52]

Hi, @andrei-tatar

In the Google Home app on Android, lights from the same room are grouped.

Now I understand , what you mean. Yes you are right.

In this example the "Living Room (Woonkamer) has 10 lamps.

And indeed, sensors and other devices are not grouped in a similar way. But you may wonder, how many sensors a single room will have. Some temperature perhaps, 1 smoke alarm. In general I don't think that many. But you are right, the more devices (sensors) the longer the list.

Regards,

Herman

[andrei-tatar]

I think the best way for now is to adapt the node to support only one sensor type from the sensor trait, but in combination with temperature/humidity/open-close. I think I can get a first version out this week.

[github-actions[bot]]

This issue is stale because it has been open for 14 days with no activity.

[andrei-tatar]

Still working on the PR, not stale. :)

[melkati]

I'm also interested in support for more sensors (all kinds, as Air Quality/CO2)

[andrei-tatar]

First version of sensor state support released in version 1.6.0. Let me know if any issues are found.

[melkati]

First version of sensor state support released in version 1.6.0. Let me know if any issues are found.

Hi.

Thank you very much for adding support for sensors.

I tried to add one sensor of type Carbon Dioxide Level. The problem is, when I select "Sensor" and type "Carbon Dioxide Level" from the drop-down list it looks like it doesn't persist and returns fo the default option (Air Quality) when I open de node configuration dialog again. The node status shows Device Invalid most of the times.

I can see sometimes it says connected, but not always:

I can see sometimes it says connected, but not always.

This is how the node is configured:

This is the flow I'm trying to test (receive the Carbon Dioxide Level via MQTT as string and a function to convert that string to int, value = parseInt(msg.payload))

Here is the flow source where I can see '"sensorType": "CarbonDioxideLevel"' so it looks to me like the option gets saved.

[
    {
        "id": "6dacd4156476bdfc",
        "type": "noraf-sensor",
        "z": "f59e1d52c864f854",
        "devicename": "SCD30",
        "roomhint": "Despacho",
        "name": "SCD30",
        "temperature": false,
        "unit": "C",
        "humidity": false,
        "passthru": false,
        "nora": "50d2cd6f27988998",
        "topic": "",
        "filter": false,
        "sensorSupport": true,
        "sensorType": "CarbonDioxideLevel",
        "sensorStates": [],
        "sensorNumeric": false,
        "x": 900,
        "y": 1080,
        "wires": []
    },
    {
        "id": "d284329b462ab727",
        "type": "mqtt in",
        "z": "f59e1d52c864f854",
        "name": "",
        "topic": "SCD30/co2",
        "qos": "2",
        "datatype": "auto",
        "broker": "c20c2d62.588f4",
        "nl": false,
        "rap": true,
        "rh": 0,
        "inputs": 0,
        "x": 490,
        "y": 1080,
        "wires": [
            [
                "bf4f77cbf04998dd",
                "5e3549cd7b191f97"
            ]
        ]
    },
    {
        "id": "bf4f77cbf04998dd",
        "type": "debug",
        "z": "f59e1d52c864f854",
        "name": "",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 670,
        "y": 1040,
        "wires": []
    },
    {
        "id": "5e3549cd7b191f97",
        "type": "function",
        "z": "f59e1d52c864f854",
        "name": "",
        "func": "value = parseInt(msg.payload);\nmsg.payload = value;\nreturn msg;",
        "outputs": 1,
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [],
        "x": 700,
        "y": 1080,
        "wires": [
            [
                "6dacd4156476bdfc"
            ]
        ]
    },
    {
        "id": "50d2cd6f27988998",
        "type": "noraf-config",
        "name": "nora config",
        "group": "",
        "twofactor": "off",
        "twofactorpin": "",
        "localexecution": true,
        "structure": "Casa"
    },
    {
        "id": "c20c2d62.588f4",
        "type": "mqtt-broker",
        "broker": "192.168.1.145",
        "port": "1883",
        "clientid": "",
        "usetls": false,
        "compatmode": true,
        "keepalive": "15",
        "cleansession": true,
        "birthTopic": "",
        "birthQos": "0",
        "birthPayload": "",
        "willTopic": "",
        "willQos": "0",
        "willPayload": ""
    }
]

btw: I already paid my subscription. I think it's worth it 😀
My user id is vlsVN7zMnRTwLXn62SbmK28HbzQ2

[andrei-tatar]

I will have a look. I mostly tested with AirQuality sensor

btw: I already paid my subscription. I think it's worth it 😀

Thanks for the support

LE: published version 1.6.1 which should address the issue

[Wireheadbe]

Since version 1.6.1 - I get the following when trying to open the configuration of a pre-existing sensor that was in 1.5.1: Uncaught TypeError: Cannot read properties of undefined (reading 'states') at HTMLSelectElement. (:141:43) at HTMLSelectElement.dispatch (vendor.js?v=2.1.4:2) at HTMLSelectElement.v.handle (vendor.js?v=2.1.4:2) at Object.trigger (vendor.js?v=2.1.4:2) at HTMLSelectElement. (vendor.js?v=2.1.4:2) at Function.each (vendor.js?v=2.1.4:2) at s.fn.init.each (vendor.js?v=2.1.4:2) at s.fn.init.trigger (vendor.js?v=2.1.4:2) at t (red.min.js?v=2.1.4:18) at R (red.min.js?v=2.1.4:18)

[andrei-tatar]

Oops :( Will fix it during the weekend.

[Wireheadbe]

No problem ;) Enjoy the weekend ;)

[andrei-tatar]

Since version 1.6.1 - I get the following when trying to open the configuration of a pre-existing sensor that was in 1.5.1

Should be fixed in 1.6.2!

[Wireheadbe]

Awesome - thanks!

[andrei-tatar]

v1.6.3 comes with support for on/off and open/close sensors (@rgerrans)

[melkati]

Hi.

As continuation on my previous post.

I tried "Carbon Dioxide Level" sensor with new version v1.6.3 and I think it's not working fine.

The GUI is now working as it should but I think it's not sending values. I can't get Google Assistant to answer with this value (may be I don't know the exact phrase to ask) but also the value "S" stays at 0 as you can see in this image:

This is the flow I'm using:

[{"id":"836ac47e1d0df607","type":"comment","z":"f59e1d52c864f854","g":"85fd2dc7e016b15f","name":"CO2 Despacho","info":"","x":120,"y":1180,"wires":[]},{"id":"d284329b462ab727","type":"mqtt in","z":"f59e1d52c864f854","g":"85fd2dc7e016b15f","name":"","topic":"SCD30/co2","qos":"2","datatype":"auto","broker":"c20c2d62.588f4","nl":false,"rap":true,"rh":0,"inputs":0,"x":110,"y":1220,"wires":[["bf4f77cbf04998dd","5e3549cd7b191f97"]]},{"id":"bf4f77cbf04998dd","type":"debug","z":"f59e1d52c864f854","g":"85fd2dc7e016b15f","name":"","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":130,"y":1280,"wires":[]},{"id":"87c5a2ae5858268e","type":"inject","z":"f59e1d52c864f854","g":"85fd2dc7e016b15f","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"762","payloadType":"num","x":330,"y":1280,"wires":[["5e3549cd7b191f97"]]},{"id":"5e3549cd7b191f97","type":"function","z":"f59e1d52c864f854","g":"85fd2dc7e016b15f","name":"","func":"value = parseInt(msg.payload);\nmsg.payload = value;\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":380,"y":1220,"wires":[["6dacd4156476bdfc"]]},{"id":"6dacd4156476bdfc","type":"noraf-sensor","z":"f59e1d52c864f854","g":"85fd2dc7e016b15f","devicename":"SCD30","roomhint":"Despacho","name":"SCD30","temperature":false,"unit":"C","humidity":false,"passthru":false,"nora":"50d2cd6f27988998","topic":"SCD30/co2","filter":false,"sensorSupport":true,"sensorType":"CarbonDioxideLevel","sensorStates":[],"sensorNumeric":false,"openCloseSupport":false,"openCloseDiscrete":false,"onOffSupport":false,"x":540,"y":1220,"wires":[]},{"id":"c20c2d62.588f4","type":"mqtt-broker","broker":"192.168.1.145","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"15","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","willTopic":"","willQos":"0","willPayload":""},{"id":"50d2cd6f27988998","type":"noraf-config","name":"nora config","group":"","twofactor":"off","twofactorpin":"","localexecution":true,"structure":"Casa","storeStateInContext":true}]

[andrei-tatar]

@melkati Can you try using msg.payload.value? That's the one that goes to the sensor trait. Keep in mind there could be multiple values (temperature/humidity) for the same sensor. I guess I could add an exception so that if the payload is number and there is a single numeric state (temperature/humidity/sensor state), send it to that one.

[melkati]

@andrei-tatar

It's working! Thank you very much.

I left here the flow I'm using for reference.

[ { "id": "d284329b462ab727", "type": "mqtt in", "z": "f59e1d52c864f854", "g": "85fd2dc7e016b15f", "name": "", "topic": "SCD30/co2", "qos": "2", "datatype": "auto", "broker": "c20c2d62.588f4", "nl": false, "rap": true, "rh": 0, "inputs": 0, "x": 110, "y": 1220, "wires": [ [ "a1c7bcabbd3a699d" ] ] }, { "id": "a1c7bcabbd3a699d", "type": "change", "z": "f59e1d52c864f854", "g": "85fd2dc7e016b15f", "name": "", "rules": [ { "t": "set", "p": "payload", "pt": "msg", "to": "$number(payload)", "tot": "jsonata" }, { "t": "move", "p": "payload", "pt": "msg", "to": "payload.value", "tot": "msg" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 340, "y": 1220, "wires": [ [ "6dacd4156476bdfc" ] ] }, { "id": "6dacd4156476bdfc", "type": "noraf-sensor", "z": "f59e1d52c864f854", "g": "85fd2dc7e016b15f", "devicename": "SCD30", "roomhint": "Despacho", "name": "SCD30", "temperature": false, "unit": "C", "humidity": false, "passthru": false, "nora": "50d2cd6f27988998", "topic": "SCD30/co2", "filter": false, "sensorSupport": true, "sensorType": "CarbonDioxideLevel", "sensorStates": [], "sensorNumeric": false, "openCloseSupport": false, "openCloseDiscrete": false, "onOffSupport": false, "x": 740, "y": 1220, "wires": [] }, { "id": "c20c2d62.588f4", "type": "mqtt-broker", "broker": "192.168.1.145", "port": "1883", "clientid": "", "usetls": false, "compatmode": true, "keepalive": "15", "cleansession": true, "birthTopic": "", "birthQos": "0", "birthPayload": "", "willTopic": "", "willQos": "0", "willPayload": "" }, { "id": "50d2cd6f27988998", "type": "noraf-config", "name": "nora config", "group": "", "twofactor": "off", "twofactorpin": "", "localexecution": true, "structure": "Casa", "storeStateInContext": true } ]

[github-actions[bot]]

This issue is stale because it has been open for 14 days with no activity.

[FireWizard52]

As the request is for filled and more or less all available sensors has been added and no further issues are open this issue can be closed.