power issue was my 1st thought. I had that before when it wasn't good enough.
I just experienced also an issue with a gateway, I had to specify the MAC address (change to whatever you like)
#define MY_MAC_ADDRESS 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xAD
BR
SJ
@yveaux I think this was the issue.
I just found that
#define MY_MAC_ADDRESS 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xAD
will specify the MAC.
After adding it, no more issues. Changed back to same topics on both gateways, seems this is no problem.
Even the gateways received different IPs via DHCP, they had the same MAC. Haven't seen an issue in any logs.
I am not sure about long term, but short it works now. Let me see if it is a permanent fix.
Still pretty strange that I receive different IPs from my router for the same MAC.
Sometimes these are the easy fixes...
Thanks for your help!
thank you @Yveaux
I changed it. Still same issue. I do not see any in the logs now. So I have different topics, different channels. both here.
Both have different client ids, both different IP's
I am lost.
As soon as I connect the 2nd gateway to the network, turning on/off in sequence of one node works a few times, after 5/7 iterations it stops, then after a few seconds all messages appear in the gateway log, also on my mqtt-spy. So there is somewhere a hickup.
after disconnection, I can turn on/off 40-50 times and no issues at all.
looks like it is mosquitto as MQTT broker.
Can we specify the mac address? maybe there is the problem with the "cheap" network adapters...
hi @electrik
this is the log of the 2nd gateway. I am only receiving messages sent from the controller to the nodes, the temp sensors etc. on the other network are not visible on the 2nd gateway. They are both in the same room, now. So from radio perspective I think it is fine.
node 121 is the only one which should be dealt with this 2nd gateway.
If I understand it correct, for node 112 received comand to turn the lights on. The gateway says it is UNKNOWN and 112 is not reachable. So far so good.
Question is, does it also arrive on 1st gateway? what is it doing with it...
I think the "simple" fix will be changing the topic. Then it should be fine.
However still thinking that there is something odd
0;255;3;0;9;TSF:MSG:READ,121-121-0,s=1,c=1,t=0,pt=7,l=5,sg=0:25.1
0;255;3;0;9;Sending message on topic: hefti-out/121/1/1/0/0
0;255;3;0;9;TSF:MSG:READ,121-121-0,s=0,c=1,t=1,pt=7,l=5,sg=0:56.5
0;255;3;0;9;Sending message on topic: hefti-out/121/0/1/0/1
0;255;3;0;9;TSF:MSG:READ,121-121-0,s=255,c=3,t=0,pt=1,l=1,sg=0:96
0;255;3;0;9;Sending message on topic: hefti-out/121/255/3/0/0
0;255;3;0;9;Message arrived on topic: hefti-in/112/0/1/0/3
0;255;3;0;9;!TSF:MSG:SEND,0-0-112-112,s=0,c=1,t=3,pt=0,l=2,sg=0,ft=0,st=NACK:62
0;255;3;0;9;Message arrived on topic: hefti-in/113/0/1/0/3
0;255;3;0;9;!TSF:RTE:113 UNKNOWN
0;255;3;0;9;!TSF:MSG:SEND,0-0-113-113,s=0,c=1,t=3,pt=0,l=2,sg=0,ft=0,st=NACK:79
0;255;3;0;9;Message arrived on topic: hefti-in/117/0/1/1/2
0;255;3;0;9;!TSF:RTE:117 UNKNOWN
0;255;3;0;9;!TSF:MSG:SEND,0-0-117-117,s=0,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
0;255;3;0;9;Message arrived on topic: hefti-in/102/0/1/1/2
0;255;3;0;9;!TSF:RTE:102 UNKNOWN
0;255;3;0;9;!TSF:MSG:SEND,0-0-102-102,s=0,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1
0;255;3;0;9;Message arrived on topic: hefti-in/113/0/1/0/3
0;255;3;0;9;!TSF:RTE:113 UNKNOWN
0;255;3;0;9;!TSF:MSG:SEND,0-0-113-113,s=0,c=1,t=3,pt=0,l=1,sg=0,ft=0,st=NACK:0
0;255;3;0;9;Message arrived on topic: hefti-in/112/0/1/0/3
0;255;3;0;9;!TSF:MSG:SEND,0-0-112-112,s=0,c=1,t=3,pt=0,l=1,sg=0,ft=0,st=NACK:0```@electrik thanks.
I would hope that they are just connected to the one they can talk to (via radio), right?
Anyhow it is a bit complicated to debug them, they are in places where I cannot bring my PC.
When I uploaded the 2nd one and had the first sensor ready, I noted in the log, that also messages from other sensors appeared but mentioned something that I cannot remember but something like "ignoring message".
So this would be very strange if this is an issue as repeater nodes are all over the place and never had any issues.
I am just thinking how many people do have a similar setup with gateways on different IDs and same MQTT topic.
Will try to change the topic, then I can also get some hints from the log potentially.
Hi there!
I have one MQTT gateway. All worked very well. Then added a 2nd gateway on a different channel and in my basement. There is no radio contact between the two.
My configuration:
// Set this node's subscribe and publish topic prefix
#define MY_MQTT_PUBLISH_TOPIC_PREFIX "hefti-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "hefti-in"
// Set MQTT client id
#define MY_MQTT_CLIENT_ID "hefti-3"
both Gateways have different client IDs, but same publish/subscribe topics.
It sometimes takes up to 30 seconds until a message is received by a sensor node (turning lights on), sometimes it is fast. turn it on/off several times, works very unpredictable.
After pulling the plug on the 2nd gateway, all works again.
Any ideas? Do I need to choose different publish/subscribe ID's for this? Or possibly QOS of the MQTT broker?
Thanks!
SJ
@zboblamont I have to agree to this.
With OpenHAB, every child is more or less treated as an individual device (item). No matter if there is one or 100 connected to one arduino.
On the other hand, I do not think that more powerful devices will change dramatically. I think with sensor networks, decentralization and loose coupling with a gateway which just translates it into a common language is what is key. Putting additional intelligence into the nodes or gateways is not what I would expect and want.
I am running a lot on mySensors. But I also do have other brands deplyed. It is quite easy to exchange one against the other. The logic and intelligence is in the controller which makes it most flexible.
@alowhum most of the time it is the other way round that there are not enough input pins on the arduino to connect all sensors.
I never had an issue with childs and what is the difference on controller side?
@zboblamont well, looks like you thought it through. I should move my write access of the RPi also to an HDD, currently just limiting and having a 2nd on standby in case my master fails.
Never had any boot issues though.
Back to the topic:
I have a solar charged weather station and had some issues on reliability. Did quite some testing and ended up building it new. The battery is a simple lion 3.7/4.2 and solar panels usually have much higher output. So bought this and did work well
https://www.aliexpress.com/item/DC-6-24V-12V-24v-to-5V-USB-Output-charger-step-down-Power-Module-Mini-DC/32692500351.html?spm=2114.search0104.3.110.7d863cbbudQu7N&ws_ab_test=searchweb0_0,searchweb201602_2_10065_10068_10890_5730315_319_10546_317_10548_5728815_10696_453_10084_454_10083_10618_5729215_10307_537_536_10134_5733215_5733315_328_10059_10884_5733115_10887_100031_5733415_321_322_5732515_10103_5733515_5733615-10890,searchweb201603_55,ppcSwitch_0&algo_expid=7e5645cc-8270-475b-97a5-d40894e33c53-15&algo_pvid=7e5645cc-8270-475b-97a5-d40894e33c53
not sure if this has enough amps for a RPi
I have a powerbank with a USB-DC adapter connected to my RPi. Most likely the battery will die when I do not expect it to happen...
However you spoke about 100% reliability. Whatever you'll build in front of the RPi, it will not be safe enough: At some point, the RPi will fail with its SD-card.
So for me, thinking too much is overkill. There are too many points of failure unfortunately. And if main power is down, a battery powered RPi and sensors don't help much, the pumps, motors and other stuff will be out of service anyway.
Sorry for OT.