@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 ;-)

Hello @gohan ,

I was able to compile correctly the network IP mode. I had compiled it with the wrong transport.
BTW, now it initialized correctly, BUT same problems.
I've replaced the radio as well (only on the gateway).
Here the logs:

mysgw: Starting gateway...
mysgw: Protocol version - 2.2.0
mysgw: MCO:BGN:INIT GW,CP=RPNGL---,VER=2.2.0
mysgw: TSF:LRT:OK
mysgw: TSM:INIT
mysgw: TSF:WUR:MS=0
mysgw: TSM:INIT:TSP OK
mysgw: TSM:INIT:GW MODE
mysgw: TSM:READY:ID=0,PAR=0,DIS=0
mysgw: MCO:REG:NOT NEEDED
mysgw: Listening for connections on 0.0.0.0:5003
mysgw: MCO:BGN:STP
mysgw: MCO:BGN:INIT OK,TSP=1
mysgw: TSF:MSG:READ,27-27-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=27
mysgw: TSF:PNG:SEND,TO=0
mysgw: TSF:CKU:OK
mysgw: TSF:MSG:GWL OK
mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
mysgw: TSF:MSG:READ,27-27-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=27
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK

As you can see the SEND message fails.
I'll try now to move the node closer and then try the scanner.

Hope it helps :-(

Simon

@masmat said in mysgw MQTT Issues:

Just a quick idea: are you powering the RFM69 from the Rpi?
I use a Rpi Zero W and when I powered my radio NRF24 from that it doesnt get enough juice even with caps.
I now use a bigger USB-wall wart and use AMS1117-3.3 to power the radio (PA-version) and added caps.

My two cents

Hello,

I've tried to get 3.3V from external source, but same situation:

Apr 16 23:27:02 mysensors-gateway mysgw: MCO:BGN:INIT GW,CP=RPNGL---,VER=2.2.0
Apr 16 23:27:02 mysensors-gateway mysgw: TSF:LRT:OK
Apr 16 23:27:02 mysensors-gateway mysgw: TSM:INIT
Apr 16 23:27:02 mysensors-gateway mysgw: TSF:WUR:MS=0
Apr 16 23:27:02 mysensors-gateway mysgw: TSM:INIT:TSP OK
Apr 16 23:27:02 mysensors-gateway mysgw: TSM:INIT:GW MODE
Apr 16 23:27:02 mysensors-gateway mysgw: TSM:READY:ID=0,PAR=0,DIS=0
Apr 16 23:27:02 mysensors-gateway mysgw: MCO:REG:NOT NEEDED
Apr 16 23:27:02 mysensors-gateway mysgw: MCO:BGN:STP
Apr 16 23:27:02 mysensors-gateway mysgw: MCO:BGN:INIT OK,TSP=1
Apr 16 23:27:02 mysensors-gateway mysgw: GWT:RMQ:MQTT RECONNECT
Apr 16 23:27:02 mysensors-gateway mysgw: connected to 192.168.1.50
Apr 16 23:27:02 mysensors-gateway mysgw: GWT:RMQ:MQTT CONNECTED
Apr 16 23:27:02 mysensors-gateway mysgw: GWT:TPS:TOPIC=mygateway1-out/0/255/0/0/18,MSG SENT
Apr 16 23:27:42 mysensors-gateway mysgw: TSF:MSG:READ,1-27-177,s=48,c=0,t=32,pt=7,l=23,sg=1: 0
Apr 16 23:27:42 mysensors-gateway mysgw: !TSF:MSG:LEN,7!=32
Apr 16 23:27:45 mysensors-gateway mysgw: TSF:MSG:READ,27-27-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
Apr 16 23:27:45 mysensors-gateway mysgw: TSF:MSG:BC
Apr 16 23:27:45 mysensors-gateway mysgw: TSF:MSG:FPAR REQ,ID=27
Apr 16 23:27:45 mysensors-gateway mysgw: TSF:PNG:SEND,TO=0
Apr 16 23:27:45 mysensors-gateway mysgw: TSF:CKU:OK
Apr 16 23:27:45 mysensors-gateway mysgw: TSF:MSG:GWL OK
Apr 16 23:27:47 mysensors-gateway mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
Apr 16 23:27:51 mysensors-gateway mysgw: TSF:MSG:READ,27-27-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
Apr 16 23:27:51 mysensors-gateway mysgw: TSF:MSG:BC
Apr 16 23:27:51 mysensors-gateway mysgw: TSF:MSG:FPAR REQ,ID=27
Apr 16 23:27:51 mysensors-gateway mysgw: TSF:CKU:OK,FCTRL
Apr 16 23:27:51 mysensors-gateway mysgw: TSF:MSG:GWL OK
Apr 16 23:27:53 mysensors-gateway mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0

Possible the problem is only sending and not receiving?
I've not tested the signal scanner right now.
I was hoping it's a power issue :'(

Simon

Hello @gohan
Installed ethernet version:

./configure --my-gateway=ethernet --my-port=5003

And it's even worst:

# ./mysgw -d
mysgw: Starting gateway...
mysgw: Protocol version - 2.2.0
mysgw: MCO:BGN:INIT GW,CP=RNNGL---,VER=2.2.0
mysgw: TSF:LRT:OK
mysgw: TSM:INIT
mysgw: TSF:WUR:MS=0
mysgw: !TSM:INIT:TSP FAIL
mysgw: TSM:FAIL:CNT=1
mysgw: TSM:FAIL:DIS
mysgw: TSF:TDI:TSL
mysgw: TSM:FAIL:RE-INIT
mysgw: TSM:INIT
mysgw: !TSM:INIT:TSP FAIL
mysgw: TSM:FAIL:CNT=2
mysgw: TSM:FAIL:DIS
mysgw: TSF:TDI:TSL
mysgw: TSM:FAIL:RE-INIT
mysgw: TSM:INIT
mysgw: !TSM:INIT:TSP FAIL
mysgw: TSM:FAIL:CNT=3
mysgw: TSM:FAIL:DIS
mysgw: TSF:TDI:TSL
mysgw: TSM:FAIL:RE-INIT
mysgw: TSM:INIT
mysgw: !TSM:INIT:TSP FAIL

Using the mqtt version at least the init gets completed.
Ideas?

Simon

@gohan said in mysgw MQTT Issues:

https://forum.mysensors.org/topic/7822/portable-rfm69-signal-scanner/6

Ok, then I need to upload it on the node (which is on a little wooden bird house) and go around with my laptop connected on it :-) Not a problem.
But would that report issues on the GW RPi as well? How?

Meanwhile I can try to compile the ethernet version to give it a try.

Thanks, Simon

@gohan said in mysgw MQTT Issues:

I forgot you had rfm69, so capacitor is not that important. Try to look at my rfm69 signal scanner and look for the code to print on debug the rssi of signal and output power and try to move around to see if you get any value change. I had problems with rpi3 gw using the alpha version, but on stable it works. You could also try to compile it as an ethernet gateway just to see if you get any changes. Can you also post the configure parameters you user?

Hello!
Which parameters?
compiling parameters of the GW?
I've configured it with:

./configure --my-transport=rfm69 --my-rfm69-frequency=868 --my-gateway=mqtt --my-controller-ip-address=192.168.1.50 --my-mqtt-publish-topic-prefix=mygateway1-out --my-mqtt-subscribe-topic-prefix=mygateway1-in --my-mqtt-client-id=raspberryRFM69

About the rfm69 signal scanner, should it run on the node or on the RPi?
(where to find it?)

Thanks @gohan :-)

