Posts made by xefil

@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

@gohan said in mysgw MQTT Issues:

Why are you using version 2.2.1? What do you see on the node log?

I've noticed this now (remote) connected to the RPi. I can give a check on the logs of the node as soon I'm back.
About the version, which should I use? This is the first I've downloaded (months ago).
I've seen there is a v2.3.0-alpha. I could test it.

Simon

Hello to all,

I'm having issues with the only node in RF69 I've actually installed.
Switched to RPi and radio connected as MQTT server I'm getting this:

mysgw: Starting gateway...
mysgw: Protocol version - 2.2.1-alpha
mysgw: MCO:BGN:INIT GW,CP=RPNGL---,VER=2.2.1-alpha
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: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
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

Is this !TSF causing me the issues not getting any informations from the node?
The node has worked well with RF68 on arduino (as gateway) before moving to RPi.
What could be the cause?

Thanks,

Simon

@gohan said in MQTTClient - Arduino uno - Ethernet Shield WIZ5100 - RFM69:

I am just referring to this https://www.mysensors.org/hardware/nrf2rfm69

The sockets you can find them on gearbest or aliexpress.

Of course the coverage gain is only within HW, but you can have closer nodes using normal W version.

Ok, you use this adapter to place the RFM69 module on it and let it fit in something like that?
https://www.aliexpress.com/item//32741923288.html

Then I could wire it as always or should it use the 5V in the RPi instead?

@gohan said in MQTTClient - Arduino uno - Ethernet Shield WIZ5100 - RFM69:

HW version is just a regular W version with an extra power amplifier on the TX side. To use them i got some of those nrf24 sockets with voltage regulator and I soldered the radio module on the nrf2rfm pcb adapter that you can find on openhardware.io

If the "HW" version has an amplifier on the TX side, do you think it's enough to have coverage gain on nodes that are only "W"?

I cannot find the nrf24 sockets with voltage regulator on openhardware.io
Do you apply it on both radios?

@gohan hello again!
I’m testing the RFM69 on RPi and seems working well. The only doubt is about the range. Seems previous Arduino-RFM69-serial setup was better. Maybe only placed better.
Btw I’m thinking to increase the range using the RFM69HW version.

Is the HW the better version that is using more power?

What have you done for connect it then on the RPi?

Actually I’m using RFM69H(not W). If all are 868Mhz, are they compatible with HW version?

If all will work stable, I’ll migrate the nRF24L01+ as well. What have you done for handle power on this? On my Arduino I’m using a capacitor, nothing more.

Thanks for you help as always!!

Simon

Thanks both @gohan and @tekka
I'll give there a look and try by myself.

Simon

Hello,

Until API2.0 I was getting two informations from the nodes:

• parentNode
• distance

I was taking those informations to have an overview how far is a node and who is his parent. All that with this code:

parentNode = _nc.parentNodeId;
distance = _nc.distance;
(...)
send(msgNodeVar1.set(parentNode, 1));
send(msgNodeVar2.set(distance, 1));

Now this is not working anymore...

error: '_nc' was not declared in this scope
   parentNode = _nc.parentNodeId;
                ^
exit status 1
'_nc' was not declared in this scope

Any idea?

Thanks,

Simon

@kebibg hello
Was you able to bring it to work?

Thanks, Simon

@gohan said in MQTTClient - Arduino uno - Ethernet Shield WIZ5100 - RFM69:

NO level converter since RPI is 3.3v but I had tu use sockets with voltage regulators for the radios because I used the high power versions

You mean the RFM69HW ?
Ok, in that case it's not the own I have, so I expect to connect both radios directly on the board (as soon I get one )

@gohan said in MQTTClient - Arduino uno - Ethernet Shield WIZ5100 - RFM69:

Yes, there is a open topic on the forum "dual spi radio", I have them both running on my RPI

Hello @gohan !
I'm trying to move on that way.
You have installed boh radios on RPi. Was a Level Converter required?

Thanks!

Simon

@gohan said in MQTTClient - Arduino uno - Ethernet Shield WIZ5100 - RFM69:

To me having the radio directly on the RPI is a much cleaner solutions, with less wires around and it is easier to update gw software remotely

Could you add the nRF24L01+ as well? I have both radios around!

@gohan said in MQTTClient - Arduino uno - Ethernet Shield WIZ5100 - RFM69:

I'd consider gettin a RPI3, there are so many working solutions that can simplify al lot of things instead of the other various "fruits" PIs that are indeed cheaper but they don't have the same community support as the raspberry.

Absolutely true! Btw years ago I've helped in implementing the vdpau drivers, testing xbmc (now kodi) and hw acceleration so I got 5 boards for free for the tests. That's the reason why I'm using it
One is for Openhab (the one that has armbian without /boot/script.bin), one used with Octoprint on my 3d printer, another in a kiosk for my MAME emulation station
If I cannot get any support with the Armbian version, maybe I'll get an RPi.

@gohan said in MQTTClient - Arduino uno - Ethernet Shield WIZ5100 - RFM69:

I am just curious, but don't you have a raspberry pi?

Eheh, not really.
I've a BananaPi board, which is mainly the same ARM board, with some differences. I was trying to follow the OrangePi HowTo but noticed that my Armbian version installed on the board is hidding me the /boot/script.bin... so I cannot proceed. On an old version it was available... Of course I've opened a thread on their forum... https://forum.armbian.com/topic/6430-armbianbananapi-scriptbin-missing/

I'm waiting for answers. Still requested again

Simon

Hello @gohan

@gohan said in MQTTClient - Arduino uno - Ethernet Shield WIZ5100 - RFM69:

library 2.2 has a new driver for RFM69 if you want to use it and it is used by raspberry gateway.

Well, then I'm correcting the right old/RFM69_old.h + old/RFM69_old.cpp + old/RFM69registers_old.h to apply the differences between this version (https://github.com/kiwisincebirth/RFM69) and the original one from Mysensors.
I've overwritten the above files taken the version from 'kiwisincebirth' and added the missing functiond like sanityCheck, powerUp, powerDown, ... and correcting the variable definition from RF69_* to RFM69_*.

Now it compiles correctly, but I don't have my board here.
Another story is to understand if that will work on the board.

As written by @Carywin in the thread suggested by him, I'll use his sketch and connect the radio over the Wiz5100 shield on my Arduino UNO using as CS digital PIN6 instead of PIN10. All via Level Converter. The remaining pins on the radio will maintain the same connections as default. Hope I've understood all correctly and that will work...

Simon

Hello @Carywin

Hello,

I think it's not working anymore on API 2.2...
Im getting a lot of compilation errors due includes non having the required functions. Seems RFM69 on MySensors are updatedb since API 2.2...

Look at 2.1:
https://github.com/mysensors/MySensors/blob/2.1.1/drivers/RFM69/RFM69.h

Compared to the 2.2:
https://github.com/mysensors/MySensors/blob/development/drivers/RFM69/old/RFM69_old.h

The name is changed as well RF69 to RFM69...
I'm trying to correct the RFM69 library taken from https://github.com/kiwisincebirth/RFM69 suggested by you.
Some new functions were included as well.
Then I'll give a try.
Let e know for the above doubts.

Thanks, Simon

@carywin said in MQTTClient - Arduino uno - Ethernet Shield WIZ5100 - RFM69:

I got it to work using Leonardo, but the same process would work for Uno I think:
https://forum.mysensors.org/topic/6249/mqtt-ethernet-gateway-using-leonardo-32u4-w5100-rfm69h-hard-spi

Hello @Carywin !
Thanks for your suggestion!
I'm not totally sure about your setup, so, to be sure:

