Can't find 2nd Extender

I ran both the scanandfix as well as the MQTT capture.   The scan and fix only finds the one active:

[email protected]:~/SDL_Pi_SmartGarden3 $ sudo python3 scanAndFixExtenders.py

before running, stop SG3.py if it is running (hit return when ready)

SGS.JSON File exists

JSONData from File= {'key': 'value', 'ProgramName': 'SmartGarden3', 'ConfigVersion': '001', 'SWDEBUG': True, 'enable_MySQL_Logging': True, 'English_Metric': False, 'MySQL_Password': 'password', 'mailUser': '[email protected]', 'mailPassword': 'Getout66', 'notifyAddress': '[email protected]', 'fromAddress': '[email protected]', 'enableText': True, 'textnotifyAddress': '[email protected]', 'INTERVAL_CAM_PICS__SECONDS': '60', 'REST_Enable': False, 'Camera_Night_Enable': False, 'MQTT_Enable': False, 'MQTT_Server_URL': '', 'MQTT_Port_Number': '1883', 'MQTT_Send_Seconds': '500', 'manual_water': True, 'Send_Status_Email': False, 'Status_Send_Email_Minutes': '300', 'Send_Status_Text': False, 'Status_Send_Text_Minutes': '300', 'Tank_Pump_Level_Full': '500', 'Tank_Pump_Level_Empty': '900', 'Infrared_High_Auto_Gain': False, 'Infrared_Low_Auto_Gain': False, 'Infrared_Low_Temp': '17.0', 'Infrared_High_Temp': '22.0', 'WirelessDeviceJSON': [{'return_value': 0, 'id': '8F2D', 'name': '', 'ipaddress': '192.168.64.18', 'hardware': 'esp32', 'hydroponicsmode': 'false', 'return_string': '8F2D,1,1,1,1,0,1,1,0,0,060', 'connected': True, 'hydroponics_temperature': 'false', 'hydroponics_tds': 'false', 'hydroponics_ph': 'false', 'hydroponics_turbidity': 'false', 'hydroponics_level': 'false'}]}

mailuser: [email protected]

mailPassword: <removed>
Wireless Device ID 8F2D Active

All devices found

Scan and Fix Extenders Complete

Restart SG3.py


Looking at the MQTT, it prints the system sending a publish request to "SGS/529D/Valves" but there is no answer. I'm not sure where the 529D mac address is coming from?   It does send and receive pings from the extender that is running, with valves (SGS/8F2D) as well as a SUBSCRIBE command with an acknowledgement (I assume because it's in the database).

Looking at my UI controller (which assigns IP addresses based on MAC address), it does see both extenders:
1) the one working with a mac address ending in 8f:2c at 192.168.61.18 (which I assume is the 8F2D that MQTT is talking to although I didn't know there were 2 mac addresses per extender - i'm guessing one for BT, one for IP?)
2) the one that won't register with a mac address ending in 27:04 at 192.168.64.17.   Could that be the one the MQTT is trying to talk to, listing a publish request to 52:9D?    I dont see anything close to that in my overall UI controller list if there are 2 consecutive MAC addresses as appears to be the case with the functioning extender (8F2C talking to network, 8F2D talking to sensors).  See below:
 



I can try and manually add the second extender into the database although I'm not sure where, and I have no sensors associated with it.

I ran a scan again from the configuration utility just to see if something changes but no - still only sees the original one.

Any ideas on next steps?

Not sure when you mention "the other JSON" file - this is the one on the Pi that I was using to control both of these. At least it was the printout coming from the test utility. However, here are the two JSON files in the directory (the New Document is the SGS JSON with the PWD removed). The email password in the prior post was removed from the file, hence the <removed>, but I appreciate the reminder - have seen that elsewhere so i caught it when i first typed it.

I have the moving but can't get it below 10mb, which won't upload above 3mb.  is there a dropbox or is there another way i can send it?   I pulled different images from the display and attached them as they transition, they are in numerical order from boot-up.   But let me know if there is a better way.

The display is mounted on a 3d printed mount that I'm making to hold a solarmax, the extender and relay, and an adafruit feather that monitors the solarmax, and does data logging.

I assume on the ARP you meant the 64.17 address....

Here is what came back:

[email protected]:/home $ ping 192.168.64.17
PING 192.168.64.17 (192.168.64.17) 56(84) bytes of data.
64 bytes from 192.168.64.17: icmp_seq=1 ttl=255 time=54.2 ms
64 bytes from 192.168.64.17: icmp_seq=2 ttl=255 time=66.3 ms
64 bytes from 192.168.64.17: icmp_seq=3 ttl=255 time=96.6 ms
^C
--- 192.168.64.17 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 54.178/72.345/96.566/17.828 ms
[email protected]:/home $ arp 192.168.64.17
Address HWtype HWaddress Flags Mask Iface
esp32-arduino.lan ether 0c:dc:7e:88:2f:04 C eth0
[email protected]:/home $

I assume the 3 digits on the LCD is simply a formatting issue trying to show the "04" and there is no leading zero specified in the print format, although I didn't look at the code.

Tried to the the reset - held both down for 15 seconds but it came back in the same statewith the 2F5 and couldnt be found by the configuration program on the pi. I tried another reset attempt but it came up in access point mode. I reset the wireless and tried again but same response.

I held both buttons down for 15 seconds but nothing happened until I released them (after something like an additional 5 seconds). Is this the proper process?

Just did 4 configurations but none made a difference - still showing 2F5 as device:

1) Press Aux, wait 10 sec, press reset, wait 2-3 seconds, release Aux then release Reset
2) Press Aux, wait 2-3 seconds, press reset, wait 2-3 , release Aux then release Reset
3) Press Aux, wait 15 seconds, press reset, wait 10 , release Aux then release Reset
4) Press Aux and reset at once, wait 10 , release Aux then release Reset

Is it possible to get another board to compare against? I'm willing to pay for it if the problem is on my side somewhere (pi, router etc). or return this one for a new one? I'm ok to keep trying but i do want to get something resolved fairly soon. Thanks!

Thanks of sending the board back. I got it yesterday and tested it today. It is what I expected. There is a bug that drops a leading zero! I'll fix it inversion 62. Shouldn't affect your new board!

BP