@gohan said in mysgw MQTT Issues:

move node closer. You could also try swapping the 2 radio modules to see if the problem changes.

Strange is, the same radios had worked well until I've switched to RPi GW.
From the logs, correct me if I'm wrong, the issue seems to be on the gateway, not able to send the return/ack message:

!TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0

The node is sending well!

TSF:MSG:SEND,27-27-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:

Or not??

I've added capacitors 100uf to both and, as well, added a copper coli antenna 868Mhz.
Now the GW is 10meters far away from the node. There is only one wall between.
I was testing to switch to RF69 radios which should be better if compared to nRF24L01+ in terms of range and walls.
This is not what expected...

I'll try to replace the radio on the GW side.

Any other suggestion is well appreciated!

Thanks, Simon

Hello!

Added capacitor, but it's still not working.
It has worked from some minutes but then no-more.
Here results from Gateway and Node:

Node:

 __  __       ____
|  \/  |_   _/ ___|  ___ _ __  ___  ___  _ __ ___
| |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
| |  | | |_| |___| |  __/ | | \__ \  _  | |  \__ \
|_|  |_|\__, |____/ \___|_| |_|___/\___/|_|  |___/
        |___/                      2.2.0

16 MCO:BGN:INIT NODE,CP=RPNNA---,VER=2.2.0
25 MCO:BGN:BFR
27 TSM:INIT
28 TSF:WUR:MS=0
30 TSM:INIT:TSP OK
31 TSM:INIT:STATID=27
33 TSF:SID:OK,ID=27
35 TSM:FPAR
1036 TSF:MSG:SEND,27-27-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
3043 !TSM:FPAR:NO REPLY
3045 TSM:FPAR
4046 TSF:MSG:SEND,27-27-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6053 !TSM:FPAR:NO REPLY
6055 TSM:FPAR
7056 TSF:MSG:SEND,27-27-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
9063 !TSM:FPAR:NO REPLY
9065 TSM:FPAR
9069 TSF:MSG:SEND,27-27-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
10904 TSF:MSG:READ,0-0-27,s=255,c=3,t=8,pt=1,l=1,sg=0:0
10908 TSF:MSG:FPAR OK,ID=0,D=1
11077 TSM:FPAR:OK
11078 TSM:ID
11080 TSM:ID:OK
11081 TSM:UPL
18379 !TSF:MSG:SEND,27-27-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=NACK:1
20386 TSM:UPL
27659 !TSF:MSG:SEND,27-27-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=1,st=NACK:1
29666 TSM:UPL

