RADIUSdesk

logo
Trace:

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision 		Previous revision
technical:openwrt-meshdesk-file [2022/09/18 13:02]
admin created 		technical:openwrt-meshdesk-file [2022/09/18 21:17] (current)
admin [Review new hardware]
Line 2: Line 2:
 ===== Background ===== ===== Background =====
   * MESHdesk use the LEDs of the device it is installed on to signal about the environment.   * MESHdesk use the LEDs of the device it is installed on to signal about the environment.
-        * It signals during startup about the method it uses to try and fetch its settings at that moment. +        * During startup one LED signals about the method it uses to try and fetch settings from the controller. 
-        * If the device is used in a mesh network it will signal how many neighboring nodes it sees after startup. +        * After startup, if the device is used in a mesh network it, this LED signals how many neighboring nodes it sees. 
-        * There is also another LED used to indicate if the device has proper contact with the controller. (The LED can be either ON or OFF in such a case) +        * A second LED is used to indicate if the device has proper contact with the controller. (The LED can be either ON or OFF in such a case) 
-        * Finally on mesh networks we can also specify a LED that will indicate mesh traffic flowing through a node.+        * Finally on mesh networks we can also specify a third LED that will indicate mesh traffic flowing through a node. 
 + 
 +===== Exploring our hardware ===== 
         * Lets look at the Xiaomi 4A 100M as a sample.         * Lets look at the Xiaomi 4A 100M as a sample.
 <code bash> <code bash>
Line 23: Line 26:
 </code> </code>
  
-  * In our case we can use the yellow LED to light up if the comms to the controller is broken. 
   * We can use the blue LED to signal during startup and neighbor counts.   * We can use the blue LED to signal during startup and neighbor counts.
-  * There is no extra LED so we will not define one for the mesh traffic. +  * We can also use the yellow LED to light up if communication to the controller is broken. 
-  * With this info we can create a hardware section in /etc/config/meshdesk+  * There is however not a third LED so we will not define one for the mesh traffic. 
 +  
 +===== Add a hardware section for our device ===== 
 + 
 +   * With this info we can create a hardware section in /etc/config/meshdesk
 <code bash> <code bash>
 config hardware 'xiaomi_4a_100' config hardware 'xiaomi_4a_100'
Line 33: Line 39:
  option wifi_led 'led0'  option wifi_led 'led0'
 </code> </code>
-  * This have to match the value for hardware under the settings section+ 
 +===== Adjust the settings section accordingly ===== 
 +  * There are two important options here to adjust 
 +        * **hardware** - have to match the value of a hardware definition under the settings section. 
 +        * **id_if** - have to match the interface specified in the **wan_network** file.
 <code bash> <code bash>
 config settings 'settings' config settings 'settings'
Line 40: Line 50:
  option lan_up_file '/tmp/lan_up'  option lan_up_file '/tmp/lan_up'
 </code> </code>
-<WRAP center round tip 90%> +<WRAP center round tip 100%> 
-Don't make the name of the hardware section more than 14characters. Longer names break things during deployment.+  * Don't make the name of the hardware section more than 14characters. Longer names break things during deployment. 
 +  * Devices where the interface used in wan_network is eth0.1 simply use eth0 here.
 </WRAP> </WRAP>
 +  * Later we will also use the value of **xiaomi_4a_100** to define the hardware on the controller.
 +===== Alarm On or Alarm Off?  =====
 +  * We use the yellow LED as an alarm which means it has to light up when communication to the controller is down.
 +  * Since we want the **yellow LED** to be off when the communication to the controller is fine we need to check what the current setup is.
 +<code bash>
 +vi /etc/MESHdesk/reporting/report_to_server.lua 
 +#Look for this section
 +    if(ok_flag)then                                 
 +        internetLED('0'); -- NOTE Here we can swap them around eg make it 0 to turn off a red LED when the internet is OK
 +        checkForContollerReboot('1');                   
 +    else                                                                             
 +        internetLED('1');                                                        
 +        checkForContollerReboot('0');                  
 +    end
 +</code>
 +
 +==== Review new hardware ====
 +
 +
 +  * The following table lists the important items with comments
 +
 +^ Item        ^ Typical value           ^ Comment    ^
 +| settings -> hardware | xiaomi_4a_100 | Must match a hw definition in the file itself  |
 +| settings -> id_if  | eth0 | eg eth0, eth1 or wan - NOT eth0.1 (for those boards its just eth0)  |
 +| settings -> skip_radio_0  | 0 | set to 1 when radio0 is a 5G radio and you don't want to use it for config SSID  |
 +
 +===== Remember Your Environment =====
 +  * Finally you need to adjust some items to match up with your controller and its environment.
 +  *  The following table lists some of the important items with comments 
 +
 +^ Item        ^ Typical value           ^ Comment    ^
 +| internet1 -> disabled    | 1  | change it to 0 in order for the device to be centrally controlled   |
 +| internet1 -> dns    | cloud.radiusdesk.com  | <wrap em>Supply Dummy Value If Not Using DNS System e.g. nohost.radiusdesk.com</wrap> |
 +| internet1 -> protocol | https | Can be http or https |
 +| internet1 -> ip | 176.31.15.210 | Fallback when FQDN does not resolve on FQDN not used |
 +
 +  * We are nearly done. The last stop is to edit the **captive_config.json** file to fit our specific hardware.
  
  
Last modified: 2022/09/18 13:02