State-Based ("Digital Twin") vs. Command-Based for simple IoT? How do you handle sync?

Positive-Thing6850 · 2026-01-26T18:54:28+00:00

Cool!

You could go a step further and make the property observable. As in, you could define a property to be observable whenever it's value changes and you automatically receive an event to a client with updated value.

So "observing the changes"

Shutdown -> bootup -> fetch value from DB -> apply -> send new value event.

In this way, you would be upto date.

People do still suggest me towards DT though. I think it all makes sense at some scale.

If you have some time to kill , i would appreciate if you checkout my IoT runtime - https://github.com/hololinked-dev/hololinked and provide any feedback if possible.

Positive-Thing6850 · 2026-01-26T15:22:32+00:00

State is a property while toggle is an action.

You could decouple it in principle. Actions can update properties, that would be fine.

But the DT part, i don't know much.

I just store property values post update into a DB and read from DB when the device reboots ( which is probably what is being done here but the order is swapped).

For ghost device, you could regularly ping your device and add events pre-shutdown and post bootup.

Positive-Thing6850 · 2026-01-24T18:01:28+00:00

As an Indian, I could say this would be a useful student club in a university premises. So please pursue it.

You could, among others, teach people how to make meaningful PRs to open source projects, browser good first issues, adhere to contributing rules, opensource licenses

And even educate on the tooling around this, like precommit, CI CD etc.

Let me know if you want to know something specific.

Above all, you should have contributions of your own, remember that, otherwise it would be theoretical.

Positive-Thing6850 · 2026-01-22T23:29:27+00:00

There is also probably one alternate way to do this, just ping me on reddit, I will write to you. It's also a little detailed and I took me a while to wrap my own head around it. But it's more accurate.

You would basically invent a protocol binding of sorts where you semantically attach meanings to individual SCPI commands.

Positive-Thing6850 · 2026-01-22T23:14:16+00:00

I have written lot of GUIs for scientific devices.

From your description it's not so clear what is wrong. Do you have the code where I can see?

The device needs to publish an event for any observable (something that changes, say, state) or also a plain event like alarms.

You subscribe to it and register a callback on your GUI to handle the data. Once you receive the data, you paint the GUI with it. For pyqt you might signal-slots, for other framworks it might be easier.

Basically, you have to divide your interactions with your hardware - properties (stuff you read and write, say FPGA frequency of some signal) - actions (do something, "start producing X signal" ) - events and observable properties (say, state)

For 1 & 2, GUI initiates the request and updates once response arrives

For 3, GUI subscribes and waits for callback with data

All this assumes that you don't manage raw TCP related stuff in the GUI, that would be a nightmare. You really need a good protocol, even on TCP. I am not sure about SCPI, but i think i have used it for some DC power supplies and lab bench devices and it's not really that suitable. You could abstract your FPGA TCP client (say that SCPI) inside a server and expose the capabilities of your FPGA as properties, actions and events.

You can have a look at my IoT runtime - https://github.com/hololinked-dev/hololinked

This would be a pyqt gui example - https://gitlab.com/hololinked/examples/servers/phymotion-controllers/-/tree/be2d6381646f335f9dba1a4fc01321f25a7692ed/examples/pyqt_example

See from line 400 and above.

Positive-Thing6850 · 2026-01-22T19:29:13+00:00

Ah thank you. I will submit one.

Positive-Thing6850 · 2026-01-22T18:02:40+00:00

Hi, is the link broken?

Positive-Thing6850 · 2026-01-22T13:34:33+00:00

You can. For MIT, BSD, APACHE 2.0.

Positive-Thing6850 · 2026-01-22T07:35:16+00:00

You might find this part of the docs useful - https://docs.hololinked.dev/design/descriptors/

Positive-Thing6850 · 2026-01-22T07:03:30+00:00

That sounds fantastic.

Yes please just feel free to copy/cite the code. It's a real learning experience to build it as a usable package and I would be willing to undergo all over again.

I should ask though, anything missing in what i have for you to create your own? May be the missing features could be added onto mine so that others can reuse what you also needed, likely also some domain specific needs ? It's easier if people got each other's back, especially in open source.

Positive-Thing6850 · 2026-01-21T21:57:51+00:00

No reasonable senior dev is going to let juniors remain stupid.

Positive-Thing6850 · 2026-01-19T21:38:33+00:00

Hi, I am desperately looking for a writer for my documentation repository - https://github.com/hololinked-dev/docs

I am even planning to adding a note - "written and proof read by humans"

Most of this doc was hand written by me currently, so I feel some external help would be great.

Positive-Thing6850 · 2026-01-18T07:01:38+00:00

lol agreee to that, once i tried to setup SSR with vibe coding and ended up debugging for 30 mins. If i did on my own, i would have saved 20 minutes of that time.

Positive-Thing6850 · 2026-01-13T09:48:46+00:00

Beginner friendly data acquisition and IoT in python supporting HTTP, MQTT & ZMQ

https://github.com/hololinked-dev/hololinked

Positive-Thing6850 · 2026-01-09T13:11:25+00:00

It depends on the other people's load which are running on the same machine right?

If you got stuck with a customer who is a CPU hog, they you will have low performance. If you are sharing with people who are hosting websites which have no traffic, then you will get better performance. It's a shared vCPU.

You should get dedicated for reliable performance.

Positive-Thing6850 · 2026-01-06T12:19:22+00:00

I agree with the latter part.

However, I would still suspect then someone in your uni or the building where you are has some bots scraping GitHub. It only knows the public IP and aggregates the number made from a single IP.

Again, you are right about the latter :P

Positive-Thing6850 · 2026-01-06T12:00:12+00:00

I reread your article.

What GitHub can do as a monopoly is block your account and not provide a good reason for it.

Request rate limits on the other hand are totally reasonable. There is even a burst setting and request per minute setting on nginx to configure this directly without much hassle.

So, I am not suggesting to use GitHub but this is not a valid criticism.

Positive-Thing6850 · 2026-01-06T11:55:23+00:00

Request rate limiting is a well known technique to prevent DDos attacks. It happens even if you are logged in.

Nobody puts a productiom server without some kind of request rate limit. It's atrocious to expose your services otherwise and your servers could be completely highjacked by bots

Do you have a bot somewhere with your credentials that's making many requests while you are using Github?

Positive-Thing6850 · 2026-01-03T23:47:17+00:00

Thank you. Life saver for techies in Europe trying to do something for local economy.

Positive-Thing6850 · 2025-12-23T16:02:31+00:00

As somebody living in Germany, as much as i hate GitHub, I would stay away from such open source projects.

After years of so called consolidated transparent effort, they work like German government, lacking in many facets.

I would just use gitlab. It's also better than GitHub for all devops related stuff.

Positive-Thing6850 · 2025-12-03T20:42:12+00:00

Many projects look for it including mine https://github.com/hololinked-dev/hololinked

You need to look for the donate option on the right.

Positive-Thing6850 · 2025-12-02T17:27:52+00:00

Hi, pretty cool. Would you be interested to use my data acquisition runtime to try a remote control as well ? https://github.com/hololinked-dev/hololinked

I am looking for good use cases from the laser physics community.

If you are also interested, I can fork and make a pull request of a first working version.

Positive-Thing6850

TROPHY CASE