Yapay zekâ tarafından English dilinden çevrildi ·
Commands sekmesi yazımdaki ile aynı CL1 kontrol cihazı, bu kez Log sekmesi. Bağlantı geçmişini ve cihazda yapılan değişiklikleri tek bir zaman çizelgesinde, en yeniden en eskiye doğru, üstte All, Connections ve Changes seçenekleriyle gösteriyor.
Bugün Pazar, 8 Kasım. 23:07’de ve yine 09:21’de aynı dakikada üç satır oluştu: Reason: client_disconnect ile Disconnected, Connected over MQTT ve Reason: takeover ile “Taken over by a new session”. 09:14’te bir Connected ve takeover çifti daha var. Connected ve Disconnected satırlarındaki istemci adresi ekran görüntüsünde bulanıklaştırılmış.”Taken over by a new session”, aynı cihaza ait ikinci bir bağlantının birinciyi devraldığı anlamına gelir. Bir cihaz bunu birkaç dakikada bir yapıyor ve çevrimiçi ile çevrimdışı arasında sürekli gidip geliyorsa, önce aynı kimlik bilgisini paylaşan iki cihaz olup olmadığına bakın.Changes filtresi denetlenen değişiklikleri gösterir: cihazın oluşturulması veya düzenlenmesi (alanlarıyla birlikte), kimlik bilgilerinin değiştirilmesi, yenilenmesi veya iptal edilmesi, özniteliklerin kaydedilmesi, komutların gönderilip tamamlanması, alarmların onaylanması ve temizlenmesi; her biri bir kişi veya sistem tarafından. Daha fazlası için Connection status and activity sayfasına bakın.
Same CL1 controller as in my Commands tab post, this time the Log tab. It puts the connection history and the changes made to the device in one timeline, newest first, with All, Connections and Changes at the top.
This is Sunday 8 November. At 23:07 and again at 09:21, three rows landed in the same minute: Disconnected with Reason: client_disconnect, Connected over MQTT, and “Taken over by a new session” with Reason: takeover. There’s another Connected and takeover pair at 09:14. The client address on the Connected and Disconnected rows is blurred in the shot.
“Taken over by a new session” means a second connection of the same device took over the first. If a device does it every few minutes and keeps flipping between online and offline, look for two devices sharing one credential first.
The Changes filter shows the audited changes: the device created or edited (with the fields), credentials replaced, rotated or revoked, attributes saved, commands sent and finished, alarms acknowledged and cleared, each by a person or by the system. More in Connection status and activity.
Yapay zekâ tarafından English dilinden çevrildi ·
Bunu Hermetry’den alabilir miyim? Denetçimiz, bir çeyrek boyunca cihaz başına bağlantı geçmişini istiyor.
Can I get this out of Hermetry? Our auditor wants connection history per device for a quarter.
Yapay zekâ tarafından English dilinden çevrildi ·
API üzerinden: GET …/devices/{deviceId}/log?source=connection (değişiklikler için source=audit), en fazla 1.000 kayıt derinliğinde. Bağlantı geçmişi 30 gün saklanır, bu yüzden bir çeyrek için dosyaları birkaç haftada bir çekip saklamanız gerekir. Değişiklikler denetim günlüğünde de bulunur; its API resourceType=iot_device ve cihazın kimliğiyle filtreler, CSV Dışa Aktar ise filtrelediğiniz tarih aralığını alır: Audit log.
Over the API: GET …/devices/{deviceId}/log?source=connection (or source=audit for the changes), at most 1,000 entries deep. Connection history is kept for 30 days, so for a quarter you’d pull it every few weeks and keep the files. The changes are also in the audit log; its API filters by resourceType=iot_device and the device’s id, and Export CSV takes the date range you filtered: Audit log.
Yapay zekâ tarafından English dilinden çevrildi ·
Hücresel cihazlarda en çok gördüğüm neden keepalive_timeout. Bu sorun tekrar ederse, yazılımı suçlamadan önce keepalive değerini operatörün NAT zaman aşımıyla karşılaştırın.
keepalive_timeout is the reason I see most on cellular devices. If it keeps coming up, check the keepalive against the operator’s NAT timeout before blaming the firmware.
Yapay zekâ tarafından English dilinden çevrildi ·
Katılıyorum. Bir cihaz veri gönderip ardından bilerek bağlantısını kesiyorsa, profiline Recent message online kuralını ekleyin; böylece son mesajı hâlâ güncel olduğu sürece tek başına bir bağlantı kesilmesi cihazı çevrimdışı göstermez.
Agreed. And if a device reports and then disconnects on purpose, give its profile the Recent message online rule; then a disconnect alone doesn’t show it offline while its last message is still recent.
Yapay zekâ tarafından English dilinden çevrildi ·
Yanlış parola gibi reddedilen bir giriş de burada görünüyor mu?
Does a refused login show up here too, like a wrong password?
Yapay zekâ tarafından English dilinden çevrildi ·
Evet. Reddedilen bir oturum açma (CONNACK 5) nedeniyle birlikte günlüğe kaydedilir. Cihazın kendisi nedeni hiçbir zaman almaz.
Yes. A refused login (CONNACK 5) is logged with its reason. The device itself never gets the reason.
Yapay zekâ tarafından English dilinden çevrildi ·
Bende hiç bağlantı satırı yok, yalnızca değişiklikler var. Cihaz bir SNMP kutusu.
Mine has no connect rows at all, only changes. The device is an SNMP box.
Yapay zekâ tarafından English dilinden çevrildi ·
Sorgulanan (polled) cihazlar yalnızca Last seen kullanır ve yalnızca Last seen only kullanan cihazlar bağlantı ve bağlantı kopma kayıtları yazmaz. Kutunuz için bu beklenen bir davranıştır.
Polled devices use Last seen only, and devices on Last seen only write no connect and disconnect rows. That’s expected for your box.
- Bu konuyu yanıtlamak için giriş yapmış olmalısınız.
Sohbete katılın
Soru sormak ve yanıtlamak, yararlı gönderileri beğenmek ve sorununuzu çözen yanıtı işaretlemek için oturum açın. Her katkı puan ve seviye kazandırır.