..and here the gateway:

Apr 10 21:49:36 mysensors-gateway mysgw: TSF:MSG:READ,27-27-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
Apr 10 21:49:36 mysensors-gateway mysgw: TSF:MSG:FPAR REQ,ID=27
Apr 10 21:49:38 mysensors-gateway mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
Apr 10 21:49:38 mysensors-gateway mysgw: TSF:MSG:READ,27-27-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
Apr 10 21:49:38 mysensors-gateway mysgw: TSF:MSG:FPAR REQ,ID=27
Apr 10 21:49:40 mysensors-gateway mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
Apr 10 21:49:41 mysensors-gateway mysgw: TSF:MSG:READ,27-27-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
Apr 10 21:49:41 mysensors-gateway mysgw: TSF:MSG:FPAR REQ,ID=27
Apr 10 21:49:43 mysensors-gateway mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
Apr 10 21:49:44 mysensors-gateway mysgw: TSF:MSG:READ,27-27-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
Apr 10 21:49:44 mysensors-gateway mysgw: TSF:MSG:FPAR REQ,ID=27
Apr 10 21:49:46 mysensors-gateway mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
Apr 10 21:49:47 mysensors-gateway mysgw: TSF:MSG:READ,27-27-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
Apr 10 21:49:47 mysensors-gateway mysgw: TSF:MSG:FPAR REQ,ID=27
Apr 10 21:49:48 mysensors-gateway mysgw: TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
Apr 10 21:49:49 mysensors-gateway mysgw: TSF:MSG:READ,27-27-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
Apr 10 21:49:49 mysensors-gateway mysgw: TSF:MSG:PINGED,ID=27,HP=1
Apr 10 21:49:50 mysensors-gateway mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1
Apr 10 21:49:50 mysensors-gateway mysgw: TSF:MSG:READ,27-27-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
Apr 10 21:49:50 mysensors-gateway mysgw: TSF:MSG:PINGED,ID=27,HP=1
Apr 10 21:49:52 mysensors-gateway mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1
Apr 10 21:49:53 mysensors-gateway mysgw: TSF:MSG:READ,27-27-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
Apr 10 21:49:53 mysensors-gateway mysgw: TSF:MSG:PINGED,ID=27,HP=1
Apr 10 21:49:54 mysensors-gateway mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1
Apr 10 21:49:54 mysensors-gateway mysgw: TSF:MSG:READ,27-27-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
Apr 10 21:49:54 mysensors-gateway mysgw: TSF:MSG:PINGED,ID=27,HP=1
Apr 10 21:49:55 mysensors-gateway mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1
Apr 10 21:49:58 mysensors-gateway mysgw: TSF:MSG:READ,27-27-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
Apr 10 21:49:58 mysensors-gateway mysgw: TSF:MSG:PINGED,ID=27,HP=1
Apr 10 21:50:00 mysensors-gateway mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1
Apr 10 21:50:00 mysensors-gateway mysgw: TSF:MSG:READ,27-27-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
Apr 10 21:50:00 mysensors-gateway mysgw: TSF:MSG:PINGED,ID=27,HP=1
Apr 10 21:50:01 mysensors-gateway mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1
Apr 10 21:50:02 mysensors-gateway mysgw: TSF:MSG:READ,27-27-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
Apr 10 21:50:02 mysensors-gateway mysgw: TSF:MSG:PINGED,ID=27,HP=1
Apr 10 21:50:03 mysensors-gateway mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1
Apr 10 21:50:03 mysensors-gateway mysgw: TSF:MSG:READ,27-27-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
Apr 10 21:50:03 mysensors-gateway mysgw: TSF:MSG:PINGED,ID=27,HP=1
Apr 10 21:50:05 mysensors-gateway mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1

