Question 1

ThingsBoard가 알람 생성을 ALARM_CREATED 대신 ENTITY_CREATED로 라우팅하는 이유는 무엇인가요?

Accepted Answer

ThingsBoard에서 알람은 엔티티 유형 중 하나입니다. 알람이 생성되면 시스템은 새로운 엔티티 생성이므로 ENTITY_CREATED 이벤트를 발생시킵니다. ALARM_CREATED 메시지 유형은 기존 알람이 트리거되거나 업데이트되는 이벤트에 사용되며, 알람 엔티티의 최초 생성에는 사용되지 않습니다. 룰 체인이 장치 생성만 처리해야 하는 경우 Message Type Switch 앞에 필터 노드를 추가하여 엔티티 유형을 확인하세요. 예를 들어 TBEL 스크립트를 사용합니다: return msg.id != null && msg.id.entityType == 'DEVICE';

Question 2

ThingsBoard 전송 속도 제한을 초과할 때 MQTT 메시지는 어떻게 됩니까?

Accepted Answer

장치가 전송 속도 제한(예: 100 messages/s, 1,000/min, 15,000/h)을 초과하면 ThingsBoard는 무음 승인 및 폐기를 하지 않습니다. MQTT DISCONNECT를 보내고 연결을 종료합니다. QoS 0의 경우 재시도 메커니즘 없이 메시지가 손실됩니다. QoS 1의 경우 장치가 영구 세션(Clean Start = false)을 사용하면 MQTT 표준에 따라 재연결 시 승인되지 않은 메시지가 재전송됩니다. 임시 세션(Clean Start = true)의 경우 전송 중 상태가 지워져 QoS에 관계없이 메시지가 손실됩니다. 플랫폼 측에서는 메시지별 로깅이 없으며, 속도 제한 위반 알림만 생성됩니다. 손실된 텔레메트리를 복구하려면 장치의 로컬 버퍼를 사용하십시오.

Question 3

ThingsBoard Cloud 데이터 포인트 할당량이 낮은 텔레메트리 주파수에도 불구하고 왜 빠르게 소진되나요?

Accepted Answer

ThingsBoard에서 각 텔레메트리 JSON 페이로드의 key는 전체 메시지가 아닌 하나의 데이터 포인트로 계산됩니다. 예를 들어, 32개의 key가 있는 메시지는 전송당 32개의 데이터 포인트를 사용합니다. 각 key를 개별적으로 저장하는 규칙 체인은 사용량을 더욱 증가시킬 수 있습니다. 사용량을 줄이려면: 메시지당 key 수를 최소화하고, 게시 빈도를 낮추며, 규칙 체인을 검토하여 중복 데이터 포인트 저장을 제거하세요. 활성 장치 수를 확인하세요. 총 사용량은 장치 수와 메시지당 key에 따라 선형적으로 증가합니다.

Question 4

ThingsBoard에서 정수 텔레메트리 값의 특정 비트에 대한 알람을 트리거하는 방법은 무엇인가요?

Accepted Answer

알람 규칙에서 직접 비트 확인은 아직 지원되지 않습니다(기능 요청 #8055). 해결 방법: Script 노드(JavaScript)가 포함된 Rule Chain을 사용하여 비트 연산을 통해 비트를 새로운 텔레메트리 키로 추출한 다음 해당 키에 대한 알람 규칙을 설정합니다. 비트 0(비상 정지)을 추출하는 예제: `var fault = msg.faultWord; msg.emergencyStop = (fault & 1) !== 0; return {msg: msg, metadata: metadata, msgType: msgType};` 그런 다음 `emergencyStop == true`에 대한 알람 규칙을 생성합니다. 필요에 따라 다른 비트에 대해 반복합니다.

thingsboard

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트