Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 22 2018 12:20
    mijicd unassigned #296
  • May 22 2018 12:20
    mijicd unassigned #295
  • May 22 2018 12:20
    mijicd unassigned #282
  • May 22 2018 12:20
    mijicd unassigned #259
  • May 22 2018 12:20
    mijicd unassigned #245
  • May 22 2018 12:20
    mijicd unassigned #244
  • May 22 2018 12:20
    mijicd unassigned #239
  • May 22 2018 12:20
    mijicd unassigned #237
  • May 22 2018 12:20
    mijicd unassigned #236
  • May 22 2018 12:20
    mijicd unassigned #216
  • May 22 2018 12:20
    mijicd unassigned #214
  • May 22 2018 12:20
    mijicd unassigned #195
  • May 22 2018 12:20
    mijicd unassigned #195
  • May 22 2018 12:20
    mijicd unassigned #195
  • May 22 2018 12:20
    mijicd unassigned #200
  • May 22 2018 12:20
    mijicd unassigned #197
  • May 22 2018 12:20
    mijicd unassigned #195
  • May 22 2018 12:20
    mijicd unassigned #198
  • May 22 2018 12:20
    mijicd unassigned #195
  • May 22 2018 12:20
    mijicd unassigned #194
magixmin
@magixmin
ok got . thanks men
Manuel Imperiale
@manuio
:+1:
magixmin
@magixmin
new errot :
mainflux-mqtt | {"level":"info","message":"Accepted new client","ts":"2021-01-23T11:30:03.263479756Z"}
mainflux-mqtt | {"level":"info","message":"Connect - client with ID: mqttjs_9bcb914a","ts":"2021-01-23T11:30:03.264903865Z"}
mainflux-mqtt | {"level":"info","message":"Disconnect - Client with ID: mqttjs_9bcb914a and username 04978536-4637-4e4a-acf3-7ece01faf2fb disconnected","ts":"2021-01-23T11:30:03.271117687Z"}
mainflux-things | {"level":"warn","message":"Method can_access_by_id for channel 12f86e57-74c1-4888-b5e1-8dd7fda78116 and thing 04978536-4637-4e4a-acf3-7ece01faf2fb took 875.639µs to complete with error: non-existent entity.","ts":"2021-01-23T11:30:03.270858068Z"}
i user mqtt.js

var mqtt = require('mqtt')

var defaultConnectOptions = {
keepalive: 60,
username: "04978536-4637-4e4a-acf3-7ece01faf2fb",
password:"12f86e57-74c1-4888-b5e1-8dd7fda78116",
}

var channelId = '12f86e57-74c1-4888-b5e1-8dd7fda78116'
var topic = 'channels/' + channelId + '/messages'

var client = mqtt.connect('tcp://iot.javodata.com:1883',defaultConnectOptions)

client.on('connect', function () {
// client.subscribe('myChannel', function (err) {
// if (!err) {
// client.publish('presence', 'Hello mqtt')
// }
// })
client.publish(topic, 'Message', '[{"bn":"Dev1","n":"temp","v":20}, {"n":"hum","v":40}, {"bn":"Dev2", "n":"temp","v":20}, {"n":"hum","v":40}]')

})

Manuel Imperiale
@manuio
@magixmin this is clearly wrong:
password:"12f86e57-74c1-4888-b5e1-8dd7fda78116",
}

var channelId = '12f86e57-74c1-4888-b5e1-8dd7fda78116'
password should be the thing key
Misbah Ulhaq
@mmulhaq_twitter
Helo
I had given some time previously last year was successful in installing and configuring MainFlux.... I was also able to work with MainFlux Ui... Now i want to send a notification or call to an external api like soap service or rest service or any thing related to this....
What is the best possible way is there a direct integraton capability or I have to put listener on the database or I can use the any Message Queue for this purpose.
Any guidance will be helpful
Scenerio is like this...
things --> Mainflux ---> External services ----> Mobile/Web applicaition
Manuel Imperiale
@manuio
@mmulhaq_twitter You can create your own message consumer following writers example: https://github.com/mainflux/mainflux/tree/master/consumers
magixmin
@magixmin
@manuio that i have found that .but now send message still have error
connection is accpeted
Manuel Imperiale
@manuio
@magixmin I can't understand whithout more details
magixmin
@magixmin

var mqtt = require('mqtt')

var defaultConnectOptions = {
keepalive: 60,
clientId: '04978536-4637-4e4a-acf3-7ece01faf2fb',
username: "04978536-4637-4e4a-acf3-7ece01faf2fb",
password:"12f86e57-74c1-4888-b5e1-8dd7fda78116",
}