• you have NOT edited and library file by yourself (i.e. the ethernet library ad discussed here: https://forum.mysensors.org/topic/5351/solved-w5100-ethernet-gateway-with-rfm69-radio-fails-at-init/7)
• you have replaced the whole RFM69 library using the one taken from Github

Then, could you explain me more in detail your wiring setup? Seems it's different from the default, but don't know if because it's due the Leonardo, the library or why.

I'm using an Arduino uno with on that the Etnernet Shield. The connections to the radio should then start from the ethernet shield to the radio.

Meanwhile I'm trying to compile it without the hardware here, but get compilation issues. I've replaced the RFM69 library into Mysensors\drivers\RFM69 and changed the name so that it matched the filenames "old/RFM*_old.*".
After that It's able to find all needed files but I get different errors like:

...arduino-1.8.5\libraries\MySensors/MyConfig.h:729:25: error: 'DEFAULT_RFM69_CS_PIN' was not declared in this scope
#define MY_RFM69_CS_PIN DEFAULT_RFM69_CS_PIN

...arduino-1.8.5\libraries\MySensors/hal/transport/MyTransportRFM69.cpp:156:14: note: in expansion of macro 'MY_RFM69_CS_PIN'
RFM69 _radio(MY_RFM69_CS_PIN, MY_RFM69_IRQ_PIN, MY_RFM69HW, MY_RFM69_IRQ_NUM);
...arduino-1.8.5\libraries\MySensors/MyConfig.h:703:26: error: 'DEFAULT_RFM69_IRQ_PIN' was not declared in this scope
#define MY_RFM69_IRQ_PIN DEFAULT_RFM69_IRQ_PIN

(...)

It's due API version 2.2?

Thanks a lot!!

Simon

I've tried but it doesn't work
I've used the suggestions provided here:

https://forum.mysensors.org/topic/5351/solved-w5100-ethernet-gateway-with-rfm69-radio-fails-at-init/

I've tried first without the patch, but no way...

Ideas?

Thanks, Simon

Hello,

I'm following this guide to try compile the MQTTClient on a RFM69 but it doesn't work
I've Arduino UNO with Ethernet shield W5100 and RFM69. MySensors 2.2 API.
All was working well via serial port (so it means that the connection are ok and the level shifter as well), but I need to migrate to an IP version, better if MQTTClient.
I've used the @Frédéric-Grandjean patch and the @Jonathan-Caes modification on the #else error. I'm using arduino 1.8.2 software and I've downgraded the AVR Board to 1.6.11. It compiles fine, but the output is the following:

0 MCO:BGN:INIT GW,CP=RRNGTSM:INIT:TSP FAIL
10117 TSM:FAIL:CNT=2
10119 TSM:FAIL:DIS
10121 TSF:TDI:TSL
0 MCO:BGN:INIT GW,CP=RRNGA---,VER=2.2.0
3 TSM:INIT
4 TSF:WUR:MS=0
55 !TSM:INIT:TSP FAIL
56 TSM:FAIL:CNT=1
58 TSM:FAIL:DIS
59 TSF:TDI:TSL
10062 TSM:FAIL:RE-INIT
10064 TSM:INIT
10115 !TSM:INIT:TSP FAIL
10117 TSM:FAIL:CNT=2
10119 TSM:FAIL:DIS
10121 TSF:TDI:TSL

This is my code:

#define MY_DEBUG

#define MY_RADIO_RFM69

#define MY_GATEWAY_MQTT_CLIENT

#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mygateway2-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mygateway2-in"

#define MY_MQTT_CLIENT_ID "mysensors-2"

#if !defined(MY_W5100_SPI_EN) && !defined(ARDUINO_ARCH_SAMD)
#define MY_SOFTSPI
#define MY_SOFT_SPI_SCK_PIN 14
#define MY_SOFT_SPI_MISO_PIN 16
#define MY_SOFT_SPI_MOSI_PIN 15
#endif

#ifndef MY_RF24_CE_PIN
#define MY_RF24_CE_PIN 5
#endif
#ifndef MY_RF24_CS_PIN
#define MY_RF24_CS_PIN 6
#endif

#define MY_IP_ADDRESS 192,168,1,52

#define MY_IP_GATEWAY_ADDRESS 192,168,1,1
#define MY_IP_SUBNET_ADDRESS 255,255,255,0

#define MY_CONTROLLER_IP_ADDRESS 192,168,1,50 
#define MY_PORT 1883


#include <Ethernet.h>
#include <MySensors.h>

void setup()
{
	// Setup locally attached sensors
}

void presentation()
{
	// Present locally attached sensors here
}

void loop()
{
	// Send locally attached sensors data here
}

Thanks a lot for any help!!

Simon

@gohan said in Ethernet GW vs MQTT:

First you can set username and password, second the gateway is connecting to a broker while ethernet is accepting incoming connections in clear text and no security of any kind ; also if you are accepting connections it is more likely to have a security risk than only outgoing connections

Thanks!

@gohan said in Ethernet GW vs MQTT:

Ethernet for ease of use and configuration, it works with myscontroller.

MQTT for better security, you can still use FOTA with MyController, once data is published to MQTT you can do lot's of things.

Hello (again )
Why is MQTT better for security?

Thanks,

simon

@gohan

@gohan said in MQTTClient - Arduino uno - Ethernet Shield WIZ5100 - RFM69:

Actually I didn't try that setup since the RPI gateway was a much cleaner solution for me. But isn't softSPI needed when using the W5100 ?

Well, I've read mainly this post:
https://forum.mysensors.org/post/56273

Seems that I've to change many files and was interesting to know if on API2.2 it's not needed anymore. Maybe @Tris or @abrasha or @Jonathan-Caes or @Frédéric-Grandjean or @korttoma could give me some hints as well
MQTTClient or Ethernet Gateway would be perfect. I need to move away from Serial

Thanks!!!

Simon

@gohan

@gohan said in MQTTClient - Arduino uno - Ethernet Shield WIZ5100 - RFM69:

You can use either Ethernet or MQTT, give it a try. I asked for raspberry because you can use it as a gateway without the need of an arduino.
I don't know if it is the same but maybe you can make it work on your hardware -> https://www.mysensors.org/build/orange

Hello @gohan !
Thanks for the quick response. The solution on RPi seems interesting as well.
For now I would like to test first the Arduino, then maybe move the radio on my BPi. Having the Arduino alread ready, it's easier.
BTW, I've read on the forum issues about Ethernet Shield W5100 and the radio RFM69, sharing the same SPI, but cannot find informations on the actual 2.2 version of the mysensors api.
Was that solved without implementing external github modifications (they would invalidate future upgrades of the API) or editing too much ".h" files around?
I'll try them in the next days, but if there are some hints, that's time I can spend form some beers instead driving me crazy because there are hidden workarounds

Thanks a lot!!

Simon

My controller is based on Banana-Pi, which is very similar to Raspberry.
BTW, looking why I've choosen to use MQTT in the past, it was because OpenHAB was able to comunicate with MySensors gateway only via MQTT. I've started using Mysensors on version 1.5.
Now, reading the API, since 2.0, OpenHAB is compatible with Serial and Ethernet Gateway as well. So, if the above hardware is compatible for a MQTTClient gateway or for a Ethernet Gateway, that would be for me the same.
Does it work?
Until now It was working as Serial Gateway, but would like to stop usng serial between my arduino and the Openhab controller.

Thanks for the help!

Simon

Hello to all,

Some years ago I've tried to setup a MQTTClient on the following hardware:

• Arduino UNO
• Ethernet Shield WIZ5100
• RFM69

Here my last thread about:
https://forum.mysensors.org/topic/4199/arduino-uno-and-rfm69-level-converter/

I was not able to accomplish the above steps so I moved to serial Gateway. It works with a level converter, but now I need to move the gateway and it would be great if it would be in IP, not serial.

I know I could try by myself, but actually I'm away, so I would like to know if there are some news on this thema, before I'll back home to try.

I've seen there is an Example in the library "GatewayW5100MQTTClient" which includes the possibility to select now more radio:

// Enables and select radio type (if attached)
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95

So is there someone with experiences on this setup or have an idea?

Even other IP solutions would be great!

Thanks!

Simon

Hello rejoe2
I think it's enough for me as well for now.
Thanks for the support!
Simon

Hello,

Thanks for the answer.
I've added the parameter, seems after 7 tries it starts the loop(), thanks!
Is there a way to reduce the tries?
I've set this but is ignored:

MY_REGISTRATION_RETRIES 1

Or seems it's used only after the first cycle of 7 retries.

Thanks,

Simon

Hello!

AFAYK if a node boots and it's able to contact the gateway, it starts the loop() procedure.
If the radio comunication gets interrupted, the internal procedures are processed anyway.
It simply gives a fail during the send() command, but the rest works.

What if the node fails to comunicate with the gateway from the boot?
Isn't there a way to skip the boot procedure and let it try later but continue to process the loop()?

The reason is I've a node with some logic inside. It works alone. No interraction from the controller is required. I use the controller to check the status of sensors but it should not stop to work if the radio comunication fails even at boot.

Is there a way?

Thanks!

Simon

Thank you!!

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

@AWI
Sorry, to be sure, so, using a nano with a 3.3V (and external power, not battery due relay board) to connect the radio, the Low-dropout is not needed, right? I'm not using it on other nodes

@AWI
Thank you for the suggestions. Great thread about the comparsion on the sensors. I'll read it carefully.
I'm using DHT11 mainly for humidity and then Dallas sensor for the temperature. Dallas seems precise and the options to use one-wire connection handles easier having more sensors. Ok for the capacitor. What stands the LDO for? Nano still has 3.3v output.

@petewill
Opening my thermostat it has only two cables coming from the wall. Closing the circuit, an electrovalve opens the water circuit to heat the heater/radiator. I need it only for the bathroom. In the rest of the house I'm using a pelletofen. It has a RS232 port behind. I've found how closing two pins it's possible to turn the ofen on or off. Another node is still installed and works great

Simon

Hello to all!
I would like to ask the community some hints to replace my thermostat.
The thermostat is in the bathroom, not really near to a power socket. First option to choose is:

Where place the node?

• Remove the old thermostat maintaing the case, insert an arduino + nRF24L01+ and a 2xrelays-board (I have only this)
• Place the node outside the thermostat (near power socket) and bring to the thermostat case the two cables connected to the relay to control it

Which setup is better based on the parts I already have?
The relay-board (https://www.aliexpress.com/item/2-Channel-NEW-5V-2-Channel-Relay-Module-Shield-For-Arduino-ARM-PIC-AVR-DSP-Electronic/1736628551.html?spm=2114.13010608.0.0.7CpgCF) needs 5V.
What is better?

• NANO 3.3V + DHT11 + nRF24L01+ + Step Up converter (like this https://www.aliexpress.com/item/Free-Shipping-One-Lot-2PCS-DC-DC-Converter-Step-Up-Module-1-5V-to-5V-500mA/1883948015.html) for powering relay board + relay board
• NANO 5V + DHT11 + relay board + LE33 regulator + nRF24L01+
• PRO MINI (has both 3.3V and 5V) + DHT11 + nRF24L01+ Relay Board

And last but not least how to power it?

• via RAW / USB PIN
• via batteries?

It would be nice if I could power it by a battery, so I could close all into the thermostat box.
But I don't know which batteries to use and how (raw pin?). I've never powered my nodes via batteries. No idea how often should I replace the batteries.

What the thermostat should do is to get commands from the controller on a time basis to turn the relays on and off when needed or on demand. I would implement all the logic on the controller. Even to turn it on if the temperature is to low, all would be decided from the controller. The node should only turn ON/OFF and give temperature/humidity data.

Thanks to all for the suggestions!!

Simon

Hi @andredts !
Well, I had not implemented the RGB Color panel, but then I've tried to create it and it works well.
BTW I've read right now that you are using the serial gateway. I'm on MQTT, so, you need to implement the rules to parse the serial messages. Apart of this, if you need the sketch and the rules/items for handling the RGB I can share it.
I've two radio networks. First on nrf24l01+ with mqttclientforwarder on mosquitto mqtt-server and other nodes on rf64 with serial gateway and python service to parse the serial and forward it to the same mqtt-server.

Cheers, Simon

@andredts now I'm on travel. I'll send/share you the code as soon I'll reach my home again

Hello @mortommy , great job

@andredts , are youo using serial gateway? I've the code used on the sketch to handle the rgb strips. I've build it following exactly this:
http://easydomoticz.com/forum/viewtopic.php?f=20&t=704

But I've as gateway, the MQTT ClientForwarder.

Simon

The reason is to not modify the actual light source because all bulbs are already present.
It's difficult to create a dimmer for 220V source? I really don't know

Hello,

I would like to dimmer a LED bulb 220V via arduino (and then via MySensors). I've found this project:

http://www.instructables.com/id/Arduino-controlled-light-dimmer-The-circuit/

BUT AFAI've understood, seems that this wont work in case of LED bulbs, but only with classic Light Bulb Tungsten Filament.
On some LED bulbs I've read it needs a "LED SCR Dimmer" to control it.
Is that correct?

Is there a way to do that?

Thanks a lot for any help!

Simon

Give me some time and I'll share it.
Simon

Seems to work well! I'll test it a little bit

hello @arendst ,

Does it work on MySensors API 2.0 as well?
I'm interested to use it

thanks!!

Simon

@Yveaux said:

@xefil does this Ethernet shield also have an SD card slot? If so, it shares the spi bus with the rfm.
You should make sure the SD card chip-select line is high, before the mysensors library is initialized (implement the pin initialization in the before()-method). Otherwise the SD card communication will interfere with the rfm communication.

Yes, it has a SD card module as well.
How to disable it?
I've tried it so:

void before() {
  // disable SD card
  pinMode(4, OUTPUT);
  digitalWrite(4, HIGH);
}

Actually I get simply this:

0;255;3;0;9;Starting gateway (RRNGA-, 2.0.0)
0;255;3;0;9;TSM:INIT
0;255;3;0;9;!TSM:RADIO:FAIL
0;255;3;0;9;!TSM:FAILURE
0;255;3;0;9;TSM:PDT

And what is that for? Does it help?

// W5100 Ethernet module SPI enable (optional if using a shield/module that manages SPI_EN signal)
//#define MY_W5100_SPI_EN 4  

Thanks!

Simon

This is the whole code again I'm using now:

#include <SPI.h>

// Enable debug prints to serial monitor
#define MY_DEBUG 

// Enables and select radio type (if attached)
//#define MY_RADIO_NRF24
#define MY_RADIO_RFM69

#define MY_GATEWAY_MQTT_CLIENT

// Set this nodes subscripe and publish topic prefix
#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mygateway2-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mygateway2-in"

// Set MQTT client id
#define MY_MQTT_CLIENT_ID "mysensors-2"

// W5100 Ethernet module SPI enable (optional if using a shield/module that manages SPI_EN signal)
//#define MY_W5100_SPI_EN 4  

// Enable Soft SPI for NRF radio (note different radio wiring is required)
// The W5100 ethernet module seems to have a hard time co-operate with 
// radio on the same spi bus.
#if !defined(MY_W5100_SPI_EN) && !defined(ARDUINO_ARCH_SAMD)
  #define MY_SOFTSPI
  #define MY_SOFT_SPI_SCK_PIN 14
  #define MY_SOFT_SPI_MISO_PIN 16
  #define MY_SOFT_SPI_MOSI_PIN 15
#endif  

// When W5100 is connected we have to move CE/CSN pins for NRF radio
#define MY_RF24_CE_PIN 5
#define MY_RF24_CS_PIN 6

// Enable these if your MQTT broker requires usenrame/password
//#define MY_MQTT_USER "username"
//#define MY_MQTT_PASSWORD "password"

// Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
#define MY_IP_ADDRESS 192,168,1,52

// If using static ip you need to define Gateway and Subnet address as well
#define MY_IP_GATEWAY_ADDRESS 192,168,1,1
#define MY_IP_SUBNET_ADDRESS 255,255,255,0


// MQTT broker ip address.  
#define MY_CONTROLLER_IP_ADDRESS 192,168,1,50

// The MQTT broker port to to open 
#define MY_PORT 1883      

 /*
// Flash leds on rx/tx/err
#define MY_LEDS_BLINKING_FEATURE
// Set blinking period
#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Enable inclusion mode
#define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
#define MY_INCLUSION_BUTTON_FEATURE
// Set inclusion mode duration (in seconds)
#define MY_INCLUSION_MODE_DURATION 60 
// Digital pin used for inclusion mode button
#define MY_INCLUSION_MODE_BUTTON_PIN  3 

// Uncomment to override default HW configurations
//#define MY_DEFAULT_ERR_LED_PIN 16  // Error led pin
//#define MY_DEFAULT_RX_LED_PIN  16  // Receive led pin
//#define MY_DEFAULT_TX_LED_PIN  16  // the PCB, on board LED
*/

#include <Ethernet.h>
#include <MySensors.h>

void before() {
  // disable SD card
  pinMode(4, OUTPUT);
  digitalWrite(4, HIGH);
}

void setup() { 
}

void presentation() {
  // Present locally attached sensors here    
}


void loop() {
  // Send locally attech sensors data here
}

@scalz

It's an WIZ5100 Ethernet Shield, yes.
I'm using the above setup. I'm in doubt if SoftSPI works or whatever can i do.

Hello @scalz and @mfalkvidd !
I've obtained new level converter and I was able to create the Gateway in Serial Connection mode. It works well on che new API2.0.
Now I would like to move this gateway to MQTTClient as well but it doesn't work. I already have an MQTTClient for the NRF24L01+ and would so use this new gateway with with RF69 on MQTTClient as well.
I obtain "Radio init Fail".
Is this a known issue on RF69 or should it work???
I'm using this simple sketch:

#include <SPI.h>

// Enable debug prints to serial monitor
#define MY_DEBUG 

// Enables and select radio type (if attached)
//#define MY_RADIO_NRF24
#define MY_RADIO_RFM69

#define MY_GATEWAY_MQTT_CLIENT

// Set this nodes subscripe and publish topic prefix
#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mygateway2-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mygateway2-in"

// Set MQTT client id
#define MY_MQTT_CLIENT_ID "mysensors-2"

// W5100 Ethernet module SPI enable (optional if using a shield/module that manages SPI_EN signal)
//#define MY_W5100_SPI_EN 4  

// Enable Soft SPI for NRF radio (note different radio wiring is required)
// The W5100 ethernet module seems to have a hard time co-operate with 
// radio on the same spi bus.
#if !defined(MY_W5100_SPI_EN) && !defined(ARDUINO_ARCH_SAMD)
  #define MY_SOFTSPI
  #define MY_SOFT_SPI_SCK_PIN 14
  #define MY_SOFT_SPI_MISO_PIN 16
  #define MY_SOFT_SPI_MOSI_PIN 15
#endif  

// When W5100 is connected we have to move CE/CSN pins for NRF radio
#define MY_RF24_CE_PIN 5
#define MY_RF24_CS_PIN 6

// Enable these if your MQTT broker requires usenrame/password
//#define MY_MQTT_USER "username"
//#define MY_MQTT_PASSWORD "password"

// Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
#define MY_IP_ADDRESS 192,168,1,52

// If using static ip you need to define Gateway and Subnet address as well
#define MY_IP_GATEWAY_ADDRESS 192,168,1,1
#define MY_IP_SUBNET_ADDRESS 255,255,255,0


// MQTT broker ip address.  
#define MY_CONTROLLER_IP_ADDRESS 192,168,1,50

// The MQTT broker port to to open 
#define MY_PORT 1883      

 /*
// Flash leds on rx/tx/err
#define MY_LEDS_BLINKING_FEATURE
// Set blinking period
#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Enable inclusion mode
#define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
#define MY_INCLUSION_BUTTON_FEATURE
// Set inclusion mode duration (in seconds)
#define MY_INCLUSION_MODE_DURATION 60 
// Digital pin used for inclusion mode button
#define MY_INCLUSION_MODE_BUTTON_PIN  3 

// Uncomment to override default HW configurations
//#define MY_DEFAULT_ERR_LED_PIN 16  // Error led pin
//#define MY_DEFAULT_RX_LED_PIN  16  // Receive led pin
//#define MY_DEFAULT_TX_LED_PIN  16  // the PCB, on board LED
*/

#include <Ethernet.h>
#include <MySensors.h>

void setup() { 
}

void presentation() {
  // Present locally attached sensors here    
}


void loop() {
  // Send locally attech sensors data here
}

Thanks for the support!

Simon

Googling and some posts on the forum as well

@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

@hek said:

Setting PA level only have an effect on amplified NRFs (if I'e understood it correctly).

If you're setting a custom data rate, you'll have to do it on all nodes and gateway.

Nodes to close to each other can sometimes to hear each other. Think of it like someone standing by you SCREAMING directly in your ear.

Ok, thanks.
I've only the GW with the NRF+PA+LNA. Do you suggest any best-practice value for MY_RF24_PA_LEVEL + RF24_PA_LEVEL_GW to add on the GW sketch? (I'm still not understanding what exactly those two settings do)

And what is the default speed? Suggestions to decrease?

Thanks!

Simon

@sundberg84 thanks for the informations.
I'll try to DISABLE the repeater feature everywhere expect on those I think are required.
I've updated the thread the same time with extra informations.
My gateway is on:

• arduino 2009 + ethernet shield wiz5100 (MQTTClient)
• radio NRF24L01+ PA/LNA (only the gateway)
• powered via USB port from my wifi router

All the other nodes have normal NRF24L01+

Do you suggest to apply those setting ONLY on the gateway?

#define MY_RF24_PA_LEVEL RF24_PA_LOW
#define RF24_PA_LEVEL_GW RF24_PA_MAX

What do they do?

And what about:

#define RF24_DATARATE RF24_250KBPS

Should I apply it on EVERY node including the GW?
I don't need speed, but range/stability.

About the distance, uh, very strange that close gives problems.

BTW I'll look now your links!

Thanks!!!

Simon

I add some informations on the setup:

• Every module nrf24l01+ have their one capacitor, around 100u.
• The gateway has a nrf24l01+pa+lna (mqtt client) and ethernet shield on arduino 2009
• The gateway is near wifi router (but some nodes are working very well)
• issues are related on nodes on the same room. On a separate room two nodes are ok. The reason is related to the fact that they are connected in a chain and the last hop before the GW has problems, so all have problems....

I would like to unterstand better what asked above to better improove.

Thanks!

Simon

Hello,

After playing a while with mysensors, I'm trying to make some optimizations.
My first question is, when enable the repeater mode in a node?
By default, every node in my env has this feature enabled. Then I've configured two variables to send to the gateway/controller the parent node of every node, as well as the distance. Most of the nodes are in the same room. The gateway is in another room.
Well, I've seen that all nodes are not connected directly to the gateway (node0) but they are connected in a chain! Should be better to enable the repeater mode only on those that are near on the GW and disable this feature to the other? Or it's better to have a node that's acting ONLY as repeater without any sensor and disable the repeater feature everywhere?
I've placed this option in some nodes:

#define MY_PARENT_NODE_ID 0

but I've read it's not mandatory, so it could not be used for sure.

.
Then...
I've seen that API2.0 has some problems with the power. Would this directive help? In case, what does it exactly?

#define MY_RF24_PA_LEVEL RF24_PA_LOW

Even adding a capacitor, seems the node needs time to register correctly.
In case do I need to apply this setting to EVERY node + gateway?

And what are these for?

#define RF24_PA_LEVEL_GW RF24_PA_MAX
#define RF24_DATARATE RF24_250KBPS

Last but not least I've read that in some circumstances if the GW and the node are too near, it gives problems? Why that??

Sorry for all those questions... Thanks for the help!

Simon

@hek
I can retrive the parent node by requesting it, that's ok. I have no idea how to do that (if you can point me to an example...)
BTW, if I would like to inform the Controller (OpenHAB) on which parent is used by a node (I'm using MQTTClient as GW) I need to present and register this information as written by me before or there is another way as well?

Thanks!
simon

Hello @hek
I was able to query the parentnode. I would like to send this information to the Gateway and then save/display it into my controller.
How i s the best way to send these informations? They are not really related to a sensor, are more custom.

I could define it something like that:

// parent
MyMessage msgNodeVar1(CHILD_ID_NODE, V_VAR1)
// distance
MyMessage msgNodeVar1(CHILD_ID_NODE, V_VAR2)

but under which sub-type present it?

present(CHILD_ID_NODE, S_<WHICHONE???>);

Then into loop() with a time I could then send these informations:

parentNode = _nc.parentNodeId;
send(msgNodeVar1.set(parentNode, 1));

distance = _nc.distance;
send(msgNodeVar2.set(distance, 1));

So, to be clean, which subtype should I use for the presentation?

Thanks!

Simon

@hek ok, thank you!
I'll adopt your example as starting point.
Many thanks!

Simon

@hek , thanks for the clarifications.
What do you mean:
Normally transportProcessMessage() gets called once every loop (unless you use wait()).

Does wait() call transportProcessMessage() as well on every use? That would make sense.

I.e.:

void loop(){
  // transportProcessMessage() is called in background somewhere here and so receive(_msg) as well.

  // some code..
  
  wait(100); // this calls transportProcessMessage() again and so receive(_msg) as well.

  // other code...
  
}

Is that above correct?

If yes, then my initial aproach would work as well. a procedure where wait() is called like this:

RedOff() {
  // turn Red ON 100%
  analogWrite(RED_PIN, 255);
  // Fade Red Off
  for (r = 255; r > 0; r--) { 
    analogWrite(RED_PIN, r);
    wait(1000);   // <<<<--------- here it checks for new messages and I could interrupt this procedure.
  } 
}

BTW I prefer your approach taken from 'DimmableLightWithRotaryEncoderButton.ino'. Seems more clean.

I ask you that, only to understand correctly how the logic works.

Thanks a lot,

Simon

@hek , great - simply approach!
If I'm not wrong, your fade function does NOT fade out until the end in one shot, but it simply it's called 'x' times between checks for button or rotary. Right??

Another question: When is exactly the void receive() function called? At the end of every loop()? I'm missing a little bit this part.... but seems I'm understanding a way to solve what I would like to do!
Thanks!!
Simon

Do you have some spare-parts to use a different radio? My gateway has a radio with nrf24l01+pa+lna to increase the range. Maybe the gain is needed with the new API? I don't know. How far are the two objects?

Simon

@TheoL that's exactly what I would like to handle and don't know how.
The wait() command should not stop to accept messages. Is there a way into the RedOff() function to stop the execution in case I get a message I need to handle? Like a turnOn as you said. Maybe @tekka or @hek have better ideas from their experience
Thanks!
Simon

Hello,

I'm planning to rewrite a sketch which actually is handling a RGB led strip. For now I've written the sketch to fade out from Red 100% to off in some minutes. The fade out is managed by the Controller (OpenHAB). It sends the command to the node every 'x' seconds with a new lower dimmer value until it comes to zero, in this way:

Controller -> Red color 100% -> Node
after minutes
Controller -> Red color 90% -> Node
after minutes
Controller -> Red color 80% -> Node
(...)
Controller -> Red color 0% -> Node

The procedure stops.

It works most of the time.

Sometimes happens the Node doesn't answer well. So It happens the led remains on even if the Controller has sent the command to turn the light off. I'll debug it better from hardware side, but I was thinking a different approach as well.
I would like to move the logic on the Node in this way:

Controller -> send V_LIGHT status set to 1 -> Node
In the void receive() I check if the message.sensor is set to the Sensor-ID associated to my trigger and in case it starts a function that turns the RedLight off... something like this:

void receive(const MyMessage &message) {
  if (message.sensor == 10) {
    RedOff();
  }
}

RedOff() {
  // turn Red ON 100%
  analogWrite(RED_PIN, 255);
  // Fade Red Off
  for (r = 255; r > 0; r--) { 
    analogWrite(RED_PIN, r);
    wait(1000);
  } 
}

This procedure would fade out in 1000 * 255 = 255000 ms = 255 seconds = 4 minutes more or less.

My question is:

Would this the best approach to reach the goal?

Then, in case I would STOP the fade even if the RedOff() procedure is not finished, in example turning on a different light attached to the same Node, how to do that?
AFAYK the wait() function calls process() to handle incoming messages during the delay, but I'm missing the logic on how, if a different message is coming to the node, should STOP the RedOff() procedure.

Any help would be really apreciated!

Thanks!

Simon

You mean you cannot find the examples from the API library? When you download it, you can find it in there. On github as well:

https://github.com/mysensors/MySensors/tree/master/examples

In case try to start uploading two examples (1 GW and 1 sensor) and check. They work without issues. If not, maybe a hardware failure.

Simon

@Jason-Brunk I already had a 100u capacitor, thanks for the suggestion.... btw strange, maybe the update was important.
@tekka , thank you!!

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

Hello!
I'm having the same issue. How to solve it?
I've converted a working sensor having API 1.5 with last API and getting this errors:

---
Setting S_LIGHT sensor: 1
---
Setting S_LIGHT sensor: 2
---
Setting S_LIGHT sensor: 3
---
Setting S_LIGHT sensor: 4
Starting sensor (RNNNA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=20)
TSM:FPAR
TSP:MSG:SEND 20-20-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-20 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=20)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 20-20-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:READ 28-28-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
TSP:MSG:BC
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL
TSM:FPAR
TSP:MSG:SEND 20-20-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-20 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=20)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 20-20-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:READ 28-28-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
TSP:MSG:BC
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL
TSM:FPAR
TSP:MSG:SEND 20-20-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-20 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=20)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 20-20-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:READ 28-28-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
TSP:MSG:BC
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL
TSM:FPAR
TSP:MSG:SEND 20-20-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-20 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=20)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 20-20-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:READ 28-28-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
TSP:MSG:BC
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL```

It has worked without issues until the last update.

@mfalkvidd, have another help would be great yes!

My goal is to have a second gateway with RFM69 radios. I would prefer to create it in MQTT, but if the only solution is using a different gateway, I could move to it.
BTW if SPI contention between Ethernet Shield and RFM69 is still a problem, moving to serial gateway doesn't solve me the needs to have a level converter and so I'm still confused on HOW to wire it. Seems I need more pins so a second level converter? confused

Simon

Hello @mfalkvidd ,
Sorry for double-posting
I'm in doubt on how to connect it, I mean, on the "connecting the radio" instructions, I have:

• GND
• VCC
• SCK
• MOSI
• MISO
• DI00

On the module instructions I have:

• BVCC
• BSCL
• BSDA
• BGND

Ok for BVCC and BGND, until here ok, but I don't know where to connect then BSCL and BSDA on the RFM69 module.
I fear to burn/break something

Any idea?

And this, considering always I'm using an Arduino UNO with the Ethernet Shield installed on it.

Many thanks for the help!

Simon

Hello,

I've purchased this level converter:

http://www.ebay.it/itm/222115738795

I would like to use it with my arduino uno. The new arduino uno needs to be a new mqtt gateway, so it has an ethernet shield as well.

Could someone help me to connect it correctly?

Thanks a lot!

Simon:

PS: Detailed thread about the software part is here:
https://forum.mysensors.org/topic/4042/mysensors-api-ver-1-6-1-mqttclientgateway-rf69-arduino-uno-w5100-shield?loggedin

Hello,

I've purchased this i2C level converter to use the RFM69 radio on my Arduino Uno:

http://www.ebay.it/itm/222115738795

Ehm, how do I use it

Thanks for the support!

PS: As written at the beginning of this thread, I need to use the Arduino Uno as a gateway, so it has the ethernet shield as well.

THANKS!

Simon

@martinhjelmare said:

@xefil

For the Uno you have to use a logic level converter to connect the RFM69.

Ok, I'll order one. My big doubt is if I can then use the radio RFM69 + the W5100 for a MQTTClientGateway. I've tested it only for W5100 with NRF24L01+ and I fear the MQTTClientgateway doen't work with RFM69.

If you use a Pro Mini 3.3 V you don't need a logic converter but you need to be able to decrease the baudrate at the controller for the serial connection to work, if using that gateway type.

Do you mean decrease it from 115200 to lower? Which speed? why?

Regarding ethernet gateway and SPI, I suggest you follow the build guide. I don't recommend the ENC module as it's notoriously hard to get working together with mysensors.

Ok to not use then ENC. I've followed the build guide, but, as written before, I think there is an incompatibility to use RFM69 and W5100 as gateway, especially as mqttclientgateway. Any experience would be great to be shared

Thanks,

Simon

Hi again to all!
Noone has suggestions or answers for what asked above?
I would have a ENC28J60 network controller. Would this help in solving the issue in any way?
Main goal: MQTTGatewayClient. Alternatives are accepted as well
Thanks!
Simon

Hi @scalz again
I've found this that could help to use SOFTSPI (https://github.com/gieemek/) but seems related to API 1.5 and I'm using 1.6 and it doesn't have the MQTTClient version.
I'm still in big doubt on WHY I have to use SOFTSPI. AFAYK it's 'cause it shares SPI and one of them needs to use software emulation.
If so, isn't enough if W5100 uses SOFT? But being a shield it's connected to the SPI port directly so the radio must be set to SOFT-SPI?

For the logic level converter it's something like that?
http://www.circuitointegrato.com/3071-thickbox_default/ebay.jpg
(IIC I2C level converter module, 5-3v system compatible, arduino sensor module)
Could I have damaged the radio without the level converter?

I would like to prevent buying more components and find out that I cannot reach the needed goal.

Any suggestion to create the MQTTClientGateway with the aboce hardware?

I'm using Openhab as Controller. Any other alternative could be apreciated.
I should have a Arduino Pro Mini 3.3V (so it doesn't require level converter) and could use the SerialGateway connecting it directly to the Raspberry Openhab?

Thanks!

Simon

@martinhjelmare
Hi, well. I'm not so proof with that at all. Feeding it with 3.3V I was thinking it's enough. Isn't the same as for the NRF24L01+. It has it own 3.3V pin on the shield. I've an Arduino Diemilanove with W5100 for the NRF24L01+ as MQTTClientGateway and it works great.

@scalz
Hi! For the 5v question see above.
For the pins, could you give me some pratical code hints based on the above sketch I've posted?

Thanks to all!

Simon

Hello to all!
I've moved my structure to the new API version 1.6.1 succesfully. Then I've recompiled the MQTT Gateway with my NRF24L01+ to use the MQTTClientGateway and send the messages to a mosquitto server. Until here all works well.
Now I would like to add a second radio network because seems (AFAYK) the RF69 has a better range. I'm starting to setup the MQTT Client Gateway but I'm getting always "check wires". Maybe the MQTT Client Gateway is not supported with the RF69?
Let's start with my hardware setup:

• Arduino Uno R3
• W5100 Shield
• HopeRF RFM69W 868Mhz

I've connected the radio as follow:

HopeRF RFM69W 868Mhz ----> Arduino W5100 Shield
3.3V -> 3.3V
Groud -> Ground
DI00 -> Digital 2
NSS -> Digital 6
MISO -> A2
MOSI -> A1
SCK -> A0

Then, into MyConfig.h I've set:

#define MY_SOFTSPI

Here both files:
mymqttgatewayrf69.ino

#include <SPI.h>

// Enable debug prints to serial monitor
#define MY_DEBUG 

// Enables and select radio type (if attached)
//#define MY_RADIO_NRF24
#define MY_RADIO_RFM69

#define MY_GATEWAY_MQTT_CLIENT

// Set this nodes subscripe and publish topic prefix
#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mygateway2-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mygateway2-in"

// Set MQTT client id
#define MY_MQTT_CLIENT_ID "mysensors-2"

// W5100 Ethernet module SPI enable (optional if using a shield/module that manages SPI_EN signal)
//#define MY_W5100_SPI_EN 4  

// Enable Soft SPI for NRF radio (note different radio wiring is required)
// The W5100 ethernet module seems to have a hard time co-operate with 
// radio on the same spi bus.
#if !defined(MY_W5100_SPI_EN) && !defined(ARDUINO_ARCH_SAMD)
  #define MY_SOFTSPI
  #define MY_SOFT_SPI_SCK_PIN 14
  #define MY_SOFT_SPI_MISO_PIN 16
  #define MY_SOFT_SPI_MOSI_PIN 15
#endif  

// When W5100 is connected we have to move CE/CSN pins for NRF radio
#define MY_RF24_CE_PIN 5
#define MY_RF24_CS_PIN 6

// Enable these if your MQTT broker requires usenrame/password
//#define MY_MQTT_USER "username"
//#define MY_MQTT_PASSWORD "password"

// Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
#define MY_IP_ADDRESS 192,168,1,52

// If using static ip you need to define Gateway and Subnet address as well
#define MY_IP_GATEWAY_ADDRESS 192,168,1,1
#define MY_IP_SUBNET_ADDRESS 255,255,255,0


// MQTT broker ip address.  
#define MY_CONTROLLER_IP_ADDRESS 192,168,1,50

// The MQTT broker port to to open 
#define MY_PORT 1883      

 /*
// Flash leds on rx/tx/err
#define MY_LEDS_BLINKING_FEATURE
// Set blinking period
#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Enable inclusion mode
#define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
#define MY_INCLUSION_BUTTON_FEATURE
// Set inclusion mode duration (in seconds)
#define MY_INCLUSION_MODE_DURATION 60 
// Digital pin used for inclusion mode button
#define MY_INCLUSION_MODE_BUTTON_PIN  3 

// Uncomment to override default HW configurations
//#define MY_DEFAULT_ERR_LED_PIN 16  // Error led pin
//#define MY_DEFAULT_RX_LED_PIN  16  // Receive led pin
//#define MY_DEFAULT_TX_LED_PIN  16  // the PCB, on board LED
*/

#include <Ethernet.h>
#include <MySensor.h>

void setup() { 
}

void presentation() {
  // Present locally attached sensors here    
}


void loop() {
  // Send locally attech sensors data here
}

MyConfig.h

/*
 * The MySensors Arduino library handles the wireless radio link and protocol
 * between your home built sensors/actuators and HA controller of choice.
 * The sensors forms a self healing radio network with optional repeaters. Each
 * repeater and gateway builds a routing tables in EEPROM which keeps track of the
 * network topology allowing messages to be routed to nodes.
 *
 * Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
 * Copyright (C) 2013-2015 Sensnology AB
 * Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
 *
 * Documentation: http://www.mysensors.org
 * Support Forum: http://forum.mysensors.org
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * version 2 as published by the Free Software Foundation.
 */

/**
 * @file MyConfig.h
 *
 * MySensors specific configurations
 */
#ifndef MyConfig_h
#define MyConfig_h
#include <stdint.h>


/**********************************
*  Serial and debug options
***********************************/

// Enables this in sketch to show debug prints. This option will add a lot to the size of the
// final sketch but is helpful to see what is actually is happening during development
//#define MY_DEBUG

// Enable MY_DEBUG_VERBOSE flag for verbose debug prints. Requires DEBUG to be enabled.
// This will add even more to the size of the final sketch!
//#define MY_DEBUG_VERBOSE

// Enable this in sketch if you want to use TX(1), RX(0) as normal I/O pin
//#define MY_DISABLED_SERIAL

// Turn off debug if serial pins is used for other stuff
#ifdef MY_DISABLED_SERIAL
#undef MY_DEBUG
#endif

// Serial output baud rate (debug prints and serial gateway speed)
#ifndef MY_BAUD_RATE
#define MY_BAUD_RATE 115200
#endif

// Disables over-the-air reset of node
//#define MY_DISABLE_REMOTE_RESET

/**********************************
*  Radio selection and node config
***********************************/

// Selecting uplink transport layer is optional (for a gateway node).

//#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69
//#define MY_RS485

// Node id defaults to AUTO (tries to fetch id from controller)
#ifndef MY_NODE_ID
#define MY_NODE_ID AUTO
#endif

// Node parent defaults to AUTO (tries to find a parent automatically)
#ifndef MY_PARENT_NODE_ID
#define MY_PARENT_NODE_ID AUTO
#endif

// Enables repeater functionality (relays messages from other nodes)
// #define MY_REPEATER_FEATURE

// The wait period before going to sleep when using smartSleep-functions
// This period has to be long enough for controller to be able to send out
// potential buffered messages.
#ifndef MY_SMART_SLEEP_WAIT_DURATION
#define MY_SMART_SLEEP_WAIT_DURATION 500
#endif

/**********************************
*  Over the air firmware updates
***********************************/

// Enable MY_OTA_FIRMWARE_FEATURE in sketch to allow safe over-the-air firmware updates.
// This feature requires external flash and the DualOptiBoot boot-loader.
// Note: You can still have OTA FW updates without external flash but it
// requires the MYSBootloader and disabled MY_OTA_FIRMWARE_FEATURE
//#define MY_OTA_FIRMWARE_FEATURE

// Slave select pin for external flash
#ifndef MY_OTA_FLASH_SS
#define MY_OTA_FLASH_SS 8
#endif

// Flash jdecid
#ifndef MY_OTA_FLASH_JDECID
#define MY_OTA_FLASH_JDECID 0x1F65
#endif


/**********************************
*  Gateway config
***********************************/

// Max buffersize needed for messages coming from controller
#ifndef MY_GATEWAY_MAX_RECEIVE_LENGTH
#define MY_GATEWAY_MAX_RECEIVE_LENGTH 100
#endif

// Max buffer size when sending messages
#ifndef MY_GATEWAY_MAX_SEND_LENGTH
#define MY_GATEWAY_MAX_SEND_LENGTH 120
#endif

// Max number of parallel clients (sever mode)
#ifndef MY_GATEWAY_MAX_CLIENTS
#define MY_GATEWAY_MAX_CLIENTS 1
#endif



/**********************************
*  Information LEDs blinking
***********************************/
// This feature enables LEDs blinking on message receive, transmit
// or if some error occurred. This was commonly used only in gateways,
// but now can be used in any sensor node. Also the LEDs can now be
// disabled in the gateway.

//#define MY_LEDS_BLINKING_FEATURE

// The following setting allows you to inverse the blinking feature MY_LEDS_BLINKING_FEATURE
// When MY_WITH_LEDS_BLINKING_INVERSE is enabled LEDSs are normally turned on and switches
// off when blinking

//#define MY_WITH_LEDS_BLINKING_INVERSE


// default LEDs blinking period in milliseconds
#ifndef MY_DEFAULT_LED_BLINK_PERIOD
#define MY_DEFAULT_LED_BLINK_PERIOD 300
#endif
// The RX LED default pin
#ifndef MY_DEFAULT_RX_LED_PIN
	#if defined(ARDUINO_ARCH_ESP8266)
		#define MY_DEFAULT_RX_LED_PIN 8
	#else
		#define MY_DEFAULT_RX_LED_PIN 6
	#endif
#endif
// The TX LED default pin
#ifndef MY_DEFAULT_TX_LED_PIN
	#if defined(ARDUINO_ARCH_ESP8266)
		#define MY_DEFAULT_TX_LED_PIN 9
	#else
		#define MY_DEFAULT_TX_LED_PIN 5
	#endif
#endif
// The Error LED default pin
#ifndef MY_DEFAULT_ERR_LED_PIN
	#if defined(ARDUINO_ARCH_ESP8266)
		#define MY_DEFAULT_ERR_LED_PIN 7
	#else
		#define MY_DEFAULT_ERR_LED_PIN 4
	#endif
#endif

/**********************************************
*  Gateway inclusion button/mode configuration
**********************************************/
// Enabled inclusion mode feature
//#define MY_INCLUSION_MODE_FEATURE

// Enables inclusion-mode button feature on the gateway device
//#define MY_INCLUSION_BUTTON_FEATURE

// Disable inclusion mode button if inclusion mode feature is not enabled
#ifndef MY_INCLUSION_MODE_FEATURE
#undef MY_INCLUSION_BUTTON_FEATURE
#endif

// The default input pin used for the inclusion mode button
#ifndef MY_INCLUSION_MODE_BUTTON_PIN
	#if defined(ARDUINO_ARCH_ESP8266)
		#define MY_INCLUSION_MODE_BUTTON_PIN 5
	#else
		#define MY_INCLUSION_MODE_BUTTON_PIN 3
	#endif
#endif
// Number of seconds (default one minute) inclusion mode should be enabled
#ifndef MY_INCLUSION_MODE_DURATION
#define MY_INCLUSION_MODE_DURATION 60
#endif

#if defined(MY_INCLUSION_BUTTON_EXTERNAL_PULLUP)
#define MY_INCLUSION_BUTTON_PRESSED HIGH
#else
#define MY_INCLUSION_BUTTON_PRESSED LOW
#endif

/**********************************
*  Message Signing Settings
***********************************/
/**
 * @def MY_SIGNING_ATSHA204
 * @brief Enables HW backed signing functionality in library.
 *
 * For any signing related functionality to be included, this define or @ref MY_SIGNING_SOFT has to be enabled.
 */
//#define MY_SIGNING_ATSHA204

/**
 * @def MY_SIGNING_SOFT
 * @brief Enables SW backed signing functionality in library.
 *
 * For any signing related functionality to be included, this define or @ref MY_SIGNING_ATSHA204 has to be enabled.
 */
//#define MY_SIGNING_SOFT

/**
 * @def MY_SIGNING_REQUEST_SIGNATURES
 * @brief Enable this to inform gateway to sign all messages sent to this node.
 *
 * If used for a gateway, gateway will only request signatures from nodes that in turn
 * request signatures from gateway.
 */
//#define MY_SIGNING_REQUEST_SIGNATURES

/**
 * @def MY_VERIFICATION_TIMEOUT_MS
 * @brief Define a suitable timeout for a signature verification session
 *
 * Consider the turnaround from a nonce being generated to a signed message being received
 * which might vary, especially in networks with many hops. 5s ought to be enough for anyone.
 */
#ifndef MY_VERIFICATION_TIMEOUT_MS
#define MY_VERIFICATION_TIMEOUT_MS 5000
#endif

/**
 * @def MY_SIGNING_NODE_WHITELISTING
 * @brief Enable to turn on whitelisting
 *
 * When enabled, a signing node will salt the signature with it's unique signature and nodeId.<br>
 * The verifying node will look up the sender in a local table of trusted nodes and
 * do the corresponding salting in order to verify the signature.<br>
 * For this reason, if whitelisting is enabled on one of the nodes in a sign-verify pair, both
 * nodes have to implement whitelisting for this to work.<br>
 * Note that a node can still transmit a non-salted message (i.e. have whitelisting disabled)
 * to a node that has whitelisting enabled (assuming the receiver does not have a matching entry
 * for the sender in it's whitelist). The whitelist to use is defined as the value of the flag.
 */
//#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0x09,0x08,0x07,0x06,0x05,0x04,0x03,0x02,0x01}}}

/**
 * @def MY_SIGNING_ATSHA204_PIN
 * @brief Atsha204 default pin setting
 *
 * Pin where ATSHA204 is attached
 */
#ifndef MY_SIGNING_ATSHA204_PIN
#define MY_SIGNING_ATSHA204_PIN 17
#endif

/**
 * @def MY_SIGNING_SOFT_RANDOMSEED_PIN
 * @brief Pin used for random generation in soft signing
 *
 * Do not connect anything to this when soft signing is enabled
 */
#ifndef MY_SIGNING_SOFT_RANDOMSEED_PIN
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
#endif

/**
 * @def MY_SIGNING_SOFT_SERIAL
 * @brief Serial number for SW signing enabled node
 *
 * Set the soft_serial value to an arbitrary value for proper security.
 * It should be random and unique for each node.
 */
#ifndef MY_SIGNING_SOFT_SERIAL
#define MY_SIGNING_SOFT_SERIAL 0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09
#endif

/**
 * @def MY_SIGNING_SOFT_HMAC_KEY
 * @brief Key to use for HMAC calculation in MySigningAtsha204Soft (32 bytes)
 */
#ifndef MY_SIGNING_SOFT_HMAC_KEY
#define MY_SIGNING_SOFT_HMAC_KEY 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
#endif

/**********************************
*  RS485 Driver Defaults
***********************************/

#ifndef MY_RS485_BAUD_RATE
#define MY_RS485_BAUD_RATE 9600
#endif

#ifndef MY_RS485_MAX_MESSAGE_LENGTH
#define MY_RS485_MAX_MESSAGE_LENGTH 40
#endif

/**********************************
*  NRF24L01 Driver Defaults
***********************************/

// Enables RF24 encryption (all nodes and gateway must have this enabled)
//#define MY_RF24_ENABLE_ENCRYPTION

// Default encryption key. Override in sketch if needed.
#ifndef MY_RF24_ENCRYPTKEY
#define MY_RF24_ENCRYPTKEY 0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x10,0x11,0x12,0x13,0x14,0x15,0x16
#endif

// Default pin settings. Override in sketch if needed.
#ifndef MY_RF24_CE_PIN
	#if defined(ARDUINO_ARCH_ESP8266)
		#define MY_RF24_CE_PIN 4
	#elif defined(ARDUINO_ARCH_SAMD)
		#define MY_RF24_CE_PIN 27
	#else
		#define MY_RF24_CE_PIN 9
	#endif
#endif

#ifndef MY_RF24_CS_PIN
	#if defined(ARDUINO_ARCH_ESP8266)
		#define MY_RF24_CS_PIN 15
	#elif defined(ARDUINO_ARCH_SAMD)
		#define MY_RF24_CS_PIN 3
	#else
		#define MY_RF24_CS_PIN 10
	#endif
#endif

#ifndef MY_RF24_PA_LEVEL
#define MY_RF24_PA_LEVEL RF24_PA_MAX
#endif
// RF channel for the sensor net, 0-127
#ifndef MY_RF24_CHANNEL
#define MY_RF24_CHANNEL	76
#endif
//RF24_250KBPS for 250kbs, RF24_1MBPS for 1Mbps, or RF24_2MBPS for 2Mbps
#ifndef MY_RF24_DATARATE
#define MY_RF24_DATARATE RF24_250KBPS
#endif
// This is also act as base value for sensor nodeId addresses. Change this (or channel) if you have more than one sensor network.
#ifndef MY_RF24_BASE_RADIO_ID
#define MY_RF24_BASE_RADIO_ID ((uint64_t)0xA8A8E1FC00LL)
#endif

// Enable SOFTSPI for NRF24L01, useful for the W5100 Ethernet module
#define MY_SOFTSPI

#ifndef MY_SOFT_SPI_SCK_PIN
#define MY_SOFT_SPI_SCK_PIN 14
#endif
#ifndef MY_SOFT_SPI_MISO_PIN
#define MY_SOFT_SPI_MISO_PIN 16
#endif
#ifndef MY_SOFT_SPI_MOSI_PIN
#define MY_SOFT_SPI_MOSI_PIN 15
#endif

/**********************************
*  RFM69 Driver Defaults
***********************************/

// Default frequency to use. This must match the hardware version of the RFM69 radio (uncomment one):
#ifndef MY_RFM69_FREQUENCY
// #define MY_RFM69_FREQUENCY   RF69_433MHZ
#define MY_RFM69_FREQUENCY   RF69_868MHZ
//#define MY_RFM69_FREQUENCY     RF69_915MHZ
#endif

// Enable this if you're running the RFM69HW model
#ifdef MY_IS_RFM69HW
	#define MY_RFM69HW true
#else
	#define MY_RFM69HW false
#endif

// Default network id. Use the same for all nodes that will talk to each other
#ifndef MY_RFM69_NETWORKID
#define MY_RFM69_NETWORKID     100
#endif
#ifndef MY_RF69_IRQ_PIN
#define MY_RF69_IRQ_PIN RF69_IRQ_PIN
#endif
#ifndef MY_RF69_SPI_CS
#define MY_RF69_SPI_CS RF69_SPI_CS
#endif
#ifndef MY_RF69_IRQ_NUM
	#if defined(ARDUINO_ARCH_ESP8266)
		#define MY_RF69_IRQ_NUM MY_RF69_IRQ_PIN
	#else
		#define MY_RF69_IRQ_NUM RF69_IRQ_NUM
	#endif
#endif

// Enable this for encryption of packets
//#define MY_RFM69_ENABLE_ENCRYPTION
#ifndef MY_RFM69_ENCRYPTKEY
#define MY_RFM69_ENCRYPTKEY    "sampleEncryptKey" //exactly the same 16 characters/bytes on all nodes!
#endif

/**************************************
* Ethernet Gateway Transport  Defaults
***************************************/

// The gateway options available
//#define MY_GATEWAY_W5100
//#define MY_GATEWAY_ENC28J60
//#define MY_GATEWAY_ESP8266

// The port to open on controller or gateway
#ifndef MY_PORT
#define MY_PORT 5003
#endif

// Static ip address of gateway (if this is disabled, DHCP will be used)
//#define MY_IP_ADDRESS 192,168,178,66

// Enables UDP mode for Ethernet gateway (W5100)
//#define MY_USE_UDP

// DHCP, default renewal setting
#ifndef MY_IP_RENEWAL_INTERVAL
#define MY_IP_RENEWAL_INTERVAL 60000
#endif

#ifndef MY_MAC_ADDRESS
#define MY_MAC_ADDRESS 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED
#endif

// Controller ip-address, if this is defined, gateway will act as a client trying to contact controller on MY_PORT.
// If MY_CONTROLLER_IP_ADDRESS is left un-defined, gateway acts as server allowing incoming connections.
//#define MY_CONTROLLER_IP_ADDRESS 192, 168, 178, 254

#endif
// Doxygen specific constructs, not included when built normally
// This is used to enable disabled macros/definitions to be included in the documentation as well.
#if DOXYGEN
#define MY_SIGNING_ATSHA204
#define MY_SIGNING_SOFT
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0x09,0x08,0x07,0x06,0x05,0x04,0x03,0x02,0x01}}}
#endif

If I try to start the node:

0;255;3;0;9;Starting gateway (RRNGA-, 1.6.0-beta)
0;255;3;0;9;Radio init failed. Check wiring.

Any idea or help?

Thanks!!

Simon

Ok, thank you!
Should be enough something like that?

int parntNode = _nc.parentNodeId;

L'll give it a try.

Thank's!

Simon
PS: I've seen I could query as well 'distance'

Hello,

I'm using succesfully the new development library.
If I set the parent to AUTO and enable the debug mode, I can see which parent was choosen.
I would like to save this output to a variable.
Can I query (maybe during presentation) the parent I get during the discovery? How?
Thanks'

Simon

Oh, maybe that's exactly the case:

https://github.com/openhab/openhab/wiki/MQTT-Binding#item-binding-configuration-for-inbound-messages

It writes:

direction: This is always "<" for inbound messages.

So, having those 3 arguments in the original version:

1. ">[mysensor:mygateway1-in/20/2/1/0/2:command:ON:1]"
2. ">[mysensor:mygateway1-in/20/2/1/0/2:command:OFF:0]"
3. "<[mysensor:mygateway1-in/20/2/1/0/2:command:MAP(1on0off.map)]" "

I think it means:

1. outbount to turn ON
2. outbount to turn OFF
3. INBOUND to check

So, I need to change 'mygateway1-in' to 'mygateway1-out'. This would explain why I was going in loop.

I THINK AT LEAST.

I'll give a try this evening.

Simon

Hello!

I've converted the entry from:

Switch  node20_sw2      "Luce Stufa"    (all,node20)            { mqtt=">[mysensor:mygateway1-in/20/2/1/0/2:command:ON:1],>[mysensor:mygateway1-in/20/2/1/0/2:command:OFF:0],<[mysensor:mysensor:mygateway1-in/20/2/1/0/2:command:MAP(1on0off.map)]" }

to:

Switch  node20_sw2      "Luce Stufa"    (all,node20)            { mqtt=">[mysensor:mygateway1-in/20/2/1/0/2:command:ON:1],>[mysensor:mygateway1-in/20/2/1/0/2:command:OFF:0]" }

And now works.
BTW I need to understood better why, removing the last part, it works. Does this query the status? In this case, then the solution could be right as written by you @drock1985 . Maybe in that case I should ask with mygateway1-out.

Simon

Hello to all!

I've used OpenHAB with MQTT Gateway for a while without issues.
Now I would like to use local MQTT (mosquitto) and use the MQTTClientGateway to publish/subscribe to mosquitto the messages.
Manually works all well. I can publish manually commands and and the relays on the remote node starts or stops.
BUT, when I configure OpenHAB, changing the publish address, it creates a loop ON/OFF as soon I try to turn a light on. Seems disco

This is the old binding using MQTT Gateway (not client):

Switch  node20_sw2      "Relay02"  (all,node20)            { mqtt=">[mysensor:MyMQTT/20/2/V_LIGHT:command:ON:1],>[mysensor:MyMQTT/20/2/V_LIGHT:command:OFF:0],<[mysensor:MyMQTT/20/2/V_LIGHT:command:MAP(1on0off.map)]" }

This has worked very well.

Now I'm using this:

Switch  node20_sw2      "Luce Stufa"    (all,node20)            { mqtt=">[mysensor:mygateway1-in/20/2/1/0/2:command:ON:1],>[mysensor:mygateway1-in/20/2/1/0/2:command:OFF:0],<[mysensor:mysensor:mygateway1-in/20/2/1/0/2:command:MAP(1on0off.map)]" }

It happens that OpenHAB sends out the message, and I got a reply message back which is replied i immediatly with an OFF:

21:22:30.396 [DEBUG] [.mqtt.internal.MqttItemBinding:44   ] - Publishing command ON to mygateway1-in/20/2/1/0/2
21:22:30.398 [DEBUG] [o.i.t.m.i.MqttBrokerConnection:437  ] - Publishing message 2680 to topic 'mygateway1-in/20/2/1/0/2'
21:22:30.401 [DEBUG] [.mqtt.internal.MqttItemBinding:44   ] - Publishing command ON to mygateway1-in/20/2/1/0/2
21:22:30.402 [DEBUG] [o.i.t.m.i.MqttBrokerConnection:437  ] - Publishing message 2681 to topic 'mygateway1-in/20/2/1/0/2'
21:22:30.405 [DEBUG] [.mqtt.internal.MqttItemBinding:44   ] - Publishing command ON to mygateway1-in/20/2/1/0/2
21:22:30.407 [DEBUG] [o.i.t.m.i.MqttBrokerConnection:437  ] - Publishing message 2682 to topic 'mygateway1-in/20/2/1/0/2'
21:22:30.422 [DEBUG] [.mqtt.internal.MqttItemBinding:44   ] - Publishing command OFF to mygateway1-in/20/2/1/0/2
21:22:30.424 [DEBUG] [o.i.t.m.i.MqttBrokerConnection:437  ] - Publishing message 2683 to topic 'mygateway1-in/20/2/1/0/2'
21:22:30.427 [DEBUG] [.mqtt.internal.MqttItemBinding:44   ] - Publishing command OFF to mygateway1-in/20/2/1/0/2
21:22:30.429 [DEBUG] [o.i.t.m.i.MqttBrokerConnection:437  ] - Publishing message 2684 to topic 'mygateway1-in/20/2/1/0/2'
21:22:30.432 [DEBUG] [.mqtt.internal.MqttItemBinding:44   ] - Publishing command OFF to mygateway1-in/20/2/1/0/2
21:22:30.434 [DEBUG] [o.i.t.m.i.MqttBrokerConnection:437  ] - Publishing message 2685 to topic 'mygateway1-in/20/2/1/0/2'
21:22:30.450 [DEBUG] [.mqtt.internal.MqttItemBinding:44   ] - Publishing command ON to mygateway1-in/20/2/1/0/2
21:22:30.452 [DEBUG] [o.i.t.m.i.MqttBrokerConnection:437  ] - Publishing message 2686 to topic 'mygateway1-in/20/2/1/0/2'
21:22:30.455 [DEBUG] [.mqtt.internal.MqttItemBinding:44   ] - Publishing command ON to mygateway1-in/20/2/1/0/2
21:22:30.457 [DEBUG] [o.i.t.m.i.MqttBrokerConnection:437  ] - Publishing message 2687 to topic 'mygateway1-in/20/2/1/0/2'
21:22:30.459 [DEBUG] [.mqtt.internal.MqttItemBinding:44   ] - Publishing command ON to mygateway1-in/20/2/1/0/2
21:22:30.461 [DEBUG] [o.i.t.m.i.MqttBrokerConnection:437  ] - Publishing message 2688 to topic 'mygateway1-in/20/2/1/0/2'

What's going on?

Thanks!

Simon

Thanks a lot for pointing me to the right place! Now it compiles correctly.
It's only to understand if it works. Cannot test it here right now. I'll do it soon!
Thank you

Simon

Thanks @korttoma but, if I remove:

MySensor gw;

and then move from:

gw.begin(incomingMessage, 20, true, 0);

to:

begin(incomingMessage, 20, true, 0);

I get

\arduino-1.6.1\libraries\MySensors/MySensor.h:223:3: error: #error No forward link or gateway feature activated. This means nowhere to send messages! Pretty pointless.
  #error No forward link or gateway feature activated. This means nowhere to send messages! Pretty pointless.
   ^
my-example.ino: In function 'void setup()':
my-example.ino:128:37: error: 'begin' was not declared in this scope
(...)

Hello,

I know it's in development, but I've moved to library 1.5 DEVEL to test the MQTT clientforwarder.
Now, I'm trying to compile an old sketch that worked on previous libraries and it fails here:

In file included from my-example.ino:17:0:

\arduino-1.6.1\libraries\MySensors/MySensor.h:223:3: error: #error No forward link or gateway feature activated. This means nowhere to send messages! Pretty pointless.
  #error No forward link or gateway feature activated. This means nowhere to send messages! Pretty pointless.
   ^
my-example.ino:109:1: error: 'MySensor' does not name a type
my-example.ino: In function 'void setup()':
my-example.ino:129:3: error: 'gw' was not declared in this scope
my-example.ino: In function 'void loop()':
my-example.ino:190:3: error: 'gw' was not declared in this scope
my-example.ino: In function 'void incomingMessage(const MyMessage&)':
my-example.ino:298:6: error: 'gw' was not declared in this scope

Line 109 is where i declare MySensor outside any void:

MySensor gw;

Line 129 in void setup() :

gw.begin(incomingMessage, 20, true, 0);

Line 190 - in void loop() :

gw.process();

Line 298 - in void incomingMessage(const MyMessage &message) {:

gw.saveState(message.sensor, message.getBool());

Any suggestion?

Thanks!

Simon

Thank you! I'll look on there.

Simon

Where can I find this board?
BTW cannot do I the same with the above components?
Now I'm ok with the battery at least. A 1000mA should be enough
And, 1W solar panel at 6V?