Life4IoT

리눅스 usb-serial latency 값 줄이기

Life4IoT.rnd — Mon, 12 Feb 2024 20:58:31 +0900

JIG에서 UART 메시지를 이용하여 Target MCU의 펌웨어 업데이트 하는 기능이 있습니다.

Target MCU에 펌웨어 업데이트 시간을 줄이기 위해 MCU에서 지원하는 최대 baud_rate로 설정하고 리눅스에 설정되어 있는 usb-serial 장치의 latency_timer 값을 1로 설정 하였다.

usb-serial/devices/latency_timer란

usb-serial 장치에서 데이터 전송을 얼마나 자주 할 것인지를 결정하는 설정 입니다.

이 값은 USB 버스에서 장치가 데이터 패킷을 보내는 빈도를 조절 합니다.

예를 들어, 'latency_timer'가 낮은 값으로 설정되어 있다면, 시스템은 더 자주 데이터를 보내게 되어 실시간성이 좋아 지지만 전체 처리량은 감소 할 수 있습니다.

반대로 'latency_timer'가 높은 값으로 설정되면, 데이터 전송은 덜 자주 일어나지만 더 큰 데이터 덩어리를 한번에 보낼 수 있어 전체적인 네트워크 처리량은 증가 할 수 있습니다.

latency_timer를 수동으로 줄이는 방법

아래와 같은 스크립트를 작성하고 실행하면, /sys/bus/usb-serial/devices 폴더에 있는 장치들의 latency_timer 값을 1로 변경 합니다.

