bugra.demiriz
@bugra-demiriz · Ağustos 2026 tarihinde katıldı
- Konular
- 11
- Yanıtlar
- 33
- Puan
- 0
Oluşturulan forum yanıtları
Yapay zekâ tarafından English dilinden çevrildi ·
Canlı cihazların bağlı olduğu bir çalışma alanında bunu denemeyin. Her host üzerindeki çalışan tüm akışları duraklatır; kök akışlar da dahildir ve cihaz verilerinizi saklayan kök akıştır. Cihaz mesajları, zamanlamalar ve webhook’lar, akışlar devam ettirilene kadar hiçbir çalışma başlatmaz.Önce onay ister: “Akışlar devam ettirilene kadar hiçbir şeyin çalışmayacağını anlıyorum.” kutusunu işaretlersiniz ve STOP yazarsınız. Akışları devam ettirmek, durdurma işleminin duraklattığı her akışı geri getirir. Daha önce kendi kendine duraklamış bir akış duraklatılmış kalır. Her ikisi de denetim günlüğündedir.
Don’t try it on a workspace with live devices. It pauses every running flow on every host, root flows included, and the root flow is the one storing your device data. Device messages, schedules and webhooks start no run until you resume.
It does ask first: you tick “I understand that nothing runs until the flows are resumed.” and type STOP. Resume the flows brings back every flow the stop paused. A flow that had paused itself before stays paused. Both are in the audit log.
Yapay zekâ tarafından English dilinden çevrildi ·
Kişi önceliklidir. Bir cihazın bölümünü aynı anda yalnızca bir yazıcı değiştirir ve cihaz sayfasındaki bir kişinin değişikliği işe göre önceliklidir; “Bir kişi tarafından değiştirildi”, cihazın işte gösterebileceği durumlardan biridir. İki iş aynı cihazı istediğinde, işin ayarı cihazın beklemesine mi yoksa atlanmasına mı karar verir.
The person wins. Only one writer changes a device’s section at a time, and a person’s change on the device page wins over the job; “Changed by a person” is one of the states a device can show in the job. When two jobs want the same device, the job’s setting decides whether it waits or skips the device.
Yapay zekâ tarafından English dilinden çevrildi ·
Bu şekilde değil, özür dilerim. Doğru olması gereken iki şey var: firmware bağlandığında ayar bölümlerini bildirmeli ve Hermetry’de o model ve firmware için ayar açıklaması (manifest) bulunmalı. Lisanslı cihazların ikisi de vardır.Kendi kartlarınız için, profilin Configuration keys sekmesinde cfg.* anahtarlarını tanımlayın (tür, sınırlar, izin verilen değerler) ve firmware’in bunları paylaşılan öznitelikler olarak okumasını sağlayın. Böylece sınırları olan tipli anahtarlara sahip olursunuz ve Attributes sekmesi her birini manifest yazmadan In sync, Pending, Rejected veya Drifted olarak gösterir. Cihaz tarafı için Attributes sayfasına bakın.
Not this way, sorry. Two things have to be true: the firmware announces its settings sections when it connects, and Hermetry has the settings description (the manifest) for that model and firmware. Licensed devices have both.
For your own boards, declare cfg.* keys on the profile’s Configuration keys tab (type, limits, allowed values) and let the firmware read them as shared attributes. You get typed keys with limits, and the Attributes tab shows each one as In sync, Pending, Rejected or Drifted, without writing a manifest. Attributes has the device side.
Yapay zekâ tarafından English dilinden çevrildi ·
Bağlantı geçmişi 30 gün boyunca saklanır ve Daha fazla yükle, bu süre içinde daha geriye gider. Profilinde Son görülme kullanan cihazlar bağlanma ve bağlantı kesme kayıtları yazmaz; sekme boş görünüyorsa profilin çevrimiçi kuralını kontrol edin.
Connection history is kept for 30 days, and Load more goes further back within that. Devices whose profile uses Last seen only write no connect and disconnect rows, so check the profile’s online rule if the tab looks empty.
Yapay zekâ tarafından English dilinden çevrildi ·
Cihaz v1/rpc/req/+ konusuna abone olur ve method ile params bilgisini alır; iki yönlü bir komut için aynı id ile yanıt verir:
PUBLISH v1/rpc/req/42
{"method": "sys.ping", "params": {"host": "8.8.8.8", "count": 3}}
PUBLISH v1/rpc/res/42
{"ok": true, "result": {"sent": 3, "received": 3, "avg_ms": 18.2}}Komutlar, cihaz o bağlantıda abone olduktan sonra iletilir.
It subscribes to v1/rpc/req/+ and gets the method and params; for a two-way command it answers on the same id:
PUBLISH v1/rpc/req/42
{"method": "sys.ping", "params": {"host": "8.8.8.8", "count": 3}}
PUBLISH v1/rpc/res/42
{"ok": true, "result": {"sent": 3, "received": 3, "avg_ms": 18.2}}Commands are only delivered after the device has subscribed on that connection.
Yapay zekâ tarafından English dilinden çevrildi ·
Kataloğdaki her komutun bir seviyesi vardır. Varsayılan olarak Basic seviyesi Users, Privileged ve Critical seviyesi yöneticiler içindir; kataloğda bulunmayan ham bir method ise yalnızca owner’lar içindir. Bir operatörün privileged komutlara ihtiyacı varsa, onu Admin yapmadan iot_rpc.send.privileged yetkisine sahip özel bir grup bunu sağlar.
Each command in the catalog has a tier. By default Basic is for Users, Privileged and Critical for administrators, and a raw method that isn’t in the catalog is owners only. If one operator needs privileged commands, a custom group with iot_rpc.send.privileged does it without making them Admin.
Yapay zekâ tarafından English dilinden çevrildi ·
Bu yüzden öyle görünüyor. Madem firmware tarafında çalışıyorsun, bir şey daha ekleyeyim: bir komut iki kez gelebilir, bu yüzden en az son 32 istek kimliğini 10 dakika boyunca sakla ve aynı kimliği tekrar çalıştırma.
That’s why it reads that way. One thing for the firmware side while you’re at it: a command can arrive twice, so remember at least the last 32 request ids for 10 minutes and don’t run the same id again.
Yapay zekâ tarafından English dilinden çevrildi ·
Gördüğümüz: en son bağlantının adresi. Bağlantı tutmayan HTTP ve sorgulanan (polled) cihazlar için bu, en son etkinliğin adresidir. Yönlendiricinizin arkasında, cihazın sahip olduğu 192.168 adresini değil, bağlantının geldiği genel adresi görürsünüz (yönlendiricinin ya da önüne bir NAT adresi koyuyorsa mobil operatörün adresi).
What we see: the address of the newest connection. For HTTP and polled devices, which don’t hold a connection, it’s the address of the newest activity. Behind your router you’ll see the public address the connection comes from (the router’s, or the mobile operator’s NAT address if it puts one in front), not the 192.168 one the device has.
Yapay zekâ tarafından English dilinden çevrildi ·
Alarmın zaman çizelgesinde. Burada Bildirildi ifadesi alıcı ve kanal sayısıyla birlikte görünür; sınırlama bir bildirimi geri tuttuğunda “Bildirim geri tutuldu” ve kimseye bildirim gönderilmediğinde Sessize alındı görünür.Bildirim günlüğünde yalnızca yapılmış denemeler bulunur (alıcı ve kanal başına gönderildi, başarısız veya beklemede). Deneme yapılmadan önce geri tutulan bir şey (bir tercih, sessiz saatler, tekrar penceresi ya da sessize alma nedeniyle) bu aşamaya ulaşmadığı için günlükte yer almaz; bu kararlar bunun yerine alarm zaman çizelgesinde gösterilir.
On the alarm’s timeline. It shows Notified with the number of recipients and channels, “Notification held back” when the throttle kept one back, and Muted when nobody was told.
The notification log only has attempts that were made (sent, failed or pending per recipient and channel). Something held back before it was attempted (by a preference, quiet hours, the repeat window or a mute) never got that far, so it is not in the log; those decisions show on the alarm timeline instead.
Yapay zekâ tarafından English dilinden çevrildi ·
Değişiklik günlüğü satırı tetikleyicinin kendisiyle ilgili: tetikleyici kalıcı olarak saklanır ve bir kesintiden sonra otomatik olarak onarılır.Çağrıların kendisine gelince, kesinti sırasında yaşam süresini (time-to-live) aşarak bekleyen bir webhook çağrısı kendi başına çalıştırılmaz. “Bekleme süresi aşıldı” nedeniyle Başarısız mesajlar alanına gider ve Yeniden oynat ile çalıştırılır. Yeniden oynatma orijinal kimlikleri korur, giden bloklar aynı idempotency anahtarını gönderir; çağrı yaptığınız sistem bunu tekilleştiriyorsa çağrıyı yalnızca bir kez görür. Ayrıntılar: Korumalar ve başarısız mesajlar.
The changelog line is about the trigger itself: it’s stored durably and repaired automatically after an outage.
For the calls themselves, a webhook call that waited longer than its time-to-live during an outage isn’t run on its own. It goes to Failed messages with the reason “Waited too long”, and Replay runs it. Replay keeps the original ids, and the outbound blocks send the same idempotency key, so if the system you call deduplicates it sees the call once. Details in Protections and failed messages.
Yapay zekâ tarafından English dilinden çevrildi ·
Başlıkta sabit bir anahtar için, bunu HTTP uç nokta bağlantısına koyardım: kimlik doğrulama türü header, header_name X-Api-Key ve değer header_value alanına girilir; bu değer gizli bilgi olarak saklanır. Bu durumda blok yalnızca bağlantıyı adlandırır ve bloğun headers bölümündeki satır kaldırılabilir.Kaydettikten sonra alanda “Bir değer saklanmış. Korumak için boş bırakın.” yazısı görünür ve değer hiçbir çalışma kaydına, günlüğe veya dışa aktarıma ulaşmaz. Akışı daha sonra dışa aktarırsanız, içe aktaran kişinin gizli bilgiyi yeniden girmesi gerekir.
For a fixed key in a header I’d put it on the HTTP endpoint connection: auth type header, header_name X-Api-Key, and the value goes in header_value, which is stored as a secret. Then the block only names the connection and the row in the block’s headers can go.
After saving, the field shows “A value is stored. Leave empty to keep it.” and the value never reaches a run record, a log or an export. If you export the flow later, the importer has to type the secret again.
Yes, if the device sends its own time. A message like {"ts": 1759572000000, "values": {...}} is stored at ts, in milliseconds since 1970 UTC. A flat object is stored at the time it arrived. Two things to watch: a record more than 10 minutes in the future is refused as bad_ts, so keep the clocks synced, and an admin can set an oldest accepted age. Details on Timestamps, late and duplicate readings.
Welcome Lakshmi. For a regular extract into your own store, the History API called by your scheduler is the usual route. If you want every reading in real time instead, a forwarding block in the root flow sends them on as they arrive. Exporting data compares the options.
Yapay zekâ tarafından English dilinden çevrildi ·
Bunu yapamazlar. Bir grup, bir üyeyi Admin minimumunun üzerine çıkarabilir, ancak Owner minimumunun üzerine asla çıkaramaz. Ham komutlar, sahiplik devri ve kuruluşun silinmesi, bir grup ne derse desin Owner’larda kalır; bu hücreler matriste owner dışındaki herkes için kilitlidir.
They can’t. A group can lift a member over an Admin minimum, never over an Owner one. Raw commands, ownership transfer and deleting the organisation stay with owners whatever a group says, and those cells are locked in the matrix for everyone but the owner.
Yapay zekâ tarafından English dilinden çevrildi ·
Hayır, gruplar yalnızca ekler. Bir üyenin yetkileri, rolü ile etkin olan tüm grupların birleşimidir; hiçbir grup yetkilerden bir şey çıkarmaz.
Bir kişiyi rolünün izin verdiklerinden alıkoymak için reddetme (deny) içeren bir erişim politikası kullanın. Reddetme her zaman matrisin önüne geçer. Politikaları kurmak için Owner rolü gerekir: Erişim politikaları. Bir rolün tamamının değiştirilmesini istiyorsanız (örneğin kuruluşunuzdaki hiçbir User onaylayamasın), Access Rights matrisinde User için o hücrenin işaretini kaldırmak daha basittir.
No, groups only add. A member’s rights are the role plus every active group, and nothing in a group subtracts.
To hold someone back from what their role allows, use an access policy with a deny. A deny always wins over the matrix. Policies need the Owner role to set up: Access policies. If it’s a whole role you want changed (no User in your organisation may acknowledge), unticking that cell for User in the Access Rights matrix is simpler.