var channelId = '8651eea5-a2c6-4e02-b4a6-4c46877f2497'
var topic = 'channels/' + channelId + '/messages'

var client = mqtt.connect('mqtt://iot.javodata.com',defaultConnectOptions)

client.on('connect', function () {
// client.subscribe('myChannel', function (err) {
// if (!err) {
// client.publish('presence', 'Hello mqtt')
// }
// })
client.subscribe(topic, { qos: 0 })

var domessage = [{"bn":"Dev1","n":"temp","v":40}, {"n":"hum","v":40}, {"bn":"Dev2", "n":"temp","v":40}, {"n":"hum","v":40}]
client.publish(topic, 'WS connection demo!',domessage.toString() )

})

client.on('message', function (topic, message) {
// message is Buffer
console.log(message.toString())
client.end()
})

mainflux-mqtt | {"level":"info","message":"Accepted new client","ts":"2021-01-25T10:50:16.883561817Z"}
mainflux-mqtt | {"level":"info","message":"Connect - client with ID: 04978536-4637-4e4a-acf3-7ece01faf2fb","ts":"2021-01-25T10:50:16.88661259Z"}
mainflux-twins | {"level":"warn","message":"Method save_states took 35.03µs to complete with error: failed to get twin id from redis cache : dial tcp 127.0.0.1:6379: connect: connection refused.","ts":"2021-01-25T10:50:16.901513058Z"}
mainflux-twins | {"level":"error","message":"State save failed: failed to get twin id from redis cache : dial tcp 127.0.0.1:6379: connect: connection refused","ts":"2021-01-25T10:50:16.901576306Z"}
mainflux-twins | {"level":"warn","message":"Failed to handle Mainflux message: failed to get twin id from redis cache : dial tcp 127.0.0.1:6379: connect: connection refused","ts":"2021-01-25T10:50:16.901589268Z"}
mainflux-mqtt | {"level":"info","message":"Subscribe - client ID: 04978536-4637-4e4a-acf3-7ece01faf2fb, to topics: channels/8651eea5-a2c6-4e02-b4a6-4c46877f2497/messages","ts":"2021-01-25T10:50:16.899834916Z"}
mainflux-mqtt | {"level":"info","message":"Publish - client ID 04978536-4637-4e4a-acf3-7ece01faf2fb to the topic: channels/8651eea5-a2c6-4e02-b4a6-4c46877f2497/messages","ts":"2021-01-25T10:50:16.901016852Z"}
mainflux-influxdb-writer | {"level":"warn","message":"Failed to handle Mainflux message: failed to decode senml : invalid character 'W' looking for beginning of value","ts":"2021-01-25T10:50:16.90430598Z"}
mainflux-mqtt | {"level":"info","message":"Disconnect - Client with ID: 04978536-4637-4e4a-acf3-7ece01faf2fb and username 04978536-4637-4e4a-acf3-7ece01faf2fb disconnected","ts":"2021-01-25T10:50:16.908110846Z"}
mainflux-mqtt | {"level":"warn","message":"Broken connection for client: 04978536-4637-4e4a-acf3-7ece01faf2fb with error: failed proxying from MQTT client to MQTT broker : read tcp 172.19.0.29:52568->172.19.0.8:1883: read: connection reset by peer","ts":"2021-01-25T10:50:16.908882398Z"}
mosquitto_pub -u 04978536-4637-4e4a-acf3-7ece01faf2fb -P 12f86e57-74c1-4888-b5e1-8dd7fda78116 -t channels/8651eea5-a2c6-4e02-b4a6-4c46877f2497/messages -h localhost -m '[{"bn":"Dev1","n":"temp","v":25}, {"n":"hum","v":35}, {"bn":"Dev2", "n":"temp","v":35}, {"n":"hum","v":35}]' is work .
Misbah Ulhaq
@mmulhaq_twitter
@manuio Thank you for the guidance, its seems all the consumers are dumping the data in postgras, cassendra, mongo , influx. Is there any use case in which the data is passed to any message queue like kafka, Active MQ, RabbitMQ etc.. or I have to wirte my version of a writer
PricelessRabbit
@PricelessRabbit
Hi all. i'm having an issue with the mainflux agent and nats commands relay (im using the 0.11 tag version). the issue is that when the mqtt connection is lost and then agent reconnects to the server, it no longer relay service messages (commands coming from mainflux) into nats topic. if i restart the service then commands are relayed correctly. Is it a known bug?
PricelessRabbit
@PricelessRabbit
i reproduced the issue in my local env. i just opened an issue here mainflux/agent#48
Manuel Imperiale
@manuio
@mmulhaq_twitter This is one of the things that the mqtt-adapter can do, forward messages in a specific broker: https://github.com/mainflux/mainflux/blob/master/cmd/mqtt/main.go#L161
Manuel Imperiale
@manuio
In any case we have to document this better
@PricelessRabbit Thanks you, we will check!
Dave
@rising_dark_gitlab

