Hello!

I've downloaded the 1.4.1 version of the library and tested it via OpenHab.
I'm still not getting the sketch_name correctly via MQTT and Openhab. Is it still an open bug?

Thanks!

Simon

I was quite sure the gateway (MQTTClient) was updated with latest API library, but I was wrong. It was on 1.5 version. Updated to the latest, the problem was solved. Hope it helps!

Simon

Ok, thanks all. Maybe it's a flag I've set on HomeAssistant on some variables and to delete them, it's not sufficient, reading the doc, to restart the mosquitto service. I'll look how delete message AND retain flag.
Thanks all!

Simon

@sundberg84 @hek ,

I've improoved the stability a lot with following modifications:

• I've applied the isolation on the NRF24L01+PA+LNA, moved away from the router and connected the Arduino 2009 with external source (no more power via USB)
• I've then changed the configuration of my chain sensors. Tracing the exact sequence of all nodes I've noticed that the last hop of all nodes with problems was a node that I'm using to monitor power usage. It reads from analog input via a "current clamp". This is taking a value every second and saves it in an array to make an average of 60 values. It gives not much time to this node to act well as repeater. Disabling the repeater feature the chain has broken and two nodes from the second room are now connected directly.

So, with those modifications I've seen big improovments.
I'll take a look in the next days (I'l start for holidays ) to check if it's stable as well.

BTW, I'm still confusing on how, when and why use these settings:

#define MY_RF24_PA_LEVEL RF24_PA_LOW
#define RF24_PA_LEVEL_GW RF24_PA_MAX

So, only to improove my knowledges

Thanks a lot!

Simon

@electrik said in Strange behavior on MQTT Gateway Reset:

@mfalkvidd said in Strange behavior on MQTT Gateway Reset:

MySensors does set the retain message on I_BATTERY_LEVEL messages (but no other messages)

If the define MY_MQTT_CLIENT_PUBLISH_RETAIN is used, all messages are retained. But that is not active by default, so probably not used in this case. Just to be complete

Thanks!
Well, I've succesfully deleted the retained messages via cli using mosquitto command:

mosquitto_pub -t <my_retained_topic> -r -n

Maybe it was set by the controller, then removed, but mqtt was retaining it.

Simon

Hello,

I've some problems updating from 2.0 to 2.1.
In my examples, I'm sending the node-id and the distance to my controller, to check which path is using my node.
Here the part of the code:

parentNode = _nc.parentNodeId;
distance = _nc.distance;
Serial.print(F("Node-id: "));
Serial.println(MY_NODE_ID);
Serial.print(F("Parent node id: "));
Serial.println(parentNode);
Serial.print(F("Distance Node00: "));
Serial.println(distance);

Now I'm getting this error:

error: '_nc' was not declared in this scope

How to get those values now?

Thanks

Simon

@mfalkvidd said in Best way to send nodeDistance and parentNode:

@xefil I've never seen anyone reuse a child ID, and I think it would confuse most controllers. Just look at the presentation call: first the sketch would present the child as type X, then the sketch would present the same child as type Y. Will the controller use the first, the second, both or none of the presentations?

But you may be right - maybe controllers can handle multiple data types per child id.

Well @mfalkvidd maybe it's me that I'm making confusion.
AFAYK, in case of HomeAssistant, it has an auto-discovery system which works, even if I don't like the naming convention it uses. BTW, using the above example, subscribing to MQTT server, I can get the values like follow:

api doc:
MY_MQTT_PUBLISH_TOPIC_PREFIX/FROM-NODE-ID/SENSOR-ID/CMD-TYPE/ACK-FLAG/SUB-TYPE

example message published on topic prefix mygateway1-out from node 28, on V_VAR1, which has id 24, becomes:

mygateway1-out/28/100/1/0/24

The same way, message published on topic prefix mygateway1-out from node 28, on V_VAR2, which has id 25, becomes:

mygateway1-out/28/100/1/0/25

This gives me the ability to subscribe on it and check for changes, like the logs shows me:

2018-12-31 08:37:09 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on mygateway1-out/28/100/1/0/24: b'0.0'
2018-12-31 08:51:09 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on mygateway1-out/28/100/1/0/25: b'1.0'

Looking deeper on what the controller recognize it during the presentation, using S_CUSTOM (id: 23) it's reassumed in this part of xml auto-generated:

    "28": {
        "protocol_version": "2.3.1",
        "battery_level": 0,
        "type": 18,
        "children": {
<code_snipped>
            "100": {
                "description": "Internal variables",
                "id": 100,
                "values": {
                    "24": "0.0",
                    "25": "1.0"
                },
                "type": 23
            }
        },
        "heartbeat": 0,
        "sketch_name": "node28Studio",
        "sketch_version": null,
        "sensor_id": 28
    },

