Windows 10: Things not opening

JakeIs sick · Aug 10, 2021

So whenever i try to open up a game the game would open into a black screen, shortly after opening the game it crashes so i tried to open up my device manger and that would open then crash as well. when the applications crash there is no troubleshooting screen that pops up. Google chrome will open fine and run with no complaints,same with discord and task manager.system ryzen 5 3600 16gbs 3600 vengeance lpx b550-a pro msi asus 1660 super ochttps://youtu.be/L6sFbObxO-Q here is a video of everything I tried to explain above

:)

Brink · Aug 10, 2021

Mail app will not open on 10041.

Hello Adam,

This is the suggested solution below if you haven't already tried it.

In this Windows 10 build 10041, the Mail, Calendar, and People apps may be broken due to a licensing issue with the Store Beta. To get these apps working again, you need to follow these steps:

Open powershell as administrator

Run the command Get-appxprovisionedpackage –online | where-object {$_.packagename –like “*windowscommunicationsapps*”} | remove-appxprovisionedpackage –online

Re-install Mail, People and Calendar from the Store (green tile)

Brink · Aug 10, 2021

Open Translators to Things: Open Approach for Accessing Similar Things

To help application developers more easily interact with the “Things” (e.g. light bulbs) around them, I am delighted today to introduce an alpha version of our new open source project Open Translators to Things (OpenT2T) on GitHub. Our goal is to enable application developers to write once, in an open and interoperable way, the exact same code to access functionalities that are shared across similar Things.

With this blog post, we introduce this new project and invite developers to take a look, check the code demo video, and hopefully join in making this open source project a success.

There are just too many different APIs that application developers need to use today to control very similar “Things” created by different manufacturers or by using different protocols. It was my honor to participate in Santa Clara in the Internet Architecture Board Semantic Interoperability workshop three weeks ago with 40+ participants (from OCF, AllSeen, W3C, Eclipse, OGC and others) to discuss this exact subject. At the workshop, I said that I would share some initial work we are doing on this to inform the conversation.

How many different APIs do you need to turn on a light, or read a temperature?

We believe end users prefer a very consistent user experience when they use similar devices (e.g. lightbulbs or thermostats), even when they come from different manufacturers or support different protocols. Similarly, we believe application developers need a consistent way to control similar devices as they create apps that can support, at scale, many manufacturers.

Suppose you want to build and sell a smart application for controlling the environment in peoples’ homes (or in factories), such as temperature, lighting, or ambience. Because you don’t control all of the environments in which your application runs, you need to support a number of different devices. But talking to these devices can be taxing.

Consider, for example, these small code snippets intended for reading the temperature from three different devices:

LM35 temperature sensor probe (adapted from here):

[table][tr][td]1[/td] [td]tempCC = (5.0 * reading(tempPin) * 100.0) / 1024.0 [/td] [/tr] [/table]

TMP36 temperature probe (adapted from here):

[table][tr][td]1[/td] [td]tempC = (5.0 * reading(tempPin) - 0.5) * 100[/td] [/tr] [/table]

Directly from a 10K Ohm Thermistor on a custom breadboard (adapted from here)

[table][tr][td]1 2 3[/td] [td]tempC = log(((10240000/ reading(tempPin)) - 10000)) tempC = 1 / (0.001129148 + (0.000234125 + (0.0000000876741 * tempC ^ 2)) * tempC ) tempC = temp - 273.15[/td] [/tr] [/table]

Similarly, how a developer turns on a light can vary much more than in the real world:

If you are using a Philips Hue (adapted from here):

[table][tr][td]1[/td] [td]PUT http://<bridge ip>/api/<username>/lights/1/state {"bri":254}[/td] [/tr] [/table]

If you are using a Wink Hub (adapted from here):

[table][tr][td]1[/td] [td]PUT https://api.wink.com/light_bulb/<device_id> {“desired_state": { “powered” : true} }[/td] [/tr] [/table]

Do app developers truly need to embed in their code specific knowledge of the characteristics of each physical device or hub?

The current alpha version uses JavaScript/Node.js, is open source and cross-platforms (with examples for Windows, OS X, Android, Azure, AWS). The basic logic, as we envision it, is composed of three parts: the schema, a translator, and the app.