echo "Set Serial Latency"
for entry in "/sys/bus/usb-serial/devices"/*
do
    if [ -d "$entry" ]; then
        echo $entry
	echo 1 > $entry"/latency_timer"
    fi
done

udev 파일을 이용하여 latency_timer 값을 1로 설정하는 방법

lsusb로 디바이스의 VendorID와 Product ID를 확인

orangepi@orangepi5:/sys/bus/usb-serial/devices$ lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 002: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 005: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
Bus 002 Device 004: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
Bus 002 Device 003: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
Bus 002 Device 002: ID 0424:2517 Microchip Technology, Inc. (formerly SMSC) Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 1409:8000 IDS Imaging Development Systems GmbH U3-36LxXC-C
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

아래와 같이 setserial을 설치하고, rules파일을 만듭니다.

$ sudo apt install setserial
$ vi 99-usb-serial-latency.rules

vi 99-usb-serial-latency.rules 파일 내용

ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6011", DRIVER=="ftdi_sio", RUN+="/bin/sh -c 'echo 1 > /sys%p/latency_timer'"

위에서 작성한 rules 파일을 /etc/udev/rules.d/에 복사 하고 Reboot 해서 적용 되었는지 확인 합니다.

# cp 99-usb-serial-latency.rules  /etc/udev/rules.d/
# sudo reboot

제대로 설정 되었는지 확인

orangepi@orangepi5:/sys/bus/usb-serial/devices$ cd ~
orangepi@orangepi5:~$ cd /sys/bus/usb-serial/devices/
orangepi@orangepi5:/sys/bus/usb-serial/devices$ ls
ttyUSB0  ttyUSB1  ttyUSB10  ttyUSB11  ttyUSB12  ttyUSB2  ttyUSB3  ttyUSB4  ttyUSB5  ttyUSB6  ttyUSB7  ttyUSB8  ttyUSB9
orangepi@orangepi5:/sys/bus/usb-serial/devices$ cat ttyUSB1/latency_timer
1
orangepi@orangepi5:/sys/bus/usb-serial/devices$

[OCPP Gateway] TW_OCPP

Life4IoT.rnd — Mon, 12 Feb 2024 20:01:17 +0900

TW_OCPP란

전기차 충전소 관리 시스템(EV Charging Station Management System, 이하 Central System)과 충전소(Charge Point)간의 통신을 중계하는 장치 입니다. OCPP는 전 세계적으로 널리 사용되는 개방형 프로토콜로, 다양한 제조업체의 충전소와 관리 시스템 간에 호환성을 제공 합니다.

용어 정리

Central System
- Charge Point를 관리하고, 사용자가 해당 Charge Point를 사용할 수 있는지 여부를 인증하는 정보를 가지고 있는 중앙 시스템(Central System)
Charge Point
- Charge Point는 전기차를 충전할 수 있는 물리적 시스템이다. Charge Point는 하나 이상의 충전 커넥터를 가짐
CSMS(Charging Station Management System)
- 충전기 등의 Charging Station을 관리하는 중앙 제어 시스템

TW_OCPP 사용 및 제어를 위한 구성도

TW_OCPP는 Charging Station의 Controller로 부터 RS-232 데이터를 받아 CSMS의 OCPP Server에게 OCPP 처리를 위한 메시지를 전달하는 구조를 가지고 있습니다..

반대로 OCPP Server에서 OCPP 메시지를 보내면, TW_OCPP는 해당 메시지를 받아서 Charging Station의 Controller에게 RS-232 데이터를 보냅니다.

참고로 해당 프로젝트에서 OCPP Server는 직접 구현하지 않고, Open Source로 배포 되어 있는 Steve Server를 사용한다.

Steve 서버를 설치하고 설정하기 위한 방법은 아래 글을 참고 하기 바랍니다.

https://kaizen8501.tistory.com/464

[Steve 서버 구축 #1] AWS Lightsail 인스턴스 & DB 인스턴스 생성

OCPP ChargePoiint 기능을 테스트하기 위해 Steve OCPP 서버를 Lightsail에 구축하려고 합니다. 우선 급한대로 AWS Lightsail에 구축을 해서 테스트 한 다음, 해당 서버를 NCP 쿠버네티스에 커스텀해서 배포 할

kaizen8501.tistory.com

https://kaizen8501.tistory.com/465

[Steve 서버 구축 #2] VM 설정

1. Putty로 Lightsail VM에 연결 SSH 연결이 정상적으로 수행되면 아래와 같은 화면을 볼 수 있습니다. 2. Update $ sudo apt update && sudo apt -y upgrade 3. Steve 서버를 구동하기 위한 필요한 패키지 설치 Steve를 구

kaizen8501.tistory.com

https://kaizen8501.tistory.com/466

[OCPP Charge Point #1] Steve와 Websocket 연결 테스트

mobilityhouse/ocpp 프로젝트 OCPP(Open Charge Point Protocol)와 관련된 Python 라이브러리르 제공하는 GitHub 프로젝트입니다. https://github.com/mobilityhouse/ocpp GitHub - mobilityhouse/ocpp: Python implementation of the Open Charge P

kaizen8501.tistory.com

[django] 마이그레이션 롤백 하는 방법

Life4IoT.rnd — Fri, 9 Feb 2024 20:53:30 +0900

기존 데이터를 유지하면서 django migrate로 마이그레이션 문제를 해결하기 위한 방법을 정리 합니다.

마이그레이션이 충돌되거나 문제가 발생 했을 때, 아래와 같은 명령으로 롤백 할 수 있습니다.

특정 migration_name에 지정된 스키마 형태로 마이그레이션 수행

$ python manage.py migrate [app_name] [migration_name]

만약 모든 마이그레이션을 롤백 하려면 아래 명령 수행

$ python manage.py migrate [app_name] zero

라즈베리파이, 오렌지파이 SD 카드 깨짐 문제

Life4IoT.rnd — Wed, 7 Feb 2024 20:47:02 +0900

제품 개발을 하던 중, 보드의 전원이 갑자기 차단하면 보드의 SD 카드의 파일이 깨지는 현상이 있었습니다.

아마 보드 입장에서 프로그램이 동작하면서 파일 시스템의 파일들을 Write 하는 도중에 전원이 차단되어 파일이 깨지는 것으로 보입니다.

해결 방법

임시 해결 방법일 수 있으나, 아래와 같이 fstab 파일에 sync 옵션을 추가 하는 방법이 있습니다.

$ sudo vi /etc/fstab

UUID=73379811-91e8-4483-8aff-7d4bc3cca9f6 / ext4 defaults,sync,noatime,commit=600,errors=remount-ro 0 1
UUID=5BC1-359C /boot vfat defaults 0 2
tmpfs /tmp tmpfs defaults,nosuid 0 0

해당 파티션이 "sync" 옵션으로 마운트되어 파일 시스템의 변경 내용이 디스크에 동기화 됩니다.

이를 통해 파일 시스템의 일관성을 유지하고 데이터 손실 가능성을 줄일 수 있다고 합니다.

주의 할 점은 sync 옵션은 파일 시스템의 성능을 저하 시킬 수 있습니다.

동기화 작업은 디스크에 대한 추가적인 입출력 작업을 수행하므로 일부 작업에서는 성능 저하가 발생 할 수 있음
특히 큰 파일을 다루거나 대량의 데이터를 처리하는 경우에 더 두드러질 수 있음

[쿠버네티스] CPU 점유율 메모리 사용량 확인, HPA 설정

Life4IoT.rnd — Tue, 6 Feb 2024 20:38:02 +0900

쿠버네티스에서 사용하는 POD들의 CPU 점유율과 메모리 사용량을 확인 하는 방법과 Autoscaling을 위한 HPA 설정 방법을 정리 하였습니다.

POD CPU 점유율과 메모리 사용량 확인

현재 사용 중인 pod의 CPU 점유율과 메모리 사용량을 확인하는 명령은 아래와 같습니다.

CPU의 100m는 0.1 core를 의미 합니다.
메모리의 116Mi는 116Mbytes를 의미 합니다.

kubectl top pods -n <name space>

C:\>kubectl top pods -n testx-dev
NAME                                             CPU(cores)   MEMORY(bytes)
tx-msa-device-service-dev-8496684c75-bzph2       208m         116Mi
tx-msa-fe-backend-service-dev-666555767d-r2mbp   3m           102Mi
tx-msa-frontend-dev-6ff6f8687b-cqfn5             4m           53Mi
tx-msa-logstash-84cd89fc7b-8wmjz                 16m          628Mi
tx-msa-payment-service-dev-6fff85957b-zw7sv      5m           242Mi
tx-msa-test-service-dev-8699bd9644-8svmk         99m          324Mi
tx-msa-test-service-dev-8699bd9644-k48w2         49m          312Mi
tx-msa-test-service-dev-8699bd9644-s2gpk         13m          321Mi
tx-msa-user-service-dev-5d45567968-nt89l         35m          246Mi

HPA(Horizontal Pod Autoscaler) 설정

HPA란

쿠버네티스에서 제공하는 자동 스케일링 시스템으로, 어플리케이션 부하에 따라 파드(Pod) 수를 자동으로 조절하는 기능입니다. PA는 CPU 사용량이나 메모리 사용량과 같은 메트릭을 기반으로 작동하며, 이를 통해 애플리케이션의 요구사항과 트래픽 변화에 유연하게 대응할 수 있도록 돕습니다.

HPA 설정 시, 최소 파드 수, 최대 파드 수, 그리고 목표 메트릭 값 등을 정의할 수 있습니다. 예를 들어, CPU 사용률이 목표치를 초과할 경우, HPA는 자동으로 파드의 수를 증가시켜 부하를 분산시키고, 반대로 사용률이 목표치 이하로 떨어지면 파드의 수를 줄여 자원을 효율적으로 사용할 수 있도록 조정합니다.

자세한 내용은 아래 링크 참고 하시기 바랍니다.

https://kaizen8501.tistory.com/480

HPA 설정 값을 확인 하기 위한 명령

아래 명령을 이용해서 네임스페이스의 Deployments에 설정된 HPA 값들을 확인 할 수 있습니다.

kubectl describe hpa -n <name space>

C:\Users\Administrator>kubectl describe hpa -n testx-dev
Name:                                                     tx-msa-device-service-dev
Namespace:                                                testx-dev
Labels:                                                   app.kubernetes.io/instance=helm-tx-msa-device-service-dev
                                                          app.kubernetes.io/managed-by=Helm
                                                          app.kubernetes.io/name=helm-tx-msa-device-manager
                                                          app.kubernetes.io/version=1.16.0
                                                          argocd.argoproj.io/instance=helm-tx-msa-device-service-dev
                                                          helm.sh/chart=helm-tx-msa-device-manager-0.1.0
Annotations:                                              <none>
CreationTimestamp:                                        Tue, 31 Oct 2023 13:42:13 +0900
Reference:                                                Deployment/tx-msa-device-service-dev
Metrics:                                                  ( current / target )
  resource memory on pods  (as a percentage of request):  32% (105512960) / 80%
Min replicas:                                             1
Max replicas:                                             5
Deployment pods:                                          1 current / 1 desired
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource utilization (percentage of request)
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Events:           <none>

HPA 설정 값을 수정한 후 배포 테스트

해당 Deployment들은 Helm 차트 기반으로 작성되어 있습니다. Helm 차트의 values.yaml 파일에서 resources와 autoscaling 부분을 아래와 같이 수정 하였습니다.

values.yaml 수정

request-memory를 819Mi로 설정
autoscaling-targetMemoryUtilizationPercentage를 80으로 설정

Describe 명령으로 확인 해 보면 아래와 같이 POD의 메모리를 10%(105,021,440)를 사용중이라고 나옵니다.

조금 이상한 건 requests에 설정한 memory는 819Mi 여서 10% 사용 중이면 819Kbytes 로 되어 있어야 할 거 같은데 1Gmi 기준으로 10%가 되는 것 같네요. 혹시 아시는 분은 댓글 달아 주세요.

resources: {
  requests: {
    cpu: 300m,
    memory: 819Mi
  }
}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  # limits:
  #   cpu: 100m
  #   memory: 128Mi
  # requests:
  #   cpu: 100m
  #   memory: 128Mi

autoscaling:
  enabled: true
  minReplicas: 1
  maxReplicas: 5
  #targetCPUUtilizationPercentage: 80
  targetMemoryUtilizationPercentage: 80

C:\Users\Administrator>kubectl describe hpa -n testx-dev tx-msa-device-service-dev
Name:                                                     tx-msa-device-service-dev
Namespace:                                                testx-dev
Labels:                                                   app.kubernetes.io/instance=helm-tx-msa-device-service-dev
                                                          app.kubernetes.io/managed-by=Helm
                                                          app.kubernetes.io/name=helm-tx-msa-device-manager
                                                          app.kubernetes.io/version=1.16.0
                                                          argocd.argoproj.io/instance=helm-tx-msa-device-service-dev
                                                          helm.sh/chart=helm-tx-msa-device-manager-0.1.0
Annotations:                                              <none>
CreationTimestamp:                                        Tue, 31 Oct 2023 14:35:40 +0900
Reference:                                                Deployment/tx-msa-device-service-dev
Metrics:                                                  ( current / target )
  resource memory on pods  (as a percentage of request):  10% (105021440) / 80%
Min replicas:                                             1
Max replicas:                                             5
Deployment pods:                                          1 current / 1 desired
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource utilization (percentage of request)
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Events:           <none>

[쿠버네티스] Helm 차트의 Resource와 Autoscaling

Life4IoT.rnd — Mon, 5 Feb 2024 20:29:04 +0900

쿠버네티스에 Deployment를 위한 설정 중 Resource와 Autoscaling에 대해 정리 합니다.

Resources

파드에 할당할 CPU와 메모리 리소스의 최소, 최대 한계를 정의
파드가 사용 할 수 있는 리소스의 양을 제한하여, 리소스의 과도한 사용을 방지하고, 다른 파드와의 리소스 경쟁을 최소화 하는데 도움을 줌

Resources 설정 예제는 아래와 같습니다.

resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"

requests
- 파드가 시작될 때 요청하는 리소스의 양
- 이 값을 기반으로 쿠버네티스 스케줄러는 파드를 적절한 노드에 배치
limits
- 파드가 사용할 수 있는 리소스의 최대 한계
- 이 한계를 초과하는 리소스 사용은 제한 됨

Autoscaling

HPA(Horizontal Pod Autoscaler)의 자동 스케일링 정책을 설정
특정 조건(예: CPU 사용량, 메모리 사용량)에 따라 파드의 인스턴스 수를 자동으로 조정 함

autoscaling:
  enabled: true
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  targetMemoryUtilizationPercentage: 80

enabled
- 자동 스케일링을 활성화/비활성화
minReplicas
- 자동 스케일링을 통해 유지 할 수 있는 파드의 최소 인스턴스 수
maxReplicas
- 자동 스케일링을 통해 유지 할 수 있는 파드의 최대 인스턴스 수
targetCPUUtilizationPercentage
- HPA가 파드를 스케일링하기 시작하는 CPU 사용률의 목표치
- 예를 들어 이 값이 80이라면 CPU 사용률이 80%에 도달했을 때 파드의 인스턴스 수를 증가
  - 80%는 파드가 할당 받은 CPU 리소스 대비 사용 중인 CPU의 비율을 의미
  - 예를 들어 CPU 요청량이 250m으로 설정되어 있고, targetCPUUtilizationPercentage 값이 80%로 설정되어 있는 경우, 해당 파드는 200m(250m의 80%)의 사용량에 도달했을 때 HPA에 의해 스케일링 됨
targetMemoryUtilizationPercentage
- 메모리 사용률에 따른 자동 스케일링을 위한 설정
- 메모리 사용률의 목표치를 지정

[pyinstaller] 바이러스, 트로이 목마 문제 해결

Life4IoT.rnd — Fri, 2 Feb 2024 20:00:41 +0900

pyinstaller를 사용하여 패키징 할 때, 멀웨어로 인식되는 문제를 해결한 방법을 정리 하였습니다.

문제

pyinstaller를 사용하여 python 프로그램을 패키징 할 때 아래와 같은 에러가 발생 하고 Windows Depender에서는 트로이목마 파일이 있다면서 에러를 출력 하였다.

  File "c:\Workspace\venv_phoenixon\lib\site-packages\PyInstaller\building\build_main.py", line 1071, in main
    build(specfile, distpath, workpath, clean_build)
  File "c:\Workspace\venv_phoenixon\lib\site-packages\PyInstaller\building\build_main.py", line 1011, in build
    exec(code, spec_namespace)
  File "makeExeScript\0_pyinstaller.spec", line 21, in <module>
    exe = EXE(pyz,
  File "c:\Workspace\venv_phoenixon\lib\site-packages\PyInstaller\building\api.py", line 628, in __init__
    self.__postinit__()
  File "c:\Workspace\venv_phoenixon\lib\site-packages\PyInstaller\building\datastruct.py", line 184, in __postinit__
    self.assemble()
  File "c:\Workspace\venv_phoenixon\lib\site-packages\PyInstaller\building\api.py", line 741, in assemble
    self._retry_operation(icon.CopyIcons, build_name, self.icon)
  File "c:\Workspace\venv_phoenixon\lib\site-packages\PyInstaller\building\api.py", line 1003, in _retry_operation
    return func(*args)
  File "c:\Workspace\venv_phoenixon\lib\site-packages\PyInstaller\utils\win32\icon.py", line 209, in CopyIcons
    return CopyIcons_FromIco(dstpath, [srcpath])
  File "c:\Workspace\venv_phoenixon\lib\site-packages\PyInstaller\utils\win32\icon.py", line 143, in CopyIcons_FromIco
    hdst = win32api.BeginUpdateResource(dstpath, 0)
  File "c:\Workspace\venv_phoenixon\lib\site-packages\win32ctypes\pywin32\win32api.py", line 208, in BeginUpdateResource
    with _pywin32error():
  File "C:\Python310\lib\contextlib.py", line 153, in __exit__
    self.gen.throw(typ, value, traceback)
  File "c:\Workspace\venv_phoenixon\lib\site-packages\win32ctypes\pywin32\pywintypes.py", line 37, in pywin32error
    raise error(exception.winerror, exception.function, exception.strerror)
win32ctypes.pywin32.pywintypes.error: (225, 'BeginUpdateResourceW', '파일에 바이러스 또는 기타 사용자 동의 없이 설치된 소프트웨어가 있기 때문에 작업이 완료되지 않았습니다.')

현재 환경

현재 사용 중인 Python 버전과 Pyinstaller 버전은 아래와 같다.

python 3.10.11
pyinstaller 6.3.0 사용

해결 방법

아래 참고 자료에 나온 글을 읽어 보니, PyInstaller가 생성한 파일을 Windows에서 말웨어로 잘못 보고 되는 문제가 있다고 한다. 스택오버플로우에서 글 처럼 pyinstaller 버전을 5.13.2로 다운그레이드 하니 문제가 해결 되었다.

아래 내용은 PyInstaller의 공식 입장이다.

이슈 #6062에서 PyInstaller 팀은 안티바이러스(AV) 보고서와 관련하여 공식 입장을 밝혔습니다. 이들은 PyInstaller가 생성한 파일을 말웨어로 잘못 보고하는 문제에 대해, AV 소프트웨어 제조사에게 직접 거짓 긍정(false positive)을 보고할 것을 권장합니다. 이 문제는 PyInstaller 도구 자체의 문제가 아니라, 안티바이러스 소프트웨어의 휴리스틱(heuristics) 방식 때문에 발생하는 것으로, PyInstaller는 이에 대해 직접적인 해결책을 제공하지 않습니다. 또한, 사용자들에게 자신의 컴파일러 체인이 감염되지 않았다는 것을 보증할 수 있는 방법도 제시합니다. 이러한 내용은 PyInstaller 커뮤니티와 사용자들에게 중요한 지침을 제공합니다.

참고 자료

https://stackoverflow.com/questions/77239487/win32ctypes-pywin32-pywintypes-error-when-using-pyinstaller-in-vs-code-possib

*win32ctypes.pywin32.pywintypes.error when using pyinstaller in VS Code - Possible Virus/Trojan?

I am using pyinstaller to generate an executable code for my python.py file. However, I am getting this error: File "C:\Users\xxxxx\AppData\Local\Programs\Python\Python311\Lib\site-packages\

stackoverflow.com

[PySide2] TextEdit의 textChanged 이벤트를 받아 개행 문자 삭제

Life4IoT.rnd — Fri, 26 Jan 2024 20:42:52 +0900

Example Code

TextEdit에서 입력된 값이 변경될 때 마다 이벤트를 받아 개행문자가 있는지 확인하고 삭제하는 예제입니다.

TextEdit에 수정된 문자열을 입력하면서도 이벤트가 발생 할 수 있기 때문에 아래와 같이 무한루프를 방지하기 위한 코드를 추가 하였습니다.

from PySide2.QtWidgets import QApplication, QTextEdit, QVBoxLayout, QWidget

class MyWidget(QWidget):
    def __init__(self):
        super().__init__()

        # 레이아웃 설정
        self.layout = QVBoxLayout(self)

        # QTextEdit 위젯 생성 및 레이아웃에 추가
        self.text_edit = QTextEdit()
        self.layout.addWidget(self.text_edit)

        # QTextEdit의 textChanged 시그널에 슬롯(함수) 연결
        self.text_edit.textChanged.connect(self.on_text_changed)

    def on_text_changed(self):
        # 현재 QTextEdit의 텍스트를 가져옵니다.
        text = self.text_edit.toPlainText()

        # CR과 LF를 제거합니다.
        modified_text = text.replace('\r', '').replace('\n', '')

        # 현재 텍스트와 수정된 텍스트가 다를 경우, QTextEdit를 업데이트합니다.
        if text != modified_text:
            # 블록 시그널을 사용하여 무한 루프를 방지합니다.
            self.text_edit.blockSignals(True)
            self.text_edit.setText(modified_text)
            self.text_edit.blockSignals(False)

# 애플리케이션 생성
app = QApplication([])

# 위젯 생성 및 표시
my_widget = MyWidget()
my_widget.show()

# 애플리케이션 실행
app.exec_()

[2024년 1월 25일] OCPP 주요 뉴스

Life4IoT.rnd — Thu, 25 Jan 2024 20:39:26 +0900

OCPP의 중요성과 영향력

OCPP는 전기차 충전 인프라에서 혁신의 최전선에 서 있으며, 서로 다른 제조사의 충전 인프라 구성 요소 간 상호운용성을 보장하는 통합된 언어를 제공합니다. OCPP는 충전 네트워크의 유연성과 접근성을 높이고, 업계 내에서 혁신과 통합을 촉진합니다.

OCPP 2.0.1의 보안 개선

OCPP 2.0.1은 중요한 정보를 처리하는 통신 채널의 보안을 강화하기 위해 세 가지 "보안 프로필"을 도입했습니다. 이는 웹소켓 통신에 대한 암호화 및 인증 메커니즘을 포함하여 보안을 향상시키고 있습니다

스마트 충전 기능의 향상

OCPP 2.0.1은 충전 프로필 관리의 명확한 지침을 제공하여 충전 프로세스의 조정 및 최적화를 개선합니다. 또한 외부 프로필의 수용 및 보고 기능을 통해 다양한 충전 인프라 및 타사 시스템과의 호환성을 높였습니다.

ISO15118과의 호환성

OCPP 2.0.1은 ISO 15118 통신 프로토콜에 대한 네이티브 지원을 포함하고 있으며, 이는 전기차와 충전소 간의 원활하고 안전한 충전 경험을 보장합니다. 이는 플러그앤플레이 및 스마트 충전 기능을 지원하며, OCPP 2.1에서는 ISO 15118-20 지원이 추가될 예정입니다.

OCPP 2.0.1의 도전과 Trialog의 전문성

새로운 기능의 도입은 구현과 실행의 복잡성을 증가시키지만, Trialog는 OCPP 개발에 깊이 관여하고 있으며, OCPP 소프트웨어 스택 및 교육 세션을 제공하여 이러한 복잡성을 관리하고 있습니다.

참고 자료

https://finance.yahoo.com/news/emqx-enterprise-5-4-integrating-180000344.html?guccounter=1

오렌지파이5B GPIO로 전원 끄기

Life4IoT.rnd — Thu, 11 Jan 2024 20:55:02 +0900

아래 그림과 같이 PowerKey 핀을 이용하여 오렌지파이5B를 종료 할 수 있습니다.

해당 핀은 아래 그림의 토글 스위치와 연결되어 있어 스위치를 누르면 OS의 종료 화면이 나오고 5초 이상 누르고 있으면 오렌지파이 보드의 OS를 종료 합니다.

해당 핀을 이용하여 케이스를 씌운 제품에 버튼을 두고, 오렌지 파이 보드의 OS를 종료하기 위한 작업을 진행하고 있습니다.

문제 및 해결

그런데 자료에 나와 있는 것과 같이 PowerKey를 이용하여 OS 종료를 시도 해 보았지만, 아무런 반응이 없었습니다. 제조사에서 제공한 회로도를 아무리 봐도 해당 핀을 사용하는게 맞는거 같은데 동작 하지 않았습니다.

제조사에서 아트웍 자료를 제공하지 않은 관계로, 테스터기로 이것 저것 찍어 보니 아래 사진과 같이 Power Key와 연결되어 있는 R90664 저항이 미삽되어 있었다.

R90664 위치에 저항을 달아 연결 되고 나서는 원하는 동작이 제대로 수행이 되네요.

회로도에 미삽이라는 표현 하나만 있었어도 이렇게 고생하지 않을거 같은데, 아쉽네요. 혹 저와 같은 고생을 하시는 분들이 있을 까봐 해당 내용을 공유 합니다.