So, actually the infos are correctly sent. It's more a matter if the usage of the IDs is correct to avoid further conflicts, if any.
That's the reason I'm asking

Thanks, Simon

Thank you!!

Simon

@mfalkvidd said in Best way to send nodeDistance and parentNode:

@xefil I've never seen anyone reuse a child ID, and I think it would confuse most controllers. Just look at the presentation call: first the sketch would present the child as type X, then the sketch would present the same child as type Y. Will the controller use the first, the second, both or none of the presentations?

But you may be right - maybe controllers can handle multiple data types per child id.

Well @mfalkvidd maybe it's me that I'm making confusion.
AFAYK, in case of HomeAssistant, it has an auto-discovery system which works, even if I don't like the naming convention it uses. BTW, using the above example, subscribing to MQTT server, I can get the values like follow:

api doc:
MY_MQTT_PUBLISH_TOPIC_PREFIX/FROM-NODE-ID/SENSOR-ID/CMD-TYPE/ACK-FLAG/SUB-TYPE

example message published on topic prefix mygateway1-out from node 28, on V_VAR1, which has id 24, becomes:

mygateway1-out/28/100/1/0/24

The same way, message published on topic prefix mygateway1-out from node 28, on V_VAR2, which has id 25, becomes:

mygateway1-out/28/100/1/0/25

This gives me the ability to subscribe on it and check for changes, like the logs shows me:

2018-12-31 08:37:09 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on mygateway1-out/28/100/1/0/24: b'0.0'
2018-12-31 08:51:09 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on mygateway1-out/28/100/1/0/25: b'1.0'

Looking deeper on what the controller recognize it during the presentation, using S_CUSTOM (id: 23) it's reassumed in this part of xml auto-generated:

    "28": {
        "protocol_version": "2.3.1",
        "battery_level": 0,
        "type": 18,
        "children": {
<code_snipped>
            "100": {
                "description": "Internal variables",
                "id": 100,
                "values": {
                    "24": "0.0",
                    "25": "1.0"
                },
                "type": 23
            }
        },
        "heartbeat": 0,
        "sketch_name": "node28Studio",
        "sketch_version": null,
        "sensor_id": 28
    },

So, actually the infos are correctly sent. It's more a matter if the usage of the IDs is correct to avoid further conflicts, if any.
That's the reason I'm asking

Thanks, Simon

@electrik said in Strange behavior on MQTT Gateway Reset:

Great thanks for your feedback!

Thanks to you for the support and hints

I wish you a happy new year!

Simon

@electrik said in Strange behavior on MQTT Gateway Reset:

@mfalkvidd said in Strange behavior on MQTT Gateway Reset:

MySensors does set the retain message on I_BATTERY_LEVEL messages (but no other messages)

If the define MY_MQTT_CLIENT_PUBLISH_RETAIN is used, all messages are retained. But that is not active by default, so probably not used in this case. Just to be complete

Thanks!
Well, I've succesfully deleted the retained messages via cli using mosquitto command:

mosquitto_pub -t <my_retained_topic> -r -n

Maybe it was set by the controller, then removed, but mqtt was retaining it.

Simon

Hello @mfalkvidd ,

Wouldn't a problem, but why different child id?
Wouldn't ok child_id 100 (in example), with presentation S_CUSTOM and setting V_VAR1 for parentNode and V_VAR2 for distanceGW?
Why I need two different child id?

Thanks!

Simon

Thanks @TheoL .
Well, I'll try S_DISTANCE, but it's related to transportGetDistanceGW(); or to a distance sensor?
The transportGetDistanceGW(); gets the distance in HOP to the gateway. If "0", it means it doesn't use any repeater to reach the gateway. BTW under presentation section of the API, I don't know what to use for personal variables, not related to sensors. Maybe S_CUSTOM with V_VAR<x> ?

Simon

Hi all,

In my nodes I'm using this method to send to my controller the distance and the parentNode to the master.
I'm in doubt I'm using the correct presentation_ID. Here the snip of the code:

(...)
#define CHILD_ID_NODE 100
int parentNode;
int distance;
MyMessage msgNodeVar1(CHILD_ID_NODE, V_VAR1);
MyMessage msgNodeVar2(CHILD_ID_NODE, V_VAR2);
(...)