“Things” start with schemas

We believe instead that developers should access a common “schema” across similar Things (e.g. a “Thermostat” or a “Light” schema) with specific properties (e.g. “Temperature” or “OnOff”).

Industry organizations, companies, or individuals create category schemas to describe devices (e.g. a schema to describe a light bulb or a thermometer). There are numerous existing initiatives doing this today with Open Connectivity Foundation’s oneIoTa tool being one of many examples. Microsoft will be working with the industry to create common schemas to describe similar Things, across protocols, in both the consumer and industrial space.

Translating a “Thing” to a common schema

Complementary to “schema” efforts, we also need a “translation” effort: We believe that the task of accessing the specific protocol calls supported by individual Things and turning it, here for example, into the Temperature or OnOff properties, is the job of a “translator” — a small piece of code that takes the input/output of an actual Thing and translates it into a common schema for application developers to access.

When many similar hardware devices are translated to the same schema, Cortana or apps or cloud automated rules can start targeting those common schemas and provide consistent and delightful experiences.

Developers interested in specific hardware will pick an existing schema (whatever is most suitable for that hardware) and write some cross-platform JavaScript code to translate the hardware to the schema. We think developers will “vote with their feet” and will connect their hardware to the most valuable schema they find and share their open source translator on OpenT2T. The best schema will get the most translators.

The job of the translator is to hide the implementation details about particular data models and protocols, exposing functionalities directly as programmable APIs. Turn a lightbulb on? No need for an app developer to think about RPC vs. REST, HTTP vs. MQTT, CoAP vs. ZigBee. What is needed is myBulb.turnOn() and the translator will map the API common schema call to the appropriate libraries to perform the operation. Cortana or other voice assistants could turn your bulb on whether it comes from Philips, Samsung, Wink, or another manufacturer.

Translators can run on local devices (PCs/tablets/phones) for proximally connected Things. Translators could also run in the cloud for cloud-connected Things or on gateways for gateway-connected Things and marshalled from the cloud.

The application experience

Application developers (client or cloud apps) can write the same code to control similar devices from different manufacturers, in an open and interoperable way. Developers achieve this by referencing the single category schema associated to similar Things and use the same function call defined by that schema to control them.

For example, suppose you want to write an application to read the temperature from a Texas Instruments CC2650 Sensor Tag. Here are the steps to do this, from the OpenT2T project:

Identify a category schema. In our initial alpha, we support the AllSeen schema syntax. You can see a very simple sample testing schema we wrote for our alpha version here. The goal is to bring consistency around schemas syntaxes and encourage the creation of schemas for different categories of Things. Together with you, we will do this through working with OCF and others in the industry. Our recommendation is to start with existing standard industry schemas though you may need to create sample schemas for testing purpose.

Find and use a translator already written by the community. Or help the community and write a translator for the data that comes off the CC2650 to that schema. The data that comes off the CC2650 device is described by Texas Instruments in a spec sheet, available here. You can see an example of that translator on the OpenT2T project here. The translator is written in JavaScript using Node.js in our alpha version but the community could decide to build support for other languages such as C++, C#, or Java.

