Firmware upgrade versions

[rodime]

Ok, so I powered down, then enabled the J14 shunt with the MPU still in place, but on powering up, comfort would not respond.

I had to power down again and remove the MPU and then when powering back up, Comfort responds, and all back to firmware 5.045. So you were correct that the MPU must not be in place AS WELL as J14 shorted, to revert to the original firmware.

Then I updated responses, powered down, removed the shunt, resit the MPU, powered on. So back to firmware 7.164. All working.

It\'s a lot of hassle for sure, not to mention noisy (alarm). I do agree with the need to get the UCM/ETH and upgrade to Comfigurator 3 so Comfigurator updates can be done without this process, but not there yet...So in the meantime...

...after setting the Sunrise and Sunset times in Comfigurator according to London, then updating through Firmware 5.045, then re-enabling the MPU firmware 7.164, I\'m having issues with the NightTime flag. We are in week 7 so for London, NightTime should be enabled at 1708, but its now 1821 and is showing as 0. Am I missing something in the way the Sunset and Sunrise times are coded into comfort and how they relate to the NightTime flag? I\'m simply using a NightTime = 0 condition to determine day and 1 for night, I don\'t have to reference Sunrise or Sunset anywhere in code in addition, they are automatically reflected in NightTime flag correct?

Or is it possibly that the Sunset and Sunrise times did not take in the Comfigurator update, because I was updating with the original 5.045 firmware in place and the minimum is 5.110?. My understanding however was that the configuration including sunset/sunrise times are contained in the Eeprom, not the firmware, so once updated, even though 5.045 was in place during the update, it should then work properly when MPU with firmware 7.164 is in place?

BTW comfort system date and time is correctly set.

[slychiu]

I could not find a condition If Night Time in Comfigurator 2, while it is there for Comfiguratir 3. How did you create this condition. My apologies as it has been a long time since I used Comfigurator 2

[rodime]

Attached screenshot of Comfigurator 2 help topic.

The strange thing is that since the above mentioned PC to Comfort update and then reapplying the MPU, NightTime is seemingly returning 0 regardless of the time, wheres first time I installed the MPU without having yet done any response update at that point (Nightime condition was already in the code), I was getting both 0 and 1 after the initial MPU install. Prior to the MPU install using the base firmware 5.045, it was always 0.

So again, I\'m not sure if I am doing anything wrong in code, but simply I am applying the If NightTime = 0 condition for daytime, without any other reference to sunset or sunrise anywhere else in code. And per above, it was working previously on initially installing the MPU.

[slychiu]

That is puzzling. Note that the Night time flag will change to 1 only by passing through the actual time, and not by changing the time after the night time.

However can you test by changing the time to 1 minute before the night time, and waiting until the night time. Then check if the flag changes

[rodime]

Separately, another one of the sensors had stopped working, and now that that has been replaced it is now responding properly to the NightTime flag in a triggered response. But the one I\'m referring to above is still not. The code is identical except for the Lighting group references, which were all working before and nothing changed there.

It doesn\'t make sense that one response is now working and the other isn\'t so I suspect something else at play like a wiring fault, which would be a coincidence since nothing has been changed, but I\'ll do some more digging and double check the responses and logs also.

I\'ve ordered the UCM/ETH anyway now, and will do the update to Comfigurator 3. it won\'t do to create neighbourly nuisance if I have to update anything again in the responses with the MPU swap method otherwise.

I\'ll let you know once I\'ve found the issue.

[slychiu]

Yes it seems like a wiring fault. You can test the troggering of the sensors in the Keypad F3,2 Security Check. This will announce the zones whenm they are triggered

[rodime]

Hi I have the UCM eth3 now and am running comfigurator 3.14.9 on the laptop, not installed to comfort yet.

I’ve opened the Comfigurator 2 CCL file and successfully converted to Comfigurator 3. Reviewing everything including responses, timers, counters, flags and everything seems to be intact and named correctly. I have noticed a few of the response numbers are different but no issues there?

I do have a UCM CBUS on this install - I’m assuming all the response commands are the same between comfigurator 2 and 3, nothing to update there?

I did a similar upgrade many years ago and seem to recall that there were a fair amount of changes I had to make to comfigurator 3 in the upgrade from 2, and that that might have had something to do with flag/counter names but I can’t see anything that needs changing in the new file on this occasion.

Is there anything I should be looking out for or should the conversion really be this straightforward, ie no changes needed?

[slychiu]

It seems good. I suggest you save the cclx file for Comfigurator3, tghn do write to Comfort. You can always write the old ccl file using Comfigurator 2 if needed

[rodime]

Ok, to be clear though I can’t use the UCM/ETH to write the Comfigurator 2 CCL though, I’d have to go back to the RS232 correct?

[slychiu]

You are right. The UCM/ETH03 needs Comfigurator 3