Topics created 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

@xefil thank you, happy new year!

@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

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

If you use that you will need to use the 5V because it has a regulator built in

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

Thank you!! Simon

@AWI Maybe I will switch to a Dallas DS18B20 sensor then. I don't really need to know the humidity anyway. I have been using DHT sensors around my house for a couple of years (mostly to keep track of the temperature) and they seem to be working fine. I haven't done any scientific tests but they all have around the same temperature. I also have some Dallas sensors which also seem to be fine. Nothing has been off enough for me to notice or question their accuracy. The main reason I switched from a DS18B20 to a DHT22 was because the library was smaller and I needed to trim down the flash memory in my sketch. Now that I am upgrading to MySensors 2.0 I have regained 7kb of memory just from the upgrade (I also upgraded the Arduino IDE).

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

Ok, but it's gone in 2.0.

@hek ok, thank you! I'll adopt your example as starting point. Many 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 }

If anyone answers @xefil's question above, please answer in this thread to avoid confusion. @xefil: Please don't post the same question in more than one place. People will waste their time answering in one thread while the question might have been answered in another thread already.

@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

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: ">[mysensor:mygateway1-in/20/2/1/0/2:command:ON:1]" ">[mysensor:mygateway1-in/20/2/1/0/2:command:OFF:0]" "<[mysensor:mygateway1-in/20/2/1/0/2:command:MAP(1on0off.map)]" " I think it means: outbount to turn ON outbount to turn OFF 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

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

Thank you! I'll look on there. Simon

You're welcome

Thanks a lot @AWI for the suggestions and explaination, even if it's a little difficult for me to understand. I have to take some other for other LED strips. So I'll take IRLZ34N or BUZ71 instead my BUZ91A so they didn't get so much hot. Simon

I had the same problem a few months ago. The problem solved powering the arduino from a different power supply. You can read a bout it here Node freezing up No more problems since

@matt-shepherd Never got the time to do it. Sorry

@xefil said: Thanks @hek and @kalle Sorry, but I'm not good to understand the debug of the scanners. In the RF24/examples/scanner/ the range is between 0000->->->7777 Those are the high order nibble of the channel byte. The low order nibble is just below it. The 125 channel numbers are printed "sideways" in hex. I would expect a list of channels between 1 and 13. You're thinking of wi-fi. This isn't wi-fi. In the second scanner (wiFi scanner found on arduino forum) It's more accurate. It seems noisy between channel 3 and 9. So, the questions are: What does default channel 76 mean? 2476Mhz? yes Would mean above channel 13, on channel 14. In this case these channels are free, based on the results. I've seen I can use: #define RF24_CHANNEL 76 //RF channel for the sensor net, 0-127 How to interpret the scanners result? Most of all the "RF24/examples/scanner/" which has an output I cannot identify in a channel. The bigger the number below the channel, the more active it is. I would like to understand the result and so choose the right channel, not only trying without knowing what I'm doing Thanks a lot for the support! Simon

@hek It works to have a feedback from the sensor, but this doesn't give a status if someone acts on the relay manually. BTW I've tested a similar approach. I send from the sensor a custom variable with the status of the relay. @gadu This is the best approach. This could handle the status of the relay even if manual activated. The return of the signal always give us the relay position. But it needs a different dual stepper relay. I'll try this as well soon. Thanks a lot to all! Simon

@pete1450 said: Based on this: http://www.mysensors.org/build/serial_api Example 1 id Node-id 0 Child-id 0 internal message no ack payload is type I_LOG_MESSAGE and your actual payload is "read: 21-20-0 s=0,c=1,t=0,pt=7,l=5:16.7" EDIT: I'm not sure if there is an easier place to get this, but I looked in the code for process where it prints "read" messages and found this to describe the payload. Send is also in there. Mysensor.cpp Line 221-222