Write an application that controls your Things, in this case the CC2650. You can see five sample applications on the OpenT2T project here. The alpha version has examples for writing UWP apps for Windows (C# example), Android apps (Java example), JavaScript/Node common cloud code (with Azure IoT Hub and AWS Kinesis specific examples). For example, in this temperature sample, there is a unique function call, m_Consumer.GetCurrentTemperatureAsync(), that needs to be called to get the temperature from all different hardware sensors that have been translated to the common sample schema.

Where we are right now and next steps

As an alpha project, we’re actively developing per our roadmap. Help us develop, test, and file issues. Keep in mind that it’s not ready for real deployment yet. The project is in the following six parts:

Translators: Repository of translators. They are grouped by translators written for a specific schema. The translator name is a unique string provided by the manufacturer identifying a “Thing” specific model
Next steps: We would love to work with the community to add new translators to the initial existing sample schemas, in order to help testing additional new Things and additional protocols.

Console: On PCs/tablets/phones, developers use the console app as a runtime to communicate with and onboard (i.e. initially setting up) actual Things. The console app hosts the node.js process: when a Thing is onboarded, it is recognized by its unique identifier, its translator loaded. The Thing is then exposed on the bus as a device supporting the schema it has been translated to.
Next steps: We hope the community will help us fully support Windows, OS X, finalize Android support, build iOS support, explore additional ways to host the runtime and to identify/build robust cross-platform libraries for the different protocol buses used to communicate with “Things”.

Cloud: In the cloud, developers use the same schema to communicate to similar Things translated to that schema in a node.js process.
Next steps: our call to the community is to help us test new Things and support additional protocols (CoAP, MQTT). We can achieve this by adding new translators, running on the cloud, for cloud-connected Things or by testing how to run Translators on gateways (e.g. Arduino, home Hubs, others) to gateway-connected Things marshalled from the cloud.

CLI: command line interface used by developers to onboard and communicate with actual Things and running the JavaScript translators.
Next steps: We would love to work with the community to round up the CLI to become the tool that developers use to run to test their JavaScript code.

Sampleapps: The alpha version provides samples of UWP apps for Windows (C# example), Android apps (Java example), JavaScript/Node common cloud code (with Azure IoT Hub and AWS Kinesis specific examples)
Next steps: We can work with the community to add sample apps for other UI frameworks such as Xamarin, Cordova or Swift and for other clouds such as Google Cloud.

Voice: By adding a voice file that can understand a specific schema, developers enable their favorite assistant to control virtually all similar things that are translated to that schema. A few samples voice files are provided for Cortana to control lights and thermostats.
Next steps: we would love to see the community add more voice files for Cortana for different categories of things and provide samples for other assistants such as Alexa and others.

How to get involved and join the discussion

Our hope is that developers will check out the project, view an end user and code demo videos, read the tutorial, ask questions, and contribute a first translator for their favorite hardware and overall to the project (please check our initial roadmap).

We are looking forward to continuing the discussions about Translation to Things in the Open Connectivity Foundation and with other groups, such as the Internet Architecture Board Semantic Interoperability workshop participants. Grounding those discussions around real code will help us tremendously.

We also checked the interest of other IoT developers and manufacturers in many companies in this space and many of them agreed to continue the conversation in the GitHub project. Among them are Sol Salinas (Accenture), Sergey Grebnov (Akvelon Inc), Acer, ASUS, David Plans (BioBeats), Dell, Lenovo, John Cameron (LIFX), Daniel Quant (Multitech), Brad Ree (Nortek), Jonathan Pickett and Charles Prakash Dasari (Schakra Inc.).

Today, we have pushed some alpha code on GitHub to start the conversation around translating Things to common schemas. In time, we hope OpenT2T becomes a vast repository of crowd-sourced cross-platform translators supporting a broad set of hardware Things and constantly curated by a thriving community where similar translators can compete, collaborate, combine, or diverge. Everyone could write a new translator to support a new hardware, from industry organizations to startups, from manufacturers to students, from enterprise to hobbyists. Translators can and will be forked, cloned, patched and discussed publicly: the proven dynamics of open source development will make the best translators associated to the best schemas emerge and provide long-term sustainability.

Written by Jean Paoli, Windows Developer Platform

Click to expand...

Source: Open Translators to Things: An Open Approach for Accessing Similar Things | Building Apps for Windows

NMI · Aug 10, 2021

Windows Update will not open in Settings

And, in particular, in your suggested step 4, why are we stopping 3 things for a second time ?
Surely we should be re-starting them having stopped them in step 1 ?
Click to expand...

Yes.

Windows 10: Things not opening

Things not opening

Things not opening

Things not opening

Things not opening - Similar Threads - Things opening

windows 11 putting things on my screen when lid is opened

windows 11 putting things on my screen when lid is opened

Why wont my installed apps open my browser for things like logging in?

Why wont my installed apps open my browser for things like logging in?

Sometimes when i boot up my computer it won't open thing such as chrome and steam gives me...

Sometimes when i boot up my computer it won't open thing such as chrome and steam gives me...

What are these startup things that ask to open my user on startup?

What are these startup things that ask to open my user on startup?

How do I remove this thing from my "Open with a different app" pop up?