Seems the GW is not able to send out the answer.
BTW It gets every message from the node...

Ideas?

Thanks!

Simon

@gohan

@gohan said in mysgw MQTT Issues:

Yes, I use 10uF ceramic because of low ESR

Actually I've only electrolytic ones, I'll try meanwhile with that, thanks!

Simon

@gohan said in mysgw MQTT Issues:

add capacitor and try again

Size? 100uF enough?

@gohan said in mysgw MQTT Issues:

use the master branch that is 2.2, the 2.2.1 are 2.3 are alpha versions and still under development

Ok, this is something I can test right now!
Same result:

mysgw: Starting gateway...
mysgw: Protocol version - 2.2.0
mysgw: MCO:BGN:INIT GW,CP=RPNGL---,VER=2.2.0
mysgw: TSF:LRT:OK
mysgw: TSM:INIT
mysgw: TSF:WUR:MS=0
mysgw: TSM:INIT:TSP OK
mysgw: TSM:INIT:GW MODE
mysgw: TSM:READY:ID=0,PAR=0,DIS=0
mysgw: MCO:REG:NOT NEEDED
mysgw: MCO:BGN:STP
mysgw: MCO:BGN:INIT OK,TSP=1
mysgw: GWT:RMQ:MQTT RECONNECT
mysgw: connected to 192.168.1.50
mysgw: GWT:RMQ:MQTT CONNECTED
mysgw: GWT:TPS:TOPIC=mygateway1-out/0/255/0/0/18,MSG SENT
mysgw: TSF:MSG:READ,27-27-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=27
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK
mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
mysgw: TSF:MSG:READ,27-27-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=27
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK
mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
mysgw: TSF:MSG:READ,27-27-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=27
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK
mysgw: !TSF:MSG:SEND,0-0-27-27,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0

Is the !TFS:MSG:SEND,0-0-27-27,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0 actually the answer sent?
Could it be a power issue? The radio is directly connected to 3.3V pin, without capacitor.

Simon