@manuio @manuio @manuio @manuio

@rising_dark_gitlab yes it is. Check here: https://github.com/mainflux/devops/

Hi, thanks for that. As I mentioned I've deployed using that, and my question is about how "tested", "stable" or "supported" these things are.
I ask because somes services (nginx, postgres) uses persistent volume claims, but other (redis-authn) use local storage.
Is this because the redis storage is simply a cache (transient) or because it is misconfigured?
I'm new to mainflux and kubernetes, I've been testing on a simple docker deployment, but now I'm trying to perform a kubernetes
deployment I've having issues with pods creating local storage that has to be deleted when migrating the pod.
:confused:

Dave
@rising_dark_gitlab
I'm starting to think the "mainflux-redis-auth-master" is generated automatically from the redis imported helm chart because it is referred to by a mainflux service.
So I should download the redis charts and see how they manage persistent storage.
Dave
@rising_dark_gitlab
I think I've finally put 2 and 2 together to make 5 or 6.. the "REDIS" chart enables persistence by default, but the mainflux charts define redis-auth.master.persistence.enabled=false
Am I meant to customize that for a deployment? Or is the data in redis truly transient?
Thanks, and my apologies for the noise.
Referring back to the mainflux manual, redis only exists to provide an event source via redis streams. There is no data stored in redis, so yes, it is completely transient.
Manuel Imperiale
@manuio
@rising_dark_gitlab check here: https://github.com/mainflux/devops/blob/master/charts/mainflux/templates/things-deployment.yaml#L28 and here: https://github.com/mainflux/mainflux/blob/master/cmd/things/main.go#L138
It's used as Things service auth cache. Redis is not only used for event sourcing.
Dave
@rising_dark_gitlab
@manuio That is correct, but
https://github.com/mainflux/devops/blob/master/charts/mainflux/values.yaml#L199
Clearly shows that "persistence" is disabled for "redis-auth". Should I enable persistence for redis-auth? or is it safe to delete/recreate (will it just force re-authentication?)
Dave
@rising_dark_gitlab
interestingly, redis-streams-master DOES have persistence enabled. I'm clearly confused about this. Is it something I need to worry about? I've force migrating via kubectl drain --delete-emptydir and things seem to keep working.
Manuel Imperiale
@manuio
@rising_dark_gitlab redis-auth recreate a mapping of ID/Key in the RAM to accelerate future Identity requests. If you restart the service it it will be generated again without lossing any information since all it's persistent in Things DB. But you can also use persistent volume. It's up to you.
Dave
@rising_dark_gitlab
@manuio Thanks for clarifying. I'm happy not to use persistent volumes, I was just a little taken aback by the need for kubernetes to purge the data when migrating the pod to another node. All is clear now.
Manuel Imperiale
@manuio
@rising_dark_gitlab great! :+1:
magixmin
@magixmin
hey man , why my grafana awalys show Network Error: Bad Gateway(502)
but it`s work befor ?
magixmin
@magixmin
Alexander Teplov
@teploff

Hello everyone!
Dear @drasko @nmarcetic give some advices please.
My question concerns dynamic configuration.
Are there some ways to get data flow from new things which was added after app connection with Mainflux had established?
In more detail:
1) create Mainflux user
2) under created user create things: "a", "b", "c" and application "app" and channels.
3) Things ("a", "b", "c") start to publish data , thing("app") start to subscribe, and it works well.
4) After that user forget to add thing "d", and create it.
So how to get data flow from thing "d" without restarting subscribe thing "app"?

Thanks

Manuel Imperiale
@manuio
@molodoj88 simply connect the new thing ("d") to the same channel and you will be able to get the data without restarting anything
Drasko DRASKOVIC
@drasko
@teploff I think you are refering to Writers, which have a hard-coded config file to connect to NATS
they are stateless in order to be clusterable, so we do not change their internal state
What you should do with your app is not to subscribe directly to NATS, but rather go via frontend protocol adapters (MQTT, WS, CoAP, HTTP, ...)
this way you can subsribe/unsubscribe dynamically
NATS is in internal network and is good for internal applications / DB writers
however when building outside applications on the top of Mainflux, better is to treat them like ordinary things and use their API keys for auth
Being in internal network, NATS is not protected by the auth
That being said - you can just use config file to subscribe to all NATS channels (*)