Login

***slychiu*** · 05-09-2020, 02:38 AM

When you change the ID of a UCM/Generak, it us not necessary to change it manually in Comfigurator. Just scan for Modules and Comfigurator will assign it if it is found
UCM/general is always recommended to be set to ID 1 because this ID can be remo0ved without causing a Comms Failure. Sometimes UCMs are removed after programming, dfor Installers who program systems for customers. In your case the UCM is permanently attached so it does not matter as much
I suggest that you add the other ucms except the UCM/P which seems to be causing some problem, and see if the problem still occutrs
For Velbus and Zwave you can Read from EEPROM to read back the settings when the ID is changed

OhPinchy · 05-10-2020, 04:01 PM

Hi, I added the UCMGSM in as ID =2 and it is recognised no problem. To rule out issues with the wiring linking the Slave to the main Comfort panel, I wired it directly to the KA/KB ports on the main Comfort panel, and directly to the 12volts transformer nearby for power.
I set the dips to ID = 3 (1,3,4 ON,2 OFF) and hit reset on the UCMPi board and did a Scan All Modules in Comfigurator. It was not picked up. I tried this with and without the CM3+ module installed on the UCMPi board. I then tried to manually add a UCM in Comfigurator, set ID to 3, and type to Pi. When I did a scan for modules. this UCM was not found so I removed it (or it may have removed itself automatically, cannot recall).
I then connected a monitor and keyboard directly to the UCMPi board. What I found was I could boot up the Raspberry Pi OS and login, but it would execute a shutdown script and shutdown after a few seconds. While it was live, I could ping 8.8.8.8 no problem and the hostname it was reporting was the correct IP address. But then it would just shutdown and the ERR LED on the UCMPi board would then light up.
To check if it was maybe an issue with the CM3+ module, I took the 2nd CM3+ I have, flashed the Alphawerk image on it and then ran the NodeRed installation script (via the curl command). It would get quite far into the process, but ultimately would fail. And then it started doing the exact same thing as the other CM3+ module - it would shutdown after 20seconds or so.
I did notice that if I left the ethernet cable unplugged from the UCMPi board, the CM3+ would seem to not go into shutdown, it was staying on without issue. When I would plug in the ethernet cable, it would again run the set of shutdown commands within 20seconds.
Here is a video of the behaviour of the CM3+ module - it moved pretty fast so I could not make out what the command at the start was: link here.
Should Comfigurator be picking up the UCMPi board even without this issue being present, or would it seem they are related?
I will post a message on the Alphawerk Slack channel and see if they may recognise this shutdown behaviour from something they\'ve seen before, as hopefully understanding that may lead to resolving the issue.

OhPinchy · 05-11-2020, 09:59 AM

Hi,
A poster on the Alphawerk Slack channel suggested that he encountered similar shutdown issues and it was resolved by upgrading the firmware of the UCM/Pi so that is very encouraging. I looked at an old CCLX file from last week and can see the firmware is 7.118. I see on the Cytech website 7.125 is the latest version.
As I cannot see the UCM/Pi in Comfigurator, is there any way to upgrade the firmware via USB cable, or UCMEth03? Or do I need to use the programming cable approach?
I will search my cabinets and see if I have a programming cable, but would be good to know what options there may or may not be. Thanks

***slychiu*** · 05-11-2020, 11:52 AM

If UCM/Pi is not polled or not detected then you cannot upgrade the UCM/Pu firmware byu Cmfigurator aoine, You beed to yse the UCM Firmware programming cable which comes with the UCM. However I am not sure that upgrade from 7,118 to 7125 would have any effect
. But it may be useful in case the firmware is corrupted
Did you mention that the D9 red and D10 freen leds on the UCM/Pi are both blinking? They should be blinking in normal operation

OhPinchy · 05-11-2020, 05:21 PM

I found my programming cable, flashed the firmware to 7.125 and all worked right away - no changes needed to the image/software on the CM3+ and the LEDs started blinking correctly.
So all is thankfully up and running without issue now. I have my >60 zones all reporting status into NodeRed, so now I will use OpenHab to have those events drive Velbus lights turning on and off. This is fantastic functionality to have available, it really will take things to the next level for my installation.
I do find that I can\'t log into Comfigurator at times since the UCMPi has come back online. But I noticed a Signin Tamper error on the keypad when this happened and by entering my PIN code it removed it and I could login again from Comfigurator. Any idea what that might be caused by so I can watch out for it?
Thanks for the support....seems this matter is closed now and I\'ve learned a fair bit along the way in investigating it.

***slychiu*** · 05-12-2020, 04:59 AM

Sign i Tamper is caused bu wrog entry of sign in code 6 times
You can clear it by signing in with the correct code 2 times

OhPinchy · 05-12-2020, 09:54 AM

Thanks. That is the bit that is confusing me - I have not had any failed sign-ins, so am wondering why it goes into Signin Tamper mode. Now I know how to unlock it by clearing that error, it\'s not a big issue as I can still use Comfigurator now, but it would be good to understand what might be causing it if you have any ideas?

***slychiu*** · 05-13-2020, 02:15 AM

Check if it happens again with the new firmware. Problem in comunicaton could have caused some numbers of the code to be miseed
Sign in tamper is only caused by enterring the wrong code on any device ; keypad, ucm hone

OhPinchy · 05-16-2020, 10:56 AM

Hi, this is consistently happening now, even after the firmware upgrade. Comfort spends vast majority of its time in Signin Tamper mode despite zero incorrect attempts to enter the PIN code.
What else could be causing it? The NodeRed Alarm Mode nodes have the correct PIN code entered in msg.payload.passcode - it\'s entered as a number, it doesn\'t need to be inside quotation marks as per a string, correct?
I removed all keypads bar one from the wall and the kids can\'t reach that one, so incorrect PIN codes from kids is not causing it either.

***slychiu*** · (This post was last modified: 05-17-2020, 03:07 AM by slychiu.)

can you read the event log to see what is happening The sign in tampers should be recorded. That may give a clue about why why and when they are happening