void presentation() {
(...)
  present(CHILD_ID_NODE, S_POWER);
(...)

void loop() 
{
(...)
    parentNode = transportGetParentNodeId();
    send(msgNodeVar1.set(parentNode, 1));
    distance = transportGetDistanceGW();
    send(msgNodeVar2.set(distance, 1));

This will create those informations available, via MQTT, on:
parentNode: mygateway1-out/<node_id>/100/1/0/24
distance: mygateway1-out/<node_id>/100/1/0/25

How would you present it?
I've this snip of code since 1.5. Meanwhile, updated to latest, the custom variables should be used.
I hit some warning on HomeAssistant telling me warnings like:

: sensor platform: node 20 child 100: S_POWER requires value_type V_WATT @ data[17]
: sensor platform: node 20 child 100: S_POWER requires value_type V_KWH @ data[18]
: sensor platform: node 20 child 100: S_POWER requires value_type V_VAR @ data[54]
: sensor platform: node 20 child 100: S_POWER requires value_type V_VA @ data[55]
: sensor platform: node 20 child 100: S_POWER requires value_type V_POWER_FACTOR @ data[56]

I think it's to set a correct presentation.

Let me know your opinion, thanks!

Simon

Ok, thanks all. Maybe it's a flag I've set on HomeAssistant on some variables and to delete them, it's not sufficient, reading the doc, to restart the mosquitto service. I'll look how delete message AND retain flag.
Thanks all!

Simon

Hello @electrik and @Yveaux ; thanks for the answers.
It's still not totally clear who is retaining those messages.
It's a mosquitto issue, an issue from the Controller (OpenHAB2 or HomeAssistant) or a driver issue from MySensors?
BTW, the last case, having updated the MQTT Mysensors gateway as well as the affected sensor leaf, I would discard this last option.
I need to understand as well how to read the debug messages from mosquitto. It doesn't contain the message value and have no idea if the retain flag is set or not I know that's a little off topic
Any further help is appreciated!

Happy Holidays!!

Simon

Hi all,

I'm noticing a strange behavior on my Mqtt Gateway Client. It was on 2.0 version, updated to latest AFTER noticing this strange behavior. As soon the MySensors MQTT Gateway client gets reset, I can see those log entries:

Mon Dec 24 15:52:52 2018: New connection from 192.168.1.51 on port 1883.
Mon Dec 24 15:52:53 2018: Client mysensors-1 already connected, closing old connection.
Mon Dec 24 15:52:53 2018: Socket error on client mysensors-1, disconnecting.
Mon Dec 24 15:52:53 2018: New client connected from 192.168.1.51 as mysensors-1 (c1, k15).
Mon Dec 24 15:52:53 2018: No will message specified.
Mon Dec 24 15:52:53 2018: Sending CONNACK to mysensors-1 (0, 0)
Mon Dec 24 15:52:53 2018: Received PUBLISH from mysensors-1 (d0, q0, r0, m0, 'mygateway1-out/0/255/0/0/18', ... (5 bytes))
Mon Dec 24 15:52:53 2018: Sending PUBLISH to home-assistant-1 (d0, q0, r0, m0, 'mygateway1-out/0/255/0/0/18', ... (5 bytes))
Mon Dec 24 15:52:53 2018: Received SUBSCRIBE from mysensors-1
Mon Dec 24 15:52:53 2018:       mygateway1-in/+/+/+/+/+ (QoS 0)
Mon Dec 24 15:52:53 2018: mysensors-1 0 mygateway1-in/+/+/+/+/+
Mon Dec 24 15:52:53 2018: Sending SUBACK to mysensors-1
Mon Dec 24 15:52:53 2018: Sending PUBLISH to mysensors-1 (d0, q0, r1, m0, 'mygateway1-in/28/1/1/0/2', ... (1 bytes))
Mon Dec 24 15:52:53 2018: Sending PUBLISH to mysensors-1 (d0, q0, r1, m0, 'mygateway1-in/28/255/3/0/6', ... (1 bytes))
Mon Dec 24 15:52:53 2018: Sending PUBLISH to mysensors-1 (d0, q0, r1, m0, 'mygateway1-in/20/1/1/0/2', ... (1 bytes))
Mon Dec 24 15:52:53 2018: Sending PUBLISH to mysensors-1 (d0, q0, r1, m0, 'mygateway1-in/30/1/1/0/2', ... (1 bytes))
Mon Dec 24 15:52:53 2018: Sending PUBLISH to mysensors-1 (d0, q0, r1, m0, 'mygateway1-in/30/255/3/0/6', ... (1 bytes))

I can simulate it with a manual reset as well. mysensors-1 is the MySensors MQTT Client.
So, why it's resetting is something I need to understand. Now, after update, seems more stable.
But what I cannot understand is why immediate after the reset, the MQTT MySensors Gateway is getting some publish commands. One of this atcivate a relay, and it's not funny that it's activated every reset.
I've moved to HomeAssistant from OpenHAB2, but cannot tell it's related. I have not an exactly idea what that happens.
MQTT Server 1.5.5-0mosquitto1.

Ideas?

Thanks and Happy Holidays!

Simon

@gohan said in mysgw MQTT Issues:

You have to check both gw and node at same time in order to understand if message is delivered but ack fails or else.

Of course. I'll provide details this evening