Gateway to hands out node ID's
-
This is not implemented in the gateway code, as it's "always" been the job of the attached controller.
@tbowmo said:
This is not implemented in the gateway code, as it's "always" been the job of the attached controller.
I know it's "always" been the job of the attached controller but I have a scenario that the mqtt gateway will send directly to a cloud broker and an app that will receive it without any controller on the way. one problem I facing is the nodes id handing...so my question is if I would like to implement this in the GatewayESP8266MQTTClient.ino file is it possible?(check for incoming id request and 255 id number and saving current id handed in gateway eeprom etc...)
-
@tbowmo said:
This is not implemented in the gateway code, as it's "always" been the job of the attached controller.
I know it's "always" been the job of the attached controller but I have a scenario that the mqtt gateway will send directly to a cloud broker and an app that will receive it without any controller on the way. one problem I facing is the nodes id handing...so my question is if I would like to implement this in the GatewayESP8266MQTTClient.ino file is it possible?(check for incoming id request and 255 id number and saving current id handed in gateway eeprom etc...)
@Mickey - What happens if you fix a static node-id for each node?
-
@Mickey - What happens if you fix a static node-id for each node?
@sundberg84 it's need to be automatic. Fix id is easy to implement but because there will be an unknown number of nodes than I cannot use fix id's...
-
Internal messages does not get exposed in the receive() function of the sketch.
To archive this you would have to modify the core somewhere here:
https://github.com/mysensors/MySensors/blob/development/core/MyTransport.cpp#L706@hek said:
Internal messages does not get exposed in the receive() function of the sketch.
To archive this you would have to modify the core somewhere here:
https://github.com/mysensors/MySensors/blob/development/core/MyTransport.cpp#L706Thanks for answer.
I tried to figure where I change the internal msg type to be exposed to GW in the MyTransport.cpp around line 706 but can't seems to find it... -
Why pass it to the sketch? You could implement the id-handout directly in core (I pointed out the area where internal messages directed to the node is processed).
@hek said:
Why pass it to the sketch? You could implement the id-handout directly in core (I pointed out the area where internal messages directed to the node is processed).
To mess with core as little as I could so it can be easy upgradable in future (I already altered the MyGatewayTransportMQTTClient.cpp to support using dynamic connection parameters instead hard coded , I don't want to alter a lot of core files but if it necessary I will...)
-
So I went and change the MyTransport.cpp file and added a few lines around line 740:
uint8_t currentID; #if defined(MY_GATEWAY_FEATURE) if (type == I_ID_REQUEST) { currentID = hwReadConfig(0X123); //Read first byte of free conf eeprom space if(currentID==0xFF)//check to see if it was never changed (255)... {currentID = 1;} _msg.set(currentID); if(transportSendWrite(0xFF,_msg)) { hwWriteConfig(0X123,currentID+1) } } else // Hand over message to controllerBut the sensor still requesting an ID without getting it...
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login