Hi Gregg,
I am interested in having MacOS support on iotivity. I have done few patches in
the past to make it better but it still has long way to go. Most of it is
trivial maintenance work, tweaking the scons files to pick up correct files for
required configurations. Now, for example, security
On Monday, 4 December 2017 19:10:53 PST Gregg Reynolds wrote:
> Sorry about previous message. New phone
>
> Anyway, hmmm. If that is the case what is the point of certification?
> Nobody asks a web server for that kind of certification, it all just works.
> Is there anything to certification beyon
Greetings,
The design intent was not originally two ways to do the same thing; dimming
(not 'dimness') represents the actuation of a dimmer function that meets the
requirements Michael enunciated already (it's a server defined range that
defaults to 0..100 but can be anything within the limits
On Dec 4, 2017 8:42 PM, "Thiago Macieira" wrote:
On Monday, 4 December 2017 18:33:44 PST Gregg Reynolds wrote:
> Was just looking at the cert page on the OCF website. That text strongly
> implies that only devices can be certified. If that is the case then how
> can a generic OCF "engine" like I
According to the OCF "Certified Product Registry" we have a grand total of
four (4! count 'em!) OCF products. Two of which come from Samsung.
What does that mean? A disaster or an opportunity? Are people building OCF
products but disregarding certification? Or (shudder) is OCF slowly dying?
(I not
On Monday, 4 December 2017 18:33:44 PST Gregg Reynolds wrote:
> Was just looking at the cert page on the OCF website. That text strongly
> implies that only devices can be certified. If that is the case then how
> can a generic OCF "engine" like Iotivity (or OpenOCF) be certified?
It cannot. You
Was just looking at the cert page on the OCF website. That text strongly
implies that only devices can be certified. If that is the case then how
can a generic OCF "engine" like Iotivity (or OpenOCF) be certified?
g
___
iotivity-dev mailing list
iotivit
+1 and lol
Input for the lighting model design...
We really only need one way to express brightness setting of a light, and it
should allow the control of real products with their diverse scales (though
many seem to be 0-255). There will need to be some adaptation somewhere, but
not in multipl
On 12/04/2017 03:18 PM, Gregg Reynolds wrote:
> Last time I looked iotivity did not support nw monitoring for if address
> changes for Mac. This is 1.3.x code.
>
> I'm looking into adding such support. Anybody wanna help?
>
> afaik on the Mac you must use the System Config framework. Ok. Not ter
On Dec 4, 2017 3:07 PM, "Mark Trayer" wrote:
Greetings,
To go to your original question it really depends on what you want to
expose with respect to your particular light device. The only resource a
light must expose is oic.r.switch.binary (i.e. you can turn it off and on),
everything else is
Hi George,
You're reading is correct. However, it's not likely you would be designing a
multi-RT with two types for which the range property would be needed. In that
case, you would be likely to have have two different measured (or set)
quantities and a collection would be more in line with the
On Dec 2, 2017 6:42 AM, "Wang, Xin" wrote:
Hi,
I have a question regarding to the “Resource Identity” in OCF core spec
1.3. Any comments is appreciated here.
I understand the “href” as discovered in the response of /oic/res can be
used as unique identifier of a resource instance. So usually
Last time I looked iotivity did not support nw monitoring for if address
changes for Mac. This is 1.3.x code.
I'm looking into adding such support. Anybody wanna help?
afaik on the Mac you must use the System Config framework. Ok. Not terribly
hard. But it exposes a flaw in iotivity implementati
If I have a dimmable light, should I expose it with dimming or brightness or
both? It sounds like the answer today is "up to you",
which means if I'm developing a dimmer switch (app or device with a client app
embedded), then I currently need to support both
or there's no guarantee of interoper
Greetings,
To go to your original question it really depends on what you want to expose
with respect to your particular light device. The only resource a light must
expose is oic.r.switch.binary (i.e. you can turn it off and on), everything
else is an implementation choice and comes down to ho
Thanks that answers a lot of questions.
Based on your responses, I assume, if you have a Multi-type RT and two of the
resources want to set one of the oic.r.baseresource values (two resources want
to use "range") then it would not be eligible for Multi-type RT and would have
to be represented a
On 12/04/2017 12:46 PM, Mark Trayer wrote:
> Greetings,
>
> You don't need to do anything with the RT in the actual Resource on the wire;
> as Wouter noted the 'baseresource' is a schema mechanism by which we can
> define 'properties available to any OCF resource instance' without having to
> e
Greetings,
You don't need to do anything with the RT in the actual Resource on the wire;
as Wouter noted the 'baseresource' is a schema mechanism by which we can define
'properties available to any OCF resource instance' without having to
explicitly call them out every time, take a look at any
I finally found the section on the oic.r.baseresource in the OCF Resource Type
Specification 1.3 in the "Annex A Base Resource Schema" (Page 269 line 13785).
The section did not do anything to answer my questions on how to actually use
the base resource.
From: smarthome...@members.openconnecti
Wouter,
Thanks for the response.
If you want to include the base properties from the 'oic.baseresource' are you
required to include it in "rt" array?
Example:
{
"rt" :["oic.baseresource", "oic.r.light.dimming"],
"if": ["oic.if.baseline"],
Hello IoTivity Developers and Community!
We need to do some infrastructure maintenance on the web front end to a
number of the IoTivity web sites, namely:
- git.iotivity.org
- gerrit.iotivity.org
- jira.iotivity.org
- api-docs.iotivity.org
- downloads.iotivity.org
- sonar.iotivity.org
On Mon, Dec 4, 2017 at 6:35 AM, Khaled Elsayed wrote:
> Great to know I was not the only one who dislike scons. Never worked with
> Bazel. Still think that make/autoconf are the greatest tools in software :)
> I think that if a bold switch to make is done, it will be a great step
> forward at lea
On 12/04/2017 05:35 AM, Khaled Elsayed wrote:
> Great to know I was not the only one who dislike scons. Never worked with
> Bazel. Still think that make/autoconf are the greatest tools in software :)
I personally have years of comfort with make, and years of discomfort
with automake (it's great, u
Hi everyone,
On 04/12/17 15:29, Mats Wichmann wrote:
> On 11/30/2017 11:56 PM, ABITHA S wrote:
>> Dear All,
>>
>> I am glad to announce that *RC6* tagging is done on *1.3-rel* branch.
>>
>> With *1.3.1-RC6* there was a failure related to Random PIN based OTM, which
>> has
>> been fixed.
>>
>> P
On 11/30/2017 11:56 PM, ABITHA S wrote:
> Dear All,
>
> I am glad to announce that *RC6* tagging is done on *1.3-rel* branch.
>
> With *1.3.1-RC6* there was a failure related to Random PIN based OTM, which
> has
> been fixed.
>
> Please use 1.3.1-RC6 + patch (https://gerrit.iotivity.org/gerrit
Hi George,
oic.r.baseresource is not a resource, but an mechanism to include the base
properties of an resource, as example:
{
"rt" :["oic.baseresource"],
"if": ["oic.if.baseline"],
"id": "unique_example_id",
Great to know I was not the only one who dislike scons. Never worked with
Bazel. Still think that make/autoconf are the greatest tools in software :)
I think that if a bold switch to make is done, it will be a great step
forward at least to break the barrier for a learning curve for another
build e
On 04/12/17 08:00, Geonho Kim wrote:
> I met now below error message when I had built iotivity 1.2.1 on yocto
> rocko branch.
> I'm not sure whether that is now issued problem or it happended only
> my PC.
>
>
> |
> /home/xxx/yocto/yocto-rocko/305-build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi
28 matches
Mail list logo
