Controllers not FTP'ing data to server
ZachParkerCR opened this issue · 8 comments
We have version 4.2 installed in our environment. We are running into a strange issue that seems to have started a while ago for some of our signal controllers. There is no data being pulled into our server from the controllers over FTP and because of that, no data is being added to the database and made visible for these controllers anymore. We have about 60 controllers that started exhibiting this behavior out of our 191 total controllers. So around 130 are working just fine.
I can still ping the controllers with their IP addresses so that seems good. But what could be causing the FTP process to fail to pull down data from the controllers? I'm not seeing any clear errors logged anywhere to see if these specific controllers are having issues.
Any guidance to send me in the right direction would be helpful!
Did you recently update the firmware on Econolite controllers?
If so, the path to the FTP files has likely changed, and you will have to update the configuration to match that change.
Did you recently update the firmware on Econolite controllers? If so, the path to the FTP files has likely changed, and you will have to update the configuration to match that change.
@shanejohnson-atspm
Shane, it looks like the problem controllers ARE the controllers that have received a new firmware. I am able to FTP into the controllers and I see the same folder "/set1" that contains the data files. But what has changed that I need to adjust on the application side so it properly pulls down that data?
The problem you will likely run into is in moe.common in SignalFtp.cs
The line is
if (!ftpClient.DownloadFile(SignalFtpOptions.LocalDirectory + Signal.SignalID + @"\" + localFileName, ".." + Signal.ControllerType.FTPDirectory + @"/" + ftpListItem.Name))
The ".." is where the problem comes in, as it means "go up one level form where I am". But, that is what you have to keep in mind when you craft the path in the devicetypes table.
Also, you will likely have to add a device type to that table in order for all of your controllers to work, as you have the newer ones with a different path than the older ones.
@shanejohnson-atspm, I am not a software developer, just a systems analyst and I'm trying to solve this problem, so my knowledge of editing lines of code is limited. Are you suggesting that I edit that line of code in the SignalFTP.cs file and remove the ".."? Where can I even find that SignalFTP.cs file on my server? I've looked in all the application folders and do not see that file.
The problem you will likely run into is in moe.common in SignalFtp.cs
The line is
if (!ftpClient.DownloadFile(SignalFtpOptions.LocalDirectory + Signal.SignalID + @"\" + localFileName, ".." + Signal.ControllerType.FTPDirectory + @"/" + ftpListItem.Name))
The ".." is where the problem comes in, as it means "go up one level form where I am". But, that is what you have to keep in mind when you craft the path in the devicetypes table.
Also, you will likely have to add a device type to that table in order for all of your controllers to work, as you have the newer ones with a different path than the older ones.
@shanejohnson-atspm , I have created a new device type row in the Controllers table. I'm still not quite sure how to format the FTPDirectory folder path in that row, though. But here is what I have to see if this works:
We have Cobalt controllers, some with the new firmware and most without the new firmware. I know the folder path on the controllers with the new firmware for the .DAT files is "/opt/econolite/set1". I'm just not sure how to format that file path in the database table to correctly get it to end up in the set1 folder.
@shanejohnson-atspm , I think I actually have it working now. I used the path "/econolite/set1" in the FTPDirectory and that correctly allows the /set1 path to be the location to pull files from. It's successfully pulling down data from the signal now!
I appreciate your help. I wouldn't have known where to start without your guidance. Have a great week, sir!